data driven

datadriven2

Beberapa saat yang lalu di salah satu saluran komunikasi kantor saya, terjadi perdebatan seru mengenai data driven company. Diskusi berkisar di definisi data-driven itu sendiri, apa manfaatnya, kenapa kita harus menjadi data-driven, dan bagaimana agar bisa menjadi data-driven company.

Sebelum kita membahas lebih lanjut mengenai data-driven, tentunya lebih baik untuk menyamakan persepsi terlebih dahulu mengenai definisi data-driven itu sendiri, karena tentunya masing-masing mempunyai definisinya sendiri. Berdasarkan Google (yang mengambil dari wikipedia), definisinya adalah sebagai berikut.

datadrivenyang kalau diterjemahkan secara bebas kurang lebih berarti mengambil keputusan berdasarkan data, bukan berdasarkan perasaan atau hanya mengikuti keputusan dari atasan atau orang yang kedudukannya lebih tinggi. Kalau ada sesuatu yang hendak diputuskan, terlebih dahulu cari data atau lakukan eksperimen.

Dalam konteks technology company, biasanya data-driven diwujudkan dalam bentuk A/B testing. Misalkan kita ingin tahu apakah tombol berwarna merah atau hijau yang lebih meningkatkan sales. Kita bagi dua saja dua saja traffic yang masuk ke 2 versi website dengan warna tombol yang berbeda. Setelah terkumpul jumlah sampel yang cukup, kita lakukan statistical test dan lihat versi mana yang lebih bagus. Bukan langsung memilih warna merah karena itu warna kesukaan boss kita.

Namun menurut saya sendiri, definisi data-driven yang paling pas itu yang diinspirasi dari bayesian method.

posterior belief is proportional to prior belief times likelihood.

Jadi keputusan yang kita ambil jadinya adalah kombinasi dari prior belief kita, hal yang kita sendiri percayai tanpa melihat data terlebih dahulu (walaupun sebenarnya ini adalah bentuk internalisasi semua kumpulan data yang pernah kita alami sebelumnya), kemudian di-update dengan hasil atau data terbaru yang sesungguhnya terjadi.

Bagaimana prakteknya? Mari kita ambil contoh Zlatan Ibrahimovic yang kini membela Manchester United.

ibrahimovic-ke-mu-730x480_c
Zlatan dengan kaus MU

Prior belief itu berguna agar kita tidak terlalu cepat mengambil kesimpulan dengan hasil/data yang masih sedikit. Kalau tanpa prior dan kita mengamati Zlatan tidak mencetak gol dalam 3 pertandingan terakhir, maka keputusan yang diambil adalah kita tidak memainkannya kembali untuk pertandingan berikutnya. Padahal kalau kita lihat rekam jejaknya, Ibra bisa mencetak di lebih dari 30 pertandingan sepanjang musim. Dengan prior belief ini seharusnya kita tetap memainkan Zlatan untuk pertandingan berikutnya.

Nah, tapi kalau misalkan hingga 35 pertandingan ternyata Zlatan tidak bisa mencetak gol sama sekali, maka kita sudah mempunyai observasi atau data yang cukup (the likelihood term). Maka keputusan yang tepat mungkin adalah tidak memainkan Ibra kembali.

(Untuk yang familiar dengan teknisnya, kita bisa modelkan peluang Zlatan mencetak gol diambil dari binomial distribution, dan memiliki conjugate prior beta distribution dengan alpha dan beta bisa diambil dengan jumlah pertandingan yang di mana Zlatan mencetak gol di musim sebelumnya) .

(Ini hanyalah contoh belaka, bukan jinx. Penulis sangat berharap Zlatan bisa mencetak banyak gol sehingga MU bisa meraih gelar juara Liga Premier musim ini dan Liga Champion musim depan. GGMU)

Bagaimana contohnya di kehidupan nyata? Misalkan kita mau pasang iklan di berbagai website untuk mempromosikan produk kita. Berdasarkan data dari similarweb kita tahu website mana saja yang mempunyai traffic tinggi. Kita kemudian bisa memasang di beberapa website yang memiliki traffic tinggi. Akan tetapi, setelah beberapa saat kita bisa evaluasi iklan dari website mana yang sebenarnya berhasil meningkatkan metrik penjualan kita. Kira-kira begitu.

Happy data-driving.

git

Theory…

