Skip to content

Housekeeping

At this time of the year, I'd usually be planning or being on holidays. Given the current situation, that is a bit uncertain. In any case, I'm taking a break from project work and I'll use this time to do some small things I have in my backlog.

Activity

Task started

I've been looking into my backlog and of course, I have more things than I'll ever be able to do (and it'll keep growing). But that's fine :) I like that idea, nothing is ever really finished. So I'm not getting bored anytime soon. I pulled a couple of things that I want to do before embarking into a new project, and I'll be focusing on those for a couple of months.

I always struggle to write. Meaning that I have to dedicate too much time, and I have other priorities. But I still think it's very important, and I want to continue honing my writing skills. This week I published a new blog post and I experimented a little with it. In particular, I didn't use "I" even once. I use it to much, and I think it's becoming a crutch in my writing. I won't continue this trend, but it was a good exercise. I also don't put writing this journal entries in the same category as writing blog posts. Here, it's fine to use "I" more often and I don't dedicate as much time either.

I also implemented the search page for the new documentation coming with Vue 3. This is useful for services redirecting to search results using a url, for example DuckDuckGo's bangs. Right now, if you search lifecycle hooks !vue in DuckDuckGo, it'll take you directly to the search results in the Vue docs. That's very useful, and in fact I was the one who implemented the search page and submitted the !vue bang to DuckDuckGo for the v2 docs. I also want to do the same for Cypress and I'll probably contribute the search page to VuePress, given that v3 docs are built with that.

Finally, I also decided on what to do with my holidays so I'll be out until August 24th. I'll still be available, but much less responsive (limited to replying emails/socials). For anyone interested, I'm going to do part of the Camino de Santiago, Northern Way.

I'm back! I enjoyed a couple of weeks away from the keyboard, and one of the highlights was doing part of the Camino de Santiago. We walked 150km in 6 days, and I'm looking forward to doing more of that in the future. This is a kind of tourism I don't do often, but I'll probably start doing it in other countries as well.

Back on the keyboard front, there's been some activity in the media-kraken repo. I've been accumulating some things I'd like to do before moving forward to a different project, and I'll probably do those before getting started with other housekeeping tasks. But definitely no new features for a while.

Something I can cross off the housekeeping list is a couple of things for the cypress-laravel package. Jeffrey Way recently released a Laravel package with a lot of overlap with my solution. But it's not exactly the same, and there are some design choices that are different. For example, his solution consists of a Laravel package that publishes Cypress assets in the project and my solution consists of two packages - one for Laravel and one for Cypress. So I'll continue maintaining my own. Today I released a new version with support for custom commands, which should make it more extensible. I also closed pending issues and added the functionality to swap env files inspired by Jeffrey's package (and Laravel Dusk).

Oops... I did it again.

It's been a month and a half since I updated this task. But I haven't been idle, quite the opposite. I started working on many threads that became rabbitholes, so here we are again. I think it's about time to write an update, even if many threads remain open. Sorry in advance, because this is going to be a long one.

Let's start with Media Kraken. As part of the housekeeping, I wanted to improve a couple of things I didn't do in the previous task.

The first one was to improve error tracking. I thought this would be straightforward (and let's face it, it is). But I got too excited and ended up creating a new UI to display errors. I am also experimenting with how much technical details I should be showing in the UI. Non technical-users may get scared when they see the stack trace, so maybe I'll reconsider it in the future. But for a first approach I think it's good enough. Users shouldn't experience errors anyways 🤞. Besides the new UI, I've also refactored error handling on start up, and I've provided some scape hatches when things go wrong. Here's a video showing some of these things:

The second thing related with Media Kraken was to improve how I generate movie resource ids. In the current implementation, movie resources are created with the same id as their document. For example, a movie found at https://your-pod.com/movies/spirited-away would use that url as id. However, this is not entirely correct because that's the id of the document, and the movie is a different entity. The correct way is to have an id like this: https://your-pod.com/movies/spirited-away#it, where it could be anything. When I started working on this I knew it wasn't going to be straightforward, because it required some modifications in Soukai. But I wanted to do it in this housekeeping task before I get into other things.

And finally, the last thing relating to Media Kraken was the solid.community drama. This is not directly related with Media Kraken, but it affects the Solid ecosystem and it's surfaced some bad practices I wasn't aware of. I won't get into the drama part, but the gist of the issue is that one of the most (if not THE most) popular POD providers is gone. This is a problem because having a stable POD provider is important to reduce friction for non-technical users comming into Solid. After that happened, it was revealed that the person managing the domain wasn't managing the data, so everything has been migrated to solidcommunity.net. The part where it concerns me is that I'm thinking what to do for Media Kraken users. For sure, I'll fix the bad practices. But I'm pondering whether to assist non-technical users in migrating their existing data. I don't like the idea of hard-coding domains in my source code. But I guess it'll be the best for users, and it's also a good opportunity to learn about migrating data in Solid.

I also tried replacing Sentry with Glitchtip. To be honest, I don't like Sentry, because it tracks too much information (location, behaviour, etc.). But I don't think Glitchtip is ready to replace it yet, in particular because it doesn't send emails and I'm not willing to check in periodically. At least I've implemented error reporting as opt-in, so most people won't be using it.

So, that was Media Kraken.

On another front, I've been preparing a follow up to my Open Productivity post. I won't give away what it's about, but one of the conclusions I got was that I need a new section in the website. It isn't anything big, but when I started working on it I also started migrating to Laravel 8 to use new features and that also became a rabbithole. I think I'll move those changes to a different branch and create the new section without new features. I've had this post written for a couple of weeks, so I'm itching to publish it.

Something else that's happening now is Hacktoberfest. Last year I participated as a contributor, and this year I wanted to explore what I can do as a maintainer. I opened a couple of issues with the #hacktoberfest label, and I was surprised in how fast I got pull requests. Unfortunately, the quality of those contributions wasn't great. Which is to be expected, frankly. Most people just want a t-shirt. So I think that's were my Hacktoberfest Maintainer Adventures end. But I think I'll complete my contributor PRs, and this year I'll totally choose planting a tree instead of getting the t-shirt. I already have the one from last year, so I don't want to generate more waste.

So yeah, I started this task with a small scope and it's blown up. What I don't like is that a big chunk of this work comes from external events, instead of my own decisions. I could make the decision to ignore these things, but I think it's ok to dedicate some time to community work. What I wouldn't like is that this becomes my new normal. I'll keep an eye on that.

Today I finally released the Media Kraken improvements I've been working on for the last couple of months. I won't go into detail because I've already talked about that in previous journal entries, you can check out the release notes for a summary.

Something interesting happened with this release though. It's the first time that I think it's important to make an "announcement" that reaches all my users. In previous updates I just added improvements or fixed small bugs, but this release is very important for solid.community users. When the domain disappeared, Media Kraken stopped working. This release makes it usable again. But given the nature of Solid (and the way I'm publishing my app), it's not possible to reach them; I don't even know how many users I have. But after some thought, I decided to just tweet/toot about the new release.

This worry comes from the fact that I make my apps thinking about non-technical users. But the reality is that most of them are probably developers. I also know that my audience is very small (after publishing my latest post, only one person reached out – thanks Vincent!). So at this point, I think it's not worth it to spend any more time on this. It'd be great to have non-technical users, and maybe some day I'll work on growing that audience. But for now I'll focus on other things.

After this update, I don't think I'll be working on Media Kraken for a while. I still have some Housekeeping TODOs, and I want to start working on my 3rd Solid app by the end of the year. But I still use it every day, as well as Solid Focus. So I'll resume development for sure and add some important missing features like tracking TV Shows.

The last thing I'll do before closing this task is learn more about building node libraries. I've had Soukai published for a while, and it works. But there is a lot of room for improvement, so I'm creating a utils package to tinker with a couple of things on a small project. In particular, these are the things I want to look into:

  • Use Rollup instead of Webpack.
  • Make sure that tree-shaking is supported.
  • Generate TypeScript declarations automatically.
  • Include source maps in the release package.
  • Generate stack traces pointing to the source code (not the minified bundle).

I've finished working on my utils package, and it ended up being easier than expected! If anything, the reason why it took me this long (2\~3 days) is that I got entranced into doing some advanced TypeScript stuff. But I ended up dialing it down a bit; I simplified the types by foresaking having a single source of truth for some definitions. Mostly because I was using some new TypeScript 4.1 features and I think the tooling is not ready for them. If you're interested to know what all that TypeScript wizardry is trying to achieve, you can read the documentation where I explain the Fluent API included in the package.

Something interesting in this task is that I did some source code diving. I am usually able to find what I need from reading documentation or blog posts, but this time something eluded me and I found the answers looking at the Vue 3 source code. As a byproduct of that, I learned about TypeScript type tests and I also incorporated some of that in the package. If you're interested in learning advanced TypeScript, I recommend looking at this repository: github.com/type-challenges/type-challenges

As I mentioned in the previous comment though, my goal with doing this package was to learn more about authoring libraries. And I'm happy to say that learning Rollup has solved 90% of my problems. The documentation is great, and in contrast with Webpack I could understand what it's doing in an afternoon. So yeah, I don't think I'll use Webpack ever again if I have a choice. I also should mention that I came across a new tool called esbuild. It is unbelievably fast, building my package was literally instantaneous. But that's the only advantage I found, so I'm sticking with Rollup for now.

Tree-shaking and sourcemaps are very easy to achieve with Rollup. To generate Typescript declarations I tried a couple of tools, and I ended up using @microsoft/api-extractor. It wasn't as smooth a sail as learning Rollup, but after reading the docs and tinkering for a bit I got it working. I had to write a custom script to achieve my goals, but nothing too complicated.

Finally, I wanted to use sourcemaps in production. There were two reasons for this: paying tribute to the web and generating readable stacktraces in the UI. The first one was easy to achieve, although I didn't manage to do it with Webpack and had to use Rollup again in the application side. The second one was more tricky because sourcemaps are only downloaded when the dev tools are open, so a stacktrace displayed in the UI will still be gibberish. But I got it working with a library called sourcemapped-stacktrace. I'm still not 100% happy with that setup, but those are application-side issues, so I can tell that the sourcemaps are being published properly.

And with this, I consider the task finished. It's been open long enough to be a "maintenance" task!

Task completed