How to deploy software on a moving bus (2018) | Hacker News Reader

How to deploy software on a moving bus (2018)

engineering.citymapper.com

63 pointsmpweiher21 comments

https://www.theverge.com/2019/6/12/18662577/citymapper-londo...

It seems like they gave up on this fairly quickly.

I thought they would have given up on deploying updates while the bus is driving (opposed to only when it’s being serviced / stationed), but it appears like their whole business proposition didn’t work as intended.

To be honest, I’m usually fairly skeptical to all those “we’re doing the same as X, but we’ll use data to make better decisions!” startups. It’s incredibly difficult to validate, as you usually don’t actually have the data until you’ve reached a certain critical mass, so you’ll end up having to sell the dream instead.

They kind of bootstrapped around this quite well. The first product was a better Google Maps app, which meant they got people's journey data. I wonder if the real problem they ran into was just that public transport in London is pretty excellent, so even with journey data plus the ton of data that TFL provide, it's pretty hard to actually run anything better.

> public transport in London is pretty excellent

Really ?!?

I'm pretty sure most Londoners would disagree with that. Dirty, expensive, crowded, strikes and signal failures. TFL doing everything possible to avoid telling the truth, stating "good service" when everyone on the platform can see they're having a bad day in the office (again !).

Compared to the Japan, the Nordic countries, Switzerland, South Korea, just to name a few, London is dire.

Look at Japan, specifically Tokyo. More populous and densely populated than London. Yes the trains can get a little crowded at rush hour. But I've been visited a good few times now and I've never experienced the London-style horrors. Everything is punctual, clean, no strikes or signal failures. And that's just the Tokyo subway. The Shinkanzen is simply fabulous. Its great !

When I used to write software like this. We typically had some sort of 'vpn', it was usually an isolated network 100% so you did not need that in the first place. For this I would have used an MDN on an isolated network. We would then write a solid bootstrap program with a watchdog on an ISR. Basically it would have an A/B area then we could flip between them as needed. If a particular version did not come up on a vehicle we could default it back to the old version. Usually some sort of flag that said 'yep this version is solid use it from now on'. Usually also the program itself could declare itself as bad usually catching itself in the crash and writing something out somewhere.

Not 100% as vehicle env is pretty harsh. +/-12V in 1-2 seconds on crank so you better have something to deal with that. -40f to +150f so you better have HW that can deal with that. Worry about how much flash wearing you have left. Oh and just general bouncing around, kicking hitting, coffee spills so your hardware better be decently hardened. Even then you still usually had those 10-20 vehicles that you just had to touch them. Usually it would be in the middle of Montana somewhere. If you were lucky it could be at a terminal. Oh and dont cost too much as your competitors probably have better and cheaper hardware.

You don’t want to get in the hardware business here and in most countries you are probably not even allowed to deploy your own raspberry-pi based solution in a public bus, because it doesn’t fulfill the necessary security requirements and certifications.

That is why you have specialized sub-contractors who provide you with tested, certified, ruggedized hardware which you can install into the vehicles. It will also have connections for most proprietary ports you find in those environments. Of course it’ll cost you.

I wonder how they're doing. Crunchbase https://www.crunchbase.com/organization/citymapper-limited/c... has a Series B for $40M back in 2016, and a crowdfunder for £6.7M in 2021. I can't imagine the pandemic was kind to them. It's a shame really, I remember they were fairly active in the London tech meetup scene around their B, usually quite enjoyable talks.

Doing great, thanks, despite the pandemic! Still providing the best routing, hiring (they/we hired me last August), and now also with an SDK for putting all that goodness into your own apps: https://citymapper.com/powers

I remember they had one of the crazier glassdoor pages I've seen - basically a bunch of disgruntled leavers calling the CEO a monster, from looking more recently it seems like they may have made some positive changes.

Based on Glassdoor reviews at places I actually work at, I have learnt to never take Glassdoor reviews too seriously

Based on Glassdoor reviews at places I've thought about applying to, I'd say this was an outlier...

I enjoyed reading the article but I don’t really see the angle here. So they went into a domain they are not familiar with and where we have established seasoned players (yes you can have every bus or tram or train or boat equipped with most state of the art hardware, even clusters.) and started rolling their own hardware.

Most problems encountered here are pretty standard and known so this blog post is more about entering any production environment where you are new and not about deploying to buses in particular. I find the lessons learned here also a bit too vague. I hope it offered more return on investment for them internally.

I worked for a company (back in 2009/10) that was putting LED advertising boards on the sides of (IIRC) NYC buses with an embedded PC to control them and report back to base. They were plagued - CF cards falling out from vibration, dirt and dust, electrical noise, etc. Needless to say, it was not a success.

They were too early would be my guess. In my opinion, embedded in today's time is easy and robust. Your thoughts?

> They were too early would be my guess.

There were rugged PC's available back then for automotive use (think cop cars and the like). To me it sounds like they did not spec the hardware properly or installed it improperly.

Yeah, there were two schools of thought - proper rugged industrial PCs or "whatever we can find cheap on $boxshifter.com". The latter cohort won (although not really because they were a constant nightmare of problems...)

Definitely too early in some respects - the LED boards were huge and clunky, advertisers weren't really interested despite the advantages (for a London bus, apparently, it took ~2 days out of service to replace vinyl adverts which is why you frequently see them with 6m+ outdated adverts), some questionable decisions were made re: software, etc.

I like the emoji idea. So simple and practical both idea and the system as well

If you already need an app on your phone to use the system... why not vibrate the phone? The user is likely holding in their hands to read something (or listening to music with it). I'm not looking at the display for an emoji...

I guess the best way is to do both, or be able to select either.

As an app developer, you don’t get to choose what the user is willing to enable. For instance, there are only three use cases on my phone that can make it vibrate day to day.

Often, a cute interface idea can break a user out of their usual notification habits, which could be pretty important for something like catching a bus!

Reply on news.ycombinator.com