ADS specializes in using Ruby on Rails to build advanced, scalable, database-backed web sites for organizations of all sizes. Find out more at our website.

Well, RailsConf Europe is over. I need a vacation! The remainder of the day was chock full of presentations. After Ola’s JRuby presentation I went to see another JRuby presentation on JRuby tools. They discussed building JRuby on Rails apps using the NetBeans IDE. While there are some cool features, I’m a lover of TextMate. When I was developing VB.NET apps back in the day I used Visual Studio. I used to miss IDE’s that do things like code completion and things of that nature, but now find that it just gets in my way. But, to each their own. If you are a Java developer (or convert) and are productive using NetBeans (or another Eclipse based IDE), go for it. That took us through to lunch.

After grabbing a few more shots of espresso and relaxing for a few, I headed back to catch up with the hobos.

“Exploring Very Rapid Web Development Techniques with Hobo” by Tom Locke was definitely cool. Hobo is “an Open Source extension to Ruby on Rails which helps you build full blown web applications incredibly quickly and easily.” Dr. Nic created the MyConfPlan site using Hobo. Filling the gap between an “auto admin” tool and hand coding an entire application, you can get an entire application up and running in a few minutes to a few hours, complete with AJAX, model level security, controller generation and the DRYML tag library. A few of the “smaller features” are automatic routing, a migration generator, authorization and sign-up, search, “kinda” theme support, and many more. Not yet at version 1.0, the Hobo team is working on documentation in the form of a comprehensive screencast series, API stability, and performance. Looking beyond 1.0, they want to add plugins, themes, and user created tag libraries.

Stuart Eccles sums up the next presentation, Extending Rails to Use the Presenter Pattern, on his Liverail blog. I was left with a “huh?” feeling from the talk.

The last presentation of the conference was “Obscure Data Formats, Workflow, and Remote Synchronization,” presented by Chad Thatcher. His presentation was excellent and had more content that I can explain at this hour (sorry folks) - check the RailsConf Europe site for the slides. One part I can comment on is the discussion of composed_of, which allows us to take control of a models’ composition by mapping our db fields to objects other than those that are mapped automatically by Rails. Check out the API docs for all the details.

And so ends the fun.

Tomorrow, Anthony and I will do some shopping for our families, and then back to the US on Friday. Senior project is Saturday, Chris arrives on Saturday, and then BarCampOrlando on Sunday. If you are there we will see you then.

Thank God for a continuous flow of coffee and multiple cafe’s on every block. I love Berlin! Things are as hectic today as they have been everyday.

The second half of this morning brought a talk on JRuby from Ola Bini, one of the JRuby development team. Ola’s presentation had a lot of material, so allow me to summarize:

What’s wrong with Ruby today?

• Green threading
• Partial Unicode support
• Speed (slow)
• Memory management, specifically the garbage collector
• C language extensions
• Politics (you want me to switch to what?)
• Legacy (Java is everywhere)

What is JRuby?

• Java implementation of Ruby
• At version 1.0.1
• Based on Ruby 1.8.5
• 6 core developers, open source, close to 40 contributors
• Commercial backing from Sun and ThoughtWorks

What can JRuby do?

• All ?��Ǩ?�pure Ruby?��Ǩ�� code works (with some caveats)
• Rake and rubyGems run well
• Rails works almost perfectly

What can’t JRuby do?

• Deterministic threading
• Continuations
• Some file system operations
• Forking, and other POSIX ilk

So, how does JRuby solve the stated problems with Ruby?

• Native threading
• Scaling across processors and cores
• Concurrent execution
• Thread scheduling
• No politics - just another Java library

What challenges does JRuby face?

• Performance of unit tests
• It’s not “free” to run both JRuby and MRI (Matz’s interpreter)
• Start-up time (especially with Rails)
• JRuby regular expressions have different performance characteristics
• YAML isn’t stable yet
• High memory consumption (but still less than Mongrel)
• Good replacement for RMagick is needed
• Lack of documentation

