Choosing the right tech stack might make or break your tech startup. Apparently, this is easily overlooked and I witness too many early-stage tech startups failed or need to pay an expensive cost for this reason. When we have a solo developer who proficient and productive in one language or technology, then most of the time that’s the best option. But when we have the freedom to choose which programming language or stack, in the beginning, choosing the right technology is crucial.

There’s a lot of angles to be considered, and “popularity” and “performance” unfortunately are the major factor people use to consider. Just because big tech startup uses language “x” often is the worst reason.

Big tech company usually have a very specific problem related to scalability or modularity. That’s not the case with an early-stage startup where their focus should be productivity and time to market. This is why “popularity” is not a really valid reason to be considered. The most popular stack is not necessarily the best indicator. Finding the developer might be easier but as long as there’s a reasonable resource to learn, any good developer can pick up almost any technology these days.

Performant language or stack is rarely hand-in-hand with productivity. Building Single Page Application, while it is performant is usually overkilled for an MVP. It takes longer to build, it needs to keep up with updates, and hard to get it right. Going microservice architecture also creates another pitfall which leads to the necessity of bigger tech team, and longer delivery time and it hurt when the business still struggles to find the market fit for the product.

Tech startup usually races with time and available budget. And while developers are generally expensive, productivity and maintainability supposed to be the most aspect to be considered.

This paper published in 2017 tries to measure Economic Metric Across over 70 Programming language on which one provides more economic value per hour on average.

TLDR: The higher the language from the machine language tends to bring more economic value per hour.

https://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty-years-of-IFPUG.-Software-Economics-and-Function-Point-Metrics-Capers-Jones.pdf

The more process you have, the less talent you have. The less talent you have, the more process you need.

(Reed Hasting of Netflix as quoted by Bill Scott in one of his lecture about Lean UX)

I used to work for Allianz where my role was to evaluate the operational business process and SOP to see if there’s any room for improvement and automation. It almost hardwired in me and most people that, process (procedure, SOP, and the like) is good for the company. No question asked.

But as I grow into a typical “move fast, break things” software developer, and live trough various tech startup culture, I develop a certain sense against the process, like a kid against their vegetable. I hate it, many good programmers hate it, but nobody says anything because its “the right thing to do”.

It’s getting harder and harder to ship new feature out because of series of design review, user behavior analysis, 4 different QA process where each of them could potentially delay or throw the entire feature out the window.

At tech startup organization you started by aggressively ship product and features. Then the organization start brings a lot of experienced people from the corporate world to “teach” how things should be organized, introducing a lot of processes.

It’s not an uncommon story where the process creation started to happened just for the sake of making a process. They didn’t aware how it could paralyze the product pipeline and extend the product iteration lifecycle, or even worse: paralyze product shipment and innovation.

So generally its a good idea to grow a skepticism every time a new process is introduced. We can also grow several strategies around it to make the process less necessary.

For example, it is beneficial to try to have as few as possible in the team. Hire the best people we can find. When we have good people, we don’t need many people and less communication problem. We don’t waste time in the communication chain. And when we have good people, we can trust them to make a decision, cut down the standard process, and have a quicker iteration.

After all, we working in a tech industry where innovation is the heart.

Sebelum diprotes para Devops, perlu dibuat disclaimer dulu bahwa ini tentu tidak 100% Apple to Apple. Tapi konteksnya akan coba dijelaskan sejelas mungkin.

Berawal dari keisengan membuat elixir library untuk generate SVG avatar yang support Colour hash dan generate inisial nama, perlu rasanya untuk sekalian dibuatkan websitenya agar bisa digunakan bagi siapapun yang membutuhkan. Jadi harapannya developer manapun dengan bahasa pemrograman apapun bisa menggunakan fitur itu.

Contoh layanan gratis yang sudah ada adalah : https://ui-avatars.com/.

Yang bisa kita improve dari layanan tersebut adalah:

1. Kita bisa membuat hash function untuk memberikan warna background yang unik, tergantung nama yang diberikan.
2. Alih alih mengghasilkan PNG, idealnya kita bisa men-generate SVG agar lebih cepat waktu loading dan tidak pecah saat diperbesar.
3. Idealnya menyediakan beberapa style yang berbeda.
   
   Hasilnya bisa kita lihat di : http://avatar-api.org

Untuk menggunakannya kita tinggal melempar paramerter seperti name, size, set, color terhadap https://avatar-api.org/avatar.svg

Karena ini layanan gratis dan (sebisa mungkin) tanpa iklan, kita akan menggunakan cloud vm paling murah yang disediakan oleh Digital Ocean. Dengan 5$ kita mendapat mesin 1 core dan RAM 500 MB.

Kebetulan, di kantor kita sedang melakukan banyak benchmarking karena kita lagi mencoba me-rewrite legacy api menggunakan golang. Kenapa Golang? Karena mendapatkan programmer yang memiliki pengalaman di Golang relatif lebih mudah, sementara Erlang jauh lebih sulit.

Meskipun dalam banyak benchmark menunjukkan hasil performance yang seimbang antara Golang dan Erlang, Erlang process menggunakan lebih banyak CPU. Golang lebih portabel, lebih mudah ditempatkan di mana mana, memiliki footprint yang kecil setelah dicompile. Sementara Erlang? Aplikasi Erlang hanya berjalan di Erlang Virtual Machine, seperti Java yang hanya bisa berjalan di JVM. Nah, VMnya lah yang ngurus segala hal sehubungan dengan manajemen resources sehingga membuat dia hampir tidak bisa mati. Sementara itu Golang bergantung pada tekhnologi lain untuk bisa hidup kembali saat crash seperti Kubernetes.

Sama seperti Java Virtual machine yang bisa ditulis pake bahasa lain seperti Clojure, Erlang VM bisa ditulis menggunakan beberapa bahasa seperti LFE, MLFE, dan Elixir. Kita menggunakan Elixir karena syntaxnya yang lebih manusiawi.

Aplikasi

Kita tidak ingin melakukan benchmark hanya sebatas mengeluarkan static output semacam “hello world” (dan di hit dari localhost) seperti yang banyak dilakukan benchmark lain. Di paragraf berikut kita akan menjelaskan apa yang terjadi saat setiap request diterima oleh server.

Setiap user melakukan request ke Https://avatar-ui.org/avatar.svg, berikut dengan parameter-parameternya, sistem akan melakukan parsing parameter, dan jika tidak ditemukan maka default options seperti color, size dan text akan digunakan. Ada beberapa operasi matematika yang kemudian dilakukan agar proporsi border, text, dll sesuai dengan ukuran yang diberikan. Men-generate inisial nama juga memerlukan beberapa operasi pada string. Terakhir, untuk men-generate warna, dilakukan operasi hash (md5), diambil beberapa karakter pertama, di-convert semua menjadi angka, dikalikan satu sama lain, dan dimasukkan dalam fungsi rem(359) agar hasil akhirnya tidak lebih dari 359 (sesuai dengan hue range), semua hasil operasi ini dimasukkan kedalam template SVG sesuai yang dipilih.

Kesimpulannya: meskipun tidak berhubungan dengan database, operasi yang dilakukan untuk setiap request bukanlah hal yang trivial.

Deployment dan Optimisasi Server
Tiba saatnya deployment. Sesuai yang sudah disebut diatas, kita akan men-deploy aplikasi ini ke dalam Ubuntu Server 1 Core dengan Memori 512 MB seharga 5$ per bulan dari Digital Ocean. Walaupun idealnya kita meng-compile sebagai BEAM release, kali ini kita hanya menjalankan mix dengan ENV=production ini memastikan tidak ada proses yang tidak perlu seperti live reloading yang hanya berguna pada development environtment. Dan walaupun sebenarnya Erlang VM mampu jalan bagus tanpa webserver tambahan, kita gunakan Nginx untuk dijadikan reverse proxy serta agar konfigurasi letsencrypt menjadi lebih mudah.

Beberapa optimisasi juga dilakukan. Dari sisi Erlang VM, kita set logger menadi error only. Dari sisi Nginx, gzip kita matikan. Ini karena target file keluaran kita adalah 400 byte atau dibawah 1 Kb. Jika Gzip kita aktifkan untuk output sekecil ini maka akan memperlambat proses dan justru menambah ukuran file karena ada metadata yang dilampirkan.

Metode testing

Kita akan simulasikan ribuan user mengakses url tersebut di saat yang bersamaan. Agar adil, requestnya tidak melalui localhost. Baik server yang di test atau melakukan serangan berada di region yang sama (Singapore). Selagi target ada di Digital Ocean, Server penyerang ada di Google Cloud Platform dengan kekuatan 4 Core.

Mengenai testing tool yang digunakan, ada beberapa yang bisa dijadikan pilihan. Secara default kita punya Apache Benchmark. Tapi konon AB tidak menggunakan semua core yang ada. Ada juga Jmeter yang berbasis GUI. Ada locust tapi kesulitan saat harus menghitung sendiri TPS ideal berdasarkan failed ratenya. Kali ini kita akan menggunakan wrk. Wrk banyak digunakan karena cukup praktis untuk mendapatkan gambaran ketahanan server. Wrk secara sederhana hanya menghitung berapa request yang sukses lalu dibagi durasi waktu penyerangan. Lebih simpel karena kita langsung mengetahui berapa maksimum Request per Second yang mampu dihandle sebuah server. Ada juga informasi mengenai latency dan berapa ukuran file yang dihasilkan di setiap request.

Command option yang digunakan :

wrk -t8 -c50 -d10s url-tujuan

Artinya kita menggunakan 8 thread, masing2 mencoba spawn 50 koneksi secara bersamaan dan dilancarkan selama 10 detik. Semua website yang kita test akan menggunakan setting ini.

Hasilnya

Pertama kita lihat dulu pesaing kita memiliki konsep yang sama: ui-avatar.com

Aplikasi ini memungkinkan kita untuk mengenerate avatar hanya melalui GET parameter. Bedanya adalah format file yang dihasilkan yakni PNG yang secara signifikan lebih besar dan kurang optimal untuk web.

root@locust-testing:/home/indodax# wrk -t8 -c50 -d10s https://ui-avatars.com/api/?name=John+Doe
Running 10s test @ https://ui-avatars.com/api/?name=John+Doe
8 threads and 50 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 295.75ms 6.97ms 349.48ms 87.76%
Req/Sec 21.02 11.78 50.00 79.61%
1389 requests in 10.02s, 1.72MB read
Requests/sec: 138.64
Transfer/sec: 175.60KB

Hasilnya adalah 138 request per detik dengan latency sekitar 7 milisecond per request.

Lalu kita bandingkan dengan jagoan kita :

root@locust-testing:/home/indodax# wrk -t8 -c50 -d10s http://avatar-api.org/avatar.svg
Running 10s test @ http://avatar-api.org/avatar.svg
8 threads and 50 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.78ms 661.53us 21.67ms 93.76%
Req/Sec 3.41k 185.27 3.93k 70.11%
272862 requests in 10.10s, 106.95MB read
Requests/sec: 27016.57
Transfer/sec: 10.59MB

Hasilnya adalah 27 Ribu Request per detik! Setiap requestnya rata rata hanya perlu menunggu 661 nano second! (1 nano second = 1000 micro second, 1000 micro second = 1 second). Hampir dua ratus kali lebih kuat dan sepuluh kali lebih cepat dari kompetitornya.

Sayangnya hasil dari analisa builtwith terhadap ui-avatar.io tidak menunjukkan tekhnologi apa yang mereka gunakan dan sebesar apa server yang mereka gunakan. namun demikian bisa kita lihat kekuatan dari Erlang VM.

Bagaimana dengan hasil test terhadap Google.com?

root@locust-testing:/home/indodax# wrk -t8 -c50 -d10s http://google.com
Running 10s test @ http://google.com
8 threads and 50 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 6.96ms 13.84ms 246.56ms 94.49%
Req/Sec 1.43k 139.20 1.64k 73.12%
114332 requests in 10.01s, 58.88MB read
Requests/sec: 11420.16
Transfer/sec: 5.88MB

Hasilnya adalah 11 ribu request per detik. Ini bukan pencarian. Hanya sekedar menampilkan halaman utama google yang berisi form pencarian. Tentu menampilkan itu juga bukan hal yang trivial bagi Google karena mereka perlu melakukan cek status user login dan sebagainya.

Tadi pengan parameter pengujian yang sama, kita masih bisa berbangga saat mesin sekecil itu mampu melayani load sebesar itu.

Secara teori, 27ribu RPS artinya kita mampu melayani sekitar 2 Milyar request per hari!

Okelah, untuk ukuran server seharga 5$ per bulan. Nah, dengan test parameter yang sama, sebagai perbandingan mari kita lihat performance dari beberapa website terkemuka di Indonesia:

Detik.com = 3706 Request Per Second

root@locust-testing:/home/indodax# wrk -t8 -c50 -d10s http://detik.com
Running 10s test @ http://detik.com
8 threads and 50 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 12.91ms 791.19us 25.19ms 84.86%
Req/Sec 465.55 18.22 500.00 76.50%
37134 requests in 10.02s, 17.42MB read
Requests/sec: 3706.24
Transfer/sec: 1.74MB

Blibli.com = 3711 Request Per Second

root@locust-testing:/home/indodax# wrk -t8 -c50 -d10s http://blibli.com
Running 10s test @ http://blibli.com
8 threads and 50 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 12.89ms 578.55us 37.32ms 92.82%
Req/Sec 466.55 15.54 494.00 81.50%
37209 requests in 10.03s, 4.08MB read
Requests/sec: 3711.62
Transfer/sec: 416.83KB

Kaskus.co.id = 3770 Request per second

root@locust-testing:/home/indodax# wrk -t8 -c50 -d10s http://kaskus.co.id
Running 10s test @ http://kaskus.co.id
8 threads and 50 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 12.70ms 570.32us 24.78ms 95.04%
Req/Sec 473.48 14.81 505.00 87.00%
37758 requests in 10.01s, 12.24MB read
Requests/sec: 3770.32
Transfer/sec: 1.22MB

Traveloka.com = 12939 Request per second

root@locust-testing:/home/indodax# wrk -t8 -c50 -d10s http://traveloka.com
Running 10s test @ http://traveloka.com
8 threads and 50 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 3.87ms 2.11ms 66.63ms 93.66%
Req/Sec 1.63k 198.91 2.02k 74.50%
129575 requests in 10.01s, 35.22MB read
Requests/sec: 12939.70
Transfer/sec: 3.52MB

I’m supposed to do something else that other night and I drank too much coffee already. But then my ADHD kicks in and instead of focusing on my task I wonder how I can generate pretty random color programmatically? I know color wheel, but how it translated into Hex code?

Randomising RGB color and convert it to Hex code might be easy but it produces horrible color. Too random, to bright, too washed out, etc. How to make it consistently good? Bunch of Google and Wikipedia later, I read about HSV color instead of RGB, it HSV allows you to control the color only by manipulating Hue, and keep the saturation fixed. This gives a consistent color. Not too bright and not too dark. So this is how they can generate pretty pastel color consistently and almost seems like they have a predefined color scheme.

An hour later, I wrote a function to generate color in HSV format and convert to RGB, then to Hex. It worked, but I’m not satisfied with my Saturation default value.

Ok done, now what? Did this knowledge give any advantage for my job or project? Not really. The worst part is I know the library to do that already exist in ruby or Nodejs library somewhere. I realize I’m reinventing the wheel and it didn’t stop there.

Thinking about it, now I can use it to generate default avatar! You know, initial-based avatar popularised by Google. Let’s write a function to generate initials out of names. The problem is, of course, Indonesian can have a really long name. The existing algorithm simply uses regex and it works up to 3 words name. My approach, I decided to simply take the first and last word and take the first letter. On top of that let’s also find and ignore strange character. Done, what’s next?

Okay, how about the actual avatar generation part? The first option is to create png using an external library like ImageMagick. That’s how other people did it. But why they don’t use SVG? It produces less computing power, less dependency, less disk space, and can be generated and transported super fast. PNG can be around 3–4 Kb while I believe I can at least 25% less with SVG.

With the spirit of DIY and reduce dependency, I write SVG generator by hand. It needs to ensure we can adjust the size programmatically, even though SVG is scalable by default once we made the file.

Okay, it’s done! Can I sleep now?

Not quite. I wonder how to generate unique color associated with the name? So it has a unique-ish property like Gravatar or Robohash? (Unlike actual hash, these will have pretty low collision probability but must be on good-enough level). This feature is to ensure the user has a somewhat consistent color associated with their name. The lazy approach is to generate the color randomly and store it in the database, but that’s boring.

After giving some thought I started with hash the string, the straightforward md5 algorithm then try to figure out is how to map given string into 259 possible colors generated by the first function? I can’t figure out the satisfying approach. I fell asleep.

The same problem still haunting me, the next morning at work. Two questions: how to map the hash string into 359 possible colors consistently? And how to find the right saturation setting for color generation algorithm. Thanks to Amanda Michiru who gives advice on the saturation setting. And Firdha Safri comes up with an elegant solution where we convert all the letter into a number, sum it up and use rem function to keep it below 359. Perfect!

Now we have an SVG avatar generator, written in pure elixir. Let’s wrap it up, put it on GitHub, forget about it and continue my life and do something that actually matters! (Boy, I’m so wrong. I ended up spin up a whole service for this the next day. I’ll explain in the next article.)

Here’s the GitHub project:

https://github.com/virkillz/hash_color_avatar_elixir

And I publish it as hex.pm library for elixir.
https://hexdocs.pm/hash_color_avatar/0.1.0/HashColorAvatar.html

Design

There are several useful tips regarding how to design your chatbot.

1. Put one specific use case for your Chatbot, don’t be too generic.

Don’t aim your chatbot to be like siri, cortana, jarvis, or samantha (remember ‘hers’ the movie?). Before you start thinking to build chatbot, it’s a good thing to know the limitation of a chatbot. Unless you have some secret sauce technology, current chatbot cannot think like human. It boils down to ‘if else statement’, basically. So the best way is to think a spesific funtion and build a design around that particular function.

2. Create a persona for your chatbot.

Don’t treat chatbot like a CLI (command line interface) where you input some command and it return bare information you asked. Give it character, make it tease you or tell you occasional joke when you ask something, make it feels more like chat with a human being. But don’t get me wrong, don’t pretend to be human. Don’t lie to your user. Give a hint and disclosure upfront your users are talking to a bot. If you lie, soon or later people will find out its a bot and they will feel cheated. Give full disclosure it is a bot, and surprise them with more humanly interaction along the way.

3. Think, and rethink user experience.

When people open your bot for the first time, give them a hint about what they can do. Ask question first. This way you can guide the user trough your purpose within your bot limitation. If the platform you choose provide button or quick answer selection (such as facebook messenger, telegram, or slack), use it. Instead of user should type freely all the time, when it possible, provide them button. Try over and over again to understand every dead node across the conversation, fix it, optimize it.

4. Come to where users are.

Instead of make one website for your chatbot or build mobile apps so people can use your chatbot, when possible, use existing platform. Most of the time, it can be done with facebook messenger. It can play text, picture, video, audio (up to 20 mb) and display nice cards (up to 9 cards). You can then focus on how to attract Facebook user (which is almost everybody) to come using your page instead of open new website or download new apps.

Regarding Technology

1. Don’t reinvent the wheel.

Some of the people code the chatbot from ground up with the language they understand, simply because they not aware there already bunch of tools for it. If you prefer to have full control of your chatbot behavior and prefer to host the engine in your own server, there are ‘Program-o’ (for PHP), then you only need to program AIML for it. For general purpose chatbot especially if you use facebook messenger as your platform, chatfuel is more than enough. It have many feature such as easy integration with facebook messenger, drag and drop AI ‘programming’, easy connection with outside json API. The only drawback is : it doesn’t understand context. But most of the time, it get the jobs done and more.

2. Hack the hell out of your tool

Whatever tool you use, ensure you know much about its feature and how to extend it. Tool like chatfuel seems basic but when you know it inside out, it still amazed me what people can do with it.

3. Extend the tool you choose to create something new.

When you trust existing tool like chatfuel or program-o to handle the basic conversation flow, think about the external data source to make it interesting. Otherwise, chatbot with static data can be boring pretty quick. Ask the bot to tell joke, or ask the bot to tell what exchange rate for today (you get the idea), you can make it exciting and useful.

Regarding Hackathon strategy

1. Everything is boiled down to one minute presentation.

Most of the hackathon only provide you very limited amount of time to present your product. Don’t too focus with your product and spend the last hackathon day to prepare your presentation. Many good product in the hackathon fail to grab attention of the judge becaue their lack of prfesentation strategy. Practise to highlight the feature and the flow of your product (and why it is important to be exist) within the provided time (we got 4 minutes for this event).

2. Do your networking and collaboration.

Don’t forget this is not only a competition, use your time to talk to other people, other group, ask something, help someone, and share your product. If ready, ask them to use and get feedback. You might get ‘participant choice’ award because of that.

In the end, we can think chatbot as an interface to a software we built. Instead of provide them with static menu, we guide them with every function they choose in interactive way.

