Thats right.  The grand plan was to have everyone use trial versions.  Except - all but three of the trials were expired.  Obviously, thats not to hard to fix… just re-image the machine and monkey around enough so you can trick adobe into giving you another 30 day free trial.  Repeat every 29 days.  She said it takes about 7 hours per machine.  ARE YOU KIDDING ME?  Buy the licenses or don’t offer the class.  I felt bad for the instructor.  She asked for the licenses and was told that it’s too expensive to pass onto the students’ departments and its not in the budget.  But instead of just offering classes based on CS2, they insisted on CS3 and their special never-ending 30 day free trial arrangement.  

I’m embarrassed that this would be an acceptable solution.  I’m sure they offer training on ethics and corporate values - I don’t think this fits.  This is a department that’s sole purpose is corporate training and they do it on a big scale.  How is this in any way a professional solution?  

Then there is the economic impact.  Someone really thought that this was a better solution?  Pay a one time fee or tie up your staff re-imaging laptops over and over again?  I don’t know what the IT staff is making - but can this really result in a cost savings, including the lost opportunity costs?  How about the costs of canceling the class and rescheduling it so machines will be available?  

Absolute shameful behavior. 

My favorite one was MVC #1 Controller Obesity but I thought they all were great.  

I also enjoy listening to the RailsEnvy Podcast. So if you’re looking for something to listen on the commute to work - check it out.

Despite my embarrassment, I still attended Optimizing Rails, a talk given by Michael Koziarski at RailsConf 2008.  This talk wasn’t about optimizing your rails application.  It focused on how to optimize the Rails Framework itself.  Optimization is a scientific process which requires profiling followed by fixing, repeated many times.  Short circuiting the process is the equivalent of guessing - and when we guess we are always wrong.  

He told a story about their Trac installation for Rails.  Their installation was above and beyond the normal traffic usage patterns of other projects and they were  having crazy performance problems.  Naturally they looked to the community for help.  People suggested lots of things.  They upgraded the database driver - no effect.  They tweaked some settings - no effect.  Finally they dug into the code to see what was going on and discovered that the svn revision number was stored in the database as a string.  Turns out there is code called multiple times on every page to calculate the most recent svn version.  Calculate is the correct word.  Instead of doing a simple sql query to get the max reversion number there was a method that would calculate the latest version number from a string (Hey - someone may want to use a Version Control System someday that uses strings as keys for revision identification - right?)  This implementation, combined with their high load was enough to bring the site down.  So they hacked it to store an integer and the performance problems went away.  The key lessons were that everyone else knew what the problems were but it wasn’t until they measured and profiled, and used a  scientific method that they found the real problem.  

This principle applies to optimizing Rails.  You can’t just guess and most people know that.  So naturally, they look for something to serve as a benchmark - and that’s the problem.  What is a good benchmark for Rails?  Many of the posts deriding Rails’s performance build a trivial hello world app and then benchmark it.  Michael showed a couple of different examples of benchmarking against a trivial program and the results.  Then he compared benchmarking one of his client’s applications and the results.  As you may guess, they were quite different.  What was a huge performance hit (say 15%) in the trivial case was completely irrelevant in a more representative application.

The Core Team does work on optimizing Rails by using their own applications as benchmarks.  While working on these real applications they find problems, bring them back to the group for discussion and finally add them to Rails if it seems like it might be a good fit.  He hinted that their time was limited, so it might be better spent working on tangible tasks like documentation, feature requests, etc, rather than blindly looking to optimize the framework.  I agree with this approach.  

We know that Rails was extracted as a framework from a real application.  I like the fact that the optimizations added to Rails are also extractions from real applications instead of just making theories and going with their gut to find performance improvements.  So the next time you think - “man Rails is inefficient or bloated or slow - why don’t those guys fix it” - go ahead and benchmark your application and see if the Framework is really the limiting factor.  You may be surprised by the results.    

Yet, I am increasingly buffeted by those singing the siren song of choice and flexibility.  It manifests itself in the form of a discussion over breakfast with some DataMapper developers.  ”DataMapper is faster.  It uses less memory, it’s more efficient, it isn’t as opinionated - you can configure it.”  Ding Ding Ding, that is the problem.  I don’t want to configure it.  I don’t want choices.  I don’t want to research, evaluate, and decide.  I don’t want Java and its infinite flexibility.  I do want to create killer applications.

The song doesn’t stop. It just changes channels, and guess what’s playing - Jumpin’ JQuery Jazz. “But JQuery is so much cleaner, it plays nice with others, it’s smaller, it’s built on css selectors, it’s unobtrusive.”  Wow - that’s really cool but what you didn’t mention is that it doesn’t work with the rails views and javascript helpers. And like a loving father who sorrowfully watches a wayward child wander in darken paths, Rails will let you override its defaults, constraints and conventions and wish you luck as you set out on your own.

By the time the Rspec retro reggae hits my ears - I just turn the radio off.  The music is giving me a headache.     