It was a great session with a lot of information. Hopefully Ola will have his slides posted to the RailsConf Europe site.

Wednesday morning at RailsConf Europe brought first a quick spiel from Cyndi Mitchell, VP of Strategy at ThoughtWorks, and then a best practices discussion from Michael “Koz” Koziarski and Marcel Molina.

Cyndi began her Ruby in the enterprise talk with a flash back to the dot com bubble, the days when business models were nowhere to be found, bloatware was prevalent, companies were told and did invest in large amounts of infrastructure and software glue, and the CIO commanded from the engine room. Fast forward to 2004. Migration projects were failing, businesses were upset with IT, everything was a mess.

Cuts began.

Enter the innovator CIO. Businesses demanded more in six months than they had received in two years. Not only did they want it faster, they wanted to be able to change it mid-stream and afterwards. They were now in a global economy and needed to be able to move faster, be more agile. They were looking for a better way. There was a better way. No longer did you need huge amounts of infrastructure to build a business application. No longer did you have to wait months for a result. No longer were you in an environment lacking the ability to quickly change.

Enter Ruby.

Ruby made it possible. Rails brought Ruby to the masses. Now, technologies like JRuby and IronRuby are lowering the barriers to Ruby adoption in the enterprise, where Java and .NET abound. Ruby and Rails developers, armed not only with programming knowledge but also business saavy are helping Ruby to cross the chasm. It is an exciting time.

Michael “Koz” Koziarski and Marcel Molina discussed best practices, focusing mainly around the fat model skinny controller method of development. Check out the articles for all of the fat model goodness. A few additional points from the talk were:

• All code in a single method should be at the same level of abstraction
• The point of object oriented programming (OOP) is that the code should map to the business that you are trying to model
• Use associations as much as possible
• A major point of test-first development is that by listing your expectations first, you approach the problem from the human perspective

The plan for the rest of the day for me includes JRuby presentations, Hobo, and more. What a day!

RailsConf Europe 2007 presentations have started to appear on the O’Reilly site. Get them here.

I couldn’t avoid going to the “Really Scaling Rails” presentation by Britt Selvitelle from Twitter, after all of the hubbub that surrounded their scalability issues. I was glad to hear that we address scaling along the same lines that they do. Here’s the low down…

Generally speaking, a Rails application deployment looks like this: Internet -> Apache2.2/mod_proxy_balancer -> mongrel_cluster -> MySQL. For smaller sites, Apache, Mongrel and MySQL are on a single box or VPS. Depending on the environment, memcache servers can also be sprinkled in between Apache and Mongrel servers, taking load off of the Mongrel servers and the backend database. Bottlenecks begin on the outside (or the Internet side) and move inwards. So, let’s see some solutions:

1. Apache: more front-ends + hardware load balancers
2. Mongrels: add more mongrel servers (with lots of memory) and configure Apache to only send one request to a single Mongrel at a time (i.e. one request per Mongrel)
3. MySQL: clustered database servers and memcache servers - try to keep out of the database as much as possible

Britt simplified the challenge to this: you either spend too much time in the application or you spend too much time in the database. Once you start tracking performance metrics in the app, can view lots of great and colorful charts, and are ready to move fast and scale quickly, address the issues.

Spending too much time in the application? Abstract long running processes using daemons - send em to the background. Also, make use of a queue. At Twitter, they use a pure Ruby distributed queuing system that can run nine or more daemons for a worker process.

Spending too much time in the database? Start by adding indexes to everything that you query on and avoid complex joins. Next, cache as if your life depended on it. Page caching in Rails is super simple, and other techniques such as action and fragment caching can speed things up as well. Once you’ve exhausted those, serialize, denormalize, and cheat (in a good way of course). Other miscellaneous tidbits that Britt left us with are:

