Situasi ini nampaknya dimanfaatkan oleh perusahaan pengembang software raksasa, Adobe, untuk mempromosikan produk mereka. Baru-baru ini Adobe memberikan secara cuma-cuma salah satu software andalan mereka, Adobe Flex Builder, khusus untuk programmer yang terkena PHK. ????? ??????? ????????? ????? ??????? ???????

Seperti sudah diduga, software ini cuma boleh digunakan untuk keperluan pribadi, bukan komersil, dan hanya untuk meningkatkan skill saja. Tidak boleh di-copy atau diberikan kepada orang lain termasuk perusahaan yang kelak mempekerjakannya.

Ironis juga sih, mengingat Adobe termasuk perusahaan yang merumahkan 600 orang karyawannya akibat krisis. Dan bisa jadi beberapa diantaranya adalah programmer yang membuat Adobe Flex Builder. ?????? ?????? ?????? ????????????? ???????? ??? ??????????? ????????? ?????? ??? ?????? ????? ???????? ????????

???????? ???? ??????

Saya setuju dengan tulisan Jeff Atwood ini. Penggunaan bahasa Inggris dalam pemrograman bukanlah persoalan Nasionalisme atau niat jahat untuk mendominasi dunia. Saya juga meragukan kalau itu dikarenakan umumnya bahasa pemrograman dibuat oleh orang Amerika, karena Python dibuat oleh Guido van Rossum yang notabene berkebangsaan Belanda.

Sebagaimana persoalan teknis lainnya, penggunaan bahasa Inggris adalah semata-mata kesepakatan kolektif dari programmer untuk berkolaborasi diantara mereka. Mungkin seperti bahasa latin yang dulu digunakan dalam sains. Sementara kita, yang tidak terlibat sejak awal bahasa pemrograman komputer dibuat, tidak ada pilihan lain kecuali mengikutinya.

Pilihan untuk menggunakan bahasa Inggris dalam pemrograman adalah satu paket dengan pilihan bahasa pemrograman yang akan kita gunakan. Dan terus terang, pilihan untuk tidak menggunakan bahasa Inggris tidak begitu populer. Kecuali Anda bisa membuat program sendiri tanpa perlu berkonsultasi dengan orang lain, sebaiknya hanya gunakan bahasa pemrograman yang populer dan dalam bahasa Inggris. Google pun akan lebih banyak membantu jika solusi yang anda cari ditulis dalam bahasa Inggris.

???? ????? ??????? ? ?????????

Maka tidak heran, kalau keterbatasan skill programmer biasanya berbanding lurus dengan keterbatasannya dalam berbahasa Inggris. Setidaknya kemampuan dalam membaca dan memahami tulisan dalam bahasa Inggris.

Oleh sebab itu, saya selalu menyarankan kepada mereka yang baru belajar untuk hanya menggunakan buku-buku pemrograman yang ditulis dalam bahasa Inggris. Atau membaca dokumentasi, tutorial atau artikel dalam bahasa Inggris saja. Karena menurut saya, lebih mudah bagi kita untuk mengartikan istilah dalam bahasa Inggris ke bahasa Indonesia dari pada sebaliknya. Mereka yang terbiasa menggunakan istilah dalam bahasa Inggris akan lebih cepat faham ketika harus membaca terjemahannya dalam bahasa Indonesia.

Mungkin ini karena kebanyakan buku terjemahan tidak begitu akurat dalam menterjemahkan. Atau terlalu brutal dalam menterjemahkan, sehingga istilah-istilah dalam bahasa Inggris yang sudah umum digunakan ikut juga diterjemahkan ke dalam bahasa Indonesia yang tidak baku. Kadang istilah yang sama diartikan berbeda tiap buku. Saya sendiri, ketika membaca artikel atau tutorial dalam bahasa Indonesia, harus menterjemahkan ke bahasa Inggris terlebih dulu di kepala untuk bisa memahami maksudnya. True story.

Ini bukan berarti kita tidak butuh buku-buku dalam bahasa Indonesia. Untuk mereka yang sama sekali baru, pengantar dalam bahasa Indonesia bisa sangat membantu untuk memberi gambaran kenapa mereka harus menggunakan bahasa pemrograman tertentu. Untuk kemudian diajak lebih jauh mempelajari bahasa pemrograman tersebut dalam bahasa aslinya, bahasa Inggris. Caranya bisa dengan menyertakan referensi aslinya atau membiarkan istilah-istilah pemrograman yang sudah umum tetap dalam bahasa Inggris. ????? ???? ???????????? ??? ??????????? ??a?a?? ??????a ???a ?????

