0 Mengintip Cara Perhitungan Klasemen pada PSB Solok 2009 Posted on : 6/25/2009 04:36:00 PM

Penerimaan Siswa Baru (PSB) Solok 2009 sudah dimulai sejak beberapa hari yang lalu. Antusiasme positif dari siswa sangat tinggi terhadap sistem online yang ditawarkan oleh Dinas Pendidikan Kota Solok tahun ini dengan memberikan fasilitas pendaftaran siswa baru melalui beragam media interaktif seperti web (http://psb.solokcerdas.com) dan SMS Server dengan mengirimkan sms menggunakan format tertentu ke nomor 0811665540.

Banyak feedback yang diterima oleh Dinas Pendidikan Kota Solok mengenai sistem PSB Online ini, terutama pertanyaan mengenai bagaimana sesungguhnya cara perhitungan klasemen pada PSB Solok 2009. Hal ini sebenarnya telah dijelaskan secara detail oleh Team ICT Dinas Pendidikan Kota Solok pada roadshow sosialisasi PSB Online 2009 yang telah dilakukan di semua sekolah di Kota Solok sejak bulan lalu. Namun ada baiknya jika kami jelaskan ulang melalui website ini.

Perhitungan dan penentuan peringkat dalam klasemen untuk setiap sekolah secara mendasar mengacu pada :

1. Jumlah kuota yang disediakan masing-masing sekolah, meliputi:
• kuota dalam rayon
• kuota luar rayon (untuk siswa yang berasal dari sekolah luar rayon dan dari luar kota)
  
2. Batas minimal Nilai UN yang ditetapkan oleh masing-masing sekolah
   

Adapun mekanisme pengurutan (sorting) untuk menentukan posisi siswa dalam tabel klasemen per masing-masing sekolah adalah berdasarkan :

1. Nilai UN Total
2. Nilai Bhs Indonesia
3. Nilai Matematika
4. Nilai IPA
5. Nilai Bahasa Inggris
6. Tanggal & Jam Melakukan Pendaftaran

Jika seorang siswa memiliki nilai UN total yang sama besar dengan siswa lain, maka sebagai komparasi akan dibandingkan lagi nilai UN per mata pelajaran dengan urutan nilai Bahasa Indonesia dilakukan perbandingan terlebih dahulu, baru setelah itu Matematika, dan seterusnya. Jika nilai-nilai mata pelajaran antara siswa tersebut masih sama -- yang mana hal ini kecil kemungkinannya untuk terjadi -- pengurutan untuk memperoleh peringkat yang lebih tinggi antara kedua siswa tersebut akan dilakukan berdasarkan tanggal dan jam siswa tersebut melakukan pendaftaran ke sekolah tersebut.

Peringkat dalam klasemen ini akan terus bergeser mengikuti dinamika jumlah siswa pendaftar yang telah terverifikasi oleh Panitia PSB sampai batas waktu terakhir klasemen memasuki tanggal penutupan.

Untuk siswa-siswa yang sudah berada di luar kuota dari tabel klasemen di masing-masing sekolah, disarankan untuk segera mengganti pilihan sekolahnya ke sekolah lain. Penggantian sekolah pilihan ini hanya bisa dilakukan untuk siswa yang sudah melaporkan nilai DANUN-nya ke Panitia PSB di posko-posko PSB yang tersebar di semua sekolah peserta PSB Online ini.

Untuk siswa-siswa yang saat ini sudah berada di "zona degradasi" alias di papan bawah klasemen masing-masing sekolah, juga amat disarankan untuk mengganti pilihan sekolahnya, dengan harapan kemungkinan di tabel klasemen sekolah lain siswa tersebut masih memiliki posisi aman untuk menempati papan atas atau papan tengah klasemen.

PSB Solok 2009 ini diselenggarakan dalam 2 gelombang klasemen, yaitu :

• Gelombang 1, dilaksanakan pada tanggal 22 Juni 2009 hingga 30 Juni 2009
• Gelombang 2, dilaksanakan pada tanggal 8 Juli 2009 hingga 9 Juli 2009

Mekanisme perhitungan dan pengurutan pada kedua gelombang klasemen itu adalah sama dan mengikuti pola perhitungan yang sama seperti yang telah dijelaskan di atas. Sedangkan ketika Klasemen Gelombang 2 berakhir, proses penerimaan siswa baru bagi siswa-siswa yang masih berada di luar kuota akan dilakukan oleh Dinas Pendidikan Kota Solok bekerjasama dengan seluruh sekolah peserta PSB di Kota Solok melalui proses Bursa Calon Siswa.

Demikian penjelasan dari Team ICT Diknas Kota Solok mengenai 'dapur' sistem PSB Online 2009 ini, semoga dapat dipahami oleh segenap siswa di Kota Solok yang tengah berjuang meraih mimpi dan harapan di calon sekolah baru. Kami ucapkan selamat melaksanakan PSB Online 2009 ini, semoga sukses!


_______________________


Rizky Prihanto
Software Architect PT Cinox Media Insani

5 Mendistribusikan MyODBC dalam Installer Aplikasi Posted on : 6/17/2009 06:52:00 PM

Ada yang nanya di milis mysql-indonesia@googlegroups.com tentang bagaimana caranya nginstall MyODBC secara otomatis dalam mendistribusikan aplikasi kita. Kadang, ketika kita memaketkan produk software kita (platform desktop, windows) -- kita ngga bisa menjamin apakah di komputer client sudah terinstall MyODBC yang diperlukan supaya aplikasi kita bisa connect ke database MySQL (tentunya bagi yang mempergunakan ODBC sebagai bridge koneksi. Kalo yang makae native API seperti vbmysqldirect, MyDAC, dbExpress, atau MySQL Connector yang lain -- ya ngga perlu MyODBC).

Gw jadi ingat jaman-jaman kelam dulu, pas masih develop pakae VB6, ribet bangedd rasanya 'menginstallkan' pre-requisites aplikasi kita ke client macam OCX, DLL, flash player plugins, dan tentu saja.. MyODBC. Tapi sejak gw mulai bosan ama keribetan itu -- gw akhirnya riset mengenai teknik-teknik membuat instalasi yang membuat gw sempet terjerembab 'sedikit alih profesi' jadi Deployment Engineer di tim gw dulu. Tentu saja gw musti memastikan bahwa aplikasi gw ketika di-distribusikan ngga bakal gagal di-execute selain di kompie gw sendiri, termasuk diantaranya menjalin koneksi dengan MySQL melalui MyODBC.

Di artikel kali ini gw mencoba mengupas mengenai teknik-teknik 'memaksakan' client menginstall secara otomatis MyODBC supaya program kita bisa running well.

caranya (gw asumsikan kita akan redistribute-kan MyODBC 5.1) :

1. di installer loe, u copy-kan file2 berikut ke %SYSDIR% (terserah sih mo dimana sebenarnya):
    a) libmysql.dll
    b) myodbc5.dll
    c) myodbc5.lib
    d) myodbc5S.dll
    e) myodbc5S.lib

