J.a.i.m’s Diary

Ada kasus yang cukup menggelitik yang pernah saya temui dalam proses pengembangan aplikasi Invoicing: perusahaan memiliki cukup banyak pelanggan/customer dan dalam menerbitkan dokumen invoice, perusahaan menerapkan bentuk format penomoran dokumen invoice yang berbeda-beda untuk tiap-tiap pelanggan yang ada. Kasus ini aslinya sebenarnya terselesaikan dengan trik yang saya buat dengan menggunakan bahasa pemrograman delphi, namun kali ini saya akan mencoba mengupasnya dengan memanfaatkan python. :)

Studi Kasus

Adalah satu hal yang lumrah dalam penerbitan dokumen invoice perusahaan menerapkan kodifikasi penomoran untuk setiap dokumen invoice yang diterbitkan, sebagai contoh: 30912/INV/EXP/III/2010. Hal ini dilakukan untuk mempermudah manajemen dan pengaturan atas dokumen yang dibuat. Permasalahannya adalah bagaimana jika kodifikasi tersebut bersifat dinamis, dalam artian bergantung pada pelanggan-nya, dalam arti misalnya: untuk pelangan PT. DAUN BUAH menggunakan format dokumen 30912/EXP/MAR/2010, sementara untuk PT. SEGARA PERKASA berformat 30912/EXP/03/2010, dan untuk PT. ABADI NUSA menggunakan format 30912/EXP/INV/2010. Hal ini tentunya akan menjadi kasus yang cukup menggelitik untuk dipecahkan.
(more…)

Tertarik dengan cuplikan kode yang ditulis pak budi, saya mencoba membuat implementasi serupa dengan menggunakan python, sebelumnya sebenarnya Waskita Adijarto telah mencoba memportingnya ke dalam bahasa C, dan sepertinya masih cukup panjang, kendati kode yang ditulisnya relatif lebih mudah dibaca. Mari kita jajal, apakah menurut anda python lebih ringkas dengan tetap mempertahankan aspek readability? :)

#! /usr/bin/python
m = n = 4
printout = lambda x, y: ' %d ' % y if x else ''

for i in range(m*n):
  y = i / 4
  x = i % 4
  print "%d:" % i,
  print printout(y != 0, (y-1) * m + x),
  print printout((x!=(m-1)), y * m + (x + 1)),
  print printout((y!=(n-1)),(y+1) * m + x),
  print printout((x != 0),y * m + (x - 1))

Hari ini saya mencoba revisit ulang driver DBExpress wrapper untuk python yang kompatibel dengan DB-API, driver ini sebenarnya telah saya buat sebelumnya, namun sepertinya saat itu karena masih banyak instability issue atas project middleware server yang saya kerja, saya coba lepasin untuk meminimalisir permasalahan yang mungkin disebabkan karena driver ini.

Namun setelah host midleware server-nya mencapai tahapan maturity yang cukup baik, sepertinya ini saat yang cukup tepat untuk melakukan revisit, dan sepertinya bisa dikatakan tulis ulang karena kode yang saya buat sebelumnya banyak yang keliru dalam pemanfaatan Python API functionya. Meskipun belum sempat saya test lebih lanjut, kode dasar ini saya postingkan di sini sebagai alternatif pengarsipan.
(more…)

Berita pagi ini juga cukup menarik, kabar terbaru yang saya dapatkan Jython merilis versi alpha atas python language yang kompatible dengan CPython 2.5. Meski masih dalam taraf alpha, namun rilis ini menarik untuk dieksplorasi sejauh mana kompatibilitas bahasa yang ditawarkan Jython yang tentunya pula akan berdampak pada besar kecilnya probabilitas Jython untuk dapat diintegrasikan dengan library-library yang menggunakan CPython sebagai basis seperti SQLAlchemy, dll.

Seberapa begitu menarikkah Jython ini dibanding CPython? Perlu diketahui, CPython saat ini memiliki kelemahan jika digunakan dalam mesin-mesin berbasis multi-core karena keberadaan GIL membuatnya secara internal hanya satu thread yang aktif dieksekusi (meski sebenarnya ada beberapa thread yang berjalan bersamaan), akibatnya tentu saja hanya 1 CPU yang bisa termanfaatkan. Sebenarnya hal ini bisa sedikit banyak diminimalisir dengan memporting kode-kode yang bersifat kritikal ke dalam extenstion module yang dibuat dengan native language, namun besar kecilnya manfaat sangat bergantung pada bagaimana model kerja kode dalam python yang dieksekusi, begitu juga dengan membuat process instance, dan beberapa solusi lainnya. Saya tidak ingin panjang lebar membahas lebih jauh tentang ini, Guido punya alasan yang kuat dan benar yang mendasari kenapa GIL tetap harus dipertahankan setidaknya di Python300 nanti.

(more…)

DB2-Express C merupakan RDBMS versi gratis yang ditawarkan oleh IBM sebenarnya sangat menarik untuk menjadi kandidat pilihan karena RDBMS ini tidak membatasi kapasitas penyimpanan (storage) seperti halnya Oracle-Express, atau SQLServer Express Edition, mendukung pemanfaatan multi-core processor hingga 2 core, dan mendukung pemanfaatan memory hingga 2 Gb membuat database ini lebih dari cukup untuk digunakan di level produksi perusahaan skala medium enterprise.

Sudah cukup lama sebenarnya saya mengevaluasi RDBMS ini, tertarik dengan fitur-fitur yang ditawarkannya sebagai high-end database system untuk dijadikan alternatif pilihan RDBMS yang disupport dalam platform yang saya kembangkan. Permasalahannya tinggal satu sebenarnya, namun justru itulah yang paling menyebalkan, python wrapper untuk akses database secara remote masih terbilang immature, sangat buggy. Hanya dalam hitungan menit setelah application server utama dijalankan, ia membuat crash system secara keseluruhan, karena memory corrupt yang menyebabkan python garbage collection tidak bisa menjalankan fungsinya secara normal.

(more…)