liampulles

Wasn't Capital One founded on the premise of massive-scale market and product experimentation? Makes sense that they would design tools that match that approach.

I love the principle of this. I hate the truncated graphs.

The copy here says that your data is Local-only and that it can interface with Claude, Codex, or Gemini... are you running these models locally, or am I missing something?

Great video on the subject of applying science to business and government: https://www.youtube.com/watch?v=sf0vb4yiZR4&t=2s

Having deno desktop do the framework handling for a bunch of popular options is an interesting choice. It seems deno is trying less to be an agnostic JS runtime, and more an "integrate everything toolkit" (not unlike Spring in the Java space).

It's very similar to Optional types in Java.

At a previous job, we introduced a simple Optional generic type, with JSON implementation, and it pretty much solved uncertain nil issues. Sometimes the solution is simple and boring.

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.