Archive for the 'Ruby' Category

Is Ruby the new Java? (live on stage)

Twice a year the Dutch Java User Group organizes a mini conference with sessions about Java, JEE, and everything related. In spring this day is called J-Spring (which has nothing to do with the Spring framework), in fall it’s called J-Fall. While preparing for RubyEnRails 2006 I thought it would be a good idea to enter a paper for the J-Spring, for an introductory session called Is Ruby The New Java?. I was a bit surprised when my paper was accepted, and even more surprised last Thursday (J-Spring day) about how many Java people showed an interest for my session: I got the big conference hall (and it really does look big when you climb the stage), filled with maybe some 200 people. Even though I got the usual nervous questions about things like duck typing and performance, I had the impression that overall, people really liked what they saw. Apparently Ruby and Rails are hot in Java land.

And likewise, Java is hot in Ruby and Rails land; allbeit with a slightly different angle. I’m talking about the JRuby project, an interface to Java allowing Ruby code to run under a Java Virtual Machine. JRuby’s ‘holy grail’ being to be able to run Rails applications in a Java application server. At this year’s JavaOne, JRuby lead developers Charles Nutter and Tom Enebo were able to show a working Rails application running under Tomcat. In spite of their help and a lot of emails, I did not manage to reproduce their setup for a demo at J-Spring. Instead, I showed how easy it is to call an EJB from Ruby, as well as a Rails application based not on a database but on a Java web service.

You might wonder what’s the use of such an interface to Java. Like I said in my J-Spring presentation, I believe it offers some great possibilities for the future of Ruby and Rails. Once Rails runs on the JVM, it becomes that much easier to use Rails within established enterprisey Java environments. For that to happen, Java developers working within those environments need to be convinced of Ruby and Rails’ added value. And so I hope that my presentation has helped to convert some of those Java developers to Java developers-who-want-to-develop-with-Rails.

If you’re interested you can download my presentation here.

2006-06-21. 3 responses.

RubyEnRails 2006 – The Week After

It’s been almost two weeks since RubyEnRails 2006, the first big Dutch/Belgian Ruby and Rails event. I think it’s safe to say that it was a success. Over 100 visitors showed up; we had an excellent venue and six very entertaining sessions:

  • Frank Oxener (Agile Dovadi) gave a live demo of building a Rails app and integrating with Google Maps.
  • Geert Rozendom (Newminds) told about his company’s efforts to integrate Microsoft Navision with a Rails frontend (we got some frowns here from people disliking anything Microsoft; well, a lot of people use Microsoft software, so deal with it guys!).
  • Michiel de Mare (Finalist) gave a Takahashi style introduction to object oriented programming with Ruby (up to and including continuations, a brave effort).
  • Stefan Kaes told us everything there is to know about Rails performance. He did a two hour session packed with tips and tricks for measuring, tuning and refactoring.
  • Wilco Bauwer is working on IronRuby, a Ruby compiler for .Net, similar to IronPython. There’s a lot of attention for RubyCLR, but not many people have picked up yet on Wilco’s project. He explained that the difference is that RubyCLR is building a bridge between native Ruby and the CLR, while IronRuby is a complete implementation of a Ruby interpreter in .Net (see for an explanation of the .Net lingo). Again some sour anti-Microsoft faces here, but they were all silenced in awe when Wilco got Ruby to play the Mission Impossible III trailer on the sides of a rotating cube.
  • Erik Veenstra, finally, Holland’s uber Ruby guru, did a session on metaprogramming in Ruby. He showed how to implement your own attr_reader/attr_writer methods, and, one step beyond, the road to creating DSLs with Ruby.

All in all it was a great day, fun to organize and a pleasure to meet so many Ruby and Rails enthousiasts at once. We should do this more often! Next time, we should maybe have separate Ruby and Rails tracks (most people want to do either Ruby or Rails; a shame really). And even though Huis de Voorst was a splendid venue, a more central location would perhaps be easier for most attendants. And we should have more sessions, and more advanced sessions. And onsite wifi so people can blog while they’re there. And less xxxl-sized t-shirts (there’s still a few left!). And, and, and……

(The presentations can be downloaded from, but they’re Dutch except Stefan’s. Photos on Flickr, tagged rubyenrails.)

2006-05-30. One response.

A Truely Historic Rails Conference

For some mysterious reason, there seems to exist a correlation between the temperature outside and the amount of entries on my blog. A sudden and long-awaited spell of sunny weather has been making Holland happy for more than two weeks now. In the evenings I am faced with the choice between sitting outside for a little longer, glass of chilled wine in hand, waiting for the sun to set and the blackbirds to start singing — or sitting inside, behind the computer, working on my blog. What a tough choice.