Duluu (sekali) saya pernah menulis sedikiit (sekali) tentang cara pakai mercurial. Karena sekarang saya lebih sering pakai git di tempat kerja saya, maka saya menulis post ini dengan harapan agar tidak cepat lupa dengan perintah-perintah yang biasa dipakai di git dan kalaupun lupa cukup baca satu halaman ini saja biar cepat ingatnya. Tapi sebelum itu mungkin saya kasih sedikit cerita mengenai apa sih sebenarnya git itu?

Sebenarnya tujuan version control system (VCS) software seperti git dan kawan-kawannya itu intinya ada 2. Pertama untuk mengatasi masalah versioning. Dulu pasti pernah kan bikin laporan, terus diberi nama final di nama file-nya. Eh tapi tahunya dari dosennya disuruh ada revisi, yang ternyata tidak ada habis-habisnya, sehingga kita terpaksa membuat banyak file yang dinamai dengan “final rev1”, “final rev2”, “final final” dan seterusnya. Nah dengan VCS ini seharusnya kita cukup punya satu file saja, tapi seluruh sejarah revisi yang dilakukan tetap tersimpan sehingga kita bisa balik ke revisi yang sebelumnya kapan saja (Fitur ini juga ada sih di Microsoft Word, tapi kayaknya enggak banyak yang pakai).

meme
Kalau file dokumen atau kode tidak pakai version control system jadinya bisa seperti ini.

Problem kedua yang berusahan dipecahkan adalah tentang collaborative work. Misalkan kita dan teman kita mau menulis di file yang sama (tapi beda posisinya di dalam file, satu di bagian awal, dan satunya lagi di bagian akhir). Dengan VCS, hasil kerja kita akan digabung secara otomatis dengan kerjaan teman kita. Daripada saling kirim-kiriman email terus lupa file yang mana yang versi terbaru yang akibatnya kerjaan kita bisa hilang atau tertimpa dengan kerjaan teman kita. Salah satu kelemahan dari VCS mungkin adalah dia hanya men-support file dengan format text saja, tidak bisa binary seperti gambar atau video.

Zaman dahulu kala, VCS yang berkuasa adalah subversion. Ini saya pernah pakai waktu kerja praktik. Bedanya dengan git dan mercurial adalah sifatnya yang centralized. Artinya repository-nya sebenarnya hanya ada di satu server, dan setiap kita mau kerja, kita ambil semua file versi terbaru dari server. Ketika kita melakukan edit pada file dan ingin komit, maka kita juga harus mengirim commit-annya ke server tersebut. Akibatnya apabila server-nya mati, atau kita tidak ada akses ke sana (no internet), maka kita tidak bisa kerja sama sekali. Selain itu, menariknya adalah kalau kita mau commit, maka harus cepet-cepetan sama teman kita, karena kalau keduluan maka kita harus fetch, merge, terus commit lagi.

(Sedikit nostalgia. Dulu repository subversion tempat saya menaruh tugas kuliah itu di-host di Google Code yang sekarang sayangnya sudah tutup. Google memang suka resek, punya kebiasaan menutup service secara mendadak (halo Reader, Wave), . Jadi Jangan heran kalau 5 tahun lagi Google+ juga bisa saja ditutup.)

Git dan Mercurial sendiri tergolong ke distributed VCS. Ini artinya setiap kopi repository git merupakan exact copy dari yang ada di server. Kita bisa commit, checkout ke versi sebelumnya, dll, cukup dari repository lokal kita. Kelemahannya adalah di awal proses checkout (atau clone dalam istilah git) itu bisa lama sekali karena semua sejarah commit dari awal sampai akhir bakal dikopi. Untuk repository yang sudah punya sejarah panjang, ukurannya bisa mencapai Gigabyte!

Kalau git sama mercurial (hg) sendiri apa bedanya? Hmm, in general, keduanya memiliki kapabilitas yang sama.  Tinggal tergantung selera kita masing-masing, sama seperti banyak hal lain di komputer (vim vs emacs, tabs vs spasi, dll). Kalau dulu waktu kuliah saya sebenarnya sih lebih suka mercurial, karena repo-nya bisa diakses menggunakan http dari jaringan internet kampus (host di bitbucket) sedangkan git hanya bisa lewat ssh (host di github). Tapi sekarang git sudah bisa http, dan bitbucket sudah bisa host git. Jadi rasanya tidak ada perbedaan yang terlalu berarti.

