Ini posting blog saya setelah 100+ hari tanpa posting . Menikah itu memang mengubah seseorang, dari single dan nyaris 100% waktu untuk diri sendiri, menjadi nyaris 100% waktu dihabiskan berdua, semuanya serasa lebih seru karena tidak sendirian lagi. Tapi itu bukanya tanpa konsekuensi, , ya salah satunya saya jadi lebih malas ngeblog ataupun melanjutkan hobi-hobi pribadi seperti dulu.

Ok cukup deh prolognya, saya mau cerita tentang Linus Torvalds deh. Tiba tiba terbetik di pikiran saya untuk menulis tentang satu orang ini, satu orang yang jenius dan mengubah cara kita hidup dalam nyaris 15 belas tahun terakhir, walaupun sebenarnya sejarah itu dimulai beberapa tahun lebih awal. Kata “Kita” di sini lebih saya tekankan kepada “kita” manusia yang terhubungkan di jalur internet, atau mungkin malah orang-orang yang mencari hidup dari boomingnya internet, seperti saya.

Diawali cerita yang menurut saya sangat mirip telenovela atau kisah klasik, seorang mahasiswa master nun jauh di helsinki mencoba menulis kode sederhana untuk membuat kernel OS yang sangat sederhana. Ternyata setelah ditekuni, kernel yang dibuatnya menjadi satu puzzle terakhir dari sebuah proyek besar. Richard Stallman dan kawan-kawan sudah puluhan tahun memulai proyek GNU untuk membuat sistem operasi alternatif yang bersifat terbuka, tetapi GNU project sangat kesulitan membuat kernel OS yang efisien dan berjalan dengan sangat baik. Maka, Linux ini menjadi tambahan terakhir dari proyek GNU menjai satu sistem operasi yang lengkap.

Linux pada awal tahun 90an masih menjadi proyek pribadi Linus, hingga beberapa tahun kemudian lewat usaha kerasnya memperkenalkan linux lewat banyak sekali konferensi, linux mulai banyak digunakan oleh perusahaan di dunia. Awal tahun 2000an menjadi gerakan yang panas sekali, dimana pendukung linux menjadi sangat fanatik memperkenalkan linux ke khalayak. Tetapi sebenarnya linux sudah digunakan banyak sekali orang secara tidak langsung.

Di belahan dunia lain, ada seorang yang sangat murah hati bernama Tim Berners Lee yang mengumumkan kepada khalayak dunia bahwa protokol yang disusunya WWW (world wide web), dilisensikan secara gratis dan dibuka untuk dimanfaatkan semuaaa orang yang tertarik. Protokol ini bisa menghubungkan banyak sekali server, dan memberikan akses informasi dalam bentuk html kepada semua orang. Tetapi sayangnya OS yang digunakan Tim adalah OS yang berbayar dan web servernya pun masih sangat sederhana. Internet yang pada dasarnya perlu pengunjung besar, informasi yang banyak dan tentu saja resource yang sangat besar tidak mungkin dibangun dengan menggunakan software-software yang berbayar, karena biaya yang diperlukan akan menjadi sangat besar.

Kedua peristiwa yang berjalan beriringan ini menjadi satu momentum yang tinggi, di satu sisi industri Internet perlu sever yang berbiaya murah di sisi lain Linux menyediakan apa yang dibutuhkan oleh internet. Momentum ini begiiitu besarnya sehingga tahun 2000 menjadi salah satu tahun bubble paling spektakuler dalam sejarah. Banyak bermunculan perusahaan-perusahaan yang menawarkan service Linux menjadi sangat besar, bahkan beberapa perusahaan berhasil mendaftarkan diri di Bursa Efek, istilahnya Initial Public Offering (IPO). Internet plus Linux mengguncang dunia dan mendorong pertukaran informasi yang sangat cepat dan gratis, dikenal dengan era informasi, bahkan mendorong evolusi sistem operasi.

Pada titik ini, banyak orang-orang mulai memikirkan kembali hakekat software dan lisensinya, karena sekarang software tidak lagi menjadi barang jualan, tetapi lebih menjadi alat untuk mendapatkan nilai yang lebih tinggi, yaitu layanan internet. Maka mulailah didengung-dengunkan Open Source agar orang, perusahaan dan siapapun yang berminat menggunakan software dengan lisensi tertentu untuk membuat layanan dengan nilai yang sangat tinggi di atas software tadi. Google, facebook dan nyaris sebagian besar perusahaan internet sekarang ini menggunakan Linux di server-server mereka. Bayangkan jika OS dengan lisensi open source seperti linux tidak tersedia? layanan seperti google search dan facebook yang beegiitu bagusnya dan memerlukan banyak sekali resource tidak akan mungkin bisa dibuat semurah ini kalau OS dan softwarenya harus berbayar.

Kita balik lagi ke personal dari Linus Torvalds dan kejeniusanya. Linux adalah monolitic software, dimana semua proses dijalankan dari satu single file. Berbeda dengan kepercayaan ahli kernel OS waktu itu, model paling ideal untuk sebuah kernel adalah model node-node kecil yang berjalan secara independen dan bertukar data dengan sistem messaging. Sistem ini dalam prakteknya sangat susah untuk diperbaiki kalau ada masalah, karena masalah bisa saja muncul dari sekenario yang sangat susah untuk direkonstruksi, dimana setiap node punya keadaan yang berbeda-beda dan pesan yang dikirim antar node juga bisa sangat berbeda. Sistem monolitic yang digunakan Linus dalam Linux pada awalnya dikritik habis-habisan oleh dosen pembimbingnya, dan disarankan untuk segera diakhiri saja karena membuang-buang waktu. Tetapi linus bergeming, sistemnya jauh lebih stabil dan tahan terhadap berbagai macam kesalahan yang muncul karena aplikasi maupun hardware tidak berlaku selayaknya.

Hiruk pikuk Linux sedikit mereda beberapa tahun terakhir ini, ditandai dengan evangelist linux yang tidak segencar misalnya 10 tahun lalu, dikarenakan linux sudah menjadi semacam komoditas yang semua orang sudah tahu kehandalanya sehingga tidak lagi diperlukan banyak sekali edukasi. Hiruk pikuk berpindah ke cara bagaimana menggunakan linux sebagai alat untuk menghasilkan produk atau layanan yang lebih menyentuk pengguna secara langsung. Misalnya membuat ecomerce atau layanan internet yang ciamik. Tetapi linus tidak berhenti berkarya, satu produk ditelurkanya setelah sebal dengan software Source Code Management system yang ada, seperti CVS atau SVN. Git lahir dari tanganya yang jenius, dengan sangat yakin linus bilang bahwa dia bisa membuat SCM yang jauh lebih bagus dari semua yang ada di luar sana dalam waktu 2 minggu!, dan ternyata berhasil.