• ????? ?????? ?????

Akhirnya saya bisa nonton juga film ini. Film drama komedi tahun 1948 yang dibintangi Cary Grant dan Myrna Loy ini disebut-sebut oleh Douglas Crockford ketika berbicara tentang kualitas software. Menurut Crockford, membangun sebuah software itu seperti membangun rumah. Perlu perencanaan yang matang, teknologi/tools yang tepat dan skill yang baik dari para pekerjanya.

Sebab kalau tidak, kita akan bernasib sama seperti keluarga Mr. Blandings di film ini. Mereka harus menempati rumah impiannya dalam keadaan setengah jadi (waktu penyelesaian lebih lama dari yang direncanakan) sementara dana mereka sudah habis untuk keperluan yang tidak terpikirkan sebelumnya (over budget).

Link:
Mr. Blandings Builds His Dream House – IMDB
Mr. Blandings Builds His Dream House – Wikipedia

The next time you’re knee deep in arcane language geekery, remember this: nobody cares what your code looks like. Except for us programmers. Yes, well-factored code written in a modern language is a laudable goal. But perhaps we should also focus a bit more on things the customer will see and care about, and less on the things they never will.

Di sini saya tidak setuju.

Memang benar, klien tidak pernah peduli dengan kode yang kita tulis. Yang penting bagi mereka adalah program yang kita buat jalan dan sesuai dengan yang mereka inginkan.

Hanya saja, kode yang amburadul akan sulit untuk dikembangkan dan dipelihara. Penulis aslinya pun pasti mengalami kesulitan ketika harus menambahkan atau memperbaiki programnya.

Padahal, tidak ada program yang dibuat sekali jadi. Akan selalu ada perbaikan, penambahan atau pengurangan fitur. Selalu ada versi 2, 3 dan seterusnya. Bahkan bisa dipastikan, program yang cuma ada versi 1 bukanlah program yang bagus karena mungkin tidak ada yang menggunakan.

Selain itu, program yang kompleks lazimnya butuh lebih dari satu programmer untuk mengerjakannya. Dalam kasus seperti ini, kode yang kita tulis harus bisa dibaca dan dimengerti oleh programmer lain, cuma kebetulan saja mesti dieksekusi komputer. Maka biasanya dibuat standar penulisan program yang disepakati (coding standards). Anda akan dimaki-maki programmer lain kalau kode yang anda tulis acak-acakan.

Dengan kata lain, cara penulisan program bukan sekedar kebiasaan atau gaya tiap programmer, tapi justru sangat mempengaruhi program yang dihasilkan. Dari pengalaman, bugs yang saya temukan biasanya muncul dari kode yang ditulis secara sembrono, asal jadi dan tidak sesuai standar.

Jadi pendapat bahwa “tidak ada yang peduli dengan kode yang anda tulis selama programnya jalan” sebenarnya tidak ada faktanya. Ide seperti ini umumnya muncul dari mereka yang lebih mementingkan “kualitas” daripada “kesehatan” program.

Saya setuju dengan Kent Back bahwa program yang “sehat” jauh lebih penting dan berharga dari program yang “berkualitas”. Karena “kualitas” adalah ukuran instan (instantaneous measure) yang cenderung menipu.

Program yang mengidap kangker akut yang penuh dengan bugs di dalamnya biasanya tampak jalan dengan baik dan terlihat berkualitas dari luar. Tapi jika anda tahu dalamnya, saya yakin anda tidak akan menggunakannya.

Program yang “sehat” sebaliknya, mungkin tidak memiliki banyak fitur. Tapi semua fitur yang ada adalah yang benar-benar dibutuhkan user dan 99,99% bugs free. Kodenya yang rapih dan terdokumentasi dengan baik sangat mudah untuk dikembangkan dan dipelihara.

Program seperti ini akan selalu dinamis untuk memenuhi kebutuhan klien yang berbeda-beda tanpa harus merombak habis-habisan kode yang sudah ada atau memunculkan bugs baru.

Currently, we’re on the final phase of this project. With so limited resources for this big project, i must say that we’ve been doing pretty well. What bothered me is whether i have done the right way managing my team.

Then i found this short article today, and i’m relief. Because that’s exactly what i’ve said to my team.

Many of you use Wordpress as blogging platform, but only view of you might know who's the guy behind this popular web apps.

