Use your Google Account for OpenID

What?

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?)

How?

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

How to Deliver Dynamic Javascript and HTML with an MVC Framework

What?

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.

Why?

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.

How?

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|
      "
#{self.send(attribute)}
"
    end
  end
  
  def to_json
    {:name => name, :email => email, :phone => phone}.to_json
  end
end

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

$('#button').click(function(user){
 $.ajax('/users/view'+user.id,{
  data : {
   id : user.id,
   format : 'html'
  },
  complete : function(response) {
   $('#output').html(response.responseText);
  }
 });
});

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)
end

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"

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.

Playing with Signals in Ruby

What?

Signal trapping and processing in Ruby - it's way easy.

Why?

Signals are very useful, e.g. to detect shutdown and let your program clean up after itself.

How?

Here's a quickie that'll get you started playing.

# Let's see which signals we can trap
{
  "ABRT"=>6, "ALRM"=>14, "BUS"=>7, 
  "CHLD"=>17, "CLD"=>17, "CONT"=>18, 
  "FPE"=>8, "HUP"=>1, "ILL"=>4, 
  "INT"=>2, "IO"=>29, "IOT"=>6, 
  "KILL"=>9, "PIPE"=>13, "PROF"=>27, 
  "QUIT"=>3, "SEGV"=>11, "STOP"=>19, 
  "SYS"=>31, "TERM"=>15, "TRAP"=>5, 
  "TSTP"=>20, "TTIN"=>21, "TTOU"=>22, 
  "URG"=>23, "USR1"=>10, "USR2"=>12, 
  "WINCH"=>28, "XCPU"=>24, "XFSZ"=>25
}.each do |signal,num|
  puts "Set up trap for #{signal} #{num}"
  trap signal do
    puts "#{signal} #{num} was trapped"
  end 
end

# Sleep away and lets press some buttons. Try for example ctr-c
sleep 100

Also check out:

at_exit do
  puts "I'm quitting now!"
end

Very useful!