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.
Posted by: Ryan Garver | May 29, 2009
Google Wave looks ground breaking
Posted in Uncategorized | Tags: google, tools
Posted by: Ryan Garver | May 17, 2009
Podcast.local – localhost podcasting
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!
Posted in agility, programming | Tags: agile process, jquery, jqueryui, programming, ruby on rails, tools
Posted by: Ryan Garver | March 6, 2009
It’s not the size of the tool
I’ve been having discussions recently with some coworkers about finding better tools for various aspects of our business. A lot of our discussions are looking at how to organize our development process, but every once in a while it diverges to a different set of issues, especially how we track our developer/designer/account managers’ hours.
If you’ve known me for a while, you’ll know that I get a kick out of trying out new apps and services. I like to find ways to make myself more efficient and better at my job and life in general. Usually I end up throwing these tools away after a few weeks. But every once in a while I find something that lasts. A great example of this is OmniFocus. I had been trying to implement a good approximation of GTD for several years, and in that time I’ve tried probably 15 different tools and online services that implement various approximations of GTD. But it wasn’t until I started using OmniFocus that I really found a sustainable process and a tool that empowered me.
Coming from the agile community the common reaction to “What tools should I use to organize my development process?” is whiteboards, poster paper, and ample note cards. While I do appreciate this tactic from first hand experience, this has some obvious flaws as soon as your team members are not co-located.
Our current suite of tools have a number of failings for a number of different reasons. The reaction that I’ve been hearing lately from my colleagues is that we need to find a single tool that handles all of our major needs. The theory—I presume—is that having fewer tools will mean less manual work maintaining the tools and their content.
I’m not a big fan of this philosophy for a few reasons:
- It is not likely we will find a single tool that fits all of our business requirements without it being too complex or expensive (or both), therefore our processes and practices will need to be adjusted for the tool. The realist in me is OK with the idea of adapting to the tool to an extent, sometimes the tool can give you a better process that you didn’t know before (eg: OmniFocus), but that’s pretty rare.
- There are a few tools that are actually working very well for us, however the “one tool to rule them all” model creates artificial value in eliminating that independent tool for a consolidated one that may be less effective.
- It impairs a teams ability to experiment with new work patterns and tools by adding cultural pressure and often bureaucratic overhead around tool choice. If agile software development is about expecting change and continuously adapting to it, then I want to have the flexibility to adapt everything down to the tools the I use.
- I’m not convinced that maintenance overhead is entirely due to the number of tools. I think it has more to do with not using the right tools.
Modern application development approaches have really focused on the idea of specialized tools that solve a small set of problems. The old model of monster apps that can be customized to do what you want, but not quite perfectly, is being phased out for interoperability and APIs. Our Github account can send post-commit notifications to our Campfire account, our Acunote account integrates with our bug tracking system, and just about everything will send an email to keep you up to date.
The moral of the story: Why use one tool that does everything just OK when you can have many tools that to their own things really well and will talk to each other?
Posted in agility | Tags: agile process, gtd, tools
Posted by: Ryan Garver | February 10, 2009
Back to jQuery
So I tried Red for a while (short while) and was all excited and thought it was really cool and I’d be using it forever. Then I tried to make a Ajax call to a rails app and got back JSON, crap. Red doesn’t support parsing JSON. I eventually figured it out and made a pretty cool billing summary widget using Red. But that took me a few days. And it was really hard. Much harder than it needed to be.
I like what Red was trying to do, but looking back I think I knew it was too good to be true. It’s not quite there and requires a lot of hacking to do most practical things. I’m now using jQuery. I reimplemented the billing summary using jQuery in a couple of hours, and most of that time was spent re-learning jQuery. I’m actually pretty happy with it after using it for a few weeks. I thought I would always return to Prototype.
In my excitement for learning a new tool I discovered the extension jQuery UI and their Themeroller. This has got to be one of the cooler javascript library extensions that I’ve seen. ExtJS tries to provide a will UI toolkit and has a theme API, but the Themeroller for jQuery UI is really sweet and super simple. As a basis for a back office admin it is ideal, and I can see a number of opportunities in a broader set of situations. The icon library alone has made producing simple, intuitive interfaces really easy.
Posted in programming | Tags: javascript, jquery, jqueryui, programming, themeroller
Posted by: Ryan Garver | January 3, 2009
JSON for Red
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:
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[0]) do
meth[1]
end
end
return ret
end
end
Now doing a simple AJAX call that returns JSON becomes really easy:
@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})
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.
Posted in programming | Tags: javascript, programming, ruby
