what do I know

Overall, I have to say I really enjoyed my first Ruby conference. The selection of speakers was great, the topics were interesting, and the vibe of the community was cool. The keynote presentations were a little far out for me at first, but after some thought I can definitely appreciate them for the messages they attempted to deliver. In fact, I must admit I have always had a stereotype of the Ruby community as being immature when it comes to development and overly focussed on a single web framework. acts_as_conference did a great job of helping me to douse those misconceptions. Also, I ended up winning a book at the conference on Google Maps, Rails, and AJAX, so that was cool; not sure if I’ll use it, but a nice perk none the less.

If I wasn’t always so busy planning for the Adogo, I would definitely try to get more involved in the Ruby community in Orlando, which is definitely thriving. I don’t know if Ruby is where I’ll end up for any large amount of time, but I’m definitely encouraged to work with it and am having fun in the process. Of course, I’m energized from the conference, so I’m sure my eagerness to fail will kick in over the next few days.

Great work organizers and I look forward to next year’s event.

The conference ended with a keynote presentation from Obie Fernandez. The topic of his presentation was “Mastering the Art of Application Development”. Obie presented the perspective that software development is more of an art than anything else. He went into detail about how mastery requires practice and that a developer, similar to a craftsman or an artist, goes through, or should go through, the stages of apprentice, journeyman, and master. He shed light on a few practices that he felt were myths (e.g. - practice makes perfect may not necessarily be the case if you practice while making mistakes and learn to adopt it as perfect). Obie used the analogy of a painter and the difficulty required over the ages to work with oil paints and their respective tools. He equated this to the evolution of software development and using the right tools when building an application. To my surprise, he also spoke to Zed’s post, showing an ad from the back of an art magazine selling the promise of learning to paint without effort next to a RoR for Dummies book with the word “ghetto?” underneath. In the end Obie focussed on showing us that after the years pass no one will remember if you programmed in Rails or anything else, but they will remember the results of those efforts (e.g. - what Twitter did for communications over the Internet).

Overall it was a good presentation. The idea of walking a career path involving an apprenticeship I think is a very powerful and practical one. Many engineering disciplines require apprenticeship for extensive periods of time before you can even call yourself an engineer. Software engineering as a discipline is gaining traction at universities and with the IEEE but its true acceptance in our industry, short of everyone wanting to use the title, is slow paced. I believe our industry still has lot of maturing to do until we can even begin to solidify what would be involved in composing a true discipline (although the SEI is doing a lot of work towards this goal). Many, including myself, think that testing will be key to some sort of success, but my opinion is probably a bit naive and inexperienced, so take it for what you will. Additionally, please keep in mind that my definition of a discipline is intended to be within the context of specificity. I use it leaving room for variation such that mastery, in terms of what Obie spoke about, can occur for specific domains of software development, not the entire field. Also, I don’t think of mastery as solely applicable to programming, but the software development process. After all, the most “beautiful code” in the world is worthless unless its potential for use can been fully realized and manifested … or something like that.

Great job on your first keynote Obie; after reflecting back upon it, I enjoyed it.

I skipped the Rich Media presentation in favor of a break, so the next talk for me was done by Charles Brian Quinn on good practices when educating others on technologies with examples given in Rails. The speaker spent most of his time going over a list of 4 things (really 5) that he felt were important to focus on while teaching:

• What is the purpose?
• Know your audience.
• Use relevant examples.
• Be objective.
• Teach how to learn, not why.

CBQ, as he called himself, suggested other tips such as getting people involved to double check work, the KISS principle, and utilizing difficult examples to make easier ones more understandable. Charles also gave a nice comparison of his experience while training with developers, designers, and managers from different backgrounds. His comments on designers struck me as really interesting; he suggested that their ultimate goal with respect to programming is to get the job done, rather than understand how. It was good to hear someone else confirm this.

Even though this talk was more geared towards those who take the responsibility to educate others in the community, Charles was able to keep people’s interest. I can definitely see the need for a talk like this in the Ruby community due to its latest boom in membership and so many taking on teaching roles. Good work CBQ.

After lunch we came back to Bryan Liles presentation on BDD which he retitled from “BDD with RSpec” to “BDD for Normal People”. Bryan is definitely a kindred spirit of mine, if only in his sense of humor. He was a great presenter and put a great face on the his own approach to TDD and BDD. What I liked about the presentation was his ability to bring practicality into the mix and give his audience direction and a place to start on their test driven journey. In any case, on to the topic at hand.