2. Lakukan install driver manual dengan nge-add registry berikut ini :
  classkey = HKEY_LOCAL_MACHINE
  sectionkey = "SOFTWARE\ODBC\ODBCINST.INI\MySQL ODBC 5.1 Driver"
    trus bikin beberapa key yaitu :
  a) nama key = "Driver"
     tipe = REG_SZ
     value = "C:\WINDOWS\System32\myodbc5.dll" --> sesuaikan ini dgn tempat di mana u nge-extract (step 1)
  b) nama key = "Setup"
     tipe = REG_SZ
     value = "C:\WINDOWS\System32\myodbc5S.dll"
  c) nama key = "UsageCount"
     tipe = REG_DWORD
     value = 1

3. Langkah terakhir, lakukan register driver ke ODBC driver, juga dgn maen-maen registry berikut :
    classkey = HKEY_LOCAL_MACHINE
    sectionkey = "SOFTWARE\ODBC\ODBCINST.INI\ODBC Driver"
    bikin key :
    nama = "MySQL ODBC 5.1 Driver"
    tipe = REG_SZ
    value = "installed"

udah. itu cara bikin installer sendiri utk MyODBC 5.1
kalo utk versi MyODBC 3.51, silakan sesuaikan sendiri (tapi buat apa makae 3.51 hare gene?)

bisa loe adopsi di :

1. jalankan ntu script di setiap app.initialization (tentu cek dulu, execute cuman kalo if not exists)
   
2. atau embedd ke dalam script installer loe (semua installer pastinya bisa nge-manipulate registry kan?)
3. atau bikin program exe sendiri yang akan menjalankan "silent-install" ntu proses, trus masukin ke script installer loe n loe program supaya ntar installer akan jalanin otomatis ntu myodbc-silent-installer setelah proses nginstall aplikasi loe selesai.
   

mau cara gampang?
Bikin installer-nya pakae NSIS (Nullsoft Scriptable Install System). Berhubung output installer dia bukan berbasis *.msi, loe bisa lakukan proses instalasi paralel (installer dalam installer) dengan file-file setup laen (pre-requisites software) yg mungkin elo butuhkan dalam redistribute aplikasi loe (misal : driver, connector, plugins, codec, bahkan automatic-install server mysql sendiri!).

Cara :
1. siapkan installer MySQL ODBC 5.1 terbaru (anggap namanya : mysql-connector-odbc-5.1.5-win32.msi)
2. sisipkan di script NSIS loe begini :
  SetOutPath "$TEMP"
  SetOverwrite On
  File "..\resources\mysql-connector-odbc-5.1.5-win32.msi"
  ExecWait 'msiexec /i "$TEMP\mysql-connector-odbc-5.1.5-win32.msi"' $0
3. compile script installer loe untuk menghasilkan 1 file installer (aplikasi loe + prerequisites-nya)

Penjelasan Script NSIS:

baris pertama, itu akan melakukan change-dir ke direktori tujuan ekstrak sebuah file (dalam hal ini TEMP DIR)
baris kedua, itu akan melakukan flagging kalo file yg akan di-ekstrak udah ada, dia akan di-overwrite
baris ketiga, itu meng-copy-kan dari installer berupa file setup mysql-connector-odbc-5.1.5-win32.msi ke TEMP DIR. parameter dari File itu adalah alamat dari paket instalan mysql-connector-odbc-5.1.5-win32.msi ketika installer sedang dibentuk
baris keempat, itu akan melakukan eksekusi file installer mysql-connector-odbc-5.1.5-win32.msi -- efeknya, ntar user pas nginstall aplikasi loe, dia akan "dipaksa" masuk ke installer MyODBC. ExecWait adalah sebuah mekanisme shell-execute yang akan menunggu proses sampai proses instalasi MyODBC selesai dijalanin user, baru kemudian lanjut ke proses install sisanya.

kelebihan dari cara gampang ini?

• loe gag perlu pusing2 ria maen2 registry (seperti cara "manual" gw di atas -- walo ada kelebihannya juga cara manual ini : loe jadi ngerti struktur registrasi ODBC Driver di sistem operasi loe. Jadi klo mo pakae connector apapun utk connect ke DBMS apapun: mudah!)
  
• loe bisa replace source install-an mysql odbc versi berapapun dgn mudah
• file installer yang kelak akan di-distribusikan ke user cuman 1 doank. udah all in one.

Kira-kira begitu...
Happy exploring...
_______________________


Rizky Prihanto
Software Architect PT Cinox Media Insani

3 Konsep Sistem Terintegrasi Posted on : 5/22/2009 10:43:00 AM

Dalam konteks sistem informasi, sistem terintegrasi (integrated system) merupakan sebuah rangkaian proses untuk menghubungkan beberapa sistem-sistem komputerisasi dan software aplikasi baik secara fisik maupun secara fungsional. Sistem terintegrasi akan menggabungkan komponen sub-sub sistem ke dalam satu sistem dan menjamin fungsi-fungsi dari sub sistem tersebut sebagai satu kesatuan sistem.

Sistem terintegrasi merupakan tantangan menarik dalam software development karena pengembangannya harus terus mengacu pada konsistensi sistem, agar sub-sub sistem yang sudah ada dan tetap dimanfaatkan secara operasional masih tetap berfungsi sebagaimana mestinya baik ketika proses mengintegrasikan sistem maupun setelah terintegrasi. Tantangannya adalah bagaimana merancang sebuah mekanisme mengintegrasikan sistem-sistem tersebut dengan effort paling minimal – bahkan jika diperlukan, tidak harus melakukan refactoring atau re-developing lagi sistem-sistem yang sudah ada.

Ada beberapa metode yang dapat dipergunakan dalam membangun sistem terintegrasi, sebagaimana yang direferensikan berdasarkan artikel dari Wikipedia yaitu :

• Vertical Integration, merupakan proses mengintegrasikan sub-sub sistem berdasarkan fungsionalitas dengan menghubungkan sub-sub sistem yang sudah ada tersebut supaya bisa berinteraksi dengan sistem terpusat dengan tetap berpijak pada arsitektur sub sistem yang lama. Metode ini memiliki keuntungan yaitu dapat dilakukan dengan cepat dan hanya melibatkan beberapa entitas development yang terkait dalam proses pembuatan sistem lama. Kelemahannya, metode ini tidak memungkinkan untuk mengimplementasikan fungsi-fungsi baru atau proses bisnis baru ke dalam sub-sistem yang sudah ada – karena effort lebih tinggi ada di proses “mempelajari” arsitektur sistem lama dan menjadikannya acuan untuk membuat sistem terintegrasi. Untuk menghadirkan ekspansi fungsionalitas atau proses bisnis baru adalah harus membuat sub-sistem baru.
• Star Integration, atau lebih dikenal sebagai spaghetti integration, adalah proses mengintegrasikan sistem dengan cara menghubungkan satu sub sistem ke semua sub-sub sistem lainnya. Sebuah fungsi bisnis yang diimplementasikan dalam sebuah sub sistem akan di-broadcast ke semua sub-sub sistem lain yang dependen terhadap fungsi bisnis tersebut supaya dapat dipergunakan sebagaimana mestinya. Untuk integrasi sistem dengan ruang lingkup kecil atau menengah dan dengan pemisahan fungsi bisnis yang jelas dan spesifik, metode integrasi ini layak untuk dipertimbangkan. Namun jika fungsi bisnis banyak terlibat di beberapa sub sistem secara dependen, pada akhir proses integrasi sistem akan terlihat sedikit “kekacauan” dalam diagram – proses interkoneksi antar sub sistem akan tampak seperti spaghetti. Efeknya, biaya perawatan dan ekspansi sistem di masa yang akan datang akan memerlukan effort yang sangat berat untuk mempelajari skema integrasi sistem berikut dependency-nya.
• Horizontal Integration, atau ada yang mengistilahkan dengan Enterprise Service Bus (ESB), merupakan sebuah metode yang mengintegrasikan sistem dengan cara membuat suatu layer khusus yang berfungsi sebagai interpreter, dimana semua sub-sub sistem yang sudah ada akan berkomunikasi ke layer tersebut. Model ini lebih menawarkan fleksibilitas dan menghemat biaya integrasi, karena yang perlu difokuskan dalam implementasi proses pengintegrasian hanya layer interpreter tersebut.  Untuk menangani ekspansi proses bisnis juga hanya perlu diimplementasikan di layer interpreter itu juga, dan sub sistem baru yang akan menangani interface dari proses bisnis ekstensi tersebut akan berkomunikasi langsung ke layer dan layer akan menyediakan keperluan-keperluan data/interface untuk sub sistem lain yang memerlukannya.

Metode Enterprise Service Bus (ESB) ini – seperti yang dilansir dari Wikipedia juga – memiliki banyak kelebihan jika diadopsi dalam merancang arsitektur sistem terintegrasi, yaitu antara lain :

1. Lebih cepat dalam melakukan penyesuaian dengan sistem yang telah ada
2. Meningkatkan fleksibilitas, mudah untuk diperbaharui mengikuti perubahan keperluan sistem (system requirements)
3. Membuat standar sistem sehingga bisa diaplikasikan di sub sistem mana pun
4. Porsi pekerjaan software development lebih banyak di “konfigurasi” daripada “menulis code” untuk integrasi
5. Dapat diterapkan mulai ruang lingkup kecil hingga di level enterprise

Namun metode horizontal integration atau Enterprise System Bus (ESB) yang tampaknya ideal ini bukan berarti tidak ada kelemahan. Beberapa kelemahan yang cukup signifikan pengaruhnya antara lain :

1. Pembuatan standar sistem dalam Enterprise Message Model banyak berkutat di aspek analisis dan manajerial, biaya analisis benar-benar tinggi karena perlu berkolaborasi dengan analis-analis yang bertanggung jawab terhadap arsitektur dan desain sistem-sistem yang telah ada.
2. Secara khusus memerlukan perangkat keras (hardware) yang spesifik, seperti misalnya business-logic-server yang independen dan tidak integral dengan salah satu atau sebagian dari sub sistem yang telah ada.
3. Perlu tambahan tenaga (SDM) berupa Middleware Analyst yang akan mengkonfigurasi, merawat, dan mengoperasikan layer Enterprise Service Bus.
4. Karena biasanya ESB mempergunakan XML sebagai bahasa komunikasi antar sistem, tentu akan memerlukan resources dan komputasi berlebih untuk melakukan parsing-reparsing dalam komunikasi data.
5. Memerlukan effort yang cukup tinggi dalam mengimplementasikan ESB karena cukup banyak layer/tingkatan aplikasi yang harus ditangani, tidak hanya aplikasi-aplikasi interface dari sub-sub sistem saja, melainkan juga layer interpreter yang juga memiliki karakteristik sebagai aplikasi juga.

