Month: January 2013

Delapan ‘Dosa’ Geek yang Mengerikan – Part 2

Hello fellas! 😀

Setelah molor beberapa hari ga bisa nge-blog karena ada beberapa urusan, dan mengingat besok adalah kuliah Sistem Terdistribusi, mau tak mau saya harus menyelsaikan bacaan saya hari ini. Sekalian baca, sekalian saya share di blog, mungkin ada yang tertarik mau membacanya 🙂

Post ini merupakan kelanjutan dari post sebelumnya.

3. Bandwidth is infinite

Ada dua hal yang membuat bandwidth menjadi sebuah fallacy. 

– Ketika bandwidth bertambah besar, jumlah informasi yang masuk bandwidth tersebut akan semakin besar juga. Infrastruktur jaringan hari ini apabila dibandingkan dengan lima tahun lalu, tentu saja memperlihatkan penambahan kualitas bandwidth yang signifikan. Namun, begitu juga dengan kemajuan Web. UI semakin ‘kaya’, video buffering bukanlah sesuatu yang sulit lagi, yang intinya konten pun semakin rakus akan data.

– Packet loss. Secara gampangnya, ketika anda melakukan transfer file melalui LAN pada jaringan kecil, kemungkinan terjadi packet loss tentulah sangat kecil. Namun, bayangkan ketika anda menggunakan WAN, chance untuk packet loss tentu akan semakin besar! Solusi yang bisa dilakukan adalah memperbesar ukuran paket. Untuk lebi jelas nya saya akan mengutip kutipan yang dikutip oleh paper tersebut.

Let’s take an example: New York to Los Angeles. Round Trip Time (rtt) is about 40 msec, and let’s say packet loss is 0.1% (0.001). With an MTU of 1500 bytes (MSS of 1460), TCP throughput will have an upper bound of about 6.5 Mbps! And no, that is not a window size limitation, but rather one based on TCP’s ability to detect and recover from congestion (loss). With 9000 byte frames, TCP throughput could reach about 40 Mbps.
Or let’s look at that example in terms of packet loss rates. Same round trip time, but let’s say we want to achieve a throughput of 500 Mbps (half a “gigabit”). To do that with 9000 byte frames, we would need a packet loss rate of no more than 1×10^-5. With 1500 byte frames, the required packet loss rate is down to
2.8×10^-7! While the jumbo frame is only 6 times larger, it allows us the same throughput in the face of 36 times more packet loss.” [WareOnEarth]

Intinya sih bandwidth di luar batas kuasa kita. Pintar-pintar saja mengatur seberapa banyak yang yang kira-kira akan dikirimkan. Ada baiknya mencoba mensimulasikan aplikasi / sistem yang dibuat dengan environment yang ada.

4. The Network is Secure

Dari judulnya sudah keliatan kan 😀 Saya jadi ingin share pengalaman saya mengikuti salah satu seminar dari perusahaan multi-nasional. Salah satu sesinya, Sang Techincal Evangelist salah satu produk mempresentasikan produknya yaitu sebuah platform berbasis awan alias cloud computing platform. Beliau bercerita tentang keunggulan produk itu dibandingkan kompetitornya, memperlihatkan sekian banyak sertifikasi yang sudah dicapai oleh produk tersebut. Ketika sesi tanya jawab, salah seorang peserta seminar bertanya

Pak, bagiamana jaminan keamanan data saya yang disimpan disana?

Sang Techincal Evangelist menjawab pertanyaan tersebut dengan peryataan bahwa tidak sembarang orang yang bekerja di perusahaan tersebut dapat masuk ke ruang server lalu nyolok flashdisk seenaknya dan mengambil data. Dijelaskan juga sekali lagi bahwa produk tersebut telah lulus berbagai macam sertifikasi. Namun, kalimat terakhirnya yang membuat saya cukup terkejut adalah

