Today's key insight: Browser APIs expose everything you need for MVC applications without the need for a framework:

* Model (Fetch API)

* View (HTML Elements)

* Controller (Events)

What browser APIs DO NOT GIVE YOU is a structured way to combine them. And there are a couple of things I'd like to see added:

1. Local Model objects that work like HTTP end-points, but may either pass-through HTTP end-points or update the data locally

2. Richer events with more context

When a website stops working and the fix is 'clear your cache', the problem isn't the cache. The problem is someone screwed up in a big way and they are unaware of or incapable of using HTTP cache headers correctly to fix it.

The fact this happens most often on the websites of big companies with large IT departments is entirely ridiculous.

The fact their support departments push the nuclear option of 'clearing the cache' AS IF IT WAS THE CUSTOMER'S FAULT is heinous.

Scenario: you are a software developer working with a customer. The customer has a requirement you do not like and you are pushing back against. In your pushback you rely on technical arguments the customer is having difficulty understanding.

Is the problem:

1. The customer's lack of understanding?

2. Your inability to explain?

3. Your own lack of understanding of the customer's requirement?

I submit (3) is often the case and it's your job to deal with the technical problems.

I was working my way through a thought-experiment on a different way of implementing web apps when I got to wondering if JSON or Protobuf was faster. Certainly JSON uses more bandwidth, but is the generating/parsing performance materially faster?

So I googled it. The answer is: Protobuf is faster, but not enough faster to choose a non-human-readable format over JSON.

Today is one of those days I really wish I hadn't agreed to un-retire and go back to work. So many things are bugging me right now.

Really, it all comes down to the fact the company has managed to turn 'Agile' software development into 'Waterfall' – and middle management won't acknowledge their processes are getting in the way of getting things done.

I blame a combination of office politics and Jira.


Mentally burned out.

Been writing technology descriptions for the company patent lawyers, which requires a different kind and level of abstraction than any or software architecture task.

Plus I'm not really on board with the whole idea of software patents, so it's annoying at the same time…

It's 2021 and I am a software designer dealing with an entire team – programmers, SDETs, scrum masters, product managers, the works – who have never read Fred Brooks' classic 1986 essay 'No Silver Bullet'.

If you are involved in large scale software development and have NOT read this essay, stop whatever you are doing and read it now.

Seriously. It has aged EXTREMELY well and 25 years later we are STILL dealing with the same misguided expectations.

This seems handy…

> Git Command Explorer. Find the right commands you need without digging through the web.

My job is designing SAAS software products. Big SAAS systems with enormous complexity and lots of parts, some of which are operating 'out in the wild'.

My biggest challenge? Getting software engineers to think about the problems they are solving with the right level of abstraction. They want to get into the weeds of detail, so they end up talking about how to solve the one particular problem right in front of them.

Whereas I want to solve the CLASS of problem.


> Patchbox OS is a custom Linux distribution specially designed for Raspberry Pi based audio projects.

In my opinion, a software application may only be considered a success when it is used in ways its creator never designed for or even imagined.

> Cosmopolitan Libc makes C a build-once run-anywhere language, like Java, except it doesn't need an interpreter or virtual machine. Instead, it reconfigures stock GCC and Clang to output a POSIX-approved polyglot format that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS with the best possible performance and the tiniest footprint imaginable.

Working with JSON-Schema today. It's powerful and expressive enough, but why does the tooling not support sub-schemas on a file system naturally, without fuss, in the same way as for http URLs?

Only, if you use http URLs there's no good way to do a test/fix/test loop. You can use a web server running as localhost, but you need to fix all the URLs before you can roll out to production.

And then test in production to make sure you didn't miss something.

It's stupid as hell.

> [Edsger W. Dijkstra] “Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”

In the news (again): Package managers and shared libraries on CDNs being hijacked by darkside hackers.

Me for the last fifteen years: Package managers are evil. Only use libraries you vet and manage yourself. If you are compiling binaries, avoid dynamic linking and static link only to code compiled from source; no library obj files.

Me for the last ten years: NPM is especially evil and the reliance on it for everything Node.js related means you should avoid Node as well.

Show older