MacKuba

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.

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?

Here are my notes from the Mobile Mobile Conf that took place in Kraków this week. I just wrote down what I heard, so it might not be completely correct, but I figured it will still be useful.

I’ve recently updated my new blog’s layout to support mobile phones, iPhone in particular (since that’s what I’m using ;). Here’s how it looks now:

I decided to use the same HTML for both versions, and use CSS media queries to define how the mobile version differs from the main one – I thought this was the cleanest and simplest solution in this case. For more complex sites, it probably makes more sense to have the two versions completely separated.

Surprisingly, it was quite easy to do once I figured out what exactly I needed to do. Turns out, the hardest part is apparently knowing what to put in your header and what media queries to use. Here are some tips and suggestions if you want to make a mobile version of your site too:

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:

For the last 3 months I’ve been working on a new web application at work. It’s quite unique in some regards, from the architecture perspective; the biggest difference from other projects that I’ve worked on is that almost entire page is one huge embeddable “widget”. This requires a completely different approach than I usually use:

• a lot of the code above the model layer is moved to the client side (i.e. JavaScript); this means that controllers and helpers are rather simple, controllers mainly return JSON, and there’s quite a lot of JavaScript to write
• since a significant part of the system is written in JavaScript, it needs to be unit-tested too
• I have to be very careful not to cause any JS, CSS or DOM id conflicts between the embedding site and the “widget“ (which includes such things as keeping all JS code in a single global namespace, and using jQuery in the “noConflict extreme“ mode through an alias)

Another thing, which I’d like to write about today, is the way the views were implemented in this project. Since entire GUI is created dynamically by JavaScript, I had basically two options:

• render the views in Rails with ERB and send big chunks of HTML via AJAX to JavaScript;
• or make Rails send only data as JSON, and render the views on the JavaScript side.