Namun, kami tidak bisa menjamin 100% data anda aman di sana. Toh, jangankan kami, CIA yang dana operasionalnya sekian juta dollar untuk mengamankan jaringan komputer nya tetap bisa dijebol oleh para hacker. 🙂 Untuk detail mengenai aturan dan regulasinya bisa diliat di website kami.

Untuk menutup bagian ini saya mengutip (kembali) paper Arnon Rotem-Gal-Oz

Peter Deutsch introduced the Distributed Computing Fallacies back in 1991. You’d think that in the 15 years since then that “the Network is secure” would no longer be a fallacy. Unfortunately, that’s not the case–and not because the network is now secure. No one would be naive enough to assume it is. Nevertheless, a few days ago I began writing a report about a middleware product some vendor tried to inflict on us that has no regard whatsoever to security! Well that is just anecdotal evidence, however.

sekian dulu, mau kelas nih 😀

Advertisements

Delapan ‘Dosa’ Geek yang Mengerikan – Part 1

Sepertinya judul post ini terlalu hiperbola. 😀 Tapi memang benar kenyataannya. Hari ini saya akan membahas sebuah tugas kuliah yang diberikan kepada saya. Kuliah ini adalah kuliah wajib tingkat tiga di Program Studi Teknik Informatika, yaitu IF3056 – Sistem Terdistribusi. Dosennya adalah Pak Achmad Imam Kistijantoro. Beliau sangat imba alias jago banget. Pengetahuan akan makul yang diajarkannya sangat mendalam. Tak ayal beliau (sedengar saya) juga bertanggung jawab atas server-server di Labtek V.

Pengalaman diajar beliau pada semester lalu cukup mengesankan bagi saya. Mengajar dengan tempo agak cepat dan mendalam. Saya sebagai salah satu muridnya dituntut untuk memiliki konsentrasi tinggi dan pemahaman yang cukup akan bab-bab sebelumnya untuk mengerti kuliah yang sedang diajarkan. Sekalinya blank atau hilang konsentrasi, maka hilanglah mood untuk melanjutkan kelas pada hari itu. Karena bisa ketinggalan / tidak mengerti cukup banyak :D. Namun beliau sangat sabar untuk membahas ulang materi yang kami rasa masih kurang mengerti. Padahal kadang saya meleng atau bengong sehingga ga ngerti :p. Oleh karena itu ada baiknya kami (lebih tepatnya saya) sebagai muridnya sebaiknya membaca dulu tugas / bacaan / slide yang diberikan sebelum kuliah dimulai.

Sekian curhat saya mengenai beliau dan kelasnya. Berikut mengenai tugas yang diberikan beliau. Kami diberikan tugas untuk membaca paper dari Peter Deutsch (cmiiw) mengenai

assumptions architects and designers of distributed systems are likely to make, which prove wrong in the long run – resulting in all sorts of troubles and pains for the solution and architects who made the assumptions.

atau yang lebih dikenal sebagai 8 Fallacies of Distributed Computing.

Ketika saya membuka blog dari oracle mengenai topic ini di https://blogs.oracle.com/jag/resource/Fallacies.html saya diarahkan untuk membaca artikel dari Arnon Rotem-Gal-Oz, yang dapat diunduh di sini.

Berikut saya mengambil intisari dari paper dan tautan yang saya baca dari :

http://www.disnetwork.info/1/post/2009/10/the-8-fallacies-of-distributed-computing.html

1. The network is realible

Dalam sistem terdistribusi layer transport yang digunakan adalah TCP. TCP digunakan karena sifatnya yang reliable dan robust. Reliable berarti data yang ditransmisikan melalui TCP dijamin akan sampai dengan selamat waalfiat ke tujuan alias tidak korup. Sedangkan robust berarti kopi, eh itu robusta deng :hammer berarti ‘tahan’ terhadap error. Namun robustness dari koneksi TCP sendiri memiliki batas, dan pada beberapa kondisi koneksi ke layanan remote bisa saja tidak dimungkinkan. Sebagai contoh misalnya kegagalan daya catu. Atau contoh lain ketika anda memiliki sebuah web e-commerce yang bekerja dengan aplikasi eksternal dari sebuah bank / jasa kartu kredit. Anda tentu saja tidak memiliki kontrol terhadap koneksi yang digunakan oleh jasa tsb. Bisa saja terjadi DDOS attack yang menyerang bank tersebut. Dan *poof*. Data user web anda tidak akan pernah masuk ke bank tsb.

