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 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!