#sidebar {
width:220px!important;
}

I just finished watching the Google IO demo of the new system Google Wave.  This is really an amazing piece of software.  Check it out.

[youtube=http://www.youtube.com/watch?v=v_UyVmITiYQ]

Last week I discovered a set of mp3’s covering Lean practices and principles.  You can access them here.  I’ve been on a bit of a management optimization stint lately and Lean is a very natural extension of Agile software development in to a broader management context.  It largely predates modern software techniques and represents one of the early generalizations of the Toyota Production System.

In any case that is not what I’m here to talk to you about.  In looking through these mp3’s the list of webinars was not collected in to any sort of podcast format.  This is frustrating because this would be ideal commute time listening on my iPhone.  Out of this frustration came podcast.local.  Podcast.local is a simple Rails application (really simple) that allows you quickly create a podcast through a series of forms.  The name comes from the naming convention provided by the Passenger preference pane on OS X.  If you set it up through the pref pane you will just need to go to http://podcast.local.  From there you can create your podcast one episode at a time and then subscribe to them through your iTunes.  The coole thing is that because it’s on the web iTunes just picks it and starts downloading episodes.

Like I said above, this application is too simple to go in to much detail.  I used it to do some experimentation with a few technologies that I haven’t had much time to mess around with.  Namely Blueprint CSS, jQuery, jQuery UI, and Paperclip.  Enjoy!

http://selfmodifying.files.wordpress.com/2009/04/cropped-2957370148_c63922a84b_b_23.jpg

I’m a software professional living in Los Angeles, CA.  My passion is building great software and finding ever better ways of doing it.  I am CTO at an innovative crowdfunding company called ProFounder.  My specialty is agile software development, cloud computing, and Ruby on Rails.  I’m always looking for top quality developers to work with.  Let me know if you are interested.

I’ve been playing around more with Red.  I alternate between really liking it and totally pulling my hair out.  On a order form app that I’m building I made some very quick work of a dynamically updating billing summary div.  It came together very quickly until I added the AJAX piece.  AJAX support in Red is actually very good, but JSON support is non-existent.  This made Ryan a sad boy.  I dug around to see what other people have done and found that they haven’t done much.  There is some stub code for a Request::JSON that my be what I’m looking for at some point, but I need it now.  So here is what I did:

[sourcecode language=‘ruby’]
class Module
def define_method(sym, &block)
`this.prototype[‘m$’+sym.value=block.block.unbound`
`Red.updateChildren(this)`
`Red.updateIncluders(this)`
return `block`
end
end

class Object
def self.from_json(text)
ret = Object.new
meths = []
`var v = eval(“(”#{text}.value“)”)`
`for(var member in v){#{meths}.push(new Array($q(member), $q(v[member])))}`
meths.each do |meth|
ret.class.send(:define_method, meth⁰) do
meth¹
end
end
return ret
end
end
[/sourcecode]

Now doing a simple AJAX call that returns JSON becomes really easy:

[sourcecode language=‘ruby’]
@req = Request.new(:url => ‘/orders’)
@req.upon(:response) do |response|
new_data = Object.from_json(response.text)
@summary = new_data.summary
@subtotal = new_data.subtotal
@total = new_data.total
end
@req.execute(:data => {’plan_id’ => @plan, ‘promo’ => @promo})
[/sourcecode]

A few things to note here.  The section that defines `define_method` on `Module` is actually back ported from the current master branch of Red.  This works pretty well, though I haven’t tried it with a JSON string that describes a living object.  But I don’t think it’s too far from being able to handle that.

No.

If you are in a position to ask this question I humbly recommend you default to: “No, I do not need this as an instance variable right now.” There is a tendency to plan for every potentiality when doing software development and this is a prime example of such a situation. Resist the temptation.

Instance variables represent state associated with an object in memory. When you declare an instance variable you are saying to all future developers: “This piece of state needs to last for the life time of this object because it will be used elsewhere.” Think very hard about that. We are saying loudly here that this variable is coupled to other fragments of code. Which code? Dunno, do a global search ;).

This is called tight coupling. I will go so far to say that coupling is the source of all evil and complexity that we deal with as programmers. With every step that we, as programmers, take in building a system should be with an eye to reduce or at least not increase the coupling in the system that we are working on. The fewer instance variables that we have in a Rails controller the smaller the potential coupling between the view and other method calls that have access to those instance variables. Each method, each action in a controller, should be as self contained as possible. The less leakage of state out of a function the better. Generally your view doesn’t need to see that temp variable of the calculations that you made to set a model attribute keep it local, drop the “@”. Worst case scenario you go back and refactor your code to include that “@”.