Matt Mullenweg is the founding developer of Wordpress. He is a young talented developer lives in San Fransisco, California. He writes a nice blog at photomatt.net which i believe the first wordpress blog in the world.

Edgework's Brian Oberkich talked to Matt in 49:30 minutes interview. You should listen to this. Matt talked about Wordpress, Akismet and the zen of web product development.

As many other open source project leader, Matt is a nice and wise guy. He knows very well how to manage team of developers, how and when to deliver product to the end users, including take an action of any feedback from them.

There's a part on that inteview where he shared a funny story behind Akismet, anti spam system for blogosphere. Some time before he released Akismet to public, his mom gave him a visit to San Fransisco and lived with him for five weeks. Until at certain point when she decided to make a blog of her own.

Worrying his mom would also get spams offering porn site and would think this as what her son's doing all the time, Matt pushed Akismet's team to make a release version as soon as possible.

Alright, i’m going to reveal some of my dark secrets. I can’t go through a day without doing certain things. Two of them are reading feeds and SVN updating using my Tortoise SVN .

Reading feeds might be a common activity for most people now. But checking out SVN repository? i don’t think so, especially when you’re not involved in the project.

But i’m telling you, it is a good thing to do for a developer. Following everything that happens in your favourite project’s repository can give you a clue whether it is actively developed or just an empty house that has been abandoned.

For example, i can easily know that projects like Zend Framework or Dojo Toolkit are still actively developed. While project like Ngeblog has been practically dead, since there’s no activity for the last four months.

Sorry guys, i have to stop Ngeblog for now on, since i don’t have much time to maintain it. But don’t worry, there is Zend_Gdata that has similar feature and even more. And since version 0.7.0, Zend_Gdata has been moved into ZF core.

I also have signed Zend CLA last december to submit some of Ngeblog code to them (Client Login authentication). So officially, i am one of ZF developer now. Although there’s no single code i submitted yet till now. Arrgh, still got so many work to do in my daily job.

Anyway, back to SVN. For some projects like Dojo or ZF, getting files by SVN gives you more than by downloading the release package through their website. Dojo for example, gives you buldtools and test utility that i think it’s pretty useful.

The other advantage, of course, you’re always be the first to know the upcoming release. But you should beware, there’s always chances to any updating or even deleting some files in its repository. So keep your local files updated.

But then i decided to change it to “My Perfect PHP Framework”, not because i was affraid of people would criticize me, but because i realized this is the appropriate way of judging PHP framework. There is no such thing as “perfect” framework, for a reason i’ll describe.

So, my perfect PHP framework obviously not pointing out the name, instead the idea or guidelines if you want. But that doesn’t mean i never tried one, i tried many of them as you can see here,

Now, what is my perfect PHP framework? here you go ..

1. MVC wise
   I don’t have any problem with MVC. From programming perspective the idea of isolating UI from domain logic is a great thing. However, if implementing MVC means bringing along like thousands scripts we don’t need, that seems too much for me. So perfect PHP framework must follow YAGNI principle and give user the option to use MVC feature or not.
2. Loosely coupled components
   If you were like me, many web application i made are not too complicated. So i need to be able to chop out some components to use it independently without having to bring along bunch of scripts i don’t need. Most of PHP frameworks today are like this, so that’s great.
3. Designer friendly
   As in its definition, framework should be allowing designers and programmers to work together. My experience working with web designers is they don’t want to know about the codes i make. They don’t even want to see the HTML source. They use Dreamweaver or Firework. So good PHP framework must use templating system or at least allowing user to implement templating system, so that designers and programmers can work without interrupting each other.
4. Few lines to implement
   My definition about productive programmer is not in lines of code, but how many web apps you could deliver. That’s why i like PHP. So PHP framework should keep it that way.
5. PHP4 Enable
   Call me old fashion, but it’s true, many web hosting out there still use PHP4. So PHP Framework should be able to run on PHP4, or at least they includes some additional scripts to cover functional that doesn’t exist in PHP4.

Well, which one then? As i said before, i don’t use one framework, instead i use many pieces of framework. I use Zend Framework and my old friend PEAR for many of its neat features, and cakePHP for cool MVC, Xajax for AJAX, plus my own templating system which i felt more appropriate for my needs, especially to deal with my co-worker in web design.

So, my point is that’s what makes PHP interesting. As the jokesaid,

PHP
You shoot yourself in the foot with a gun made with pieces from 300 other guns.

Let’s keep it that way, shall we.

