Cartoon by Scott Simmerman

Menyambut Kelahiran Davin

Hari ke-empat di bulan suci Ramadhan 1441H atau Senin 27 April 2020 (Masehi) atas izinNya, telah dilahirkan putra pertama anak pertama kami, yang kami beri nama Davin dan disematkan nama marga Afifudin.

Semula proses persalinan dijadwalkan Selasa pagi 28 April, namun ketika kami tiba di RS pada malam hari sebelumnya untuk dilakukan pemeriksaan dan persiapan-persiapan, ternyata dari hasil pemeriksaan tersebut maka tim medis memutuskan agar proses persalinan dipercepat, yaitu malam itu juga. Puji Tuhan berjalan lancar dengan catatan kelahiran pukul 21.21.

Davin lahir di masa puasa Ramadhan dan ketika dunia sedang dilanda pandemi Covid-19. Prosedur-prosedur dari RS yang harus dilakukan antara lain rapid test untuk ibu Davin sebelum tindakan medis dilakukan, rapid test bagi Davin ketika lahir, suami tidak diperkenankan masuk ke ruang tindakan untuk mengurangi risiko Covid-19, dan tidak diperbolehkan tamu berkunjung selama dirawat di RS, kecuali neneknya namun dianjurkan juga tidak. Domisili orang tua saya & istri juga bukan di Bandung, dan karena pembatasan pergerakan masyarakat terkait Covid-19, maka hanya kami berdua yang saling menemani dibantu dengan semua staf medis RS.

Berselang 3 hari kemudian, tanggal 30 April, dokter penanggung jawab dengan memperhatikan perkembangan Davin dan ibunya, maka kami diizinkan untuk pulang ke rumah. Jalanan di kota Bandung dalam masa-masa tersebut relatif sepi dikarenakan anjuran dan peraturan agar orang-orang bekerja dari rumah (work from home) dan menghindari bepergian jika tidak penting.

Pertimbangan Membeli Komputer Mainframe

Semahal dan secanggih apapun komputer server yang dibeli, termasuk mainframe, manfaat yang diperoleh ditentukan oleh beberapa faktor, terutama:

• Ketersediaan software sesuai kebutuhan. Jika ternyata komputer tersebut tidak memiliki software yang dibutuhkan, maka tentu harga yang mahal menjadi sia-sia. Kemampuan processing yang diunggulkan di spesifikasi hardware menjadi tidak maksimal penggunaannya bahkan mungkin memberikan hasil yang tidak jauh berbeda dengan komputer server non-mainframe. Ketersediaan software ini pun harus sesuai dengan kebutuhan-kebutuhan yang spesifik dari organisasi/perusahaan, yang mana kebutuhan tersebut dijadikan alasan pengadaan server yang mahal. Dan bukan tidak mungkin jika kebutuhan tersebut tidak bisa dipenuhi oleh software yang telah tersedia di pasaran, sehingga harus dibangun khusus dan direkayasa (engineered) sedemikian rupa agar mendayagunakan sumber daya yang menjadi keunggulan server mahal tersebut.
• Data yang menjadi masukan bagi software. Masih terkait dengan faktor pertama di atas, bagaimana data yang menjadi input diperoleh dan diolah oleh software. Jika data input tidak berkualitas keabsahannya maka keluaran yang diberikan juga tidak bisa dijadikan pegangan bagi pihak yang berkepentingan. Masalah data ini turut dipengaruhi oleh rancangan software dan tentunya kembali ke apa kebutuhan dari sistem yang hendak dibangun.
• Pengoperasian software dan hardware (komputer server). Jika kemampuan pengoperasian baik oleh manusia ataupun secara otomatis oleh mekanisme apapun itu, tidak memadai atau tepat, maka outcome-nya juga tidak maksimal atau bahkan salah. Pengoperasian dalam hal ini juga  meliputi bagaimana data disediakan dan diinput (apakah secara manual atau dalam bentuk lain) serta bagaimana hasil output dimanfaatkan.