Pada akhir kisah, merancang dan membuat sebuah sistem terintegrasi -- memang bukan merupakan pekerjaan yang ringan. Apalagi kalau sejak awal pengembangan sistem-sistem terpisah yg sudah ada itu tidak dirancang untuk saling diintegrasikan satu sama lain. 

Tapi itulah hidup..., kita tidak bisa tau (sistem kita) besok bakal jadi bagaimana -- terus berkembang, atau berakhir di rak-rak penyimpanan CD usang di ruang arsip yang berdebu.

_______________________


Rizky Prihanto
Software Architect PT Cinox Media Insani

0 Dampak Evaluasi Implementasi dalam SDLC Posted on : 5/01/2009 06:11:00 PM

Di facebook gw, ada message di inbox yg berasal dari salah satu friend gw. Isinya *dia nanya* begini :

Maaf baru aja add tp dah repoti

need help u makalah gw, sebenernya sumber kesalahan suaru software tu dari mananya? apakah selalu desainnya, atau mungkin ga implementasinya? need referensi yang sahih buat dasarnya

thx 4 ur att.

Gw bukan mo mengomentari "kenapa beliau ngga nanya via imel aja? tp kenapa lewat FB yg mana fungsi utamanya bukan untuk imel-imel-an, melainkan untuk narcis-narcis-an.." ~ bukan. Gw mo nyoba jawab pertanyaan dia, coz sebenarnya gw juga sering (SERING-BANGEDD) mengalami masalah berupa kesalahan di software yg tim gw bikin, itu sebenarnya karena kita kurang evaluasi di faktor mana-nya?

Kira-kira begini hasil pemikiran gw :

Kalo dirunut-runut, ada beberapa tahap dasar dari sebuah siklus pengembangan sistem (SDLC), yaitu :

1. Perencanaan
2. Analisis
3. Desain
4. Konstruksi
5. Implementasi
6. Maintenance/support

Produk sistem yang dihasilkan itu sendiri, akan dinikmati oleh user di dalam fase IMPLEMENTASI (beda artinya dengan KONSTRUKSI -- walau banyak miskonsepsi mengenai ini dalam materi-materi Rekayasa Perangkat Lunak, bahwa proses "coding" itu adalah proses "implementasi". Bukan! Itu konstruksi.).

Nah, masalahnya -- seperti case yang coba dibedah temen gw tsb, kalo ada kesalahan dalam suatu produk software -- itu yang salah ada di fase mana?

Hmm... jawabannya : semua fase dalam SDLC selalu menimbulkan potensi munculnya sebuah kesalahan.

Yaa, kita ngga perlu membahas kalo programmer juga manusia, punya rasa punya hati, juga punya khilaf ^_^ ~ itu manusiawi. Tapi mari sekali-sekali kita simak bagaimana sebenarnya SDLC itu sendiri. Silakan perhatikan gambar di bawah ini : 

Dari gambar di atas, dapat dideduksikan bahwa sebuah "perulangan" fase terjadi jika : 

• kesalahan program (error/bug)
• ketidakcocokan solusi sistem (software) dengan teknologi baru
• terdapat masalah-masalah dan keperluan bisnis yang baru
• solusi sistem (software) sudah tidak layak lagi

Untuk proses terjadinya "revisi" karena kesalahan program, step dalam SDLC yang harus di-ulangi adalah di fase KONSTRUKSI. Artinya, perbaiki code atau mungkin coding ulang.

Sedangkan kalo ketidak-cocokan solusi dengan teknologi baru -- misalnya, ekspansi pembayaran cash menjadi pembayaran debit/kartu kredit atau karena upgrading DBMS atau karena pengen dirombak ke platform teknologi terbaru (contohnya, yg tadinya di-coding-in under DOS menjadi di-coding-in under Windows, atau dibikin dari VB6 pengen diganti jadi .NET) -- fase DESAIN harus diulangi dan implikasinya, fase KONSTRUKSI juga harus diulangi.

Kalo terdapat masalah-masalah dan proses bisnis baru? Misalnya: ternyata sistem yg udah terimplementasi dengan baik ini diharuskan TERINTEGRASI dengan sistem di atasnya yg lebih besar; atau terdapat penambahan beberapa requirement baru yang belum terfasilitasi di sistem existing. Kalo itu yang terjadi, proses SDLC mau-ngga-mau harus diulangi dari fase ANALISIS, trus DESAIN lagi, trus CODING lagi deh...

Dan yang paling parah, yg ini nih : ternyata setelah IMPLEMENTASI sekian tahun lamanya, solusi sistem yang terimplementasi di aplikasi existing ini udah bener-bener usang dan ngga layak pakai. Mau tetap dipertahankan untuk dioperasikan, salah. Kalo itu yang terjadi, PERENCANAAN ULANG! ~ tapi, diambil sisi positifnya aja. Perencanaan ulang dan mengulang segalanya dari awal lagi, kan artinya PROJECT BARU. hehehe... loemayan laah daripada loe manyun. ^_^

Sebagaimana lagu PeterPan, memang benar bahwa TAK ADA YANG ABADI. Bahkan sistem dan aplikasi. Tahun 2000 lalu, seiring dengan launching-nya Windows Millennium, Bill Gates mengatakan : DOS udah mati. Sah-sah saja. Ngga ada yang benar-benar perlu disesali.

