Skip to content

Busy’s complexity wall and changing deployment assumptions

Hit the complexity wall on implementation 9 of Busy. So I did some research. Two main contenders for cognitively light programming languages. Lua had the best score. Light on both the project and the modular level. I know Lua, and wouldn't mind working with it... I thought, naively.

The real problem with Lua is that it's an obsolete abandoned project. There are no current strains of it, and it's designed for embedding, not direct use in an app. This is problematic for what I want to do.

Dart has the next lowest cognitive complexity score. Smaller than go, marginally lighter on a per module basis, significantly simpler on a per file basis, about par with Lua. So that's what I went with.

The other big difference in this build is the tact. Okay, going back to first principles... do we really need a real time chatbot? Probably not. What we do need is something that orients itself around code.

So I spent the weekend writing this absolutely beautiful system. It's two tiered. Written in Dart for the client app, and PHP that runs on a webhost. But... I had to tunnel for the callback, and initiate an ftp transaction for the tunnelling, so the PHP app knew who to call.

Do anything on GitHub in a subscribed repository, and the system catches it! And that's how implementation 10 is going to work. At least on the low level. For stuff like this, it's important to think about the plumbing first, before you think about the agent functionality with AI.

The plumbing is gorgeous... but the tunnelling wasn't designed for this. It times out quickly, and doesn't handle reconnections well. Half of what the system was doing was connecting initiating a transaction, timing out, and repeating the process until it reached the max exponential backoff, and shut itself down.

So I looked into the paid tunnelling solutions so I could handle it all locally and evaluated my options carefully. And what I figured out is that I could just buy a vps server at the web host I'm already working with, that would solve the tunnelling problem by assigning the app a dedicated IP number. And, for the price $5 a month, I get all the server candy a gal could want. Publishing by means of secure git repository, sudo access if I need it, and....

Well, now the key assumptions that were made when I designed it make no logical sense anymore, and I need to redesign the whole thing. Well, not all of it. That's the joy of using modular architecture. So today, I'm working on rejiggering it, and moving components around.

I'm going to consolidate the webhook functionality into the Dart app, along with all my secure endpoints and database functionality, and hopefully get rid of all that cognitively dense (but functional) PHP code. Keeping the database in the same place, and whitelisting the vps, so we keep our concerns separated. And, when done, all I have to do is make a couple of quick changes in the GitHub app configuration, and we're golden.

Next step is adding the AI itself!