Jadi apakah sudah tepat merumuskan kebutuhan sehingga memerlukan tenaga komputasi yang disediakan oleh server mahal? Bagaimana kesanggupan untuk pengoperasiannya? Dan bagaimana perawatannya apakah pengadaan ini untuk kebutuhan jangka panjang atau hanya 1-3 tahun saja?

Framework Marriage

Our team have been building a software for more than a year, and sometimes it makes me think about our framework usage. Then I read this passage from Robert C. Martin book, Clean Architecture which I mostly agree:

Asymmetric Marriage
The relationship between you and the framework author is extraordinarily asymmetric. You must make a huge commitment to the framework, but the framework author makes no commitment to you whatsoever.

Think about this point carefully. When you use a framework, you read through the documentation that the author of that framework provides. In that documentation, the author, and other users of that framework, advise you on how to integrate your software with the framework. Typically, this means wrapping your architecture around that framework. The author recommends that you derive from the framework's base classes, and import the framework's facilities into your business objects. The author urges you to couple your application to the framework as tightly as possible.

For the framework author, coupling to his or her own framework is not a risk. The author wants to couple to that framework, because the author has absolute control over that framework.

What's more, the author wants you to couple to the framework, because once coupled in this way, it is very hard to break away. Nothing feels more validating to a framework author than a bunch of users willing to inextricably derive from the author's base classes.

In effect, the author is asking you to marry the framework - to make a huge, long-term commitment to that framework. And yet, under no circumstances will the author make a corresponding commitment to you. It's a one-directional marriage. You take on all the risk and burden; the framework author takes on nothing at all.

The Risks
What are the risks? Here are just a few for you to consider.

• The architecture of the framework is often not very clean. Frameworks tend to violate the Dependency Rule. They ask you to inherit their code into you business objects - your entities! They want their framework coupled into that innermost circle. Once in, that framework isn't coming back out. The wedding ring is on your finger; and it's going to stay there.
• The framework may help you with some early features of your application. However, as your product matures, it may outgrow the facilities of the framework. If you've put on that wedding ring, you'll find the framework fighting you more and more as time passes.
• The framework may evolve in a direction that you don't find helpful. You may be stuck upgrading to new versions that don't help you. You may even find old features, which you made use of, disappearing or changing in ways that are difficult for you to keep up with.
• A new and better framework may come along that you wish you could switch to.

The Solution

What is the solution?

Don't marry the framework!

Kembali Lembur Malam Hingga Dini Hari

Di usia yang semakin bertambah ini, dan meski telah memiliki beberapa rekan muda di perusahaan, tentu masih ada urusan yang memerlukan saya untuk menyelesaikannya secara langsung. Dalam 4 hari terakhir ini saya kembali melakukan aktivitas hingga lewat tengah malam.

Hari pertama, janjian dengan tim IT klien kami di Padalarang untuk melakukan maintenance server linux. Dikarenakan staf kami dan klien masih kurang pengalaman dengan linux, maka saya tangani langsung. Jadwal pengerjaan dimulai dari 22.30 hingga menjelang 02.30. Tentunya ada variabel-variabel X yang muncul secara tidak terduga dan terpaksa dicarikan solusinya dengan analisis dan sintesa pengetahuan.

Hari yang ke-dua, berangkat menuju kota Makassar. Dengan ditemani salah satu staf programmer kami, tepat pukul 02.02 meluncurlah kami ke Bandara Udara Kertajati dari kota Bandung. Sopir travel lumayan kebut dan ~2 jam (pukul 04.01) kami tiba di area keberangkatan.

Hari yang ke-tiga, setelah tiba di kota Makassar dan langsung berkegiatan di lokasi-lokasi klien, saya baru kembali ke rumah setelah pukul 22.30. Yang ini tentu tidak sampai lewat tengah malam.