Kalo dapat komplain dari end-user atau stakeholder pemesan sistem yang kita bangun, syukurilah... Itu artinya kita tetap menjaga relasi dengan dia dan menjaga perputaran siklus development kita tetap berjalan. Stakeholder yang bijaksana, tentunya mengerti sedalam-dalamnya bahwa setiap terjadi perubahan sistem PASCA-IMPLEMENTASI akibat ini-itu, pasti ada biayanya. Dan pada kenyataannya pun, kita sebagai system-developer juga sering mbikin proposal bukan cuman judulnya "proposal pembuatan sistem" atau "proposal pengembangan sistem" -- tapi juga "proposal pemutakhiran sistem". Waaa, sering bangedd nie muncul di Media Indonesia tender-tender di instansi pemerintah yang bertemakan PEMUTAKHIRAN. Artinya : update sistem lama, entah starting point-nya dari re-code, re-design, re-analysis, atau ... REVOLUSI!

_______________________


Rizky Prihanto
Software Architect PT Cinox Media Insani

9 xp_autokode Posted on : 4/30/2009 03:31:00 PM

Barusan baca-baca blog-nya dendie tentang Stored Procedure. Ada yg comment, nanya, pengen nge-convert stored-procedure yg dia bikin dari SQL Server ke SP di MySQL. Dia co-pas-kan script SP di SQL Server-nya sebagai berikut :

============================================
CREATE PROCEDURE [dbo].[AutoNumber]
@NoMember varchar(10) OUTPUT
AS
DECLARE @NoTertinggi numeric,
@Indek int
Select @NoTertinggi=MAX(CAST(RIGHT([No Member],8)As Numeric))
From Member
Set @NoMember = 'NM'
If @NoTertinggi is null
set @NoTertinggi = 0
set @NoTertinggi = @NoTertinggi + 1
set @Indek = LEN(@NoTertinggi)
ulang:
if @Indek <> 8
begin
set @NoMember = @NoMember + '0'
set @Indek = @Indek + 1
goto ulang
end
set @NoMember = @NoMember + cast(@NoTertinggi as varchar)

GO
==============================

Setelah gw tracing singkat, ntu SP tujuannya adalah untuk nge-generate auto-number otomatis dari sebuah tabel. Hmm..., gw jadi sedikit tergelitik untuk nge-share xp_autokode buatan-ku di masa-lalu nih utk nanganin kasus serupa. Begini script-nya :

/* Procedure "xp_autokode_out" DDL */

delimiter $$
create procedure `xp_autokode_out`(
  depan varchar(20),
  digit tinyint,
  tabel varchar(255),
  kolom varchar(255),
  out newvalue varchar(255)
)
begin
 if digit > 0 then
  if length(trim(depan)) = 0 then
   set @sql = concat(' select concat("',trim(depan),'",lpad(ifnull(cast(max(substr(',kolom,',length("',trim(depan),'")+1,', digit,')) as signed),0)+1,',digit,',0)) as newkode into @value from ',tabel,' where left(',kolom,',length(',kolom,')-',digit,') = "',trim(depan),'" AND (',kolom,'+0)/',kolom,' = 1');
  else
   set @sql = concat(' select concat("',trim(depan),'",lpad(ifnull(cast(max(substr(',kolom,',length("',trim(depan),'")+1,', digit,')) as signed),0)+1,',digit,',0)) as newkode into @value from ',tabel,' where left(',kolom,',length(',kolom,')-',digit,') = "',trim(depan),'"');
  end if;
  prepare query from @sql;
  execute query;
  set newvalue = @value;
 else
  select 'Digit tidak boleh lebih kecil dari 1 !!!' as pesan;
 end if;
end $$
delimiter ;


ntu xp ~ extended stored procedure -- gw menamakan xp-xp generic gw begitu ~ adalah routine yg bisa meng-generate autonumber untuk *sembarang tabel* dengan primary key berupa varchar atau char.  Dan bisa dalam formatting tertentu, pula.

Misalnya :
mo bikin nomor nota B-00001 dari sebuah tabel penjualan dengan kolom primary key namanya "kode", loe tinggal rumusin dulu format2 autonumber yg mo di-generate sbb :

Prefix : "B-"
Jumlah Digit : 5 ~> 00001 terdiri 5 digit angka, bukan?
Nama Tabel : penjualan
Nama Kolom : kode

Cara pemanggilan SP :

mysql > call xp_autokode_out("B-",5,"penjualan","kode",@new_kode);
mysql> select @new_kode as `kode_baru`;
+-----------+
| kode_baru |
+-----------+
| B-00001   |
+-----------+


cobain ndiri deh...

Dan loe bisa ekspansikan penggunaan xp ini di dalam stored procedure loe. Misalnya, sp untuk simpan nota, seperti ini contohnya :

delimiter $$
create procedure `sp_penjualan_simpan`(
  v_kode_barang varchar(20),
  v_jumlah int,
  v_harga double
)
begin
 declare new_kuitansi varchar(20);
 call xp_autokode_out("B-",5,"penjualan","kode",new_kuitansi);
 insert into penjualan values (new_kuitansi, v_kode_barang, v_jumlah, v_harga);
end $$
delimiter ;

gimana-gimana? keren kan?
_______________________


Rizky Prihanto
Software Architect PT Cinox Media Insani

0 Teknik Praktis Analisis Posted on : 2/26/2009 07:20:00 AM

Di Cinox Media Insani, kami sering 'berganti-ganti formasi' dalam setiap pengerjaan sebuah project. Kadang, setelah progress berjalan, developer kami perannya digantikan oleh developer kami yang lain. Hal ini sangat mudah dilakukan karena kami semua mempergunakan framework aplikasi yang sama, dan kami sudah memahami standarisasi code yang ditetapkan oleh perusahaan, juga kami sudah tau karakteristik coding masing-masing rekan yg duduk di samping kami.

