Xavier Defrang

Here we go for a little round-up of the sessions I attended today...

Doc Searls delivered a very entertaining keynote covering a very wide spectrum of issues ranging from the transformation of vocabulary to free speech. The bottom line was: get up now and stand up for your rights!

Robert Scobble made a terrific job at putting everyone back to sleep. After being introduced by the host with the famous "Microsoft has no taste" Jobs quote, he tried to play it cool with a live IRC feed running on the big screen. But this presentation was plain boring: did anyone in the audience really needed an explanation of what blogs and PageRank are all about? Please, this was no Visual Basic Developers conference...

Michael Heilemann's lessons from the Kubrick template was a talk on open source design. The session was actually a bit like the template itself: not really bad but nothing groundbreaking neither.

Dina Mehta gave an uplifting talk about the rise of social and collaborative software (the combined use of Blogs, Wikis, VoIP, mobile messaging, ...) in India in the perspective of the crisis management and business development.

Ben Cerveny's presentation about games as dynamic systems model was thought provoking but maybe a bit too fast-paced at some points. I don't if it's because he was anticipating the lunch break that much or if my brain was just too slow.
Citing Nintendo as an example, Ben said that as games are getting closer to reality, the subsequent player boredom will leave even more room for abstraction and surrealism just like when photography 'killed' painting. He also gave some interesting insight about the collision - which is bound to happen - between virtual and real economies.

Jimbo Wales told the audience about the wisdom of Wikipedia and other projects from the Wikimedia Foundation. Some pretty interesting figures were shown regarding the demographics of Wikipedia editors and Wales also provided some explanation about the associated quality insurance and community processes. A very good example of how a loose system managed with a flexible policy can end up producing quality.

I was a bit disapointed by the talk about Goal-oriented and Persona-based design as the resulting overall process seems very linear and doesn't leave a lot of space for client interaction. There were some interesting ideas which could be especially useful when designing task-oriented user interfaces but I think I'll stick to the wireframe and mock-up iterative design approach.

Jason Fried of the 37signals & Basecamp fame delivered a really brilliant speech about building successful projects with small teams. Here are some random notes I took:

• Small teams is about less for more.
• Get rid middle/muddle managers to avoid distortion and put everyone on the frontline
• Go for the simplest solution to lower the cost of change
• Say no by default and let features remind themselves
• Don't add, think about improving first
• Every decision is temporary
• Get your software out of the way of the user
• Functional specs are political documents aimed at blaming people
• No problem till it's a problem
• Big design upfront Vs Making decisions when you have real information

Too bad, I still can't see how that kind of attitude can work with small teams embedded in larger structures ridden with system dependencies, politics, ass-guarding, job protection and fear.

David Heinemeier Hansson's Ruby on Rails talk was a nice explanation of the origins and design philosophy behind the best web development framework to date. Some of the highlights:

• Being quick without getting dirty
• Be it PHP or Java, it's not fun to keep fighting a language or an environment. Most programmers are not happy because they have to deal with harassing technology
• Investment to get started is key to success
• No academic aspirations, Rails is no revolution: patterns deja-vu (MVC, ORM, ...), shared-nothing architecture (PHP-like), familiar open-source foundations (Apache, Lighttpd, MySQL).
• Old ideas, new context: Taking a good idea in Java to make it a great idea with Ruby.
• Convention over Configuration: optimize the common case. It's a trade-off, flexibility doesn't mean that everything should be equally hard.
• Choice is overrated especially in programming stack, flexibility is not free. Apple gets this. Trade some flexibility to earn a lot of productivity in return.
• Languages of love, platforms of passion. Unlike Java, assume competence; Attract programmers caring for the craft; Motivation determines productivity. Programmers who shoot themselves in the foot with the gun the (dynamic) language offer them would be bad programmers in any language anyway.
• Ruby on Rails is the sum of all its parts and the philosophy around it
• Culture clash with 'Enterprise Developers' (That won't scale! But is it mature! Nobody ever got fired for...). Java people just say what C++ folks said when Java came out.
• Ruby on Rails just steal the ideas from the 'smart guys' and give them to all those 'green programers' to play with
• Bottomline: no single, big innovation

This conclude my report of the first day of Reboot!

I'm taking off tomorrow morning to spend a few days in Copenhagen and attend Reboot. The talks I anticipate the most are:

• The Social and Psychological Sides of Software Architecture by Peter Lindberg
• Doing Big Things with Small Teams by Jason Fried of the 37signals fame
• Ruby on Rails: Tech, Necessity, and Passion... or why Developers with a cause are more productive

You can expect some almost live feedback but no MacWorld-like fanatic coverage... So, no "18:29:43CET - David takes the stage wearing a 'Java Sucks' sweater and a denim". ;)