Hari ke-empat, kembali melakukan maintenance server di lokasi klien yang lain lagi. Maintenance dilakukan menunggu ditutupnya aktivitas operasional. Dimulai sekitar pukul 23.00 hingga selesai pukul 2 dini hari.

Semoga semua aktivitas yang kami lakukan memberi manfaat bagi banyak orang dan dihitung sebagai amal ibadah.

Feasibility dan Visibility dari Proyek Pembangunan Perangkat Lunak

Dua kata yang pengucapannya mirip yaitu feasibility dan visibility. Namun yang pertama memiliki arti kelayakan dan yang terakhir visibilitas (jelas terlihat/terbaca).

Dalam konteks software project management, dulu saya pikir dua hal ini sama, bahkan mengira penulisan seperti "visibilitas proyek" adalah salah tulis yang harusnya "kelayakan proyek" alias project feasibility, tapi ternyata memang berbeda maknanya. Secara umum saya mengambil definisi berikut (setelah baca sana sini, terutama dari https://www.simplilearn.com/feasibility-study-article dan https://www.liquidplanner.com/blog/project-management-challenge-5-no-visibility-project-status/):

Feasibility (kelayakan) proyek adalah penilaian potensi keberhasilan dari pengerjaan proyek. Feasibility ini adalah aspek yang harus dilakukan di awal untuk menentukan layak tidaknya suatu proyek dilaksanakan. Jika dinilai tidak layak maka tidak dikerjakan atau dicarikan solusi lain. Berdasarkan situs simplilearn di atas, ada 5 jenis studi kelayakan yaitu:

1. Kelayakan Teknis
2. Kelayakan Ekonomi
3. Kelayakan Legalitas (aspek hukum)
4. Kelayakan Operasional
5. Kelayakan Penjadwalan

Lebih lanjut tentang kelima hal di atas, bisa dibaca di link simplilearn di atas.

Adapun Visibilitas proyek adalah kejelasan progress atau perkembangan kemajuan dari proyek. Termasuk juga dalam hal ini adalah penggunaan sumber daya (resource allocation) dan risiko-risiko yang potensial. 

Jika kita tidak mudah mencari tahu bagaimana perkembangan proyek sampai dengan saat ini? Siapa sedang mengerjakan apa? Apa hambatan/masalah yang ditemui dalam pengerjaan suatu modul yang sedang berlangsung? Butuh berapa lama waktu untuk menyelesaikan suatu modul atau fitur? Maka ini berarti visibilitas proyek kurang.

Untuk dapat menunjang visibilitas maka aktivitas-aktivitas utama dalam proyek harus bersifat trackable, komunikasi tim juga harus baik. Pemanfaatan tools dan dokumentasi juga sangat berperan untuk menunjang visibilitas. Tools seperti Trello, Atlassian Jira, atau Gitscrum bisa dipakai untuk melacak tugas-tugas yang akan/sedang/telah dikerjakan. Tiap tool biasa menawarkan fitur-fitur tambahan selain pelacakan, tapi jangan sampai terjadi juga, yaitu tata cara atau pendekatan yang kita pakai dalam monitoring & control proyek didikte oleh tools yang dipakai sedangkan kebutuhan yang sesungguhnya ternyata berbeda.

Lemah Empati

Sedang mengantri pesan makanan di Burger King salah satu cabang di Gowa. Nampak isi toko ramai dan antrian di kasir juga berjubel. Beberapa orang kesulitan mendapatkan tempat duduk karena penuh terisi. Yang sedang antri memesan juga was-was seandainya sudah siap santap tapi tidak kebagian tempat duduk. Begitulah risiko kalau tempat sedang ramai dan penuh terisi.

Ada situasi yg tidak wajar saya jumpai, yaitu orang-orang yg telah selesai makan masih duduk lama tanpa peduli bahwa banyak orang lain yg sedang mencari tempat. Mereka merasa bukan masalahnya, toh sudah membayar dan sepenuhnya hak mereka mau duduk berapa lama pun. Tipikal seperti ini berarti empatinya sangat kurang bahkan mungkin tidak ada. Bisa jadi karena tidak pernah dididik untuk memiliki empati ke sesama manusia maupun makhluk.

Kebersihan Toilet dan Kemajuan Suatu Masyarakat

Dikatakan bahwa jika ingin mengetahui kemajuan suatu masyarakat, maka tengoklah bagaimana kondisi toilet umumnya. Jika berbau ataupun kotor maka berarti masyarakat setempat masih ... ya tahu sendiri kelanjutannya kan? XD

Ditolak Masuk SMP Karena Faktor Usia

Berikut cuplikan berita yang saya baca hari ini dengan judul Ditolak Masuk SMP Negeri karena Terlalu "Tua", Remaja Putri Ancam Bunuh Diri (https://regional.kompas.com/read/2019/07/10/22113481/ditolak-masuk-smp-negeri-karena-terlalu-tua-remaja-putri-ancam-bunuh-diri)

Tidak seharusnya hak pendidikan seseorang dibatasi oleh faktor usia, apalagi untuk kasus di atas hanya selisih 1 bulan bahkan mungkin kurang dari batas syarat. Permendikbud nomor 14 tahun 2018 mensyaratkan usia masuk SMP adalah maksimal berusia 15 tahun. Jika tidak memenuhi syarat tersebut maka solusi yang tersedia adalah ambil paket B.

Maksud peraturan tersebut mungkin agar rentang usia tidak terlalu beragam. Tapi pada kasus ini hanya terpaut sedikit sekali, dan  selama sekolah bisa menampung (tidak melebihi kapasitas) maka jangan ditolak.

Kenapa lembaga pendidikan kita yang seharusnya mendidik dan melahirkan insan manusia yang adil, malah dipaksa berlaku tidak adil melalui aturan tersebut. Yang seharusnya mendidik dan melahirkan insan yang mampu menggunakan nurani dan akal sehatnya, justru dipaksa mengingkari nuraninya. Mungkin itulah yang terjadi jika lembaga pendidikan dan orang-orang yang terlibat di dalamnya, tidak lagi paham "ruh" yang sesungguhnya dari pendidikan.

Linux Performance Observability Tools

Picture below is from my friend’s post on facebook.

Top 6 Resources for Mobile Design Inspiration

I forgot where I get this list, but it's from someone's account on instagram.

Top 6 resources for mobile design inspiration:

mobbin.design
Mobbin is a hand-picked collection of The latest mobile design patterns from apps that reflect the best in design. It has over 170 apps and 10,000 patterns.

uisources.com
Mobile UI design pattern videos from the world’s best designed and highest grossing apps. Analyze product features and micro interactions and get new insights.

pttrns.com
Pttrns is the finest collection of design patterns, resources and inspiration. It has designs in more than 30 categories covering a total of 4 device types.

UpLabs.com
Uplabs curates the best of design and development inspiration, resources and freebies. It also conducts regular design challenges once every week.

Behance.net
Behance is a platform to showcase and discover the latest work from top online portfolios by creative professionals across multiple industries.

Dribbble.com
An online community for showcasing user made artwork. It functions as a self promotion and networking platform for web design and other creative areas.

Insidious Problem in Software Industry

Some of insidious problem in software industry, taken from Domain-Driven Design Distilled by Vaughn Vernon:

• Developers trying to throw technology at business problems; chasing “shiny objects”
• Database and data model given priority over business process and operations.
• Developers not placing proper emphasis on naming objects and operations with a business focus.
• Poor collaboration between stakeholders and developers: the “Specifications Divide”.
• Project estimates given too much attention and cause delays in production development.
• “Task-Board Shuffle” and “No Design” lead to developing a _Big Ball of Mud_.
• Developers house business logic in the user interface and persistence code. Leading to slow queries and locking block database results.
• Wrong model abstractions lead to wrong solutions that miss the concrete business needs.

And our team totally agree with these point =)

Pallu Kaloa

Hidangan pallu kaloa di salah satu rumah makan di Jalan Tentara Pelajar, Makassar. Biasanya pallu kaloa memakai kepala ikan, tapi karena saya kurang suka kepala ikan (karena dagingnya kurang), maka saya request minta bagian badan/tengah dan kebetulan masih ada :)