Beberapa minggu belakangan, gw melihat sebuah 'potensi baru' dalam tim kami yang solid ini. Gw mo latihan switch-role ke definisi jenjang yang berbeda. Bukan substitusi antar coder, tapi substitusi di level query building, di level art-designing, dan di level architecting. Permasalahan umum-nya yg dihadapi, apakah ada standarisasi di aspek query building, art-designing, dan bahkan architecting? Bukankah hal-hal tersebut adalah aspek-aspek subyektif yang *so-pasti* berbeda klo ditangani oleh orang-orang yang berbeda?

Betul sekali.

Maksut gw sebenarnya bukan substitusi dalam arti di tengah2 permainan sang architect diganti ama architect lain. Bukan begitu. Tapi formasi tempur Cinox pada "starting line-up" nya utk posisi-posisi architect, query-builder, art-designer -- seyogyanya jangan melulu di-isi oleh orang-orang yang sama terus. Bosan. Gag ada variasi-nya. Jadi, maksut gw, substitusi di sini adalah memberikan kesempatan bagi bro-bro dan sis-sis Cinoxers yang lain untuk "ikut merasakan" gimana sengsara-nya jadi Software Architect, atau jadi Art-Designer, atau jadi Query Developer.

Oke, deal!

Project yang jadi 'kelinci percobaan' udah ditentukan. Yang dijadikan case-study adalah aplikasi manajemen penerimaan pajak daerah. Gw lirik-lirik dokumen output yg diharapkan, cukup simpel. Dan gw coba utk project ini, gw hibahkan role Software Architect ke Bro Ali Hanifa. Hehehe.. sekalian belajar buat dia. Udah selayaknya dia naik 'pangkat' jadi Programmer/Analyst mengingat potensi besar yang dia tunjukin "kadang-kadang" udah cukup bagus utk di-upgrade ke level selanjutnya.

Eh, tau-tau... selang beberapa hari setelah dia nyoba ngebikin Spesifikasi Aplikasi, nongol imel dari dia yang isinya *curhat* -- dia kebingungan. BINGOENG ABIEZZ mo mulai nge-trace dari mana, sementara apa yang dia dapat hanya satu bundel format reporting yang diberikan ama Dinas Pendapatan Daerah.

Terlalu raw. Terlalu mentah.

Akhirnya, gw coba share-share dikit tentang teknik praktis analisis sebagai berikut (gw co-pas aja dari imel yg gw tulis utk beliau via milis staff@cinox.co.id) :

Sebenarnya "merumuskan spec" dari data2 mentah seperti format laporan itu adalah fungsi dari Software Architect berpusing-pusing ria di awal. hehehe...

klo data mentah masih kurang menggambarkan requirements? yang (biasa gw) bisa lakukan adalah :

1. tanya ke marketing kita atau "penghubung kita" --> apa sih yg elo janji-in ke client? itu akan jadi patokan dasar pembuatan spec kita. Dokumen kontrak kerjasama sebenarnya harus diberikan ke SA (oke lah, silakan sensor bagian tentang nominal project) -- karena dari situ kita bisa dapatkan scope pekerjaan. Batasan, scope, sampai di garis mana seorang SA boleh berimajinasi tentang struktur aplikasi yg bakal dihasilkan. Jangan sampe, marketing bilang ke client "sampe pendataan pajak" -- eh si S.A. berfantasi sampe ke "Wikimapia untuk informasi subyek pajak secara GIS" hehehe... -- atau sebaliknya. Scope yang dijanjiin sampe di state ini, tp spec yang dibuat ngga nyampae ke sono. Ini berbahaya. Sangat berbahaya.
   
2. bikin prototype trus ajukan ke client, klo begini kurangnya di mana?
3. klo client abstain ato malah bingung dengan spec prototype, kita tanyakan penilaian spec kita ke orang lain yg lebih 'terampil' : pegawai-nya client. Soalnya kebanyakan client itu adalah top-management. Sedangkan kebanyakan aplikasi yg kita bikin itu adalah aplikasi yg bakal dikonsumsi ama level low-management.
4. bingung bikin prototype? pelajarin proposal dan spec orang. Google adalah sahabat Anda.
5. Juga cari referensi apakah ada produk opensource serupa yg pernah dibikin orang? ato walo gag opensource, ada gag produk orang yg ada live-demo-nya? SourceForge.Net adalah kekasih Anda utk urusan beginian..
   
6. baca-baca referensi non-teknis tentang kasus yg dihadapi itu banyak membantu pemahaman kita n mempengaruhi spec yg kita bikin. Misal : undang-undang perpajakan daerah, bacaan2 direktori pajak dari pajak.go.id, artikel2 di koran atau portal berita seputar pajak
7. dan cukup penting juga kita "berteman" ama orang2 yg bergumul dengan tema sistem yg mo kita kembangkan. Misal, gw : punya temen SMA yg skrg kerja di pajak, kerja di depkeu, yg dulu kuliah di FIA Negara atau Ekonomi -- obok2 Facebook & Friendster Anda utk mendapatkan contact teman2 lama Anda...
8. juga, cukup penting juga kita "berteman" ama sesama software developer yang mungkin pernah mbikin sistem/aplikasi serupa. Klo ini, Kaskus room 147, diskusiweb, dan milis-milis komunitas software developer adalah tempat yang tepat untuk scouting.
9. Pengalaman pribadi dalam bikin sistem serupa sebelumnya juga "sangat berharga bangedd" utk membentuk perspektif spec yang akan kita hasilkan.
   

begitulah bro... keep on rolling the eyes..

Untuk kasus aplikasi pajak daerah ini ini, mgkn bro Ali bisa bikin spec utk dinikmati ama Jeng Tika (query), Non Dety (desain), ama Suhu Dendie (coder) dengan berpatokan dari struktur-schema yang akan gw bikinkan. Tapi utk development-lifecycle yg bener, bikin spec IO ama bikin struktur-schema itu adalah responsibility dari SA secara keseluruhan --> karena dalam bikin IO n struktur itu dilakukan secara iteratif n bersamaan. Saling mengevaluasi satu sama lain.

