Molgenis is an open-source platform for scientific data management and research. The name “Molgenis” is derived from “Molecular Genetics Information Systems.” It provides tools for researchers to design, capture, and share data in the field of molecular genetics and other related areas.
Molgenis is designed to facilitate the handling of large-scale, complex datasets in genomics and other biomedical research domains. It offers features such as data integration, data modeling, and data management. Researchers can use Molgenis to create databases, design forms for data entry, and perform data analysis.
At The Day Job, we’re using it as part of our oncology research infrastructure project to act as a source of truth for certain system information as we build out a distributed access platform to help scientists and doctors conduct their research.
Anyway, at time of writing, there wasn’t a PHP client library for it, so I quickly put one together. Have fun!
Just a quick one; first of all as a sign of life, I know I’ve been quiet of late, and second of all, to put out something that might be of use (albeit to a niche audience).
DOIs, or Digital Object Identifiers, are persistent identifiers for digital object for all sorts of things on the internet. Typically these are published documents, but they may also be things like datasets, workflows, images, etc.
I deal with these a fair amount at The Day Job, and often need to resolve these strings into something that returns metadata (title, author etc). Nice to be able to do this over an API.
Datacite, Crossref etc, who deal in DOIs, do provide their own resolution APIs, but only for items minted in their own namespaces, not the canonical set. DOI.org do provide a proxy, in order to resolve a doi to a location, but no obvious way of extracting metadata.
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.
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.
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.