Ukuran potongan dagingnya termasuk besar. Bahkan itu hanya seperempat bagian tengahnya ikan cakalang. Berarti ukuran ikannya memang tergolong buesarr :)  Hanya sepotong daging ikan itu yg dimakan bersama nasi dan bisa kenyang (sekali lagi berarti potongan ikan yg saya santap memang besar)

Terlambat karena koneksi Internet lambat

Ceritanya saya sedang di Jakarta mengurus aplikasi VISA. Pukul 8.45 saya sdh berurusan dengan petugas di counter. Ternyata ada dokumen yang membutuhkan tanda tangan ayah saya. Tentunya di era teknologi informasi sekarang ini, maka saya langsung menelpon ayah saya dan minta untuk menandatangani dokumen lalu kemudian dipindai (scan) lalu dikirim via e-mail ke saya.

Singkat cerita, dalam waktu kurang dari 20 menit e-mail telah dikirimkan. Hmm.. masih ada waktu untuk bisa menyelesaikan urusan ini dengan cepat. Tapiiiii.. oo.. oow.. saya menerima dan memrosesnya (yg mana memrosesnya juga butuh koneksi Internet) lambat oleh karena koneksi Internet yang saya gunakan lambat meski sinyalnya 3G. Ganti ke free wifi yg tersedia di gedung, semoga lebih cepat, tapi.. wah.. malah lebih lambat. Doh..!!  (mulai garuk-garuk kepala)

