Many of my developer peers seem to have picked up the practise of publishing weeknotes. I’ve been meaning to do this for a long time, so here goes.
I discovered Shape Up originally via Adam Wathan who posted absolutely brilliant Twitter thread about becoming a succesful independent maker. It took me a wihe to manage to actually read it, but now that I finally did, it left me with some good ideas about shaping up (pun intended) my own work practises.
Shape Up is a very Basecamp-y look on modern development workflow and work practises. It narrows down on an idea of a 6-week work cycle where the team works on a pre-planned (shaped) project with external phases for planning and also for bug-fixing (what they call cooldown). Reading this felt really good as it is very similar what I’ve been doing with many teams of various sizes for a long time now.
I’ve found out that with most agile teams the idea of a 10-day sprint that inludes design and retro phases are just way too short. It forces the work to be planned and scheduled too much from the top down and leaves the team very little time for independent organization. If the work is instead planned (shaped up) beforehand with a smaller and more experienced team, and there is a separate bugfixing (or cooldown) period after the actual work phase (which is longer than two weeks) the probability of succesful delivery grows drastically.
This is very interesting topic for me and I’ll propably write more about it in the future. With some new inspiration from these ideas I reorganized my near future personal work in a new way. I converted my monthly plan from two sprints into a one cycle with a proper Iteration Plan (idea stolen from VS Code team) that has just one properly shaped and planned goal and clear dates for work phase. My cycle lasts for three weeks after which there is a one-week cooldown for bugfixes and planning for the next cycle. This method lets me keep monthly release cycle and hopefully allows me to actually ship something every single release. I may report back on the success of this model in the future.
New Vue 3 + TypeScript Project Template
For my end goal of shipping a totally new Vue 3 + TypeScript powered frontend for Slipmat users and artists I need a good and tested base for which to build on. To experiment with this I started a new project from scratch to remake the current admin views which have become a bit of a dumpster fire.
I’m using Tailwind UI components as a base which makes getting started really easy and fast. Unfortunately all the components are based on very bright color themes so I’ve had to come up with my own dark color scheme as Slipmat needs to be dark by default. I spent a week with the initial design and refactoring some old API views to get some basic dummy data for developing. The end result looks pretty good as a starting point, I’m sure the final product will work out great. (This is just a proof of concept after all!)
Vue 3 is now in RC phase and using it with TypeScript feels really solid already. The tooling (devtools in particular) is lagging a little bit behind but it’s early days still. I’ve got the project base pretty much nailed, it has fully automated CI/CD pipeline with end to end tests with Cypress and Mirage JS with coverage monitoring that fails the build if coverage drops below 80%.
Here’s the full list of my current dream stack that powers the new project:
Turns out there aren’t that many serious contenders. There’s Fuse.js which is great for small datasets (say less than few thousands of objects). I’ve used it in the past for some projects but I wanted something a bit more serious for this. There’s also Lunr.js and Elasticlunr.js both of which are loosely based on Solr. These are serious search engines with lots of options for tweaking the results and proper indexing.
I ended up picking MiniSearch which is a tiny (6k min+zip) yet “proper” and modern search engine that has no external dependencies and can do all kinds of nice things like fuzzy matching, auto suggestions, field boosting and realtime index updating. It can also export and import the built index which makes the initialization very fast. I’m testing the system with a 2Mb json file that has few thousand latest instances of about every model one might want to search (offline) from the admin dashboard. The biggest overhead comes from downloading this first json. Initializing the engine takes about 300ms but when you save the index it shrinks to about 1,5Mb and initializing that only takes about 50ms. As an initial proof of concept the simple pre-warmed and cached json works well enough though.
I’m not yet sure if having a offline-capable frontend-only search is worth it when everything is already indexed in Elasticsearch but this was an interesting one-day experiment in any case. Here’s the search in action:
Okay so this weeks notes were a bit on the long side but hey, it’s been a while. But let’s try to do this again next week! In the meanwhile, find the RSS-feed and @Uninen on Twitter 🙂