Thursday, July 30, 2015

Internet of Things, Opo Kuwi?

Belakangan ini aku sering mendengar istilah Internet of Things, tapi gak gitu paham apa maksudnya. Sejauh ini sih aku cuek saja, toh belum bersinggungan dengan pekerjaan. Akhirnya pagi ini tertarik dengan satu link video yang memberi penjelasan tentang IoT ini.


Intinnya adalah  benda-benda bisa berkomunikasi satu sama lain lewat internet, bahkan tanpa campur tangan manusia. Apakah ini hal baru? Tergantung definisi barunya sejak kapan, yang jelas sih kalau di film-film sudah sering kita tonton kisah-kisah fiksi tentang teknologi ini.

Tapi sekitar 10 tahun lalu aku sudah sempat mendengarkan cerita dari Pak Bagus Mahawan tentang hal ini. Hanya saja waktu itu istilah IoT belum ada.

Dalam sebuah perjalanan penuh macet menuju pertemuan dengan salah satu client di Jakarta, pak Iwan berkisah tentang apa yang sedang terjadi di Jepang. Terkesan bahwa saat ini mereka sedang stagnan dalam perkembangan teknologi, dan mulai kalah dengan negara lain. Makanya mereka sedang mengembangkan konsep IT yang disebut dengan ubiquity. Kurang lebihnya itu lah. Intinya teknologi yang akan menghubungkan peralatan-peralatan, bisa rumah tangga atau dimanapun.

Misalnya ada kulkas yang bisa mendeteksi stok susu. Jika susu sudah habis, atau hampir habis, sistem di kulkas itu akan memberi informasi ke pemilik. Atau bisa langsung menghubungi pihak supermarket tertentu untuk memesan susu secara otomatis. Obrolan yang cukup menarik waktu itu karena penggunaan teknologi yang cerdas dan tepat bisa sangat mempermudah dan memanjakan hidup.

Tapi di satu sisi aku juga pesimis, dari sisi keamanan. Adanya integrasi system, apalagi kalau sampai terhubung ke internet, berarti akan memungkinkan celah untuk hacker atau pihak lain untuk menerobos sistem dan ngobok-obok semua perangkat yang terhubung. Apa gak bahaya? Kebanyakan nonton film tentang hacker, apalagi yang terakhir dari Fast and Furious 6 soal God's Eye :)

Di luar masalah pesimis, tampaknya IoT adalah hal lain yang akan berkembang dan perlu dipertimbangkan kalau ingin selalu uptodate dengan perkembangan teknologi.

Tuesday, May 26, 2015

Foto-Foto Dalam AWS Summit 2015, Singapore


Meja registrasi acara AWS Summit 2015 di Singapura masih tampak lenggang karena acara baru akan dimulai sekitar satu jam lagi. Aku datang agak awal karena janjian dengan teman, yang mengundangku ikut acara ini. Mumpung gratis katanya, siapa tahu bisa nambah ilmu dan nambah koneksi. Lagipula aku sedang tidak terlalu sibuk, jadi ya ikutan saja. Acara berlangsung seharian di Raffles City Convention Center, lantai 4.

Aku bukanlah pengguna aktif AWS, karena bagiku layanan mereka terlalu mahal. Tapi karena kantor dulu beberapa kali menggunakan layanan AWS, khususnya layanan EC2, ya sedikit banyak aku tahu lah. Tapi ya sebatas EC2 saja, lebih ke server hostingnya. Padahal sebenarnya layanan dari AWS itu ada lebih banyak lagi, sampai aku bingung dengan banyaknya menu yang ada. Karena merasa tidak perlu, aku malas belajar sendiri. Nah dengan adanya acara ini, setidaknya aku dapat overview tentang produk-produk AWS itu, siapa tahu suatu saat dibutuhkan.


Saat acara baru akan dimulai, ruangan belum 100% terisi, masih banyak tempat kosong. Tapi menariknya, saat acara berlangsung, mulai padat.

Acara ini menurutku adalah bentuk promosi Amazon Web Service di ASEAN, termasuk promosi rekan-rekan bisnisnya. Kalau dilihat di jadwal acara, sebagian besar acara diisi oleh sponsor mereka. Meskipun demikian, acara seperti ini, kalau memang berkualitas, akan menguntungkan kedua belah pihak. Bagi peserta, bisa dapat pengetahuan gratis serta kesempatan untuk konsultasi gratis dengan para ahlinya, meskipun hanya sebentar, juga bisa menambah jaringan bisnis. Bagi AWS dan para sponsor ya jelas, mereka bisa mempromosikan bisnisnya.


Satu hal lagi yang membuatku tidak merasa rugi ikut acara ini adalah makan siang dan coffee break yang gratis. Hidup gratisan hehehe... Jarang-jarang bisa dapat sajian makan sekelas hotel berbintang, gratis dan bisa makan sepuasnya.


