Saya dan Jordan secara resmi memulai fellowship pada 27 Oktober 2014. Pastinya banyak yang bertanya-tanya, full-time TOKI itu berarti kerja kantoran kah? Kalau iya, memangnya TOKI punya kantor? Pada minggu-minggu pertama, pertanyaan-pertanyaan seperti itu sering sekali ditanyakan oleh para kerabat maupun teman kami, sehingga sebaiknya utarakan di sini juga jawabannya. Jawaban-jawaban ini masih berlaku setidaknya untuk 1-2 bulan ke depan.

TILIL (Tanya Itu Lagi Itu Lagi a.k.a. FAQ) Mengenai IA TOKI Fellowship

Q: Kamu sekarang kerja apa, sih?
A: Saya sekarang ini kerja full time di TOKI.

Q: Lho, memangnya TOKI itu perusahaan gitu ya?
A: Bukan, saya bekerja di Ikatan Alumni TOKI, yakni semacam asosiasi yang menghimpun alumni-alumni TOKI.

Q: IA TOKI kantornya di mana?
A: Belum ada kantor. Saat ini sementara kami bekerja “menumpang” di kantor Agate Studio, Bandung.

Q: Terus kamu di sana kerjanya jadi apa? Ngapain?
A: Saat ini kami sedang mengembangkan platform pembelajaran programming untuk siswa-siswi di Indonesia.

Dengan banyaknya impian yang ingin dikerjakan, tentunya harus disusun prioritas dan jadwal. Berhubungan dengan Q/A terakhir, untuk bulan-bulan pertama kami ingin fokus membenahi TLC.

Setup Domain

Pertama-tama, tentu IA TOKI harus punya domain sendiri. Setelah didiskusikan, diputuskan bahwa domainnya harus berbeda dengan toki.or.id, karena itu adalah domain untuk TOKI sedangkan kegiatan ini adalah kegiatan IA TOKI. Maka, diputuskanlah untuk membeli domain ia-toki.org.

Setelah memiliki domain, langkah berikutnya adalah memiliki email “kantor” untuk kami berdua. Sayangnya, Google Apps sudah tidak gratis lagi (dulu gratis untuk 10 email). Alternatifnya, kami menggunakan Zoho Mail, yang juga gratis untuk 10 email. Email kantor kami adalah ashar.fuadi@ia-toki.org dan jordan.fernando@ia-toki.org. Kami menggunakan email ini untuk berkorespondensi satu sama lain mengenai urusan IA TOKI.

Setup Server

Selama ini, development maupun production TLC berada pada server yang dipasang di ITB. Akan tetapi, kami sudah sering memiliki pengalaman buruk: ITB sering mati lampu! Dan biasanya, ITB mati lampu di saat-saat kritis: pernah saat H-semalam kuis/simulasi sehingga tim scientific tidak bisa mempersiapkan soal di TLC, bahkan pernah juga saat simulasi terakhir Pelatnas 3. Kami tidak mau hal ini terjadi juga selama development, sehingga kami mencari alternatif lain.

Alternatif berikutnya adalah menggunakan server (Fasilkom) UI. Kepala IT Fasilkom UI berbaik hati untuk menyediakan virtual server untuk kegiatan TOKI. Namun, terdapat keterbatasan: SSH hanya bisa dilakukan pada jaringan internal UI, sehingga hanya saya yang bisa login ke servernya untuk melakukan setup-setup. Ditambah lagi, ternyata port-port yang diperlukan banyak yang ditutup, sehingga ada beberapa hal setup krusial yang tidak bisa dilakukan.

Berikutnya, ada wacana untuk memindahkan server-server yang ada di ITB ke Indonesia Data Center agar server bisa bersifat always on karena (seharusnya) tidak pernah mati lampu. Masalahnya adalah, server-server yang ada di ITB itu sebenarnya adalah hibah pemerintah, sehingga untuk memindahkannya tidak bisa cepat karena butuh perizinan kementerian dan lain-lain.

Jadi bagaimana solusinya?

Setelah mengalami berbagai masalah dengan “server gratisan”, kami mulai mencoba melirik alternatif penggunaan server berbayar. Pada akhirnya, kami mencoba memakai server di AWS, menggunakan paket Free Tier yang gratis setahun. Untuk pendaftaran AWS dibutuhkan kartu kredit. Karena kami berdua belum memiliki kartu kredit, kami mendaftar menggunakan kartu kredit Brian. Kami rasa ini memang keputusan yang paling tepat setidaknya untuk sekarang. Namun, kami belum tahu nanti bagaimana pendanaan untuk tahun-tahun berikutnya 😀

Setup Project Management

Karena kami ingin pengembangan TLC ini seprofesional mungkin, kami ingin menggunakan sistem untuk issue tracker dan code review. Untuk issue tracker, saya sendiri sudah mencoba eksplorasi menggunakan Trello dan Asana versi gratisan. Untuk code review, saya pernah menggunakan Gerrit dan GitHub. Semuanya ada plus minusnya tersendiri.

Lalu, kami mendengar masukan dari beberapa teman untuk menggunakan Phabricator. Setelah kami mencobanya, ternyata asik juga! Phabricator memiliki banyak subaplikasi yang mendukung semua kebutuhan kami. Saya pun tertarik dengan dokumentasinya yang fun, misalnya:

Maniphest
Keep track of tasks and bugs, but not insects.

Conpherence
Group messaging, but you have to manually refresh. It’s like 1999.

Menarik bukan? Setelah saya baca-baca, pembuat Phabricator memang ingin memasukkan rasa fun ke dalam manajemen software yang ia anggap membosankan. Dan setelah kami pakai, Phabricator ini memang tidak hanya fun, tapi juga memang powerful.

