[teknologia] Re: gontok2an
4. kalau programming, kecenderungannya trial and error. Programming itu biasanya pasti ada masalah. Solusinya? cari code snippet pake google, coba gabungkan dgn program, kalau jalan ayo teruskan, kalau gak jalan, coba cari lagi yg lain. Gak tau kenapa kecenderungannya kalau di depan komputer itu trial and error. Seolah2 tujuan itu hanya supaya program jalan. Apalagi kalau udah di kejar2 deadline. Ini lama-lama jadi seperti sebuah mitos, bahwa keberadaan Internet dan Google akan menyelesaikan semua masalah, termasuk masalah programming. Padahal, justru itu hanya salah satu faktor saja (dianggap sebagai infrastrukur). Kemudahan mencari informasi malah dapat menjerumuskan sehingga orang berpikir secara instant. Akhir dgn kecenderungan tadi, aku kehilangan kontrol sama codeku. And kemudian aku butuh bug tracking seperti fogbuzz nya joel on software. I don't really agree with bug tracking. Dengan bug tracking kelihatannya developer udah kehilangan kontrol (seolah2 ada ribuan bug). Akhirnya mulai lah bug development cycle. Bug tracking itu penting sekali karena programer tidak bisa mengingat semua bug di kepalanya. Catatan yang ada di dalam bug tracker juga pantas digunakan untuk merancang pengembangan ke arah masa depan. Dalam kasus open-source, bug tracker juga merangkap sebagai buku komunikasi karena patch, komentar, screenshot, dokumen tes, dan semacamnya bisa ditempelkan ke dalam bug tersebut sehingga tidak mudah hilang. Tapi realita adalah kita gak nulis OS sendiri, compiler sendiri. Belum lagi kebergantungan sama API (API programmer :). Kalau ada masalah sama API cuman bisa nangis. Ini mungkin menghasilkan bug. Untuk kasus ini, mungkin perlu bug tracking. Kalau belum betul-betul fatal, biasanya selalu ada workaround untuk problem semacam ini. Makanya terkadang bekerja dengan toolkit (Qt, GTK+, wxWidgets) lebih menguntungkan di sini karena banyak workaround untuk bug-bug dari layanan OS-nya sudah ditangani (tentu, selama toolkitnya sendiri tidak mengandung bug lain lagi). Contoh kasus favorit saya adalah listview control di Win32. Normalnya, kalau listview ini dibuang dari memori, akan ada message LVN_DELETEALLITEMS sehingga si program bisa juga menghapus data-data yang terkait dengan masing-masing item di listview tersebut. Menurut dokumentasi MSDN, setelah LVN_DELETEALLITEMS ini, tidak akan ada lagi message LVN_DELETEITEM (yang hanya menghapus satu item). Tetapi nyatanya dalam beberapa versi comctl32.dll, ada bug sehingga setelah mengirim LVN_DELETEALLITEMS, Windows masih mengirim LVN_DELETEITEM sehingga program bisa crash karena double deletion. Nah, untuk ngambil kontrol itu, makanya aku pilih gontok2an, pilih nulis dokumen detail, dan kalau bisa pilih nulis code di kertas bukan di computer. Ini kebalikan dari bug tracking, yaitu ngetrack gimana program jalan. Tidak sama karena bug tracker untuk (mayoritas) menyimpan bug-bug karena perilaku program tidak sesuai dengan implementasinya, bukan karena gagasan untuk implementasi (alias desain utama) yang salah. Menulis dan merancang desain di awal-awal hanya menentukan arah jalan yang dituju adalah benar, tetapi tidak tidak menjamin bahwa nanti tidak akan terjadi jatuh-bangun selama jalan tersebut dilewati. Lihat contoh bug listview di atas. Test Driven kelemahannya, hampir gak mungkin nulis semua test. Dan dengan test driven, sebenarnya kontrol udah kita kasih ke test code yg kita tulis. Kembali seperti yg dikatakan Djikstra bahwa test itu bagus untuk menemukan bug, tapi tidak bisa memastikan bahwa gak ada bug. Dia berpendapat bahwa sebaiknya programming itu di kembalikan ke math. Cuman gak terlalu ngerti maksudnya, apakah berarti lisp? :) Mungkin maksudnya menggunakan metoda formal untuk analisis programnya. Tentang regression test, memang tidak ada jaminan (dan memang tidak akan pernah ada) bahwa programnya bug-free. Tetapi tetap saja lebih baik ada test daripada tidak ada. Seperti sudah saya tulis, kelebihan regression test itu adalah karena otomatisasinya: sekali dijalankan, banyak test. Bandingkan kalau semuanya harus satu per satu. Let me admit again, i am fan of Djikstra. :) dia bisa nulis OS di kertas untuk suatu mesin, padahal mesinnya belum ada. Dan ketika mesinnya jadi, OS nya jalan perfectly. Tapi nggak semua orang seperti Djikstra :-P -- http://www.google.com/search?q=ariya+hidayatbtnI
[teknologia] Re: gontok2an
On Fri, Sep 23, 2005 at 06:38:44PM +0700, Andika Triwidada wrote: whoaaa, jangan-jangan Ronny adalah the infamous Polisi EYD yang sedang dicari-cari selama ini oleh Amal cs? ;) Hahaha... ampun pak. Bahasa Indonesia saya aja masih kacau mau jadi pulisi, hehe. Sumpah bukan saya, hehe. Ronny pgp7vlcrGFkER.pgp Description: PGP signature
[teknologia] Re: gontok2an
On 9/23/05, Andika Triwidada [EMAIL PROTECTED] wrote: whoaaa, jangan-jangan Ronny adalah the infamous Polisi EYD yang sedang dicari-cari selama ini oleh Amal cs? ;) lah bukannya pak Rektor sendiri pak? (sol) -- Bi[G] http://www.7sphere.com Y!:br4ind4m4ge Gmail:[EMAIL PROTECTED] http://blog.adypermadi.com http://www.adypermadi.com
[teknologia] Re: gontok2an
On 9/23/05, Ronny Haryanto [EMAIL PROTECTED] wrote: On Fri, Sep 23, 2005 at 11:47:08AM +0200, Ariya Hidayat wrote: Let me admit again, i am fan of Djikstra. :) dia bisa nulis OS di kertas untuk suatu mesin, padahal mesinnya belum ada. Dan ketika mesinnya jadi, OS nya jalan perfectly. Tapi nggak semua orang seperti Djikstra :-PSorry sakit pedantic saya lagi kumat :-)Kalo yg dimaksud ini http://en.wikipedia.org/wiki/Edsger_Dijkstra makanamanya Dijkstra, bukan Djikstra. iya, sorry2 .. mungkin aku kebawa2 eDjaan lama bahasa Indonesia. :) -- PakcikUnder Construction
[teknologia] Re: gontok2an
Pakcik wrote: penasaran dgn gontok2an. :) Pernah dengar test driven programming kan. gimana kalau kita kembangkan gontok2an driven programming? hehe ada yg berminat? :p anak sekolahan biasanya langsung gak terima nih, gak ada dibuku soalnya. :) aku lagi ada develope software. bukan kerjaan kantor sih. mungkin semacam experimental gitu. Tapi pendekatannya mungkin gontok2an driven programming ini. Jadi udah sekitar 2 bulan developmentnya. Tapi even 1 line code pun belum ada. Kita bekerja 2 orang. Jadi apa yg kita lakukan selama ini? Kita itu gontok2an dalam arti positif. Diskusi. Write it down on paper. Aku emang sengaja pilih cara ini. Gak mau coding sebelum semua jelas banget (detail). Tapi ada yg berpendapat, kalau begini terus kapan Codingnya? Hasilnya menurutku bagus. Apa hasilnya: 1. Roadmap. paling susah dapet roadmap ini. Tau versi 1.0 itu feature apa aja, versi 2.0 itu apa. dan seterusnya. Ini menuntut design scalable. 2. Functional spec dan technical spec. (Baca joel on software untuk tau bedanya). 3. Layering Architecture . (Kita itu udah bisa ngomong kita lagi bicarakan layer 1 kan?) Hasilnya bagus? Apa ya hasilnya? Dokumen berisi ide. He he he. Kalau dokumen itu dalam waktu panjang tidak jadi aplikasi juga maka sesungguhnya tidak bagus. Karena ini adalah penyakit klasik paralysis by analysis. Yang paling penting itu yg aku temukan, bahwa aku bukan jenius. Butuh orang lain untuk argue designku. Sering kejadian begini, Kok gak kepikir yah, iya juga yah. Padahal peerku itu cuman kuliah IT 1 tahun dan udah 2 tahun gak pernah ber-IT ria lagi. Sekurang2 pengalamannya peer kita, kalau diajak gontok2an(diskusi), sangat membantu. Pernah juga coba langsung coding. hasilnya bug semua. hehe mirip tulisan om rofiq ini http://blog.bujursangkar.net/post/227 Betul tapi ini cara yang dipakai MS untuk bikin Windows 3.1 dan Linus untuk bikin kernel Linux. Nah kita sudah tahu kan apa manfaat bug. Bug ada untuk dibunuh. :-D Pernah ikutin cara2 kuliahan, hasilnya boring. :P Kuliah saja sudah membosankan apalagi kerja pakai cara kuliahan.
[teknologia] Re: gontok2an
Pernah dengar test driven programming kan. gimana kalau kita kembangkan gontok2an driven programming? hehe ada yg berminat? :p anak sekolahan biasanya langsung gak terima nih, gak ada dibuku soalnya. :) Sulit dibandingkan. Kelebihan pendekatan test-driven itu adalah karena mekanisme tesnya dijalankan secara otomatis. Bila salah satu bagian program diubah, selama hasil tes totalnya tidak failed, maka bug diasumsikan belum muncul. Juga, karena fitur perlu dites, hal ini sedikit memaksa programer untuk mengimplementasikan fitur (dan interfacenya) sedemikian rupa sehingga dapat dites. Gontok-gontokan itu kan belum bisa dijalankan secara otomatis dan berulang-ulang. Kecuali memang nantinya tingkat kecerdasan buatan (AI) sudah semakin meyakinkan sehingga IDE nggak cuma dipakai mengedit, compile, debug, tapi juga gontok-gontokan :-P Bayangkan kalau Anda seenaknya sendiri membuat objek global lalu ditegur dan disuruh oleh KDevelop (atau Eclipse, atau Emacs, atau apa pun) untuk dijadikan singleton... -- http://www.google.com/search?q=ariya+hidayatbtnI
[teknologia] Re: gontok2an
On 9/22/05, Monang Setyawan [EMAIL PROTECTED] wrote: Jadi ingat kata dosen saya dulu : Semakin cepat kamu menyentuhkomputer (meninggalkan kertas dan pensil), semakin lama programmu akanselesai. :) let me admit it. actually, i hate computer. hehe .. ini kebiasaan ku kalau di depan computer: 1. baca email/mailing list 2. baca berita/blog 3. browsing2 4. kalau programming, kecenderungannya trial and error. Programming itu biasanya pasti ada masalah. Solusinya? cari code snippet pake google, coba gabungkan dgn program, kalau jalan ayo teruskan, kalau gak jalan, coba cari lagi yg lain. Gak tau kenapa kecenderungannya kalau di depan komputer itu trial and error. Seolah2 tujuan itu hanya supaya program jalan. Apalagi kalau udah di kejar2 deadline. Makanya aku penggemari quote2: Programs must be written for people to read, and only incidentally for machines to execute. Computer Science is not about computer Akhir dgn kecenderungan tadi, aku kehilangan kontrol sama codeku. And kemudian aku butuh bug tracking seperti fogbuzz nya joel on software. I don't really agree with bug tracking. Dengan bug tracking kelihatannya developer udah kehilangan kontrol (seolah2 ada ribuan bug). Akhirnya mulai lah bug development cycle. Tapi realita adalah kita gak nulis OS sendiri, compiler sendiri. Belum lagi kebergantungan sama API (API programmer :). Kalau ada masalah sama API cuman bisa nangis. Ini mungkin menghasilkan bug. Untuk kasus ini, mungkin perlu bug tracking. Nah, untuk ngambil kontrol itu, makanya aku pilih gontok2an, pilih nulis dokumen detail, dan kalau bisa pilih nulis code di kertas bukan di computer. Ini kebalikan dari bug tracking, yaitu ngetrack gimana program jalan. Test Driven kelemahannya, hampir gak mungkin nulis semua test. Dan dengan test driven, sebenarnya kontrol udah kita kasih ke test code yg kita tulis. Kembali seperti yg dikatakan Djikstra bahwa test itu bagus untuk menemukan bug, tapi tidak bisa memastikan bahwa gak ada bug. Dia berpendapat bahwa sebaiknya programming itu di kembalikan ke math. Cuman gak terlalu ngerti maksudnya, apakah berarti lisp? :) Let me admit again, i am fan of Djikstra. :) dia bisa nulis OS di kertas untuk suatu mesin, padahal mesinnya belum ada. Dan ketika mesinnya jadi, OS nya jalan perfectly. -- PakcikUnder Construction
[teknologia] Re: gontok2an
4. kalau programming, kecenderungannya trial and error. Programming itu biasanya pasti ada masalah. Solusinya? cari code snippet pake google, coba gabungkan dgn program, kalau jalan ayo teruskan, kalau gak jalan, coba cari lagi yg lain. Gak tau kenapa kecenderungannya kalau di depan komputer itu trial and error. Seolah2 tujuan itu hanya supaya program jalan. Apalagi kalau udah di kejar2 deadline. Programer levelnya macam2,ada yang kelas rt/rw sampai kelas Dunia, yang bedain berapa line of code dan permasalahn apa yang dicoba untuk di-tackle ? Is it leading edge problem or not ? Kalau mau coba hire programer world class,coba hire orang2 IIT, sebagian orang2 IIT ini bener2 bisa nulis code (misalnay untuk protocols) tanpa referensi :) Gua pernah denger joke kalau gak ada org2 dari IIT,there will be no India in Global Software Roadmap.Sampai ada karikaturnya lagi di Dilbert Comics. Makanya aku penggemari quote2: Programs must be written for people to read, and only incidentally for machines to execute. Computer Science is not about computer Pernah dengar quote ini ? At Startup,there is time to shoot the Engineer Akhir dgn kecenderungan tadi, aku kehilangan kontrol sama codeku. And kemudian aku butuh bug tracking seperti fogbuzz nya joel on software. I don't really agree with bug tracking. Dengan bug tracking kelihatannya developer udah kehilangan kontrol (seolah2 ada ribuan bug). Akhirnya mulai lah bug development cycle. Tapi realita adalah kita gak nulis OS sendiri, compiler sendiri. Belum Yang realistis,sampai sekarang masih susah untuk temukan developer yg tahu isi produk dari A-Z dan arsiktektur,etc...biasanya mereka cuman responsible/care dengan modul dan interkoneksi dengan modul lain. lagi kebergantungan sama API (API programmer :). Kalau ada masalah sama API cuman bisa nangis. Ini mungkin menghasilkan bug. Untuk kasus ini, mungkin perlu bug tracking. Bug Tracking itu satu komponen paling penting untuk persh/vendor/startup yang jual software apalagi networking box. Jaman sekrg kompleksitasnya beda. Bayangkan persh yg punya multiple products line,multiple software release,customer issues,QA Bugs,internal software issues,development team yang satu ada di US dan satunya lagi di India,etc ..untuk mecahin masalah ini memang state of the art dan gak bakal ketemu jawabanya di buku2 software classic.tantangan development jaman skrg jauh lebih rumit dibanding dulu. Anyway paling penting dalam software discipline sebenarnaya Code Review. Habis coding,kemudian harus dibikin code review antara software team lead dan developer.Setelah dicheck,code dicompile,masuk ke automation,dan kemudian codenya ditest lagi menggunakan 3rd party tools seperti Lint atau Coverity untuk checking standard programer error seperti null pointer,buffer overflow, freed/unfreed descriptor/memory blocks,etc ... Intinya: dalam realita,bug tracking,3rd party tools dan software discpline sama pentingnya. Carlos
[teknologia] Re: gontok2an
On 9/19/05, Patriawan, Carlos [EMAIL PROTECTED] wrote: Sebenarnya untuk produk roadmap,bukan orang teknis yang menentukan,tapi input dari orang Produk marketing yang lebih punya peran. Orang teknis cenderung lebih rancu...(contohnya debat mau pake OSnya vxworks atau bsd atau linux, codenya mau beli atau develop sendiri, asicnya mau beli atau develop sendiri, mau develop diatas C atau Java,hahahaha :) ) Istilahnya,80% waktu yang dipakai,harus digunakan untuk develop module yang making money,dan harus robust.Daripada bikin software dan waktu yg digunakan lebih banyak ke fancy stuffs,tapi gak sellable. Oh ya,version 1.0 itu memang penting banget,karena design arsitekturnya sangat mempengrahui development dan limitation kedepannya. Kalau pertanyaanya Kenapa orang Product Marketing ? Ini karena2 org2 ini tahu market intellegence,tahu customer maunya apa,tahu customer untuk software ini mereka mau bayar berapa,etc. Ini berlaku untuk sistem yang dikembangkan dan dipakai untuk keperluan internal juga? :D Bias kita jauh berlawanan ya? :D (I *hate* marketing.)
[teknologia] Re: gontok2an
Kalau pertanyaanya Kenapa orang Product Marketing ? Ini karena2 org2 ini tahu market intellegence,tahu customer maunya apa,tahu customer untuk software ini mereka mau bayar berapa,etc. Ini berlaku untuk sistem yang dikembangkan dan dipakai untuk keperluan internal juga? :D Tidak. ini gimana vendor develop produk sebenarnya. Hampir semua vendor yang saya tahu pola penentuan software roadmapnya ya begini. Bias kita jauh berlawanan ya? :D (I *hate* marketing.) Makanya sebagian produk IT karena gak memerhatikan market. Anyway orang Product Marketing sebenarnya orang2 Engineer juga yang terus pindah karir. Dan Jangan salah,orang2 PM ini seringkali orang2 yang nulis buku dan punya kontribusi di draft/RFC. Jadi level marketingnya beda dengan marketing di Indonesia. Carlos
[teknologia] Re: gontok2an
Pada tanggal 9/20/05, Nico Las [EMAIL PROTECTED] menulis: sori kalau semi oot, tapi si crichton kalau bikin novel kan risetnya cukup dalam, dan kalau sampai dia angkat penokohan cowok itu dan backgroundnya, pasti practice itu cukup sering terjadi di dunia IT, setidaknya di belahan dunia 'sana'. tema yang diangkat di filem itu soal kekuasaan, perempuan vs laki-laki, dengan quote-nya sexual harrasment is not about sex, it's about power balik kedunia nyata, gontok-gontokan sering terjadi karena kekuasaan juga, yang nyata adalah marketing vs engineering, sama-sama sering (tanpa sadar) saling melecehkan karena orang engineering sering ketiban pulung oleh ulah marketing, jadilah quote baru engineering harrasment is not about engineering, it's about money -- http://yulian.firdaus.or.id/
[teknologia] Re: gontok2an
On 9/18/05, Pakcik [EMAIL PROTECTED] wrote: penasaran dgn gontok2an. :) Pernah dengar test driven programming kan. gimana kalau kita kembangkan gontok2an driven programming? hehe ada yg berminat? :p anak sekolahan biasanya langsung gak terima nih, gak ada dibuku soalnya. :) aku lagi ada develope software. bukan kerjaan kantor sih. mungkin semacam experimental gitu. Tapi pendekatannya mungkin gontok2an driven programming ini. Jadi udah sekitar 2 bulan developmentnya. Tapi even 1 line code pun belum ada. Kita bekerja 2 orang. Jadi apa yg kita lakukan selama ini? Kita itu gontok2an dalam arti positif. Diskusi. Write it down on paper. Aku emang sengaja pilih cara ini. Gak mau coding sebelum semua jelas banget (detail). Tapi ada yg berpendapat, kalau begini terus kapan Codingnya? Hasilnya menurutku bagus. Apa hasilnya: 1. Roadmap. paling susah dapet roadmap ini. Tau versi 1.0 itu feature apa aja, versi 2.0 itu apa. dan seterusnya. Ini menuntut design scalable. Sebenarnya untuk produk roadmap,bukan orang teknis yang menentukan,tapi input dari orang Produk marketing yang lebih punya peran. Orang teknis cenderung lebih rancu...(contohnya debat mau pake OSnya vxworks atau bsd atau linux, codenya mau beli atau develop sendiri, asicnya mau beli atau develop sendiri, mau develop diatas C atau Java,hahahaha :) ) Istilahnya,80% waktu yang dipakai,harus digunakan untuk develop module yang making money,dan harus robust.Daripada bikin software dan waktu yg digunakan lebih banyak ke fancy stuffs,tapi gak sellable. Oh ya,version 1.0 itu memang penting banget,karena design arsitekturnya sangat mempengrahui development dan limitation kedepannya. Kalau pertanyaanya Kenapa orang Product Marketing ? Ini karena2 org2 ini tahu market intellegence,tahu customer maunya apa,tahu customer untuk software ini mereka mau bayar berapa,etc. 2. Functional spec dan technical spec. (Baca joel on software untuk tau bedanya). 3. Layering Architecture . (Kita itu udah bisa ngomong kita lagi bicarakan layer 1 kan?) Yang paling penting itu yg aku temukan, bahwa aku bukan jenius. Butuh orang lain untuk argue designku. Sering kejadian begini, Kok gak kepikir yah, iya juga yah. Padahal peerku itu cuman kuliah IT 1 tahun dan udah 2 tahun gak pernah ber-IT ria lagi. Sekurang2 pengalamannya peer kita, kalau diajak gontok2an(diskusi), sangat membantu. Untuk ini sebaiknya kudu kerja di Valley (biar puas banget sama yang kayak beginian),argumentasi di software war room memang paling hangat dan gua paling demen disitu,soalnya kebanyakan developer main implmentasi asal cepet aja,tapi gak mikirin interkoneksi dengan module lain.jadi bisa disikat kalau ada yang ngeyel dan schedulenya gak realistis. Carlos
[teknologia] Re: gontok2an
On 9/19/05, Patriawan, Carlos [EMAIL PROTECTED] wrote: Untuk ini sebaiknya kudu kerja di Valley (biar puas banget sama yangkayak beginian),argumentasi di software war room memang paling hangatdan gua paling demen disitu,soalnya kebanyakan developer mainimplmentasi asal cepet aja,tapi gak mikirin interkoneksi dengan modulelain.jadi bisa disikat kalau ada yang ngeyel dan schedulenya gak realistis. Ada temen pernah ngasih 'rahasia' kenapa dulu itu Microsoft bisa 'berjaya' and be way-ahead the other. It's because it's modularity in developing it's application. Terserah modulnya dibikin oleh siapa or pakai tool apa, yang penting modul tsb interfacingnya jelas. Inputnya apa, outputnya apa. Begitu jadi, intergrate and then sell it!! It may be a quick and dirty solution. Soalnya kalau mau menunggu sebuah software itu 'jadi' dan 'sempurna', bisa jadi nggak jualan... Selain itu, dengan dibikin modular, programmer jadi terpecah belah. It will be difficult to the programmers to know the big picture, yang bisa jadi merupakan rahasia perusahaan. FYI, that friend of mine, end up ONLY doing bezier planes for drawing icons. Doing that. Only. For months. So he quits :p Nggak tau deh apa sekarang Microsoft masih begitu. Nggak tau juga apa sekarang lawan Microsoft juga ada yang ikut-ikut menjalankan cara itu. -ivo