It’s good to see the weather’s changing though, from downright hot to a temperature better suited for, let’s say, a conference. One week from now we’re hosting RubyEnRails 2006, the first major Dutch/Belgian Ruby and Rails event. Besides Dutch Ruby guru Erik Veenstra, some real-life Rails cases, and Wilco Bauwer presenting his Ruby-on-DotNet compiler, Stefan Kaes is doing a two-hour workshop on Rails performance. And then there’s the Rails introduction workshop Remco and I will do, coding a simple photo album application live to show how quick & easy it all is (that’s the plan, anyway!). Over 100 people have already registered. It may not be London, Chicago or Vancouver, but we do have the most historic venue of them all: a 17th century Dutch castle.

Huis de Voorst

2006-05-11. No responses.

Calling All EJBs — From Ruby?

After installing and playing with JRuby a few days ago, I started wondering if it would be possible to access an EJB from a JRuby script. After all, the Java code to call an EJB is purely client code, only communicating with an application server over an HTTP-like protocol (HTTP-like in BEA’s case, anyway). At my current project, the OptimalJ team generates all their domain code and delivers business services around that in the form of session EJBs to us, the web frontend team. We’re using BEA WebLogic Portal to code the frontend. Now if we’d have EJB access from JRuby, and Rails on JRuby (which seems to be only a matter of time), I guess we would be able to build a frontend like this in Rails. There’s just the tiny matter of convincing the company’s enterprise architect, who’s already sick of hearing me talk about Ruby and Rails.

Anyway, to the code! To my surprise (after 6 years of experience with EJBs, anything EJB-related working instantly comes as a great surprise) it was just a matter of JRubyfying the Java code that you would write to use an EJB. It just works, there’s nothing more to it. Here’s an example of the magic code:

require 'java'
include_class 'java.util.Properties'
include_class 'javax.naming.Context'
include_class 'javax.naming.InitialContext'
properties =
properties.put(Context::PROVIDER_URL, "t3://localhost:7001")
context =
home = context.lookup("business-ejb-jndi-name")
business_ejb = home.create
result = business_ejb.someBusinessMethod(parameters)

Okay, here’s some small print. The example works on a BEA WebLogic application server. For another JEE application server you’ll need to fill in the correct InitialContextFactory class name. Fill in the JNDI name for the EJB after the lookup call. Also, before running the script, you’ll have to put the right libraries in the CLASSPATH environment variable. For example, for the BEA server I had to include weblogic.jar and the EJB client jar containing the home interface to the EJB. But once you’ve figured that out, it should work; I got it to work on JBoss as well as BEA. Consult your local Java guru if necessary.

I’ve put all this in a JRuby module (to be downloaded here), which enables you to write just this to call your favourite EJB:

require 'rejb'
business_ejb = Rejb::ejb("business-ejb-jndi-name")
result = business_ejb.someBusinessMethod(parameters)

I’ve been feeling very happy over the last few days, even though there’s no Spring in sight. Must be the summer of Ruby that’s coming…

2006-04-13. 4 responses.

Rails Team Ends Second In Dutch Development Contest

In Holland we have a yearly development contest called “Development Tools” (formerly RAD Race). In two days, several teams consisting of two coders build an administrative application according to fixed requirements, with database access, forms, reports, the works. The contest was originally organized for 4GL RAD tools, but in recent years Java teams have entered the competition. Without too much success though, for no Java team has up till now managed to beat the 4GL tools. This year, for the first time, a Rails team joined up. And not just any Rails team; my co-bloggers from ““, Remco van ‘t Veer and Michiel de Mare were in it. Today the results from the contest were published, and guess what — Remco and Michiel came in second! They beat all the Java teams; first place was for the CrossmarX Application Engine. Congratulations to Remco and Michiel, and to Rails of course!!

2006-03-29. One response.

How Java is Ruby?

Following up on my recent post on Ruby and Rails’ enterprise-readiness, we might want to rethink any strategies comparing or opposing Ruby with Java. Don’t get me wrong: Ruby is a breeze where Java is a mouldy draught; Ruby is a butterfly where Java is an ostrich; Ruby makes you smile where Java is often a maniacal grin. But also they’re both gusts of air, both have wings, both evoke emotion. Both are object oriented languages, both have classes, and methods, and instance variables, and structured in-code documentation, and closures (more or less), both are pass-by-reference-by-value, both have apis for Lists and Maps and Files and Regexps… The list goes on and on.