Setup Continuous Integration

Saya merasa bersyukur pernah intern di Palantir selama 3 bulan. Selama di Palantir, saya mendapatkan banyak sekali pengalaman baru mengenai software engineering, salah satunya mengenai continuous integration. Di Palantir, saya merasa tidak perlu khawatir kode saya merusak codebase karena kode saya melewati banyak tahap verifikasi sebelum akhirnya di-merge ke dalam codebase. Tahapannya kira-kira sebagai berikut:

• Setelah seorang developer selesai menyelesaikan suatu fitur, kodenya dicek kesesuaian style kodenya terhadap suatu standar yang telah disepakati oleh tim. Dengan cara ini tidak ada kode yang berantakan dan menyalahi standar.
• Setelah itu, kodenya dicek pula kebenarannya dengan cara dijalankan unit test pada server.
• Jika keduanya sukses, kode direview secara white box oleh peer developer.
• Setelah peer developer OK, barulah kode di-merge ke codebase.

Saya ingin membawa budaya yang baik ini pada IA TOKI karena saya benar-benar merasakan manfaatnya selama di Palantir. Oleh karena itu, pada bulan pertama ini saya ingin menginvestasikan waktu untuk mengimplementasikan semuanya agar pengembangan kode berjalan dengan teruji dari awal sekali.

Langkah pertama adalah instalasi Jenkins untuk menjalankan unit test secara otomatis pada server. Ternyata ini saja pun tidak berjalan mulus: pada awalnya kami tidak bisa menjalankan unit test sama sekali. Setelah dicek-cek, rupanya hal ini disebabkan RAM instance AWS kami yang terlalu kecil, yakni hanya 1GB (maklum versi gratisan). Kami pun mulai mencari-cari cara mengakalinya, seperti mencari cara mengurangi pemakaian memori pada sistem build yang kami pakai (Activator), namun tetap tidak berhasil. Setelah hampir putus asa, Jordan berhasil menemukan solusi yang langsung berhasil: memasang partisi untuk swap memory pada server.

Langkah berikutnya adalah menyepakati style kode yang akan dipakai untuk TLC. Untuk hal ini, kami menggunakan Checkstyle untuk meng-enforce aturan-aturan style. Kami menghabiskan beberapa waktu untuk berdiskusi aturan-aturan mana yang ingin dipakai. Hasilnya, memang totally worth it: Checkstyle banyak menangkap kesalahan style selama pengembangan, dan hasilnya source code menjadi sangat rapi.

Nah, kemudian langkah paling penting adalah setup integrasi antara Phabricator, Jenkins, Activator, dan Checkstyle agar semua proses di atas terotomatisasi. Hal ini rupanya tidak mudah karena setelah saya cari-cari di internet, belum ada yang mengimplementasikan semua ini dan di-publish. Jadi, saya sendiri menginvestasikan waktu beberapa minggu untuk mempelajari API masing-masing komponen tersebut dan menulis kode integrasinya. Dan berhasil! Mungkin nanti akan saya tulis proses dan kodenya pada blogpost terpisah, siapa tahu yang lain ada yang berminat mengimplementasikannya juga

Setup Wiki

Seperti yang telah disampaikan pada postingan sebelumnya, kami ingin agar setiap proses terdokumentasi dengan baik dan terpusat. Untuk itu, perlu dipasang sebuah situs yang berfungsi sebagai knowledge base. Terdapat beberapa kandidat, seperti MediaWiki, TWiki, dan subaplikasi wiki dari Phabricator sendiri yang bernama Phriction. Saya pun melakukan riset kecil-kecilan di internet mengenai kelebihan dan kekurangan dari semuanya. Akhirnya saya mencoba untuk memakai TWiki.

Kemudian, tiba-tiba Jordan menemukan suatu artikel yang menyatakan bahwa terdapat successor TWiki yang bernama Foswiki! Successor di sini artinya, menurut artikel tersebut, TWiki sudah tidak terlalu dikembangkan lagi, dan banyak pembuat TWiki yang beralih mengembangkan Foswiki. Akhirnya, kami memutuskan untuk mengganti TWiki dengan Foswiki.

Dengan adanya wiki ini, kami mulai menulis dokumentasi informasi terkait IA TOKI sedini mungkin supaya tidak tercecer. Misalnya, informasi akun admin Phabricator & Jenkins dkk, informasi alamat IP AWS, dan lain-lain. Kami juga sudah mulai menulis panduan untuk alumni-alumni lain yang ingin berkontribusi sebagai developer selanjutnya. Panduannya meliputi setup subaplikasi Phabricator untuk code review (Arcanist) serta alur pengembangan dan code review.

Dokumentasi, Dokumentasi, Dokumentasi

Pada wiki tersebut juga, kami mulai sedikit demi sedikit menuliskan dokumentasi desain TLC yang baru secara komprehensif. Hal inilah yang selalu terlewat pada pengembangan tahun-tahun sebelumnya. Dokumentasi ini meliputi diagram-diagram komponen, Gantt Chart, desain skema basis data, deskripsi komponen-komponen TLC, dan lain-lain.

—

Kesimpulannya, pada bulan pertama ini kami fokus pada setup segala hal yang mendukung pengembangan apapun di IA TOKI, tidak hanya TLC. Tentu saja dibarengi dengan memulai pengembangan TLC secara hampir paralel. Semoga dengan investasi waktu yang tidak sedikit ini, ke depannya proses pengembangan menjadi lebih efektif dan efisien 😀