[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] Dicari RF Engineer.
Ada yang mau melamar? -- budi -- Forwarded message -- From: Prasetyo Yudono [EMAIL PROTECTED] Date: Sep 22, 2005 8:51 AM Subject: re: RF Engineer. To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Pak Budi, Yth. Terimakasih sebelumnya atas kesediaan-nya membantu mencarikan candidate untuk RF Manager. Yang mencari ini sebuah persh telkom dari Singapore untuk ditempatkan di Jakarta mengelola project-projectnya di area Jawa Barat (saat ini) dan Sumatera. Kalau ada yang berminat CV-nya bisa diforward ke kami, agar bisa langsung kami akan hubungi. Informasi mengenai perusahaan dan posisi yang dicari secara singkat kami sarikan di bawah ini. Sekali lagi terimakasih. Salam, Pras --- A Telecomunication company provides mobile engineering services and solutions to mobile network equipment vendors, mobile network operators and service providers. Our services and solutions include the planning, designing and building of mobile networks, enhancing the coverage and performance of existing mobile networks and assisting in the migration to 3G networks. RF Manager Responsibilities . To manage a team of RF specialists which provide on site survey for In-building and Out-door RF measurement, coverage survey and planning, distribution design and link budget calculation, parameter setting, network optimization and performance measurement . To provide technical management for network rollout and also build the competency internally for new technology . To interface between internal Account team and project organization and customer interface on project schedule and deliverables' quality Pre-Requisites: . Diploma/ Degree in Electronics/Electrical/Telecommunications . Experience in large scale Cellular network rollout is a must . Familiar with In Building distribution business model . Basic knowledge of Transmission networks and solutions . Good interpersonal skills and ability to work with people of different cultures and background . Technology specific knowledge (IDEN, WiFi, Bluetooth, Tetra, GSM, CDMA, WCDMA, CDMA2000). GSM knowledge is a must. From: Mico Wendy [EMAIL PROTECTED] Sent: Wednesday, September 21, 2005 2:09 AM To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RF Engineer. Dengan hormat Pak Budi Rahardjo, Ini mico yang tadi telpon... Kenalkan rekan saya Pak Prasetyo Yudono dari Talentis. Pak Pras ini yang sedang mencari SDM setingkat manager di bagian RF yang kira-kira sudah mempunyai pengalaman 5-10 tahun. Untuk spesifikasi kompetensi yang diharapkan tadi pak Budi minta lebih detail. mungkin Pak Pras bisa langsung email ke beliau Terima kasih sebelumnya. ps. sorry email ini kelihatannya minggu lalu tidak sampai... Salam, Mico Wendy [EMAIL PROTECTED] yahoo: micowendy, icq: 1384769, msn: micowendy PT Konsep Dot Net - www.konsep.net Turning Concept into Reality Web Programming - Software Development - ERP
