Today was a training day.  The conference officially starts tomorrow, but there were some interesting things that I learned in my classes:

Ruby Craftsmanship with Gregory Brown & Brad Ediger

Code is written once and ready many, many times over.  It’s because of this fact we want to make sure we write good code.  Writing good code also helps you avoid shooting yourself in your foot or painting yourself into a corner on a project.  You’ll find your work more enjoyable as well, it’s more pleasant to work in a well-ordered project than one which is in disarray.

Reading code is an important skill.  You should practice often by reading code from other projects, like open source projects, and figure out how things are working.  Try to be as comfortable reading code as you are conversing with people.  Remember docs can lie (they can be out of date or just plain wrong), so it is important to be fluent at reading code.

A good majority of the morning was spent working through design koans and talking about why they are true.  A koan, for those who are unfamiliar with the term, is a Zen practice where the student is demanded to answer the question.  In the class they were a series of unfinished unit tests that had to be completed and made true.  You can find a set of them here: http://github.com/edgecase/ruby_koans

The second half of the class talked about the nuances between a class, a module, and a singleton. Why would you use one over the other?

Classes

• can be instantiated as objects
• class variables can have far-reaching (unintended) affects
• object data exists separately
• can implement interfaces

Modules

• cannot be instantiated as objects on their own
• help manage namespace and be used as a mixin
• module methods are not included into their calling class

Singletons (class, not pattern)

• are class-like entities, but cannot be instantiated
• methods are stored per-object, rather than per-class
• all class methods of a class are actually kept on a singleton class

The singleton stuff can be mind-blowing, so if you wish to understand it better you can check out an article “Understanding Ruby Singleton Classes“, by Peter Jones.

We were also encouraged to pair-programming during the session.  A rare experience I get to enjoy, since we do not pair-program where I work.  I got to pair with Ben Kimball, a local Austin developer like myself.  He wrote the unit tests (defining what the interface should be) and I wrote the implementation (the actual code to make them pass).  The interesting thing that was happening is that through the process of test/code writing we talked about the design and really came to understand what was going on and what was needed – resulting in a better design (that was also testable and tested) than maybe we could of done individually.

Greg and Brad also shared some other general bits of wisdom:

• When working on problems, even when doing so alone, talk with your team as you go along.
• YAML parser will automatically convert things that look like dates into a Date class.
• Do not ever use class variables, instead use class instance variables (by opening up the singleton class), because class variables can have far-reaching affects.
• If you work in an “enterprisey” organization you can still do TDD.  Just do your pair session and write your tests, which will flesh-out the design, then go back and create/update your “formal” design documents to match.

Additional things to research:

• eigenclass and metaclass
• dependency injection

Day three of the conference was not as good as the first two. The presentation by Rails Envy was great. Greg knows what he’s doing, and Jason is always able to inject humor.
Rails Envy – A Year of Innovation

Gregg and Jason spent about an hour touching on various “cool” things that have come out this year, or just finally came to popularity this year. Below is a list of some of the things that I found interesting:

* Prawn – a PDF generator for Ruby
* roo – used to read spreadsheets (works with Excel, OpenOffice and Google docs)
* Shard – lets you partition databases based on schema
* merb – a Rails alternative
* Mack – a Rails alternative, specially suited for portal applications
* Webby – a Rails alternative, geared around static web content (brochure sites)
* Shoes – a way to make cross-platform Ruby applications
* Sinatra – a good choice for more “purely REST” applications
* Redmine – a very flexible PM tool
* Adhearsion – VOIP with Ruby
* make_resourceful (and resource_controller) – both remove duplication you often find inside Rails REST-style controllers
* Starling – provides lightweight messaging
* Thin and Ebb – faster web servers than mongrel, allow deferred requests
* Neverblock – allows for multi-threaded DB adapters

Gregg even did a few demos of particular ones. The one most impressive for me was Neverblock. Gregg demonstrated a series of queries that took 30 seconds to complete (because they were handled in a single thread, one at a time). With Neverblock the same set of queries took 3 seconds!!

The second day at the Lonestar Ruby Conference was filled with heavy hitters: Bruce Williams, James E. Gray, Bruce Tate, Evan Phoenix, and Yukihiro Matsumoto (aka Matz) himself. I was also excited to see Dave Thomas (a personal hero, he wrote the “pick-axe” book and does the Pragmatic Books). I learned a lot.
Ruby 1.9

The day started with a talk by Bruce Williams. He’s well known and respected in the Ruby community, and he lives in Austin, TX – which is cool. It has that “Lance Armstrong” effect when you have notable people living in your own town. Anyhow, he talked about what’s coming up in Ruby 1.9. It was a lengthy technical discussion about the inner-workings of Ruby 1.8 vs 1.9. I will not get into it here, there’s plenty on the net about it.
Hidden Gems

The next talk was by James Edward Gray II, and it was one of the best presentations of the whole conference. He compared what’s going on in the Ruby community to Battlestar Galactica and presented a series of lesser known Ruby Gems that could help make life better. He debunked the myth that Ruby is slow saying, “Ruby is slow—it’s not true. It’s as fast as you want it to be.” (The “Ruby is slow” or “Rails can’t scale” were recurring themes in a lot of presentations – it’s the biggest misconception the community is wrestling with right now.) Some of the gems he presented that I found interesting were:

* NArray (Numerical Array) – really good a heavy number crunching, provides a 3-dimensional array
* SQLite – it’s a fast and free database, often overlooked by people
* RBTree – James considered this the “big gun of computing” (like the cylon soldier robots)
* FSDB – this isn’t a gem, but it works better than a RDBMS in storing time-sorted data (eg logs, reports, etc)
* Rinda – it comes with Ruby and doesn’t need to be installed, it is dirt simple IPC

He also plugged Scout, which is a Rails server monitor he wrote.
Ruby Best Practice Patterns

The last presentation before lunch was on best practices and patterns, presented by Rein Henrichs. I found his presentation to be clever. He presented it as a parody, “unfactoring” as he called it. The premiss was that developers who write clean, easy-to-maintain code were stupid and soon to find themselves out of a job. Instead he proposed we write code that was hard to maintain and thereby keep our jobs secure. Of course he wasn’t being serious.

Some of the points that I took away (and many of which I already subscribe to) were:

* Use intention revealing names for variables and methods
* Write code for maintainability, optimize for it, since 90% of a project is maintaining code you wrote
* You should be able to read something at a glance and understand what it’s doing (if you have to take time to “walk through the code” before you understand what it’s doing, it’s badly written)
* Use around_filter (in Rails) instead of before_filter + after_filter

Javascript Frameworks

This session was insightful. It mainly focused around SproutCore, which is the same JS library that’s used by Apple’s MobileMe. You can write an application with very ERb’ish style mark-up. You can get SproutCore on GitHub. Some of the highlights of SproutCore:

* standards based
* builds desktop grade apps in your browser
* mvc
* used by MobileMe
* more Ruby flavored
* generators
* fixtures
* uses Merb for local development

The Care and Feeding of Ruby Developers

This session was presented by the VP of Development and Technology at FiveRuns. He’s come to the conclusion that Rubyists are a different breed of developer. They’re not like the Perl and C++ folks. Rubyists actually care about aesthetics! Some of the highlights of his talk:

• Pervasive Aesthetics
  • visual design aesthetics are very important, essential
  • aesthetics of the work environment (they will find a good place if you don’t provide one)
• Collaboration
  • baked into the community from the beginning
  • course correcting feedback
  • independent of physical location
  • independent of organizational boundaries (business competition, politics, etc., not as much a factor)
  • people who are not contributing, etc. get seen as not being alive, fade into the backdrop
