Tuesday, April 22, 2008

Betulaceae, Thy Art my Cryptonite.

Today the Pollen count hit the ceiling. Every year this happens, and every year I am just as surprised to find myself floored around the time the weather turns warm.

I've often said that there are two weeks of good weather in Chicago every year - one as hot summer turns to cold winter, and another when cold winter turns to hot summer. 

I was wrong. As it turns out, there is one week of good weather in Chicago each year.

Electron microscope image of various pollen species [wikipedia]

Monday, April 21, 2008

Coding for Google SoC this summer

I just received the following in my mail:

This means that my project proposal was accepted, and that I will get to spend much of the summer working on a browser user interface for gRavi, mentored by Ravi Madduri of the Globus Alliance and Argonne National Labs.

You can find more details about the project in this google doc.

Monday, April 14, 2008

Ruby Syntax for the Javascript Fantasts


A gem that gives you the Mash object which mimics the javascript object notation (with some powerful additions). 


It's a really easy and quick way to build and access deeply nested structured, e.g.

mash = Mash.new
mash.author!.name = "Michael Bleigh"
mash.author.info!.url = "http://www.mbleigh.com/"

Check out the blogpost at intridea, alternatively go straight to the gem

sudo gem install mash

or straight to the source

git clone git://github.com/mbleigh/mash.git

Saturday, April 12, 2008

Jumpstart Webpage Layout with YUI Builder


A way to get your website cross-browser compatible Column layout ready in 30 seconds or less.


Column layouts is traditionally done with tables. WRONG.

YUI grids css gives you a cross browser compatible column layout, and the YUI builder helps you construct the HTML skeleton in a neat wysiwyg fashion.


Go over to http://developer.yahoo.com/yui/grids/builder and build your layout.

Then just hit the Code button and get the plain text - voila. It also resets your fonts to make for a really nice, discreet default look that you can then modify.

Friday, April 11, 2008

Use your Google Account for OpenID


OpenID is a way to sign in once, and only once, for all your web services. Only problem is: you need an OpenID account provider. Not anymore - just use your Google Account (Because we all have those, right?)


Just go to http://openid-provider.appspot.com/. Google takes care of the rest.

Wednesday, April 9, 2008

How to Deliver Dynamic Javascript and HTML with an MVC Framework


Some thoughts on how to organize your javascript file structure and encode your database models to json or HTML for the wire. They were inspired by an email from a guy in Germany in response to my Online Desktop demo presentation on YouTube.


MVC is a great way to organize your web apps - it makes you write good code! However, fitting snippets of html and javascript code for ajax type pulling into the picture is not necessarily obvious.


I think there are a few good ways to do this, and a mix of them all is probably the right way to go. As I see it, there are three ways to deliver your js code to the client, and two ways to dynamically process and display database objects from the server on the client side:
Deliver JS
static js file inclusion (<script src=""> tag)
dynamic js file inclusion (a la dojo.require('...')
ajax request + eval on content (harder to debug and potentially unsafe)
Deliver objects and visualize them
Send json down the wire, sanitize (still a risky business), and eval (if you're using EXTjs, use it's util parseJSON method)
Send html down the wire, and use jquery's $('div').html(htmlVar) or Ext's equivelant

In Ruby on Rails, I do the first two by just including files in my /javascript/file.js directory. That's where I keep all my application code, like layout, event hooks, utility functions etc. Neatly organized into separate files, I can then easily mash them all into a single file at production time to save connections/bandwidth.

I rarely use the third option of sending javascript down the wire and running it. If you have something like GWT producing the code for you, that's fine, but otherwise I feel like it just breaks the MVC structure.

To maintain a continuous and manageble way to send my objects down the wire I tend to have two methods for each object I'm dealing with: to_html and to_json. The client then uses a query parameter to specify which format I wants the response in, and then uses setHtml(response.responseText) or eval('var obj = '+response.responseText); (with some sanitization done first).

That way I can implement the methods on the server side to very easily encode the object for display, send it, and display it however I want. A user account for example, could in ruby do:

class User < ActiveRecord::Base
def to_html
['name','email','phone'].collect do |attribute|

def to_json
{:name => name, :email => email, :phone => phone}.to_json

And on the client all I'd have to do (in jQuery) is

data : {
id : user.id,
format : 'html'
complete : function(response) {

Finally, the controller would just have to pull up the correct object, and send back the object in the right format

# Users controller
def view params
render :text => User.find(params[:id]).send("to_#{params[:format]}".to_sym)

Monday, April 7, 2008

Read This and Become Creative

An interesting study on potent graphics says:

" ... even the briefest exposure to the Apple logo may make you behave more creatively"

Thursday, April 3, 2008

Google Summer of Code 2008 Project Proposal

 Introduction - The Grid.

Grid computing promises the potential to coordinate vastly distributed computational resources into a coherent whole. In doing so it poses qualitatively novel challenges to the field of technology. The socio-political structure among Grid participants is far from obvious; the software communication protocols are complex; and the actual deployment of a ready service onto a grid is exceptionally non-trivial. 

What is the project? Being a service made easy.

Assuming that we have a working grid at our hands, the development, deployment and maintenance of a service is still difficult. At the moment, the participation threshold for anyone but the technology wiz is simply too high. Thus we aim to create a browser-based user interface with the goal to bridge the gap between the highly domain specific complexities of WSDL/WSRF/etc and a seamless user experience. Imagine a South American student on an XO laptop successfully deploying a Grid service - that's our dream.
Conceptual design: After discovering services by search 
and by browsing the service archives, a service flow is 
easily created by connecting services to each other.  

Why is it a good project? Anything is only as useful as it's used.

In short: Grid computing has huge potentials but is still a young technology and extremely difficult to use. In order to leverage its fullest potential the participation threshold has to be lowered, and the user experience made more pleasant. 
Our particular choice of a browser-based GUI has the obvious benefit of easy distribution and minimal client requirements.