Archive for the 'Ruby' Category

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 »