Koodihommia

I'm a fan of Kent C. Dodds. He has an excellent blog , he holds office hours on Youtube  and he manages an active Discord community focused on helping developers make maintainable React apps. I especially appreciate the way he thinks about state management in React apps. It does not have to be so reliant on external libraries. React itself is a library for managing state, so why not depend on its built-in abstractions. On a React Native app I'm building, most (> 95%) of the state management is indeed done with the React primitives: useStates, Contexts, and Refs. It is a big pile of hook compositions, and that's the way I like it. If you are familiar with React and can read its documentation, you can understand the code. There are a handful of places where using the primitives fall short, though. In these spots, plain old React hooks would require excessive glue code and would ultimately be confusing. Also, skipping needless renders in components such as forms can be tric...

I write a lot of stupid and useless unit tests. I confess that I'm aiming towards the elusive 100% test coverage. Sure, I'll never get there, and I realize it is not even a desirable goal. After an assessed threshold, we start to get diminishing returns. Why do I keep writing wrong tests then? Which unit tests should I leave out? My case is that it is tricky to write a large codebase with only valuable tests. I dare say that some (minority) of the essential tests might have outright bad practices where they end up testing how well I can mock stuff. The value of the test is not predetermined; hence I keep writing a lot of seemingly poor ones. There is an argument that high test coverage does not strongly reduce bugs and increase maintainability. That is likely true. Nonetheless, it is not so apparent which tests will avoid the most bugs or are the most useful in refactoring in the long term. The cliché is that requirements change, sometimes towards unknown directions.  It is mor...

VS code feels slow. All of a sudden, saving took forever in a TS project. The first suspect was a recently added WallabyJS test runner extension. So I disabled all plugins but still, saving took several seconds. My head then turned towards TS. Arrogantly I blamed some dependency but I had not a clue which one. Github TS wiki has some tips and tricks on what to do, including instructions to run a profiler. Turns out, a new profiling tool was introduced not too long ago in TS 4.1.  The output looks like this. Compiling the slowest source file takes more than 7 seconds! There is one massively slow checkSourceFile call which, as the name says, compiles a single file. To my embarrassment, it was in my code 😱 The profiling output is rather hard to decipher. The UI shows which TS internal functions are called and references a separate JSON file containing the type names. In my case, the slow function(s) included some weird single character type names, so it was not much help. The ...

I tried out the Encore go backend framework. I had no particular project to use it for; it was more that I wanted to do some go programming. Here are my two cents about it. Encore uses a simple package-based structure to build simplistic services. It has the usual niceties with hot code reload, minimal boilerplate, easy authentication management, etc. An endpoint is defined by an annotated function with a set of defined parameters. Encore provides also a runtime platform with one command deploy (git push actually) which is rather cool. Perhaps the most opinionated feature to me was the transparent integration to PostgreSQL. If a service has a migration file with some DB calls, the run or the deploy command automatically creates a database for the service and runs the migrations. The cloud console is pretty neat Would I use Encore in an actual project? Maybe not. Firstly, it's still in beta. If I'd start a plain old rest project with Postgres, sure, it takes away the boilerplat...

SerenityOS is a cool project to implement a 90's style retro operating system. I ran into it when some commenter in Hacker news recommended watching the  Andreas Klings Youtube series  on the development.  I've been obsessively watching his content for months now. In the videos, Andreas screencasts his work on the various features he is implementing. They are a fascinating watch. He is a master software craftsman. There is plenty to learn from his sessions, even if you would not be interested in C++ or system development. I've been doing minor hacks here and there, mainly to the UI components, since they are the easiest to approach for me. I'm not planning to contribute much to the project, but I think I'll keep watching the videos and reading the Discord channel actively.  I have almost completed one feature, though. I extended the screenshot utility to capture gifs as well. I found an open-source library that creates gifs out of PNGs. It sorta works; the colors a...

I created a simple "about me" website in the most ridiculous possible way I could imagine.  https://jompanakumpana.fi/ I did it with kaboom.js , a simple library by  replit . It's best explained by just trying it out. Trust me, it is a fun way to spend an afternoon or two!

In an app I'm building, I use SVGs in certain list items. The SVGs are custom status icons and thus are pretty simple. They contain trivial path and circle elements, have one color without any fancy gradients. The list feels a bit janky though, especially on my crappiest Android test device. My intuition was already when I added the SVGs that this might happen. Android is not the most performant with vector graphics, especially when using react-native-svg. I did some profiling with the Flipper mobile app debugging tool. My gut feeling was confirmed. The component which is the most prominently visible in the flame graph is the SVG, being almost ten times slower to render than the text components.  Performance of the SVG component Since the SVGs are so simple, the solution to this performance problem is to convert the set to a font. We use a ton of icon fonts, and they are almost as fast to render as "normal" text. I used IcoMoon for the conversion. As expected, IcoMoon c...