Akhirnya urusan pun selesai setelah tertunda sekitar hampir 1 jam. Tapi dalam waktu sejam itu, antrian semakin banyak pula sehingga giliran saya dilayani kembali tentu mengalami perlambatan lagi. Karena penundaan tersebut maka terpaksa saya pun ketinggalan travel untuk balik Bandung pukul 10.45. Seharusnya urusan bisa selesai lebih awal dan bisa segera balik Bandung dan melanjutkan aktivitas pekerjaan saya. Dari cerita di atas, faktor apa yang menyebabkan saya tidak bisa selesai lebih awal sehingga mensangkilkan waktu? Tentunya kecepatan Internet. 

Mungkin terkesan sepele, tapi sesungguhnya banyak sekali kegiatan bisnis/urusan penting yang mengandalkan kehandalan dan kecepatan Internet. Jadi ingat pertanyaan seorang pejabat tinggi di Kementerian Komunikasi dan Informatika yaitu "kalau Internetnya kenceng trus mau ngapain?" *tepok jidat* 

Nikmatnya mengurus segala sesuatu dengan dilandasi kejujuran

Jika tiba masa dimana ada suatu persoalan yang harus diurus/diselesaikan tapi kita tidak percaya diri menampilkan diri kita apa adanya, maka pasti kita menjalankan skenario "berpura-pura".

Contohnya, ada saudara/kerabat yang harus mendapat penanganan di rumah sakit dan biayanya tidak kecil, maka seringkali anggota keluarga atau kerabat yg pembuat keputusan memberikan alasan ke rumah sakit untuk berpikir-pikir dulu, atau beralasan masih menunggu persetujuan dari anggota keluarga lainnya. Masalahnya, alasan diberikan dengan kesan seolah bukan biaya yg menjadi pertimbangan, tapi benar-benar persetujuan soal mau tidaknya, rela tidaknya, mendapat tindakan. Akhirnya penundaan pun terjadi, padahal kondisi pasien bisa jadi bertambah buruk, dan upaya penyelamatan menjadi semakin menipis.

