Belajar Tidak Selalu Berhasil

Seharian ini saya mencoba ngoprek pemrograman lagi. Coding. Sebetulnya saya hanya ingin mencoba menggunakan bahasa pemrograman Golang untuk membaca webcam saya melalui OpenCV. Masalahnya versi OpenCV yang didukung Golang adalah versi terbaru yang tidak ada di komputer saya. Artinya saya harus mengunduh dan merakit (compile) sendiri. Oke lah.

Dahulu saya biasa merakit sendiri berbagai paket program dari kode sumbernya. Tidak masalah. Namun sekarang ternyata proses perakitannya menjadi lebih kompleks. Ini disebabkan kode sumbernya juga semakin kompleks dan platform yang digunakan orang juga bervariasi sehingga ada banyak konfigurasi yang harus dilakukan. Ternyata konfigurasi bawaan dari paket ini tidak cocok dengan sistem operasi yang saya gunakan (Linux Mint 18.1 Serena).

Setelah ngoprek nyaris seharian – dari pagi sampai menjelang Maghrib ini – ternyata hasilnya tidak ada, alias gagal. Ya begitulah. Belajar kadang memang harus seperti ini. Banyak gagalnya dahulu. Tidak selalu harus berhasil. Kesel memang. (Ini ngetiknya juga sambil kesel.) Habis mau gimana lagi? Keselnya saya adalah karena menghabiskan waktu yang seharusnya dapat saya gunakan untuk belajar yang lainnya. Grrr.

Anggap saja ini adalah upaya saya untuk menambah “jam terbang” ngoprek Linux. (Padahal saya ngoprek Linux sejak pertama kali dia dibuat Linus. ha ha ha.)

Berikut layar terakhir hari ini sebelum saya berhenti dulu. “100% tapi gagal”. Heu.

Oh ya, versi videonya ada di YouTube channel saya. Ini dia.

Aplikasi (Contact) Tracing vs. Privasi

Belakangan ini mungkin Anda sudah mendengar bahwa perusahaan Apple dan Google bekerjasama untuk meluncurkan sebuah aplikasi yang melakukan tracking (pemantauan) keberadaan orang dan kaitannya dengan risiko terpapar virus corona (penyakit covid-19). Di Indonesia juga ternyata ada beberapa instansi akan (sudah?) meluncurkan aplikasi sejenis. Katanya aplikasi ini memantau keberadaan kita dan orang-orang di sekitar kita.

Ada banyak permasalahan dengan aplikasi sejenis ini. Masalah tersebut terkait dengan keamanan (security), termasuk masalah privasi. Kita mulai satu persatu dahulu.

Pertama, adanya ketidakjelasan cara aplikasi tersebut bekerja. Ada sih memang penjelasan umumnya, tetapi penjelasan umum tidak cukup. Misalnya, data apa saja yang dibaca oleh aplikasi? Diapakan saja data tersebut? (Dikirimkan kemana kah? Diproses apa kah?) Misal, apakah data kontak kita juga dibaca? Bagaimana dengan orang-orang yang berada di dalam kontak kita tetapi tidak ingin diketahui oleh orang lain nomor teleponnya (credentials-nya)? (Ada banyak orang yang seperti ini. Saya tidak bersedia membocorkan nomor telepon kawan-kawan saya kepada siapapun.) Apakah data orang-orang tersebut dibaca secara plain ataukah di-obfuscate atau diubah? Dengan cara apa? Apakah data tersebut digunakan? Dikirim? Diproses? Atau apa?

Kemudian ketika Anda berdekatan dengan seseorang, data apa saja yang dipertukarkan? Ada yang menggunakan Bluetooth dan saling bertukar data. Ketika kita mendapatkan data dari Bluetooth, bagaimana kita memastikan bahwa kita tidak kesusupan malware, trojan horse, virus, dll. Ada satu panduan yang umum digunakan, yaitu ketika tidak dibutuhkan, matikan Bluetooth. Jangan membiarkan Bluetooth hidup terus menerus. Ada banyak program penyerang Bluetooth. Belum lagi kalau kita bicarakan batre yang kesedot karena Bluetooth (atau networking lain) yang hidup terus.