gpp.. kita jadikan ini ajang buat belajar bareng aja.. -- siapatau ntar "dalam perjalanan" kita nge-development, kita bisa dapat pengalaman-pengalaman yg makin mematangkan perspektif kita tentang Software Engineering...

:-)

_______________________


Rizky Prihanto
Software Architect PT Cinox Media Insani

1 MySQL & General Public License Posted on : 2/02/2009 02:53:00 AM

Ada diskusi menarik di milis mysql-indonesia@googlegroups.com yang *mempertanyakan* seputar lisensi MySQL yang rada-rada ambigu. Kekhawatiran muncul apabila kita me-rilis aplikasi komersil -- apakah bentrok dengan GPL dan melanggar "kontrak-kontrak sosial" yang udah disepakati di dalamnya?


Adhari C. Mahendra -- tampaknya beliau bekerja di Sun Microsystems Indonesia memberikan tanggapan menarik. Gw co-pas aja conversation mereka di sini :


fansul wrote:

mau tanya tentang license mysql apakah benar2 gratis untuk dipakai
diperusahaan.

License MySQL by default adalah GPL, jadi impactnya, aplikasi yang anda bangun adalah GPL. Sun atau dulunya MySQL AB tidak menarik bayaran atas license, mereka hanya jualan support sekaligus memberikan hak kepada yang membeli support untuk merubah lisensi GPL ke lisensi lain.

Selain itu ada lisensi OEM jika anda hendak menjual branding produk anda yang didalamnya ada MySQL.

soalnya lagi mempertimbangkan mau pakai oracle atau mysql, di cabang2
karena ada rencana merubah program dari ver lama dos ke ver windows
dengan back end mysql/oracle.
klu harus beli, bisa beli dimana dan harganya berapa di hitung per
user atau bagaimana ?
tks.

Kalau anda hendak membeli support MySQL anda bisa menghubungi kantor Sun Microsystems Indonesia di Wisma Metropolitan I Lt 13, minta kontak sales software. Harga support tergantung level dari support yang dibeli dan dihitung per system terserah jumlah user dan jumlah CPU yang dimiliki per systemnya.

***
Ada lagi pendapat dari Abangkis (gw gag bs mengidentifikasikan siapa nama sebenarnya dari Bapak satu ini ^_^) yaitu :

Secara garis besar penggunaan MySQL bisa dibilang gratis. Sedangkan yang dijual oleh Sun adalah Support Subscription/SLA. Dengan membeli Support subscription maka anda akan mendapatkan Support dan beberapa fitur lain seperti :
- update berkala
- binary khusus
- software2 enterprise khusus yang amat membantu untuk memaintain database.
- dll

untuk lebih detailnya bisa dilihat di : http://globalspecials.sun.com/store/mysql/ContentTheme/pbPage.categoryEnterprise

SLA ini dihitung berdasarkan jumlah server, dan merupakan subscription  tahunan. Kalau oracle bisa per user atau per cpu. Untuk harga, bisa dibandingkan sendiri di  http://www.oracle.com/corporate/pricing/pricelists.html. Perbedaannya lumayan jauh :P

Nah kalau kita bicara license, seperti pak adhari bilang, license MySQL adalah GPL. Kalau aplikasi yang anda kembangkan adalah untuk internal perusahaan maka hal ini tidak akan terlalu berpengaruh. Karena source code aplikasi dimiliki oleh perusahaan anda juga.


***

Benar-benar conversation yang menarik. Gw pengen membahas GPL dari sisi "konteks" -- terlepas itu diberlakukan di MySQL atau di produk-produk opensource yang laen. Begini ceritanya...

Berbicara mengenai *gimana sebenarnya* lisensi MySQL untuk produk komersial yg kita bikin, memang sangat membingungkan... Simak pernyataan berikut yang dikutip dari artikel ini :

Q2: Does the FOSS License Exception apply to all Sun software products, including the MySQL database server?

A: No. The FOSS License Exception does not apply to Sun's MySQL database server or any Sun or MySQL software other than the GPL-licensed MySQL Client Libraries. 

 

Q4: Can commercial OEMs, ISVs or VARs combine and distribute commercial products with Sun's GPL-licensed MySQL software under the FOSS License Exception? Does this include the MySQL database server?

A: Distributors of commercial products that combine GPL-licensed MySQL software with commercially licensed software (i.e., software not licensed under a FOSS license) must comply with the terms of the GPL. This includes use and distribution of the GPL-licensed MySQL database
server and MySQL Client Libraries. The FOSS License Exception does not apply with respect to products licensed under any license other than the FOSS licenses listed in the section above titled "FOSS License List."

Di situ dijelaskan bahwa FOSS License hanya berlaku untuk MySQL Client Library. Bukan database-nya. Saya lebih "senang" (atau tenang?) menginterpretasikan masalah lisensi MySQL ini seperti yang Pak Adhari Mahendra dan Pak Abangkis jelaskan di atas. Bahwa aplikasi kita yang mempergunakan MySQL sebagai database/backend itu mempergunakan lisensi GPL ketika di-deploy ke client. Aplikasi GPL tidak selalu harus dibuat dari platform yang GPL juga (misal PHP/Python). Tapi aplikasi yg dibikin dari C++, Delphi, .NET, atau VB juga boleh di-rilis sebagai GPL.

Nah, yang jadi masalah itu sebenarnya adalah *pendapat awam* tentang GPL itu sendiri.. Itu bener2 jadi momok menakutkan bagi para coderpreneur (ini istilah gw sendiri utk "pengusaha" code) : "apakah klo saya makae MySQL, brarti aplikasi saya gag boleh dijual (dikomersilkan) ???" -- dan kebingungan massal ini juga sering dimanfaatkan oleh (calon) customer yang membutuhkan software aplikasi : "ini kan GPL? mestinya gratis donk... mahal amat ngejual-nya?" ^_^