…and Practice

Oke, kita langsung masuk saja ke cara menggunakan git, untuk basic workflow yang sederhana. Akan ada sedikit penjelasan untuk tiap command-nya biar enggak kayak komik di bawah ini. Sebenarnya untuk bisa berfungsi normal dalam kehidupan sehari-hari cuma sedikit kok command git yang harus dihafal dan dimengerti. Untuk kasus-kasus unik dan menantang bisa diselesaikan dengan bertanya di stackoverflow atau senior programmer di kantor masing-masing.

git
Classic xkcd. Tapi sarannya valid lho, ultimate solution-nya ya memang clone ulang dari awal.

> Pertama, ya instalasi. Kalau di ubuntu gampang tinggal jalanin ini di terminal:

sudo apt-get install git

Kalau Windows dan lainnya bisa lewat installer dari situs resminya https://git-scm.com/downloads.

> Kemudian, setup nama dan email. Cukup sekali di awal.

git config --global user.name "Muhammad Iqbal Tawakal"

git config --global user.email mit.iqi@gmail.com

Tentunya sesuaikan dengan nama dan email masing-masing ya.

> Setelah itu tinggal buat repository baru dari dalam sebuah folder

git init

Atau ambil dari repo yang sudah ada

git clone <repo_address> <target_directory>

> Commit time

Bisa dibilang ada beberapa tingkatan level file di dalam git. Pertama untracked files. Ini adalah file yang tidak di-track oleh git, namun ada di dalam direktori repository. Sebaiknya, semua file yang penting itu di-commit dan sisanya yang tidak penting (temporary files, output log) itu di-list di dalam file .gitignore. Gunakan git add <filename> untuk memasukkan untracked file ke staging area. Apabila file-nya sudah di-track, tapi isinya sudah diubah dari yang terakhir di-commit, itu termasuk ke uncommitted changes. Ini juga bisa dimasukkan ke staging area dengan perintah yang sama.

Semua file yang ada di staging area ini akan di commit ke dalam repository kalau kita menggunakan perintah git commit. Tambahkan parameter -m kalau kita ingin memberikan pesan komit dalam satu baris. Kalau tanpa -m maka git akan membuka text editor di terminal (seperti vim), terus kita harus memasukkan pesan kita di dalamnya. Save file untuk melanjutkan commit. Ilustrasinya bisa dilihat di bawah.

git stages 1
The many (faces) stages of git.

Nah gimana kalau kita berubah pikiran dan mau pindah dari stage atas ke bawah? Sebenarnya git akan memberikan petunjuk kalau kita ketik git status, tapi untuk gampangnya bisa dilihat di gambar berikut. Intinya reset dari staging ke uncommited, dan checkout dari uncommitted changes ke versi commit-annya yang terakhir.

git stages 2
Kebalikannya.

Kenapa modelnya seperti ini? Harus di-add setiap mau commit? Jadi sebuah commit itu sebaiknya adalah 1 self-contained logical changes. Jadi kalau misalkan banyak file yang berubah sejak commit terakhir, kita supervisi sendiri mana file yang akan di-commit dan mana yang tidak, atau nanti dimasukkan di commit yang berbeda. Ini menjaga agar kita tidak (secara tidak sengaja) memasukkan file yang tidak ada hubungannya dengan apa yang sebenarnya mau kita commit. (Di mercurial, setiap commit akan memasukkan semua file yang berubah dari sejak terakhir commit).

Selain itu sebaiknya tiap commit itu tidak mengandung error. Kalau hal terakhir ini sebenarnya bisa di-enforce dengan menggunakan static code analysis tools seperti linter atau dengan code-review dan automatic testing. Mungkin bisa dibahas di post-post berikutnya.

Sedikit tambahan lagi. Untuk melihat apa yang berubah antara files di uncommitted changes dengan versi originalnya di committed revision bisa dengan perintah git diff. Untuk melihat status dari setiap file (sedang berada di stage mana) bisa menggunakan git status. Untuk melihat daftar commit apa saja yang sudah diperbuat, gunakan perintah git log.

And that’s it! That’s all you ever need to know if you want to use git all by yourself on a single machine for versioning. Of course, git offers more features than just for this kind of usage. Keep reading if you’d like to indulge yourself more in the world of git.

> Branching

