We steer software development with visualizations. They nearly never look as nice as the ones we typically put on Keynote or PowerPoint presentations for the board. Missing legends, no great layout, lots of accessibility issues. Why do we do that? Static vs dynamic With GToolkit, the picture itself is only
Yesterday, I was at FOST Amsterdam where Lucía Luzuriaga presented Building Digital Democracy: Code, Community, and Trust. She describes it as: As governments seek more inclusive approaches to decision-making, open-source civic technologies are playing an increasingly important role. Consul Democracy is one such platform, enabling participatory processes like consultations, participatory
We have been building up a growing collection of analysis tools that we use to analyze existing code bases and steer development. The existing workflow of starting GToolkitLauncher, opening the releases view, clicking to download the latest version, and then copying and inspecting multiple Metacello invocations to load the tools
Updated from an earlier posted on LinkedIn If this is state of the art at Cursor, I have some questions. The largest LLM generated Rust file in the repository is over 77000 lines. That is far too large, and shows that working with so many agents on the code base
Prototypes are easy, but getting an LLM to generate maintainable code over a longer period of time is not. As the models are not yet good enough, we need a very short feedback cycle. Reading all the code doesn't scale, and we need another way to maintain trust
When I get into a project with existing software, I need to know whom to ask for help if I don't understand something. The source code repository can tell me who made changes to which parts, when they were done, and in what way they were made. It
In our production environment we're hosting a number of virtual machines and containers. As a step in the direction of Digital Sovereignty, we are evaluating several environments. ProxMox is one of them. It has a nice web user interface for managing a cluster, but we don't
We see a lot of people enthusiastically getting started with GToolkit. Some of them stick around, but a lot of them try a few things, make some nice graphs, and then somehow drop out. Why does that happen? Here are some of the hurdles to cross: Moldable development requires new
When using LLMs to help us write code, we want to have an overall understanding of the code, and significant details. We do not necessarily want to read all the code. In an earlier experiment we had to throw away what was generated, and that is something we want to
Keeping up with the rapid pace of GToolkit development is a challenge. Often several new versions of GToolkit are released per day. When I'm working on projects not using GToolkit, it is difficult to follow along on the development Discord and GitHub. With the default download process the
Moldable development with Glamorous Toolkit (GToolkit) can be overwhelming. So many tools, and when you start with existing code, there are so many places to start. Which one do you choose? We often see enthusiastic people try something with GToolkit and then stop when they find out that not everything
In this episode we focus on specific views that allow stakeholders with deep domain knowledge and us to have a shared understanding of risk, value and progress of the migration - early and continuously. (Part 1) Steering on value and risk Stakeholders need to understand what we are doing and