Most Java coders that are first introduced to Ruby recognize a lot of things; and what they don’t know, still feels like what they’ve always wanted. There is the new syntax to learn, and so many new apis, and Ruby’s coding standards differ from Java’s — but let’s not overreact. If you’re a good Java (or otherwise OO) programmer, you will easily pick up Ruby.

All this goes to say that the introduction of Ruby and Rails in the (Java-oriented) enterprise must not be hindered by arguments like “We have already invested so much in Java, we don’t want that to go to waste.” If you have invested in a Java infrastructure, in Java-skilled developers, you have already invested in Ruby and Rails. You have (hopefully) trained your developers to understand object orientation, as well as things like MVC architecture, test-driven development, standards-based programming. Java is but a tool — or at least it should be. Ruby just builds on that.

The same goes for the Java-based infrastructure. Investments there aren’t wasted either. The time will come, sooner rather than later, when Ruby and Rails will neatly run inside a JEE application server. We will be able (if we aren’t already) to develop web frontends in Rails, talking to JEE business components, message queues, connectors, web services, data sources and what not. We will be freed from the restraints that Java forces upon frontend developers, with its xml and pojos and faces and struts.

Let Ruby and Java blossom in the enterprise — together like a daisy and a rambler rose!

2006-03-28. 3 responses.

Ruby and Rails Get Enterprise-Ready

In the recent, rather entertaining discussion between James McGovern and the rest of the world, about Ruby and Rails being enterprise-ready or not, a lot of emphasis was placed on the speed of development that Ruby and Rails may offer. Anne Zelenka correctly stated that speed of development isn’t all that important in an enterprise environment.

In a way it is sad, but big enterprises, large corporations, might not care much whether an application could be developed with Rails in half the time it would take with Java. Development (I’m including design here) is only a small piece of the entire implementation of an application. There’s functional testing to be done, training of end-users as well as support staff, setting up and maintaining the technical infrastructure for development, test, acceptance and production environments, data conversion, and overhead costs like project management, meetings, planning, the works. Things you can happily do without (more or less) if you’re a web startup, but not so for your average enterprise. (I’m not saying an enterprise couldn’t cut back on them, but most just don’t or won’t — it seems to be a given when you’re entering the enterprise world). And then of course there is application maintenance. Long ago I learned that, as a rule of thumb, application maintenance costs 20% of application development — yearly. That’s 20% of the costs of design, development and testing. Which means that, if you keep developing new applications, your yearly planning slowly fills up with maintenance work.

Instead of just focussing on the amount of development time you might save on, why not focus more on the reasons why development time can be saved on? For example, one of the reasons developing in Rails is so much faster, is the principle of ‘convention over configuration’. I think that might hold some attraction, as it is something that many enterprises are already trying to achieve, for instance with software factories: standards based coding. As a by-product of this, you need less code for your application, which also means less code to maintain. Another example is the shorter build cycle (at my current Java project, the “record” for longest build time stands at 1.2Ms). And how about prototyping? You might actually sit down with an end user and prototype view, model and controller in a Rails application. I’ve never seen that done properly in a Java environment. Prototyping often results in better user acceptance. Or test driven development, which in Rails is not an afterthought as it is in Java. TDD can prevent many unnecessary bugs, so also means less maintenance. (At the moment I am on a project where unit tests “are not needed because all code is generated with OptimalJ.” Yeah right.)

If Ruby and Rails can solve problems that enterprises currently have in their development environment, and save time and money in the process, they could become more interesting for bigger companies.
Of course, there are also reasons why enterprises may not want to use Ruby and Rails — but that’s for another post. Or maybe I should leave that to James McGovern.

Disclaimer: I am neither an enterprise architect, nor a thought leader on that subject. My opinions are based on my work for Dutch enterprises, which may not be comparable to U.S. enterprises. And I’m talking primarily about developing web applications, where Rails excels.

2006-03-27. 8 responses.

Can You XML a DSL, And Would You Want To?

For me, one of the principles of programming has always been: “Use the programming language best suited for the job; and if there is none, create a new language.” I believe this is directly related to the idea of Domain Specific Languages (DSL) that are all the rage right now. Creating a new language that is best suited for a specific problem domain: that really says it all, doesn’t it? Still, it’s a quote that I first heard when I started my programming career, which was about twenty years ago — and it may very well be even older than that. How did people go about creating a language back then? (I mean parsing and compiling or interpreting it, not designing the language.) And how do we do it today? Has anyone ever asked the questions:

  • “What programming language is best suited for implementing another (DS) language?”
  • “At what point will creating and maintaining a new (DS) language result in less work than using a second-best language for solving the problem?”
  • “Can we describe a new language that is meant specifically for creating DSLs, a meta-DSL?”

I was led to these questions after reading a post by Obie Fernandez on his blog. He describes how his team created a DSL that describes a data model. Depending on its context, the DSL code will either create a table creation script, a script for creating stored procedures, or XHTML code for display in a browser. His description is not all too elaborate, I must say, so maybe I’m missing some interesting feature here. But it sounded to me like nothing more than doing some data transformations. Wouldn’t XML and some XSLT scripts have done the job here? Also, if you create a DSL for this, you have the added disadvantage that you’ll have to maintain the DSL implementation as well (even if the DSL is easy to write in Ruby). Three DSL implementations even, one for each context you can use. The idea of contexts is nice, until you need to implement an extra feature in one context that will conflict with the others. Unfortunately, Obie never got round to answer this question that I put in my comment on his blog post.

I believe a lot of XML code written out there could actually be called a DSL in its own right. Someone wrote the other day (in one of the 40,000 blogs I try to read now and then) that XML is Java’s tool for creating DSLs; and I agree to some point. To some point. I mean, I write XML every day (in the form of JSPs), so by now I’m used to writing conditional statements and loops in the form of XML tags, but it’s hardly elegant if you think of it. It’s actually plain ugly. (And if you think that’s not ugly enough, go take a look at the next step in XML programming: Jelly, executable XML. Yuck!)

Mixing data and code is (in principle) a bad thing, I think; whether you start of with data and mix in code (like in XML) or you start with creating a DSL and add in data (like in Obie’s example). I would prefer to to put the data in XML (or Yaml, or a database, or some other form of structured data) and keep the code separate. This will also give you better insight whether you’ll need to create a DSL for processing the data, of if you can simply use XSLT.

P.S. “Simply use XSLT”? Did I just write that down? I take it back! I can fully understand how having to write XSLT can drive any sane person to code his own DSL. In assembler, if needs be!

2006-03-23. 3 responses.

Start Your Own Campfire

After marvelling over the idea behind Campfire, I wondered how easy Rails would make it to start my own campfire. After all, the concept doesn’t seem to be all that complex: log people’s messages and feed them back to all the other people in the same chatroom. There’s some bells and whistles around that, like logging in, creating your own room, inviting others to join your room, etcetera. But I think, if you’ve got the basic concept covered, the rest will follow easy enough. And that basic concept didn’t proof to be all that hard to build — with Rails.

First, I created a very simple database table to hold all messages with a timestamp and username for each message. Then I created my Rails application, with one model class for the messages and one ChatController. ChatController contains an index method that initially reads all messages from the database and passes them and a fresh new Message object to the view. There’s a create method that will store a newly entered message in the database. And finally there’s a refresh method for periodically refreshing the div in the view that contains the message log. The index.rhtml displays the messages using a _messages.rhtml partial that is also used for refreshing them, with a periodically_call_remote call. To add some more Ajax, newly entered messages are sent back with a form_remote_tag, so the visitor never sees the screen blank for server requests.

That’s it, really. Nothing more to it. For the basics, anyway. I could think of a ton of features I’d like to add. First thing I’ll do is to add authentication; then put it on DreamHost and tell my colleagues and friends. We won’t be needing Campfire’s services, thank you very much. Blame Rails for making it easy.

Download the source here: Kampvuur (Dutch for Campfire) 0.1 BETA

Kampvuur screenshot

2006-02-21. One response.

Ruby’s Exclamations: A Dream Come True

After writing the post about exclamation mark methods in Ruby yesterday evening, I couldn’t get to sleep (lesson learned: don’t go straight to bed after blogging). My mind was still churning away over the whole issue. And just before I fell asleep, in the short period of time when a lucid state of geniality bordering on insanity sometimes befalls you, when either the greatest ideas or the worst flops come to you — I dreamed up this code.


class Ruby
    S = ['yes', 'no', 'absolutely not',
        'of course', 'you already know', 'of course not',
        'who knows?', 'I guess so...', 'I guess not...',
        'maybe', 'perhaps', 'certainly not',
        'positively so', 'try google', 'who cares?',
        'why not?', 'the answer is in your heart',
        'we may never know for sure']
    def self.exclamation_mark!
        @@r = rand
    def self.is_redundant?
        q = @@r * S.size

puts Ruby.exclamation_mark!.is_redundant?

2006-01-23. No responses.

« Prev - Next »