I hope this note can be useful for someone interested in AI, chatbot, or hackathon in general. Also for my cousin.

“Anda akan merasa kecewa pada akhir artikel ini.”

Oke oke, saya memang sedang mengekploitasi kepopuleran topik Ahok belakangan untuk menggiring perhatian pada beberapa topik lain yang sangat jauh berbeda. Artikel ini akan banyak membahas beberapa hal mulai dari ramalan, kecerdasan buatan, hingga pawang hujan.

Alkisah, pernah hidup disuatu masa, seorang penyair dan astrolog bernama Nostradamus. Dia yang hidup di abad ke 16, lebih tepatnya antara 1503 dan 1566, menulis banyak sekali quatrain dalam bahasa perancis yang ia bukukan per 100 quatrain yang dia beri judul centuries. Berikut satu quatrain yang dia buat:

Bêtes farouches de faim fleuves tranner;
Plus part du champ encore Hister sera,
En caige de fer le grand sera treisner,
Quand rien enfant de Germain observa.

(Centuries II quatrain 24)

Salah satu penggemarnya, Cheetam, menerjemahkannya kedalam bahasa inggris sebagai berikut:

Beasts wild with hunger will cross the rivers,
The greater part of the battle will be against Hitler.
He will cause great men to be dragged in a cage of iron,
When the son of Germany obeys no law.

Sejenak, coba pahami kalimat tersebut. Baca kalimatnya satu persatu. Pahami konteksnya, dan pahami letak keanehannya.

Quatrain itu terlihat menceritakan tentang hitler. Pertanyaanya: Bagaimana mungkin orang yang lahir di abad 16 mendeskripsikan kebangkitan hitler yang lahir lebih dari 300 tahun sesudahnya dengan sangat akurat? Mulai dari nama, negara, hingga deskripsi bagaimana rezimnya menyeret orang besar kedalam sangkar besi? Sejago itukah nostradamus dalam meramal?

Ini baru satu quatrain. Dia memiliki ratusan quatrain. Dan beberapa quatrain disebutkan meramalkan meledaknya pesawat ulang alik challanger, kematian john F. kenedy hingga tragedi WTC 9 November.

Bagaimana mungkin?

Walau sempat menjadi legenda umum selama bertahun tahun pada akhirnya Ini kemudian dijelaskan secara gamlang oleh James Randi. Dia adalah seorang mantan pesulap beraliran escapologis, tokoh skeptik yang mendirikan James Randi Educational Foundation. Lembaga ini terkenal karena menawarkan uang 1 juta dollar bagi siapapun yang mampu mendemonstrasikan kemampuan supranatural dalam kondisi yang diawasi ketat, dan tidak ada yang pernah berhasil membuktikannya hingga sayembara ditutup lebih dari 10 tahun kemudian. Randi menjelaskan bahwa kecocokan nostradamus dengan kejadian populer sangat tergantung pada kreativitas orang yang mencocokkannya. Dalam contoh kasus ramalan hitler, kesalahan terbesar sudah ada sejak penerjemahan dari bahasa perancis menjadi bahasa inggris. Dengan berbekal kemampuan menerjemahkan bahasa perancis kuno, pengetahuan budaya dan sejarah setempat, inilah terjemahan versi Randi:

Beasts mad with hunger will swim across rivers,
Most of the army will be against the Lower Danube.
The great one shall be dragged in an iron cage
When the child brother will observe nothing.

Randi menunjukkan bahwa kata ‘Hister’ tidak merujuk pada nama orang, melainkan nama lokasi geografis di sekitaran Danube. Begitu pula dengan kata “Germain” yang direferensikan pada area di Eropa jaman dulu, sebelah utara Danube dan sebelah timur Rhine dan bukan merujuk negara Jerman.

Kecocokan sajak lain dengan kejadian lain pun dijelaskan sebagian besar adalah cocoklogi (pencocokan paksa) yang melibatkan penerjemahan, pemutar balikan kata, pemaksaan tahun, bahkan sajak palsu yang tidak ditemukan di literatur Nostradamus yang asli.

Trik dibalik ramalan
Dari masa kemasa banyak tokoh peramal yang muncul ke permukaan. Ki Joko bodo dan mama lorentz di Indonesia adalah dua contoh dari Indonesia. Di kancah internasional paul the octopus misalnya terkenal karena memprediksi kemenangan permainan bola di Piala dunia.

Yang tidak banyak orang sadari adalah: diluar orang orang yang terkspose media ada jauh lebih banyak lagi orang yang mengaku bisa meramal dan sering mengeluarkan ramalan. Sebagian dari mereka jatuh tanpa sempat terkenal. Ada dua kesamaan mereka:
1. Ramalannya sering ambigu dan multi tafsir. Ini memungkinkan mereka atau pengikutnya berkilah jika gagal atau memaksakannya supaya cocok.
2. Pamornya redup begitu ramalannya mulai meleset.

