Tuesday, August 26, 2008

Building Hyype.net with Helma Object Publisher

Today, Hyype.net was launched. Hyype.net is a micro-blogging sports site. It is designed to encourage loud, boisterous, trash-talking about each others favorite teams. We have some ideas of where we'd like to expand to, but the first part is completed and live.

This blog entry is not about Hyype.net though. This is about building Hyype.net, and more specifically, about my experiences with Helma Object Publisher. Helma is a web-development framework using Mozilla's Rhino JavaScript as the server-side language.

Disclaimer: I am not an expert at using Helma. There may be better ways to organize things. Hopefully, some of the Helma guys will step in and point out where I did things the stupid way. This entry is about a newbie's experience learning the framework and building something useful with it.

Getting Started

After having struggled with installing a number of different frameworks, Helma was absolute bliss to get up and running. Inside of a minute I was able to download it, configure it, and get it running. At that time, I was presented with this:

It was a powerful feel-good moment. Not only was it easy to get up and running, but I was presented with something that was actually useful instead of some stupid splash page. This page also has links to a tutorial and documentation.

The tutorial was a great place to start, and after an hour of going through that, I felt like I knew what to do.

HOPped up on objects

At about this point, my romance with Helma began to sour. What exactly is a HopObject? Why is there 'Root' and 'Global'? Why the @#$@! do my macros work here, but not there?