Branching, atau percabangan, adalah salah satu fitur andalan git agar proses development kita bisa lebih bersih lagi dari error. Gambar di bawah menunjukkan skema branching yang lazim dipakai untuk suatu proses development software. Ada satu branch utama, bernama master, yang berisi kode yang siap release ke production. Active development dilakukan di branch develop yang secara berkala akan di merge ke branch master ketika sudah siap.

branch
Typical development branch. Gambar dikopi dari slide tech talk Salestock.

Setiap kita hendak mengimplemen fitur baru, maka kita buat branch baru dengan nama fitur tersebut yang baru akan kita merge ketika implementasinya sudah selesai. Hal ini akan membuat proses development menjadi lebih rapi, karena semua logical changes dan commit yang memang khusus untuk fitur itu saja terisolasi di dalam satu branch, dan tidak mengganggu developer lain yang hendak mengimplementasi fitur lain.

Perintah git branch akan memunculkan semua nama branch yang ada di repo kita. Kalau kita mau buat branch baru, gunakan perintah git checkout <hash_commit/another_branch_name> -b <new_branch_name> atau hilangkan commit hash kalau kita mau bikin branch baru dari HEAD (HEAD ini menunjuk ke commit atau branch yang sedang aktif di workspace). Kalau mau berpindah-pindah branch, cukup ketik git checkout <branch_name>. Branch yang lama dapat dihapus dengan cara git branch -d <branch_name>.

> Collaborative Work

Sekrang kita akan membahas satu fitur terpenting lainnya dari VCS, yaitu untuk bekerja secara kolaborasi. Pejamkan mata Anda dan bayangkan skenario seperti berikut. Ada satu repository yang terletak di server origin, yang dulu dikerjakan oleh Misty, dan 2 orang developer baru, Ash dan Brock, yang akan melanjutkan pekerjaan yang dahulu sempat terhenti.

git awal
Phase 1: Fresh from the server.

Pertama, Ash dan Brock meng-clone repo tersebut ke laptop mereka masing-masing sehingga sekarang mereka mempunyai complete copy dari repository tersebut. Ash kemudian menambahkan fitur baru dan meng-commit-nya. Agar kerjaannya itu bisa dipakai orang lain, maka Ash melakukan push perubahannya kembali ke origin server dengan melakukan git push origin master.

git tengah
Phase 2: After push

Brock juga tak mau kalah dengan Ash dan juga menambah fitur baru yang berbeda. Namun ketika dia hendak mem-push commit-nya, server origin menolak karena Ash sudah lebih dulu melakukannya. Yang Brock harus lakukan adalah mengambil commit-nya si Ash dan menggabungkannya dengan commit-nya.

git tengah 2
Phase 3: Merging

Perintah yang digunakan untuk mengambil commit baru dari server adalah git fetch. Setelah fetch ada 2 opsi yang bisa dipilih, merge atau rebase. git merge akan menggabungkan 2 commit yang berbeda menjadi dengan membuat commit baru. Sedangkan git rebase akan meng-apply commit kita ke atas commit yang satunya. Sebenarnya ada shortcut yang bisa dipakai, untuk fetch+merge, bisa menggunakan git pull. Sedangkan untuk fetch+rebase bisa menggunakan git pull --rebase.

git akhir
Final phase: Teamwork is beautiful, isn’t it?

Setelah itu Brock bisa mencoba melakukan push lagi dan kali berhasil sehingga  Akhirnya server origin menjadi berisi commit dari 2 orang tersebut, dan siap untuk di-clone orang berikutnya yang akan melanjutkan pekerjaan mereka berdua.

> Tips and Trick

Untuk mempersingkat penulisan beberapa command yang sering dipakai, biar lebih menghemat keystroke dan juga umur, gunakanlah perintah alias. Hasilnya juga jadi lebih mirip command di hg. Misalkan untuk 2 perintah yang paling sering digunakan.

git config --global alias.ci commit

git config --global alias.st status

Kalau yang ini rekomendasi saya untuk dipakai melihat commit tree dalam bentuk grafik di dalam terminalnya langsung. Akan sangat memudahkan untuk mendapatkan mental image dari kondisi repositori sekarang. Apalagi kalau branch-nya sudah banyak dan rumit.

git config --global alias.tree "log --graph --decorate --oneline --all"

Untuk melihat semua shortcut (plus informasi lainnya) bisa dengan:

git config --list