Semua data ini kemudian diolah oleh “siapa”? Lokal di handphone kita? Menghabiskan batrekah? Atau dikirim ke tempat lain? Apa hak-nya “siapa” (instansi) yang mengelola data kita tersebut? Kalau data kita bocor, apakah “siapa” ini dapat kita tuntut ke pengadilan?

Bayangkan ini seperti aplikasi google maps / waze yang melakukan tracking kemana saja Anda pergi, ketemu siapa saja, atau dekat dengan siapa saja. Kemudian dia bakalan tahu juga kontaknya kontak Anda.

Cara-cara (protokol, mekanisme) yang digunakan harus terdokumentasi dan terbuka untuk publik. Jika ini dirahasiakan, maka itu sebuah tanda bahwa sistem ini tidak aman. Kita ambil contoh di dunia kriptografi. Sebuah algoritma kriptografi dinyatakan aman apabila algoritma tersebut dibuka ke publik. Keamanannya bukan terletak kepada kerahasiaan algoritmanya, tetapi kepada kerahasiaan kuncinya.

Setelah desain dari aplikasi tersebut kita nyatakan aman – atau setidaknya belum ditemukan masalah – maka kita beranjak kepada implementasinya. Bagaimana ide tersebut diimplementasikan. Banyak aplikasi / sistem yang idenya bagus tetapi implementasinya buruk. Jebol di sana-sini. Yang ini harus dibuktikan melalui evaluasi atau audit.

Setelah itu ada juga masalah di operasionalnya. Apakah orang mudah menggunakannya atau cenderung mengabaikan keamanannya. Misalnya ada sebuah sistem yang didesain teramat sulit ditembus, tetapi gemboknya (password-nya) misalnya 40 karakter. Karena sulit dihafal, maka password tersebut dituliskan di layar (menggunakan post-it-note). Hal yang sama, kadang karena sulit dihafal makas sandi tersebut kita simpan di handphone. Bubar jalan.

Masih ada hal-hal lain yang bisa kita bahas. Pada intinya, selama aplikasi tersebut tidak terdokumentasi dengan terbuka dan belum dievaluasi maka jangan gunakan aplikasi tersebut. Tujuan yang baik dapat berdampak buruk jika implementasinya ngawur.

Oh ya, versi video dari penjelasan ini dapat dilihat pada channel YouTube saya.

Semoga penjelasan ini dapat memberikan cara pandang lain.

Bacaan terkait.

• Apple and Google’s new smartphone alert system for tracking the coronavirus could be ‘alarming’ for privacy, US senator warns

Mencari Developer Software

Beberapa waktu yang lalu saya menghadiri acara Bekraf yang diorganisir oleh Dicoding di Bandung. Acara ini mengumpulkan developer software (pengembang aplikasi) di kota Bandung dan diberikan berbagai pengetahuan (seminar, training). Berikut ini adalah contoh foto yang hadir. Banyak! Lebih dari 1000 orang!

Namun yang menjadi masalah adalah ketika saya mencari developer, ternyata kesulitan. Sebetulnya mereka ada dimana? Ini adalah sebuah paradoks; katanya banyak SDM yang mencari pekerjaan tetapi ada banyak perusahaan yang kesulitan mencari SDM.

Saya mendapat permintaan untuk programmer dan support (untuk berbagai jenis software baik yang sudah kadaluwarsa maupun yang masih baru). Akhir-akhir ini malahan dapat permintaan tiap minggu! Nah, apakah perlu saya tanggapi permintaan-permintaan ini dengan lebih serius? Dahulu kami memang pernah memiliki perusahaan outsourcing seperti yang dimaksudkan, tetapi sekarang para pengembangnya sudah tersebar. (Ada yang pindah ke luar kota, mengambil kuliah di luar negeri, menjadi freelancer, membuat perusahaan sendiri, atau menjadi bagian dari perusahaan kami lainnya.) Nah, perlukah kami membuat kembali perusahaan ini?

Ketika Koding Menguasai

Semalam, pukul 1 malam (atau tepatnya pukul 1 pagi) saya terbangun. Teringat sebuah ide koding (pemrograman) LED yang saya buat beberapa waktu yang lalu. [Lihat tulisan saya tentang ini.] Saya ingin membuat sebuah kode lagi. Langsung saja saya tidak bisa tidur lagi.