Brian started out describing his own journey into testing and some of the struggles involved. He pointed out that as most of us begin to integrate testing, many of us are adopting different approaches but still writing poor tests to cover poor quality code. Brian identified that tools can help us in our journey by introducing more clear test names and concepts such as context, but we still have to apply these tools more effectively. He gave the following steps as a basic guide to BDD:

• Get comfortable with the concepts in TDD.
• Make it your mission to practice TDD all of the time (even when it hurts).
• Think of your application as objects expressing behaviors.
• Create examples of those behaviors [and use them as the basis for your tests].

He expressed that TDD is painful and there is an upfront cost, but that upfront cost is migitated by the quality of the tests you produce and the less trouble you have as the software grows.

On the practical side of things, Brian, although praising what RSpec has done for testing in Ruby, suggested looking into alternatives that work a little better under the hood. He suggested sticking with Test::Unit, shoulda, and RSpec StoryRunner as he’s had the most success with this combination. Additionally, in the questions segment, Brian said he doesn’t have much faith in code coverage tools and only uses them to show a relative change in coverage to confirm that coverage has gone up or down.

Overall, I’ve got a lot of new topics to read on, and I’m sure Dan and Tyler will be happy to see me giving TDD/BDD another shot. Great work Brian!

NOTE: I forgot to mention the most important note from the entire presentation … TDD == BDD, it’s just a matter of perspective. Thanks to Dan for reminding me of this.

Anthony Eden gave this presentation on the inner workings of ActiveRecord. His approach was a little unconventional diving straight into the source code of the ActiveRecord::Base class. He did a good job of summarizing how AR utilized the different language aspects of Ruby to accomplish its goal. Mixins play a pretty large role in the library which didn’t seem like much of a surprise since I can definitely see their benefit when working with DSLs in Ruby. I was surprised to see that AR has a built in form of caching it uses for repetitive method calls (methods being generated at runtime and explicitly mixed into models to avoid repeat calls to missing_method); I thought this was pretty cool. Overall, I am a pretty big n00b to the world of Ruby and Rails, but from the parts I was able follow, Anthony’s presentation kept my attention.

I definitely still like GORM’s approach to ActiveRecord over Rails’, but that’s Groovy; what about Ruby? Also, what about the issue of working with legacy databases in Ruby? With a little research, Dan was able to show me DataMapper and rBatis which, we both agreed, look like great alternatives in the world of Ruby ORMs for the ActiveRecord and legacy stories. rBatis can even be installed as a Rails plugin, so maybe working with JRuby and Rails in the enterprise isn’t going to be as hard as I thought.

In any case, great talk Anthony! Good to see a fellow Melbourne-ite involved in the Central Florida technology scene.

Day 2 started out with some presentations from the sponsors of the conferences. We got to ask questions to guys at Engine Yard as well as see a short demo of working NetBeans for RoR development. Emphasis was placed on having a true debugger in NetBeans over other IDE solutions available in this particular development arena. I know a debugger is essential for the work I do with Java, so I can definitely see the benefits that Sun was trying to show; I hope others at the conference were able to come to similar realization. After these short plugs, we got into the real start of the day with Charles Nutter and his presentation on JRuby.

Charles is the recent celeb in the JVM languages world with the work that he’s done to bring JRuby to the community as well as participating in efforts to build standardized testing and set new baselines for performance in the Ruby language. Charles approached his presentation from the perspective of a developer who has only worked with MRI. He showed us a few uses cases that have been successful with JRuby and Rails including Oracle Mix and Mingle. He ran some performance tests for us showing JRuby 1.1 (trunk) versus Ruby 1.9 and how in most benchmarks JRuby was more performant after the initial startup costs of Java. He talked about the great work being done in the activerecord-jdbc-adapter project along with the benefits of using JDBC for database connectivity. For his final point, he talked about deployment scenarios comparing Mongrel and more traditional JEE servers, exemplified via GlassFish.

If you follow JRuby in the news, there was only one surprise in his entire presentation. Charles showed us an awesome gem that the GlassFish had put together to make it easier to deploy JRoR applications. I’m going to mess with the gem more, but from what I could tell, the gem allows you start a stripped down Glassfish server preloaded with your Rails app by simply calling a command that comes with the gem. It was mentioned that it’s a 0.1 beta, but the end goal is have a production quality server out of the box. Awesome.

Overall, it was great introduction to JRuby and the tools available to it. Great work Charles!

To end the day, Dan Benjamin gave a keynote presentation simply entitled “Simplicity”. Dan started out talking about how the real world can effect your applications as well how the internet can effect the real world. He showed us some statistics from Twitter around the Super Bowl and then how campaign funds raised over the Internet helped to provide major increases to presidential candidates’ coffers. He went over some comparisons for growth and overall demand in the developer industry as well as conveyed an interesting statistic that Orlando is 16th in the nation for technology jobs. Dan went on to show some examples of what he considers complex user experiences versus simplistic ones. Examples were drawn from some sites he found online as well as his experience with Cork’d, citing most of his success with Cork’d due to his designer colleague and a simple user experience. A focus was placed on the ability for a developer/designer to drive design decision when the user should be the one who is really in control. Dan has a few other suggestions: don’t release a beta, apologize to users when things go wrong, and just ship the product to avoid feature creep.

Overall the keynote was a lot different than other conference keynotes I’ve seen delivered. Most people usually expect keynotes to focus on the technological topics from which the conference is based, usually with a focus on direction for those technologies. Dan took a more general approach and focussed on good design practices in a technology agnostic way. Although different, it was a good presentation and I enjoyed the talk.

Peter Armstrong, author of Flexible Rails, gave this presentation which focussed on how Flex and AIR can consume REST’ful resources. Peter unfortunately had a hard drive crash about an hour before his presentation so needless to say his presentation didn’t go as planned. Although he didn’t really have any slides (because they were all destroyed) he was able to borrow the laptop of a fellow conference go’er and show us some code examples.

The code examples were geared towards introducing MXML and Actionscript to Rails developers. I feel pretty comfortable with both, but it’s always good to see different approaches to coding in Flex, especially code using HTTPService since I spend more time using RemoteObjects. I would have liked to seen, if only mentioned, the topic of component development (visual and non-visual) and data binding, but I can understand why it was omitted since most Rails developers aren’t familiar with UI practices other than your standard web stack.

Towards the end of the presentation, Peter revealed Ruboss, a Flex framework built specifically for consuming REST’ful resources. Ruboss uses a controller to expose an Actionscript interface to translate CRUD operations to their REST’ful equivalents. He said he’s going to be releasing it over the next few weeks under his new company, so watch Ruboss.com for more details.

We’ve asked Peter to give a Connect presentation at an Adogo meeting later this year on Flex/AIR and Rails. The Orlando community can definitely benefit from Peter’s work with Flex/REST and we hope to pimp that to its fullest … j/k Peter, keep up the great work.

Luke Francl, from SlantWise Design, gave the 2nd presentation of the day on Best Practices for Rails Teams. He went into common problems that any Rails shop with 3 or 4+ developers have to address. I didn’t get much out of the presentation since I’ve spent the majority of my career trying to solve these issues, but a lot of people were attentive and the Rails twists did peek my interest; migration conflict resolution was very interesting. Luke did a great job referring to some classical and popular texts for project management and had even had a detailed hand out, so he was definitely prepared.

It’s always good to see people pushing good SCM and PM practices in a community. Keep up the great work Luke.

Yesterday morning I skipped the charity session, not because I hate charity, but in favor of getting some work done at the office before the conference. For me the first session was Neal Ford’s presentation on Advanced DSL’s in Ruby. Neal works for ThoughtWorks where they have being using Ruby to build internal DSL’s for customers with some success. He focussed his presentation around a Bakery example, but more importantly, while doing so was able to convey a set of patterns that they’ve found useful while building DSL’s (mainly internal DSL’s).

• Went over good uses for method chaining and nested method as they apply to creating/maintaining an object’s state (Good Citizen pattern).
• Spoke about benefits of using method/property aliases as a cheap way to provide clarity (e.g. - gram() and grams() do the same thing)
• Detailed the Type Transmogrification pattern and the Constant Missing Factory pattern and the benefits of using “open” classes (e.g. - missingMethod and missingProperty methods) to avoid cluttered implementation classes that provide flexible interfaces.
• Talked about using context to reduce code noise within the DSL itself.
• Went into the Bubble Word pattern which provides “empty” semantics allowing the DSL to be more expressive but helping to simplify the DSL’s implementation.

Neal also spoke about external DSL’s a bit getting into an Expression Builder pattern which gives a good context for good practices as far as parsing DSL strings go. One thing that was reassuring to hear was the discouragement of complicating DSL strings with the intention of using regex to reduce complexity. I’m regex stupid, so whenever someone tells me they’ve been successful by taking simpler approaches, I’m always happy.

This by far was the best presentation of the day, IMO. Recently I’ve been working on a mock object library for ColdFusion and a lot of the topics Neal mentioned in his talk resonate with me as a good basis for solidifying my ideas for the library. ColdFusion lacks the majority of the great meta-programming features that a Ruby or Groovy would have, but I’ve some ideas up my sleeve. Great work Neal! I really enjoyed the talk.