Dalam satu sisi Git merevolusi bagaimana seorang programmer menggunakan kodenya untuk berinteraksi dengan orang lain, hal ini dimungkinkan dengan adanya layanan github.com yang membuat coding menjadi kegiatan sosial layaknya seseorang membagi status wallnya kepada orang lain. Satu pengguna bisa mengikuti pengguna yang lain, berteman dan mengambil proyeknya untuk dibuat branch. Sekarang coding tidak lagi menjadi kegiatan personal, tetapi sudah bisa menjadi kegiatan sosial. Seseorang tidak lagi merasa terpencil dan tidak ada keterikatan dengan kode yang dibikinya, dengan github, kode bisa menjadi pengikat antara seorang programmer dan kode yang ditulisnya.

Nah segitu dulu cerita saya tentang Linus Torvalds, semoga memberi inspirasi kepada kita, bahwa sesuatu hal kecil yang kita mulai dengan sungguh-sungguh bisa mempunyai dampak yang begitu serius kepada sekeliling kita. Jangan ragu-ragu memulai, jangan merasa sia-sia, lakukan, bagi dan kamu akan sadar bahwa apapun yang kita bagi, selama itu adalah pengetahuan, pada satu titik akan menjadi inspirasi bagi orang lain.

Saya baru saja selesai menterjemahkan buku “Scrum and XP from the trenches” karangan Henrik Kniberg ke bahasa indonesia, judulnya saya ganti menjadi “Scrum dan XP Secara Praktis”.

Sesuai dengan judulnya, buku ini membahas bagaimana Henrik dan timnya mengimplementasikan Scrum dan XP di dalam perusahaan mereka. Hal ini membuat buku ini menarik sekali untuk dibaca dan mudah sekali untuk dicerna, karena isinya lebih banyak bercerita tentang kisah mereka mengimplementasikan Scrum dan XP. Jauh sekali dari buku-buku lain yang lebih banyak membahas teori.

Buku ini dulu saya baca karena ada saran dari kenalan saya yang bilang “Sebelum umur 30 tahun harus segera switch ke jalur managerial” (sambil lirik dhiku ) ). Jadi ini persiapan saya semoga bisa lancar ikut jalurnya dhiku switch ke managerial.

Bukunya bisa diunduh dari :

http://tanyajava.com/download/scrum

Saran, kritik dan yang penting adalah koreksi isi dari buku atau malah mungkin koreksi dari kesalahan penterjemahan buku sangat saya tunggu.

Selamat membaca dan semoga bermanfaat.

Episode kali ini adalah lanjutan dari episode sebelumnya. Tamu kita masih sama, Feris Thia dari PHI Integration dan founder dari milis pentaho indonesia (pentaho-id@googlegroups.com). Kita membahas dari awal apa itu pentaho hingga secara detail membahas satu per satu komponen / modul yang ada dalam pentaho. Tak lupa juga kita bahas tentang milis pentaho indonesia yang ramai sekali.

Setelah itu kita lebih jauh membahas tentang langkah-langkah development aplikasi BI mulai dari membuat star schema, kemudian setup ETL untuk mengambil data dari aplikasi transaksi dikirim datanya ke BI. Setelah itu dibuat cube dari fact table, dan pada akhirnya bisa dibuat MDX query untuk mempresentasikan cube yang sudah dibuat.

Pembahasan paling seru terjadi ketika kita membahas secara teknis bagaimana ETL (Pentaho Data Integration / kettle) bekerja, membuat table transaksi yang BI friendly hingga membahas perbedaan antara data dalam excell dan data dalam table database.

Podcast kita akhiri dengan pembahasan lebih lanjut tentang industri BI di indonesia serta membahas karir di BI.

#15 http://indo-java-podcast.googlecode.com/files/indo-java-podcast%2315.mp3
- Pentaho sebagai solusi dan pentaho sebagai perusahaan
- Arsitektur aplikasi yang menggunakan Bussiness Intelligence
- Komponen Pentaho
– Pentaho Reporting
– Pentaho Data Integration (Kettle), aplikasi ETL yang merupakan komponen jagoanya Pentaho
– Pentaho Analysis (Mondrian), crosstab reporting tools
– Pentaho Data Mining (Weka)
– Pentaho BI Server

Hari ini di milis it-project-indonesia@googlegroups.com ada Joshua Partogi dari Scrum Indonesia yang kenalan, kemudian terjadi diskusi yang cukup seru tentang Scrum Vs Waterfall. Nah di salah satu thread ada yang menanyakan gimana sih development di banking kepada saya


> Buat Ifnu, bisa ceritain nu development di banking kaya gimana dan
> kenapa waterfall itu yang terbaik?


Nah karena jawaban saya panjang lebar, sepertinya cocok diletakkan di dalam blog agar lebih banyak yang bisa baca. Hmm, oke gw ceritain agak panjang yah tentang topik ini.

Background Institusi

Salah satu investment bank paling gede se jerman. Budget biasanya sih ga jadi masalah, karena uang cukup berlimpah, bisa bayar employee di atas rata-rata pasar singapura.

Team

Di sini ada beberapa team yang menangani aplikasi :
1. Team development : Developer, BA, Functional Specialist, PM
2. Team Internal Testing
3. Team UAT testing
4. Infrastructure team: Unix, DBA, Deployment, Configuration team dan Source Control team (build, package, versioning system)
5. Production support team

Di luar itu ada beberapa peran yang gak ada di dalam team di atas :
1. Product Owner dari sisi bussiness
2. Product Owner dari sisi IT

Development Methodology

Kita menggunakan Waterfall strict yang comply dengan CMMI Level 5, semua dokumentasi dimantain di sharepoint server dan ada guidlines (template) dokumen apa saja yang perlu dibuat setiap release. Ketika project diinisialisasi diasumsikan bahwa project ini akan terus didevelop, dienhance, patch dan dimantain selama bertahun-tahun.

Project akan dikasi alokasi budget fix di awal tahun, budget ini biasanya ditentukan apakah aplikasi ini menghasilkan ROI yang bagus di tahun-tahun sebelumnya. Kalau iya maka diterusin dikasi budget besar, kalau nggak biasanya cuma dikasi budget seupil untuk maintenance aja. Atau malah dibunuh aplikasinya kalau sudah ga ada client sama sekali. Budgetnya juga ga main-main loh, aplikasi gw ini cuma kecil banget tapi bisa habis ratusan ribu USD setahun. Ada aplikasi yang source codenya aja 5GB, ini bisa puluhan juta dolar budgetnya, #ngiler.

Setiap aplikasi akan release 4x dalam setahun, misalnya tahun ini ada release 11.1, 11.2, 11.3 dan 11.4. Apa yang ada di dalam setiap release ini ya juga tergantung budget, kalau dikasi budget development ya banyak yang direlease, kalau cuma maintenance ya sudah ga ada release sama sekali. Paling cuma simple patching, seperti ganti copyright setial awal tahun ).

