When we started huijiwiki.com, PHP was the language of the choice. But it was not much a choice. MediaWiki was coded in PHP. It provided us a solid starting point to expand our idea. Since then I have touched many languages and am moderately proficient in some of them. Among them, Go is my current favorite. Rust is the language I want to explore more. Go as well as Rust has a very different nature compared to PHP.

DMP stands for Data Management Platform, and per Wikipedia, it is a technology platform used for collecting and managing data, mainly for digital marketing purposes. To put it simply, DMP is a collection of data about user attributes. As you might expect a DMP may contain more than millions of data. The DMP I worked on contained nearly a billion. Open source toolings such as Elasticsearch provided a good average baseline for data analytics, and reasonable response time for general-purpose querying.

I have to admit I am really clumsy when it comes to SQL related stuff. This is the year of 2019, and SQL is not a fancy technology to learn anymore. I managed to get away with not diving deep into SQL for a long time, but the lack of fluency in SQL bites me quite often recently. Yesterday I was forced into a binlog trace of the production MySQL database.

RxJS is bonkers! Imagine you have an unbounded stream of events. Each has a unique id. Now you want to throttle the stream based on id, ie. each id should not appear more often than X minutes. With RxJS: // Throttle each id in one minute. fromEvent(emitter, 'tick').pipe( groupBy((e: Event) => e.getId()), flatMap(group => group.pipe(throttleTime(60 * 1000))), ).subscribe( //Do your stuff ); Without RxJS: Too much to write.

Over the days I have been thinking about improving my coding one step further. As I was refactoring some company work, this idea came to me. One of the least mentioned traits of good code is that you can easily remove a slice of them (from a larger project). Think about that. Removability means components are modular, architecture is layered, and abstractions are aptly interfaced. It also means Single Responsibility is enforced, so removing one thing won’t jeopardize another.

Vue community exploded due to changes in Vue 3. Some comments are full of gunpowder with regards to the recent functional API RFC. Let me show my opinions up front: A. OSS authors clearly deserve more respect. B. I think functional API generally are more expressive compared to the old one. However I would like to provide a counter argument to a very point the defender of RFC made.

Came across this pic from twitter. If I have an adequate number of audience, I would like to make poll out of it. What do you think about this piece of code? A: It is good code. B: It is bad code. I have never done react before (Or I have, but not professional). However this piece of code is very readable to me. If I was tasked with the job to maintain this code, I would appreciate the original author for coding in this fashion.

I have done some quick’n’dirty bid data processing with Apache Beam in past weeks. As someone who try to stay away from JVM, I am not a big data expert at all. However the working with apache beam is a blast (Using JAVA!). The lazy execution style feels right a home. I love wiring a various component into a topology, and only start processing when data arrives. I once heard a Haskell fan said that she thought lazy execution was what set Haskell apart from other programing languages.

Just read a thread in twitter from Matt Klein, where he basically summarized his opinion about complex tooling like service mesh. Though it is not straightforward to me that Matt, the creator of envoy, is actually dissuading people from jumping on the mesh train, his opinion is not really a fresh one. It seems to be a more and more accepted idea that service mesh are not for every body. It solves a domain of problems that only the top of the pyramid would encounter but meanwhile introduces a bunch of other headaches.