Demikian juga hal ini bisa diterapkan di urusan lain, misalnya urusan pengajuan permohonan ke bank. Biasanya kalau mengajukan permohonan ke bank, kita tidak percaya diri jika nilai tabungan kita tidak besar. Akhirnya ketika diminta pengisian data oleh pihak bank, kita lalu memberikan data ygfiktif. Padahal ada baiknya kita "berkonsultasi" dulu dengan pihak bank (biasanya customer service ataupun bagian khusus yg menangani pengajuan) tentang apa yang kita inginkan, kondisi riil kita saat ini, dan bagaimana keinginan tersebut diupayakan. Seringkali pihak bank malah membantu kita supaya pengisian data bisa "diakali" secara bersama-sama. Terlepas dari masalah kejujuran, seringkali urusan bank itu adalah persoalan berurusan dengan sistem, dan sistem melakukan penilaian berdasarkan input yang diterima. Jadi jika inputnya "diakali" supaya "bagus/baik" maka ada harapan besar outputnya pun sesuai harapan. Tentunya usulan yang saya tuliskan di atas ini, tidak bisa dirampatkan (disama-ratakan) ke semua hal ya, termasuk segala jenis urusan bank, tapi setidaknya bisa dijadikan acuan awal saat berupaya.

Code Smell: Bad Smell

Dalam pemrograman, dikatakan Bad Smell jika secara heuristik dicurigai ada masalah dengan suatu kode meski kode tsb belum terbukti menimbulkan masalah. Memanfaatkan CodeDeodorant bisa menghilangkan "smell" tsb, namun tidak menghilangkan penyebabnya. 

Menulis kode yang baik, termasuk menghindari code smells, seringkali bukan hal yang mudah. Terutama jika kita harus menuliskan suatu kode-kode baru sembari dikejar oleh waktu. Terlebih bila kode tersebut bukan untuk persoalan yang trivial bagi kita. Bagi saya, jika terpaksa menimbulkan "bau" maka segera pula dipakaikan "deodoran", alias CodeDeodorant. Deodoran ini seringnya berupa komentar dengan huruf kapital atau simbol-simbol yang menarik perhatian, atau memberi jarak vertikal dengan spasi (vertical whitespace)

Ulasan beserta contoh Code Smell, silahkan kunjungi http://c2.com/xp/CodeSmell.html

Moment

Midnight Coding

Doing some midnight coding...

Kata yang paling banyak dikenal di seluruh dunia: OK

Ada fakta yang cukup menarik. Menurut kamus Miriam Webster (http://www.merriam-webster.com/dictionary/), kata yang paling banyak dikenal oleh manusia di seluruh dunia adalah Okay/OK.

Tahukah Anda bahwa OK adalah singkatan dari All Correct (dengan bunyi Oll Korrect). Lebih lanjut silahkan telusuri artikel/video di Miriam Webster Dictionary.

Selamat Tanpa Makanan Selama 2 Bulan di dalam Mobil Terkubur Salju

Jika Tuhan memang belum menghendaki ajal seseorang, maka selalu saja ada tata-cara alam yang bekerja sehingga seseorang tersebut selamat meskipun berada dalam kondisi yang "seharusnya" sudah menjemput ajalnya.

Kali ini seorang lelaki Swedia berumur 45 tahun, ditemukan selamat setelah terkubur bersama mobilnya, di dalam salju, selama 2 bulan tanpa makanan apapun. Secara ilmiah disebutkan bahwa dikarenakan suhu yg rendah, maka tubuh lelaki ini berhibernasi seperti yang biasanya dilakukan beruang di musim dingin.

 Untuk artikel selengkapnya, silahkan kunjungi http://gizmodo.com/5886507/how-a-man-survived-without-food-for-two-months-in-a-snow+buried-car