Ruby Hoedown V - Friday Afternoon

After lunch on Friday, there were four remaining sessions to go before day’s end. All were good, but I’m only going to recount the two that left the biggest impression on me. Alan Johnson talked about his project Handlebars.js, an open source project for templating data in views with Javascript. It is a spiritual ancestor to mustache but simplifies some of the more convoluted mustache conventions and introduces a slick set of “helpers” that make templating ridiculously easy. The premise of both Handlebars.js and mustache is that view data should be just that – only data – and that the view should be responsible for organizing that data into meaningful patterns. In traditional web architecture, this has always fallen to the server (at least on initial page load). This is fine until you start introducing Ajax calls that are going to load up additional data from the server and use it to populate your views client-side. At that point, you are probably creating partials on both the server and the client, effectively duplicating code. Javascript UI frameworks like Handlebars.js and mustache move this all to the client, which means that views and view logic exist in one place. Alan did a great job demonstrating this and giving the justifications for why this might be a legitimate approach in certain web application categories. His explanation of why he chose to create a new project instead of simply extending mustache was also interesting (ultimately too much mustache code would need to change at too low a level). The last session of the day was about debugging techniques in Ruby. Jim Weirich talked about the Ruby gem Pry, which is like the Immediate window in Visual Studio jacked up on steroids. He dropped some “pry” statements in his code and ran it through IRB, and whenever a pry statement was executed the interpreter would stop and generate a bunch of data about the current code being executed. He queried object data much like you would in a traditional debugger, but then he demonstrated how, using traditional file system commands like “ls” and “cd”, one could traverse scopes of execution and examine data anywhere in the application. Which was pretty damn amazing. Being an Emacs fan, he also demonstrated how the Ruby debugger could be wired up to Emacs to give a much more “visual” debugging experience. One thing I didn’t realize is that, in the Ruby community (and perhaps in other open source communities as well), there is a general antipathy toward debugging (tests should find all your bugs, right?), and when debugging _is_ necessary, many ruby developers prefer to simply litter code with “puts” statements to see state changes in the application. This method is simple, quick, and effective, but is also quite limited when non-trivial debugging is required. On Friday night, everyone went over to The Red Door bar on Music Row for a fine party hosted by the Github reps who were participating in the conference. A good time was had by all!