• The Doing is Close to the Planning
  • results in more Stars
• Living on the Edge with the Latest
  • tend to be early adopters
  • comfortable with the rapid iterations of open-source
• Enlightened Capitalists
• Care and Feeding?
• Awareness
• Purpose
• How well do your other communities match these qualities?

Tate’s Talk

Bruce Tate gave a talk about unconventional wisdom. Rails was great in that it brought a lot of people to Ruby, but at the same time it made a lot of people stop thinking. The auto-magical nature of Rails makes it easy to take off your thinking caps. His talk was to challenge us to get back into thinking critically about what it is we do as Ruby developers. Dave was in the audience on this one. At one point he said, “The boilerplate controller code in Rails is crap; and it shouldn’t of been done that way.”

• What do you aspire to be?
• What motivates you? Beauty? Money?
  • money should be the motivator
  • beauty helps you get there
• Who’s the beholder?
  • consider perspectives
  • REST has its advantages, but it comes at a cost
• Fixtures and testing—remember isolation is the goal, and islands are not dry!
  • use fixtures for small projects, simple models, and teams with few developers
  • go fixtureless when it’s a large project, complex models, or teams are large or inexperienced
  • don’t use fixtures for edge cases
  • don’t use more than 4 then that’s a code smell, refactor
  • don’t use fixtures for count or roll-up tests
  • don’t use fixtures for edge cases

Tate’s final comments:

* Have purpose
* Value the economics (money)
* Your code should tell a story and be readable

Tate’s challege to us all:

* We are in a fortunate time and industry (with Ruby, in the US), mentor someone in Ruby
* Find ways to give back to the community
* Use your skills to change the world

Later that Evening

Evan and Matz were the keynote speakers. Out of respect I kept my laptop shut and listed to their talks. So not many notes here. Both presentations were very good. Matz reminded me a lot of working at NTT Verio—I miss those days.

I’m attending the Lone Star Ruby Conference, here in Austin, this week. I’ll be attending some classes for the first day, then the presentations Friday and Saturday.
Advanced Active Record

The first class was insightful. It covered various aspects of ActiveRecord. It was cool to be able to see the Rails Envy guys in person. I think the time given for the code challenges could of been a little more generous. It felt a little rushed. A lot of it was a review, but they also covered some subjects I haven’t done that much with (such as the use of indexes). They also touched on plug-in and gem creation. Something I want to play with more very soon.

Things I’ve Learned

When you have to load a large sets of data it’s a good idea to wrap it inside a transaction. You can also use two extra gems that help make your job easier: ar-extensions and faker (you should check them out).

Do you have queries that are taking longer that you’d expect? Maybe you need an index. When you have a lot of associations indexes are a good idea to keep things speedy.

If you are using :include to pull in data from other tables try to avoid using :conditions along with it. You’ll find that things might get ugly.

One really cool thing I learned from this session was the use of counter caches. I’ll probably write more about this later, since I don’t have the time to go as in depth as I’d like with it right now.

How to write plug-ins and gems. (Well they didn’t go too in-depth on it, but I know where to start – so a new weekend project will begin soon).
Advanced Mocking

The mocking class was interesting. I learned more about the differences (although subtle) between a stub and a mock. Jim says there isn’t really any (for practical purposes). He taught that knowing when to use a mock vs a real object is a personal preference. As is when using a partial mock with a pure mock. (You can create partial mocks based on real objects/classes).

I’ll try to write more on this topic as well as it’s pretty interesting. It too requires some though and there’s not enough time to go into right now, so more later.
Overall

All and all the training was good. I wouldn’t say it was the best, but it’s definitely worth the price. The thing I think that was great about the training was you had access to the experts. Jim wrote Flexmock, for example, and how great is that to be able to have the author teach about his own testing library? The negative though with both is they felt rushed. There were a lot of exercises and a times it felt chaotic or rushed in terms of what your objective was and or what you already had on hand to start.