Not so much about science...

So in looking back over that last few entries, it seems I have strayed from my original mission, which was to cover issues regarding informatics and how it relates to science. The first part seems to have dominated the posts recently, so I am dropping all pretenses starting a new blog, over at Blogger competitor Wordpress.

Why a new platform? I figured I would give Wordpress a spin to see how it compares to blogger. Also I like the template they had for the blog ;) So far, the interface is similar, but looks a bit cleaner than Blogger's. Overall, it seems the same functionality and workflow, with the addition of one thing that I can see coming in very useful for a site like I envision, permanent pages.

In effect, If I write something that I want to be prominently displayed at all times, I create a page. This can come in handy say, if I give a set of instructions for setting up your development environment, or for providing a listing of resources. As a regular blog post these types of items are "discoverable" by searching, but they will eventually go away as new posts drown them out.

Another agument for the Page as opposed to a post is to combat a post from becoming stale. How many times have you thought you found an answer to a question in a blog post but it turns out said post is a bit old and the solution no longer applies? I guess stackoverflow seeks to remedy this, but bloggers can do their part by posting "important" and generally applicable posts with prominence as a page, thus they are always reminded to update it, since is it always visible.

Anywho, there I go again, talking strictly about web applications. Well, I guess I'll shut up now and you can check AppMecha for more posts related to these issues.

Google App Engine: constraints are good

There has been a lot of rejoicing and jeering over Google's web application deployment offering, Google App Engine. Most of the gripes (that I have seen) have been about the constraints of only supporting a single language, limited database capabilities, no file or OS access of any kind. Frankly I think there is an element of FUD to all of these.

First for language choice, AppEngine has been receiving a lot of flack over the choice of a hobbled Python over and above all other languages. Also there have been a couple of gripes overheard at the lack of real foreign key constraints in the relational layer.

Boo frickin hooo. Stop whining and get coding and you'll come to the same conclusion all artists, composers, coders, and generally anybody that ever created anything did. Namely that constraints are sometimes the inspiration for the creation. Sometimes it is the constraints that shape the work more than anything else. Lack there of may sometimes lead to interesting experimentation, but I put forth that actively not following a system of conduct is itself a constraint. Trying to be original is hard work, and all the harder by not framing your work within something familiar.

But I also should stop bitching and get to work. My idea has the potential to reshape the way collaboration science is conducted, but I need to deliver the tool to the audience. Seems like G-Apps would be a perfect test bed.

Sequel's lackluster to_*

Sequel is a great bare-bones ORM, but the bare-bones quality of Sequel::Model leave something to be desired. For instance the obj.to_json method just calls the default ruby object inspect method, which prints out the class name and memory space. Not helpful. Also no to_xml() for easy REST incorporation. Almost makes me want to go back to ActiveRecord, but then what's the point in using Merb?

Anywho, it's not that hard to extend the functionality of Sequel::Model, so I have started writing some gems to make development with Merb + Sequel a little easier. Like real to_xml & to_json methods on the model instances and instance collections. More on this as it develops.

Merb TLS mail plugin gem

UPDATE: Now available on github : merb_tlsmail github page

My previous post on sending mail via a TLS SMTP server on merb covered monkey patching Merb::Mailer.

I took the time to code this up as a gem, using Merb's meta-programming routines to extend Merb:Mailer in a standard way (for merb that is). See this open ticket in the Merb lighthouse issue tracker to download the gem until it is released as a proper plugin.

Secure SMTP server (TLS) from merb apps

It seems that Merb's Mailer class is either using a local sendmail client or a non-TLS enabled SMTP server. This is not a unique problem to merb, but rather a deficiency in Ruby 1.8.

I took some time to look around and found that Rails has the same problem, and it was fixed via a plugin, not a gem as is the "merb way". There was also a gem that packaged the Net::SMTP classes from Ruby 1.9, which do have TLS support. It isn't hard to guess what I did next.

I monkey punched Merb::Mailer to overwrite the net_smtp method and added two config options into merb_init.rb. See the pastie for the code example here.

http://pastie.caboo.se/151190

Python 25 & MySQL on Leopard

There was a bit of trouble when I tried to use macports to install the excellent Trac project management and issue tracking application. Specifically, the py25-mysql port did not compile correctly.

Trolling through the InterWeb, I found this post about a fix to compile the python module from scratch. The post, however, has more instructions than are necessary, so here is my revised procedure:

1. Download the source from here.
2. Unpack the archive and edit the _mysql.c file to comment out lines 37-39:
   
// #ifndef uint
// #define uint unsigned int
// #endif

   
3. Edit the site.cfg file to set the mysql_config path. For me this was:
   
mysql_config = /usr/local/mysql/bin/mysql_config



4. Compile as normal
   
python setup.cfg config
python setup.cfg build
sudo python setup.cfg install


Now if only someone would make these changes in the port file, then trac installs would be super easy, instead of just easy-ish.