MacKuba

I had different plans for this year… then, Elon Musk happened.

Elon took over Twitter in October last year, which set many different processes in motion. A lot of people I liked and followed started leaving the platform. Mastodon and the broader Fediverse, which has been slowly growing for many years but never got anything close to being mainstream, suddenly blew up with activity. A lot of those people I was following ended up there.

Then, Twitter started getting progressively worse under the new management. Elon’s antics, the whole blue checks / verification clusterfuck, killing off third party apps and effectively shutting down the API, locking the site behind a login wall, finally renaming the app and changing the logo – each step made some of the users lose interest in the platform, making it gradually less interesting and harder to use.

Changes, so many changes… and things changing meant that I had to change my workflows, change some plans, build a whole bunch of new tools, change plans a few times again, and so on. My GitHub looks like this right now, which is way above the average of previous years:

Back in spring I built a website that lets you browse charts of coronavirus cases for each country separately, or to compare any chosen countries or regions together on one chart. I spent about a month of time working on it, but I mostly stopped around early May, since I ran out of feature ideas and the pandemic situation was getting better (at least in Europe). The traffic that was huge at the beginning (over 10k visits daily at first) gradually fell to something around 1-1.5k over a few months, and I was only checking the page myself now and then. So it seemed like it wouldn’t be needed for much longer…

“Oh, my sweet summer child”, I kinda want to tell the June me 😬

So now that autumn is here and winter is coming, I suddenly found new motivation to work on the charts site again. But instead of adding a bunch of new features right away, I figured that maybe some refactoring would make sense first. I initially built this page as a sort of hackathon-style prototype (“let’s see if I can build this in a day”), but it grew much more complex since then, to reach around 2k lines of plain JavaScript – all in one file and on one level.

I started thinking about how I can make this easier to manage, and somehow I got the idea to try TypeScript.

Since my update to the iOS version of Banner Hunter was rejected by app review, the app’s been in a kind of Schrödinger state, both dead and alive. It’s still selling those few copies a week, and I’m updating the blocklist, but I’m afraid to make any updates to the Mac app now… So since then I started looking for some other ideas for new apps I could build instead.

One thing I started working on is a Chrome version of Banner Hunter. I wasn’t really planning to do it before, but since Apple pushed me now… I might as well give it a try. I have no idea if it’s possible to make any money on Google Store, since the vast majority of extensions are free, but we’ll see. The main part of the app is done, but I need to work on the non-technical parts like graphics and copy, and it will probably have to wait until late summer at least.

I’ve got another idea though which has kind of come up by itself, which is… to build an ad blocker for Safari.

(TLDR: here’s the landing page.)

I’ve been tracking the growth of the new coronavirus ever since it first appeared in China in the last week of January, and even more since it spread to Europe around mid February. Initially I’ve been looking mostly at the popular ArcGIS dashboard made by Johns Hopkins University that everyone is probably familiar with.

However, I really wanted to see some charts showing how the numbers grow in each country separately, since just seeing “8000 in Italy” doesn’t tell me much if I don’t remember how much it was yesterday. At that point it wasn’t possible to see that kind of information on the dashboard, and I couldn’t find any other source that showed that in an accessible way.

But then I saw a mention in the footer on the dashboard that the authors have shared all their data (including past numbers) in a GitHub repository in the form of CSV files. So of course I decided to do what always comes to my mind when I have a problem to solve… build a new project :)

And that’s how the Coronavirus charts site was born.

I’ve read a post comparing Backbone to AngularJS recently, and another that ended with similar conclusions about Backbone, and since I’ve been working with Backbone for the last year or so, I thought it would be a good idea to share my own experiences with it.

In 2012 I’ve been working with a few other developers at Lunar Logic on a new webapp. We’ve decided from the beginning to build it as a single page application, based on an API that was being developed for an existing mobile app. We have considered EmberJS for a moment, but we’ve decided it probably wasn’t stable enough at that point, so we went with Backbone instead.

Looking back I think we made the right choice back then - EmberJS has changed a lot since then (some important parts were still being changed a couple of months ago in 1.0-pre versions), and they still haven’t released a final 1.0, though it seems it’s getting close to that. I’m also glad I had a chance to learn Backbone and get to see its pros and cons. Still, if I was starting the same project right now, I’d probably choose Ember instead.

So what have I learned about Backbone during this year?

If you’ve read the Rails 3.1 asset pipeline docs, you’re probably aware that you can add preprocessors to your asset files by appending extra file extensions. For example, to write your JS files in CoffeeScript you need to add the suffix .coffee, and if you also want to pass something from Rails to those files, like paths to image files, you also need to add the .erb suffix. All the extensions are added together, so you end up with e.g. profile.js.coffee.erb (it’s simpler with stylesheets, because by adding a Sass preprocessor you get a bunch of asset path helpers for free).

What the docs don’t tell you is that Sprockets can also be configured to include preprocessors implicitly based on a content type.

I started this blog almost 3 years ago. It was a bit of an experiment, as I wasn’t sure if that actually made sense, if I would want to keep writing it a few months later – so I put it on Jogger (Polish Jabber-based blog service) and I used the classic Kubrick design.

Since I’m rather happy with how this experiment ended up, it was time for a change. The new version is hosted on Linode (definitely the best hosting I have used), and uses a custom-made engine based on Sinatra. Hopefully with this new design I’ll have a bit more motivation to write, because I just couldn’t look at the old one anymore…

If I find some more time, later this year I’m planning to learn some NodeJS and rewrite the engine using it (e.g. with Express).

There’s a few things that I’ve learned while working on the redesign:

I’m working on a new version of this blog, in which I want to use RightJS. This week I wanted to add some kind of pretty JavaScript tooltips there; there is a Tooltip class in RightJS, but I don’t like the way these tooltips look. However, I know a jQuery library called “TipTip” which adds very attractive black tooltips. So I took the TipTip code and rewrote it using RightJS (and renamed to RipTip, for obvious reasons) – code is available on GitHub, as usual.

This is how the tooltips look: