Martin Fowler did the keynote at the end of the first day.
Quick Version: WOW. An amazing talk. Very funny, very engaging. He circles around a point, then re-enforces it several times.
He thought it was strange that he was asked to talk – since he’s never used Rails.
Then he went on to talk about what he thinks about “Opinionated software”. And how Rails is an example of that. ActiveRecord (a name He came up with!) has tradeoffs. Works great if you have control over the app, db, etc. If you have a DBA or anything like that, AR is not a good pattern for your situation. If you can make your world an ORM one, with an AR mapping, life is easy. That is the major design point behind Rails’ ActiveRecord.
Rails makes what you CAN do, that much easier.
Rails has taken AR much further then anyone imagined it could go. And it shows you what you can achieve when you have single-minded focus on a pattern / set of ideals.
The idea that one framework can solve everything, is insane. But there is a right architecture for each problem.
Rails has really shown Fowler that the AR pattern can be used in much more situations then he ever thought possible.
He also really likes the drive towards simplicity that Rails exemplifies. Java’s enterprise frameworks are hugely powerful, but total overkill. As a reaction to that, things like Springs and Hibernate grew as a response. What Rails has done is taken that drive towards simplicity and taken it further then any other framework has gone. The overriding question is “How can we make it simple?”. Simple, not applicable to all problems and situations.
h3. Rails Influence
All java groups are talking about how to make their frameworks more simple. Fowler truly believes that Rails will succeed, but even if it doesn’t it’s solved a problem that needed solving. It has lightened the other frameworks, and will keep future frameworks simple from the gate.
Something else that Rails has done is challenge the notion that Simple = “Quick and Dirty”. Previously, there was a continuum that ranged from a one week VB app, that is totally unmaintainable through to total overkill and huge framework that takes forever. Rails, on the other hand, is showing that quick can be maintainable. Smalltalk was the first language that showed that quick != dirty. Then what attracted Fowler to ruby was the greatness of Smalltalk. Speed of scripting language, but clean OO for future growth. Rails takes that to the next level – into a viable framework. Quick doesn’t have to be dirty.
Strong testing culture. Rails is very embracing of testing.
h3. The conversation between developers and clients.
Does a client give “A blue toss” what language or framework that you use to build their application? Probably not, but what rails has done is: It allows us to change the rules of how we converse with our customers. We can give them instant feedback, keep them engaged and get to the target together. You cut down the cycle time.
This is the major idea of the “Agile Manifest”:http://agilemanifesto.org/.
The essence of XP, to the creator of it, was to change the relationship between clients and coders. The hardest part of sofware development is building what people NEED, not what they want. How do you best explore what they need? Well, a quick-feedback loop. Conversations between all those involved and iterating with that in-mind.
“Conversational Software Development”
Fire, aim, fire, aim, fire, aim verses
aim, aim, aim, aim, aim, fire.
The more the customer is engaged in the process, the more able they are to express their true desires and needs. Rails helps to achieve that quick cycle time.
Rails is helping change requirements planing from a static, formal process to more of a conversation. The “Customer Engagement” Notion.
Instead of asking people what they want (because they don’t really know), just give them something, and let them see how they react. Taking the idea of requirements planing is turned all the way around in this case. This is “37s’”:http://37signals.com/ modus opperandi. Watch what people do, don’t listen to what they say they want.
Fowler is much more interested in business rules then how to make a database talk to a language. He got into software to learn more about businesses. Rails makes that “plumbing” stuff go away. You can focus on the business problem.
Rails is a shift away from the idea of a developer having to worry about plumbing first and business cases second.
On a personal note, the things he’s talking about – are really resonating with me. Business is interesting, rules on how things have to work are cool – things like writing drivers aren’t.
He has not used rails, but he has used ruby for a long time. He liked perl initially because it allowed him to write easier scripts then bash and c-shell. Then he got into Python and thought it was perfectly fine. Then he read the Pick Axe. What bothered him most about Java and Python was the libraries. He truly hopes that Ruby never has extensions that are nasty and not-cleanly designed. Blocks and closures also made him very happy. Therefore, the more Rails succeeds, the more Ruby love is out there. Then more libraries are written. Also, ruby is much more then rails.
He half-jokingly said that Rails has failed because there IS a conf for it. It’s so easy that it just disappears.
h3. Post-modern programming
The real world, both in software and nature, is a mess. Lispers look down their nose at the hodge-podge of the world, but they don’t really get to make “real” software. The real-life rules are what make software interesting.