Untuk dokumentasi yang lebih lengkap, dan berisi semua hal yang bisa diketahui dari git, bisa lewat buku progit yang kebetulan full version-nya dibuka di sini: https://git-scm.com/book/en/v2

Kalau butuh visualisasi lebih mendetail untuk operasi-operasi git lainnya, bisa ditilik di tautan berikut: http://marklodato.github.io/visual-git-guide/index-en.html

Wah, jadinya panjang juga. Demikianlah, semoga berguna.

Salam.

Kisah Dua Garis

Ada dua kemungkinan kejadian yang akan dialami oleh 2 buah garis sembarang di euclidean geometry.

images

Pertama, kedua garis itu akan mendekat, terus mendekat, hingga akhirnya bertemu di satu titik, dan akhirnya kemudian menjauh, dan terus menjauh. Mungkin seperti pertemuan 2 manusia, yang sebelumnya tidak kenal, lalu bertemu dan berbagi senyum, tawa, serta cerita. Lantas kemudian berpisah, dan hilang tanpa bekas.

Kisah kedua terjadi pada 2 garis parallel, yang tidak akan pernah bertemu satu sama lain sama sekali, hingga ujung waktu. Mungkin mirip dengan 2 orang yang berbeda pendapat dan tidak pernah bisa menemukan titik temu.

Tapi tahukah kamu, kalau dua buah garis parallel itu pun masih bisa bertemu di satu titik, horison. Kalau mereka berada di projective geometry dengan menggunakan perspective transformation. Ah, mungkin ini petunjuk kalau kita perlu mengubah sedikir perspektif kita agar bisa bertemu pendapat dengan yang lain.

Celotehan acak di tengah malam takbiran.
Karanggede, 5 Juli 2016.

mongo

Di tempat kerja saya sekarang, database yang dipakai adalah MongoDB. Mongodb ini termasuk ke kategori database yang bekennya disebut NoSQL. Karakteristik database ini yang membedakannya dengan database versi relasional, seperti MySQL atau PostgreSQL, salah satunya adalah schemaless. Table (atau Collection) tidak punya skema yang tetap, sehingga tiap baris (atau document) bisa saja memiliki format kolom (atau atribut) yang berbeda.

Kelebihannya yang saya tahu, kalau tidak salah, database tipe seperti ini itu lebih mudah untuk dilakukan replikasi, sehingga lebih memudahkan untuk scaling, apalagi kalau load-nya sudah tinggi, misalkan diakses ratusan ribu kali per detik.

Setelah menggunakan beberapa saat, saya merasa lebih suka sintaks-nya dibandingkan harus menulis sintaks SQL karena lebih mirip menulis kode program seperti biasa. Kekurangannya sih paling kalau query-nya sudah kompleks maka simbol kurung kurawal (curly braces) terlalu banyak sehingga mungkin agak kurang mudah dibaca / readable.

Tapi saya juga menemukan hal-hal yang kurang mengenakkan lainnya.

Pertama, format output dari object-nya adalah BSON (Binary JSON). Mirip JSON, tapi ada tambahan tipe NumberLong untuk angka yang sangat besar. Tapi format NumberLong ini tidak bisa dilakukan komparasi, sehingga dia harus di-cast dulu ke string (“”+NumberLong(123)). Sayangnya untuk angka yang sangat besar (seperti 21 digit), ketika dilakukan cast ke string, angkanya pertama akan dibulatkan terlebih dahulu karena keterbatasan presisi.

Selain itu javascript memang bahasa yang mengesalkan. Penuh inkonsistensi. Masak fungsi getDate() nilainya dari 1 sampai 31, tapi fungsi getMonths() mulainya dari 0 sampai 11. Ini mungkin video paling terkenal untuk memamerkan kebusukan javascript.

Yah, sabar.

Tips Hidup Hemat di Stockholm

Stockholm, dan Swedia secara keseluruhan, merupakan kota dan negara yang mempunyai biaya hidup yang cukup mahal (walau mungkin belum semahal tetangganya Denmark dan Norwegia). Apalagi untuk mahasiswa yang hanya mengandalkan beasiswa dan/atau belum bekerja. Harus pintar2 mengatur pengeluaran agar cukup setiap bulannya.

Berdasarkan pengalaman pribadi saya, ada beberapa teknik yang bisa digunakan untuk hidup hemat di Stockholm. Berikut ulasannya.

1. Hemat beli barang

