Okay, I would talk about how Gosling was treated by Oracle, but you can read about that yourself. My reasons for dumping paradigmLIMS as a Java based LIMS platform have everything to do with my own (growing) feelings that Java, in the hands of the mighty Oracle, is bad.
To be fair, I have tried to like Java though. I really have. I spent hours learning the language and literally hundreds of dollars on books but what I learned after much of the ardorous experience is that writing LIMS functionality in some kind of scripting language is, for a busy professional, more enjoyable. Java is verbose -- the syntax is like C/C++ -- which generally means you have to write code and create objects for even mundane things. You have to constantly think in terms of visibility and scope. After a while, when you find yourself automatically looking to create yet another class to perform some job, you regurgitate. I avoided the gag reflex by avoiding working on the paradigmLIMS system.
Armed with the belief that it was high time to start looking at scripting instead of big/monolithic languages like Java I actually got pretty excited about the Open-LIMS project which is natively written in PHP. However, as you can see from recent posts, the project is in some kind of frozen alpha limbo where the authors have even refused to publish patches for their work. Reading the code and running the example system they did publish revealed numerous issues that make it very far off from a usable platform. It was hard, but I gave up on this as well.
Quite by accident then I started working with a tool called TWiki -- a wiki engine. Wikis are kind of like weblogs except any registered user can edit the pages. The changes are stored as versions. This particular wiki is is extremely powerful in that it allows for structured data to be stored inside of wiki pages, called topics. With this you can search on the data or easily extract it and place it in a relational database management system. This makes it ideal for use as a base platform for a LIMS. It uses the Perl scripting language as its base language and for Plugin development but many things can be added to the system without coding.
Honestly, TWiki should rightfully be called a development platform because it is so versatile. Built in user and group protection, a web-based interface, embedded management and installation tools; easy extensibility are among its native features. But could it be used to create LIMS functionality? I was only too eager to try it out.
Before I get into this, let me explain precisely just what LIMS functionality is supposed to be. As far as I am concerned the most complete and basic definition of a LIMS is specified in the ASTM E 1578 (particularly the E 1578-06) standard aptly titled Standard Guide for Laboratory Information Management Systems (LIMS). In Adobe PDF format this standard is 39 pages worth of specifications, definitions, and even a checklist at the end to use when evaluating a LIMS. It is a fairly good guide to use when deciding whether a LIMS has enough functionality to be usable now and in the immediate future. It is also very handy when trying to rebuild a LIMS from scratch.
So, a couple of weeks ago I elected to try and utilize TWiki to build the LIMS basic functionality -- you know, sample, test, result registration, searching for specific data, calculations, etc. It held up surprisingly well with only the available tools provided with the installation. At first I admit to being a bit bewildered by the ease with which I was able to do this. It took zero coding -- just a bunch of configuration and cut/copy/paste of a few forms.
In the coming days I will start to publish the parts of my core solution, the things in TWiki that make it work, and a tentative roadmap to making a real-world LIMS solution based on TWiki.Go Back
Citation: New Directions. (2011). Retrieved Mon May 1 02:11:28 2017, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1309310073