elsurudo

I find the rest of Trailblazer a bit over-engineered and prescriptive, but I really like cells (http://trailblazer.to/gems/cells/). IMO these are good for encapsulating view state. It more replaces the "helper" layer than controller layer, but it also helps you write controllers that just focus on HTTP stuff and nothing else (together with service objects, of course).

Point taken that it is ok to use i, x, y, z sometimes (eg. when iterating), but the notion 'a meaningless parameter that is just a variable' doesn't really exist... if it's meaningless, why are you saving it?

Only other use case I can think of is doing metaprogramming or some sort of templating where you have a variable, but might no even know what it represents, because it isn't your concern.

Fascinating. Where can I read more such analysis? About TSLA, but also just in general.

Boiling a frog? https://en.wikipedia.org/wiki/Boiling_frog

Looks nice overall, but I'm not a fan. It has nothing to do with the implementation itself... just the fact that I view the consistency of the iOS UI toolkit as being more important than fancy looks.

It's a good thing (tm) that no matter which app I open up, the date picker looks the same, and works the same. This is the nice thing about native apps. So I wish we would stop reinventing wheels like this (once again, no offence intended to the author – this is a more of general critique).

Not sure if you should rely on SemVer for maturity estimates either, though. I guess it can be one signal, but I wouldn't say a very useful one.

To scratch a similar itch today, I self-host (well, on Heroku) an instance of Huginn (https://github.com/huginn/huginn). It's a bit of a different model, but works nicely. It's also pretty straightforward to extend by adding your own agents (especially if you know ruby/rails, which it is written in).

Good riddance. The web was a finer place before this ad boom.

Brave "rewards" started appearing in my Android's notification center without my consent. Seems pretty intrusive to me, and I defiitely did not opt in...

> Toronto seems like a bit of an unfair example when you compare sheer ridership because it’s bigger than all but five US cities

Actually the metro area pop. is only beat by LA IIRC, so your point is even understated

Interestingly, Toronto has pretty terrible congestion. I haven't lived there in a while, but IIRC "rush hour" is more like 3 hours (morning an evening). And (apparently) the bus network still does a decent job. Not sure how true that is, but I hope they at least added dedicated bus lanes wherever possible.

Are you sure that was the reason they did that? I don't have any evidence, other than that I always assumed it was either cheaper or more practical to have narrower gauges in cities. It seems to be the case for most streetcar networks I've seen...

Maybe "inevitable" is too strong, but only slightly...

Those entities that don't adopt automation will be outperformed and supplanted by those that do.

It's a similar phenomenon with many technologies. Many people opposed cars, looms, cell phones... what happened to them?

It's not always _just_ about objective features. I really like trams and trains in general, because they feel "solid" – like an immovable part of the city infrastructure. There are mental benefits to this, I feel. Buses jostle around, abrupty change speeds, etc. Trams... just glide. You are on a movable walkway, seeing the cityscape unfold on both sides as you commute to work.

Sounds like an excuse. If I can find a way to make something like this gracefully degrade, I'm sure Google also could...

You might say it's over-engineering, but in aggregate terms this could make a big difference in power and network usage. I'm talking more about the users (usually mobiles). So I would call it just... engineering.

I assume the GP meant "scale of codebase complexity" – which is orthogonal to whether something is "web scale" (ie. everything Google does).

Thanks for these links. As a UW CS alum who didn't take the CS452 and now regrets it a little bit, this was fascinating reading – especially when he gets to the modelling aspects (last link).

Ads, but they mimic the look of regular results

> People should really stop complaining about the dongle situation.

You're not really refuting anything below, just essentially saying to people: you know, I know better than you, you don't really need these things (the same thing Apple is saying).

> Just about any portable device can be bought with USB-C or wireless. For fixed desk hardware (keyboard, mouse, monitor, ethernet) you should use a TB dock anyway.

Never had a need for a dock before...

> Yes, if you do presentations you probably need a dongle for the projector, but that has always been a mess anyway (VGA, HDMI, DP, DVI, it's never the same connection as your laptop).

I dunno, HDMI is pretty standard these days.

> Yes, if you use a camera you'll need an external SD card reader, but you'll need that for many other computers too.

No my current MBP, though, which is the point here.

> how teletext worked

How teletext works! In Europe, it is still used. There is weather, classifieds, LOTS of "seeking partner" ads usually for the older generation, etc...

Really neat technology/"hack" when you think about it

I mostly agree with what you're saying, but I will add that is is also possible to write well-designed, modular, easy-to-test (minimal mocks) OOP code. It does provide more guns to shoot yourself in the foot with, I will admit.

I recently used table inheritance to great effect on a project, so I wouldn't write it off completely. My use-case was a bit different as it involved zero-downtime data imports from separate sources (concurrently), but it proved a great tool for the job.

At UW (University of Waterloo), our Real-time OS class projects used physical trains. Walking the halls of the Math & CS building, you could see kids "playing with trains" all through the night quite routinely.

It had the reputation of being one of the hardest CS classes in the undergrad curriculum.

Wow, what a sincere message. That right there is a true encounter. His philosophy – much like Erlang's – is unique and refreshing.

I flew Jet just once (from Toronto to Hong Kong I think), and I remember it as the only airplane meal that didn't seem like it came from a microwave. It was actual Indian food – maybe not top-tier-restaurant quality, but good! They also handed out _actual_ hot towels – not those single-use ones. This was all in economy.

I have nothing to add, except to say thanks for writing that – I really enjoyed reading it. A bit of whimsy in the preceding paragraphs.

I use Safari on a Mac with a simple ad blocker, but I use a lot of Google products, and I also get a captcha most of the time.

So perhaps it's Safari and/or the ad blocker that are to blame? Hard to say, though.

He never said it was worse, just that it is bad. Both of these are bad.

Hi Martin,

First of all, this is great work, and fascinating!

Suggestion: for the "named roads", I think it'd be a good addition to actually add the names of the roads.

SEEKING WORK | REMOTE (EU) | FT, PT, TRAVEL OK | Experienced (8+ years) full-stack web and mobile freelancer

Well-rounded developer with an attention to detail. Things I've done: greenfield projects, prototypes, refactoring, team leadership/building, project management, and more.

Expert in: Ruby on Rails, Objective C, Swift, Vue.js/JavaScript/TypeScript, Architecture, Relational DBs

Experience with: C, C#/VB.NET, Python, PHP, Java, Ember.js, + many many tools one comes across as a working developer these days...

Currently learning: Blockchain/Solidity, Node.js, Scala, Elixir/Phoenix (would love to work with these technologies – will offer preferential rates!)

Education: University of Waterloo (Canada) Comp Sci

---

Web: http://www.twisted-leaf.com | Email: ernest [at] twisted-leaf.com | LinkedIn: https://www.linkedin.com/in/elsurudo/ Resume: http://static.twisted-leaf.com/ErnestSurudo-resume.pdf