HN user

kerpele

227 karma
Posts1
Comments53
View on HN

Not sure where your information that n8 was supposed to run Meego comes from, but I remember working with the Nokia s60 team already early 2009 and they were using n8 protos at the time. It’s definitely possible that there were two parallel projects though.

On the other hand, Maemo, the predecessor to Meego, required a pen-like pointer to comfortable use at the time as the UI elements were designed to be small. Only after they completely overhauled the UI (and renamed the Linux based OS Meego) it could have worked on the N8.

I’m not a ship engineer but I do know that ships are not built to be suspended from the ends. I guess in the worst case the hull breaks which would mean the canal to be blocked for quite a while.

The main class of failures that I am worrying about regarding the MTTR is the very same observable problem that you solved last week occurring again due to a lack of quality gates. To the customer this looks like last weeks problem was not solved at all despite promises to the contrary.

I think the quality gates mentioned in the article are the ones where you have a human approving a deployment. If you have an issue in production and you solve it you should definitely add an automated test to make sure the same issue doesn’t reappear. That automated test should then work as a gate preventing deployment if the test fails.

Is it possible that the problem there is the amount of women starting studies in stem fields? I don’t have any numbers but anecdotal evidence of two Helsinki based schools in CS related programs had very lopsided gender ratios in bachelors and masters levels.

If someone told the young Linux freak me back in the early 2000s that one day Internet Explorer’s rendering engine is based on the KDE rendering engine I would’ve probably died laughing and frozen in horror at the same time.

Yeah, I realize there’s probably nothing left if the old KHTML but it still does give me a chuckle.

Nice visualization!

I don’t think the algorithm is correct though. The heuristic seems to use Euclidean distance instead of “how the crow flies” and thus this implementation goes along the axis instead of directly towards the goal. This causes the algorithm to find the optimal route only occasionally and probably has little to no effect on average execution time.

I think the big issue with companies like Facebook is not that their development model moves too quickly for them to be able to react to their issues but that they simply don’t care. Facebook has known about the issues with privacy, hyper targeted advertising etc for years. You don’t need to move very fast to react to a fundamental issue in that timeframe.

Exactly.

I remember a few years ago I came across an article on a major car website that ranked four wheel drive as more important in winter conditions than proper winter tires. I personally don’t care if accelerating takes a little longer as long as I’m able to steer and stop, but I guess everyone has their own preference.

On the other hand, a machine will not get tired or bored where a human most definitely will if the diff is anywhere near that 500 lines

I use on Mac (Firefox & Safari) and iPhone, wife uses on Mac (chrome) and Android. Neither has had any issues in the past year and a half outside of mild confusion about the new Safari extension after Apple removed support for the old extension format.

I completely agree with this article. I've worked in scrum and kanban teams and also lead both kinds at some point. To me kanban is by far the better option for the exact reasons outlined in the article.

The point is that deadlines are bad for the people doing the work when they can't influence the amount of work. Not that deadlines should be removed completely, but they should be moved to a level where the amount of work can be influenced, namely project/product management. They should then, completely independently from the development team, adjust the backlog and/or deadlines in case the project schedule starts to slip. If the deadlines are needed because there are doubts that the dev team is not working as hard as they reasonably can then there are bigger issues that any project management method cannot fix.