Menariknya, pola ini mirip dengan fenomena keberadaan pawang hujan. Tentu saja hanya ada dua kemungkinan hasil dari pekerjaan pawang hujan, yaitu Hujan atau tidak hujan. Dengan prinsip probabilitas ditambah sedikit berbekal prediksi cuaca BMKG seorang pawang hujan bisa survive berkarir bertahun tahun hingga pamornya turun dan tidak dipercaya lagi. Dengan prinsip probabilitas, kalikan ribuan orang yang perprofesi sama, akan ada segelintir pawang hujan yang paling banyak sukses berturut turut. Jika anda tertarik bisa mempelajarinya dengan mencari ‘law of large number’. Tentu pawang hujan yang gagal tidak akan terkenal, hanya pawang hujan yang memiliki track record panjang lah yang terkenal. Informasi ini beredar dari mulut ke mulut sehingga di dalam persepsi masyarakat berkembang: Pawang hujan itu ada dan sakti. Ditambah lagi, pawang hujan sering menjustifikasi kegagalannya dengan “atau pihak lawan menyewa pawang hujan yang lebih sakti.” atau bahkan sekedar “kehendak Tuhan”. Dewasa ini memang orang terlalu mudah membawa nama Tuhan untuk menjustifikasi apapun perbuatannya. Dan orang lain tidak bisa protes.

Kembali ke topik, ada banyak sekali trik yang bisa digunakan untuk memunculkan efek seolah anda bisa meramal. Pernah membaca ramalan zodiak? Mereka menggunakan trik yang dikenal dengan “barnum statement” atau gaya penulisan tertentu yang menimbulkan efek dimana orang merasa tulisan tersebut sangat mendeskripsikan mereka. Penulisannya ditulis sedemikian rupa sehingga terkesan spesifik padahal sering berlaku secara umum seperti:

“Ada sering merasa orang lain susah memahami anda. Dalam keadaan tertentu anda adalah pemimpin yang baik. “

Kebanyakan orang merasa sesuai dengan deskripsi semacam itu. Ada sebuah percobaan terkenal yang dilakukan Bertram Forer (1914–2000) dimana dia mencatat nama dan tanggal lahir para siswanya dan memberikan selembar kertas yang dikatakan hasil analisa psikologi komputer atas pribadi mahasiswanya. Isinya sebagai berikut:

You have a need for other people to like and admire you, and yet you tend to be critical of yourself. While you have some personality weaknesses you are generally able to compensate for them. You have considerable unused capacity that you have not turned to your advantage. Disciplined and self-controlled on the outside, you tend to be worrisome and insecure on the inside. At times you have serious doubts as to whether you have made the right decision or done the right thing. You prefer a certain amount of change and variety and become dissatisfied when hemmed in by restrictions and limitations. You also pride yourself as an independent thinker; and do not accept others’ statements without satisfactory proof. But you have found it unwise to be too frank in revealing yourself to others. At times you are extroverted, affable, and sociable, while at other times you are introverted, wary, and reserved. Some of your aspirations tend to be rather unrealistic.

Forer lantas meminta siswanya untuk memberi nilai dari skala 0–5 sejauh mana analisa psikologi tersebut cocok dengan karakter mereka. Nilai 4 adalah “good” dan nilai 5 adalah “excelent”. Hasilnya? Nilai rata rata keseluruhan adalah 4.2 dalam artian 84% akurat. Mereka diberi tahu kemudian bahwa semua orang mendapat kertas dengan tulisan yang sama persis.

Trik diatas adalah segelintir trik yang bisa dimanfaatkan untuk menimbulkan efek ramalan. Seolah orang mengetahui sesuatu tentang kita. Kumpulan tekhnik semacam ini bisa diterapkan untuk “meramal” masa lalu dan masa depan, “membaca” pikiran, “menggali” memori, dan sebagainya. Jika tertarik anda bisa membacanya di sebuah buku berjudul “The Full Fact Book of Cold reading” Tulisan Ian Rowland.

Nah, kita sudah mengetahui polanya. Lalu bagaimana menuangkan dalam bentuk algoritma sehingga mesin bisa melakukan “ramalan” untuk kita?

Artificial Inteligence
Pandu (@mbakpandu) dari IBM Indonesia membuat robot twitter yang bisa membuat puisi. Tidak hanya itu, robot ini juga bisa meniru gaya puisi orang lain. Terinspirasi dari ciptaannya, saya memiliki ide serupa untuk membuat robot yang hidup di Twitter bernama Airima (@rima_robot) yang mempelajari gaya penulisan puisi Nostradamus dan membuatnya mampu menciptakan sajak dengan gaya yang sama dengan nostradamus, yaitu gaya ramalan. Setiap satu jam Airima mengenerate sebuah kalimat yang seolah keluar dari mulut cenayang dari abad ke 15. Kalimat yang penuh kata misterius yang ambigu di suatu tempat namun terkesan detail di tempat lain.

Ini dilakukan dengan sebuah algoritma bernama ‘rantai markov’. Belajar dari 3500 baris quatrain Nostradamus, Airima mengenerate kalimat dari pola yang dia pelajari literatur tersebut. Karena berbekal Nostradamus, banyak diantara kalimat yang dia hasilkan menyebut nama nama lokasi di Eropa. Pada akhirnya kita menemukan satu “ramalan” yang bisa kita eksploitasi bersama sehingga seolah sedang meramalkan Ahok.

Ini adalah ramalan dia yang akan kita cocok cocokkan dengan masa depan Ahok:

“Quality of the sun. Under the splendor will be a King who will come to compromise the fork-nosed one.”
Airima, 12 December 2016

Apa artinya? Mari kita cocologikan bersama.
Siapa yang dimaksud ‘quality of the sun’? Siapa lagi kalau bukan Ahok. Selain bahwa dia bagaikan matahari yang mencerahkan Jakarta (lebay? sengaja.), nama aslinya pun adalah “Basuki tjahaja Purnama”. Cahaya, dan purnama. Dia layaknya bulan dengan kualitas matahari, kualitas purnama. Lalu apa yang dimaksud kalimat selanjutnya? “The splendor” yang dimaksudkan disini, siapa lagi kalau bukan Jokowi. Yang pamornya tidak diragukan lagi sebagai bintang baru di jagad politik Indonesia. Dari sini kita bisa mengambil kesimpulan (ngawur) bahwa Ahok akan menjadi raja (presiden) dibawah restu Jokowi yang nantinya akan terpaksa berkompromi dengan “fork-nosed one.” Siapa itu “fork-nosed one”? Siapa lagi kalau bukan beberapa orang yang nurut saja dengan perintah untuk demo layaknya “kerbau dicucuk hidung” (fork-nosed) padahal sebagian besar tidak tau kejadian dan ucapan Ahok yang sebenernya yang dibilang menista agama itu.

Ngawur? Jelas. Berarti anda masih waras. Saya sendiri tidak secanggih itu dalam hal mencocok cocokkan. Masih ada yang lainnya. Hingga saat ini Airima masih membuat ramalan tiap satu jam sekali.

Ini adalah “proof of concept” dimana kita bisa mencocok cocokkan kalimat dengan model tersebut terhadap satu event yang akan terjadi atau telah terjadi.
Suatu hari nanti kita tinggal mencocok cocokkan kejadian besar yang terjadi dengan salah satu dari baris yang ia buat lalu membuat klaim bombastis bahwa:

“KEJADIAN INI TELAH DIRAMALKAN ROBOT DENGAN KECERDASAN BUATAN JAUH HARI SEBELUMNYA”.

Lalu tunjukkan analisa bagaimana baris tersebut cocok dengan kejadian yang ada. Lalu bagaimana dengan kalimat lain yang tidak masuk akal? Kita tinggal katakan: “Akal terbatas kita belum mampu menerjemahkannya.” Kita bisa dengan mudah bersikap militan terhadap Airima dengan berprinsip “Airima tidak pernah salah. Kesalahan adalah produk manusia yang memiliki akal terbatas dalam menafsirkannya.”.

Fenomena ini jelas terjadi pada Nostradamus. Beberapa orang sangat yakin bahwa Nostradamus memang memiliki kemampuan melihat dimasa depan. Tergantung kemampuan oranglah kata kata nostradamus bisa diterjemahkan. Ini juga terjadi pada kitab Jayabaya di tanah Jawa yang diperkirakan ditulis di abad yang sama dengan Nostradamus. Karena syairnya memiliki gaya penulisan prediktif di beberapa bagian, ada orang yang menganggap ia mampu memprediksi masa depan. Dikatakan hanya keterbatasan kitalah, kalimat itu tidak sepenuhnya dipahami. Pola ini terjadi di banyak literatur yang diagungkan. Setiap masa ada literatur yang dikultuskan dan dikatakan memprediksi sebuah kejadian di masa depan dengan arti kalimat yang dicocok cocokkan. Anda mungkin menyadari betapa saya menghindari mengatakan kitab suci memiliki pola yang sama. Itu penistaan.

Begitulah.

Bagaimana? Sudah kecewa?

Ok. Bayangkan skenario di mana kita bisa meminta program dengan kecerdasan buatan untuk memberikan opininya terhadap suatu topik. Dan dia bisa menjawabnya. Pasti seru. Seberapa ngaco opininya? Seberapa nyambung?

Tentu saja tekhnologi robot AI belum sampai pada tahap dia bisa berpikir dan mempertimbangkan suatu topik. Jika ada pun, mungkin masih dalam pengembangan yang digenggam erat oleh raksasa tekhnologi seperti google. Komputer dan software bagus dalam hal mengolah data, namun masih belum mampu memahami dan mempertimbangkan sebuah wacana. Lalu bagaimana kita bisa mencapai efek dimana robot memberikan opini? Kita menggunakan algoritma yang dinamakan rantai markov untuk mencapai efek itu.

Algoritma ini mampu menyusun ulang sebuah sequence dari data yang diberikan, berdasarkan pada probabilitas pola yang muncul. Dia merujuk pada data historis dan digunakan untuk memprediksi kata apa yang muncul setelah kata tertentu. Penerapannya cukup banyak dan cukup ajaib.

Keyboard smartphone Anda besar kemungkinan sudah memiliki fitur yang memanfaatkan algoritma ini. Dia memunculkan kata apa yang disarankan tiap Anda selesai mengetik satu kata berdasarkan histori Anda menggunakan keyboard, atau histori standar bawaan aplikasi.

Contoh lainnya, kita bisa membuat puisi dengan gaya yang sama hanya dengan memberikannya kumpulan puisi sebagai referensi. Robot Twitter saya, Airima (@rima_robot) mampu membuat baris-baris ramalan ala nostradamus secara cukup realistik setelah saya memberinya 3500 baris quatrain dari nostradamus. Dengan kata lain, Airima bisa membuat sajak nostradamus setelah belajar dari 3500 baris sajak nostradamus.

Ini bisa diterapkan pada Nietzsche, dia mampu membuat kalimat dengan gaya bahasa seperti Nietzsche walau jika diperhatikan seksama akan sering ditemukan kata yang nggak nyambung.

