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 =)