In my last post about my side project I have mentioned that I have extracted 2 shared bundles to increase my build speed, and one downside of that is that now have two more requests for every page, and this week I have implemented a small tweak that will compensate to that: indefinite caching.

This weekend I have finally got to optimizing the TypeScript build for my side project. Because page bundles included both shared modules — one for the code shared between the backend and the frontend, and one for the code shared between the pages — they were getting longer to compile.

Today I would like to explain how I arrange validation and error handling on my side project. One useful outcome of using TypeScript on both sides — backend and frontend — is that I get to share the data structures, error states, and also the validation logic. And it’s not as much about sharing the code itself, but about the ability to keep the two sides aligned as the code evolves.

Hi. My name is Vlad and I missed my weekly goals.

One of the items that I had planned for this sprint was to fix the deployment system. Well, the “system” is a bit too grandiose for a Bash pipeline in the Makefile. The essence is that I didn’t pay too much attention to it after a couple of initial deploys, and then one day I went to the public URL and the app didn’t come up. I logged into the DigitalOcean server, and felt lost: didn’t really remember the commands to check for the system service status, didn’t know how to verify if the code is up to date.

One thing that I didn’t feel completely content with regards to the work on my side project was that I sometimes was getting lost down some rabbit holes, mostly on technical matters, like getting some makefile right or getting types right in TypeScript. This could take entire mornings with nothing to show for, and when this came out a couple of times during my own weekly retrospective, I decided I should do something about it.

Two weeks ago I wrote about the overall organization of the code on my side-project. I have since then added a couple more scenarios, and I want to get just a little bit into the specifics of it.

A couple of weeks ago I wrote about the P/PC Balance, and while thinking about it some more, a kind of comic realization stroke me: I realized that one good reason to prioritize feature work above technical work on a project is that the former is finite, while the latter is potentially infinite.

On the side-project that I’ve mentioned before, I’m making a priority of 2 things: (1) use the least amount of libraries and frameworks, and (2) organize the code in a way that reflects the logical structure of the app.

#user-work vs. #tech-work == P vs. PC