Terutama untuk mahasiswa yang baru datang, biasanya ada banyak barang kebutuhan hidup yang harus dibeli di awal. Biasanya salah satunya adalah barang perabotan untuk kamar, dapur, dan kamar mandi. Untuk tipe barang seperti ini, jangan lewatkan untuk singgah dan berbelanja pertama kali di IKEA. Ada 2 IKEA di Stockholm, Kungens Kurva di Selatan dan Barkarby di Utara. Silakan pilih yang terdekat.

ikea
IKEA di Stockholm dan cabangnya yang baru buka di Alam Sutra, Indonesia.

Bagaimana dengan barang-barang lain seperti jaket winter dan sepatu? Kalau itu bisa dicari di loppis, semacam garage sale versi orang Swedia, dimana orang-orang banyak menjajakan barang bekas. Meskipun bekas, kualitasnya biasanya relatif masih bagus, orang Swedia biasanya juga jualnya jujur, dan harganya tentu lebih miring dibanding toko, walau harus untung-untungan. Loppis yang digelar di luar ruangan biasanya adanya sepanjang summer, walaupun ada juga yang dilakukan indoor ketika sudah musim gugur.

loppis
Foto poster promosi loppis dan foto contoh dagangan yang dijual.

Bagaimana kalau kelewatan? Untungnya ada toko yang namanya Myrorna. Ini toko barang bekas yang buka sepanjang tahun, walau barang yang dijual biasanya juga mengikuti musim. Sama seperti loppis, di sini kita bisa membeli barang dengan harga yang lebih murah, cuma kekurangannya harga tidak bisa ditawar.

myrorna
Satu dari banyak myrorna yang tersebar di seluruh Stockholm. Saya pernah dapat 2 buah raket badminton dengan harga murah.

Sedikit peringatan, hati-hati kalau misalkan membeli barang bekas yang bersentuhan dengan kulit seperti baju atau kasur karena Stockholm dulu pernah terjadi diinvasi oleh bed bugs, serangga kecil penghisap darah.

Kalau mau lebih hemat lagi, biasanya mahasiswa yang sudah selesai meninggalkan banyak barang yang tidak bisa dibawa pulang ataupun tidak sempat dijual. Barang turunan seperti ini tentunya bisa diperoleh secara gratis. Kontak PPI di kota tinggalmu untuk mendapatkan informasi tentang barang tersebut.

2. Hemat di Swalayan

Berdasarkan hasil observasi saya selama 22 bulan, swalayan Lidl yang aslinya dari Jerman, adalah swalayan yang termurah untuk kebanyakan barang seantero Stockholm. Keluhannya biasanya variasi barang yang tidak sebanyak swalayan lain, dan jumlah dan lokasinya yang lebih jarang, jika dibanding swalayan tandingan macam ICA.

Swalayan di Swedia juga kebanyakan tidak memberikan kantong plastik secara gratis, harus tambah 1-5 kron lagi tergantung ukuran dan bahannya. Oleh karena itu sebaiknya dikumpulkan sehingga lebih hemat dan tentunya ramah lingkungan.

Selain itu, kalau belanja minuman berbotol disini biasanya dikenakan biaya tambahan 1-2 kron, tergantung ukuran dari botolnya. Nah, botol-botol tersebut dikumpulkan, kemudian dimasukkan ke mesin bisa ditukar dengan voucher yang nantinya bisa dipakai belanja di swalayan yang bersangkutan. Lumayan kan.

bottle
Botol-botol sebanyak 1 kantong tersebut dimasukkan ke mesin di tengah, hasilnya 26 kron. Lumayan buat nambah belanja.

3. Hemat makan

Nah, kalau ini memang keuntungan tinggal di kota yang ada KBRI-nya. Ada acara hari besar apapun, Idul Fitri, Natal, HUT RI, biasanya KBRI mengadakan acara dan tentunya ada acara makan-makannya yang jumlahya berlimpah. Bisa buat makan untuk satu hari, apa lagi kalau boleh bungkus. Lebih awet lagi.

Demikian cara yang saya tahu. Apakah dari teman2 pembaca punya teknik lainnya?

Salam.

Beamforming with Kinect