Di sisi vendor, ada 2 arrangement: managed service dan non managed service. Di jenis managed service, vendor akan dikasi budget fix per tahun, kemudian dikasi scope apa aja yang harus dikerjakan dan dikasi komposisi teamnya. Nah biasanya kalau managed service ini sama vendor
dieksekusinya di negara asalnya, india, nggak di singapura. Kenapa? ya karena gaji karyawanya kan cuma 1/3 dari singapura. Delivery menjadi tanggung jawab vendor, kalau ada yang salah, misalnya ada show stopper bug di production, vendor bisa kena denda setelah 3x. Dendanya buaanyak. Dari sisi client cuma ada Product Owner, PM dan Senior Architect. PO akan menentukan feature apa aja yang dibuat, partnernya di sisi vendor adalah BA. PM menentukan gimana jadwalnya dan architect menentukan bagaimana feature ini secara teknis diimplementasi.

Jenis satunya lagi non managed service, client bertanggung jawab terhadap delivery project, vendor cuma menyediakan resource dan nyalain argo . Simple, dan easy money sih di sisi vendor.

Flow development dimulai dari highlevel management untuk menentukan strategi bisnis dan aplikasi, kemudian PO akan merancang requirement apa saja yang perlu dari aplikasi ini. Setelah itu PM bersama dengan PO dan management akan menentukan budgeting dan proyeksi go livenya kapan. Setalah itu Architect akan membuat highlevel design dan arsitektur aplikasinya. Sampai di sini belum ada keterlibatan development team, semua effort masih di sisi client, hingga suatu saat (ini bisa bertahun-tahun kadang-kadang) dirasa semua stakeholder aware dengan semua aspek aplikasi maka development dirollout deh.

BA akan membuat Functional Spec yang saaangatttt rinciii, sampe kecil-kecil pritil-pritil, sampe ke error message, error validation dan semua tetek bengeknya. Setelah Functional Spec kelar, baru kemudian Architect memerintahkan Functional Specialist membuat detail design, seperti UML, ERD, dan seterusnya. Product Owner signoff Functional Spec, architect sign off Detail Design document.

Baru kalau Functional Spec dan Detail Design kelar, developer dihire. Langkah pertama adalah bikin POC, bikin Project Template, bikin build script, DDL, DML dan semua logistik project. Functional Specialist akan melakukan code review berkala untuk semua kode yang dicheckin oleh developer. Ada dokumenya juga loh :O. Dia akan memeriksa hasil code analysis dari PMD, Findbug dan Sonar.

Dalam waktu bersamaan Internal Tester akan membuat skenario testing yang lengkap untuk semua feature aplikasi, ini ga main-main jumlahnya, di project saya aja ada sekitar 400 test case, padahal project kecil. Kalau yang gede ga tau deh berapa banyak . BA akan sign off
skenario testing ini.

Proses development biasanya dibagi-bagi menjadi drop kecil-kecil, drop 1, drop 2, drop 3 dan seterusnya. Setiap drop ini ada release notesnya feature apa saja yang sudah diimplementasikan, tester akan mengetest berdasarkan skenario testing dan berdasarkan functional spec yang dibuat oleh BA. Nah inilah masa-masa developer dipecut-pecut, . Masa ini disebut dengan SIT testing period, setiap hari jam 2 sore ada rapat TD (test defect) setiap TD yang dibuat oleh tester dibahas oleh: PM, Product Owner dari aplikasi, Senior Developer, Functional Specialist dan kadang-kadang BA juga ikut kalau ada feature yang kurang jelas.

Ini adalah sesi pembantaian developer , pertanyaan banyak sekali diajukan oleh PM, jangan kira PM ini males-males dan maunya beres aja seperti di indo loh, senior banget jabatanya udah
Vice President dan nanyaaaaaaaaaaaaaaaaaaaaaaa terus kerjaanya . Kalau kita gagu aa uu aa uu, wah wah wah, dicatet deh sama PM, kalau ada pemotongan jumlah pegawai ya siap-siap dikasi surat cinta.

Setelah masa SIT berarkhir maka SIT akan menyerahkan hasilnya (TD yang belum terpecahkan dan TD yang udah terpecahkan) ke UAT tester. UAT tester ini adalah kepanjangan tangan dari Product Owner dari sisi Bussiness, mereka ini biasanya bukan orang teknis, ya disimulasikan
seperti user biasa aja, tapi pinter-pinter, bisa ketemu deh skenario aneh2 yang bikin aplikasi jadi ga beres .

Bersamaan dengan UAT biasanya ada Load Testing yang akan mengetest performa aplikasi ketika dikasi load tertentu. Kalau Load Tester ini membuat Test Defect, alamaaaaak, cari pemecahanya susyaaah bener. Pasang profiler di mana-mana, pasang transaction log untuk melihat eksekusi per komponen aplikasi, pasang database index, pasang cache L1, pasang cache L2, pasang asynchronous/background process, pasang heap dump log, pasang JVM argument aneh-aneh, pasang JVM BEA, ganti lagi JVM Sun, pasang ini itu di sana sini masiiih aja kadang-kadang ga
ketemu bugnya di mana. . Nangis darah deh kalau kena jenis ini.

Test terakhir adalah penetration testing, ini sih bugnya menakutkan, tapi mengatasinya sih ga susah. Soalnya kalau di java frameworknya sudah banyak membantu, seperti SQL injection, XSS, Session Forgery dan ACL sudah ada frameworknya, tinggal masang aja.

Semua tester harus menyediakan signoff sebelum deadline production release, ada satu aja tester ga mau tanda-tangan ya sudah production date akan ditunda.

Day To Day developmentnya sih cukup hectic yah, seperti yang saya bilang di atas setiap jam 2 sore ada Test Defect call, kemudian kadang-kadang kalau ada load test defect yang serius, seperti outofmemoryexception atau page timeout akan ada load test defect call
jam 4 sore. Trus jam 9 malem ada UAT Test Call juga. Hedeeeeh. gila deh.

Setelah release biasanya kita pesta-pesta, makan makan dan selama management menentukan apa saja yang perlu discope di release berikutnya, developer bisa pulang tenggo . Tapi technical specialist gw ga rela deh kalau ada developer idle, pasti dikasi kerjaan apa gitu, POC misalnya. Soalnya kalau developer idle PM akan nanya, si ini ngapain? kalau dijawab ga ngapa2in, PM akan nanya lagi, udah berapa lama ga ngapa2in? udah 2 bulan. Ya sudah PM akan segera melepas ini developer deh. Kalau developer ini pegawai tetap ya vendor akan meletakkan dia di “pool” dan dicariin project lagi, asik banget deh di pool ini, ga ada kerjaan gajian jalan terusssss ). (sayang gw ga pernah masuk pool, ngenes).

Kalau di indonesia model development seperti ini juga lazim digunakan, cuman yang bener-bener mirip itu Permata, soalnya dipengaruhi oleh pemegang sahamnya, HSBC. Sedangkan bank lain seperti BRI masih pake project management kuno, koboy ).

Nah sekian cerita saya nih. Kalau capek bacanya bisa dengerin saya cuap-cuap bareng adelwin tentang topik large development team di banking

http://ifnubima.org/indo-java-podcast-10-ngobrol-bareng-adelwin-tentang-large-development-team/