• It’s OK to use Monit to kill processes if they get too big.
• Ensure that you can deploy frequently - enhance and deploy.
• Ensure that you can roll back easily - for those “oops” moments.
• Scale where it matters - where do your users spend most of their time?
• Some code is ugly. That’s OK.
• Ensure that your users can easily give you feedback.
• Use the community.
• Make an API - scale your developer base
• Twitter runs on edge Rails using Piston - weren’t we told NOT to do that?
• Put gems in Vendor - tweek em and keep em

The second presentation was Evan Phoenix from EngineYard talking about Rubinius. The purpose of Rubinius is to develop a better Ruby that will result in a better Rails. The project strives to address many of the pain points of the current Ruby interpreter. Per Eva, current pain points include:

• Memory usage - the Ruby garbage collector uses a lot
• Packaging and deployment
• Performance - people say Ruby is slow…
• Error reporting - back traces are illegible, even for developers
• Profiling - running it on a production server is crippling

Rubinius addresses these (respectively) by:

• Fork all you want, it won’t use more memory
• .war-like packages (.rba), pre-compiled code, meta data about a project (RDoc), and assets
• Inline caching, pre-compiled code, and JIT (eventually)
• Back traces are produced in Ruby code, are super easy to read, and even get their own extendable class
• A sampling profiler will always be available with little to no impact on performance

Rubinius is a very exciting project that everyone will be watching.

Next up are three keynotes - busy day.

Hello everybody. Tuesday morning brought a boat load of Rails goodness to us here in Berlin. DHH, as usual, gave a great keynote and took questions. Nick Sieger has a great writeup about it on his blog.

It was hard to decide which morning session to attend, however my choice was Making Rails More (Artificially) Intelligent. The focus here was using Bayesian networks, a Ruby classifier, and genetic algorithms, to solve common challenges such as how best to optimize ad revenue on a site and routing emails to the appropriate department. Check below for links to a variety of gems that make this unbelievably simple (have I said how much I love Ruby today?).

• Presentation materials - http://bee.com.es/
• Bayesian Networks for Ruby - http://bn4r.rubyforge.org/
• General Genetic Algorithms for Ruby - http://gga4r.rubyforge.org/
• Ruby Classifier - http://classifier.rubyforge.org/

The second session of the day was 3rd Partying Issues and Solutions, by Ryan Garver, CTO of ELC Technologies. ELC heavily uses 3rd party applications such as BaseCamp, Trac, Salesforce.com, and Google Apps. The challenges that Ryan addressed were tying these disparate applications together using their APIs to present a single dashboard interface with a single sign on, and potential hazards such as timeouts and unavailability. ELC is about to release a Rails plugin called “synchronize_it” that will the rest of us integrate multiple 3rd party applications into a single Rails app. Stay tuned for that one.

Update: Casper Fabricius has a great overview of the DHH keynote as well. Read it on his blog: http://casperfabricius.com/blog/2007/09/18/railsconf2007-dhh/

Can there be art without engineering? Can there be engineering without art? These were some of the questions Dave Thomas asked in his keynote last night at RailsConf Europe.

Comparing software developers to artists, Dave likened the tools of the developer to those of the artist. Our canvas, a blank screen, our brushes, languages and frameworks. He discussed how we too have writers block, overcome with rapid prototyping, something Rails excels at with scaffolding. By getting something into or editor, we break down the blocks and start to see how we might approach a new project. Dave then went on to discuss how we can learn from the master artist Michelangelo.

When he was commissioned to paint the ceiling of the Sistine Chapel, I am sure that Michelangelo, at first, looked at the task as a rather large one. There were two possible approaches: take the ceiling as a whole, or break the task into smaller portions. He chose the latter. Taking a modular approach, Michelangelo depicted a portion of the Genesis story on each panel. Taken individually, the panels stand alone; taken as a whole, the viewer gets the entire story. This is the same way in which modular software design works. Each piece performs a single, specialized function (a module), and is then tied into the program as a whole. Programming in this way also allows a more iterative approach, which simply means that you develop the application piece by piece.