Tulisan singkat ini saya tujukan untuk anda yang tengah atau akan mempekerjakan programmer, yang berurusan dengan programmer, yang ingin jadi programmer dan tentu saja yang benar-benar ingin ditinju programmer.

Masih tertarik? Baiklah, berikut cara-cara jitu yang bisa anda lakukan,

1. Manuver “cuma sedikit kok”
   Biarpun programmer rata-rata menghabiskan 120% waktunya di depan komputer, mereka juga manusia seperti anda. Ini mungkin mengejutkan bagi beberapa orang. Tapi percayalah, itu benar. Jam biologis programmer sama dengan manusia lainnya.

   Jadi ketika anda bilang “Tolong diperbaiki ya, cuma sedikit kok.” padahal normalnya dibutuhkan waktu dua bulan untuk mengerjakan itu, anda termasuk beruntung kalau tidak mendapat tinju.

2. Teknik “satu lagi mas”
   Ada yang bilang rata-rata programmer lemah dalam matematika. Saya sama sekali tidak setuju. Kalaupun itu benar, programmer bukanlah orang bodoh sampai berhitung saja tidak bisa.

   Jadi kalu anda mengatakan “satu lagi nih mas” padahal ada dua ratus lebih komponen yang mesti dikerjakan, anda memang layak dapat tinju.

3. Sindiran “masih banyak bugs”
   Programmer biasanya sangat sensitif dengan bugs. Seperti artis sinetron yang sangat sensitif dengan berat badan.

   Coba saja anda katakan “program anda ini banyak bugsnya” kemudian pergi begitu saja. Siap-siap dihajar dari belakang.

4. Trik “mudah kok”
   Lagi-lagi pelecehan terhadap programmer. Bahwa programmer itu bodoh dan mudah dibodohi. Mereka sering dipuji-puji untuk diperas tenaganya.

   “Ah, untuk programmer sehebat anda pastinya mudah. Tolong ya, buatkan search engine seperti Google dan Yahoo!”

   Kalau memang anda lebih tahu, pasti anda mengerjakan sendiri tanpa menyewa programmer. Jadi jangan bilang ini mudah itu mudah. Kami programmer yang lebih tahu. Kami yang menentukan mana yang mudah dan mana yang sulit.

   Tuh, baru nulis saja saya sudah emosi, apalagi kalau ada yang benar-benar mengatakannya di depan saya.

5. “berapa duit, bang?”
   Anda harus tahu, programmer memang perlu uang untuk hidup. Namun uang bukan motivasi mereka. Tapi kegemaran (fun) itu yang jadi alasan programmer hebat yang saya kenal.

   Jadi tolong jangan samakan programmer dengan pekerja seks pinggir jalan yang siap memuaskan anda dengan bayaran murah.

   Kalaupun programmer tertarik dengan uang, mereka tertarik dengan uang dalam jumlah besar. Kalau anda menawarkan 500 ribu rupiah untuk membuat website perusahaan anda, kami bisa beri 2 juta untuk membuat anda pergi dari hadapan kami, plus sekepal bogem mentah.

Sepertinya mydreamapp.com akan menjadi website yang sering saya kunjungi berikutnya. Bukan karena saya salah satu kontestan di sana, tapi karena mengikuti proses transformasi ide menjadi sebuah aplikasi nyata adalah sangat menyenangkan. Siapa tahu saya menjadi saksi hidup dari proses revolusi sebuah aplikasi yang akan booming dalam dua atau tiga tahun mendatang.

Mungkin itu yang menarik dari mydreamapp.com. Dunia seringkali terlewatkan merekam sebuah revolusi yang terjadi di sekitarnya. Kita baru terkagum-kagum mendengar kisah bagaimana revolusi itu dimulai setelah 5 atau 10 tahun berikutnya. Diantara kisah tersebut yang jadi favorit saya adalah bagaimana Steve Wozniak dan Steve Jobs ketika memulai cikal bakal Apple dari sebuah garasi kecil di rumah orang tua Wozniak di California dengan dana dan perangkat seadanya.

Kalau ada orang yang berusaha keras merekam revolusi yang tengah terjadi saat ini, itu adalah Tim O’reilly. Dia menyebutnya dengan “alpha geeks“. Yaitu usaha untuk mencari tahu apa yang sedang dikerjakan para geek saat ini yang tidak banyak diketahui orang tapi bisa jadi booming dalam 2 atau 3 tahun ke depan. Dia yakin bahwa masa depan sudah ada di tengah-tengah kita, hanya saja belum terdistribusi dengan baik (The future is here, only it’s not distributed yet).