Richard Stallman, pencetus GPL itu sendiri, pernah menganalogikan Open Source dan GPL itu begini : "this is not about FREE BEER. but consider this (open-source) as FREE SPEECH" -- *dalem bangedd maknanya.. Kita berhak memasang harga sebesar-besarnya untuk aplikasi yang kita buat. Karena itu artinya kita telah "bersikap adil" terhadap jerih-payah kita. *hanya saja* -- kalau suatu saat client kita meminta source-code kita, berikanlah... Itu adalah GPL. Kenapa? Dengan GPL, kita sebagai developer sebenarnya dimudahkan, karena *mungkin* yang perlu kita lakukan klo mau membuat custom-build application hanya perlu melakukan refactoring dari aplikasi yang sudah ada. Poin ini sebenarnya juga memiliki nilai investasi lebih bagi stakeholder (client), karena dia ngga perlu "membayar" developer sebelumnya untuk sekedar konsultasi mengenai arsitektur sistem-nya dahulu. Di sisi lain, programmer juga dilindungi "kepemilikannya" -- karena GPL melarang kita memodifikasi tanpa menyertakan credit title author asli di code program. Walaupun hal ini *amat sangat mudah* dihapus oleh developer selanjutnya, tapi kekuatan hukum-nya kuat bangedd apabila developer asli pengen menuntut-nya dengan menyertakan bukti copy asli code aplikasi tsb. (Entah gimana dengan hukum di Indonesia, bisa ngga mengakomodir masalah ini klo suatu ketika ada code yang di-meja-hijau-kan)

Klo interpretasi saya sendiri, IMHO :

1. aplikasi yg dikeluarkan under GPL, itu source-code-nya memang harus diserahkan ke publik. Tapi definisikan "publik" itu sendiri siapa? yaitu client kita... Client berhak dapat source-code dari aplikasi yang dia beli.
2. Kalo developer tetangga -- yang dalam arti lain sama dengan "kompetitor kita" -- boleh ngga "nyontek" source-code dari aplikasi2 yang kita? -- ini pertanyaan rumit. Tapi hadapi saja. Siapapun developer yang pengen tau isi source-code dari aplikasi2 GPL kita, beranikan diri untuk face-to-face datang dan minta sendiri. :P -- dan biarkan idealisme dan harga diri yang berbicara kemudian... ^_^
   
3. Kalo suatu saat definisi publik di poin 1 itu makin melebar ke publik = komunitas atau publik = masyarakat -- buka aja code-nya n taruh di repository publik. Toh, klo emang kita yang bener2 bikin ndiri ntu aplikasi, kita juga bisa bikin ulang lagi aplikasi itu kapanpun kita mau. Kekayaan intelektual kita ngga akan berkurang secuil-pun dengan melakukan hal itu. Malah ada peluang "nambah" -- dengan dapat feedback dari orang2... -- loe pikir, MySQL bisa sebesar ini karena coder-coder di MySQL AB doank apa? Power of community itu sama seperti cara Son Goku mengalahkan Iblis Bhu : mengumpulkan energi manusia se planet bumi dengan BOLA SEMANGAT.
4. Masalah finansial, -- setelah gw pelajari dari pengalaman-pengalaman gw -- ada banyak hal yang ternyata lebih valuable secara finance ketimbang aplikasi gw sendiri : CONTENT dan SUPPORT. Kalo gw bikin web-portal, duit bisa datang dari content (entah iklan, entah isi berita itu sendiri) -- dan kalo gw bikin aplikasi sistem informasi, kue terbanyak dari income adalah dari PELATIHAN, PENDAMPINGAN, dan CONSULTING. Bahkan dengan GPL -- kita bisa saling berbagi kue pelatihan/pendampingan/consulting itu dengan partner developer lain. Kita jadi trainer/consultant dari produk dia, dia jadi trainer/consultant dari produk kita.
   

Gw punya temen yang bijaksana bangedd, dia punya filosofi gini : "Developer Indonesia kalo mau bersaing, bersainglah di sisi materi/finansial -- tapi utk urusan teknologi, sebaiknya saling bahu-membahu" -- dia menyampaikan itu waktu berkunjung ke kantor gw pas malam lailatul qadar bulan ramadhan kemaren. Bener2 ILLUMINATING deh. Dia ngingetin gw lagi tentang apa alasan utama gw terjerembab di dunia code seperti sekarang ini : yaitu mengabdikan code-code gw untuk kemajuan negara ini.

Duit bisa dicari coyy.. - kalo emang kita baik ama orang, orang akan bantu kita -- dan Tuhan sendiri juga akan sayang ama kita...

(eh, makin OOT ya? -- kembali ke laptop deh)

tentang Lisensi MySQL, gw cukup mengutip tulisan di website-nya MySQL ini :

For users or organizations looking to maintain their own solutions, (if) I have :

• My own method of keeping my systems up to date and am comfortable upgrading and configuring MySQL.
• Time to monitor and adjust the MySQL settings that will tune, scale and maintain performance.
• Experience with database security so that I know when a security breach has occurred.
• Experience designing, setting-up and monitoring the status of MySQL replication.
• Time to identify and resolve technical issues for myself and others.
• Time to design and tune application code, database schemas and dynamic queries for optimal performance.

TAKE ME TO THE COMMUNITY DOWNLOADS

yang gw interpretasikan : "yeah, I just only need the Community Edition of that database server..."

Demikian sedikit "curhat" dari saya tentang MySQL Licensing ^_^
-- maaf klo banyak yg OOT atau mencederai perasaan temen-temen... (-_-)
_______________________


Rizky Prihanto
Software Architect PT Cinox Media Insani