Ruby Hoedown 2009 Recap

2009-09-05T09:30:20-07:00

I had the pleasure of going to the Ruby Hoedown again this year. As awesome as it was last year, this year was even better! There were some really good talks, good hallway track discussions, and last but not least the venue was over the top ridiculous, like small city under a glass roof ridiculous.

Writing software, not code, with Cucumber - Ben Mabey

I was really excited to see a Cucumber talk that wasn’t just a basic intro to Cucumber. Ben did a good job showing how Cucumber features can add business value to your project. I’m already a Cucumber fan, so I didn’t need to be sold. But even so there was one statistic that really stood out, “56% of all bugs are introduced in requirements”. Over half of our bugs are introduced before we write even a single line of code. That is scary.

For me the best part of the talk was Ben walking through a typical workflow with Cucumber + Rspec. It’s something that I haven’t seen in a talk before and really showed how these two can work really well together. That’s not to say that you can’t use Test::Unit or shoulda or whatever testing framework along with Cucumber.

Ben also introduced a handful of additional tools, some which I hadn’t heard of, which make Cucumber even more sweet to work with. I’ll just link to the tools here, as they probably each deserve a blog post explaining how to use them.

How to be Simply Awesome - Corey Donohoe

First off, I heard a lot of people talking who felt like it was an Engine Yard is awesome talk. They are wrong. While Engine Yard may or may not be awesome, they are merely empowering Corey and Tim to do the awesome work that they do. Any company that would give these two free reign over their projects would see the same results I think.

This talk was Simply Awesome! Corey tells me this talk was recorded the following day when he gave it at LSRC. So watch for it to become available, it is a must see. It was a fast paced Takahashi style talk, so the slides themselves are practically useless. You really have to watch or at least hear this talk to get the message. I’ll just touch on some of the thoughts that I came away from the talk with.

We need to really embrace Agile, no I mean REALLY EMBRACE it.

To be able to quickly respond to changes in requirements, Corey and Tim, like to build small services wrapping specific endpoints, instead of monolithic apps. They did TDD/BDD all the time, so each of those tiny services was ruthlessly tested. When your services are tiny with excellent test coverage, you are no longer afraid to make changes, refactor, or add in new features.

Corey also demanded that we man, or woman, up and really own our code. No more of the whining and complaining about requirements changing. We all know requirements WILL change so why are we so miffed when a client actually requests a change.

Corey also talked about the impact that using tools you like have on the work that you do. Specifically they use Sinatra, DataMapper, Cucumber, and RSpec, among many others I’m sure. This of course doesn’t mean you will enjoy these same tools, but that is the point, find what you like and use it.

MacRuby to the Max

Unfortunately this talk was cancelled. Having recently launched an iPhone app, I was interested to see how much more friendly Mac development would be without having to use Obj-C.

External DSLs with Ruby - Luke Kanies

Luke was a very opinionated speaker, which always makes for a fun and interesting talk. Building external DSLs aren’t part of my daily ruby work, so I just took down the main points and figure I can lookup more info if I need it later. It basically boiled down to four things.

Buy the dragon book.
Define a formal grammar.
Don’t reinvent the wheel on your lexer, parser, or interpreter if you don’t have to.
Use ASTs, which are only really discussed in the dragon book. But that’s ok cause you have the dragon book now right? :)

Be a civic coder - Luigi Montanez

I missed the first part of this talk, and decided to check out the hallway track instead of trying to play catch up with what was being discussed.

Appcelerator Titanium - Leon Gersing

First off, I need some of that magic EdgeCase public speaking juice. Just like every other EdgeCase presenter I’ve seen, Leon was very engaging and comfortable speaker.

On to the good stuff.

Appcelerator currently has two platforms, desktop and mobile. Both of which look pretty cool from a rapid development point of view. Both platforms use HTML, CSS, and Javascript as the backbone. The desktop platform also supports Ruby and Python. The desktop platform is basically a webkit or gecko instance, depending on the platform. While the mobile version actually offers use of native controls and features.

There is a sweet packaging and management gui. Also there are cloud services for building applications on platforms you don’t have access to. There is also a good possibility of an App Store like feature coming to the platform.

The demos were really where you saw the power of Appcelerator. So if you are interested, I suggest you look online for some screencasts or presentations.