Mydreamapp.com mungkin akan mempermudah kerja Tim. Karena ide-ide itu ditampilkan secara terbuka, bahkan diperlombakan. Dan semua orang bisa menentukan mana ide yang paling menarik sekaligus mengeliminasi ide-ide lainnya lewat polling.

Namun mekanisme semacam ini memunculkan persoalan lain. Karena fakta menunjukan bahwa kebanyakan aplikasi yang populer saat ini justru berasal dari ketidakpopuleran. Kisah Wozniak dan Jobs di atas adalah salah satu contohnya.

Hal ini bukannya tidak beralasan. Paul Graham menjelaskan dengan baik sekali mengapa aplikasi hebat itu seringkali berasal dari ide yang tidak populer.

One reason so many good ideas come from the margin is simply that there’s so much of it. There have to be more outsiders than insiders, if insider means anything. If the number of outsiders is huge it will always seem as if a lot of ideas come from them, even if few do per capita. But I think there’s more going on than this. There are real disadvantages to being an insider, and in some kinds of work they can outweigh the advantages.

Imagine, for example, what would happen if the government decided to commission someone to write an official Great American Novel. First there’d be a huge ideological squabble over who to choose. Most of the best writers would be excluded for having offended one side or the other. Of the remainder, the smart ones would refuse such a job, leaving only a few with the wrong sort of ambition. The committee would choose one at the height of his career– that is, someone whose best work was behind him– and hand over the project with copious free advice about how the book should show in positive terms the strength and diversity of the American people, etc, etc.

The unfortunate writer would then sit down to work with a huge weight of expectation on his shoulders. Not wanting to blow such a public commission, he’d play it safe. This book had better command respect, and the way to ensure that would be to make it a tragedy. Audiences have to be enticed to laugh, but if you kill people they feel obliged to take you seriously. As everyone knows, America plus tragedy equals the Civil War, so that’s what it would have to be about. Better stick to the standard cartoon version that the Civil War was about slavery; people would be confused otherwise; plus you can show a lot of strength and diversity. When finally completed twelve years later, the book would be a 900-page pastiche of existing popular novels– roughly Gone with the Wind plus Roots. But its bulk and celebrity would make it a bestseller for a few months, until blown out of the water by a talk-show host’s autobiography. The book would be made into a movie and thereupon forgotten, except by the more waspish sort of reviewers, among whom it would be a byword for bogusness like Milli Vanilli or Battlefield Earth.

Tentu ini tidak bisa dijadikan standar untuk mengetahui apakah ide itu bagus atau tidak, yaitu dari ketidakpopulerannya. Karena ada juga aplikasi hebat yang sejak awal sudah dikenal banyak orang. Google misalnya merupakan proyek penelitan Larry Page dan Sergey Brin untuk meraih gelar Ph.D. di Universitas Stanford, California. Sistem pencariannya kemudian diterapkan di Universitas tersebut dengan menempati sub domain google.standford.edu.

Hanya saja menurut saya ide itu bukanlah sesuatu yang dapat kita putuskan bagus atau tidak dari sekedar keberadaannya. Karena orang tidak menggunakan ide, namun orang menggunakan implementasi dari ide tersebut. Orang baru akan memutuskan ide itu bagus setelah merasa puas dengan implementasi ide tersebut.

Kita tidak akan mengaggumi kegigihan Woz dan Jobs dalam mewujudkan impian mereka tentang PC (dulu komputer cuma berbentuk mainframe yang sangat mahal dan tidak semua orang bisa memilikinya) sampai setelah kita benar-benar melihat dan memakai Apple. Google pun hanya akan menempati rak-rak perpustakaan yang cuma diketahui mahasiswa Standford saja jika Google tidak banyak dipakai orang seperti sekarang.

Di sinilah ide untuk membuat kompetisi ide terbaik menjadi terdengar sangat aneh. Sama anehnya dengan kalau ada orang yang mengadakan perlombaan membuat resep masakan.

Namun begitu, saya tetap akan sering mengunjungi mydreamapp.com. Bukan untuk mengetahui ide siapa yang akhirnya jadi pemenang, tapi untuk mengetahui ide-ide seluruh kontestan, termasuk (dan terutama) ide dari mereka yang tereliminasi sejak awal perlombaan.

Siapa tahu drama penolakan ide Wozniak untuk membuatkan PC bagi rekan-rekan kerjanya di Hewlett-Packard terulang kembali. Dan seperti kita tahu, justru penolakan itulah yang kemudian melahirkan Apple.