There is a reason that java developers are famous for developing frameworks rather than actual applications - they all get bogged down in the decision-making process.  I mean it is completely overwhelming.   They have to choose a web framework, a presentation layer, a database access strategy, a build system, a testing framework, a development environment, and find a way around or out of the train wrecks that are EJB and JSF.  Luckily, being excellent computer scientists they recognize the limitations of the current offerings and set off to fix them.  And that, ladies and gentlemen, is why we have Ten Thousand Java Frameworks And Counting.

So I proudly declare it.  I’m not a computer scientist.  I’m an application developer and entrepreneur.  I solve business problems.  I’m a Rails Disciple.  I embrace its constraints and conventions.  I love that it makes many choices for me.  I’m not blind and oblivious to new technology and I don’t claim Rails the victor in the discussion of technical superiority.  However, I will outsource many technical decisions to Rails and sleep all the better for it.  After all, if it works for 37 Signals, surely it can work for me.  

While talking about color schemes he touched on the fact that colors have emotions, often conflicting ones, attached to them.  And we aren’t even talking about meanings attached by different cultures.  Red can signify error, love, hate, passion, etc.  He advised us to be conscious of the emotion colors may trigger in our users.

In a discussion about using web-safe colors (his answer was no-you don’t need to) - someone told a funny tale.  They were designing a site for a restaurant.  The restaurant was big on fresh produce so he worked hard to get the right combination of green and yellow ready for the site.  After everything was finally tweaked to perfection - he gave it to the client.  Later, while he was at the restaurant and looking at the client’s machines running the site in IE, he got sick.  Literally - the colors that he had so carefully crafted now reminded him of being sick.  We all got a good laugh and the point was emphasized to test on every browser if we want to be sure of our design.  In fact he said, “If you have a mac, it’s ridiculously easy to test IE.  If you have a PC - get a mac.”  

We also spent some time going through the process of designing a logo in Adobe Illustrator.  I hadn’t ever used Illustrator before, so it was great to see a demo like this.  My logo skills have consisted mainly of tweaking fonts - but now I have some new tricks in my bag.  

We did a similar thing for Photoshop - showing how you can quickly mock up a site and transfer it over to your rails apps.  He was running short on time by this point - so he went over this a bit quickly because he wanted to cover some information on css.  I wish he would have spent more time on it - I’ve always resorted to just using css to try and mock things out and wondered if using photoshop would be faster.  From what we saw - it seemed like it could be a very positive thing.

The CSS information was good - but not new to me.  There was discussion about how to size fonts.  He told us that he always uses pixels - because its a common measurement between the web, illustrator, photoshop, and the screen.  He acknowledged that many people point out that this will result in messed up layouts if the user changes the font size.  He mentioned that as someone who regularly increases the font size of a site - at that point he isn’t interested in how it looks - but just wants to read the content.  In general he thought that it shouldn’t be the designer’s problem to make the site look good as fonts scale - but rather their job to make sure that it would still be readable if that happened.

We also spent some time talking about font faces and how to lay out fonts.  He pointed out that while in the print world - body text is easer to read as serif and sans-serif fonts are better for headlines, the opposite is true on the web.  He talked about font-grids and that he likes to set his font at 12px and line heights to something like 18px, to create a uniform grid look.  

 My only complaint about the talk had to do with his use of the zoom.  While I’m sure it made what was going on the screen bigger, it gave me motion sickness to have the screen constantly zooming and panning while trying to watch him work in illustrator or photoshop.  I don’t fault Brian, and appreciate his forethought, I still wish there was a way he could show what he was doing on a bigger screen at such a resolution that even those in the back could see.  But overall, it was a great presentation.  I would listen to him speak again and am anxious to read his book when it comes out.  

In contrast, I left RailConf 2007 with mostly a headache.  I was expecting a similar experience like those from NFJS- minus the small conference like atmosphere.  I think the biggest surprise were the vendor land-mind talks.  You know the ones - they have titles like “scalability” etc but really are about a specific product.  I wasn’t really aware of this trap, and took for granted the NFJS policy on not allowing vendor presentations, and inadvertently spent more time that I would have liked in vendor sessions.  My goal is to avoid unintentionally wandering into those this year.

It also seemed like the presentations just weren’t up to par - both the topics and the skills of the presenters.  RailsConf sold out quickly last year - and to address the increased demand the conference added another track late in the process.  I’m not sure if that was the cause, but I suspect it played a part in the feeling that overall things just weren’t polished.  Now there were definitely exceptions, but I felt that out of the 3 days - almost an entire day of sessions could be categorized as ‘meh’.  Maybe it was just a manifestation of the growing pains exhibited in the community as a whole.  Maybe I just didn’t know, like in college, which were the do not miss, in contrast with the avoid at all costs, presenters.  

This year, I’ve grown up a bit with rails.  I’m more familiar with the technology.  I have some experience under my belt and am able to ask better questions.  I think the speakers have also had the time to prepare their thoughts and polish their presentations.  I’ve done some homework on the speakers and am looking forward to hearing what they have to say.  I’m also excited to meet fellow developers and broaden my horizons.  My outlook is a bit different,  I have a better idea of what to expect, and I’m optimistic that this is going to be a great event.  Here’s to a great RailsConf 2008.