(As Ruby on Rails got its 3rd slashdotting in a couple of months or so, it's time to post that long article which has been floating in an open TextMate window for way too long...)

In what I believe is yet another desperate attempt to attract eyeballs to his - far from popular - Java framework, Geert Bevin has recently fueled the fire of the already overheated J2EE Vs RoR discussion.

If it looks like most Railers have a J2EE experience (and a terrible one), the opposite doesn't seem to be true. I'm actually wowed by the lack of programming culture the average (and even some seasoned) Java developer shown on that particular TSS thread. It's just like any piece of code running outside of a JVM is not even worth looking at... what a terrible mistake!
So, as a daytime Java web developer and RoR night owl, I'll try to address some of the bogus statements (FUD?) and issues raised in the TSS discussion.

Claim: RoR does create a lot of Ruby and HTML files, it's a code generation based framework.

No, it's certainly not. Rails uses code generation to 1) make sure that you don't have to think about the organization and configuration of your project and 2) help you kickstart your application (scaffolding). Most of the generated code will be rewritten or removed in the final product, it's just there to help you get results quickly, not to replace you. Rails just give you a CRUD interface for free, but it won't in any way prevent you from overriding any of these reasonable defaults.

Claim: Ruby is a scripting language, it was not designed for large applications.

As that statement is usually not backed by any kind of reasonable argument, I'll assume that what makes Python/Ruby/... a useless language for your "Enterprise" (yet another buzzword pushed by Sun's marketing monkeys) needs is that it lacks an IDE which supports refactoring, has no fancy debugger, has no built-in adapter for your COBOL backend and last but not least: it doesn't scale.

Some people think that using scripting languages means that you'll have an unmanageable code base scattered in a bunch of files loosely tied together using some character-level include mechanism. If this may be true for PHP, more advanced languages like Python or Ruby have very powerful concepts of introspectables modules (also acting as namespaces) which are far superior to Java packages.

Did you ever wonder why were you using a debugger? The main reason is probably that your environment is so overwhelmingly complex that you have no idea what's going on if something breaks. Ruby on Rails encourages simple, terse, modular and test-driven development in a way more than an order of magnitude easier than what Java has to offer. If you never wrote web apps in anything else than J2EE, I promise you can't even imagine what I'm talking about. The request processing pipeline is also much more straightforward and thus easy to troubleshoot. The use of WEBRick as a development server and the breakpoint framework used with a Ruby interactive console provide all the tools and information you need to troubleshoot your application.

Most of what you use refactoring for in the Java environment is not really an issue in a dynamic language where you can rely on the good old search & replace (followed by a regression test of course).

In 2005, the choice of a development language and framework shouldn't depend too much on performance issues. In respect to the separation of concerns principle, I firmly believe that performance is now out of the scope of web applications development, it's more of a system issue. If scalability is the first thing that pops to one's mind when looking at a new technology, the he suffers from severe premature optimization syndrom. A Rails application is independent of its running environment, the way the framework was built allows you to choose the right runtime configuration for the task to accomplish and load to sustain, from pure Ruby with WEBRick, Apache+CGI, Apache+mod_ruby and even Lighttpd with a cluster of FastCGI application servers.