Forget Kindergarten, Learn to Scale - Blake Mizerany

This was a high level blitz of horizontal and vertical scaling techniques. Blake went through a variety of tools and showed very briefly how to take advantage of them to speed up your app. It blew away the misconception that some of them were some kind of voodoo magic that I would never understand. He used the Heroku platform in many of the examples to explain how these technologies can be used in the real world. Needless to say I was totally blown away with the Heroku platform and started messing around with it that night.

I did manage to come away with a few tips so here is a short list.

Use HTTP cacheing, Heroku has a very cool cacheing layer, but even if you aren’t on Heroku, use browser cacheing to your advantage.
Use S3, or similar cloud storage, instead of relying on problematic NFS/GFS.
Keep your response times down, under 200ms. Use ajax to hide slowness if possible.
Use delayed job or message queues where appropriate.
Move complexities to small standalone apps and keep the front end dumb and fast.

Time of Your Life - Yossef Mendelssohn

Due to audio problems and being in the back of the room, I ended up in the hallway track again. From what I could gather it was a look at time tracking and specifically a tool Yossef built to help him keep time in Freshbooks.

Threaded Awesome - Joe Damato and Aman Gupta

A suprisingly easy to follow discussion of their experience improving the ruby threading model. They introduced me to a handful of awesome profiling tools that I would have probably been to scared to touch otherwise. Definitely check out the slides for this talk if for no other reason than the examples using the profiling tools.

Testing or Something - David Chelimsky

The title was just a working title, the talk ended up being about mock objects and how and when to use them. There were at least 3 different mock libraries used throughout the talk, so you got a quick glimpse at the syntax of each. Much like Ben’s Cucumber talk, this talk had some excellent BDD step by step walkthroughs that were extremely helpful. Because of these walkthroughs, the talk was actually a really awesome intro to BDD with RSpec. The talk and the questions brought up some very interesting thoughts on testing philosophies, something I hope to look at in more detail on this blog.

Keynote - Jamis Buck

Jamis used the world of string figures, as related to programming, to explain how diversity, expertise, and moderation all play a part in doing the best we can. Diversity opens up new perspectives and thought processes that might never get explored in problem solving situations. Expertise of not only your language, but also your tools, and even your platform was emphasized. Jamis really pushed the moderation part as well. Recommending that we all find at least one hobby that was away from our day to day technology. It will help you to unwind and relax, and can even be a source of diversity in your thought processes.

Tips & Techniques to deepen your knowledge in expert areas, as well as areas you are just learning were discussed. “Code spelunking”, as Jamis called it, is something many of us do already, but if it isn’t then you should definitely start. Basically when you are doing something unfamiliar, don’t just chalk it up to magic and go on about your day. Open the hood and step through what is actually going on. Even if you can only spare a couple of minutes, you will have a better grasp on what is happening, and can dig even deeper the next time.

Also mentioned was sharing knowledge. While you are learning you will obviously be looking to others for answers. You should look for ways to share those answers, and other knowledge you have, for others that might have the same questions. Blogs, forums, and mailing lists were mentioned as great opportunities for this.

Lighting talks, hallway track, dinner, and hacking sessions.

As always, the extracurricular activities at a Ruby conference were awesome. If you are going to conferences and watching the talks, then kinda sitting back by yourself chilling out, YOUR DOING IT WRONG! Go out and ask questions, propose ideas, and don’t be afraid to have opinions. I got to meet loads of new people this year, and got involved in many thought provoking conversations.

Overall

Hoedown Rocked!

@jm ROCKS!

The sponsors that made it all possible ROCK!

See you next year at the Hoedown!

Adopting the GitHub deployment strategy

2009-09-03T19:46:39-07:00

The other day I read a blog post from @defunkt about cleaning up the deployment strategy at GitHub. He explained, including some example code, how they had created a git based deployment strategy for Capistrano. He also mentioned that this new strategy was MUCH MUCH faster than the typical git deployment.

I happened to be prepping an app for deployment and decided I would try out this new strategy. I ran into a few issues where the examples given weren’t namespaced properly to work right out of the box for me. I also decided to make a few changes for my needs. In the end I have a new favorite deployment strategy that can deploy this specific app in around 3 seconds which is AMAZING! Read the original post for an in depth explanation of how it all works, or just grab this deploy.rb and have at it.

almost productive