Ada dua pilihan. Tetap memaksakan diri untuk tidur kembali (dengan risiko kehilangan ide dan juga tidur mungkin tidak nyenyak) atau bangun dan membuat kode, koding. Saya ambil pilihan yang terakhir. Langsung ambil laptop.

Sambil koding saya nyalakan TV. Eh, film yang sedang main adalah film horor. ha ha ha. Hmm … sudah malas saya mengubah channelnya untuk memilih film yang lain. Pikiran sedang fokus ke kode. Maka saya biarkan saja film horor itu tetap on. hiii. Koding berlanjut. Ternyata semangat koding mengalahkan seramnya film horor. Baru kali ini saya tahu. ha ha ha.

Setelah sekitar setengah jaman koding, beres. Ide terimplementasi. Untungnya tidak terlalu banyak masalah di kodenya. Saya upload kode ke akun sementara saya untuk kemudian besok saya upload ke github. Baru bisa tidur kembali. Nyenyak.

Ngoprek IoT

Kata IoT – Internet of Things – sedang ngetop sekarang. Dimana-mana saya melihat kata ini sebagai bagian dari seminar, kompetisi, startup, dan seterusnya. Pokoknya seru saja. Nah, sayapun tidak mau ketinggalan.

Saya mencoba menggunakan Arduino UNO dan board buatan DycodeX untuk kode IoT ini. (Sebetulnya saya punya banyak board lainnya, tapi itu untuk cerita terpisah.) Selain board ini saya juga menggunakan LED board buatan ProcodeCG. Berikut ini adalah beberapa video yang saya buat untuk menunjukkan demo / contoh kode dengan board-board di atas.

Dalam dunia hardware, IoT, salah satu cara memulai atau mencoba adalah membuat demo “blinking LED”. Kalau di dunia software, ini adalah “Hello World” versi hardware. Biasanya sih blinking LED-nya hanya satu LED. Kali ini saya mencoba menggunakan beberapa LED biar lebih seru.

Video di bawah ini menunjukkan demo Knight Rider, yaitu LED yang bergerak dari kiri ke kanan dan sebaliknya. Nama ini diambil dari film seri Knight Rider (jaman dahulu dan versi barunya). Dalam film tersebut ada mobil cerdas yang bernama KITT. Kalau dia aktif, maka ada LED yang bergerak-gerak seperti ini.

Dalam video di bawah ini, saya membuat Knight Rider LED juga tetapi dengan menggunakan board Arduino UNO.

Video di bawah adalah demo untuk membuat LED seperti meter yang ada di radio (equalizer). Board yang digunakan adalah DycodeX ESpectro.

Oh ya, kode-kode untuk demo di atas dapat dilihat dan diunduh dari koleksi saya di github.com yaitu di: https://github.com/rahard/BRiot-stuff. Selamat ngoprek.

Keamanan dan Kinerja Aplikasi

Kemarin seharian saya menjadi salah satu juri dalam lomba aplikasi berbasis open source. Lumayan capek juga seharian menjadi juri. Sekalian ini menjadi tempat bagi saya untuk mengukur pemahaman pengembang software tentang keamanan (security) dan kinerja (performance) dari aplikasi.

Hasilnya? Kalau soal lombanya belum ada hasilnya karena masih berlangsung. Kalau soal masalah pemahaman keamanan dan kinerja ternyata masih cukup jauh juga. Saat ini pengembang masih terlalu fokus kepada aspek fungsional saja. Aspek security masih mengandalkan bawaan dari sistem / framework / tools yang ada saja. Bahkan ada yang menyerahkan kepada network (misal firewall) untuk aspek pengamanan. Sementara itu untuk aspek kinerja, umumnya belum ada yang mengukur. Program aplikasi jalan dan
“cukup cepat” saja sudah cukup bagi mereka.

Nampaknya saya harus membuat tulisan-tulisan mengenai hal ini. Hmmm…

Editor Foto di Linux?