Protokol  yang digunakan oleh Sistem Terdistribusi adalah Distributed Information Transfer Protocol (DITP) yang didesain untuk mengatasi kegagalan koneksi. Sebagai contoh misalnya ada beberapa server yang didesain untuk saling tersinkronisasi antar satu dengan yang lain. Lalu tiba-tiba terjadi kegagalan jaringan. Server A dan Server B akan berproses dengan data yang sama namun dengan aksi yang berbeda dan jaringan yang berbeda. Ketika jaringan antar server tersebut tersambung kembali, data akan kembali disinkronisasi antar Server A dan Server B.

2. The Latency is Zero

Latency adalah waktu yang diperlukan dalam perpindahan data dari satu tempat ke tempat lain. (Sedangkan bandwidth adalah seberapa banyak data yang dapat ditransfer dalam satuan waktu). Latency tentu saja akan bagus di dalam jaringan lokal (LAN). Namun biasanya Sistem Terdistribusi akan menggunakan Wide Area Network (WAN). DITP dapat mengurangi latency dengan cara asynchronous request. Jadi ketika client akan menggunakan data, yang harus terlebih dulu di-download dari server. Client dapat melakukan proses lain sembari menunggu data tersebut dari server. Ketika download sudah selesai maka proses tadi yang sempat tertunda dapat dilanjutkan. Contoh pemakaiannya adalah AJAX dan JavaScript. Selain itu dapat juga digunakan metoda mengirimkan code yang akan dieksekusi oleh remote service. Sebagai contoh JavaScript pada Web 2.0.

The minimum round-trip time between two points of this earth is determined by the maximum speed of information transmission: the speed of light. At roughly 300,000 kilometers per second (3.6 * 10E12 teraangstrom per fortnight), it will always take at least 30 milliseconds to send a ping from Europe to the US and back, even if the processing would be done in real time.” — Ingo Rammer on latency vs. Bandwidth

Sekian dulu post bagian pertama mengenai 8 fallacies ini 😀 akan saya lanjutkan pada malam hari nanti / besok malam 🙂 Stay tune!

II 3062 – Keamanan Informasi

Kuliah pagi hari ini adalah kuliah yang paling saya nanti-natikan dalam semester ini. Dan sepertinya bukan hanya saya saja yang menanti-nantikan kuliah ini. Buktinya terdapat 161 mahasiswa yang mendaftar kuliah tsb. Dan tadi pagi, ruang kelas sampai tidak cukup menampung seluruh mahasiswa. Saya pribadi sangat antusias mengikuti kuliah ini, bukan hanya karena materinya, melainkan karena dosennya adalah orang yang sangat inspiratif menurut saya. Beliau adalah Pak Budi Rahardjo. “Bermain” di bidang IT, entrepreneur, dan Rock’n Roll Band, menjadikan beliau (menurut saya) orang yang cerah dan energik di usianya! 😀 .Mungkin hal ini juga yang menyebabkan kuliah ini membludak peminatnya. 🙂

Pada kuliah pertama ini, beliau menyampaikan aturan main yang ada di dalam kuliah ini. Cukup menarik karena beliau tidak peduli dengan kehadiran, bahkan beliau (entah bergurau atau tidak) berpikir untuk melakukan absensi online, sehingga mahasiswa tidak perlu harus masuk setiap saat :D. Selain itu, beliau bercerita sedikit tentang dirinya. Namun hal yang paling menarik bagi saya adalah, ketika beliau bercerita tentang dirinya menggunakan slide PowerPoint. Pada halaman depan terdapat nama beliau beserta tulisan

versi 3.3

