drown in a jar full of nuts

no one love to be left unnoticed

someone said it’s kinda taste like mixed bag of nuts

except that I love every kind of nuts


being unnoticed means more time to be drown by solitudity

more time to eat all gross food I like

more time to sleep until my arm aching

more time to nurture my disgusting and dirty imagination

more time thinking about being left unnoticed


it’s just like you leaves and I am staying

it’s just like you forget and I am being forgotten

it’s just like you are trying and I am giving up

it’s just like you are write a book and I am throwing all the memories

it’s just like you miss me and I’m being missed by you


gRPC is cool. Then what?


What is the most popular RPC right know? I would say restful with JSON. It is flexible, easy to test, using very common http stack and easy to do versioning. Then comes gRPC, offering more efficient network usage, faster serialization and deserialization and has good versioning support. I will not cover how to create basic service and the implementation, but will talk instead about using gRPC alongside existing restful API and doing versioning on gRPC.

In restful API there are routing and handler function which handle incoming request and responds it back. Another common practice is to have middleware to do pre or postprocessing on the request like logging and sanitizing. The question is could we use these existing functionality to work on our new gRPC service?
Everything is possible in engineering, but how big the changes is? It’s depending on your existing code.

Make it work together

This is common go webservice structure, or at least this is my favorite way to organize my code.


Inside route.go is http routing in this app, may looks like this :

router := httprouter.New()
router.GET("/student/:id", student.GetIDHandler)
router.GET("/schedule/:id", schedule.GetIDHandler)

Then we will have two services on the gRPC which has their getID procedure.

service student {
 rpc getID(studentMessage) returns (idResponse){}

service schedule {
 rpc getID(scheduleMessage) returns (idResponse){}

On the go side we can do service multiplexing on the same connection for both services, let’s put it on gRPCServer.go . Continue reading

Aku punya ratusan atau bahkan ribuan filosofi soal langit, tapi kali ini ijinkan aku hanya ingin melihat dia yang jelas lebih indah daripada langit sore ini. 


image from shutterstock

Ada sebuah jendela di mana saat orang memandang ke dalamnya maka akan terlihat sepasang kekasih yang saling memandang, tenggelam dalam lautan asmara. Dari jauh pun dapat terlihat temaram lampu kuning itu berbayang siluet sang mereka sedang menggenggam tangan satu sama lain. Mengisahi makna pertemuan dan mencumbui sisa-sisa malam, aura kehangatan itu membuar keluar lewat celah-celah jendela.

Talking about Qt vs HTML5 whitepaper

It was in the middle of midnight when I stumbled upon a white-paper comparing Qt QML app development with web app development. I like the idea to compare these two wonderful technology, however more I read the white-paper more I dislike it. I think it’s just another misleading marketing stun. Let’s dive down a bit on this white-paper titled Qt QML vs HTML5 – A Practical Comparison.

So in this whitepaper an Austrian company tasked a developer to build an Embedded Application using QT and HTML5, the developer had 160 Hours to build the QT version then another 160 Hours for the HTML5 version. The developer was experienced in HTML5 and C++ but had little experience on building QT/QML apps.

From this point please read the whitepaper before continuing this post, for complete context.

The result

I think there is one main misconception which leads to inappropriate comparison in this whitepaper.

The definition of Embedded Application; I would say embedded application would come in packaged and controlled target machine, like for webapp we can pick whichever browser our app work best. And for QT apps would mean which operating system and hardware platform the apps is targeted, so we can limit the build number to release. On both software stack or in embedded application generally, limiting target environment means less testing and less extra variable to take into account.

Continue reading