I’ve put together a functional initial version of a Slack integration library for Hamilton Venus that leverages the Slack API and a (hopefully elegant) set of functions to post messages and upload files to a Slack deployment.
My thinking here is that
Slack is a nearly ubiquitous user interface for communication and messaging.
Slack is where users are already looking for and expecting timely and relevant updates in their daily work.
Slack provides user interaction mechanisms that blow a notification channel like text or email out of the water.
Flexible channel architecture adaptable to single instrument or massive automation deployments.
Essentially if you can follow this guide to deploy a Slack app with fairly minimal scopes that allow for posting and enumerating users and channels you’ll be all set to begin sending messages to your Slack deployment.
I’m at the point to need feedback if anyone wants and opportunity to give it a shot and provide feedback with the caveat that it’s in late-ish stage development and needs some documentation and TLC to finalize for production.
For anyone thinking “who the heck is this random?” I wrote or supported a few tools that you may be familiar with while developing custom automation projects working at Hamilton a handful of years ago for sending HTTP requests, parsing XML, generating random numbers, working with time… etc. I’m aiming to get this to a production quality implementation thinking that saving the 5 minutes it takes for a user to notice an error email or replenish tips, or search for a trace file multiplied by the hundreds of companies that use Hamilton liquid handlers and Slack is a piece of software that provides value and needs to work.
Feel free to respond here or shoot me an email to the address in my profile if you’re interested in testing this out.
Woah! That sounds amazing! My lab would definitely be down for testing it, especially for notification when a method is finished or an error occurred, etc.
I wanted to sort of gauge interest here before releasing something into the wild. There’s certainly enough to justify polishing things up a bit to feel good about getting into more hands, writing an implementation guide, and fleshing out some real-world use case demonstration methods that hopefully go a ways towards allowing us to focus on robustness and features instead of troubleshooting deployment
I’m going to get to work and will update here in the coming days.
Is this ready?
I worked on something similar, using Elasticsearch, and thinking maybe to release it. It allows for archiving all log into the cloud / locally deployed server.