Kinect adalah perangkat pendeteksi gerakan (motion sensing) buatan Microsoft yang awalnya dijual bersama perangkat konsol game, Xbox 360 dan Xbox One, walaupun kini juga sudah dijual terpisah. Kalau melihat sejarahnya, Kinect ini kalau tidak salah dibuat untuk melawan konsol Nintendo zaman dulu, Wii, yang juga support motion sensing tapi menggunakan remote.

Tapi menurut pengamatan saya Kinect ini ternyata kurang laku di pasaran. Buktinya dulu paket ini diwajibkan untuk Xbox One. Tapi sekarang sudah ada paket yang tanpa Kinect dengan harga 100 dollar lebih murah karena orang kurang minat pakai Kinect. Saya sudah coba dua game yang menggunakan Kinect, Kinect sport dan Kinect Star Wars, dan memang agak pegal kalau harus main sambil gerak-gerakin tangan  terus-terusan. Lebih nyaman pakai controller sambil duduk anteng.

Kinect kalau saya bilang malah lebih disambut antusias oleh kalangan akademik yang memakainya untuk berbagai topik riset. Alasannya adalah fitur depth camera dari Kinect yang memang powerful serta harganya yang relatif murah karena diproduksi masal. Misalkan untuk problem localization pada robot, daripada memakai Lidar seperti yang ada di atas Google self-driving car yang mahal, lebih murah jika menggunakan Kinect. Dulu di lab tempat saya jadi asisten di Fasilkom sendiri Kinect dipakai untuk pengenalan bahasa isyarat. Yang tertarik bisa membaca lebih lanjut paper berikut: Spectral domain cross correlation and generalized learning vector quantization for recognizing and classifying Indonesian Sign and Language dan Combining depth image and skeleton data from Kinect for recognizing words in the sign system for Indonesian language (SIBI [Sistem Isyarat Bahasa Indonesia]).

Tapi post kali ini tidak akan membahas lebih lanjut fitur depth kamera dari Kinect, melainkan microphone array untuk melakukan beamforming untuk speech recognition.

Beamforming sendiri adalah teknik untuk mengetahui arah datangnya suara dengan menggunakan lebih dari satu microphone. Harapannya dengan mengetahui arah tersebut, mic dapat difokuskan ke arah tersebut sehingga mengurangi noise yang datang dari arah yang lain. Nah, suara yang lebih bersih dari noise inilah yang kemudian diharapkan akan memberikan performa pengenalan yang lebih baik pada speech recognition.

Untuk menguji hipotesis tersebut, di-settinglah eksperimen dimana suara diambil dari 6 lokasi berbeda dengan menggunakan dan tidak menggunakan fitur beamforming dari kinect. Suara ini kemudian akan dicoba dikenali. Fitur yang dipakai adalah Mel Frequency Coefficient Cepstrum (MFCC) dengan menggunakan Hidden Markov Model (HMM) yang sebelumnya sudah dilatih memakai software HTK.

Hasilnya? ada peningkatan akurasi apabila membandingkan pengenalan kata pada posisi tidak tepat di depan Kinect apabila menggunakan beamforming. Tentunya hasil ini bukan definitif karena eksperimen yang dilakukan masih berskala kecil. Eksperimen dengan skala lebih besar harus dilakukan lagi untuk memverifikasinya. Tapi untuk hasil awal, lumayanlah.

Untuk lebih lengkapnya silakan lihat poster presentasi berikut.

poster_snip

Semoga berguna. Salam.

thrashing

Pernahkah Anda memiliki terlalu banyak pekerjaan yang harus dikerjakan pada satu waktu, terus bingung mau mengerjakan yang mana dulu, dan akhirnya tidak ada yang selesai?

Di komputer, fenomena serupa juga terjadi. Namanya thrashing.

Hal ini terjadi ketika ada terlalu banyak thread yang aktif pada CPU, misalkan karena membuka terlalu banyak aplikasi, sehingga CPU lebih banyak menghabiskan waktunya untuk gonta-ganti proses ketimbang menjalankan instruksi proses itu sendiri. Efeknya yang terasa mungkin adanya lagging ketika menggunakan komputer tersebut. (Oke, definisi aslinya sebenarnya adalah tentang utilisasi CPU dan paging memori, tapi pesan moralnya sama).

Solusinya, ya, jangan membuka aplikasi terlalu banyak atau tambah ukuran RAM.

Begitu juga untuk kasus manusia, kerjakan tugasnya satu per satu karena manusia memang tidak bisa efektif bekerja secara multitasking.

Sekian celotehan malam2.