Di akhir acara juga ada pembagian doorprice, baik dari AWS sendiri maupun dari masing-masing sponsor. Tapi memang sejak awal aku gak berminat mengikutnya karena selama ini tidak pernah beruntung kalau soal lucky draw. Tapi aku dan temanku tetap mengikuti acara hingga akhir, penasaran saja. Hadiah yang diberikan bervariasi, mulai dari voucher AWS, paket liburan, hingga gadget terbaru, bahkan ada juga perhiasan emas.

Berikut beberapa foto selama kegiatan, iseng-iseng saja buat kenangan, meskipun gak ada nama yang akrab buatku.

Richard Harsman, Head of ASEAN, AWS

Stephen Orban, Head of Enterprise Strategy, AWS

Ernest Cu, President & CEO Globe Telecom (Filipina)

Rajesh Lingappa, Redmart

Brendan O'Neill, SEACO

Baru tahu soal Amazon Aurora, database engine buat nyaingin MySQL, yang tersedia sebagai salah satu bagian layanan RDS (Relational Database Service)

Marcelo Wesseler, CEO SingPost eCommerce Pte Ltd

Glenn Gore, APAC Solution Architect Manager, AWS. Dia menjelaskan sedikit tentang big data, termasuk salah satu produk baru Amazon Learning Machine.

Anindo Sengupta, Minjar (Sponsor)

Chris Hampartsoumian, Technology Evangelist, ASEAN AWS, menjelaskan tentang dasar-dasar produk AWS. Nah, dengan begini jadi lebih paham secara garis besar apa saja produk AWS. Ternyata banyak dan cukup menarik.

Dhruv Parpia, Solution Architect, ASEAN, AWS.

Menjelaskan tentang mobile development dengan menggunakan produk-produk AWS, seperti Cognito, Lambda, Mobile Analytics, SNS dll. Salah satu keynote favoritku.

Sivaram Shunmugam, Manager, Infrastructure Practice, Redhat.

Keynote ini membuatku tahu (meski belum paham), tentang container, salah satunya yang populer adalah Docker. Sepertinya teknologi ini pantas untuk dipelajari.

Russell Nush, Solution Architect, AWS
Secara keseluruhan aku cukup puas ikut acara ini, apalagi gratis dan dapat makan juga. Di akhir acara juga dapat botol minum gratis hanya dengan menyerahkan feedback form. Pokoknya puas karena gratis lah :)

Wednesday, August 27, 2014

Soal Test Class di Salesforce.com

Sumber gambar: force.com
Aku adalah penganut falsafah "learning by doing", artinya lebih suka untuk praktek langsung daripada repot baca teori. Ini berlaku juga saat membeli barang baru, langsung utak-atik tanpa mau repot-repot membaca buku petunjuk penggunaan. Termasuk saat belajar pengembangan aplikasi di Salesforce.com (force.com). Seminggu pertama baca-baca dan mengikuti tutorial sangatlah membosankan, dan baru semangat ketika terjun langsung dalam proyek, dan belajar dengan mencontek hasil kerjaan orang lain. Akibatnya, tidak memiliki dasar yang mendalam.

Termasuk dalam hal membuat testclass. Selama ini aku anggap testclass hanya sebagai basa-basi, formalitas agar aplikasi bisa di-deploy ke production. Soalnya system mewajibkan minimal code coverage 75%, baru bisa di-deploy. Tentu saja ini hal yang menjengkelkan dan membuat frustrasi. Hal ini diperparah dengan kebiasaanku yang tidak pernah membaca teori tentang test class ataupun cara yang benar untuk membuat test class. Jadinya asal jadi saja, yang penting bisa di-deploy.

Masalah muncul ketika kerumitan memperoleh code coverage dikombinasikan dengan adanya berbagai governor limit, terutama SOQL limit. Secara standard, dalam satu alur eksekusi, salesforce membatasi hanya boleh ada 100 kali query untuk mengambil data (SELECT). Ini termasuk query yang terjadi dalam trigger, yang mungkin memicu rangkaian trigger dari object lain yang terpengaruh. Oke lah, dalah prakteknya aku bisa paham, karena sifatnya multi-tenant, jadi masing-masing tidak boleh mendominasi resource. Tapi ini kan cuma test class.

Kejengkelanku bertambah karena ternyata di dalam test class, penerapan governor limit itu merupakan akumulasi dari seluruh proses awal. Jadi misalnya aku ada melakukan insert record untuk 3 object berbeda, selama itu masih dalam satu fungsi testclass, akan dianggap sebagai satu eksekusi proses dan akumulasi penggunaan resource akan dikontrol dengan governor limit. Padahal dalam prakteknya, sangat mustahil proses itu berjalan sekaligus. Biasanya user akan insert record A, kemudian pindah menu untuk insert record B, dan terakhir pindah menu untuk insert record C. Jadi dalam prakteknya akan ada 3 eksekusi, yang masing-masing memiliki penggunaan resource yang terpisah. Payahnya, seringkali aku harus membuat testclass untuk object X, dimana untuk bisa membuat record object X itu perlu terlebih dahulu dibuat record untuk object A, B, C, D dst. Pokoknya prosesnya panjang. Kadang baru sampai di pembuatan record D saja sudah mentok kena governor limit.

Salah satu cara untuk mengakali adalah dengan memanfaatkan @isTest(SeeAllData=true)   supaya bisa memanfaatkan data yang sudah ada untuk membuat test class bagi trigger/class yang aku buat. Keuntungannya adalah aku tidak perlu melewati tahap insert record  A, B, C karena asumsi record sudah ada. Kekurangannya jelas kita harus memastikan bahwa data untuk dipakai itu sudah ada, kalau gak ada ya test classnya jadi mubazir, dan ujung-ujungnya bisa gagal mencapai code coverage 75%. Sejauh ini teknik ini banyak membantu. Teknik lain adalah dengan memecah-mecah test class menjadi beberapa fungsi testclass, karena setiap fungsi akan di-reset perhitungan governor limitnya. Ini juga cukup membantu, asalkan alur prosesnya tidak terlalu panjang.

Tapi hari ini aku kembali mentok, gara-gara kena governor limit. Padahal sudah pakai SeeAllData, dan prosesnya pun tergolong pendek. Entah kenapa tetap saja kena query limit. Iseng-iseng aku nyeletuk di twitter, eh kok ada yang membalas, katanya soal test class itu cuma masalah pengalaman, kalau sudah terbiasa akan menjadi "piece of cake". Busyet .... pengen lempar asbak rasanya. Untung aku gak ngerokok :D

Setelah hampir seharian ngoprek, sampai lebih dari 10 kali mencoba melakukan deployment dan masih gagal, aku coba cari solusi di internet. Di situlah aku nemu tentang fungsi startTest() dan stopTest(). Lebih lengkapnya Test.startTest() dan Test.stopTest(). Rupanya aku bisa menggunakan ini untuk menentukan bagian mana yang aku anggap untuk testing, dan saat mulai memanggil startTest itu, perhitungan governor limit akan di-reset. Jadi aku bisa mengumpulkan data dulu, bikin record A, B, C misalnya, baru waktu mau mulai bikin record X, aku panggil startTest(). Dan hasilnya .... mujarab! Masalah governor limit teratasi. Jadi sekarang aku punya 3 senjata :

  1. Menggunakan SeeAllData=true
  2. Memecah menjadi beberapa fungsi testclass
  3. Menggunakan StartTest dan StopTest


Oh ya, sepertinya aku harus lebih banyak baca teori. Jadi mendingan aku salin saja "Testing Best Practice" sebagai pengingat (dengan sedikit improvisasi, bukan sekedar terjemahan)

  1. Capailah coverage sebanyak mungkin, untuk setiap kelas. Jadi jangan hanya mengandalnya total rata-rata, yang minimal 75%
  2. Jika ada logika kondisi (if, case dsb), usahakan untuk membuat test class untuk setiap kondisi
  3. Lakukan pemanggilan fungsi dengan inputan data yang benar maupun yang tidak benar
  4. Pastikan testclass tidak menghasilkan error, kecuali kalau errror itu bisa dijebak dengan benar (tidak menimbulkan fatal error)
  5. Pastikan menangani setiap peluang kesalahan (exception) dengan benar, tidak hanya menjebaknya.
  6. Gunakan metode System.assert untuk memastikan kode program berperilaku dengan benar
  7. Gunakan metode RunAs untuk melakukan pengujian dengan berbagai profil yang berbeda
  8. Latih dengan menggunakan data yg banyak, minimal 20 record dalam testing yang dibuat
  9. Gunakan ORDER BY untuk memastikan hasil yang diinginkan dalam urutan yang sesuai
  10. Jangan berasumsi bahwa Record ID itu pasti berurutan
  11. Kumpulkan data yang diperlukan sebelum membuat kode untuk testing, dan setelah itu baru panggil fungsi Test.startTest().
  12. Buat komentar selengkap mungkin, tidak hanya tujuan pengujian, melainkan juga data awal dan data akhir yang diharapkan, perkecualian dan lain-lain.
  13. Buat test class untuk masing-masing kelas secara terpisah, jangan hanya membuat satu test class untuk seluruh aplikasi.
Setidaknya dalam 3 tahun pengalaman ngulik force.com ini, sudah 50% dari saran-saran diatas yang aku ikuti hehehe..... perlu lebih disiplin lagi nih :)

Update:
Ada satu fungi yang belakangan aku temukan adalah Test.isRunningTest(), untuk mengetahui apakah yang menjalankan code adalah program test atau bukan. Jadi ada baiknya, di class/trigger yang menggunakan penggalan code yang tidak bisa ditest, seperti callout, diabaikan saat test.