Saya sedang mencari-cari program untuk mengedit foto di Linux. Program yang saya cari adalah yang mirip dengan program Photoscape yang berjalan di OS Windows. Kelebihan dari program Photoscape, selain gratisan, adalah cepat dalam melakukan manipulasi terhadap foto. Biasanya yang saya lakukan adalah (1) mengecilkan ukuran foto (scale menjadi 800 x 600), (2) melakukan filter vignette (agar sisi-sisinya agak gelap), (3) … eh sudah, itu saja. Kadang memang saya gunakan efek lain tapi ini sangat jarang.

Sekarang saya menggunakan Gimp. Ini mungkin masih yang terbaik di Linux ya? Hanya saja Gimp ini terlalu berat (terlalu powerful?) untuk apa yang saya inginkan. Vignette, misalnya, bisa dilakukan di Gimp tapi agak sedikit repot. Memang lebih powerful (karena bisa dibuat macam-macam) tetapi menjadi lebih repot. (Harus buat layer dulu, dan seterusnya.) Kalau di Photoscape tinggal satu klik 🙂 hi hi hi dasar pemalas.

Ada yang bisa kasih saran program untuk mengedit foto yang Anda gunakan di Linux? Atau apakah lebih baik saya menggunakan Windows emulator di Linux dan menjalankan Photoscape di sana saja? (Ini menjadi pertanyaan lain, lebih baik pakai Windows emulator atau pakai VirtualBox saja?)

Oh ya, kalau di Mac OS saya biasanya menggunakan Seashore.

Sejak Kapan Software Berbayar?

Saya sedang mencoba menelusuri sejarah software. Sejak kapan ya software itu berbayar?

Pemahaman saya adalah software pada mulanya tidak berbayar karena dijual secara paket atau menjadi bagian dari penjualan hardware. Ini pada era mainframe dulu. Memang ini bisa terjadi karena tidak ada pengguna komputer di luar lingkungan militer, tempat riset, dan juga mungkin beberapa perusahaan besar saja.

Nah, sejak kapan software dijual secara produk atau retail ya?

Saya ingin menejelaskan bahwa tren sekarang, yang mana software itu bisa gratis, bukanlah sebuah hal yang baru atau hal yang menakutkan. Ada yang ketakutan bahwa karena software itu bisa gratis lantas apa gunanya sekolah komputer (menjadi programmer)?

Selain itu saya juga mencari statistik seberapa banyak programmer di Indonesia yang bekerja mengembangkan produk yang dijual secara retail (atau secara produk lah), bukan sebagai konsultan, atau orang yang melakukan customization, atau sistem integrator. Pemahaman saya sebagaian besar programmer di Indonesia mengembangkan aplikasi internal perusahaan atau melakukan customization. Jarang yang mengembangkan produk yang dijual secara retail. Sehingga sesungguhnya keberadaan open source lebih menguntungkan.

Wordprocessor Sok Tahu

Saat ini saya sedang mengedit sebuah berkas (laporan) dengan menggunakan sebuah wordprocessor. Dalam laporan ini ada gambar, tabel, dan obyek lainnya. Nah repotnya kadang wordprocessor ini sok tahu dalam menempatkan gambar.

Saya pasang gambar di titik ini (di baris setelah paragraf ini). Ternyata oleh si wordprocessor dipindahkan ke tempat lain. Mending kalau dipindahkannya ke bagian setelah teks. Ini dipindahkannya ke bagian sebelum teks sehingga kadang teks saya menjadi ngaco; “perhatikan gambar berikut …” (gambarnya sudah nongol duluan, hi hi hi).

Sebel dengan wordprocessor yang sok tahu 🙂

Sharing Vision: Software Cost Estimation

Kemarin (dan hari ini) saya mengikuti pak Arry AA mendiskusikan tentang estimasi harga software. Topik ini merupakan salah satu topik yang menarik dari berbagai sisi; ilmu, teknologi, seni, bisnis, project management, hukum, dan seterusnya.

[AAA in action …]

Ada banyak sub-topik dalam diskusinya. Misalnya, apa artifak dari software yang bisa dijadikan alat ukur untuk membandingkan kompleksitas software? (Semakin kompleks diasumsikan semakin mahal.) Lines of codes (LOC) – jumlah baris dari kode sumber – mungkin bisa digunakan, tetapi saat ini dia dipertanyakan karena berbagai faktor. Function points bisa juga digunakan, tetapi dia agak subyektif. Work Breakdown Structure – membagi-bagi pekerjaan menjadi sub-pekerjaan – mungkin juga digunakan.