Udah lama sekali ga ngeblog yah, ga kerasa udah beberapa bulan ga ada entry. Mungkin karena ramadan ini badan jadi terasa lebih seger, atau karena ramadhan bisa pulang tenggo dan ga terlalu cape sesampainya di rumah? yang manapun ga masalah deh, asal ngeblognya jalan lagi.

Barusan saya posting di JUG tentang performance tuning guidlines, nah karena pentingnya topik ini saya pikir lebih baik diletakkan di blog untuk pengingat kalau suatu saat perlu.

Blog entry ini akan saya terus edit untuk agar lebih lengkap dan ada contoh-contoh kongkritnya, sekarang cukup kerangka umumnya dulu yah.

Optimisasi itu biasanya cukup yang makro, guidlines ini saya urutkan berdasarkan kepentingan sebagai berikut:

1. Buat index untuk semua query agar tidak ada query yang full scan.

Pertama harus dikumpulkan semua query yang sering dieksekusi dan
profile mana aja yang slow query. kemudian gunakan query explain untuk
menjelaskan berapa cost setiap query. baru tentukan index yang harus
dibuat agar query menjadi lebih cepat.

2. Minimisasi disk seek (pembacaan disk).

Kalau punya duit ganti ke hardisk yang jarum dengan hardisk SSD deh database servernya, wush wush wush kenceng abis. Kalau ga bisa ganti SSD ya bikin cache di level aplikasi agar hit ke database minumum, kalau perlu load semua data ke memory dan gunakan database
sebagai backup ) .
Kalau ada upload dan file processing gunakan IO yang ada buffernya (buffered writer / reader).

3. Resource allocation optimization.
gunakan paging untuk menampilkan table / grid, gunakan connection pooling, close semua I/O setelah tidak digunakan, gunakan singleton untuk kasus yang memungkinkan.

4. Asynchronous/background process

Untuk proses yang tidak berhubungan dengan user experience, gunakan @Async (Spring dan EJB punya asynchronous method call) atau buat scheduler framework yang dijalankan dari JVM yang berbeda. Proses-proses yang berat dan melibatkan pengambilan data dari database yang cukup besar seperti End-Of-Day process, report generation, file upload dan audit trail/log, semua
bisa dilakukan di background atau async.

4. Tambah resource / lakukan clustering

5. Tambah Tier aplikasi.

Sekarang kan yang lazim itu ada 2 tier kalau aplikasi web : App server + Database. Nah ini bisa ditambah lagi satu tier : web server + app server + Database.
Semua static content seperti image, javascript dan applet ditaruh di web server ini, kemudian optimisasi http header agar gak semua static content diload setiap kali page dihit.
Gunakan tools yslow dari yahoo di firefox untuk memeriksa skor setiap page, apakah cepet loadnya apa nggak. Ada performance guidlines gimana agar content lebih cepet diload oleh
browser, cek di http://developer.yahoo.com/yslow/help/

6. Pindah ke platform 64 bit

7. Micro optimization

lihat kode di dalam loop, minimalisasi import, cek string concatenation, cari algoritma yang lebih efisien, dst dst. Rata-rata micro optimization bisa dibaca di buku Effective Java. Kalau
aplikasi database sih sepertinya ga sampe ke sini deh optimisasinya. Kecuali aplikasi yang memerlukan latensi / response time yang cueeepet seperti trading atau forex baru deh optimisasinya bener-bener teliti. Karena beda satu atau 2 detik untuk setiap proses bisa mempengaruhi kinerja aplikasi secara keseluruhan, karena biasanya sih proses yang
dihandle bisa ribuan per detik, artinya kalau satu proses bisa dihemat 1 detik, penghematan secara keseluruhan bisa signifikan.

Nah semoga bermanfaat bagi temen-temen yang sedang mengalami response time aplikasi yang lambat atau malah sering kena outofmemoryexception .

Hi pendengarnya indo java podcast. Lagi-lagi kita perlu waktu 3 bulan untuk menerbitkan episode baru , setelah awal tahun kemaren saya yang sibuk, gantian 3 bulan terakhir Dito yang sibuk, jadi mohon maaf atas ketidaklancaran penerbitan episode Indo Java Podcast. Kali ini kita kedatangan tamu, Feris Thia, dari PHI-Integration. Kita ngomongin Data Warehouse, Data Mining dan Bussiness Intelligent dari awal sampai akhir bahkan sampai beberapa topik diluar teknis seperti lowongan kerja, karir di area ini hingga pengalaman implementasi PHI di berbagai perusahaan.