The organization of a Helma project at first seems bizarre. Combined with some subtle differences in how functions work (Why doesn't renderSkin() work like this.renderSkin()?), I slowly developed the feeling that Helma was well-polished on the surface, but buggy and horribly organized. I compared it to PHP, which is about the dirtiest insult you can hurl at a Java-land framework.

And then, all of a sudden, I got it. The pieces clicked together, the organization made sense, and I was left reeling. I had to lie down for a minute until the world stopped spinning.

Here is the key thing you need to understand about Helma: it is an object-oriented framework.

That might not sound like a big point. After all, most frameworks today are built with object-oriented languages and overrun with objects. But that is not quite the same thing. Take Rails, for instance. It has a clean organization with model objects, controller objects, and views (which are probably objects too—I don't really know).

In contrast, each Helma application is one massive, amorphous object. It is like the difference between classes and prototypes. This is the type of organization that makes complete sense if you are thinking in a JavaScripty way.

One subtle distinction about JavaScript programs is that each one runs in the global object. It has no name, we never really see it, but it is there. (This was a crucial point when I was building JOMP—top-level functions are methods of the global object and need no special handling). Helma has just taken this idea and build a web framework on top of it. My master's thesis spends a great deal of time extolling the benefits of JavaScript's object system, so I was a little embarrassed that it took me so long to grock Helma's organization.

Each folder in Helma corresponds to some type of HopObject. These folders will hold the database configuration (if needed), the actions (more on those later), the methods, and the skins (html templates).

Global is the global object where all JavaScript objects live. Before I understood it properly, I had a fair amount of the skins stored there. Now, I have only a single macro. I'm not really sure I even need that. This is probably good form — global===bad, as Douglas Crockford would say.

Root is the single massive object that is the web application. This was the single most crowded directory for Hyype.net. Anything that did not clearly belong to a single object ended up here.

There is also HopObject, which serves as the parent object of all other Helma objects, including Root itself. I probably should have used this more, but this directory is empty for Hyype.net.

Every other directory corresponds to some object specific to your application. As it turns out, Hyype.net really only needed 3: Users, Profiles, and Thread.

For the rest of this article, remember that everything is owned by some object. A skin or an action belongs to some object—HopObjects are not passive lumps of data like they are in other webdev frameworks.


The core use of objects in almost any web framework is to serve as containers for data. This is easy to do in Helma. It does take some configuration, but that is pretty minimal. Here is the User configuration for Hyype.net:

_db = myDataSource
_table = user
_id = id

username = username
password = password
email = email
verified = verified
createdAt = created_at
updatedAt = updated_at

profile = object (Profile)
profile.foreign = user_id
profile.local = id

This is a little more work than it would be in Rails, but it is not too bad. It would be nice if Helma could generate a base config, but it would really only save a minute of work. Better yet would be if it could default to the same names as the DB fields. The associations are also a little trickier than in Rails, but not bad. The documentation is fantastic, however, so I was able to figure things out without too much trouble.

One note: In good Helma form, the database field names should have been in all caps. I ignored that, but it would have made the configuration a little clearer. With all lowercase, it is not as obvious which side is which.

HACking something together

Every action corresponds to a url. While there are different ways to do it, the standard approach (and the one I used) is to create a separate .hac file for each action. Here is a simple one:
res.data.title = "About Hyype.net";
res.data.selected = "about";

res.data.body = this.renderSkinAsString("about");


"res" stands for "response". The data property stores the variables that your template will need. The renderSkin methods will write out the templates.

I would have liked Rails' style layouts. If there is a built-in setup for this in Helma, I could not find it. Rolling my own was easy enough though. I did this by creating a skin cleverly named "layout". Within it, there is a body variable. Using "renderSkinAsString" I could fill out this spot and then render the layout itself.


My last project involved JavaServer Faces. Before that, it was a PHP project. They represent the two extremes. JSF is rigid and unfriendly (and, perhaps worst of all, not html). PHP lets you do whatever you like, even things you should never, never do.

Helma's skins take a nice middle ground. They don't allow arbitrary code, but they do allow you to call macros (special JavaScript functions). The result is that no code bleeds into the html. Some html did bleed into the code, however, but I managed to keep this relatively minimal.

One really cool thing about Helma's organization is that objects can render themselves. They can contain their own skins. For example, Thread has templates for being rendered as clips (displayed on the left rail), details (for a more complete view of the thread), and myClip (for the "My Hyype" page). Within the main page, each thread is rendered with 'str += hyype.renderSkinAsString(clipSkin);' The current thread is displayed on the center of the page with 'res.data.body = selectedThread.renderSkinAsString("details");'

It seems like an unusual way of organizing templates, but I found it very effective. Unlike objects in other frameworks, HopObjects know how to dress themselves.

Here is the template for Hyype.net's threads in clip view.

<div class="bb-box"><div class="ctl"><div class="ctr"></div></div><div class="pad">
<a href="<% rootPath %><% this.posterProfileHref %>"><img src="<% this.smallPic %>" alt="<% this.poster %>" title="<% this.poster %>" class="bb-img" /></a>
Posted by<br />
<a href="<% rootPath %><% this.posterProfileHref %>" class="lnk-green"><% this.poster %></a>
in <a href="<% rootPath %>main?cat=<% this.categoryName %>" class="lnk-green"><% this.categoryName %></a><br />
on <% this.postedOn %>
<div class="comm"><a href="<% rootPath %>main?threadID=<% this.id %>&pageNum=<% request.pageNum %>" class="clip-title"><% this.title %></a></div>
<% this.agreeDisagree %>
</div><div class="cbl"><div class="cbr"></div></div></div>


Helma offers a rich set of utilities as part of its core and a number of optional extensions. And if that is not enough for you, the Jala Project offers a bunch more modules. For the most part, these are well-documented and easy to use. The one time I had a problem, a note to the Helma mailing list quickly answered my question.

One problem spot I did run into was trying to include Java code in my project. For the most part, this is not needed. Rhino allows you to call Java. However, I wanted to get the MD5 hash of a string for comparing passwords. I could not call the methods I needed in Rhino, since it was ambiguous to Rhino which method I was calling.

I wrote the method I needed in Java, but there was no good place to store the class file. Instead, I put the class file in a jar and added it to the lib/ext/ directory. This was not the cleanest process in the world, especially since it is shared by all projects, but it did the job.


Once we had the application ready to deploy, life got a touch more challenging. We went off the beaten path a bit by not using Antville. Things went more or less smoothly until we tested out uploading images.

The server crashed. We reconfigured a few things. It crashed again. After several hours of research and troubleshooting, we nailed down the problem to our version of Java. Specifically, it was using GNU's implementation, which ignored some of the flags we were passing it. I still have not totally forgiven GNU.

While I think Helma is blameless for this, it is one risk of using a framework that is not as widely used as PHP, JSF, etc. Fortunately, the community is friendly and active, which usually more than makes up for this.


Helma has gotten to be my favorite webdev framework. Given any choice in the matter, this is what I'd use for a new project. Helma seems to be in active development, and I'll be excited to see where it goes from here. If you have a new project coming up, give Helma a look.

Monday, June 23, 2008

Yes, We're Open

90% of the time when I need some work done on my car, I take it to Sears' Automotive Center. This is despite the fact that they are usually unable to fix anything more than the basics.

The main reason I keep going there is that it is incredibly convenient. When I have tire problems driving home on a Friday night, they are open. If I want to drop my car off on a Saturday and then walk to the movie theater in the same shopping mall, I can do it.

In contrast, the Ford dealership has generally done a better job of fixing more complicated problems. But they are only open 9-5, and they are in the middle of nowhere. I can only read outdated snowboarding magazines for so long. Also, they charge twice as much, so I take my car there only in desperation.

Convenience Matters

This should not come as a surprise. Unfortunately, the state of many software projects out there would suggest otherwise. Far too many of them have terrible installation instructions and horrid documentation.

If you want people to use your tools, put yourself in the position of your new users. What are the pain points? Where is this confusing? You won't catch all possible problems, but the more you do catch, the more users you will be able to win over.

I've been working on XMUltra lately. My initial efforts have largely been focused on just this part -- how to make it easy for a new user to get started. I have a ways to go yet, but I think the initial public launch had much better tips for getting started than the internal documentation.

Eclipse vs. Emacs

These two have very different strengths. Emacs is the more powerful of the too, or so the Emacs elite claim. (Not being an Emacs power-user myself, I have to take their word for it).

Eclipse is decidedly easier to get started with. For one, it uses the standard key bindings, so that ctrl-x, ctrl-c, ctrl-v, ctrl-s, etc. all work as you would expect. In addition, it is decidedly prettier. It has nice file open dialogs and more or less intuitive preferences settings.

Actually, Aquamacs comes pretty close here. It takes advantage of the fact that Macs have both a command and a ctrl key, so you can still use command-x, command-v, etc like you would in any other program, but use ctrl for emacs key sequences. It also has nice GUI interfaces overlaying the Gnu Emacs versions, so you can get decent looking file open dialogs (in addition to the regular Gnu emacs versions).

But Emacs and all of its touted power fails miserably in actually being able to transfer that power. Yes, I'm sure it is much easier to write an Emacs plugin than to write an Eclipse plugin, but that is only half of the story. After I write one, someone else has to install it, or nobody but me benefits from it.

In Eclipse, I have to type in a url into a package manager.

For Emacs, let's take a look at a couple of examples of installation instructions:
  • JDEE includes steps like "Download the latest versions of Eric Ludlam's speedbar, eieio, and semantic bovinator packages and install them on your system, each in their own directory." Great.
  • HtmlModeDeluxe: "First, you must install all four modes needed. The php-mode I tested so far and which seem to work well are Turadg Aleahmad's 1.0.2 and 1.0.4. As I had several reports during the last few weeks that the current mmm-mode cvs does NOT work, I now recomment to first try..."
  • Emacs WebDev: "You will need the following packages: *psgml *mmm *generic-x *php-mode *css-mode *xxml *tidy"
Hmm... So do I have semantic bovinator installed on my system already? How do I tell? What version do I have? And, most importantly...


This is the single biggest failure point of Emacs. There are some attempting to fix this, but one really, really, really needs to be made part of the Gnu Emacs code base.

A Tale of Two Frameworks

I'm a big fan of Rhino JavaScript. Enough so that I built a JSF-based web framework for it. I spent some time looking around at what other frameworks existed.

One of the first I found was Phobos. They have nice webcasts, and it looks pretty cool. But... For one, Java.net is painfully slow to load. Some might be turned off before they ever see the homepage. But if you have some patience, you might make is as far as the download page and see this in the installation instructions: "You need to have the NetBeans IDE installed."

Wow. So in one fell swoop, the Eclipse users have already been turned away. But maybe this is just for tool support. Perhaps this will work just fine as long as Glassfish is installed. And what does the website say? <cue the crickets>

In contrast, let's take a look at Helma. Here we have a nice, prominent download link. After downloading it and following the instructions, I had Helma running with a useful admin tool inside of a minute. It even has a default file-system persistence setup in case you don't have a database installed. The first experience is lots of happy juju.

So take a wild guess which framework I am using now.

Helma takes some getting used to, but it is worth the effort. The organization is very cool... but very different. While I did some head scratching before I figured it out, I made the effort because Helma had already won me over. I wanted to like Helma, and so I spent the time to find its cool features. Also, the documentation pointed out those features for me. (And seriously... If you are a Rhino fan, check out Helma -- I actually prefer it over Ruby on Rails.)

As Simple As Possible, But Not Simpler

One final note... Sometimes you cannot make things as simple as you would like. If you are building a complicated product, it may be that a complex installation is required. But challenge every pain point. Would a Rails-style sensible default be a wise move? The answer is usually yes.

Back to my mechanic... Before Sears, I went to a private mechanic. The work was fantastic, the prices were fair, and I went there despite the hassle of driving to and waiting in the middle of nowhere.

Unfortunately, he went out of business.

Monday, May 5, 2008


XMUltra framework teamRecently, XMUltra was released on SourceForge.net. This had been the feed processing engine for Knight Ridder Digital, the online division of the once-mighty Knight Ridder newspaper company. (No, we don't make talking cars).

Although originally designed for news feeds, it was expanded for use in a number of other areas. It has acquired a fairly large number of utilities, including tools for transferring files, running scripts, compressing files, etc.

In short, it has become to feed processing what Ant is to build processes.

XMUltra is available at http://xmultra.sourceforge.net now. If you are involved in Java-based data feed processing, you should check it out. However, I thought I'd talk a little about the history of the product today.

In The Beginning...

Before XMUltra, KRD processed news feeds with a collection of Perl scripts, shell scripts, C code, and (for some odd reason) the print spooler. These scripts did their job, but they were becoming increasingly difficult to maintain. We were becoming a Java shop, and it was decided that we should have a Java-based feed processing engine.

Total rewrites tend to fail. Usually, you are better off refactoring your existing code base. In this case, however, XMUltra was a complete success. It was hailed as a triumph, not only by Knight Ridder, but even by the Newspaper Association of America.

The Architect

Wayne Weber was the perfect person to head this charge. He had a clear long-term vision for the product, a passion for technology, and perhaps most critically, an amazing mind for details.

I've thought about the best way to describe Wayne, but I think the best way is to show an excerpt of his code:

try {
// Using reflection to avoid compiler warnings for "stop" (heh, heh).
Class classObj = Thread.class;
Method method = classObj.getMethod("stop", null);
method.invoke(processorThread, null);
} catch (Exception e) {

My first thought was to nominate this for The Daily WTF. Except, it is not really a WTF. It can't be when there is a clear comment about what exactly he was doing. There was a section I left out that explained the reasoning for using the deprecated method.

More importantly, it speaks to something deeper. Wayne went through some elaborate hoops just to avoid any compile warnings. Despite the large number of classes, there were absolutely zero warnings and no methods or classes without JavaDoc comments. No one else was allowed to get away with anything less than perfection.


XMUltra was primarily designed for news feeds. Among other things, it featured a whole plugin architecture for news feeds. However, it also had a variety of extra general-purpose utilities, and gradually we began to use XMUltra wherever we could.

This is really where I first became involved. I extended XMUltra for processing classified ads. Writing new processors was somewhat painful at the time, but it was well worth it. Over time, through the efforts of the KRD team, XMUltra gathered a richer and richer collection of utilities.


There was one problem with XMUltra. It aged. Codebases become out of date if they are not maintained. And while we spent our efforts on adding new tools, we did not have the luxury of updating the core architecture.

It shows in a few areas. Built before log4j was well-established, XMUltra features its own custom logging framework. There was a well established bulk-test, but no unit-tests. When Java 5 was released, XMUltra went from warning-free to having several hundred warnings.

XMUltra seemed doomed after McClatchy merged with Knight Ridder. McClatchy Interactive was a Perl and Ruby shop, and Java applications have gradually been phased out. XMUltra is still in fairly heavy production use, but it is clear that it does not have a future within the organization.

Wayne himself has left McClatchy Interactive now. Most of the rest of the core XMUltra team was gone already. I am the last.


McClatchy Interactive agreed to let me open source XMUltra. Before he left, Wayne and I spent a couple of days cleaning up the build process, stripping out MI/KRD specific components, adding some examples, and updating the documentation. It is not in perfect condition, but it is in a form ready for public consumption.

Check it out! I hope you find it as useful as I have.

Monday, March 31, 2008


It is fairly easy to design a flexible language. You can create any object, module, class, or function you like in most programming languages. JavaScript 1.x only has objects and functions, but can mimic the other constructs easily enough. Methods in Java are fairly limited compared to other languages, but you can emulate them easily enough with functors. Objects don't exist as a core port of all languages, but in most you can do things in an object-oriented fashion -- it just is a matter of how much you have to fight with the language to do so.

The point is, all of these constructs are open. I can create as many classes, objects, and functions as I like.

This is not true of operators. Operators don't fit smoothly in with the rest of the language's design. Because of their unique behavior, they must be fixed at the moment that a program is parsed. This means that they are almost always closed.

There are some interesting exceptions, however. Many languages allow operator overloading. This allows you to change the behavior of an operator and, more importanly, it allows you to apply operators to new classes. (If Java had this feature, you could add two BigIntegers with '+').

This is only a partial solution, however. While it does let you expand the usage of an operator, you still cannot create a new one.

The Lisp family takes a novel approach to this issue by simply not having any. As a plus, the core of the language(s) remains small, clean, and elegant. But there is a trade-off. Now, instead of being able to type:

42 + 3/4;

You have:

(+ 42 (/ 3 4))

Lisp advocates will be quick to argue that Lisp's form is unambiguous, and often more concise than the infix notation that we are all familiar with. This is why Lisp people never get invited to any parties.

Scala, however, has cleverly done away operators and yet still maintained the **appearance** of them. It does this by making both parenthesis and the dot optional. As a result, this works just fine:

scala> 42 + 3/4.0
res2: Double = 42.75

Despite the appearance, there are no operators. This is essentially the same statement:

scala> 42.+(3./(4.0))
res4: Double = 42.75

The genius of this is that operators essentially become an open class. However, what happens to the rules of precedence? That is another major complication of operators. If we reverse the order, we will most likely get 3./((4.0).+(42)), right?

scala> 3/4.0 + 42
res3: Double = 42.75

Hmm. So what is happening here? Well, the answer is that Scala looks at the first character of a method. If it starts with '+', it is lower in precedence than a method starting with '*'. With some clever tricks, Scala has operators that are both open and intuitive.

So is Scala perfect? No. While it has essentially made operators an open class, it still has fixed rules for the precedence. As a result, some things are missing in Scala.

scala> var i = 4
i: Int = 4

scala> i++
:5: error: value ++ is not a member of Int
val res6 = i++
The reason for this is that the results would not be what you would expect. Consider this pseudocode statement:

x = 5
y = 7
x = x * y++

At the end of this code, you would expect x=35 and y=8. But in Scala (if the ++ method existed) it would translate to:

var x = 5
var y = 7
x = (x.*(y)).++

While Scala has made an impressive step, the problem is still not totally solved.

Tuesday, January 29, 2008

Ruby Backlash

I suppose it was about time. Ruby and Rails had been a little too highly touted, and now the backlash has begun. Zed's blog entry was the biggest slap to the Ruby/Rails communities, but there have been others.

I love Ruby. I have never found another programming language that has been as easy to use. I've played with Lisp. I've written some small utilities in Python. I've used PHP, Java, and Perl for production sytems. In terms of pure programming pleasure, the only language that has even come close for me is Rhino JavaScript.

As for Rails, I have my objections, but I have yet to find a framework that I like better. DHH hit on something, and there are a lot of frameworks out there that have been trying to copy the Rails formula. I've played with a number of others, but the ones I like best tend to follow Rails in the ease of DB access and the clean organization.

Ruby vs. Python
One common thread among the Ruby backlashers is "I already know Python". There is something to be said for this. When I started working with Ruby, I knew a little Python, but I was still just learning. If I had been introduced to Ruby a year later, it might be a different story. Python is an amazingly beautiful language, and it is hard to be wowed by Ruby after learning Python.

Nonetheless, there are a few places where I think Ruby shines in comparison.
  1. Regular expression support. I rely on regular expressions heavily. In data feed processing and linguistic work, they are a wonderful tool. Python has decent libraries, but... They feel tacked on. In Ruby, they are a core part of the language. Ruby is the only language I know that can go toe-to-toe with Perl in this area.
  2. Object-oriented syntax. This is a minor point, but Python's OO syntax has always kind of bugged me. Passing 'self' as the first parameter seems, well... pretty friggin' lame. You get used to it, drink the kool-aid, and then spend your time telling everyone that "it's not a bug, it's a feature". Ruby does not have this, um, feature.
  3. Erb (embedded Ruby). Equivalents to this exist in almost every major language these days, but the key distinctions of Erb is that it can be used from the command line. This is huge. For one example, I replaced a 2108 line XML configuration file with a 473 line erb file.
  4. Ruby blocks. Python is only getting bashed on this point because it is first in the list... The biggest thing I miss when using other languages is Ruby's ability to pass blocks of code. Blocks are closures, and this is huge. All of the boilerplate code that you can't avoid in other languages is easy to sidestep with Ruby. (Neal Gafter's proposal for closures in Java will bring the same benefits -- I hope he succeeds).
Now, to be fair, Python has some strengths as well. A real Python guru could probably add a few more, but these were the ones I noted from my Python experience.
  1. Whitespace sensitive. This is often listed as a criticism of Python, and I've never been sure why. I think there is a huge value in tying the actual logic of the program to its apparent logic. We use whitespace to organize things -- why shouldn't the computer follow suit? The arguments against this seem to be a) it makes embedded Python difficult and b) tabs v. spaces becomes a real problem. Point A seems valid, but there are a number of Python web-dev frameworks out there. They must have solved it somehow. As for B... If you open a file and edit it, but don't match the whitespace, you are getting off easy with broken code. Personally, I think it a hangable offense.
  2. No implicit returns. This is another minor point, but since I criticized Python for its OO syntax, it seems only fair to mention it. I don't like implicit returns. If I want to return something, I'll @#$! well type 'return'. I wish the rest of the Ruby community would too. It seems a bad idea to me that you are returning values when you might not mean to. What happens if others start relying on that behavior?
Ruby vs. Java/Perl
Matching Java and Perl may strike many as odd. However, Ruby combines some of the best of both worlds. On the other side, both Java and Perl have the advantages that come with being well-established, fire-tested, battle-hardened languages

What appeals to me about Ruby and Perl over Java:
  1. Great regex support. I mentioned this under Python already. Perl is king of regular expression support. I'm vaguely aware that Perl has some extras that Ruby does not, but I could not tell you what they are. The biggest difference that is noticeable is that regular expressions are objects in Ruby, which means you can set them as arguments, add methods to them, etc.
  2. Easy to experiment with. Any project I do becomes object-oriented when it hits a decent size. However, in Ruby and Perl I don't have to do so until I am ready. When I am experimenting, I can just start typing commands. When it gets a little larger, I can toss in a stand-alone function or two. When I have more that that, it is time to bring in the objects. You can't do that in Java. Your best bet then is to use BeanShell.
  3. Good support for hashes/arrays. In Java, there is some support for creating Arrays succinctly, but it is limited. There is no succinct way to create any kind of Map. In Java, you need a property file a lot sooner than you do for any other language.
What appeals to me about Ruby and Java over Perl:
  1. Simple syntax for objects. Perl's OO system is a bless-ed mess.
  2. Arrays of Hashes, Hashes of Arrays, etc. One surprising complication in Perl is getting a collection out of a collection. There are so many '$'s and '%'s that it looks like cartoon swearwords. I have to look the syntax up every time that I do it.
Where Ruby fails short of Java and Perl:
  1. Performance. Ruby is slow. Most of the time, this is not a factor for me... But not always. Once, I wrote a part of speech tagger in Ruby. I ran it on a large amount of data, and it took well over an hour to run. I ported the code to Java. The new program was 4 times the size, but ran in about 15 minutes, which I thought was a nice illustration of the strengths of both languages.
  2. Libraries. Java and Perl have a massive collection of libraries. Whatever you want to do, you can at least find one library for it. That is not always true for Ruby.
Off subject, but... Perl is the only language I know of that has not been ported to the JVM. There are JVM implementations of Ruby, Python, JavaScript, and a whole mess of Lisps. A huge number of new languages have been written for the JVM. Library support is always the key. Perl's support is every bit as good as Java's, so why would anyone bother?

Ruby vs. Rhino
These have become my two favorite languages. Both have rich metaprogramming features. Whenever I use one, I miss features from the other.

Where Ruby rocks:
  1. Blocks. JavaScript functions are closures, but it is not enough. As Neal Gafter would say, "you can't just slap a pair of curly-braces around it".
  2. Class-based object system. This is likely to change soon, but Rhino currently does not use a class-based object system. Prototypes are cool. I even took advantage of this to build a metaobject protocol for JS. However, classes are easier for programmers to understand. It is nice not to have to do the mind-shift to the world of prototypes. This is a minor point for me, but important for some.
  3. Server-side programming? Or maybe not... There is Helma and Phobos, and possibly one day we will actually get to see Rhino on Rails. Rails still seems to have more of the world's attention, but that could change.
Where Rhino tramples Ruby:
  1. JVM support. JRuby has been making rapid progress, and it could end up matching Rhino here one day. Maybe. But in a lot of small ways, JS is a lot closer to Java. Simple things like the use of CamelCase instead_of_underscores make Java programmers feel more at home.
  2. Getting/Setting unknown variables. In JS, you can get or set a property easily if you have the variable name in a string. This is doable in Ruby, but not as easily. You need to use the 'method' method and then use the 'call' method on the returned method:
    property_to_print = :bar
    f = Object.new
    def f.bar
    puts f.method(property_to_print).call

    In JS, we can do the same thing more easily:

    var propertyToPrint = 'bar';
    var f = {};
    f.bar = 42;

    This seems somewhat trivial, but it comes up surprisingly frequently.

Ruby on Rails Vs. PHP
Ruby is overwhelmingly better as a general-purpose language. PHP is overwhelmingly better as a framework-less web development language. A more informative comparison is to compare Rails to PHP. But this is not really fair either. Rails is a framework, and PHP is a language. It would be more even to pit Rails against CakePHP or Zend. The fundamental problem here is that I don't know either of those frameworks. But so it goes.

PHP is unusual. It seems like half a language and half a web development framework. Initially I felt nothing but disdain for it, but I've been slowly coming to appreciate its strengths, particularly after reading "PHP in Action".

I do miss a number of Ruby's features when doing PHP. In particular, the lack of first-class functions is frustrating. PHP has create_function, but it is less than pleasant to use. Worse, it does not work for creating methods on the fly (at least not in PHP 5).

However, when it comes to creating an initial mockup, there is no language I like better. I have a Mac, and with PHP pre-installed, I can just start typing html, embedding chunks of code where it simplifies things. It is ugly and crude, but extremely easy. The ability to get something in front of the customer quickly is tremendously useful for getting feedback.

Once the demo hits a database, I throw PHP away and switch to Rails. There is no reason you could not use a PHP framework instead, but at this point you begin to need the clean organization that a (decent) framework provides.

I only have one substantial application running on PHP, and I lost a lot of time re-inventing the wheel. However, I'm glad I did it. It was a great learning experience for me. With most frameworks, you are protected from the little details. With straight PHP, you can feel the bones of the web underneath. I made a number of mistakes in my design, but I'm a hell of a lot better web developer now as a result of having made those mistakes. Building a decent-sized website without the benefit of a framework is something that every web developer should do once.

So should you learn Ruby, if you don't already? That is up to you. If you are interested in Rails, or if you would like a language with strong regex support (and you don't already know Perl), you should think seriously about it. Don't be turned off by the backlash -- it comes from success.

Tuesday, January 8, 2008

Reinventing the Wheel

In college, I met several friends who had built their own PCs. I had never so much as opened the case of mine. As a graduation present to myself, having both a little time and a little money on hand, I decided to finally build my own machine.

It was a frustrating experience at times. Not everything went smoothly, but in the end I had **my** machine. I built it, I customized it, and I was very proud of it.

Of course, that was several machines ago. I have not bothered to build another one. My time is too precious, and it is not something I particularly enjoy doing. Let Dell do it for me. Nonetheless, I'm glad to have done it once. I'm not afraid to work on my machines anymore, and I've upgraded them frequently. More importantly, I know a lot more about what is happening under the hood.

Recently I've been cleaning up a PHP project. It was the first time that I put together a site without using a framework of some kind. I did just about everything wrong. I ignored the MVC pattern, and the code I put together is a total mess. (Well.... Maybe not total. My database setup is actually passable. It still shows a lack of understanding of PHP, but the organization there is clean -- swapping out MySQL for another DB should be a snap).

Frameworks are good. If done right, they remove the drudgery from your work. You can just focus on the creative parts. Not that this ever really happens, but it is a wonderful ideal. I will never build a site without one again.

But I'm glad I did this one. Before, I could speak at least semi-intelligently on the pluses and minuses of a few different frameworks, but I only understood them at a superficial level. Now I've gotten my hands dirty in the guts of a web application, and I'm a better web developer for the experience.

Right now, I'm working on my own framework, extending Rhino JavaScript and JavaServer Faces. It may never hit prime-time, but I've managed to get an even deeper understanding through this project. Reinventing the wheel is a hell of a way to learn about wheels.