Gitara: a local function-calling git agent

I wrote a blog post at our company blog about how we trained a local Small Language Model git agent.

Close the loop

It's hard to think more than a couple of steps ahead when you're building something new.

When you're walking in the dark, don't leap forward because you'll end up in a ditch. Instead, take things step-by-step, at each point gathering new information, re-evaluating where you are and what you want to do next.

Building new things is like that - action gives you information so you need to act to gather information and plan ahead. But you can't plan too far ahead, because you only have a little bit of information, so you need to keep moving so you can plan further. Not having a plan is bad, but following a plan past its expiry date is worse.

Surprise, your data warehouse can RAG

Another post on the Rainforest blog, this time about how to do RAG in your existing data warehouse.

The importance of doing the exercises

You know the feeling of going through some materials and thinking "I got this, I understand everything"? And seeing the exercises at the end of the chapter and feeling they're completely pointless because you understand everything already and it's just a waste of time?

I remember feeling like this when I was 11 and then forcing myself to do the exercises anyway (only because they were my assigned homework) and discovering that, to my huge surprise, I didn't actually completely understand everything yet. And then going through them, re-reading some of the stuff I thought I knew, trying again and then eventually getting it. And then having this renewed respect for the exercises at the end of the chapter.

The thing is, this cycle happens to me every time I go through some learning material. You'd think that by now my monkey brain would learn that the exercises are really valuable no matter how trivial and obvious they seem at first. But no, it hasn't - I know I need to do them, but I still feel they're pointless and need to force my way through the feeling.

Building reliable systems out of unreliable agents

I wrote a post for the Rainforest blog about how you can build reliable systems out of the unreliable agents built with today's LLMs. Check it out!

Deploy really hot code with habanero 🌶️

How can you dramatically decrease time-to-deploy? Wouldn't it be cool if your CI/CD pipeline took very little time? Wouldn't it be cool if it took zero time? Is that even possible?

One way to minize deploy time is to follow the standard procedure and use solid engineering to parallelize your tests, get beefy CI machines, add lots of caching etc. Another way is to throw all the best practices out of the window and YOLO hot-code deploy whenever your local code changes. Guess which path this post is about.

Luckily, Elixir has very good hot-code-deploy capabilities. Unluckily, hot code deploys are pretty complicated if you want to do them right with no errors in production. Luckily, I don't have production constraints on my side projects, so I can do it the easy way anyway.

Deploying regex.help and CI/CD

Now that I've written up [how regex.help was built]({% post_url 2021-05-20-building-regex-help %}), it's time to focus on deployment. I used to think deployment was... not the most exciting part of building things. Howqever, recently I find it more and more interesting, probably because I care more about good CI/CD. Elixir and fly.io make it even cooler and shinier - let's jump in!

In my [last side project]({% post_url 2021-05-03-building-secretwords %}), I wanted to see how it feels deploying everything by hand. Turns out, it's fine - but not the most interesting thing to do. This sad, little script does most of the work, but then I still need to SSH into the server and restart. If I wanted to make it do everything, I'd probably end up with something similar to what David did here.

Also, starting a new project requires a bunch of manual setup and I wrote down the necessary steps here (for which BTW I have to thank Simon Willison, who's blowing the horn of writing documentation for personal projects). In the past, I atomated stuff like this with Ansible, but didn't get to doing it this time.

Using Rustler with Elixir 1.12/OTP 24

Read this if you want to get rustler running on the new, shiny Elixir 1.12/OTP 24.

The problem is that, as I'm writing this, rustler had a bunch of fixes, which did not yet make it to an official Hex release. So if you try to just add the following to your mix.exs (as hex tells you to), your project will not build on the new version of Elixir/OTP:

# this does not work with Elixir 1.12
        

Building regex.help

Now that regex.help is functional and deployed (check it out if you're writing regular expressions) I want to share how I built it. In the text post will cover deployment and CI/CD setup. In case you want to look at the code, head over to the GitHub repo.

First: what is regex.help? It's a web interface for grex, which basically writes regex for you. Given a couple of example strings you want to match, grex will generate a regular expression matching all of them. That's pretty much it, although quoting the README: "often, the resulting expression is still longer or more complex than it needs to be" so you might want to adjust it by hand. You can do that interactively on regex.help while getting real-time feedback for each of the examples you specified.

The stack

Setting up Plausible, Hitting the Tracker Wall

After [buiding regex.help]({% post_url 2021-05-04-regex-help %}) I was curious about how much traffic it gets. fly provides some basic metrics, but that wasn't enough to really know how many people find the site helpful.

For a while now I've been hearing about both Plausible Analytics and Fathom. They share a bunch of similarities and the ones most important for me are: