Interface21 Followup

Since the conversation has become public, I think it's only fair to mention that Rod and I had a pleasant and productive chat on Friday about the issues raised in our back-and-forth. He graciously apologized for his tone and I repeated that I had a lot of respect for him.

We're going to look into how I might contribute to Spring and what might be possible in bringing our two companies closer together on common interests.

Rod lived up to his reasonable and knowledgeable reputation, and I'm happy that whatever unintended rancor may have arisen, it is not an obstacle to working together for the benefit of all.

Now where did I put that Kumbayah MP3...

Good things sometimes come to those who sit patiently: Halo 3 review

Having finished Halo 3 a scant few minutes ago -- and having taken yesterday off work in order to play uninterrupted by annoying responsibilities -- I figure this is a great time to write that crappy game review I've always wanted to write. So here goes!

Warning: There be spoilers ahead. If you care, come back here after you get a life.

Go ahead, I'll wait.

Hmm.

Everybody else ready? Let's begin.

I see no real need to start off in the standard review fashion of rehashing the game's history, the previous two entries in the series, or the jaw-dropping amount of money it's going to make. You know all that anyway if you're reading this. If you don't, allow me to summarize for you:

Microsoft buys small game developer, invests tons of money, and game developer creates better-than-average first-person shoot-em-up on Microsoft's somewhat dodgy console, singlehandedly legitimizing its existence.

As I write this, Metacritic has collected 33 "professional" reviews of the game, none of which I have read. As Bioshock did last month, the game is causing these esteemed journalists to soil their pants in the sort of way that would have earned them sound ass-thrashings for their incontinence in high school. I have to agree with Yahtzee's comment on how the insane and ridiculous level of hype for these games eventually backfires when you realize that, well executed and beautiful as they are, after beating them you're still not going to be any more attractive to hot women who currently go out of their way to avoid breathing your stink.

You see, before I say one word about the game I'm already slightly annoyed by it. Whether it's rational or not, it's a bias and therefore should be up front in any review that claims to be objective. On to the real deal.

Visually, Halo 3 is impressive, but not new. On my dying 27" standard definition TV, the water effects are cool, the lighting has gotten better, and the sheen is applied liberally to all surfaces. While many gamers are really excited by these kind of environmental effects, I really don't care that much. The game is what matters. I doubt anyone will be disappointed by what's here, but it's not the Twenty-third Coming (or whatever we're up to for game messiahs). The art direction has again been pushed from Halo 2 as that game did from the first one; new ships, new weapons (though some are redundant, like the fuel rod gun/rocket launcher, and we see far too little of the flamethrower), and what seems like a grim determination to not repeat settings from the previous games.

Halo 1 fans no doubt remember dragging themselves through gray corridor after gray corridor after gray corridor, except sometimes when they were purple. Precious little of this appears in 3, and it's not missed. Yet there are fewer large open spaces than in 2. The number of vehicle segments has been scaled back as well; you only get one go with the Scorpion tank, a couple of brief periods in the super-jetpack Hornet, and a few Warthog outings. Eventually the forced variety and lack of cohesion in the play begins to feel a bit forced, as if the novelty is what you're supposed to care about rather than solid and flexible play.

The story is weaker this time around. Halo 2 offered the innovative device of switching back and forth between the Arbiter's story and the Chief's story. In addition to offering two distinct styles of gameplay, this also helped the story by telling it simultaneously from two viewpoints. One gets a rich view of the Covenant world and mindview through the Arbiter's eyes that the Chief would never have a chance to understand. 3 abandons the switching and tells the story entirely from the Chief's perspective, relegating the Arbiter to an AI NPC that follows you around and basically distracts the big evil from focusing solely on you. It feels unsatisfying to remember how much time was spent creating the Arbiter's character and then see him turned into a walking turret. The final confrontation between the Arbiter and the Prophet of Truth can't help but feel like an anticlimax.

A few other things in the story annoy me. So first Guilty Spark finds you, apologizes, helps you through most of the story, and then suddenly turns on you just before his role in the story has to end? I knew he'd be useless in the story once the new Halo was activated, and so I knew they'd have to get rid of him at some point before that happened. When you get to the control room, the dialogue is so predictable you'll be able to finish their sentences. Apparently they knew they needed Spark to activate the Halo, but didn't bother to find a more believable path in the story. Then there's the Flood. Truth tries to activate the rings, so the Flood help you. The second the rings are off, the Flood turns on you. And who didn't see this coming? The Arbiter and Chief look around, their body language thick with anger at the betrayal. Don't they remember being sent back and forth by Gravemind in Halo 2? Wouldn't they expect some kind of underhanded dealings? Captain Keyes also shows up just in time for her convenient extermination. The plot seems to lurch from point to point without much thought on how to get there.

Finally, I'm glad I sat through the credits to watch the end cinematic. I was all ready to rip Bungie a new one for killing the player offscreen at the end of the game, but they managed to save it by exiling him in the middle of nowhere while setting up the inevitable Halo 4. Regardless, the ending is just unsatisfying in a way that's hard to describe. The war, which began as a struggle against the Covenant, turned into a war against the Prophets, who were then killed, which then turned into a war against the Flood, who were then wiped out. We never get to see the real effect of the war on Earth, nor of the personal toll borne by those who survived. There can't be anyway, since every important character other than the Chief, Cortana, and the Arbiter gets whacked. What's left to care about? Why am I supposed to get teary-eyed when this Lord Hood guy gives a weak Gettysburg Address paraphrase on a dirty hill?

To the next point: The AI is just godawful. Countless times I was manning a turret and gleefully plugging infinite ammo at the bad guys when my own squad would calmly and without hesitation walk directly into my line of fire. Of course I'd cut them down before I could stop firing, so it got to the point where I had to make sure I was shooting over their heads. This was almost always too high to hit the bad guys. At times in the game I saw soldiers jumping on top of boxes or sliding down a hill to get to a battle. So why is it so hard to code them to go around a friendly turret or at least crawl under it? It's not like it's advanced soldering you only learn after five years in the freaking army! Enemies sometimes fly into battle on slow-moving rocket packs, making perfect targets for the sniper rifle. Brutes will drop bubble shields and then walk out of them, making it easy to pick them off. Snipers will give away their positions while still too far away to hit you with any accuracy. Grunts seem not to understand the concept of cover. There were too many lapses to list, and all of them together add up to a constant annoyance during play.

The point about thumbstick control being inferior to the mouse and keyboard has been made before, so I'll just amplify here that it does in fact suck and that the mouse/keyboard is in fact better. The major culprit is just not being able to turn your firing direction fast enough, as well as making it too hard to rotate your view at a comfortable rate. This problem isn't really fixable, so no need to hash it out further, but it does suffer by comparison to the PC.

Finally, the checkpoint/save system, which worked pretty well in the first two games, takes a step back here as well. Most of the time, getting past one knot of enemies or one particularly tricky bit of vehicle maneuvering earns a checkpoint as soon as you're in relative safety; however, there are times when you'll be in near-constant battle for upwards of a minute and make it past one or even two checkpoint positions without the game crediting them to you. At that point you become panicked not because you're being shot at but because if you get ganked by some cheese-rific enemy placement you'll have to fight the entire damn sequence over again. Again, this takes you out of the flow and just pisses you the hell off, especially when you take the same path, aggro 10 less enemies, and are awarded a checkpoint only 30 seconds after your previous one. The inconsistency is maddening.

After all that ripping, did I like the game? Well, yes. It's a solid, if unspectacular, first-person shooter that looks great and offers at least a try at a serious scifi storyline where most other games are happy to get by on violence and tits. It's got more bugs than it should, and the execution is off in some key places, but Halo fans won't be disappointed, and shooter fans will definitely find the good points to outweigh the bad.

But it's definitely not the Forty-second Coming.

**** (4/5)

Open Source FTW!

Wow, I write one little blog and the heavy hitters take notice. First, thanks to all who read and commented. I'll try not to let success go to my head. Second, there are a lot of touchy political things going on in this discussion, and while I don't wish to offend anyone, being honest about my beliefs and my practices is bound to piss someone off. To that person I say "sorry, but I'm famous now". :)

Seriously, there are a couple of things I want to look at.

From Rod's blog, where he paraphrases my support company point into an incorrect metaphor:

Rod claims that dependable car repairs requires trained mechanics. This must come as a surprise to all the non-mechanics employed by every other garage in the world. Someone has to do the sales and run the business and fix the building and keep the website updated and find new customers, etc., etc. Mechanics don't get you any of these, and who's going to tell me they're not required for a successful garage?

As Rod surely knows, car mechanics almost never design or build the cars they are paid to repair. A very small group of designers produce almost all the automobile designs used in the world. The guy at your local Fix-It-Cheap Auto Service doesn't work for Toyota and probably never has, but (assuming he's a competent mechanic) you don't insist that he has to before you trust him to fix your car; he's read the manuals, studied the engine specs, read the latest bulletins and recall notices, and worked on dozens of cars very similar to yours. He fixes your car for a hopefully reasonable price and you're out and happy.

Rod, Juergen, and the other i21 engineers are like the car designers. They decide how Spring should be architected, and then they write code that implements the design they've settled on. While they certainly can support Spring, there's no reason some other engineer (me) can't study the same code and achieve the same level of expertise as far as a customer's support needs require. In my experience, a customer wants their immediate needs met when they open a support case. If we help them fix their problem, they're happy, and if we educate them on how to avoid similar problems in the future, they're very happy. Working with the community to find the best long-term solution that works the best for all Spring users is the second problem and one any good developer is happy to help with.

One thing i21 might look into is having a certified Spring technician program backed up by a rigorous curriculum that makes that really mean something. Toyota certifies mechanics on very strict tests. Cisco, Microsoft, Red Hat, etc., all have similar programs. The companies make money on course and training fees and crank out qualified engineers that spread the mindshare into every corner of every company they serve.

Rod speaks out against companies who, he says, try to make money off open source without fairly compensating the original developers of that code. SourceLabs is not such a company, as our active participation, including committer access, to several projects will show. By implying that these companies are parasites, he makes the fallacious implication that the original developers are always owed a cut of revenue derived from the code. If that's not what he means, it's hard for me to suss out any other interpretation of his statements on this issue. I strongly disagree with this opinion; a true open source project (the FSF term "free software" might even be applicable here) does not belong to any one person or entity, but rather to the community of its users. Rod seems to think that the purpose of Spring is to enrich Interface21; I believe the purpose of Spring is to make developers' lives easier. I make this claim because Spring is licensed under the Apache Software License, which explicitly allows free distribution and even (urk) proprietary forking. If Spring does not truly belong to all of us, then it is mislicensed. If Interface21 honestly feels that Spring belongs to them, they should change the license to reflect that instead of misleadingly claiming to be an open source company.

Finally, Rod claims that SourceLabs has not committed anything back to Spring. I could make the admittedly weak argument that I've personally sent two little tiny patches to the build file which were both accepted, but Rod has also said that valuable contributions to Spring include evangelizing and helping to broaden its community. We have been doing this since the company's inception. I've personally given one of my canned "Spring rocks" speeches to customers, and I've also encouraged other people I know in my professional sphere to use it. Such contributions are valuable not just because Rod says they are but also because they make life easier for everybody using the Java platform, whether they're our customers, i21's, or nobody's.

I'd like to close by offering my help in a professional capacity as a Spring enthusiast with time on his hands to Rod and Interface21. It is explicitly part of my job description to improve Spring however possible. Guys, where can I help? I'm happy to assist with anything you'd like assistance with: code, test cases, documentation, even giving speeches or talks at conferences and venues I visit. My offer is not contingent even on future employment at SourceLabs; I'm volunteering as an open source developer. Have Juergen (or whoever handles this sort of thing for you) drop me a line. I don't want committer access unless and until you've decided I earn it. I don't insist you adopt my patches. I don't insist on helping design the car. But I will help you however you'd like to make Spring better with dedicated time each and every working week.

So how about it? Would you like the help? Let me know.

Nonsense about Interface21

Rod Johnson, a man I respect and admire, has managed to step on one of my hot buttons. He's put up a new blog entry that reiterates his earlier complaint against other companies that offer support or services for Spring. While I agree with some of them, his brush is far too broad for the truth.

Before I start, full disclosure: I work for SourceLabs, a company that offers 24/7 enterprise-level support for Spring as part of a fully integrated and certified Java enterprise software stack. I'm proud of our products and how we've helped our customers.

Rod starts off with this:

OpenLogic needs to understand that the opening comment in Stormy's post that "Developers that work on open source software typically have day jobs that pay pretty well…so they work on open source software for free and write code during the day for big bucks" is largely wrong, understand where the open source software they hope to profit from comes from, partner appropriately, and set a price point that allows for genuine support. An alternative would be to stop claiming to provide enterprise support, and be clear that what is being offered is a kind of on-call development assistance, with no guarantee of being able to resolve critical issues.

Actually, Stormy's not largely wrong. Companies who sponsor open source by hiring its developers are neither a necessary nor sufficient condition for a successful project. The obvious example is Linux, which rapidly evolved into a stable and usable kernel long before the words Red Hat or SUSE entered the conversation. Back then, all Linux developers were far-flung, spare-time volunteers who didn't receive a dime for their work. When the first Linux companies decided to try offering support, there wasn't a "Linux21" company headed by Linus they could negotiate with, and Linus never claimed that he was the way, the truth and the life of Linux support.

Jesus may have said that no one comes to the Father without coming through me, but Linus explicitly disavowed control of the Linux community at a very early stage. He maintains his position through the universal respect of his judgment and that he has demonstrated that he is beholden to no one. Whether he succeeds or fails, he tries to do the best thing for Linux, not whatever company he's working for. Red Hat's Linux support is not somehow delegitimized for lacking an explicit Linus Stamp Of Approval, and neither is Canonical's, Novell's, SUSE's, etc. Plus, aren't those companies making money just fine, and isn't the competition between them good for all Linux users, individual and corporate? One might also mention XenSource, who never claimed to be the only legitimate source of Xen support, and yet recently sold for hundreds of millions of dollars. There are tons of consultants who are expert in Ant, Maven, Zimbra, JSF, etc., who may compete for contracts, but none of them can seriously claim to be the only legitimate option over the others.

Rod claims that dependable support requires committer access to the source code. This must come as a surprise to all the non-engineers employed by every other support company in the world. Someone has to do the sales and run the business and fix the servers and keep the website updated and find new customers, etc., etc. Committer access doesn't get you any of these, and who's going to tell me they're not required for a successful support company?

Good support means that you have a personal relationship with your customer. You know what they need, what other software they're using, what they're most concerned about, and you establish a bond of trust with them that you will be there for them. That goes way beyond giving them a pager number and saying, "Call me if it breaks".

Despite what Rod would have you believe, I (or anybody else) can offer top-quality Spring support thanks to the ASF license Spring uses. You don't need to be a Spring committer to fix bugs in it, and you don't need Interface21's permission or endorsement to use it. If there's a bug that impacts your production server, I can find it in the code myself, talk to the customer, and figure out what the best solution is: patch, workaround, client code change, etc. I can do that because I have access to the source code that matters -- the one the customer is using -- and because I understand, through careful and tedious preparation, what the customer needs.

Moving on, we next have this:

It may seem strange to you, but it's normal for individuals and companies to want a return on investing millions of dollars, passion, blood sweat and tears in something. Interface21 sustains and develops Spring and we do a good job. I think it's perfectly reasonable to expect that we can leverage this investment into an advantage in the support market.

Sure, Rod. You want to sell support for Spring, be my guest. Play up every advantage you can in the market, but it is a market. If you want to argue that control over committers makes you the best support option, go ahead, but as I said above, it's a pretty weak argument.

Authors and thousands of these developers contribute to the success of the project and community through their evangelism. That's an important way of contributing. OpenLogic does not; it merely aims to make money from projects that others have built, evangelized and conveniently maintain and enhance. Now that's a "sweat deal".

OpenLogic may not contribute to the projects they use, but at SourceLabs we do. Our credibility as an open source company depends on it. I'm a committer on the Apache Commons project. We have people in house who have committer access on Struts, Hibernate, and Maven, and we're also involved daily in Tomcat, Axis, and other projects. We have brought Spring into companies because we like working with it, thus increasing mindshare and support for Spring without anyone at Interface21 knowing anything about it or lifting one finger.

No one at Interface21 can seriously claim to be actively engaged with the other pieces of a full Java enterprise stack; Spring, for all its awesomeness, is a framework, not a stack. It doesn't provide everything an enterprise customer needs, and supporting only Spring is not going to cut it with companies who also need help with Hibernate or Struts. In fact, Rod has to say that if you do need help with the other parts of your Java solution, Interface21 can't help you since they don't control the source code of those projects.

It's true that aggregation in and of itself is not worth much. But neither is control of the code. Open source allows everyone to compete on a level ground in whatever arena seems valuable enough to conquer. I hope Interface21 isn't just afraid of a little competition from companies who understand that doing support right is much more complex than having an SVN account.

One final point for Rod: why did you open source Spring at all? If you're so convinced that no one else can offer credible support for it, why not just make it proprietary?

Sun is misusing the GPL for Java: Part 2

Slashdot | Sun Lowers Barriers to Open-Source Java

Now for Part 2.

Last time I ran down what I see as the differences between the FSF and the ASF's handling of their communities as expressed in their respective licenses and practices. I feel they start from very similar places yet wind up in ones that, in a purely practical sense, function differently, even to the point of not being able to collaborate. This is a shame, but both groups have sound reasons for doing things their way. It makes it hard on those of us who want to participate in both, however.

When Sun announced the release of Java under the GPL, I was naturally delighted. Finally a free software system could include Java, finally the gray cloud hanging over Java developers with a conscience could finally dissolve, finally we could inspect (and even fix) core Java classes without fear of taint or lawsuit, etc. It was a good day all around.

Until the news dropped recently that Sun was changing the license terms of the Java Compatibility Kit (JCK). This was expected since the previous terms of the JCK's license conflicted with the GPL, but Sun went a step further and declared that only Java implementations "substantially based" on Sun's GPL implementation would get access to the JCK. This is a good thing, since people who patch Java can still get it certified as Java, including ports to different platforms and architectures, but it is also a big middle finger to all existing Java implementations, especially Harmony and Classpath. (Also, several projects trying to offer a free software JVM, like Kaffe and Japhar, are also affected.) Sun has effectively delegitimized these other efforts, saying, "They're not Java, they never were Java, and they never will be. There is only one place to get real Java, and it's from us."

The most important thing about Java in Sun's eyes has always been control: control of its brand, control of its implementation, and control of its uses. Java has never been nearly as open as some people would have you believe: the first version was licensed in frankly despicable terms, turning off a lot of interested developers who were willing to look past the ubiquitous and insipid hype. It's also easy to forget that for several years, Java was crippled by poor performance and buggy internals. Microsoft's JVM was preferred not because it was included in the OS (applets were already a dud) but because it was faster and more stable than the official. Naturally Microsoft sought to embrace and extend Java into something they could control, and of course Sun fought back and eventually won, but the damage to Java's reputation had been done. The development and later uptake of C# is significant also because it offered something developers needed: a Java that performed very well that hooked deeply into Windows.

Finally, Sun's obsessive compulsion to control all things Java retarded its development. Sun doesn't have the resources to push Java along nearly as effectively as a group of interested developers passionate about the technology. If Java had been GPLed in, say, 1997, it would be very different from what it is now. I'm not sure it would be the same thing at all, but I am sure it would be a better thing. With developer interest, a free software license, and tons of time to research and experiment, we could have things like a real native code compiler, streamlined and less bloated VMs, tighter class libraries, and a myriad of other pipe dreams we're probably never going to get now. The determination to do new language features like generics while preserving very strict backward compatibility guarantees has resulted in a clunky and difficult development environment; if the technology were under the control of a group that tried to do what was best for the technology instead of what was best for the interests of a tiny minority of its users, there would be at least a fighting chance to avoid a situation like this.

Sun has found a way to control Java by ostensibly setting it free, and they're doing it by using the GPL as a club. The GPL's copyleft was designed to preserve the Four Freedoms after the software left the hands of the original developer. Sun has turned it into a weapon against people who can't or won't develop Java according to their rules. They plan to "open" the Java community not by joining with the existing ones but by creating a new one and marginalizing every other existing one.

When I say "misusing the GPL", I mean that Sun is going against the spirit of it, not the letter of it. Sun has every right to take this action, and as a member of the FSF it's hard to find fault with it -- it's what I've wanted for years. But in my time in the ASF, I've come to appreciate the work they've done, and they have a legitimate beef with Sun over their conduct in the JCP and by talking out of both sides of their mouth with respect to the ASF's access to other TCKs. (See Geir's letter for more.) This, apparently, is Sun's response.

While the new Java may be a GPL world, there is reason to wonder why anyone at the ASF should spend further time working on Java. Sun has left them for good, and pending a licensing resolution with the existing Java code, it will be more difficult to construct a system with Sun and ASF code from now on. At the same time, Classpath stands to benefit hugely from this, again at Harmony's expense; fixing Classpath and Sun Java is very easy while fixing Harmony is that much harder.

I'll have to think about what this means for ASF.

Sun is misusing the GPL for Java: Part 1

Slashdot | Sun Lowers Barriers to Open-Source Java

I'm a proud member of the FSF as well as the ASF. For years, the incompatibility between the GPL and the ASL drove me nuts as well as many other developers. Building a complete free software Java platform is a Herculean task, and the duplication of effort between Classpath and Harmony struck me as needless. Of course the developers involved are free to do as they please, and I happily support any effort producing free software, but from the practical standpoint of just wanting one to use, neither had achieved parity with the Sun implementation. As a Java developer who wanted to make a living , I needed a rock-solid stable Java, and there just wasn't a free software option.

I don't believe there's any significant ethical difference between the FSF philosophy of free software and the ASF philosophy of open, community-driven collaborative development. I see it as two viewpoints on the same principle. Several developers work on projects for both organizations, and I know of no ethical conflict between doing so from anyone's perspective. However, the different emphases of both organizations, as expressed in their licenses, give rise to some annoying and probably unintended results.

Both the GPL and ASL are free software licenses because they protect the Four Freedoms, but the GPL uses copyleft to prevent someone else from restricting the Four Freedoms once it leaves the copyright holder's control. The ASL doesn't care about that beyond some patent restriction language that is not in and of itself a bad idea. The GPL is both a shield and a club: the shield protects the user from legal responsibility for the code and preserves the Four Freedoms for that user; the club is used to beat around the head and neck those who, having had the freedoms extended to them, would then seek to deny it to others. The GPL is the summation and distillation of everything the FSF believes in.

The ASL is emphatically NOT a distillation of everything the ASF believes. The ASF has tons of rules regarding how projects must be managed, handled, advanced, promoted, demoted, etc. These procedures are designed to ensure that any ASF project is developed in the open, that the community of users and developers can always be heard from, and that no project can ever be taken over by any individual or group hostile to the spirit of openness.

I think this is the key distinction between the two groups: FSF uses the GPL to control its community, ASF uses its culture and members to control the community.

I'm not trying to spark a debate about which is "better" or "more ethical"; again, these are different outgrowths of what I believe is the same thing, the love of what the FSF calls "free software" and what the ASF calls "open, collaborative software development". However, this doesn't mean that the different approaches work equally well in all possible situations.

Consider a software project whose copyright is held by the FSF. Anyone contributing to a FSF project must legally transfer their copyright on their contributed code to the FSF; this is done because the GPL copyleft is much easier to enforce if a single entity holds the copyright. The FSF cares about nothing more deeply than the Four Freedoms and will do anything it thinks is necessary to protect and defend them through the GPL. It's understandable that many individuals who would like to contribute to a FSF-controlled project cannot do so due to this restriction. For example, a programmer's company usually claims copyright on any code written while in the employ of that company, sometimes even code written on the programmer's own time and equipment. This programmer may not participate in the project through no fault of his own.

Also, imagine a software fork: the canonical example here is the Emacs/XEmacs division. The GPL protects the right to fork, and so XEmacs is just as legal as Emacs is. Without getting into the history of this rather ugly story, the FSF and Lucid, both acting in good faith, were unable to come to a consensus on the technical merits of Lucid's Emacs patches. The two projects forked, developed their own communities of users and developers, and continued on their separate ways. I'm not criticizing either program or either community; I only want to point out that the result of the dispute was a fork.

Contrast this to the ASF approach. ASF committers are not required to turn over copyright on their work other than under the terms of the ASL; however, ASL members must be individuals, not companies. Many contributors may insist on keeping their own copyrights, and the ASF allows this. ASF projects are controlled by a management committee, the leader of which reports to the Apache Board, and are answerable to the same. Major project decisions, such as releases, require a lazy consensus vote, and commits to a project require unanimous consent. Because the ASF puts so much effort into its community, forks and major disputes are much less common than in FSF-controlled projects; when they do arise, they are resolved not necessarily to everyone's satisfaction but to the point that the project may continue. For getting things done, this approach has obvious advantages. Again, the ASF cares about open development for its own sake and is less concerned with guaranteeing the FSF's Four Freedoms.

So what does all of this have to do with Java? My next post will discuss that, as well as ripping Sun a new one for misusing the GPL.

Shiny rails and testing

Man, Rails kicks ass.

After getting a hold of Ruby a few months ago, I've been looking deeply into Rails. There are a couple things at work that use it, and I'll probably wind up maintaining them if we don't replace them altogether.

There's little point in me talking about how great Rails is, since you can find Rails worship sites just by typing random letters into a google search, but I am going to emphasize the thing that really kicks unseemly amounts of ass -- the one thing that no one else has done nearly as well: testing.

Rails does first-class support for model (unit) testing and controller (functional) testing better than any other framework I know, including the one I support professionally. While unit tests have been around forever, there hasn't been a concerted push to get a comprehensive functional test strategy in Java. Part of the problem, of course, is that Java has more web frameworks than France has baguette shops, and several of them seem to make a point of being as different as possible from any other framework. Rails, being an all-in-one solution for your web needs, can offer integrated tests easily, but for the Java offerings you more or less have to reinvent the testing axle every time you reinvent the wheel.

Case in point: Our framework includes Struts 1.3.8, which for purposes of this discussion means we support it and give people a number to call if it breaks. We also ship a sample application that uses our framework, and I volunteered to maintain/update/rewrite it for the next release. The guy who did the first version is no longer with the company, and he never bothered to write unit tests for his models nor functional tests for his controllers. Now it's no indictment of the technology if the developer is too lazy to code properly, but after filling in the missing tests I got to Struts. I'm not willing to ship an app without all necessary test coverage, and controller routing and request processing falls within that box. (If you disagree with this, you are wrong.) So I poked around for some test help and came across StrutsTestCase, which seemed to be just what the doctor ordered. Unfortunately, it's apparently been abandoned and the latest release is three years old, not to mention it doesn't even compile under Java 5. So I've been working on something similar for our needs.

All told, the googling/studying/problem solving/coding that I'll have done by the time this is finished will add up to a decent chunk of effort. I remind those reading that Struts 1 is still the most widely used MVC Java web framework, so one would expect to find solid testing support for it. Well, you won't, and there isn't.

The comparison to Rails, where a test case for your controller can be generated with a simple script and the entire test written and done in minutes, reflects badly on the Java world. I can only conclude that Struts shops write their action mappings and then laboriously, manually test each one through a running browser. In addition to being inefficient, slow, and boring, it takes forever, which is another way of saying that it won't be done. This is the kind of thing the computer should be doing for you, people. This isn't a Java vs. Ruby issue, and it's not even an issue particular to Struts; there is a resistance to spending code effort to automate tests that can and should be automated.

We need to make managers aware of the need for automated functional testing so time for it gets built into schedules. We need to improve our testing tools so they'll be ready to handle new technologies. We must spend our time working on difficult problems, not fighting the machine.

Guess I'll start by writing a test library.