Over my few years writing scripts in Python or Perl , I always told myself that the next time I had to solve a problem I would make my code more object oriented and re-useable. Like an addict trying to break a habit , I always failed miserably. It was just too easy to just write one giant script to get the job done. So much so that when I started writing this blog almost two years ago , I once again stated my desire to break this habit. Also along these lines, I always felt I should be using some form of version control. Even for a script it made sense to be able to experiment with code and go back and forth on a source tree. But again I just did not have the time to do any of that!
I am quite happy to say that I have finally managed to write an object oriented set of python classes that create dispense lists for a liquid handling robot . Also I went ahead and used git for version control all along the way.
The problem I was solving was fairly routine . I had to create an easy software routine to create dispense lists for the Formulatrix liquid handling robot in the lab. Each dispense list was a list of volumes of the robot had to dispense to each well of a 96 well plate.
Crystal screens typically keep some components constant across a 96 well plate while varying some others systematically. Therefore the dispense list creator code had to deal with creating gradients of components along the two axes of the plate and also handle component staying constant . Regardless the final output is a tab delimited set of volumes that the robot then uses to carry out the dispense. Imagine a 96 character array with volume for each well and one array for each component.
Like all object oriented approaches tell you , it helps to model the problem space appropriately. This involve defining all the actors in the problem you are trying to solve and writing appropriate classes. For me that was the hardest part. Object oriented analysis and design is Hard! But I persisted in the good faith that the object orientation would pay off , and once I modeled my classes appropriately the code would just write itself .
As my code grew . Adding new features became easier than it ever had been when I was writing imperative linear scripts. Also thanks to some timely and excellent help from Michael Foord and Chris Lasher delivered over twitter and a blogpost , I could use the object oriented nature of the code to quite some advantage . Incidentally Michael Foord writes an excellent pythonic blog at voidspace,is one of the main developers at Resolver Systems and the co-author of IronPython in action and Chris Lasher is on the Bio-python team and an avid Bioinformatician who I got introduced to thanks to Atom.
The code that creates these dispense lists and the examples are posted on github . Take a look and let me know how I did with the design aspect of my classes . The most exciting moments of writing object oriented code is when you realize that adding functionality comes so much easier than procedural code . I am thinking in terms of writing a GUI to wrap the functionality of the code in additon to a web app/form based CGI frontend. Any help and suggestions are welcome.
The icing on the cake was when the code actually worked and I now have a few custom screens with multiple gradients hopefully growing giant membrane protein crystals.
Now onto writing some GUI code.
Python: Python has clearly becoming my first choice for tackling any problem. Whether it involved analysing the many trajectories generated by the channel finding program HOLE , or writing an http based API for Bioscreencast , or an HTTP based web service for Bioscreencastwiki, python has ensured that I can get it done . There is no problem that I dont attempt to solve using python . Python has even ensured that I jettison a desire to pick up Excel and instead adopt Resolver one , the pythonic spreadsheet instead . My only problem with python is the learning curve to pick up a new API . The dynamic typing sure makes it hard to unravel code by just reading source , something that I was used to doing having leant to code in Java. Further , tools like netbeans and Eclipse with code completion also make it easier to familiarize yourself with a new API in Java . In python , I still go about it using the dir builtin function and reading the various forms of python documentation available on the web. In some ways I really cannot wait for something like nbpython to become fully useable.
Java : Since I am still developing code to solve problems for myself or web-centic problems for an apache based webserver . I have almost not written a single line of java code the last year. Python has ensured that java takes a backseat.
Excel : Having got on to the python horse, I can hardly justify the headaches that mastering Excel syntaz gave me . And for most simple spreadhsheets I have gotten used to Google spreadsheets.
Matlab: My desire to master matlab was to understand the many algorihtms I encounter in X-ray crystallography. In may ways Python and MatPlotlib have ensured that I can get a lot of that done using python , without the need to learn the Matlab way of things . I have also attended a few Mathematica Seminars and am extremely impressed with the Mathemtica 6 ( and 7) platform . For understanding algotihms and the behavior of functions etc I have been turning to Mathematica and python more than Matlab.
So in summary , python and the pythonic way are what I have embraced in 2008 and really want to start writing python code that starts to build on this foundation in 2009.I am also really starting to use Mathematica and pick up processing as a java centric visualization platform and hope to write about these in this new year.
As a crystallographer we routinely travel to the national synchrotron light sources at Chicago , NSLS on Long ISland NY, the BCSB at Lawrence Berkeley etc to collect X-ray diffraction data from our protein crystals at the various beamlines.
A beamline is basically a station or a lab room at a synchrotron facility where out of a tube emerges a very intense strem of x-ray photons , typically at a tuned wavelength. While synchrotons are very complex machines , the beamlines themselves are also are very sophistcated experimental stations and typically have several computer controlled components like the detector , monochromator , crystal bearing goniometer , cryo-coolers , video cameras and many more . All of these synchronize to allow you to collect your data and are operated using a single computer loaded with the beamline control software.
Each data collection run goes on for many hours and you end up working almost continuously for a 48hr stretch since you typically get only one or two such 48 hr allocations per 3-4 month cycle. So a beamline trip is a fairly involved activity , especially if you are not fortunate to have a synchrotron in your own backyard.
But a lot of that is changing thanks to things such as NXclient from Nomachine
and its counterpart FreeNx from Gnu.
NXclient and Nxservers are basically network solutions that allow you to operate and interact with a remote computer as though you were actually there . NxClient is thus basically a remote desktop application like apple screen-sharing or real-vnc ( chicken on the VNC) but in my opinion offers a level of interactivity with the remote machine at a speed that surpasses these other offerings. In NXclient the control information is sent over ssh (secure shell) and the compression allows almost real time interactivity with the remote computer especially where the windowing/graphical system is X-based. So for Linux/Unix /Solaris and even for Xbased MacOSX applications NXclient/Nxserver technology allows you to control the remote system with very much near real-time interactivity.
The reason I call this transformative is that a lot of synchrotron beamlines employ applications running off linux servers and soon we will not have to travel to these facilities but can operate the experiments remotely using nothing other than a robot to mount our crystals and the beamline computers to control our experiment whilst sitting at a the comfort of a remote computer connected via NXclient.
I decided to try out NXserver on my home machine and controlling an application on it from my lab. Installation my own home ubuntu box was a breeze, and withn minutes I could connect remotely from my lab macbook pro running a copy of the nxclient . Although my connection up at home is the “slow” standard comcast cable internet and my lab computer is on a LAN connection I could interact with a pymol session almost as if I were sitting at home.
I really cannot wait to start controlling the robots at the synchrotron while I sit at home sipping tea and eating crumpets.
You can catch the original high resolution nxclient screencast at bioscreencast.com