If the gentle folks in Javaland were really taking care of performance issue, they would still write C++ code, wouldn't they? ;)

Why did so many people switched to Java back in the late 90ies? What did Java offered more than C++/VB/Delphi/...? A richer object model? Better error handling? Better libraries? Sure it was a slow donkey but It was just a better way to develop so that's why they traded off performance for simplicity. (yes, Java 1.1 was still simple) So why should I bother about ActiveRecord benchmarks if it makes me write better code and build better applications? We're talking about web applications here, I'm surely not going to write an invoice collecting process for a company with millions of customers using ActiveRecord but this kind of process has nothing to do with web applications... and maybe even with ORM at all.

I can't figure how Ruby could be any "more" object oriented than Java or even Python as in Python everything is an object.

The anwser is as simple as:

(-2).nil?   # -> false
5.times { |i| print i }   # -> 01234 

Now compare that with the mess of int type Vs Integer class in Java...

The purity of the object model is not a toy, it really helps to build flexible and powerful APIs close to Domain-Specific Languages and it spares a lot of the troubles and verbosity inherent to an incomplete object model (Java's built-in array type, anyone?).

Just have a look a the Pickaxe Book chapter titled: Classes and Objects. You can also have a look at this catalog of design patterns implemented The Ruby Way...

Claim: RoR favors the use of code embedded in HTML. This is an old-fashioned approach that Java is moving away from as embedding code in the View is considered bad practice.

This is certainly the most criticized thing in Rails. RoR uses ERb to allow developers to benefit from the expressiveness of Ruby while keeping a terse syntax. Java is a terrible language for manipulating strings and that's basically what web presentation logic is all about. That's why plain JSP is considered evil, because simple formating details can't be implemented without involving extra complexity and useless code bloat.

Now please tell me which one of this code snipped is evil:

Now what's the difference? Except that one version is less verbose and much readable than the other one...

Come on, JSP custom tags are nothing less that code packaged with an XMLish unreadable syntax and burried under a bloated API.

I'll be kind enough not to show an example of RIFE's templating language as it's unbelievably ugly. It looks like it's been designed after COBOL data declarations...

Now if you say that RoR's views are evil because they use real Ruby (something which technically speaking is "code") and not some dumbed down microlanguage, then I hope for your safety that your favorite J2EE book author is not going to tell you how great it is to jump from a bridge...

What about debugging? There's no IDE for Ruby.

Using WEBRick as a development server helps a lot, the log/development.log file offers plenty of useful information and last but not least, breakpoints allows you to interact with your model on the fly.

I would also add that when dealing with a fully dynamic and straightforward environment, the need to sit in front of a debugger is far less important than when a NPE pops up somewhere in a Tomcat > SiteMesh > JSP > OGNL > WebWork > XWork > Hibernate stack...

IDEs are in no way a mandatory tool to produce good code in all languages. Having a good and smart text editor does obviously help but when most of your attention span stays focused on the model of your application rather than in lost somewhere between the application server, the framework and the language you use to implement it, the need for an IDE is not as important...

Look at Monster/Dice/StepStone/... there are no Ruby on Rails jobs whereas I can find gazillions of people looking for Struts/JSF manpower

Were there a lot of Java jobs 6 months after its debut? I don't think so. There is a flourishing and healthy market of very skilled freelance developers available for hire. Don't worry guys, they are not going to take your beloved Enterprise Java job, no manager will bet on RoR as it is now, that's exactly why it's the right time to start working with it, it just gives you an edge over the competition.

Howard Lewis Ship, architect of the Jakarta Tapestry framework, sums it up very nicely: "it's natural to be a little scared of new developments. It's painful to think that your exclusive, hard-won skills may be even a little bit obsolete". No wonder nobody reacted to this quote...

Here are some (rather random) thoughts about the buzz surrounding the soaring popularity of Ruby on Rails:

On Rails and Java

Some people seem to be very irritated by the recurrent Java bashing going on in the Rails community. The whinings of the Java folks have dramatically increased as Rails was casting a larger shadow (well, at least in some popular media) on existing and well-established Java web frameworks.

So why is J2EE bashing so popular out there? The explanation probably lays in the demographics of the Rails world. A lot of RoR users are still stuck writing enterprise Java to pay the bills and they know how painful it is to build and maintain thousands of lines of Java/JSP/XML. For this type of developers, Rails comes as a real pain-relief, they just feel like doing real web development again using a tool that makes sense and narrows the spectrum of problems you've to deal with to help you focus on your application's domain. That just makes them even more frustrated and angry at all these clumsy tools which are forced down their throats by managers to accomodate average developers needs.

The recent Trails video walktrough just showed that J2EE zealots were definetly not getting it : the What is as important as the How. It's not even fair to compare that maelstrom of XML scripts, annotations in code generated with bloated dialog boxes, microlanguages and deploy-n-reload cycle to the purity, elegance and instant gratification Ruby on Rails offers. By the way, their focus on scaffolding is torn into pieces in this post from David HH much better than I could have explained myself.

On Rails and Python

Simply put: you can try to stack up as many existing Python framework as you want but there's no way a Python on Rails can be as elegant as the real deal.

I consider myself a real Pythonistas (hell, I even have my name printed in a nice O'Reilly book!) and I've never thought of Ruby as attractive because of its syntax I (still) find a bit too sweet. Even the extra features available in Ruby's rich object model do not make it worth learning for a seasoned Python programmer. But now that there is a killer app for Ruby which appears to square the circle of web development, can you think of a better time to look at it?
Unfortunately, I never used Python for serious web development because of the lack of reasonable framework backed with a proven, widely adopted architecture. I looked at a lot of Python frameworks but I just never felt them. Rails provides all that and makes a fantastic use of all the nice features offered by Ruby. That's why Rails exists as it is. And it's because It's written in Ruby. There will never be anything like it in Python, PHP, Perl or Java just because language matters.

On Rails and PHP

I predict that a lot of high-profile PHP developers will soon or later switch to RoR. As a frustrated Python-lover writing object-oriented PHP code, Rails really fits as the best-of-both-world solution.
For a couple of years or so, there was a movement in the PHP community to try to bring it to the next level by adopting patterns and more advanced development practices. This was great but the evolution was way too slow on the framework side, a lot of energy being wasted trying to built silverbullet CMSes instead of focusing on a more lightweight approach. Forward thinking people like Harry Fuecks worked really hard to raise the bar but even with its new Java-like object model, PHP still lacks a decent framework (which PEAR is not). With the "elite" switching to RoR, I hope PHP won't go down the slope and remain some sort of newbie language for quick development of web applications.

On Rails and the Hype

I can understand the frustration of some framework designers who, after years of hard work, still haven't seen their baby get the momentum RoR currently has, only a few months after its inception.

This kind of adoption rate is not that common for such a framework, it's even more surprizing that its written in yet-another-language. So why did thousands of developers jumped in the train so quickly? The major point is that Rails was already proven technology before it went public. From day one, Rails had the benefit not to look like yet another super nice framework with an empty wiki page begging for big names to show up.

The exponential learning curve coupled with the instant gratification factor also leads to faster adoption. Just have a look at any "quickstart" document about a random Java framework and you'll have to get through pages of mindless setup procedure and this is certainly not the kind of thing you'd do for fun on a rainy sunday afternoon...

And what's wrong with the Hype anyway? As long as you can back your claims with facts, measurable results and working code, I don't see what's wrong with surfing the Hype. Sun has the marketing, David Heinemeier Hansson has the attitude.

The productivity boost offered by Rails is similar to what I experienced when switching from C++ to Python as my main development language. Everything is so simple and natural that it feels just like your own framework you would have grown yourself after years of trials and errors. It's so great to finally get your hands on a framework which is primarly designed with simplicity and elegance in mind instead of trying to show up as a Design Pattern gallery. The very experience of its author working closely with designers and web standards can be felt when using the framework. I totally share David's vision of what software construction should be like and I really thank him not only for the great software he makes but also for standing up and speaking out against the tyranny of bloatware.

And to those who still think it's a toy or label Rails as a RESTful CRUD framework (for the sake of buzzword compliance), please skim through the API...

From the clueless wannabes department :

"struts4php is an application framework for PHP which is designed with the MVC pattern. It is the link between the persistence layer and the presentation layer of your application. The idea behind struts4php comes from the already known project Apache Struts. The usage of struts4php is very similar to the Struts of the Apache project. For developers who already know the Apache Struts it's very easy to learn how to use struts4php. "

Holy crap, they did it... Let me highlight some of the core features of this brilliant port :

• The framework will happily parse a bloated and redundant XML configuration file for each and every page request so you don't have to restart your application server...
• The central piece of this enterprise grade framework is the aptly named ActionBanana "controller component" (they probably meant "dispatcher component" but let's give up on nitpicking)
• It relies on the Smarty templating engine (oh, I thought PHP already was an embedded language)
• Yes, the completely useless ActionForms are there too. Thanks to struts4php, You'll be able to use the sacred word "Bean" when talking of your PHP project with that Java developer sitting next door that you secretly wish you were.
• Last but not least : "struts4php is designed for PHP4 and so it does not make use of the new object oriented features of PHP5.". Sounds fair enough for a full object-oriented framework... who needs exceptions anyway...

I just don't get it... who has enough time on his hands to write a port of the worst web framework ever made while completely ignoring the features of the target platform (ie the sandbox-based architecture of PHP)?
And they're so proud of it that they bought a f*cking domain name for it!

It's high time people stop aiming at the Java-way when trying to design or build "serious" software unless they really want to shoot themselves in both feet.

For the last few days, I've been playing with Rails web framework and it's really worth the hype.

Not only the framework gives a simple and effective answer for every letter in MVC, it also offer lots of valuable goodies. All the small helper functions it provides show a real expertise and experience in the area of web development.

Instead of trying to give generic (and hardly usable) answers to questions which were not even going to be asked, the developer just feels like the framework just sit down here ready to help you anytime with some very advanced functions (such as link_to_unless_current or the built-in support for Markdown) which you can use straight out of the box...

It's actually so easy to bridge a database to a web front-end with Rails that one could think of it as an object publishing framework like the dead on arrival Zope, but with nearly no learning curve.

The only important thing it currently lacks is built-in support for i18n and you really need that if you aim to build applications in multilingual environment like Europe. So, let's hope this issue is already on David's radar and that it gonna make it for the upcoming 1.0 release.

It makes me really wonder about the sanity of the whole IT industry when a brilliant lone danish developer gets right what legions of pattern-fueled Java architects are not even close to achieve despite the marketshare of their platform...

Holy cow! Carl is back into blogging!

I should be sorry for my own lack of update to this blog but I've been way too busy with other things like just having a life... and being quite busy with Scarlet One.

MSFT has launched a developer friendly blog supposed to increase the level of communication between the guys responsible for their bloatware and actual people trying to solve day-to-day problems. This ugly-ass (but supposed-to-be-hip) blog demonstrates how excellent these guys are at building state of the art web apps as their source proudly displays a groundbreaking MS_POSITIONING="GridLayout" as a body element attribute. Way to go folks!

Ok that's probably standard zealot nitpicking but it's crap anyway and I don't feel like argumenting today.

Absolutely cheesy web standards jokes. Stupidly fun!

On the lack of updates : Boups Radio has just relaunched!

Expect some improvements in the upcoming days. I'm still not satisfied by some things here and there.

People expect developers to deliver cleverly engineered applications that are bug-free and that works. But when will web developers finally get half-decent HTML from all these cow-boys who call themselves web designers? The time they "earn" using their WYSIWYG is lost when it comes to script and template integration. They can't imagine how rewarding it is to crawl their obsolete table-based layouts and their clueless span tags. It's just like your BMW mechanics was using Lada spare parts...