Beliau lalu bercerita tentang perubahan kehidupannya yang bersifat major (1.0 – 3.0). Secara singkat terurai seperti ini:

versi 1.0 : ketika beliau memandang wargakenegaraan adalah hal yang terpenting di dalam hidup ini. Bahkan beliau sempat terpikir untuk berpindah wargakenegaraan ketika melanjutkan studi di Canada.

versi 2.0 : kewarganegaraan bukanlah hal yang terpenting lagi. Terinspirasi dari buku “the world is flat”, yang dikejar beliau pada masa ini adalah pekerjaan di multi-national company. Asalkan bertitel IBM apapun warganegaranya, mungkin sudah sangat oke 😀

versi 3.0 : ketika titel perusahaan multi-national company bagi beliau sudah tidak penting lagi. Yang penting adalah dirinya. Dia adalah dia. Yang terpenting adalah bagaimana beliau bisa memberikan kontribusi kepada humanisme.

Dan bagi saya sendiri, saya pernah melewati ketiga versi tersebut. Ketika saya merajut mimpi akan masa depan, sempat terpikir untuk mencari green card, sempat juga terpikir untuk berkarir di perusahaan multi-national, dan menurut Pak Budi, hampir 80% mahasiswa sekarang berada di bagian versi 2.0 tsb. Begitu juga dengan saya. Bisa dikatakan saya sedang berada di versi 2.8 atau 2.9. Dimana saya sedang dalam proses merombak mimpi yang sedang dirajut. Merombak mimpi untuk membuat saya lebih menjadi ‘saya’ seutuhnya di masa mendatang.

Tapi saya masih sangat berharap bisa kerja praktek di perusahaan multi-nasional loh 🙂

Fly with eagle and be one of them..

[Repost – Copas] Cara Menghitung Nilai Proyek

Image

Beberapa waktu yang lalu saya membaca sebuah tautan yang di-share oleh salah satu teman saya di facebook. Tautan ini mengarah ke forum kaskus mengenai bagaimana cara menghitung nilai proyek. Mungkin hal ini bisa dijadikan referensi apabila kita sebagai developer menerima sebuah tawaran proyek 🙂

Saya akan memulai kumpulan posting baru dgn prefix “Curhat Proyek”. Posting ini berkenan dgn pengalaman saya menghadapi problem technical dan non-technical di dunia Independent Software Vendor / software house kecil. Semoga bermanfaat bagi mereka yg nantinya berniat terjun menjadi entrepreneur software juga…

Posting pertama adalah tentang Nilai Proyek. Posting ini di-dedikasikan untuk brothers-brothers saya yg kadang menelpon minta pendapat “ngasih harga proyek”…

Mungkin ketika kita masih mahasiswa dan bekerja freelance, kita “seenaknya” memberi harga:
“Berapa Z, kira-kira fee-nya?”
“Yah, standar lah Pak… kira-kira 2 juta selesai 1 bulan”
“Woow, mahal banget…. kamu kan masih mahasiswa, kasih harga mahasiswa donk. Gimana kalo 1 juta aja?
“Hmm, ya deh boleh…”

Kenapa Anda bisa “ngalah” nego? Mungkin karena Anda masih di-supply oleh uang kiriman orangtua ketika mahasiswa, jadi tidak peduli betul dgn harga yg Anda berikan. Tapi Anda butuh uang extra untuk ditabung, atau untuk membeli sesuatu (graphics card terbaru, external hard disk 1TB, dsb.)

Namun, sikap seperti ini tidak bisa lagi diterapkan jika Anda menjalankan bisnis software development.

Sebagai Pimpinan perusahaan, Anda akan dituntut untuk:

* mendapatkan untung dari bisnis, bukan “tekor” atau loss yg menyebabkan awal keruntuhan bisnis Anda. Kalau tidak ada untung (terlalu sering memberikan diskon), lebih baik Anda menjadi karyawan saja, karena buat apa berbisnis jika tidak ada untungnya?
* menghidupi diri sendiri (mengambil gaji untuk sendiri) dan menghidupi orang lain (menggaji karyawan).

