I’m getting close to new departure calculation code being ready. The implementation is in place and right now I’m focusing on testing it and fixing errors. The way I’m testing it at the moment is by building a departure list for every single stop in the entire country and then comparing it against what I know is the correct list for that stop. There’s around 30.000 stops so it takes a while but at the end I’ll be pretty sure the code works.

I ran it for the first time a couple of days ago, it didn’t even get the first stop right. I fixed that problem and tried again, it got a couple right but hit the next error almost immediately. So I fixed that problem. Then I could run a couple of hundreds before hitting an error. Now it’s just running and running and hopefully it’ll get all the way through. As I’m writing right now it’s completed 48% of all stops without any errors.

Part of what makes this tricky is that often it’s only when you try that you realize that the underlying schedules are really weird, and you have to deal with the weird cases too. For instance, one really hairy problem turned out to be caused by the schedule for Gudhjem Øvre which has a bus that leaves 05:37 on Tuesdays – and also one that leaves at 29:37 on Mondays. Really. Which is actually valid. What leaving on 29:37 on Monday means is that it actually runs at 05:37 on Tuesdays (29:37 = 24:00 + 05:37) but according to the calendar for Mondays. So if Tuesday is a public holiday and Monday isn’t, the 05:37 on Tuesday won’t run because of the holiday whereas 29:37 on Monday will because Monday isn’t a holiday. In effect what you get is two busses at 05:37 most Tuesdays which my new implementation got wrong, it returned only one. This is a mistake in the schedule of course, there is only one bus for that route at that time, but since it’s technically a valid and meaningful schedule the code should behave correctly in that case too.

One improvement of the new version is that the same code can calculate both arrival and departure lists, and it can calculate lists both forward and backwards in time. I need the forward/backward thing to be able to show the scrolling lists in the app where you can scroll infinitely forward and backwards. This means that even when I’m done testing departures for all stops I need to do it again for arrivals, and then I need to do it again for both but listing backwards. And then I’ll be pretty confident the code works. So I’m on testing duty for a while yet.

Now it’s at 90% done without errors!

For the last few weeks I’ve been working on how the app computes the departures from a particular stop. This is the new version that works on android, iOS, and the web version, whereas the current version only works on android.

In addition to working on more platforms the new version is going to be much faster – really lightning fast – and solve some problems with the old version.

The worst problem was that the old way to compute departures worked day-by-day and considered all possible departures every day. This means that even if it’s Tuesday, for instance, it would also consider departures that only occur on Sundays, but just not show them because they don’t run on Tuesdays. At the end of each day it would go on to the next day and then consider all departures all over again. For a departure that runs only on Sundays the departure computation would go: does it run on a Tuesday, no, how about Wednesday, no, what about Thursday, no, Friday then, no, Saturday?, no, Sunday, yes! Now imagine a stop that only have departures in the summer – a ferry for instance – and it’s two months until summer. In that case we have to check all possible departures every day for two months until we meet the first one that actually runs. This approach seemed like a good idea but turned out not to work too well in practice.

In the new version it’s different. Instead of stepping day by day I step departure to departure, so if it’s Tuesday and the next departure is on a Sunday I’ll skip right ahead to Sunday immediately without even considering the days in between.

That’s very technical of course and while it does have an impact on what it’s like to use the app, it may seem like a lot of effort for not that much. And in a sense it is, it’s been a long time I’ve worked on this with no visible impact on the app. As a user of the app it looks like nothing at all is happening. That’s a problem so I’ve decided, in the future, I’ll make an effort to not to disappear into the machine room for long stretches but to spend at least some time making visible changes to the app. It’s not like there aren’t things that need fixing, I just decided not to focus on them. I’ll try not to do that next time.

Okay so a while ago I teased that I might be getting a lucky break. It turns out I did: my preferred domain, atilb.dk, expired and I managed to grab it. I know how much people have to fight (and pay!) to get their preferred domain so I’m super thrilled that worked out painlessly.

Longer term when I start looking into sharing it’s going to be really central but for now I’ve just thrown together a very basic landing page.

It’s one of the first sunny days of the year and a perfect one for sitting outside on the balcony and relaxing with a good book reading a stack of research papers about transit routing algorithms.

Eventually the app will have automatic routing but nothing I’ve read about so far solves the problem in a way I can use. It’s a hard problem even when you have huge servers, it’s even harder on a processor- and memory-constrained device like a phone. But I’ll get there, my head is full of ideas and even if these papers don’t solve the problem they help by planting even more ideas.

Oh, by the way it looks like I might get a lucky break on something that will be quite significant for the project longer term. I won’t say what it is before it’s settled, I’ll just say that it’s something I’ve been hoping for for a while and it’ll be really super great if it works out.