Tapi di situlah kecocokannya. Kata yang digenerate dari algoritma markov akan seolah sering cocok secara grammar, namun agak aneh secara makna sehingga ini akan cocok untuk men-generate hal-hal seperti puisi atau kalimat yang seolah memiliki makna mendalam (semacam pseudo intelectual words). Robot puisi (@robotpuisi) ciptaan Mbak Pandu dari IBM Indonesia adalah contoh penerapan model ini, Anda bisa beradu puisi dengannya.

Microsoft sempat membuat robot Twitter bernama Tay dengan algoritma kecerdasan buatan di baliknya. Idenya adalah menyerap opini di jagad Twitter dan akhirnya membentuk pengetahuan dan karakternya sebagai robot. Public Relation Microsoft mengatakan bahwa Tay diharapkan dapat beropini layaknya anak muda sehingga Microsoft dapat memahami aspirasi tipikal anak muda secara umum.

Banyak programer (termasuk saya) yang menerka-nerka algoritma seperti apa yang ada di baliknya. Tebakan saya adalah: Tay menggunakan preprogrammed AI behaviour dengan AIML untuk percakapan standar dan sementara itu mengumpulkan opini yang di-mention kepadanya dan pada akhirnya diolah dengan algoritma serupa markov chain.

Masalahnya adalah: hacker mana pun yang punya pasukan robot twitter, bisa men-spam Tay dan memaksakan sebuah opini. Karena inti dari rantai markov adalah analisa probabilitas, maka jelas ini adalah sebuah bug yang cukup fundamental. Hasilnya? Kurang dari 24 jam Tay berubah dari robot naif menjadi robot rasis, pemuja hitler, dan suicidal. Microsoft menutup proyek itu seketika.

Mereka yang kurang paham akan kemungkinan teknologi di balik Tay (saya bilang kemungkinan karena tentu saja hanya Microsoft yang tahu persis), menggunakan insiden ini sebagai argumen bahwa pengembangan kecerdasan buatan (AI) adalah suatu yang mengerikan dan dapat mengancam kelangsungan manusia.

Sementara saya melihat bahwa teknologi sekarang, termasuk teknologi yang digunakan oleh SIRI, Cortana, ataupun Google Assistant, fondasinya masih sebatas pattern matching, belum mendekati “kesadaran” yang mampu menyelesaikan turing test yang paling sederhana sekalipun. Kita belum sampai ke sana.

Para pemimpin perusahaan teknologi di seputaran Silicon Valley sedang merumuskan kode etik bagi AI. Di sisi lain, masih banyak pekerjaan yang harus dilakukan untuk mencapai sebuah kesadaran komputer. Artificial inteligent masih memerlukan kemajuan dari banyak disiplin ilmu sekaligus mulai dari machine learning, Natural Language Processing, hingga komponen pendukungnya seperti speech recognition, neural network, big data analysis.

Kembali ke topik yang menyenangkan. Bagaimana membuat efek yang serupa dengan Tay? Kemarin saya mencobanya. Saya memprogram Airima (@rima_robot) sehingga ketika kita tweet dan mention dia yang mengandung kalimat “apa opini kamu tentang”, maka dia akan mengolah kata atau kalimat sesudah itu dan membuat tweet tentang topik tersebut. Salah satunya adalah sebagai berikut:

“Apa opini kamu tentang persidangan Ahok?”

Salah satunya dia menjawab: “Terlalu banyak yang sudah dia lakukan untuk Islam. Kita tidak boleh membiarkannya jalan sendiri.”

Wow. Apakah dia benar berpikir demikian? Tidak.

Itu adalah salah satu jawaban terbaik dan nyambung dengan topik yang diberikan. Beberapa percobaan sebelum dan sesudahnya menghasilkan kalimat yang sulit dipahami walau seolah relevan.

Di baliknya, program akan mengubah kalimat tersebut menjadi string pencarian dan dengan menggunakan Twitter search API, mencari 100 tweet sehubungan kalimat atau tagline tersebut. Lalu difilterlah dan dikeluarkan tweet yang berupa retweet, tweet yang mengandung link (biasanya sekedar share link), tweet duplikat (biasanya ulah bot juga), dan menghapus semua kata yang diawali tanda @ (mention).

Ini dilakukan 20 kali (karena pencarian terbatas maksimal 100 search per hit) dan hasilnya dikumpulkan menjadi sebuah teks panjang berisi kumpulan opini tentang topik tersebut. Dari sinilah diterapkan algoritma markov untuk men-generate opini dari topik yang diminta.

Masih banyak ide menarik untuk mengembangkan metode ini meski masih berbasis algoritma markov. Salah satunya adalah dengan menyimpannya dalam database berbasis dokumen yang biasa digunakan untuk support big data, dan menyimpan node yang di-generate dari rantai markov ke dalam database juga. Hasilnya adalah generate kalimat yang lebih unik, menarik dan kemungkinan lebih relevan.

Namun pada akhirnya, proyek iseng ini hanya sebatas prove of concept (POC) saja karena masih mengandung banyak bug. Saya turunkan dari Twitter. Salah satu kendalanya adalah search API Twitter sangatlah terbatas. Jika kita meminta opini dengan string yang agak panjang, di atas 4 kata, Twitter tidak memberikan hasil, program akan crash.

Di sisi lain, ada juga masalah sepele namun cukup menyebalkan, yaitu bagaimana memotong kalimat yang dihasilkan agar tidak lebih dari 140 karakter namun masih tetap berarti. Ah, sudahlah.