Formula Nilai Proyek pada umumnya adalah:
Formula Nilai Proyek pada umumnya adalah:

Project Fee = Cost + Profit + Tax

Contoh:
Anda mendapatkan proyek yang harus selesai dalam waktu 3 bulan. Karena 3 bulan deadline inilah, Anda butuh:
– 2 orang Programmer (coding, coding, coding);
– 1 orang Supervisor Developer (give instruction, code inspection, code);
– 1 orang Lead Developer (Anda sendiri, translate bisnis process menjadi software flow, high-level architecture) dan
– 1 orang Designer (create button images, Expression Blend artist).

Menghitung cost per orang secara lebih detail akan dibahas di post lainnya. Untuk saat ini, asumsinya adalah orang-orang diatas adalah dedicated resources, sehingga mereka hanya mengerjakan proyek ini, sehingga tiap bulan gaji mereka adalah gaji dari proyek ini.

Pertama-tama, buatlah tabel cost salary untuk orang-orang diatas:

Sebagai warga negara yg baik, Anda harus taat pajak. Untuk kasus diatas, ini diambil dari model freelance. Untuk “Pegawai Honorarium atau Imbalan Lainnya” (Freelancer), tarif PPh 21 nya adalah Pasal 17, UU No. 17 (http://pajak.go.id/index.php?option=…gkp=oyes&idp=2) , yaitu untuk penghasilan sampai dengan 25jt, tarifnya adalah 5%.

Sehingga dgn memasukkan unsur pajak ke cost, Anda memberikan “gaji bersih” kepada developer/designer Anda.

Diatas juga ada item Electricity dan Internet. Lima (5) Komputer/laptop akan menyala selama 3 bulan, dari jam 09.00 – 17.00, bahkan terkadang sampai malam. Apakah Anda akan membayar listrik dari gaji Anda sendiri? Ya, jika Anda masih dalam mindset karyawan. Tapi ini bisnis, pisahkan antara uang perusahaan, cost perusahaan dan uang pribadi/keluarga Anda dan cost pribadi/keluarga.

Jangan gunakan uang perusahaan dari Profit untuk membeli susu anak, membayar listrik rumah, dan kebutuhan rumah tangga lainnya. Untuk semua itu, gunakan uang Anda dari gaji yg diterima perusahaan (gaji Lead Developer dalam contoh diatas).

Ok, sekarang menghitung Profit dan Total Cost+Profit untuk 3 bulan (lamanya estimasi proyek ini):

Cost per month diambil dari kolom Subtotal + Tax, karena Anda ingin karyawan Anda menerima gaji bersih bukan?

Profit… ini masalah sangat personal, karena tergantung Anda ingin berapa besar mengambil untung. Menurut filosofi saya:
– 30% adalah angka ideal (client mampu dan besar).
– 25% adalah angka tengah (client minta harga diturunkan).
– 20% adalah angka minimum (client adalah teman/keluarga, jangan turun dibawah ini, ingat bisnis Anda harus untung).

Selanjutnya, apakah dalam proyek ini Anda membutuhkan 3rd Party Component? Misal Aspose untuk membaca Word dokumen tanpa menginstall Microsoft Word? Jika ya, masukkan sebagai komponen terakhir dan kalkulasikan totalnya:

Selanjutnya, ini adalah hal terpenting dalam bisnis software development. Client Anda sebagai Pengusaha Kena Pajak wajib memotong Tarif Pajak PPh Pasal 23. Lihat http://www.pajak.go.id/lampiran/07PJ_PER70.htm, untuk “Jasa sehubungan dengan software komputer, termasuk perawatan, pemeliharaan dan perbaikan” dikenakan tarif 30% x 15% atau 4.5% dari total bruto sebelum PPN.

Tarif pajak ini wajib Anda masuki, karena pajak ini dipungut oleh divisi Finance Client Anda, jadi pasti dipotong dari total invoice yg Anda keluarkan:

Nah, sekarang masukkanlah angka Rp 94.441.875 (Sembilan Puluh Empat Juta Empat Ratus Empat Puluh Satu Delapan Ratus Tujuh Puluh Lima Rupiah) dalam Proposal Proyek Anda

Ok, biasanya, Client akan menawar. Maka opsinya adalah:

* turunkan Profit Margin Anda.
* bilang kepada karyawan Anda bahwa gaji “3 juta belum termasuk pajak loh”… jadi Anda akan menghitung Total Cost tanpa Pajak PPh 21.

Yang terpenting, jangan pernah mengikuti angka Client Anda. Ingat, Anda punya formula sendiri untuk menghidupi bisnis Anda dan para karyawannya. Mereka pun sama. Jika angkanya tidak ketemu, mungkin scope project harus diturunkan lagi. Atau saatnya Anda mundur dari proyek ini dan memberikan kepada mereka yg lebih berani (yg meng-outsource proyek ini ke programmer yg mau digaji dibawah Rp 1 jt)

Jika Anda melakukan dealing dgn IT Manager yg merupakan teman Anda… teman dekat sampai saling memanggil dgn prefix, “Brother…” atau “Bro.”, maka Anda bisa melakukan konversasi seperti berikut: (tapi jangan kalo Anda tidak kenal dekat, nanti malah tersinggung dan nggak dapat proyek lagi hehe)

“Bro… 94 juta mahal banget… gw nggak bisa segitu bro…”
“Bro… look into my eyes. Saya tidak tega memberi gaji programmer saya dibawah Rp 3jt. Mereka bukanlah buruh kasar, tapi tenaga professional yang harus dibayar sewajarnya…”

“Bro… ok gw ngerti tentang filosofi gaji programmer elo… tapi tetap aja angkanya ketinggian”
“Bro… ente kan minta 3 bulan kelar… makanya ane ambil 4 developer (termasuk ane) + 1 designer. Kalo angkanya ketinggian, gini aja deh… ane turunin jadi 3 developer (termasuk ane) + 1 designer. Tapi scope projectnya harus diturunin yaa…”

“Bro… walaupun scope-nya diturunin, koq angkanya masih tinggi sih? Perusahaan ane nggak bisa bayar setinggi itu…”
“Bro… ente IT Manager dgn gaji 8jt / bulan. Ente punya 3 anak buah dgn gaji 3jt / bulan. Sebulan, perusahaan ente punya cost 17jt belum termasuk pajak dan biaya reimbursement. Tiga bulan, perusahaan ente rela ngeluarin 51 juta untuk cost tim IT ente. Nah, cost tim ane dgn cost tim ente cuman beda X juta aja. Itu ane ambil pertama buat buffer kalo proyek nya molor lebih dari 3 bulan. Kedua, itu untuk untung/profit bisnis ane. Bedanya ente punya jaminan kerja dan gaji tetap. Bedanya ane, kalo nggak ada proyek ga dapet gaji. Jadi ane harus untung biar ane ga bangkrut di masa-masa sepi order.”
“Hehe… ente bisa aja jelasinnya… ok deh bro, nanti ane bilangin ke user dan atasan kalo ini harga final ente.”

Jika setelah konversasi semacam diatas, nilai proyek Anda tetap minta diturunin maka kemungkinannya dua:
1. Client ingin proyek extravagant yg costly dan harus cepat selesai, tapi minta semurah mungkin. Ini bad business. Walk away from projects like these because the chance of failure is bigger.

2. Contact Anda tidak rela melihat Anda mendapatkan transferan 90 juta rupiah tanpa dia tidak mendapat sepeser pun. Ini kembali kepada moral Anda, apakah akan memberikan dia bagian dari proyek… ataukah Anda akan walk away?

Berikut Excel sheet untuk kalkulasi proyek diatas, silakan customize sesuai dgn proyek dan organisasi Anda

http://dw8zra.bay.livefilestore.com/…e.xls?download

sumber :
http://geeks.netindonesia.net/blogs/zeddy/

 

credit & source : here