Archive for December, 2018

Shunning Frameworks

I’ve used frameworks for about every language I’ve used throughout my entire career. I’ve always picked up a language and a framework at the same time – using the framework as a guide for what is possible, what the best practices are, and how to write idiomatic code. Quality, of course, varies by framework.

Over time, I’ve started to realize that frameworks provide magic, and there are secret incantations to bring out that magic. I can usually jump into the source and figure out what’s going on, but this detracts from developer velocity. And this makes the framework less appealing; I start to feel that I’m using a language on top of another language which quickly leads to a halt in developer velocity due to the law of leaky abstractions.

The law of leaky abstractions dictates that as abstraction complexity increases, the likelihood of exposing the underlying complexity also increases. Most modern frameworks allow for the customization of abstractions, allowing you to plug any leak. But there is always that one case the framework doesn’t cover and when you’re the only one with that problem, you really have to get your hands dirty.

I no longer use frameworks. Or I should say I build custom frameworks for the problem I’m trying to solve. I do this by piecing together libraries, which of course have their own leaky abstractions, but they are not usually monolithic. And if there truly is a leak and nobody has ever had the same problem, I’ll fix it and contribute back to the community. Actually, if nobody has ever had the same problem, I’m usually doing it wrong.

Inspired by this nice post over here – Stop Learning Frameworks.

gRPC Clients

Not speaking for my employer, but about my employer:

Our entire QA team has scoured the internet looking for a gRPC equivalent of Postman. So many contenders… so many failures. Not a single client we’ve found has been able to do a fraction of what we want. The closest we got was a cli tool that failed on recursive definitions. Fail, fail, fail.

To fill this void, we had to create our own client. The main one is Java based and is used heavily by QA to test all our definitions and endpoints. The other is a kafkacat type utility that reads protobufs out of Kafka. This one if Python based. Sometimes the two conflict (e.g. Timestamp), which causes us to rip our hair out. Best to stick within one language for testing.

Someday, when I have an exorbitant amount of free time, I hope to slap a UI on this thing and release to the public.

The Death of Edge

Update: Brave has also fallen.

Microsoft released Edge on July of 2015, dethroning IE’s decades long reign on error. Initially, Edge was going to support the legacy IE renderer, but this idea became the laughing stock of Redmond (or so I assume) and they abandoned it. Web developers the world over cheered, until they realized how much money that single app doled out.

I’ve never had the pleasure of making anything “Edge-compatible”, I haven’t heard much negativity so it comes as a tiny bit of surprise this engine is now getting dropped as well. Again, devs cheered (I literally heard this in the office), but the reality is the we are now left with three mainstream engines – Chromium, Webkit, and Gecko.

Quick economics on this:

  • fewer engines = less competition
  • less competition = winner takes most
  • winner takes most = less standardization
  • less standardization = winner takes all
  • winner takes all = we all lose

I certainly don’t think we want to live in a one-world engine. Before you cheer for Chromium, think about what the consequences could be… and give Safari or Firefox a chance. My primary browser right now is the Safari Technical Preview, I highly recommend it.