I stumbled upon a weird bug few days ago when I needed to implement a function that will gracefully fail instead of throwing an error. I thought it was as simple as try the function and catch the error, then return something else. Apparently, with async, things got a bit confusing.

We have recently updated to React 16.8 after more than 1 year stuck with the old version. The process was surprisingly pleasant, in fact, I accidentally updated our React version to 16.8 and we didn’t notice it for 1 week, nothing broken as we have gradually got rid of all the legacy stuff. Now that we have updated to 16.8, the fun officially begins. I have been a regular guest in the refactory hotel recently and I decided to write down some interesting cases I have encountered during my journey.

Last week, I was lucky to be able to give a talk at HelsinkiJS. The presentation was rather long compared to other because it introduces the type system as well as Flow. In this blog post I’m gonna summarize my presentation.

It has been (maybe more than) a year since my last post. One year ago, I decided that I should start doing something else other than sitting in front of my laptop building random stuff. It’s not only unhealthy but also slowly killing my motivation to build things. And I am glad that I did it. I spent my free time collecting and playing board games, my collection has grown from few games to more than 100 games now. I guess too much of something is not good and it’s time to get back to building random stuff. Anyway, if you happen to live in Helsinki area and need a gaming partner, hit me up.

Dependency injection is one of the basic programming principles that I learned and still remember. It’s a very useful principle but I don’t see it being used widely in the Javascript world. From all the Javascript libraries and frameworks that I have used before, only Angular 1 and Loopback force the use of dependency injection. In this blog post, I am going to discuss dependency injection and why is it important for medium to large projects.

I have been watching Vue from the distance for some time, and I have decided to jump into the hype train to take a closer look at Vue and its ecosystem after reading about nuxtjs. Nuxt is built on top of Vue to make server-side rendering great again. Server-side rendering was a hot topic few years ago. Maybe it has always been hot but I just don’t pay attention. Anyway, Nuxt offers a very simple (but powerful) way to do server-side rendering using Vue’s infrastructure and components. In this blog post, I am going to describe how I do authentication in nuxt, it’s using a different approach than the official auth example

Postgresql is my favorite relational database. There are a lot of cool things that Postgresql can do and one of those is to handle the authorization layer. Some people argue that putting authorization logic into the database makes the application code harder to read, and that’s actually true if there is only 1 code base connecting to a database. However, if there are more than 1 code bases communicating with a database, having a centralized authorization logic starts to make more sense. In this blog post, I am not going to discuss the pros and cons of having the authorization logic inside the database, but instead I am going to describe how I put all my authorization logic into postgresql.

I worked with React Native once last year. I was pretty impressed by its ability to apply the same React architecture to build mobile applications. At that time, it was a brief few months working with React Native, so I didn’t have much time playing around with it until recently. For the past 10 days or so I spent most of my spare time learning React Native. And one of the things that I learn is how to have multiple themes for a React Native application. In this blog post, I will describe the basic principles and how I manage multiple themes in my React Native project. This can also be applied to normal React apps since they are just React after all.

Although the game 2048 is not a hot stuff like it used to be several years ago, I am still playing it once in a while. And now I thought that maybe I could try to implement it by myself just to do something else other than web development.

In a project, there usually are a lot of tests. I am not going to discuss how much testing is enough because it depends on each project. What I am going to do in this blog post is to write down what I did for my work project to split a huge mocha test suite into smaller suites and run them in parallel. The end result is a testing process that used to take 7 minutes, now takes around 3 minutes. And the more test suites I run in parallel the faster it becomes.