Kita mulai membahas tentang apa itu Data Warehouse dan dua mahzab yaitu : Ralph Kimball dan Bill Inmon (http://en.wikipedia.org/wiki/Data_warehouse). Kemudian dilanjutkan dengan membahas lebih lanjut teori aliran Kimballites, di dalamnya ada teori tentang snowflake schema dan star schema. Saya sendiri cukup mendapat banyak penerangan tentang istilah-istilah penting dalam DW, misalnya apa itu fact table dan dimension table yang sebenernya adalah nama lain dari master table dan transaction table di OLTP.

Setelah puas membahas DW, kita lanjut ke tema yang lebih seru, yaitu Data Mining dan Bussiness Intelligent. Nah di sini ada istilah yang disebut dengan active reporting, dimana report yang ditampilkan kepada pengguna sudah mengandung “kecerdasan”, bukan lagi pasif reporting yang cuma menampilkan data dalam bentuk table, diagram atau malah cuma angka-angka gak bermakna. Singkatnya, Data Mining dan Bussiness Intelligent itu membuat data bisa ngomong dengan bahasa manusia . Data Mining dan Bussiness Intelligent bisa membuat management melihat keadaan perusahaan dengan lebih jelas dan dengan persepsi yang sama, kalau cuma data pasif yang disajikan, maka setiap orang dalam managerial bisa punya asumsi yang berbeda tentang keadaan perusahaan, ada yang bilang oh penjualan kita OK nih, nah ini parameter OK dilihat dari mana? Bussiness Intelligent bisa menterjemahkan data yang dikumpulkan oleh Data warehouse menjadi laporan-laporan aktif seperti ini.

#14 : http://indo-java-podcast.googlecode.com/files/indo-java-podcast 14.mp3
- Data Warehouse
– Ralph Kimball dan Bill Inmon
– Snowflake schema dan Star schema
– Dimension dan Fact schema
– Slowly changing dimension
- Bussiness Intelligent dan Data Mining

Akhirnya setelah 10 bulan menulis, mengedit dan menyiapkan website, buku Java Desktop bisa anda unduh dengan gratis dari URL di bawah ini :

http://tanyajava.com/download/javadesktop

Buku ini berisi intisari pengetahuan dasar bahasa pemrograman Java hingga pengetahuan tentang bagaimana membuat aplikasi dekstop menggunakan Java. Intisari tersebut saya kumpulkan selama 3 tahun terakhir. Buku ini terdiri dari 8 bab, antara lain :

Bab 1 kita akan membahas tentang Java Fundamental, bab ini dibagi menjadi dua bagian besar: belajar sintaks java dan belajar OOP menggunakan java. Di dalam bab ini juga dibahas tentang java 5 language enhancement yang mencakup beberapa perubahan fundamental di dalam sintaks java. Bab ini cukup panjang dan mangambil porsi hingga 1/3 dari buku ini.

Bab 2 membahas tentang tools yang kita gunakan, NetBeans. Bagaimana membuat project, menambahkan library, menambahkan library ke pallete, menggunakan editor dan debugger, dan seterusnya. Penguasaan akan IDE diperlukan untuk menaikkan produktiftas, tanpa penguasaan IDE yang baik, produktiftas tinggi susah untuk dicapai.

Bab 3 membahas tentang koneksi ke database menggunakan JDBC. Di bab ini mulai dibahas tentang design-pattern dalam membuat kode. DAO dan Service adalah design-pattern sangat penting dalam akses database. Dilanjutkan dengan membahas ORM, Hibernate dan Spring untuk akses data. Dengan menggunakan Hibernate, produktiftas programmer menjadi meningkat drastis dibanding menggunakan JDBC murni. Spring digunakan sebagai “lem” untuk merekatkan berbagai macam komponen aplikasi, termasuk nanti digunakan sebagai tulang punggung arsitektur three tier

Bab 4 membahas tentang Swing dan komponen-komponenya. Dibahas juga pattern MVC yang digunakan komponen Swing dalam mengolah dan menampilkan data.

Bab 5 membahas bagaimana membuat aplikasi POS. Dimulai dari membuat halaman master, dilanjutkan dengan membuat halaman pembelian dan penjualan.

Bab 6 membahas bagaimana membuat report dengan JasperReport. Di dalamnya termasuk juga teknik mengcompile report yang dibuat secara otomatis menggunakan ant script bawaan dari NetBeans.

Bab 7 membahas bagaimana mengimplentasikan arsitektur three tier menggunakan Spring Remoting.

Bab 8 merupakan bab terakhir yang membahas bagaimana membuat installer menggunakan IzPack, sehingga aplikasi mudah didistribusikan dengan adanya fle installer.

Hari ini saya login ke server dan mendeploy aplikasi tanyajava.com, eh eh ternyata saya lupa password root mysqlnya . Sudah dicoba dengan apt-get remove dan apt-get install berkali-kali ternyata password rootnya tidak disetting ulang.

Setelah cari tutorial ke sana ke mari akhirnya dapet juga tutorial yang bagus di situsnya mysql. Langkahnya ternyata tidak terlalu sulit dan mudah diikuti.

1. Stop mysql server

$ sudo /etc/init.d/mysql stop

2. Buat sebuah file untuk meletakkan script reset password, misalnya nama filenya adalah reset-mysql-password.txt yang saya letakkan dalam folder /home/ifnu kemudian isikan query berikut ini :

UPDATE mysql.user SET Password=PASSWORD('MyNewPass') WHERE User='root';
FLUSH PRIVILEGES;

ganti nilai ‘MyNewPass’ dengan password yang anda inginkan. Pastikan passwordnya strong agar tidak mudak dijebol hacker.
3. Login ke dalam sistem dengan user root :

$ sudo su

4. Setelah dapat akses root linux, jalankan perintah ini :

# mysqld_save --user=mysql --init-file=/home/ifnu/reset-mysql-password.txt

5. Setelah itu coba login dengan menggunakan user root

$ mysql -u root -p

6. Kalau langkah 5 berhasil, keluar dari mode safe (msyqld_safe) dengan menekan ctrl + c dan jalankan service mysqlnya secara normal

$ sudo /etc/init.d/mysql start

Selesai sudah langkah mereset password root dari mysql.

Posting kali ini saya mau membahas cara mensetting ssh login dari mac ke linux ubuntu tanpa menggunakan password, jadi tujuanya adalah membuat linux mempercayai saya (mac) sebagai client yang terpercaya sehingga tidak perlu meminta password setiap kali login ssh ke server. Dengan fasilitas ini memudahkan berbagai macam aktifitas dari client (mac) ke server, semisal melakukan scp dan rsync tanpa harus memasukkan password.
Untuk mengetahui lebih jelas skenario ini serta sedikit intro tentang private-public key, anda bisa baca entry dari blognya endy di sini

Langkah-langkahnya sangat sederhana, yang pertama adalah membuat rsa private-public key dengan perintah ssh-keygen di mac (client) :

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/ifnu/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/ifnu/.ssh/id_rsa.
Your public key has been saved in /Users/ifnu/.ssh/id_rsa.pub.
The key fingerprint is:
xx:xx:xxx...:xxxxxx

Perintah ini akan menghasilkan dua buah file di dalam folder .ssh yaitu id_rsa dan id_rsa.pub, file id_rsa.pub adalah public key yang akan kita kirimkan ke server.
Langkah kedua adalah menyiapkan konfigurasi di server, tentu saja sampai saat ini ssh server sudah terinstall di server, tetapi setiap kali login kita perlu memasukkan password. Misalnya IP server saya adalah 12.34.56.78, usernamenya adalah ifnu dan home folder saya adalah /home/ifnu, kita perlu membuat file authorized_keys di dalam folder .ssh yang ada di dalam home folder. Kalau folder dan filenya belum ada silahkan buat dulu menggunakan perintah mkdir dan touch.
Setelah file /home/ifnu/.ssh/authorized_keys tersedia, kita perlu mendaftarkan public key yang sudah kita buat di client ke server. Cara pendaftaran public key yang sudah dibuat di langkah pertama di atas sangat sederhana, kita cuma perlu mengkopi paste isi dari id_rsa.pub yang ada di client ke dalam file authorized_keys yang ada di server. Buka file authorized_keys menggunakan text editor, semisal nano, paste isi dari id_rsa.pub ke dalam file tersebut dan simpan.
Setelah proses pendaftaran public key selesai dilaksanakan, maka ssh login ke server dari client tidak perlu lagi menggunakan password, cukup ketik perintah :

$ ssh ifnu@12.34.56.78

maka kita langsung bisa masuk ke dalam server tanpa password sama sekali.

Di milis JUG indonesia sedang ramai membahas topik tentang lingkungan seperti apa yang enak untuk karyawan. Thread seperti ini biasanya panjang, seperti halnya thread gaji, kedua thread ini punya satu kesamaan : membahas masalah hubungan employee-employer. Ada satu sisi ingin mendapat fasilitas, gaji dan kebebasan berekspresi super satu lagi ingin mendapatkan margin keuntungan selebar-lebarnya.

Thread mulai panjang ketika salah satu “owner” perusahaan melempar pertanyaan seperti ini :

Sebenarnya definisi/kondisi enak di suatu perush itu apa ya? Sebenarnya kita juga lagi cari Java Programmer
Mungkin sbg perusahaan, siapa tahu kita bisa menciptakan kondisi yg enak tsb kalau kita tidak tahu kondisi yg enak, maka tdk pernah tercipta kondisi enak tsb.

Kemudian ada yang menjawab dengan sangat baik pertanyaan di atas

Kriteria sy lingkungan kerja development khususnya aplikasi java development:
A. Aset: perlakukan tiap2 developer sbg aset persh. Menurut sy ada beberapa aspek yg perlu dilakukan dalam pengermbangan aset tsb:
Lingkungan kerja:
1. Buat kondisi lingkungan kerja IT berbeda dengan industri masal. Menurut sy banyak pengembang yang bermimpi kerja di google, krn foto2 ling kerja di google itu manusiawi dan santai banget.
2 Pembagian kerja dan level supervisi yang jelas. Kadang persh kurang orang, sehingga menjadikan dev sbg teknikal writer atau financial controller sbg tugas tambahan.

Nilai skill dan pengalaman:
1 diberikan kesempatan untuk menerapkan pola kerja agile, atau lainya yang akan mengasah tiap developer baik dari segi skill atau team work
2 diberi kempatan kreative utk mempelari ‘the new way’(mis new framework) untuk solutioning. 1 – 3 bulan. Kalau dr kacamata persh anggap ajah investasi
3 kadang persh juga perlu analisa kejiwaan developernya. Kerja yang monoton, berhadapan dengan layar komputer, projektor dan berlembar2 kertas use cases bisa mengganggu kejiwaan seseorang. Kegiatan refreshing bersama2 rekan kantor atau aktifitas ‘kegirangan’ lainnya akan sangat membantu.

Masa depan
1. Tahapan work appraisal yang terpola. Banyak persh IT tdk menerapkan ini, krn berpikir selama karyawannya tidak nego gaji, maka gaji tsb sdh cukup. Sementara programmer berpikir, gaji sy tdk akan naik kalo sy tdk pindah. Tak heran persh IT punya turnover yg tinggi
2 sama spt umumnya pekerja, masa depan dan tanggungan keluarga menjadi fokusnya setelah pulang dari kantor. Jika persh mampu memberikan jaminan hal tsb, akan mengurangi beban pikiran developer

B. Berpikirlah menjadi besar (berlanjut kalo lagi sempet ajah yah)

Jawaban di atas sangat positif dan sangat “indonesia” sekali, jadi mendapat tanggapan yang positif

Kita butuh programmer yg bisa ngomong spt ini nih,
kita sbg perusahaan mau aja memberi & membuat lingkungan spt yg diimpikan para programmer, tapi selama ini blm ada programmer yg ngomong maunya apa.

Saya berani investasi untuk membuat perusahaan yg diimpikan programmer, Tapi harus ada orang yg bisa mewujudkannya dlm tindakan nyata. Kalau orang itu berhasil, akan saya jadikan partner.

Kita coba 1 tim kecil aja, 2-3 orang, kalau 2-3 orang tsb berhasil mewujudkan lingkungan/kondisi kerja yang baik tsb, maka kita rekrut bbrp orang lagi,
siapa tahu kita bisa jadi tempat kerja yg diimpikan programmer spt google.

Lagi hangat-hangatnya berdiskusi kok ya ada yang reply statement yang sangat tidak etis (baca WTF!!) seperti ini tho :

Allow me to make it short and simple :
1. Gaji “gede”
2. OT Jarang
3. Kegiatan “nyambi” diworking hours
4. Dikasi waktu buat traning , research and development ,etc . Eventhough deadline didepan mata ?

Did i understand correctly ?

Utterly unethical!!
Ada juga yang melihat bahwa kerja di rumah adalah kondisi “nirvana” buat programmer

kondisi yg enak?
bisa ngeliat anak istri main2 di sekitarku..

say no to office
hahaha

Buat saya pribadi, kehidupan sosial di kantor itu sangat penting, karena ada teman kerja yang bisa hang-out bareng dan melakukan aktifitas “bergaul” lainya seperti outing, family gathering dan seterusnya. Aktifitas sosial ini kemungkinan besar ga ada kalau kita tinggal di rumah, tapi karena orang indonesia itu orang rumahan banget jadi ga ada masalah kerja di rumah dengan keluarga.
Komentar paling komprehensif dan favorit saya datang dari Endy . Komentar ini paling cocok untuk kondisi dan karakter lingkungan kerja di perusahaan Indonesia.

Pengalaman saya waktu jadi pegawai dulu gini. Nasib kita yang tentukan ya kita sendiri.

1. Gaji
Misalnya, kita mau gajinya naik, tapi kita sendiri gak mau minta kenaikan gaji, melainkan cuma nunggu yang rutin setahun sekali. Coba bilang sama bos, “Saya udah kontribusi A, B, C, kalo diuangkan nilainya sekian untuk perusahaan. Naikin gaji saya dong”. Masalahnya, kita sendiri tidak bisa mengkuantifikasi kontribusi kita, entah karena kontribusinya kurang, gak bisa ngitungnya, atau yang kita kontribusikan sebetulnya tidak signifikan dari sudut pandang perusahaan.

2. Karir
Urusan karir apalagi, ini mutlak bener2 harus diurus sendiri. Ini bisa dilihat terutama dari pemanfaatan waktu luang.Namanya programmer pasti ada waktu luang, entah nungguin bos meeting requirement/scope, nungguin usernya ngetes, di jalan menuju ke client,etc. Bagaimana dia memanfaatkan waktu luang? Update status di facebook atau baca ebook Mythical Man Month? Apa isi tweetnya, sharing knowledge (a.k.a self marketing), atau broadcast mood dia saat itu (a.k.a nonsense useless narsis)? Selama waktu luangnya dihabiskan facebookan dan twitteran narsis, ya jangan harap maju. Menunggu training yang disediakan perusahaan? Training Java yang bagus sulit dicari, bahkan walaupun perusahaan mau mentrainingkan kita, instruktur yang bagus itu sulit dicari. Apalagi di Indonesia, programmer yang bagus2 lebih suka coding daripada ngajar, karena bayarannya lebih bagus. Codingnya juga lebih suka di luar negeri (a.k.a TKI)

3. Lingkungan kerja.
Nah, kalo kita sudah mengurus diri sendiri di #2, #3 kita bisa menentukan. Pengalaman saya sih, perusahaan IT cenderung fleksibel. Asal kerjaan beres, jam kerja gak terlalu strict. Coba buktikan kalo kita deliver dengan baik, pas jam kerja ya kerja, jangan facebookan. Yang sering lembur itu kadang juga salahnya programmer sendiri, jam kerja facebookan, begitu mepet sore, baru coding. Ya jelas aja pulang malam.

Kesalahan kedua, salah estimate. Biasanya PM kan minta estimate dari programmer, kerjaan ini berapa lama. Nah, kitanya terlalu optimis, kerjaan 2 hari dibilang 1 hari, dihitung codingnya aja, testing dan bugfixing gak dihitung.Ya udah ditagih 1 hari sama PM nya, akhirnya pulang malam. Atau dari awal sudah bercita2 mau lembur, misalnya, udah tau kerjaan 12 jam, bilangnya sama PM selesai 1 hari. Nah ini kan namanya emang cari penyakit sendiri. 12 jam kalo mau hidup normal ya 2 x 6 jam, bukan 1 x 12 jam.

Kesalahan ketiga, codingnya gak bersih. Akhirnya bolak balik bug fixing. Cari gampang di awal, tapi jatuhnya jadi boros waktu bolak balik.

Kalo waktu kerja udah dimanfaatkan bener, estimate yang bagus, coding bersih, masih juga OT, ya pindah kerja aja. Programmer Java di Indonesia demandnya jauh lebih besar dari supply. Kalo masih ada yang sulit cari kerjaan, email saya, asal qualified besok langsung kerja. Company ngurusin kita, itu anggap aja bonus. Tapi kalo bercita2 diurusin company, itu namanya cari penyakit sendiri.

Nah itu dari sudut pandang karyawan, dulu saya juga karyawan. Gimana dengan company saya sendiri, ArtiVIsi?

1. Gaji.
Di sini kita gajinya kecil, tapi tiap termin project cair atau berita acara dittd client, kita kasi bonus yang signifikan, sering > gaji. Ini biar fair, kalo mau dapat uang ya deliver. Deliver banyak bug ya bonusnya tertunda karena client gak mau ttd berita acara UAT.

2. Pengembangan skill.
First of all, akses langsung ke saya. Mau tanya apa aja silahkan. Tiap kita pake teknologi baru, saya training, contohnya waktu kita migrasi ke Git, implement Maven, dsb. Pake teknologi lama tapi gak ngerti, misalnya Hibernate, ya tinggal telpon atau YM. Yang belum kuliah kita kuliahin, yang udah kuliah kita suruh kursus bahasa Inggris.

3. Lingkungan kerja.
Saya termasuk yang beraliran anti lembur, hidup seimbang. Kenapa gitu, soalnya kalo programmer capek, dia akan menambah bug, bukan menambah fitur. Cuma jadi kerjaan tambahan di belakang hari. Kita lembur juga kadang-kadang, tapi jarang, gak jadi lifestyle tiap minggu pasti ada lembur. Dalam sebulan belum tentu ada, kalopun ada paling 4-8 jam. Kalo sampe ada lembur, berarti PMnya kerja gak bener. Entah dia salah estimasi, atau dia overpromise ke client.

Ok, demikian sharing, kita tutup dengan iklan. Yang mau apply, langsung aja kirim email ke hrd@artivisi.com. Sertakan CV dan source code aplikasi yang pernah dibikin dalam bahasa apapun (gak mesti Java). Lebih diutamakan source codenya ada di Github atau Googlecode,menunjukkan bahwa Anda programmer gaul yang gak ketinggalan jaman.

Komentar dari Hendry Luk juga ga kalah bagusnya, cuma keadaan yang digambarkan beliau adalah suasana kerja di negara-negara maju seperti amerika, eropa dan australia. Singapura, Malaysia dan India termasuk “negara maju” dilihat dari industri ITnya, cuma kondisi kerjanya lebih baik dari di Indonesia tapi tidak sebaik yang digambarkan oleh Hendry Luk di bawah ini :

Jempol buat initiativenya! Memang susah kalo employer gak tau apa kondisi yang ngebuat lingkungan yg disukai employee. Ide yang sangat mulia buat go out dan nanya apa yang employee mau.

Tapi di laen sisi, banyak employees yang gak pernah ngerasain tempat kerja yang enak, dan mereka juga gak tau apa yang mereka mau minta. Biasanya mereka cuma bisa kasih saran2 yang ngambang dan cliche, semacam gaji-gede, manajemen yang baik, lingkungan kerja yang nyaman, etc etc, tanpa hal2 yang konkrit. Seorang employee mesti pernah ngerasain lingkungan kerja yang enak dulu sebelom bisa ngasih saran2 yang kongkrit.

Dan kadang lu bahkan bakal kaget bahwa yang membuat lingkungan kerja yang enak itu bukan hal2 yang “grand”, mewah, dan muluk2, tapi justru hal2 sepele & kecil2 ajah yang keseluruhan berkesan kuat dan ngasih kepribadian unik dari lingkungan tersebut.
Yang penting dari lingkungan nyaman justru bukanlah “materi”, tapi adalah lingkungan yang “highly cultured” dan berkepribadian, yg bikin lu ngerasa sebagai part of a small community. Bukan cuma sekedar employee yang bekerja untuk materi.

Gw coba kasih contoh2 hal2 konkrit dari pengalaman gw yang bikin gw ngerasa nyaman sebagai employee.. yang mungkin bisa lu terapkan.
1. Kulkas selalu penuh dengan boutique beers/champagne/wine/etc yang bisa lu comot any time (of course its politically inappropriate buat minum2 sebelom jam sore), dan selalu distock terus tiap Jumat (karna adanya point #3).
2. Dapur juga selalu tersedia snacks/breakfast etc, jadi kebanyakan employee sarapan-nya di kantor, dimana lu jadi saling randomly ketemu dengan satu sama laen, secara gak sadar ngejalin hubungan antar seluruh employees walopun berbeda teams/departments
3. Jumat, jam 4 adalah beer o’clock. Semua staff mesti pegang botol bir (ato other drinks). Ada sharing session tiap jumat, dimana semua orang berkumpul di satu ruangan ngelilingin sekeranjang bir, dan 1 orang (digilir tiap minggu) bakal ngebawain topik pilihan dia di projector (dan video-conference ke semua kantor2 cabang laen), ngebahas hal2 baru (framework, best-practices, trend, etc) yang menarik buat dishare ke anggota tim laen.
4. Jumat, setelah sharing session, semua ke dapur buat free friday meal (berkisar antara grilled meats, steak-pies, pasta, gourmet pizza, salad, etc). Semua staff berkumpul makan n minum bareng ngomongin hal2 yg gak berkaitan dengan kerjaan.
5. Tiap pagi/sore, team lu ada daily stand-up meeting. Benefit dari daily-meeting BUKAN semata2 kayak yg lu denger orang2 scrum (memantau progress/kendala project), tapi justru benefit yg gak related dengan project, melainkan social interaction. Meetingnya biasanya casual banget, penuh gosip, jokes, current affairs. Tempat meetingnya ganti2, kadang di luar, duduk di rumput, di sebelah kolam, ada yg sambil makan buah etc. Sering bawa2 maenan (sackballs, rubber ducks, etc) buat dilempar2/ditendang2 to each other. Layaknya any scrum-meeting, tiap member ngasih update ttg kegiatan terakhirnya, both dalam project dan (more importantly) *diluar kerja* (gosip, etc), dan giliran ngomong biasanya ditentukan dengan siapa yg lagi pegang bola. Kadang tiap team punya yel-yel yg khas buat mengakhiri meeting. Ini yang gw maksud saat gw mention “lingkungan kerja yang punya culture dan kepribadian khas”. Padahal ini bukan hal materi, tapi bikin lu ngerasa nyaman di dalam team.
6. Sewa tukang pijat tiap kemis, adalah ide yang bagus. Biasanya kemis gw paling males kerja, karna tinggal 1 hari lagi sebelom weekend. Tapi tukang pijat di kantor selalu jadi satu2nya alasan gw buat get up dari ranjang tiap kemis. Dan juga bagus buat kesehatan, terutama buat profesi kita yang kerjanya duduk terus.
7. Kulkas kantor yang penuh bir ironically justru sering malah jadi hal negatif buat kehidupan social di kantor, karna tiap orang jadi gak pernah lagi keluar bareng2 ke pub etc, karna kalo mo minum ya tinggal buka kulkas. Karna itulah tiap rebo malem adalah hari “going out”. Secara bergilir, 1 orang team member mesti menyelenggarakan kegiatan (dinner, bowling, piano bar, wall-climbing, etc). Kegiatannya TIDAK disponsor/didanai kantor.. Kantor gak ngasih apa2. Again, ini contoh hal yang gak materi, tapi adalah “culture” yang bikin team members merasa bagian dari sebuah family.
8. Ritual yang sering gw jumpai saat lunch time adalah trivia quiz (biasanya dari koran). Sepele tapi good fun, takes away pikiran lu dari kerjaan
9. Training allowance. Terutama buat ngedukung point #3 (sharing-session), dimana tiap employee berhak atas 150 jam training allowance tiap taon, yang bisa dipake buat ngebiayain seminar/conference/training, ato bahkan buat pake buat self-learning research2 hal2 baru di rumah ato di kantor, yang nantinya bisa lu share ke team member laen di sharing-session jumat depan.
10. Health-initiative program, dimana perusahaan ngasih allowance buat reimburse biaya lu yang mendukung active lifestyle lu di luar kantor, e.g. gym membership, sport-club, gears & equipment etc. Ini buat meng-encourage karyawan lu hidup aktif dan sehat. Tentunya ada limit bulanannya, jadi kalo lu beli sepeda ya reimbursenya dicicil across beberapa bulan.
11. Laundry. Jadi baju2 kotor tinggal buang ke keranjang, tiap minggu ada laundry yang dateng. Di indo sih mungkin gak terlalu bermanfaat mengingat tiap karyawan dah punya pembantu sendiri di rumah. Kantor juga nyediain kaos2 (berlogo company) yg lu bisa comot buat pake kerja (gak wajib tentunya), maupun kaos khusus buat yang nyepeda. Tentunya outfitnya mesti reasonably attractive supaya kita mau dan bangga pakenya.
12. Projects, budgets, quotes, costs, revenues, etc semuanya available “REAL-TIME” di intranet (diintegrasi dengan project-management system). Termasuk kontribusi perorangan kita sendiri. Jadi semuanya transparant, lu bisa liat project kita berapa duit, marginnya berapa, situasi project kita gimana financially, apakah kita dah keteteran, kontribusi kita berapa gede, etc. Jadi lu diperlakukan bukan sebagai buruh pekerja, melainkan parter terpenting yang menentukan sukses gagalnya financial company tersebut. Dan ini juga mendorong karyawan dengan attitude yang lebih mature karna bisa liat implikasi financial dari kesuksesan/kegagalan kita mendeliver project.
13. Beberapa company, umumnya yang technologically innovative (e.g. yang bikin algorithm buat 3D processing, ato engineering tool buat NASA dan military), salah satu bagian dari renumeration kita sebagai employe adalah berupa saham dan devident. Ini bikin karyawan bener2 memperhatikan situasi keuangan perusahan tersebut, karna mereka sendiri DIRECTLY benefit dari keuntungan financial companynya. Ini lebih effective buat menjaga inovasi mereka daripada mensegel komputer karyawan supaya gak bisa nyuri source-code keluar (apalagi saat resign).
14. Occasional social activity… jadi bbrp bulan sekali kita ngadain kegiatan (skii, wine-testing, sailing, etc). Kadang ada bbrp company yang narik voluntary fee per orang (e.g. $10 per bulan buat yang berminat), tapi biasanya companynya tetep mensponsor significant part dari biayanya.
15. Online sport-tipping competition, misalnya English premier league, antar pegawai dan families, yang berhadiah duit dan piala di akhir tiap seasonnya. Tiap participant bayar duit ke kompetisi ini, tapi company tetep nyuntik dana buat pump up the prize dan piala-nya, sehingga hadiahnya menantang dan kompetisinya lebih panas.
16. Christmas party! Sekali lagi.. Christmas party! Gw gak bisa stress this enough betapa pentingnya xmas party. Lu gak boleh punya company tanpa xmas party! Theme costume party, get away somewhere, sewa villa ato yatch etc. Gw pernah berapa kali dapet better offer dari job laen, tapi tiap kali gw abis celebrate xmas party (ato liat funny pics/videos dari xmas taon lalu), gw selalu gak pengen pindah, dan refuse the other offer. A memorable end-of-year party tuh punya enormous emotional meaning terhadap hubungan pegawai dan organisasi.
17. Non seriuos award nominations of the year adalah another good idea.. Biasanya saat xmas party. Kasih award buat non-seriuos achievements, e.g. “weirdest eating habbit 2011″, “quote of the year”, “biggest flirt”, etc yg dinominate oleh seluruh employee di akhir tahun, lengkap dengan piala/piagam yang mesti lu pajang sepanjang tahun berikutnya di atas meja
Tapi lagi2, lingkungan kerja yang nyaman itu cuma bisa dibentuk dari etika kerja karyawan yang tinggi. Management style yang relaxed dan “westernised” itu cuma bisa diterapkan pada pegawai yang punya attitude yang mature, motivated, bisa self-manage diri sendiri, creative, punya integrity tinggi, kepedulian terhadap perusahaan, professional, etc.Kadang2 kita sering lacking kualitas ini. Sering loath company sendiri, gak punya integrity, gampang disogok, cuma peduli kepentingan pribadi, gak professional, gak motivated (ato even peduli) buat push organisasi kita sesukses mungkin. etc. Team kayak gitu lebih cocok dengan management style yang authoritarian, dimana tiap pegawai mesti didikte satu persatu kerjaannya, tanpa kebebasan dan ruang buat kreatifitas.
Tapi seriously, gw pernah liat ada yg advertise jobs di forum sini yang ngasih banyak fasilitas, tapi malah ada yg komplain minta lebih baik fasilitasnya diuangkan ajah jadi salary. That’s not very smart!
Coba pikir..Packs of beers, kaos, makanan, laundry, yang biayanya borongan buat puluhan/ratusan employees, itu sebenernya works out murah banget each person… kalo budgetnya diuangkan jadi salary mah sama sekali gak worth a lot.
Fasilitas itu contributes more ke lingkungan yg nyaman for its money daripada salary.

Fantastis bukan suasana kerjanya? ingin tahu bagaimana suasana kerja seperti yang digambarkan Hendry Luk di bawa ke keadaan paling extreme enaknya? silahkan lihat suasanya “extreme enak” di kantornya google

Mulailah bermimpi bekerja di perusahaan ini, bangun portofolio yang bagus, belajar yang giat, bekerja yang keras dan jangan lupa mengasah bahasa inggris lisan dan tulisan, serta jangan lupa mendengarkan Indo Java Podcast episode 3, wawancara dengan Bramandia yang diterima sebagai pegawai google di googleplex.