Tag Archives: ai

Software

Volunteering at State of Open 2025

I volunteered at the State of Open conference this month, the conference is put on by the Open Source technology advocacy groups OpenUK.

Volunteering allowed me to sit in on a few sessions. AI was obviously a hot topic. There is naturally a lot of unhappiness at what constitutes the idea of an “open” foundation model; it isn’t just the code and the model weights, there’s also an interest in the training corpus and any human refinement process that might be used.

It is reasonable to assume that a lack of transparency in training data is because a lot of it has been illegally obtained. The conference did have a discussion group on the UK government’s consultation on copyright and training material, one that critics have said represents a transfer of wealth from creators to technologists.

Overall though it felt that there was more unhappiness than solutions. The expectation seems to be that companies will be able to train their models on whatever material they want and can obtain.

This unhappiness rang again for the other topic I heard a lot about which was maintainer well-being and open source community health. Maintainers feel stretched and undervalued, companies have been withdrawing financial support and informal, volunteer-run organisations handle conflict poorly within its own pool of collaborators leading to people leaving projects where they feel criticised and undervalued.

The good news is that people’s belief in the importance and value of openness, transparency and collaboration is still strong. The speakers at the conference were here to share because they want to help others and believe in the power of shared efforts and knowledge.

Becoming a volunteer

Someone asked me about how you volunteer for the conference and to be honest it was pretty straight-forward, I saw an invitation on LinkedIn, filled out a Google Form and then just turned up to the briefings and did the jobs I was asked to do. If I have the time then I think it is always worth volunteering to help out at these kinds of events as while you might not be able to get to see everything you want it also means you have something meaningful to be doing if the schedule is kind of ropey.

You also get to interact with your fellow volunteers which is much more fun that going to a conference alone.

Links

  • Astronomer Apace Airflow as a service
  • dbt a tool for transforming data
  • Tessl a start up looking to switch from coding as we know it today to specification-driven development

Talk recommendations

This is purely based on what I was able to see.

Standard
Month notes

October 2024 month notes

For small notes, links and thoughts see my Prose blog.

Web Components versus frameworks

Internet drama erupted over Web Components in what felt a needless way. Out of what often felt wasted effort there were some good insights Lea Verou had a good overview of the situation, along with an excellent line about standards work being “product work on hard mode”

Chris Ferdinandi had a good response talking about how web components and reactive frameworks can be used together in a way that emphasises their strengths.

One of my favourite takes on the situation was by Cory LaViska who pointed out that framework designers are perhaps not the best people to declare the future of the platform.

Web Components are a threat to the peaceful, proprietary way of life for frameworks that have amassed millions of users — the majority of web developers.

His call to iterate on the standard and try to have common parts to today’s competing implementations was echoed in Lea’s post.

The huge benefit of Web Components is interoperability: you write it once, it works forever, and you can use it with any framework (or none at all). It makes no sense to fragment efforts to reimplement e.g. tabs or a rating widget separately for each framework-specific silo, it is simply duplicated busywork.

The current Balkanisation of component frameworks is really annoying and it is developer’s fear and tribalism that has allowed it to happen and which has sustained it.

Postgres generated UUIDs

In my work I’ve often seen UUIDs be generated in the application layer and pushed into the database. I tried this in a hobby project this month and rapidly came to the conclusion that it is very tedious when you can just have the database handle it. In Postgres a generated UUID can just be the column default and I don’t think I’m going to do anything else in future if I have a choice about it.

Python 3.13

I’ve started converting my projects to the new Python version and it seems really fast and snappy even on projects that have a lazy container spin-up. I haven’t done any objective benchmarking but things just feel more responsive than 3.11.

I’m going to have a push to set this as the baseline for all my Python projects. For my Fly projects extracting out the Python version number as a Docker variable has meant migrating has been as simple as switching the version number so far.

For the local projects I’ve also been trying to use asdf for tool versioning more consistently and it has made upgrading easier where I’ve adopted it but it seems I have quite a few places where I still need to convert from either language specific tools or nothing.

uvx

uvx is part of the uv project and I started using it this month and its rapidly becoming my default way to run Python CLIs. The first thing I started using it with was pg-cli but I found myself using it to quickly run pytest over some quick scripting code I’d done as well as running ad-hoc formatters and tools. It’s quick and really handy.

There’s still the debate about whether the Python community should go all-in on uv, looking at the messy situation in Node where all manner of build and packaging tools could potentially be used (despite the ubiquity of npm) the argument for having a single way to package and run things is strong.

Standard
Programming

Juxt 24

Juxt hold an occasional conference and this edition was focused on Fintech which isn’t an area that I know really well but have dabbled in a bit.

Opening keynote

Fortunately the opening talk by Fran Bennett of the Ada Lovelace Institute was on AI and draw a parallel between the Post Office/Fujitisu debacle and the current level of credulity around the potential of generative AI. I particularly liked this (paraphrased) quote.

Computer systems operate within existing systems of power

If we choose to believe the myth of infallible machines over fallible humans then injustices like the Horizon scandal will just occur again and again.

Eliminating non-determinism

Allen Rohner of Griffin Bank offered a talk on improving testing systems by taking aim firmly at “flaky” tests and attributing them to non-deterministic and side-effecting behaviour either in the system under test or in the testing code itself.

He used the example of the FoundationDB testing strategy and a focus on invariant behaviour to facilitate automated generative testing. The practical twist he offered on this was Griffin’s use of stateful proxies that can also be part of generated testing to provide something strong than mocks or stubs in integration testing.

I think the key takeaway though was to change the way that you think about unreliable tests and consider changing the system to solve the problem rather than hacking around the tests.

Workflows in service clothing

Phill Barber‘s talk on workflows was one of my favourites of the day. Perhaps because I wasn’t expecting to enjoy it and partly because his argument in favour of workflows and orchestrated workflows (over choreographed events) was persuasive. He also didn’t try to deny the problems there can be with workflows: like only being able to visually design them and then exporting them to source control and never delivering the ability to for non-technical to change the system.

He tackled the key issues of the “workflow black hole effect” head on by putting the workflows inside the service boundaries. This approach also minimises the complexity and rigidity that can come from orchestration as you are talking about a few dedicated flows within a service. The orchestration rules are hidden from the service callers and therefore remain malleable.

He also suggested something interesting in that when a collaborating service becomes too anaemic and the balance of functionality ends up in the workflow side you can eliminate the service entirely and allow the workflow to access the datastore associated with the service. In the example given this essentially eliminated a feature light microservice in his example and instead brought the data ownership into a service with broader responsibilities. I would be interested if the idea would extend to multiple data ownerships but the thought only occurred to me well after the event.

He mentioned nflow as an embeddable (JVM-based) open source workflow engine that allows configuration in code.

Monoliths, monoliths, monoliths!

Everyone was of one mind that you should start each development with a monolith as Vlad Yatsenko, CTO of Revolut, put it, the service should be just one box on the system diagram. No-one was fundamentally against microservices but the preference was clear for “right-sized” services divided by organisation or operational properties and to decompose the monolith into the services rather than trying to jump straight to a distributed system.

Magic versus abstraction

In the questions section of the final talk by Zohor Melamed, Harry Percival asked the question about what the difference was between a great abstraction and the “magic” behaviour that Zohor had railed against in his talk. Again paraphrasing the response:

The difference between magic and a good abstraction is that the abstraction doesn’t shape the solution.

Bad abstractions are like async and await, good abstractions are like Docker which genuinely does not leak the details of the running container.

Conclusion

Thanks to Malcolm and Jon for the invite, it was an interesting line up, even for someone for whom the “buy side” is a mystery.

Standard