Setelah itu masih ada juga permasalahan dari sisi SDM-nya. Berapa harga mandays yang layak?

Wah pokoknya pusing dan menarik!

Software Lebih Mudah?

Latar belakang saya adalah hardware. Maklum saya berasal dari lab elektronika dan dahulu memang saya hobi ngoprek elektronik sampai ikutan ORARI segala. Pada jaman itu (awal tahun 80-an), memang komputer belum populer dan masih mahal. Maka belum banyak yang ngoprek software.

Sekarang nampaknya jaman sudah terbalik. Lebih banyak orang yang ngoprek software daripada hardware. Saya lihat di lab kami juga begitu. Lebih banyak mahasiswa yang mengerjakan tugas akhir atau penelitian dalam bentuk software dibandingkan hardware.

Pernah sekali saya tanyakan kepada seorang mahasiswa dari jurusan elektronika, mengapa dia mengerjaan tugas akhir dalam bentuk software bukan hardware. Jawabannya adalah lebih mudah. Hah? Saya kira ini adalah pandangan umum; bahwa membuat software lebih mudah dibandingkan hardware.

Saya katakan kepada mahasiswa yang bersangkutan bahwa kalau memang softwarenya hanya main-main atau asal-asalan, ya memang “mudah”. Kalau ingin membuat software yang “sungguhan”, maka dia tidak mudah. Tanpa ilmu yang benar, software kita bisa jalan tetapi mungkin dia tidak efisien (tidak bisa digunakan untuk data yang jumlahnya besar) atau mengandung bugs.

Dulu, ketika saya belum belajar ilmu komputer, saya memang bisa memprogram (dengan belajar sendiri). Ketika saya membuat simulator, sebuah program yang menghasilkan test pattern untuk rangkaian digital, ternyata program saya hanya bisa jalan untuk beberapa puluh transistor. Saya tidak yakin program saya bisa jalan dengan jumlah transistor yang ratusan. Padahal rangkaian sesungguhnya saat ini mungkin memiliki jutaan transistor. ha ha ha. Ternyata saya mengalami masalah dengan kompleksitas.

Setelah mempelajari ilmu komputer (teori-teorinya), barulah saya sadar bahwa membuat software ternyata tidak mudah. 🙂 Bayangkan, untuk mengurutkan (sorting) saja ada banyak algoritmanya. Belum lagi urusan pemilihan struktur data yang paling tepat untuk sebuah problem tertentu. Ternyata ruwet juga.

Software Merusak Hardware

Xbox anak saya baru kembali dari reparasi. Ini sudah ketiga kalinya Xbox ini masuk ke reparasi secara berturut-turut. Setiap habis dibawa pulang ke rumah, pasang games “Fable II” langsung Xboxnya rusak lagi. Di bawa ke tempat reparasi dan pulang begitu lagi.

Akhirnya di sana minta dibawakan power supplynya dan games yang dipakai di rumah. Setelah dicek di sana, ternyata games yang dipakai juga membuat Xbox lain rusak! Halah!

Software ternyata bisa merusak hardware ya. Hati-hati para programmer di sana. Kalau buat program yang bener dong. Mosok hardware bisa sampai rusak? Kan, serem jadinya.

Ada yang punya cerita yang sama / mirip (software merusak hardware)?

Nilai dari Software

Dalam acara Sharing Vision kemarin kami membahas salah satu topik yang cukup berat, yaitu tentang estimasi harga dari software. Topik ini bisa kita perlebar menjadi nilai (value) dari software.

Software itu tidak kasat mata. Yang terlihat adalah media dimana software itu berada, misalnya disk atau CD dimana software itu disimpan. Demikian pula ketika dia sudah berada di dalam komputer, yang terlihat adalah komputer atau RAM-nya, bukan softwarenya. Akibatnya, agak susah bagi kita untuk memberikan apresiasi terhadap software. (Yang kasusnya mirip dengan ini adalah desain grafis ya? Yang terlihat dan yang dihargai hanya kertasnya. he he he.)

