I heard about Parcel about a year ago, back then I didn't feel like it was stable enough to be used in my personal projects. And that I was just getting into RollupJS, compared to Webpack that was already a massive step up in terms of ease of use and simplified configuration. A year later, now I am finally ready to try out Parcel and see exactly how simple it is compared to the established alternatives like RollupJS and Webpack.
I have recently been working in a team that creates web apps that sits inside a webview wrapper application on Android TVs. Coming from more of a web background, even though this is still using React and other common web technologies, there are still some interesting challenges.
If you have read the title of this blog, then you know we'll be talking about CSS performances on Android TVs. This is not a new topic, since performance is an issue on all low end spec devices, but the ones comes with TV are a bit different.
This is my fifth year as a software developer, it certainly has been a long and fulfilling learning journey until now. There are simply too much to learn no matter how we plan it out, not even mentioning there are new tech coming out every day. When I started my career I felt like I knew so little about the world of software development, and that feeling never really went away. This game of catch-up is tiring to say the least, some even gave this overwhelming feeling a name - development fatigue.
So here's a question, if someone told you to draw a sketch would you like to be rulers and grids OR do you prefer to just have a blank canvas? One gives you structure, guidance and assistance, while the other gives you freedom. This is exactly the same argument with statically typed language VS dynamically typed language. This question has been around for a long time, and no one has managed to settled the argument yet.
I came across this error "Invariant Violation: You must pass a component to the function returned by connect. Instead received undefined" when trying to debug React/Redux app. This article walks through how I went about to solve it, and what was the issue.
As a developer, I have both explained and heard others explain to less technical people about how the team need to slow down adding new features/functionalities and take care of some tech debt first. Often, the management asks why. Sometimes it is hard to communicate the idea across to some people. In fact, it is quite nature for tech debt to occur and it is no one's fault that this happens. It has always bothered me when tech debt become a point of tension between developers and management. Because I think it happens so often that everyone, developers and management, should understand why projects end up with tech debts, what they are and how to manage them.
One of the reason why there wasn't any blog post recently was because I was migrating my blog to a new platform...again. I can't remember how many times it has been in the past few years, and this is excluding the times where I investigated in other blogging platform but didn't decide to commit. But I'm happy to announce that this new platform should be much easier for me to create content going forward. In this post, I wanted to explain how it works now and why I've spend month migrating again.
Recently I was working on a personal JS library Serina. It is a open source library, I wanted to use Typescript (TS) to ensure better stability due to it is static typed. It should make the code base more readable and therefore easier to contribution.
About 10 months ago I switched from Ghost blog to Hexo. I decided Hexo because it would be generating static site, which is great for SEO. It can be hosted on Github pages, which saves some £££. Then there is the most important reason: so I don't have to spend energy and time on maintaining the blog server and constantly migrating to newer Ghost versions.