What a difference a year makes… and I ain’t dead (yet). Long time, no post. Suffice it to say it has been a very busy year, with a lot going on, both professionally and personally, both good and bad. But, I won’t go into that here.

AI is the new hotness, as has been remarked. A lot of my day job now involves AI in some form or another, and indeed, the field of Structural Biology leads the way on a lot of the technological adoption. Notably, things like AlphaFold for AI based structural predictions, but also, some of the stuff I’m more directly involved with which aims to build a model for improved fragment based drug discovery. More on that stuff in due course.

Compared to that, this little thing I put together while bored during a meeting today may not be earth shattering, but as a proof of concept I think it does start to address a problem we on the ARIA team have faced for a little while.

Namely, our catalogue is very well placed to allow people who know what they’re after to get what they want, but not if they want to, for example, find something out but have no idea how to go about it.

Previously, we had used human experts, and even played with a live chat feature. None of this really scaled very well, but now we’ve got fancy pants AI, I figured I’d give it a try!

My thinking on this is fairly simple, the first step is to make sure all the services in ARIA have good descriptions, including down to what each machine can and can’t do. The better the description, the better the results from the model.

The second is to feed this context into the prompt, and instruct the AI (via the new fangled technique of prompt engineering) to act as an expert and set the parameters according. For example, to instruct to only recommend information in the context, and to provide, as a result, a list of suitable application URLs (which in reality will allow the user to directly apply for the service).

I also instructed the AI to consider how it could connect services together into a pipeline, as well as to consider alternative recommendations.

Proof of concept right now, but already I’m getting possibly interesting results. I’ve got more tedious meetings coming up, as well as a fair amount of sitting in airports, so my plan is to wire this up with a chat interface and let real scientists play. No doubt we’ll have to tweak the prompt a number of times as we go, but as a first play with the technology I think this was a morning well spent!

» Visit the project on Gitlab...

Part of my day job is writing and maintaining a fairly massive and complex piece of software which has become mission critical for various large scientific infrastructures around Europe.

For reasons that will be familiar to anyone who’s built platforms that suddenly become successful, certain things were left out when building the software. One of these was any kind of monitoring.

We are of course building this out “properly”, however one of the simple things I did early on turned out to be a really big win. This was to simply catch all fatal errors and exceptions being thrown, and then pipe them to a slack channel set up for the purpose. With the help of clerk, this can be made easier.

Before adding the slack monitoring we’d often be surprised by error – receiving garbled reports third hand as they were escalated from a user email, through the administration team, and to us. By which time the detail has been lost, and any logs long since rotated away.

Our devs live in slack, and as a multinational team who’s members frequently travel, this has become the nervous system of the organisation. Now, my team is no longer surprised, and can jump on issues instantly.

Very very simple to set up, but turned out to be a big win. Here’s how

First, capture fatal errors in your application

I wrote about this before, about capturing WSOD errors, but assuming you’re using PHP, this is all about registering an exception and error handler for your application.

Create a slack app

Select “Incoming Webhooks” from application menu

Next, create a slack application and add it to a monitoring channel in your work workspace.

Add an “Incoming webhook” for your app, that posts to your monitoring channel. This will give you a URL, anything POSTed to which will end up in your channel.

Posted text supports Markdown for formatting, which is handy if you want to post raw error messages etc, or links to data dumps.

Link the two

Finally, from your error handler, POST the error / stack trace / etc to your slack channel.

Conclusion

Obviously, this should be no replacement for proper monitoring. Proper monitoring can provide historic information and statistics about the overall health of your platform.

However, in the absence of this… this may be a quick win that you can implement without too much effort. Certainly for us, this proved to be invaluable, and allowed us to quickly diagnose and fix faults we were previously unaware of.