I had a bunch of fun following along with this post with my own Hugo blog to construct a sqlite database of metadata. Building the database indices, I found a mistake I had made years ago in defining a post’s alias, which was a duplicate, so I fixed that. I’ve read a lot of praise of sqlite lately and wanted to get more familiar with the tools and ecosystem and this was a nice way to start to do that.
I used open-interpreter to read an epub file and create a DIY audio book. Open-interpreter suggested that I use the bs4 and ebooklib libraries. It recommended an API to create audio files from text, but I was easily able to switch this out for the free and local alternative, say on macOS. As I worked (let the model write code), it was easier to copy the code to a separate file and make modifications.
Further investigation with Open Interpreter today reaffirmed certain strengths but also revealed a number of weaknesses. The look is excellent at parsing structured data like JSON or CSV, doing analysis with tools like pandas and numpy, and plotting the results with matplotlib. However, it falls short when trying to perform more complex data fetching tasks. It seems to struggle to scrape websites or make use of less common libraries, at least when I tried without providing any additional documentation.
I did some more experimentation with open-interpreter today. The first use case I tried was to create, organize and reorganize files. It didn’t generate interesting content, but it was fluent at writing Python code to organize and rename files. When I prompted it to generate a fake dataset, it installed faker and created a CSV with the columns I requested. When I requested it plot those data points, it installed matplotlib and did so without issue.


I read quote from a long tweet the other day that made me smile. Writing pure JavaScript is like trying to cut a watermelon with a chainsaw in the dark. It sounds fun and free and quite easy until there’s a roomful of mess to clean up. https://twitter.com/kettanaito/status/1699440414812504443
There is a website I log into often that I protect with 2FA. One thing that bothers me about this process is that the 2FA screen does not immediately focus to the input, so I can immediately start entering my 2FA code. Today, I tackled that problem. The most recent experience I’ve had writing userscripts was with a closed source browser extension. A few minutes of search and I discovered Violentmonkey, an open source option with no tracking software.
I usually use tail -n +2 to get all the first line of a file but today I learned you can also accomplish the same task with sed '1d' Both also work for removing more than just the first line of an input. To remove the first three lines sed '1,3d' is equivalent to tail -n +4 It seems like tail is recommended for larger files though, since it doesn’t process the entire file.
To write software is to experience constant failure until you get a success. When you start learning to write code, very little works, especially on your first try. You make a lot of mistakes. Maybe you copied example code to get started, then modify it to try and do something new. Reading errors to help you understand your mistakes is the only way forward. You can read documentation, search the web or chat with a language model to try and work through the problem, but it is inevitable that you will make mistakes when writing software.
It’s much easier to test Temporal Workflow in Python by invoking the contents of the individual Activities first, in the shell or via a separate script, then composing them into a Workflow. I need to see if there’s a better way to surface exceptions and failures through Temporal directly to make the feedback loop faster. From this paper: 62% of the generated code contains API misuses, which would cause unexpected consequences if the code is introduced into real-world software