liampulles

There is a core 20% to Kubernetes which is very nice, mostly being the Deployment and Service management stuff. That along with a very basic GitOps for cluster management (an infra repo for operators using Flux, applying service level yaml from app repos in CI) above a cloud managed Kubernetes cluster, where you still keep your DB and build servers off the cluster, can be quite nice for a small team.

Beyond that, there are massive holes of despair to fall down if a novice team starts to engage with extensive operators (starving the control plane), DB operators (distributed persistence) and build operators (spikey, expensive loads). At least, I know that I've had to dig out of those holes.

I just hope people don't use k8s in the same way many use microservices: as a way to introduce complexity for complexity's sake.

Most stupid animations I have seen introduced to UIs are done because they are stupidly effective at impressing business stakeholders, especially non-technical ones.

It never fails to astound me how some people will fawn over "delightful" transitions. I guess I can understand it in the sense that it is an easy thing to help communicate the perception of high quality to the broader business.

*Claude Fable is relentlessly burning your dollars

There, fixed it for you.

The original Skunkworks optimizes for a low production volume of vehicles which operate in a very extreme band of performance. And yes these projects are able to deliver within budget, but they are still very expensive machines. This is totally opposite to what is applicable to Ford, where really the innovation needs to be in the factory.

The other key lesson from the Skunkworks book, which is applicable, is that to the greatest degree possible, one should not reinvent the wheel. Reuse parts from other high production vehicles, which have proven their reliability. Focus the innovation tactically.

Its never been quicker or cheaper to build something with bad foundational assumptions and principles. Its never been easier to add features whilst not recognizing that it comes with added responsibility. And it will never be too late to hire me for your V2 migration project.

Ok, but doing manual memory management in Rust is a bit like digging a ditch with a spoon. I get that its technically possible, that does not mean it should be done outside the most exceptional of circumstances.

There are performance reasons to handle memory allocation manually and tactically. This is why languages which deal with memory manually are not going anywhere.

Whether Zig will become dominant in that space remains to be seen.

This kind of thing is totally routine here in South Africa. Probably about a third of power cuts in my area these days are due to some kind of cable or electrical theft.

I'll wait until they do some PAL emulation: take an NTSC source, blurrily upscale it to 576p, apply a crap deinterlacing algorithm to produce a technically progressive image, and some frame blending to get it to 25 fps. Shitorific.

I think the 80/20 solution for reliable workflows is:

- Ensure the workflow is idempotent - if it stops or fails at any point, you should be able to start it from scratch and skip / happily redo various elements.

- Store the messages which trigger workflows.

- Track failures (if your log aggregation is good, even that's enough to start).

Then when the odd thing fails (or sometimes a bunch of things fail, because e.g. a core integration goes down) you can lookup the messages and have a little script or tool to go and re-queue them. This is an easy starting point that can keep you going for a long time until you really approach huge scale.

At my last company, I wrote a little tool for pretty printing our JSON logs. You pipe into it and it prints out. It's quite easy to write such a thing in Go, and useful for assigning preferred timezone conversions, and colors for your special common log items.

It's interesting to think that logging is now an undocumented API.

My usecase would be investigating a potential integration - I want to go and see everyone's comments on the websites themselves. I'm not looking for an answer - I don't know the question - I'm looking for understanding.

Google's Search and its AI result can alternatively help or hinder me, I find.

If I'm looking for a relatively straightforward and simple piece of information quickly (e.g. "wooden arch mirror stores linden") then the AI summary can be useful, because I don't need more than surface level info.

If I intend to analyze and understand something (e.g. "developer API issues Zoho Thrive"), then the AI summary and the general degradation in the quality of search results from Google really hinder me. I have to work to avoid a lazy and low value answer, whereas what I really want to do is go through various actual websites and reflect on them to gain insight.

Developing software is as much about the journey as the destination. I build a lot of my understanding of the actual problem in the pursuit of solving it.

There are many times when writing a feature that my spidey senses flare up and tell me that this thing is a lot more painful to code then I was expecting (and will be painful to maintain) and that a more elegant process may actually solve the problem, at which point I'll draw up an alternative option and talk to the product owner.

I've definitely started to see the consequences of the converse, which is large amounts of shite brittle code that solved the original spec narrowly, but is now an elephant on our back when we need to add other concerns to the system that cross over.

(BTW, this isn't against the use of coding agents entirely, its more against high-level agentic usage. I tend to use Claude Code to do little well defined tasks whilst I reflect on it).

As a millenial, I first got into something-like-programming by playing around with Game Maker. A few of my colleagues have said similar. I'm curious to see where others in my cohort started...

The show has its moments - mature, intelligent, human moments found little elsewhere - but its an intelligence that struggles to escape very typical network sitcom trappings. One wishes it had gone a little more in the direction of M.A.S.H. and ditched the pretense of having to make jokes every minute.

I still have my jailbroken PSP, back from my school days. Great fun for playing emulated PS1 games. I imagine joysticks and buttons on modern handhelds are considerably better though.

Can't wait to see the rooting hacks resulting from mousing over a strawberry and text saying "count the r's".

Another way to read it is that they are shifting blame away from their backend - which is so shitty that it experiences notable service disruptions when some of their existing users send unexpected headers - onto the client software.

And they report service disruptions as a result of this - so perhaps they are are also learning what gateways are.

Blaming the CLIENT for this is absolutely crazy.

I own a base model 2020 Suzuki Swift GL, which I specifically bought because it has no touchscreen. It has a radio with Bluetooth and dials - that is it.

No issues so far.

Well Zuckerberg, this is the brainrot staring back at you.

I used to write raw HTML for my blog because I needed more formatting and structural power than what Markdown could provide for Jekyll. Then I built my own little blog generator that uses Markdown and which pre-substitutes my own hacky syntax elements for the extras I need.

And this is what Markdown is for: its just enough above plain text such that you can get at least 95% of what you need for a blog post, whilst still have the source be easy to type and proof read.

Frankly, calling software development engineering is quite debatable. We should be calling less things engineering that aren't actually engineering qualifications.

Sure, but this issue is not specific to QA. Any roles which you depend on with incompetent people occupying them will lead to issues and frustration.

I work with someone who does great QA work. They know how to rip something apart, they understand the user's non-technical perspective and approach, and they understand what edge cases to look out and they have the actual equipment to test on different physical devices (and so on).

Most importantly, they have the diligence and patience to methodically test subtly different cases, which I frankly don't have.

On the question of whether QA slows things down, I have to ask: slows down what? Slows down releasing something broken? Why is that something to optimize for? We should always be asking how long it takes to release the right thing (indeed I'm most productive when I can close a ticket after concluding nothing is needed).

You are not wrong. There are of course tradeoffs here. There are various things that can improve web service performance, but if we are talking about the performance of a web service in comparison to other more general concerns, like maintainability, then I agree trying to make small performance wins falls pretty low on the list.

After all, even if one has some slow and beastly, unoptimized Spring Boot container that chews through RAM, its not that expenseive (in the grand scheme of things) to just replicate more instances of it.

I use Ecto with Elixir in my day job, and it has a pretty good query building type solution. BUT: I still regularly come into issues where I have to use a fragment in order to do the specific SQL operation that I want, or I start my app and it turns out it has not caught the issue with my query (relating to my specific MySQL version or whatever). Which unfortunately defeats the purpose.

My experience with something like the latest Claude Code models these days has been that they are pretty good at SQL. I think some combination of LLM review of SQL code with smoke tests would do the trick here.

I agree with you fully yes. One has to watch out for overwhelmingly large or locking queries.