Monthly Archives: January 2009

My first object oriented code:A set of python classes to create dispense lists for the Formulatrix liquid handler robot

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.

Code-itch 2009 – Progess report

Almost two years ago I first started writing the codeitch weblog about my code ambitions on wordpress ( .This blog was driven by a strong desire to get better at writing code and importantly building solutions that enabled better science. To do that I had decided to pick up python , Java , javascript and also master Excel and Matlab. Since a new year is always a time for reflections , resolutions and such, I figured I will write down this progress report.

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.

Javascript : To me javascript is  mainly a UI language , since I regard the browser as the ultimate UI . Since I have yet to get into the UI writing mode , my javascript useage over the last year was restricted to troubleshooting the few glitches we had at Bioscreencast . Again tool support ( like the amazing firebug utility or even netbeans) ensure that I dont abandon picking up javascript in my spare time and definitely plan to use javascript and a browser as my UI of choice  when the need arises.

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.

The transformative world of NXclient and FreeNX: Remote desktop gets real time

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