Know when to stop. Sometimes, we have to step away from the keyboard. Did your mother ever tell you to go outside and get some sun? Mine did, and only now do I see how wise this simple phrase is. By stepping away from a challenge for a few moments, we are able to refocus our efforts and come back with fresh eyes and a clear mind.

Dave went on to say something that I have been hearing at a lot of developer conferences - satisfy the customer. As each customer is different, it is up to us to delve deeper into what will satisfy them. We must look underneath the layers of requirements and the “I want” phrases that cloud our conversations. This is what separates those who paint portraits and those who take pictures. They look for what is underneath. By doing this, we can discover what our customers need truly are, and work to satisfy those. This results in a win-win situation.

Dave Thomas concluded by telling us that there is art in engineering, and engineering in art. One cannot truly exist without the other. He then left us with words of inspiration:

Be an artist
Create something great
Create something beautiful
Sign it, be proud of what you have created

The second tutorial of the day, “Using Adobe Flex with Rails ,” was very cool. Headed up by Aslak Hellesoy and B?ɬ?rre Wessel, the tutorial showed how easy it is to build a beautiful front-end to a RESTful Rails application. At ADS we are looking into using Flex to remove some of the headaches that comes with implementing AJAXY applications that work in every browser we are asked to support. Most of this great tutorial was code. You can grab it off of Google Code.

Flex on Rails Resources

Flexible Rails - Peter Armstrong
Adobe Flex - Adobe
Carigorm - Adobe Labs

WebORB - Midnight Coders
Ruby AMF - Aaron Smith

Check out the pics on Flickr.

The first tutorial of the day, “A Half-day of Behavior-driven Development on Rails,” was great. Led by David Chelimsky, Aslak Hellesoy, and Dan North, the first half of the tutorial discussed Behavior Driven Development. In short, we were instructed on:

• What problem BDD solves
• Programming from the outside-in
• Peoples and roles
• Two audiences
• BDD background

BDD, per our instructors, helps developers write software that matters. What is meant by that is that customers who will use the software will be more involved in the development process, and due to the way that they are engaged, will better understand what they are getting and how it works. In addition, by asking questions such as “What should this application do?” and “What does this part of the app do?” both the developers and the stakeholders (the audiences) better understand what the desired outcome is. That last point was stressed quite a bit. Scope creep was defined as a disconnect between how the development team and the customer define “done.” An upfront definition and agreement on just what “done” means is imperative to the success of every project.

Programming from the outside-in was an interesting point. Sponsors (or customers if you prefer) talk about what the app does, not how it works. These descriptions of functionality then become the technical specification, which in turn becomes a series of rspec tests. As rugby was the talk of the day, a rugby cup application was the example. A few of the rspec model tests included:

• “should report correct number of max_teams”
• “should create 2 rounds for 4 teams”
• “should create first round with 4 matches for 8 teams”
• “should not allow changing max teams after creation”

Now those are tests that a customer can understand without knowing any code! Plain English - life is good. Notice too that the tests don’t sound like how the application works but rather what it does, or should do. You could manually QA these as well (which some of our clients like to help out with).

The second half of the tutorial was coding. You can download all of the code we used at:

svn co svn://rubyforge.org/var/svn/rspec/branches/railsconfeu2007

One item that I learned about today which I didn’t know about was how rspec does integration testing. True to the BDD technique, rspec integration testing uses a Story format. The story that we were testing was planning a cup. Download the files from subversion and navigate to trunk -> stories -> plan_cup.rb. Very cool.

For more information on RSpec, check out the website, or see the RSpec Rails documentation for Rails specific RSpec goodness.

Check out the pics on Flickr.

Good afternoon from Berlin!

I have posted the first pics from Berlin to Flickr. Lot’s more are on the way so stay tuned!