Ada banyak sekali pertanyaan yang muncul seputar harga software. Perlu dicatat bahwa peserta workshop kemarin latar belakangnya bervariasi. Yang paling banyak adalah dari bagian pengadaan IT (procurement). Jadi latar belakang pertanyaannya adalah seputar kesulitan yang mereka hadapi. Mari kita bahas beberapa pertanyaan yang muncul dalam acara kemarin. Ah, kita batasi dulu pertanyaannya ya.

Jika kita memberikan (melakukan outsource) sebuah pekerjaan pengembangan aplikasi baru kepada sebuah perusahaan pengembang aplikasi, berapa harga yang wajar untuk software tersebut? Bagaimana memperkirakan harganya?

Sebuah pertanyaan yang sederhana akan tetapi jawabannya tidak mudah. Dahulu estimasi harga ini dilakukan dengan feeling. (Sekarang juga masih. ha ha ha.) Sekarang sudah ada beberapa metodologi untuk melakukan estimasi. Meskipun metodologi tersebut belum ada yang sempurna, tetapi mereka dapat digunakan sebagai panduan (rough estimate).

Metodologi pertama yang muncul untuk melakukan estimasi harga software adalah dengan menghitung jumlah baris dari kode (lines of code atau disingkat menjadi LOC). Idenya adalah satu baris koder terkait dengan satu upaya (effort) tertentu. Seorang programmer memiliki kemampuan memprogram sejumlah LOC tertentu dalam satu hari (rata-rata). Pengembang aplikasi kemudian dibayar sesuai dengan jumlah baris yang dia kembangkan.

Ada beberapa masalah dengan metoda ini. Ambil contoh dua pengembang (A dan B) yang mengerjakan sebuah fungsi yang sama. Pengembang A membutuhkan 1000 baris, sementara pengembang B membutuhkan 100 baris untuk mengimplementasikan fungsi yang sama. Mana yang lebih baik? Tentu saja pengembang B yang lebih baik karena dia bisa mengimplementasikan fungsi tersebut dengan lebih efisien (dilihat dari sudut pandang jumlah barisnya lho, kita asumsikan algoritmanya sama). Akan tetapi pengembang A akan mendapat bayaran yang lebih mahal jika ukuran harganya adalah jumlah baris. Maka pengembang tidak mendapat insentif untuk membuat aplikasi seefisien mungkin dan bahkan cenderung untuk memperbanyak baris. ha ha ha.

Masalah berikutnya adalah sekarang sudah banyak tools untuk mengembangkan software yang berbasis GUI (CASE tools). Kita tinggal tarik kotak ini itu kemudian kita hubungkan satu sama lainnya. Kode (source code) kemudian dihasilkan dari tools tersebut. Apakah metoda LOC masih cocok untuk hal yang sejenis ini?

Belum lagi nanti kita berbicara framework dan bahasa pemrograman yang berbeda. Satu fungsi mungkin bisa diimplementasikan dalam 1 baris di perl tetapi membutuhkan 10 baris di visual Basic. Masih banyak variasi lainnya lagi. Untuk hal yang ini memang bisa dipecahkan dengan membuat tabel perbandingan upaya (effort), meskipun masih tidak mudah.

Di sisi lain, LOC merupakan artifak software yang paling mudah dilihat secara obyektif.

Masih banyak pertanyaan lain, seperti misanya

Kan kita ingin membuat perkiraan (owner estimate). Softwarenya kan belum jadi. Kita tidak tahu jumlah LOC-nya. Apalagi kita orang pengadaan, bukan pengembang aplikasi. Jangan-jangan nanti kita dibohongi pengembang. Bagaimana ini?

Nah lho. 😀 Jawabannya adalah … selamat menderita! ha ha ha. Gak ding. Ada jawabannya. Lain kali ya.

Selain metoda LOC masih ada beberapa metoda lagi yang digunakan untuk melakukan estimasi upaya pengembangan aplikasi, seperti Function Point (FP), Work Breakdown Structure (WBS), COCOMO, dan seterusnya. Ah, sudah kepanjangan. Lain kali saya sambung dengan pertanyaan lainnya.

[Foto saya sedang break di belakang peserta, sementara pak Dimitri Mahayana sedang serius memberikan presentasi di depan. ngopi dulu ah … hi hi hi]