Wednesday, September 30, 2009

Portland, Oregon, joins the ranks of the open cities « Silicon Florist

Portland, Oregon, is now an open city.

Following in the footsteps of open cities like San Francisco, Chicago, and Vancouver, BC, Portland’s Mayor Sam Adams and the City Council today unanimously approved a resolution that directs the City of Portland to open data to outside developers and encourages adoption of open source solutions in technology procurement.

Very, very cool. Now if only the federal government would do the same. It's definitely getting better but we have a LONG way to go, particularly on the adoption of open source solutions front.

Steve Jobs, As Demonized By His Nemesis - doubletwist - Gawker

Oh how the worm turns. Can't say I disagree. Apple started out as an "alternative" with their "Think Different" campaign (to contrast with IBM's "Think" motto), but between iTunes and the iPhone they want control over every aspect of people's digital lives. High time Apple went back to their roots--I think the backlash has been building for quite a while and the tighter Jobs clenches his fist the more customers will slip through his fingers. Or something. ;-)

Code Monkeyism: The dark side of NoSQL

The three problems no-one talks about – almost noone, I had a good talk with the Infinispan lead [1] – are:

  • ad hoc data fixing – either no query language available or no skills

  • ad hoc reporting – either no query language available or no in-house skills

  • data export – sometimes no API way to access all data

Much as I'm loving CouchDB these days, these are valid concerns if you're considering moving to a "no SQL" type database (and there are a few other concerns as well).

As always it comes down to using the right tool for the job. This is pointed out at the end of this article and in the comments, but depending on your needs you may wind up with a combination of a No SQL database for what they're great at, and a traditional RDBMS for the problems that No SQL databases don't solve.

Tuesday, September 29, 2009

Happy Start of Year 26 of the GNU Project

"I could have made money [by joining the proprietary software world], and perhaps amused myself writing code. But I knew that at the end of my career, I would look back on years of building walls to divide people, and feel I had spent my life making the world a worse place." Richard Stallman, GNU Project

Tomorrow marks the end of the 25th anniversary year of the GNU Project and it's been quite a year! Here's some of the highlights sent out in today's Free Software Supporter newsletter:

As I said in a previous post, without the FSF the free software movement from which we all benefit today wouldn't exist. The FSF tirelessly fights software patents, DRM, and a number of other important issues because they believe free software is vital to a truly free society. I couldn't agree more.

Here's to another 25 years of the GNU Project, and a heartfelt thank you to everyone involved with GNU and the FSF for making the world a better place through their commitment to free software.

Font Encoding and Searchable PDFs

I ran into a weird issue today I thought I'd share in case anyone else runs
into this.

In one of my applications I'm populating PDF forms via CFPDFFORM in
ColdFusion. It works great but the PDFs generated aren't searchable, by
which I mean if you're in Acrobat Reader (or any PDF reader application
from what I tested), you can search the PDF but any data that was
programmatically inserted into the PDF form fields isn't searched. So for
example I can be looking at the name "Smith" in the PDF, but if I do a
search for "Smith" it will yield 0 results.

It turns out that the reason for this is due to the encoding of the font
being used on the form fields. I chose Arial for the font (in Acrobat Pro
on the Mac if I remember correctly) when I was creating the empty form but
didn't realize that the version of Arial I chose used Identity-H encoding.
Identity-H is a double-byte encoding so I find it a bit odd that it's not
searchable, but the solution (at least that I've found so far) is to use a
font with ANSI encoding instead.

Since I've been generating PDFs with this app for 2+ years now (funny no
one noticed until now!), I guess I'll be regenerating a lot of PDFs if I
want them to be searchable. Luckily there's a function in the app for just
that purpose, but my server's going to hate me for having to do all that
work over again.

Hope that saves someone else's head and nearest wall from unnecessary

Saturday, September 26, 2009

Time Machine Problems After Snow Leopard Upgrade

I finally got around to upgrading my Mac Pro desktop to Snow Leopard a
couple of weeks ago, but I didn't reconnect my Time Machine backup drive
until late last week. When Time Machine fired up it would endlessly hang
while starting the backup, or hang on a "clean up" operation, or in some
cases would crash the Finder entirely and force me to have to reboot the

My backup drive was connected via firewire, so on a whim tonight I
reconnected it via USB. So far no problems. I searched around a bit and did
find several references to firewire problems after Snow Leopard upgrades,
so I'm hoping that was the culprit. Just thought I'd post this in case
anyone else was having similar problems.

Richard Stallman is Not the Bad Guy | Boycott Novell

“Value your freedom or you will lose it, teaches history. “Don’t bother us with politics,” respond those who don’t want to learn.”

–Richard Stallman

What the so-called "pragmatists" of the free software movement forget is that there wouldn't be a free software movement without Richard Stallman, or at best we'd have a weak, watered-down version of the free software ecosystem from which we all benefit.

Furthermore, the Free Software Foundation tirelessly fights the free software fight, and purists and pragmatists alike benefit from that. There is no equivalent organization on the pragmatist side of this argument, so the pragmatists are attempting to vilify Stallman when what they should be doing is thanking him.

People on the "open source" side of the fence need to put up or shut up. Once they have an organization that fights against proprietary software with the same passion and effectiveness as the FSF, maybe I'll listen. Until then they're giving an inch while proprietary software takes a mile.

Friday, September 25, 2009

MongoDB: A Light in the Darkness! (Key Value Stores Part 5) | Engine Yard Blog

MongoDB can be thought of as the goodness that erupts when a traditional key-value store collides with a relational database management system, mixing their essences into something that’s not quite either, but rather something novel and fascinating.

I've been playing around with CouchDB quite a lot lately, and MongoDB seems quite similar. After writing a couple of small apps with CouchDB I'm finding it pretty darn painful to go back to RDBMS when I have to.

Verizon scraps Palm Pre plans

Poor sales at Sprint as well as interest in handsets from Research in Motion and Motorola reportedly contributed to Verizon's decision to ditch the Palm Pre

So utterly bummed. Guess I'll have to wait for Android phones now ... The Pre is awesome but I really don't want to switch to Sprint. Been way too happy with Verizon over the years.

Thursday, September 24, 2009

More N00b Grails Errors - When a Domain Class Isn't a Domain Class

I figure as I make my travails with Grails I'll post stuff I run into so
others can benefit if/when they jump into Grails.

Today I started a new Grails application and created a domain class and a
controller for User. These were in packages but that's irrelevant, so I'll
keep things simple for the purposes of the example.

grails create-domain-class User
grails create-controller User

I then edited my User class:

class User {

String email
String password
String firstName
String lastName

static constraints = {


And edited my controller to add the scaffolding:

class UserController {

def scaffold = true

def index = {}

When I fired up the app I got an error to the effect of "Can't scaffold
because User isn't a domain class." Weird. Since I hadn't spent much time
on anything yet, I nuked my domain class, controller, and test files and
started again.

This time around the app ran but I got a 404 error when clicking on the
UserController link on the index page:



Very odd it's looking for JSP, but it dawned on my that I told it to
scaffold AND I had an empty index action defined, so remove the index
action and voila, all is right with the world.

If you got this far and are thinking "DUH!", remember that I warned you
with the "N00b" declaration in the title. ;-) I'm sure other people are in
the same boat I am, namely augmenting skills they have in other languages
and technologies with Grails, so even if it's a no-brainer for those more
familiar with Grails I figure I'll share anyway. Expect my Grails posts to
get more interesting the more I dig into Grails.

Community Equity: Facebook for Enterprise

Community Equity goes beyond a simple structuring of people and their online content. Community Equity performs complex calculations to rate one's participation and contribution levels, the ultimate goal being to drive the adoption of content and ideas, which provides an ideal platform for corporate communities.

Interesting open source "Facebook for Enterprise" application by Sun. Could be just the ticket who want Facebook internally but also want something a bit more business oriented in addition to the social aspects.

Flex/ColdFusion Developer Position Available - Rockville, MD

Contact Jim Gray ( for more information.


FLEX SOFTWARE DEVELOPER – Potomac-Rockville area – 85-100K for a
growing software company

Seeking a Flex Software Developer. Will be coding software in Flex and
ColdFusion. Write technical requirements, work on designing the software
product and work with SQL Server in writing queries and stored procedures.
5 years of web development experience to include experience with Flex,
ColdFusion and SQL Server. Eclipse desired. Ability to analyze,
troubleshoot and contribute to the development process is required. Degree
preferred. Full benefits.

Wednesday, September 23, 2009

Windows 7 House Party Host Guide

This is seriously misguided and embarrassing. MS didn't get the memo that community isn't something you do to people.

How Ravelry Scales to 10 Million Requests Using Rails | High Scalability

Ten years ago a site like Ravelry would have been a multi-million dollar operation. Today Casey is the sole engineer for Ravelry and to run it takes only a few people. He was able to code it in 4 months working nights and weekends. Take a look down below of all the technologies used to make Ravelry and you'll see how it is constructed almost completely from free of the shelf software that Casey has stitched together into a complete system. There's an amazing amount of leverage in today's ecosystem when you combine all the quality tools, languages, storage, bandwidth and hosting options.

Really interesting and quick read (link to a great interview at the top of the article as well) about building and scaling what started out as a small site (don't they all?). Excellent details about the technologies used and why, and nice lessons learned. "Keep it fun" is one I continually have to remind myself.

Tuesday, September 22, 2009

Enterprise Java Community: Programming is Also Teaching Your Team

Programming has two goals.

One goal is to do something, of course: calculate an amortization table, present a list of updated feeds, snipe someone on Ebay, or perhaps smash a human player's army. This goal is focused at a computing environment.

The other goal is - or should be - to transfer knowledge between programmers. This has a lot of benefits: it increases the number of people who understand a given piece of code, it frees a developer to do new things (since he's no longer the only person who can maintain a given program or process), and it often provides better performance - since showing Deanna your code gives her a chance to point out where your code can improve. Of course, this can be a two-edged sword, because Deanna may have biases that affect the code she writes (and therefore, what you might learn.)

Nice reminder of one of the big goals of programming in my mind. Developers often get so busy that we furiously code with an eye only to the short-term end goal, while neglecting the longer-term goals of the development team as a whole. Deadlines may get met this way, but it's damaging over the long haul.

The Tao Of Programming

The master programmer moves from program to program without fear.
No change in management can harm him. He will not be fired, even if
the project is cancelled. Why is this? He is filled with Tao.

So much programming wisdom it's scary.

Monday, September 21, 2009

Note to self: Grails integration tests fail with static delcaration before constraints

Ran into this today and it was semi-tough to hunt down so I figured I'd post it since lord knows I'll forget this sometime in the near future.

If you have a class as follows:

class User {
  String firstName
  String lastName

  static constraints = {

And an integration test like so:

import grails.test.*

class UserIntegrationTests extends GrailsUnitTestCase {
  void testSave() {
    def user = new User(firstName:'Matt', lastName:'Woodward')

You may find Grails throwing this error when you run your integration tests:

No signature of method is applicable for argument types:() values:[]

Bit of a weird error but from what I can tell, the integration tests don't like the way the scaffolding formats that constraints block. I reformatted without the line break at the tests pass, and now even when I put things back the way they were, the tests pass.

Hope that helps someone else's head and the nearest wall if you're starting to dig deeper into Grails.

Hot Air Balloon Ride - a set on Flickr


I took a ride in a hot air balloon with a couple of friends last week. Really amazing experience. Nothing quite like being out in the open that high up!

Last Call for Pre-cf.Objective() 2010 Training

If you're interested in providing any training before (or after) cf.Objective() 2010, you have until October 2 to make a final commitment. I've heard from several people but at this point we have as many rooms available as we need, so if you want to do some training speak now!

I do have full details of costs associated with the rooms, meals, etc. now so if you've been hesitating because I couldn't let you know exactly what you were getting into ;-), hesitate no more. And as always if you have questions, please let me know.

Also if you're interested in attending training but not offering training yourself, feel free to give me suggestions of topics and trainers and I'll do my best to make it happen.

Please spread the word if you can. We got a late start on pre-conference training last year so we're making up for it this year.


"The Open Internet: Preserving the Freedom to Innovate"

I believe we must choose to safeguard the openness that has made the Internet a stunning success. That is why today, I delivered a speech announcing that the FCC will be the smart cop on the beat when it comes to preserving a free and open Internet.

In particular, I proposed that the FCC adopt two new rules to help achieve this.

The first says broadband providers cannot discriminate against particular Internet content or applications. The second says broadband providers must be transparent about their network management practices.

Given how out of touch and backwards government usually is on the Internet, this is a very welcome shock.

Additional Thoughts on "Is Java Dead?"

Part of how I use posterous is as a web scrapbook of sorts, and it's a great way to keep the full version of something I come across on the web that I find interesting. Still find it odd you can't edit the excerpts posterous generates, but on the other hand if the original link goes away, then I still have it handy.

Anyway, someone on Twitter asked if I had any thoughts on the "Is Java Dead?" article I found earlier today, and although I had a couple of comments at the bottom of that post, I have a lot more to say about the continual predictions of Java's demise.

Living in the CFML world for so long I'm used to people proclaiming that one of my technologies of choice is dead. For those not in the know ComputerWorld put ColdFusion on their "Top 10 Dead or Dying Computer Skills" list in 2007/. In the top spot on their list was COBOL, but more on that in a moment. I won't rehash the whole ColdFusion is Dead trope here, but semi-related to my recent Grails post, I did find a blog post by Dave Lowe from 2007 on this topic that was particularly rational, and it begs the question: has enough changed in two years? I'd say yes and no, but that's fodder for another post ...

Back to Java. The timing of the "Is Java Dead?" post is interesting given that COBOL just turned 50. According to ComputerWorld and many others, COBOL is dead and has been for a long time. The irony here is that COBOL runs most of the world's ATMs and, according to the article, powers 75 percent of the world's business applications. I'm not sure how they define "business applications" and that number seems rather high to me, but regardless of the specific statistics, it's fair to say COBOL is far from dead. As a COBOL programmer friend of mine always says, "I'm not a dinosaur. I'm a shark." (He's referring to the fact that sharks have been around for millions of years but are still here and still to be feared, in case that wasn't obvious.)

Java has still to appear on any ComputerWorld obituaries (only a matter of time), but it seems that every year or so, much as with CFML, people fire up the death rumors once again. This year in particular that's to be expected since nothing fans the flames of FUD more than Oracle's acquisition of Sun. And to be frank, the mechanisms for Java to evolve aren't particularly speedy, which even Sun predicted back in 2000. (Some interesting parallels there with what's going on in the CFML world today.)

So is Java dead? To answer that we first have to consider what Java is, and it's much, much more than the OO programming language people love to hate.

What's Java?

In the first Java programming class I took at Sun back in 1999, the first question my instructor put on the whiteboard was "What's Java?"

People in the class had various answers, but none got at what the instructor was looking for. "Above all," the instructor eventually revealed, "Java is a platform." So Sun had the platform in mind from the start, and it turns out that's the smartest thing they could have done.

Java is of course also a programming language, and as such it's great. I can hear people disagreeing already, so let me support my assertion a bit. By "modern" standards (whatever that means) Java is more verbose than people would like, it's too strict, and compared to languages like Groovy and Ruby it seems downright dated. But what the Groovy, Ruby, Python, etc. advocates forget is that without Java they have nothing against which to look good.

OK, I'm being facetious, but I hope you get my point. Java wasn't designed to be the latest whiz-bang dynamic web 2.0 wunderkind because that wasn't the state of the world back in the 1990s. When Java 1.0 was released in 1996 it was, hard to see 13 years later, revolutionary. The garbage collection alone put it lightyears ahead of C++, and Java had serendipitous timing with the advent of the Internet as well.

As a language Java is admittedly rather stodgy compared to the fancy new dynamic rapid ajaxified agile toolkits we have at our disposal today, and yet with JRuby, Jython, and more directly in the case of Groovy, not to mention CFML, modern languages want to run on the Java platform because it's ubiquitous, it's powerful, and it's not going anywhere.

Java as a Platform

Regardless of your opinions of Java the language, there's much to love about Java the platform. Sun's original claim of "write once, run anywhere" is technically true even of C and C++ given the one additional step of native compilation, and this slogan has frequently been bastardized into "write once, test everywhere." But on balance Java lives up to its run anywhere promises, and this is precisely what allowed Java to grow and become as entrenched as it is today.

The notion of a virtual machine, driven by Java's origins as a platform for set-top boxes, turned out to be a stroke of genius that went far beyond its original intent. It was head of its time, to be sure. The notion of a compiled-yet-interpreted language was odd, and at first Java was dead slow compared to natively compiled languages. The promise--and actual delivery--of true portability was compelling enough for Java to take off, however, and these days the speed argument against Java is wholly irrelevant due to tremendous speed improvements with Java itself and the ridiculously powerful machines we have at our disposal.

So take or leave Java as a language, but as a platform Java got things 100% right. Where web applications in particular are concerned, I still get a big smile on my face every time I drop a single WAR file on a servlet container to deploy my applications as opposed to FTPing scores of individual files, and that's all thanks to the Java platform. Java thought well beyond being just another language and continues to be hugely compelling on the platform side even if you prefer to write your code in another language.

What Else is There?

Most of the arguments against Java are against its perceived shortcomings as a language, but even on that front Java does what it does incredibly well. It's extremely fast, and if you need the features that a strongly typed language has to offer, you could do far worse than Java. If you want to go with one of the newer kids on the block, where something like Groovy is concerned you really do get the best of both worlds: dynamic features for rapid development, with the speed of Java and access to the huge Java ecosystem at your fingertips.

When people claim that Java is dead and focus on the language, they're completely missing the all-important platform piece of the puzzle. So on this point I'd like to ask a blunt question, and one that none of Java's naysayers ever get around to answering: What else is there? What else out there offers what Java does as a platform?

To my mind the answer is nothing, so if Java truly is dead we're all a bit doomed. The closest corollary is the .NET platform in the Microsoft world, and therein lies the problem: it lives in the Microsoft world. People who know me know that makes it a 110% non-starter for me, but from a more objective standpoint that's an issue for much of the rest of the world as well. Why would people sink a lot of time and money into developing business applications that will only run on Windows servers? Yes, there's the Mono project that allows .NET CLR languages to run on Linux, but I suspect over time that effort will wane, and even now it's well behind the official MS version. The gNewSense project just announced it's eliminating Mono from its distributions, and given public opinion on the matter Ubuntu will likely lean in this direction as well.

So 13 years after its release, if you want write-once run-anywhere applications, great speed, and a tremendous platform on which to run all your apps in multiple different languages, Java truly stands alone.

Long Live Java

Even though Java's a bit long in the tooth in the opinions of some, all these years later it still offers things no other technology does. If Java is truly in jeopardy all of the efforts to run more modern languages on the Java platform wouldn't continue. Java still has tremendous value as both a language and a platform, and if anything Java seems to be experiencing a renaissance these days from where I stand.

A friend asked me just last week if I thought taking Java classes and learning Java was a good idea. I didn't hesitate to answer in the affirmative. Java as a skill is still in large demand, the Java community is alive and strong, the number of powerful open source projects written in Java is astoundingly deep, broad, and diverse, and given the other options in which my friend could spend his time and money, Java still comes out well ahead.

Java's not a dinosaur. It's a shark. And I can say with a great deal of certainty that sometime in the 2040s we'll see an article on Slashdot celebrating 50 years of Java. I just hope I'm there to see it.

Is Java dead? (via CodeMonkeyism)

Written on September 21, 2009 by Stephan Schmidt

Is Java dead?

var dzone_url = '';


Is Java finally dead? There has been much discussion about the end of Java. As a developer, do you need to care? How do you need to change your decisions in the case that Java is dead? I have pounding this question for the last several years, beginning with my adventures into Ruby at the end of the 90s. I hope to give a thorough representation of my thoughts here.

In a very interesting thread on LtU Sean McDirmid wrote:

The Java death watch continues. Its future is tied up with Sun, which continues not to make money, and in this economy… JavaFX was late and didn’t make the splash it needed to make. Can Scala (or Clojure I guess) save the JVM? And who would take over the Java mantle if Sun imploded, IBM?

while Ross Smith is adding:

I think Sun will be widely recognised as doomed, if it isn’t already dead, by the end of 2009, and they’ll take Java (and the JVM) down with them.

A lot has happened since then: Orcale is buying Sun, the JRuby team has jumped ship to Engine Yard. 2009 has not yet ended, we will see if that prediction holds true.

Searching for java is dead with Google, one gets

Results 1 – 10 of about 8,620,000 for java is dead.

Dead indeed. Or at least lots of people think it is or will die 2009.

For a start we first need to explore what “dead” means, and in particular what dead means for Java. What dead means to you as a developer. After that I will look into the potential successors and why they are better than Java – or not. Looking into the question “why should Java die” I want to make some prediction about Javas future and especially about some future Java programming style.

What does dead mean?

Let’s begin with some thoughts on what Java means. . Most people mean different things when they talk about Java. There are mainly three parts:

  • Java, the language

  • Java, the libraries (JDK)

  • Java, the virtual machine

So does “Java is dead” mean the language, the libraries or the virtual machine? Contrary to the commentors on Lambda the Ultimate the Java VM is safe. There are considerable efforts to open source the virtual machine beside the language. Indeed with the beginning of the Java language summit it looks stronger than before. Should Sun as a company die, Oracle drop Java or stop development on the VM, most probably some other players with their VM implementations or the OpenJDK community would jump in.

The VM as a platform has grown enormously in 2008 and 2009. Lots of people talk about JRuby as Rails for the enterprise – Engine Yards has pledged support. Scala is an object-functional language on the VM with a strong following and a lot of momentum in 2009. Both Scala and JRuby are established on the JVM, but there are newcomers. Clojure stirred up the Lisp community and the Java community in 2008 and made a lot of buzz in 2009. Just in time for christmas last year Ola Bini released Ioke, what he described as a mixture of Smalltalk, Ruby and Lisp. It looks like a more dynamic Ruby to me after some hours of playing around with it. Great feat. And recently Noop has been released.

Or does “Java is dead” mean the language? What does it mean to be dead for a programming language? Perhaps that it is no longer the default choice for projects? Default choice for what projects? It is obviously not any longer the default choice for web-sites and web startups. For some years this has been Rails, and with good reasons. Though I think a Wicket/WebBeans/Seam/JPA stack is as fast for development as Rails, Rails is a good choice for rapid development for a VC demo. The problems are down the road some years – or so I hear form some CTOs – and Grails might be a safer choice with the easy possibility to go to Java for your stable layer later.

The only large – and lets say profitable and growing – startup that uses Java is LinkedIn. Although some internal systems at FaceBook (Cassandra) and other sites run Java in their core, Twitter runs parts of it’s services in Scala. They show that it can be done. Contrary the German LinkedIn competitor XING is written in Rails.

With Rails and Python moving into the Enterprise, is Java no longer the default choice for new projects there? Not that I know of. Perhaps some grass root projects go with Rails, the default choice still is Java, C or C# depending on your enviroment. Beside some funny view on enterprise applications:

It’s been 10 years and there are still no compelling client side or desktop apps in Java and all the compelling server apps (sorry enterprise apps don’t count as compelling!) are done in PHP, Python, Ruby, Perl, Smalltalk et al.

I can’t see companies move their programmers and default choice to Ruby, Erlang, Python, Lisp or OCaml. As this would mean polyglott programming and as Alex Ruiz writes:

I haven’t seen any practical evidence yet to convince me this is a good idea.

For you as a developer, does dead mean you can’t get any more jobs in Java development? Looking at Dice

shows that Java jobs are still high, with a significant increase in 2008. The German news website Heise News showed the same for project work, a more than 89% increase since the beginning of 2007:

203 in Q1 2007

384 in Q3 2008

Is Java dead because other languages are better?

With a different angle we can discuss the death of Java in the view of it’s potential successors. As a matter of fact a language cannot die without successors, otherwise noone could develop any software. People suggest a lot of successors, some of them are:

  • Ruby

  • Python

  • Groovy/Grails

  • Scala

  • Fan

  • Erlang

  • OCaml

  • Ioke

  • Factor

Not all of them – although excellent and interesting languages – share the same goals as Java and fit into the same place. Ruby and Python seem currently not enterprise ready, mostly because of tools, skills and deployments. This might change in the future, we’re not there yet. OCaml and Factor are interesting and capable, but too far away from the procedural mainstream that is the C legacy. Most prospects have the JVM languages, Fan, Groovy, Scala, Ioke. Fan doesn’t seem to have succession ambitions, Ioke is specially designed as a testing ground for ideas. Scala and Groovy seem to battle it out as successors. Scala has momentum and hype, companies use it in enterprise environments – and it’s also my current favorite. Groovy looks stronger, it made some inroads silently in the enterprise and with Spring having bought the Grails committers – and now VMWare having bought Spring – it’s better positioned than before.

Those successors need to be better than Java, otherwise it would me a folly to replace Java with high costs and gain nothing. What does better mean?

  • Faster to write?

  • More cost efficient?

  • Higher maintainability, cleaner code?

  • Shorter code?

Most of them are faster to write because they have shorter code. As I’ve shown, Java is 1.7x – 4x bigger than Python in lines of code, but does that mean Java is dead?

Most comparisions take 5 to 10-year-old brownfield, legacy Java projects with hundreds of developers – many of them average – and compare them with 2-year-old Rails projects, where the initial developers – most of them excellent – are still on board. For a real comparison one would need to compare state of the art frameworks, Webbeans/Wicket, Stripes/JPA with rapid development frameworks like Rails and Django. I’ll spare this comparison perhaps for another post in the future, but would be happy if someone does a decent comparison. I consider this question open.

A Java successor needs to go through the enterprise. There is the main beef, the most money and the most developers. To die a language needs to die there. Enterprise software is used for longer periods of time, with many developers working on it. The longer time periods mean higher turn-over during the life-time. Were are the problems in the enterprise and how could successors solve them in better ways?

Enterprise pain points

  • Maintenance

  • Readability

  • Reuse

Do the potential successors solve those pain points better than Java? Partially. Some of them have richer reuse models, some of them have better readability and are less noisy. But I also consider this question open – from my experience with many languages those problems aren’t solved. Perhaps because many language designers today disdain the enterprise. Scala is a sweet spot for me, it gains on those issues but doesn’t introduce new problems.

Goals of Java and does Java no longer meet it’s goals?

What have been the goals of Java? Those are linked intrinsically to the success, so we need to take a look at them, and if those goals no longer represent what people need. Those goals are many, but the main ones seem to be:

  1. Solve problems of C++

  2. Internet capable

  3. Standard library – JDK

  4. Automatic Memory Management – GC

  5. No error prone pointer operations

  6. Enterprise-Ready – a goal that evolved after some time (easy to use, low entry, big departments)

  7. Easy concurrency in the language

I can’t see that those goals are no longer valid, or Java does no longer fulfill them. The goals are valid, and fulfilled. Only concurrency is the item which is highly discussed and can be an issue. Concurrency is the future. Concurrency can be an issue as the early lock and synchronize system of Java proofed to be too difficult. The new trend is multi-core. Is Java unfit for massive multi-core machines? Java in later editions added easier concurrency with concurrent lists, queues and fork and join and is fit for multi-core machines. No worries at least for me that Java misses this trend.

One requirement to a language wasn’t seen as important in 1995 as it is today: Rapid development and rapid turnaround. Java still falls flat, even with JRebel which allows seamless reloading of classes, RAD web frameworks like Wicket and splendid IDEs. Rails, Django and PHP are better and have a faster turn around. Period. Java is lacking here, and reloading changes look to be the biggest problem with Java development today. Maven deployments are a pain after you’ve worked with Rails or PHP..

Faster turnaround has higher productivity. Which means more money. If Java doesn’t solve this – Java might be on the way to extinction.

Why should it die, what should we learn?

Java might die, because the drawbacks beside turnaround have gotten too big. Lots of concepts have been proven to be bad ideas.

  • Inheritance: outside of frameworks, inheritance is inflexible, leads to tight coupling and is plain bad. Composition is most often a better choice. As are mixins and traits

  • Noisy syntax: Lately there has been the enlightenment that too much noise in a language is a bad thing. Java is especially noisy in closures (anonymous inner classes) and generics.

  • Null / NPE: Null as the default for object references was a billion dollar mistake. An object should by default need a value. Otherwise NPEs will proliferate through your code. Newer languages prevent nulls or make the null behavior the non default one

  • Design patterns: Many design patterns are a good thing, but some of them are just covering inefficiencies in an only-OO language like Java

  • List processing: As shown by functional languages, list processing should not be done in loops. Many operations in applications are just that: get a list, transform the list, filter the list and return a list. Javas new for loop is better than the old – but solves the wrong problem. Java should have native support for easy list processing, not via the – best we have – constructs in Google Collections.

Those are valid concerns and one wishes Java would die for those. But the Java community is working on fixes – although as can be seen with the discussion on Closures in Java 7 sometimes too slow. I consider those problems painful, but not big enough that they will lead to Javas imminent death. They could lead to a death by thousand cuts though.

Java Future and what does this mean for you

From what I’ve written  I come to the conclusion that Java is not dead. It’s not fundamentally flawed, it still meets it’s goal, there is interest in Java, no really clear successor has emerged, the platform evolves, the JVM shines, new languages flourish and new projects are started in Java.

But just because Java is not dead doesn’t mean it has a future. Developers need to open their eyes and learn new languages. I’m really disappointed in interviews when candidates show no interest in programming beside Java. So for you as a developer: no worries. As a student: You still need to learn Java to have a high probability to get a job – with the conditions you like. For you as a manager or CTO: have a plan ready for when the Java era ends.

It’s too early for a requiem. But if Java dies, what can we learn? Before and foremost one needs to learn from Javas success and eventual decline. The points I’ve written about, wrong concepts, enterprise pain points and what Java did right need to be remembered.

Is Java dead because no-one talks about it anymore?

Thanks for bearing with me through this long post and we now come to an end. Jitter about Java has significantly gone down. My blogging on Java has gone done. My twittering on Java has gone down. Some years ago everyone was talking about Java, now it’s mainly enthusiasts. Java is a none-hype. It’s not as bad as COBOL, but a lot like C and C++. Is a language dead when none talks about it anymore? You decide. In the end the only question that really matters: Is Java dead for me? Would I start a project in Java? I would have in 2008. Would I in 2009? Probably not, I’d use Scala.

You can leave a Reply here.
Of course, you should follow me on twitter here.

Interesting thing to ponder is Java as a language vs. Java as a platform. Java as a platform isn't going anywhere, and the fact that so many more "modern" (funny to think of Java as not modern now ...) languages can be run on the JVM shows that there's value in the platform.

I also think there's still a lot of value in the language and when you look at some of the alternatives, I think we'll see Java as a language around for a long time to come. Nothing else fits in the space Java does quite as well.

Monday, September 14, 2009

I'm Having a Crisis of Faith After a Weekend with Grails

I have a confession to make: I cheated on CFML this weekend. And I enjoyed every minute of it. Heresy, I realize, but if you stick with me through this brain dump I hope you'll see that despite the sharp criticism contained herein, I'm extremely optimistic about the future of CFML. We just have a helluva lot of work to do.

To set the stage for things, I'm embarking on a side project with a friend of mine and as usual it's a big job with a tight deadline. None of this is anything new and previously I wouldn't have thought twice about which technology to use. CFML: Now More Than Ever. (Sorry, I just love that bumper sticker.)

I've been taking several runs at Grails over the past year or so, and with a semi-free weekend I decided to re-read a few books and some issues of GroovyMag. Basic requirements for the aforementioned project in front of me on Protoshare, I figured I'd give myself an hour to get a couple of the domain classes up and running in Grails. I downloaded fresh versions of Groovy and Grails and set off to work.

I didn't need the whole hour. I didn't even need half an hour. About 10 minutes after getting everything installed, and this included reading a couple of refresher instructions (and truth be told I ate a little sushi while doing all of this), I had my basic domain classes that involved a one-to-many relationship done, persisting to a database, tested, and the basic Grails master/detail views and CRUD functionality up and running. And before you think an IDE of some sort was lightening the workload, I did all of this in a terminal using vi.


Granted, I've done this sort of exercise before so Grails wasn't totally new to me. For someone new to Grails you might have needed the whole hour. ;-) Previously though, I'd screw around with inconsequential "Person" or "Book" or "ToDo" classes and think, "Impressive, but if I were doing this for a real application there'd be much more to it." But this time around I was starting at square one on a real project, so in my mind I was looking at Grails from the standpoint of building a real application with it.

I proceeded to build out more of the application, fully expecting to lift up a stone and find some nastiness I couldn't live with, but the hidden gotchas never came. Grails simply delivers.

A Concrete Example

Before moving on to my counterpoint that sets up the rest of this post, let's take a quick detour to see how Grails does what it does. To prove I'm not blowing smoke, this--literally and with no omissions--is what you have to type in a terminal to have this working Grails application up and running. (Be nice if you add stuff there. Your mother might read it.)

First, you create the application and have Grails generate a couple of objects:

grails create-app UserTest
cd UserTest
grails create-domain-class User
grails create-controller User

That creates the application and two files, User.groovy and UserController.groovy.

You then add this to User.groovy:

String email
String firstName
String lastName

You then add this line to UserController.groovy:

def scaffold = User

And finally, you run the application:

grails run-app

That's it. You've just built out the basic CRUD operations for a User class in about two minutes. And if you don't like the terminal, NetBeans makes this even easier.

Want to deploy the app to another server? Type:

grails war

Then drop the generated WAR file on any Java servlet container. Granted this is using HSQLDB at this point, but having it point elsewhere is a matter of tweaking a DataSource file and setting your production database to whatever you want. Grails is smart enough to handle different environments (e.g. development vs. production) and use the production database settings when you generate a WAR. (Yeah, they pretty much thought of everything.)

Stark Contrast

Back to my experiment. With some basic functionality for my app up and running so quickly in Grails I decided to open up Eclipse and go through my usual process of developing this same functionality in CFML. I'll be completely honest and say that this is not a fair fight, which kind of gives away one of the punchlines of this post, so read on ...

I haven't ever been a real fan of any of the code generators available for CFML, nor have I ever delved much into the CFML ORM tools. This is not a slight against the authors of those tools in any way; I've just always preferred to do things by hand. I do use Peter Farrell's Rooibos Bean Generator regularly since writing beans is pretty much the definition of drudgery, but my Mach-II listeners, my service layer, my DAOs, etc. have all been written by hand.

Why? Because I'm a control freak. Every time I'd try a code generator or ORM I'd be thinking, "That's not exactly the way I'd write it," or I'd be wondering what the heck the ORM was doing under the hood, or I'd be concerned about performance with an ORM, or any number of other excuses, so I never made the leap. I didn't want to give up the control. And I type fast enough and have done enough of the basic grunt work that it's not as if I was adding a ton of time to my projects. A few days on most typically sized projects for me and the basic plumbing would be done. Not so bad.

To even begin to approximate the Grails test I started from scratch with the CFML application as well, other than my existing Eclipse/CFEclipse and Tomcat installation. (For those who aren't aware, Grails comes with literally everything you need to run it including Jetty.)

I downloaded an Open BlueDragon WAR, Mach-II, the Mach-II Dashboard, the Mach-II skeleton, and ColdSpring ... all the familiar faces I'm used to seeing in most of my projects these days. I then set out to write all the same code that existed in the application that Grails scaffolded for me, which involved:

  • Creating a database (I used H2 to keep things simple)
  • Creating two domain classes with a one-to-many relationship between them
  • Creating a controller for each domain class
  • Creating a list view and the related queries for each domain class
  • Creating an add/edit form and the related queries for each domain class
  • Creating unit and integration tests for each domain class

In short, all the stuff you'd need to get a nice head start on the backend of any web application, and nothing more than what Grails gave me in 10 minutes.

I downloaded files. I unzipped files. I moved files around. I edited config files. I wrote code. I edited more config files. I wrote more code. I wrote a lot of freaking code.

A couple of hours later, I had something that approximated my stopping point on the Grails experiment. But it wasn't as nice, and I had to be honest with myself: it was a horrendous amount of work by comparison.

I didn't even get to the testing part, for which I would have had to download MXUnit and create test CFCs and functions. I gave up and went to bed.

It's All Relative

Before people think the situation is too dire, let's keep things in perspective. Creating a working prototype of a couple of major pieces of a web application in a couple of hours really isn't that bad in the greater scheme of things. As I said earlier, it's not as if we're talking about adding weeks to a project schedule by doing things this way (though I suppose on huge projects time spent here would add up). And of course if all I wanted was pure development speed I could have done old-school CF 5 style development and been done with it, but that's not a good way to lay the foundation for a extensible, maintainable application.

On the other hand, everything's relative. After the instant gratification from Grails I had to face the fact--and I hope everyone understands how difficult this was for me--that working with CFML was like running in bare feet on the sand, and working with Grails was like having that jet pack we've all been promised for so long.

I didn't plan on winding up where I did when I fired up Grails the other night. It's not as if I'm fed up with CFML and was looking for something different, and I had no intentions of taking a bit of a hard right turn on this particular project and going with a technology that truth be told I'm still not all that familiar with. But here I am. And I'm not sure I can look back.

No, This is Not One of "Those" Blog Posts

I'm not going to make a big speech about how I'm "leaving CFML" to raise a ruckus and get some attention. I care a great deal about the future of CFML or I wouldn't spend so much time on it. But the longer I've been in this business, and the longer I've been using CFML, and given all the tools and languages I've seen come and go over the years, I've become a lot more pragmatic than I used to be.

I've gone down a couple of dead-end paths over the years (any REBOL fans in the house?), and although each of us tend to have what amounts to a love affair with a particular language--the one we keep going back to time and time again, and the one that will always have a special place in our hearts for more emotional that practical reasons--we owe it to ourselves and the technology we love to be open to other possibilities, and to be brutally honest when something comes along that just plain works better. Admitting that isn't admitting failure: it's admitting that you care.

If we don't ever look outside our own little world, preferring instead to contemplate our navels, live blissfully in Lake Woebegone, and engage in full-blown siege mentality when we're threatened, then I'm sorry, that's not being dedicated to the technology we love. That's coding while Rome burns.

I realize this sounds pretty dismissive of CFML. It's not, but that's another punchline coming a bit later. CFML is the first programming language I learned after HTML, and 12 years later I'm still using it and still extremely excited about where it's going, particularly with the shiny new open source movement in CFML.

All this being said, I simply can't shake the experience I had with Grails the other night. The contrast between a sophisticated, well-thought-out, extremely well-executed, comprehensive framework like Grails (not to mention the elegance of the Groovy language) and the comparable tools we have available for CFML is too striking to dismiss or ignore. And again, that's not to denigrate the fantastic work anyone does on any of these tools. Remember, I'm involved with some of them myself and I don't plan on stopping those efforts. They're great at what they do, but what they do is no longer enough.

As I mentioned earlier I've taken a few stabs at Grails so I'm not quite sure what was different last night. Probably a whole lot of thoughts and directions and changes in my attitudes about things came together in a particular way and at a particular point in time and space, but whatever the reason, Grails opened my eyes wide last night, and I simply can't dismiss that. To quote one of my favorite movies, "How you gonna keep 'em down on the farm once they've seen Karl Hungus?"

What Changed?

If I'm totally honest with myself, probably the biggest change in my attitude towards development these days is I just want things to work. After writing CRUD code for so many years, not being willing to give up any control, and convincing myself I was doing my application a favor by writing every single line by hand, I'm tired.

CRUD crap (is that redundant?) is a commodity. Basic object generation is nothing more than a means to an end. Your users don't care a lick about your hand-crafted, finely tuned SQL, or your oh-so-clever service layer, and if you do, I'm reminded of the old adage about peeing your pants: it may give you a warm feeling, but no one else cares. Users want something with a great front end because to them that IS the application. As long as it's easy to use, it works, and it meets the applicable performance and scalability requirements, the application is successful.

So given the finite amount of time we all have, why would we consciously choose not to use a tool that does the commodity stuff for us so we can focus on the front end and business logic? I know SQL pretty well but I can't say I enjoy writing SQL. It's just something I felt I had to do. Same with so much other boilerplate crap. But if I had my druthers, I'd focus more on business logic and UI functionality and have all the persistence nonsense and a lot of the other drudge work handled for me. Not to mention the fact that when I'm using best-of-breed tools to do this, I can rely on the fact that the underlying code has been battle-tested by thousands of users. I can't say the same for my own persistence code until I put the app into production.

Grails isn't only about GORM of course. If I just wanted an ORM I'd use Transfer, and ORM capabilities are coming in ColdFusion, Open BlueDragon, and Railo. But Grails is about much more than ORM. ORM alone only gets you a fraction of the way there.

The real secret to the Grails sauce is how overwhelmingly compelling the entire package is, from the Groovy language itself, to GORM, to the fantastic flow and incredible speed of the entire development and deployment experience, to the powerful front-end tag library, to the integrated testing, to the sophisticated and dead-simple AJAX functionality ... I could go on. The point is Grails is a complete pleasure to use from top to bottom, and I'm finding it increasingly difficult to talk myself out of taking it seriously.

Apples and ... Different Kinds of Apples

Thus far you may have been thinking, "Is this guy a moron? He's comparing a language (CFML) to a framework (Grails)." To a point, that's true. But when I'm comparing Grails to CFML I'm just using CFML as a short-hand way of referring to the tools available in the CFML world. So I'm really comparing Grails as a package to the disparate bits and pieces that create some semblance of Grails-like functionality in CFML.

Take Mach-II for example, which in my incredibly biased opinion is the finest MVC framework for CFML. ;-) Peter Farrell, Kurt Wiersma, Brian FitzGerald, and I spend a ton of time on Mach-II, not to mention all the great help from our community, and it's a damn nice framework. It continues to get better with each release, and with caching, logging, the dashboard, the new front-end tag libraries, and everything else we've put into Mach-II and have planned for future releases, it's a really compelling package.

One of many things that struck me as I've been working with Grails is how the basic constructs of Mach-II map one-to-one with Grails. Grails has "controllers," Mach-II has "listeners." Grails has a flash scope to persist data across redirects, Mach-II has the same. The Grails docs talk about how to keep your controllers dumb and use a service layer for your business logic, just as we advise in Mach-II. Even the Grails code I've been writing, particularly the controllers and services, looks eerily similar to the Mach-II code I write. This is probably why I've found myself surprisingly comfortable in Grails so quickly.

But Mach-II is only one piece of the puzzle. To manage dependencies, we need to grab ColdSpring and wire everything together in an XML config file. If we do want ORM, we have to grab Transfer or Reactor and again, more configuration. Then we grab MXUnit for testing, and it's yet another piece of things that knows nothing about any of the other pieces of our puzzle until we explicitly tell it. If we want to do functional testing we grab Selenium. And round and round we go.

Ultimately it's not that we lack the tools in the CFML world that give us the ability to do what Grails does. Heck, Grails is based on Spring, Hibernate, JUnit, and other best-of-breed tools in the Java world, so it's not as if the Grails authors created this entirely from scratch.

What we're missing in the CFML world is flow, and without good flow you simply don't have good productivity.

Integration, Integration, Integration

I won't belabor this point too much since I've made it in other ways a couple of times now, but the magic of Grails is the cohesiveness with which all the various bits and pieces of the web development process have been integrated. MVC, DI, ORM, unit and integration testing, functional testing, i18n, AJAX, deployment, documentation, even a run-time environment ... literally everything is contained within Grails, and it all works seamlessly. It's magic.

This elegant integration of what in the CFML world are still very disparate tools is what makes Grails such a joy to work with. I've never experienced a better development workflow than what I can achieve with Grails, and this leaves me free to focus on the things that matter most to the success of my application. And for simple applications I can crank stuff out more quickly than ever before.

That's what I kept coming back to as I fought with myself over whether or not to use Grails for a real-world application. In the end, it's all about the success of the application and how I can do the best job possible in the shortest amount of time. Much as I love CFML, in this case Grails won out. Even with my years of experience with CFML and relative lack thereof with Grails, I had to have a heart-to-heart with my friend (after the one I had with myself) and tell him that I truly believed I could get things done more quickly and with a better end result than I could with CFML, at least for this particular project. After showing him a demo or two of what Grails can do and writing some live code to show I had nothing up my sleeve he, another long-time CFML developer, had to agree.

Yes, it's a poor craftsman who blames his tools. But you sure can cut the grass faster with a lawnmower than you can with a pair of scissors.

Why Grails

I'm well aware that this is the honeymoon period between me and Grails. I'm sure we'll fight. But I'm equally sure we'll make up. The real test will be building an actual application with it, and I'll have a lot more to say as I do.

At least at this point in my experience with Grails, it strikes the perfect balance between taking the drudge work out of web development while still letting you have full control over the stuff that matters. This is the promise of CFML, but compared to Grails we're not there yet.

As for going with something like Spring, I like Java, I really do, but Java Sucks Ass. It's documented. (Be sure and read the follow up post to that one.) So Groovy gives me a faster, dynamic version of Java, and Grails gives me a fantastic toolkit to get great stuff done quickly. This way I keep what I love about Java in the mix without having to make a massive sacrifice in productivity.

Can Ruby on Rails do all this stuff for you? Sure. Grails used to be called Groovy on Rails (no way!) until DHH requested a name change (at least that's what wikipedia says), so clearly the Grails folks thought Rails had a ton of good ideas in it. I've also dabbled in Ruby and Rails a bit over the years, but as a language Ruby just doesn't do it for me. I'm sure many people out there love Ruby, and that's fine. For me Grails is a much better fit, not to mention the 100% seamless integration with Java when I need it.

Why Doesn't CFML Have a Killer Framework Like Grails?

Honestly I'm not even sure the "why" even matters. I have some ideas about why CFML isn't farther along than it is given its lengthy history, but I'll save those for another post. Fact of the matter is we have the makings of what could be a great development experience, but we don't have the whole enchilada. Not by a long shot. We deserve better. We can do better.

What would make up a Grails-like framework in CFML? Here's the basic pieces:

  • CFML runtime
  • MVC framework
  • ORM framework
  • Logging
  • Caching
  • Unit and integration testing framework
  • Front-end/functional testing framework
  • JavaScript/AJAX framework
  • Templating engine
  • Command line tools for code generation, scaffolding, deployment, etc.

If you're saying "we've got all that," on most points you're right, and with the view tag library in Mach-II 1.8 we're even getting there on the templating engine front. But we're still lacking all of this in a single easy-to-use package that increases our productivity in CFML by leaps and bounds. One could argue there's still less typing in CFML than in other languages, which is a dubious argument at this point given things like Ruby and Groovy, but we're still lacking the proper tools to truly make developing an application, not just writing code, far more productive in CFML.

So let's go down the list and figure out how we'd make this happen.

Building the Perfect Framework

You can't run CFML without a CFML runtime, so the CFML engines are certainly part of the puzzle. My only cautionary statement here is we can't rely on them to give us the CFML version of Grails. In my opinion that isn't their job. To create a development experience similar to Grails, having the ability to easily plug in and distribute (that's key) a CFML runtime is crucial. The distribution part is where Adobe ColdFusion is a non-starter, but of course the magical CFML framework that exists in my head would allow you to choose OpenBD or Railo as your runtime, and those could be bundled, or you could plug Adobe CF in after the fact if you so choose. To me having everything in a single downloadable package eliminates one more headache and much more closely approximates what you get with Grails.

ORM is another piece of the puzzle. We have Transfer and Reactor now, and we have ORM support being baked directly into the CFML engines as we speak. Again no offense to the Transfer and Reactor folks, but I think once Hibernate, or JDO, or some other implementation of the JPA is baked into all the CFML engines, or even just available as a seamless add-on to CFML, we'll have a much bigger step forward on this point. I've used Transfer a bit and it works great, but there's no substitute for the thousands of man hours of development and testing, not to mention the wide usage, of the ORM tools in Java. Java's just a much bigger pond and I think we can benefit greatly from leveraging it whenever we can.

As for MVC, here's where I'm going to get myself into trouble, but I don't think the CFML world needs a dozen MVC frameworks like we have now. The CFML community is way too small to have so many people spending so many man hours reinventing the same wheel over and over again. Now of course I'll admit my bias and say I think as a whole Mach-II gets us closest to the final result we need, but ultimately what I'd like to see is all the framework authors working together towards a common goal even if the people behind the various frameworks still choose to do things their own way. Maybe the magical framework in my head exposes an API that all the MVC frameworks implement so you're free to pick your poison on that front as well. (As you can tell, I'm still thinking through how all this would work.)

As for the rest of the pieces the choices are obvious. For JavaScript and AJAX, jQuery would be rolled in but you could use another framework if you choose. Pluggability is key here as well. Mach-II is well on its way to having a full templating engine built in, but there may be other projects out there in CFML land that I'm not aware of. For unit testing we have MXUnit. For front-end testing we'd have to leverage something like Canoo, or maybe Selenium is equally configurable and scriptable (haven't looked at it in a while).

Command line tools are where things get interesting since you can't run CFML commands from a terminal. (Anyone working on that?) So, two thoughts come to mind. Either this is all web-based, which is OK, or Java and ANT are used to do the command line pieces. Maybe we have both options. (I can ask for the world when this all exists only in my head.) I do think the command line bit is key, not only because I like working that way, but because it's a faster, easier way to do things than clicking around on web pages.

So put all this and some awesome scaffolding together and you're done! Yes, I realize what I'm proposing is a tremendous amount of work. Grails was three years in the making before it hit 1.0. So it's not that it can't be done, we as a community of framework authors and CFML advocates just need to commit to making it happen and start chipping away at the mountain of work involved to get there.

The Punchlines

I said I had some punchlines, and though you've probably assembled then in your head by now after reading everything to this point, I'll just enumerate them so they're more, uh, punchy.

  1. Grails kicks ass, and we deserve something this awesome in the CFML world. We should have had it by now. We don't need more frameworks, we need to demand more from our frameworks.
  2. We need to collaborate more as a community and work towards common goals instead of everyone being off in their separate caves cranking out code that does the same thing as what the guy next door is writing. Specifically I'm targeting those involved with framework projects, myself included. I'm not even necessarily proposing one framework to rule them all, but it does seem a bit silly that as a relatively small community we spend such a huge amount of time and effort to wind up with such subtle differences in how the various frameworks do their respective jobs.
  3. We need a vision. I've tried to present one here, although as you can tell at this stage it's still a bit cloudy. But we need to open up the dialogue and remove our egos and biases from the picture and answer the question: What would the perfect set of tools for CFML development be?
  4. We need an action plan. I haven't thought that far ahead quite yet, but the first thing that comes to mind is a framework authors mailing list. Maybe there already is one. And it's key that this discussion be completely open and anyone who has interest, framework author or not, can participate. From these discussions we can quite easily come up with a high-level, concrete set of tasks and goals and get to work. I'm not saying it's going to be easy, but on the other hand I feel like we have all the basic building blocks available, so how hard can it be? ;-)

Who's With Me?

If the ideas in this post scare you, good. They're meant to. But they're also meant to motivate you. If you care about CFML as much as I do, then I hope you have the courage to admit that we're falling behind and that we need to do something about it. This doesn't mean blogging, and twittering, and conferencing, and defending CFML against all enemies domestic and foreign, and all the rest of the community-oriented stuff we all do. This means coming together as a group, knuckling down, and doing some seriously hard but even more seriously rewarding work from which we all will benefit.

We can do this. We need to do this.

Total Eclipse of the Heart: Literal Video Version

"Mullet with headlights." Absolutely brilliant.

Saturday, September 12, 2009

Enabling Java on Firefox on Ubuntu

Since I never remember how to do this, I figured I'd put it up here. This assumes you already have Java installed, and note this is for 32-bit. I'll be getting a shiny new 64-bit laptop very soon, and from what I understand things are a bit different on 64-bit.
  1. In Firefox, go to Edit -> Preferences -> Content and check "Enable Java"
  2. Quit Firefox
  3. In a terminal, cd to /path/to/firefox/plugins. On my machine and for my current version of Firefox, this is in /usr/lib/firefox-3.0.14/plugins If in doubt, locate plugins | grep firefox should narrow it down.
  4. Create a symlink to the Java plugin. Your path to Java may differ, but on my machine I did:

    ln -s /usr/share/java/jdk1.6.0_14/jre/plugin/i386/ns7/
  5. Restart Firefox
Apparently on 64-bit the i386 directory under jre/plugin doesn't exist, but there are some solutions. I'll have to verify when my 64-bit machine (complete with 8GB of RAM and a solid state drive!) arrives.

What's the New York Times Doing with Hadoop?

Interesting yet very brief interview on what the New York Times is doing with Hadoop. It's always fascinating to me to read about the tools and approaches people use with the level of scalability most of us don't have to worry about. Also interesting to me is the MapReduce functionality in Hadoop since it's the same idea used by CouchDB views, and I'm absolutely loving the bit of work I've been doing with CouchDB.

Nirvanix Support in Open BlueDragon

More exciting cloud support has just been added to the nightly build of Open BlueDragon! This time around it's full support for the Nirvanix Storage Delivery Network. Read more in the announcement on the OpenBD blog, and full usage notes are on the OpenBD wiki.

Nirvanix is similar to Amazon S3, which OpenBD also supports, but Nirvanix offers the ability to create child accounts that can be limited by storage capacity and bandwidth. Nirvanix also has fantastic functionality form media files such as audio, video, and photos, allowing you to convert file formats, resize, crop, etc. all from Nirvanix.

Cloud computing is seriously powerful stuff, and we're making all this power available across multiple cloud services right from within OpenBD.

Thursday, September 10, 2009

OpenBD Google App Engine and cfc's - Paul Kukiel

In my previous OpenBD on Google App Engine post I mention there is no relational database ( yet ) for OpenBD on GAE. There is however the ability to write and save objects directly to Googles Data Store. This sort of feels like working with an ORM but it's even more abstracted as there is not actual database that we can see but we can put objects in this place and run simple queries against the data sets.

Here is a code snippet:

Persisting Data:

  3. cfset v = createObject("component","Visitor").init() />  
  7. cfset v.setFirstName("Paul"/>  
  10.       in a collection called Visitors --->   
  12. cfset googleWrite(v,"Visitors"/>  
  17.       This will return an array of Obhjects ( cfc's ) that are 
  18.       in the datastore in the Visitor collection    --->  
  20. cfquery name="dataStoreQuery">  
  22. select  
  24. from Visitors  
  26. cfquery>  

from Visitors

Notice I must use variable.VariableName rather then cfproperty name="variableName this is explained here.

Here is a small application to demonstrate this in action:

Click Here for a live demo.
( Yes it looks like UniCode just works :) )

Being that it lives on Googles servers the application should be very fast and I expect Googles connections to be very fast you'll notice I do a cfhttp call in every page request you almost don't even notice it's happening.

I really have no metrics to judge/comment on the performance of the datastore but I am working on a project with Rob Parkhill which will make use of the datastore or the SQL engine that's being built so I may have something to report in a few weeks/months.

Here is the official OpenBD wiki entries on the datastore.

Here is the sample app code:


Great intro by Paul to some very slick stuff with OpenBD on GAE! Make sure and read the comments--Vince is working on making this syntax compatible with the ORM functionality in CF 9.

Bypassing Windows Security Checks in Firefox 3

Firefox 3 now respects any Windows security settings, such as not allowing you to download MSI and EXE files. Better security if you don't know what you're doing, sure, but annyoing when you're trying to download a bunch of stuff to configure a new Windows server.

Easy fix without changing the Windows security policies at the OS level is to open a new tab in Firefox, and in the location bar, type about:config and hit enter. This will bring up Firefox's configuration settings.

Right-click anywhere and choose "New" then "boolean." For the name of the new config setting, type and set the value to true. Hit OK and you're done--no need to even restart Firefox.

Lots more about the Firefox settings related to downloads and security can be found on the site.

Pigeon Turns Out to be Faster Than S. African Net writes "The results are in: it's faster to send your data via an airborne carrier than it is through the pipes. As discussed Tuesday, a company in South Africa called Unlimited IT, frustrated by terribly slow Internet speeds, decided to prove their point by sending an actual homing pigeon with a "data card" strapped to its leg from one of their offices to another while at the same time uploading the same amount of data to the same destination via their ISPs data lines. The media outlet reporting this triumph said that it took the pigeon just over 1 hour to make the 80km/50mile flight, whereas it took over 2 hours to transfer just 4% of that data."


Reminds me of the old "never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway" quote.

Wednesday, September 9, 2009

ColdFusion 8 on Snow Leopard

I did a clean install of Snow Leopard on my Mac Pro, and although I do 100% of my work on Linux these days, many of my colleagues use Macs so I thought I'd give installing ColdFusion 8 a shot.

First problem is the CF 8 intsaller won't run without Rosetta, which is an emulation layer that allows Universal Binaries to run on Snow Leopard. (For those of you who aren't aware, Snow Leopard does not run on PowerPC-based Macs.)

I decided not to install Rosetta, so that's a non-starter. From what I understand if you have Rosetta it does work, but the JRun web server connector doesn't. This is exactly the same as it was with CF 7, when you had to get the web server connector source code and compile it using Xcode. Not a big deal, but I don't use JRun anymore and since it's more or less a dead product at this point, I really encourage people to investigate other servlet containers like Tomcat. Short answer is it's not worth my time to even worry about the web server connector.

So what to do? Since this is all Java you can use a WAR file generated on ANY machine, deploy it on Tomcat, and you're good to go. I grabbed a WAR from my Ubuntu laptop, dropped that in Tomcat's webapps directory, and it runs fine.

Just thought I'd throw that out there as another approach since in the big of Scroogling I did on the issue, it seems people are just twiddling their thumbs waiting for Adobe to release a patch for Snow Leopard.

Why wait? Scrape up another machine somewhere, fire up a VM, or beg a friend who's not running Snow Leopard to generate a WAR for you, and move to a much more flexible development environment than you get with the standard ColdFusion install.

Tuesday, September 8, 2009

Startup Script for Tomcat on CentOS 5

The final step of my VPS migration was to move the Tomcat startup script I created in /etc/init.d over to the new VPS.

Unfortunately my old script didn't work on CentOS 5. Fortunately, I found this one that does!

So with that, I think I'm finally moved to the new VPS. Couple of lingering issues (MySQL storedprocs, some weird proxying stuff with my blog URL), but overall things went pretty smoothly.

Logitech Performance Mouse MX: Best. Mouse. Ever.


I won't get all gushy about the Darkfield Laser Tracking because I don't care about that feature. What I do care about is they finally have the form factor of the MX Revolution mouse that I love with the tiny little USB receiver of the VX Nano that I love. If you haven't tried the scroll wheels on the new Logitech mice you're seriously missing out--like buttah.

Flex Architect Position Available

Contact Doug Pajak ( for more information.

This Role requires expertise in Flash/Flex Development. This position will work closely with Product Managers, Designers, User Experience and Creative Teams to deliver hot, cutting edge web and client based applications and affiliated presentation components.

For this role we require the following:

1. Minimum of 3+ years of Flash/Flex Development working on Major Flash RIA
2. Strong command of ActionScript 3.0 and OOP
3. Experience working with Flash Apps that use XML and Server Side Technologies (including an understanding of XSD/DTD for validation.
4. Understanding of Flash Memory Management
5. Solid understanding of Web Browsers
6. Ability to mentor and coach others in Flash/Flex

We would like to see a portfolio, or some other way to show us your work.
This role will be very visible and you can be assured that you will be working on projects that are substantial.

Our client is extremely well-known and offers a truly fun and casual work environment. You'll be in a team of highly talented and creative developers.

Steps for Migration to New VPS at Viviotech

I just completed the migration from my old VPS to a shiny new one at Viviotech and I figured I'd actually document things this time. I've done this a couple of times before with Viviotech, but since this is a bigger move it's a bit more manual this time around. Since I'm being moved from a FreeVPS server to a Xen server the VM image itself can't just be ported over, which means moving files, mail, configuration, databases, etc. all manually. Honestly this is probably a good thing since it gives me a chance to do some serious cleanup.

Another big change with this move is there's a new Kloxo (formerly Lxadmin) administration console. Previously they were using CP+ but I still did all my configuration by hand. Kloxo is a bit more draconian about having control over config files for Apache, but I dig into that later in this post. Kloxo is a much nicer admin console than CP+ (and since there hasn't been a release of CP+ since 2007 I think it's probably dead ...) but Kloxo does have some different concepts to be aware of.

So, here's the steps I took. Even if you're not going through this yourself hopefully they'll be some interesting info for future reference, or you'll gain a few Linux tips if nothing else. And thanks to Tim, Mark, Jordan, and everyone else at Viviotech for answering my questions as I went through this. I'm continually impressed by the level of service those guys provide. Best in the business bar none.

Step 1: Create User Accounts
I have a couple of freeloading friends using my VPS for some things (just kidding--they know I don't mind), so I set up user accounts for them on my server. This way they have their own directory, I can set quotas if I feel like it, and I don't have to give them root access unless I need my Linux sysadmin friend to fix something for me, which is a fair trade for giving him some space on my server.

In Kloxo they deal with users a bit differently than I was used to. Kloxo has the concept of "Clients," and clients can either be "Resellers" or "Customers." A customer account is the equivalent of a regular user account, so when you create a new customer they'll get a home directory, a web site, an FTP account, a mail account, and you can set features on the account like what they can and can't run on the web site, as well as put any quotas you need in place. Customers can also create additional domains if you allow them to.

Resellers are a bit different in that resellers can have customers under their account. Since I don't need reseller capabilities I used the customer option for creating all the accounts I needed.

When you SSH into the server you'll see the usual stuff, meaning a home directory for each user, and under the home directory they'll have a directory for each domain that is associated with their account. This is a really quick process and seems much less klunky and error-prone than with CP+, so overall I think Kloxo is definitely a step up.

Step 2: Move Files
This is probably obvious but since I'm moving about two metric tons of files from the old server to the new one, there's no way FTPing everything down to my local machine and FTPing back up was feasible. Since both servers are in the same data center, moving directly from one to the other is much, much faster.

SCP is a great tool for this job. You could also just FTP between the two servers but FTP is a lot less elegant for mass file moves like this.

So I sshed into server 1, navigated to the various directories, and scped all the files over:

scp -r -P port_num source_dir user@server2:target_dir

Again, since both servers are in the same data center this is amazingly fast. I gotta wonder about my one friend who has 9GB of stuff in his home directory, but I won't ask. ;-) Even that much data didn't take more than a few minutes to transfer.

Repeat scp as necessary to move things from the home directories on the old server to the home directories on the new server.

Step 3: Database Backups
I use MySQL exclusively on this box so this step was pretty easy. SSH into server 1, log into MySQL, and backup all the databases:

mysqldump -u username -p --all-databases > filename.sql

SCP that file over to the new server and restore it to MySQL on the new server:

mysql -u username -p < filename.sql

I still can't get over how much easier that is than dealing with SQL Server.

You'll also have to set the appropriate permissions on the databases once they're loaded up on the new server, so don't forget that step. (I'll assume if you use MySQL you know how to do that, or it's easy enough to Scroogle.)

One final thing I still haven't solved is that my storedprocs in MySQL throw a "Error occurred attempting to prepare the Call Procedure" error when they're run from OpenBD. The permissions are fine, and I can even run the storedprocs from the MySQL command line tool. At first I thought it was the MySQL driver, but I tried three different drivers and no luck. I'll follow up once I get that figured out, but if anyone has ideas I'm all ears.

Step 4: Tomcat and Open BlueDragon Installation
The new server already had MySQL and Apache on it so I didn't have to install those myself, but since I use Tomcat and Open BlueDragon I needed to get those set up.

Getting these running in and of themselves was as dead simple as usual: download Tomcat, Java, and OpenBD, and you're off to the races. Hit things at {server_name}:8080 to make sure Tomcat's working on its own. During this migration I was reminded again of how much I love working with OpenBD. Since I have each of my OpenBD sites completely self-contained, moving them to the new server meant copying files. That's it. No messy installations and configurations, I just drop files in Tomcat's webapps directory and I'm done. Complain about Java as a language all you want, but one thing Java gets absolutely right is web app deployment.

So all this went smoothly, but configuring Tomcat to work with Apache in the new Kloxo world was a bit different than doing it by hand.

Step 5: Apache Configuration
When you create web sites from Kloxo it likes to put the root directory for the site under a client's home directory. This is OK, particularly for plain HTML sites, but since I run most of my sites from Tomcat I personally prefer to have everything living under Tomcat's webapps directory.

You have a couple of options here. Depending on what you're wanting to accomplish, what will and won't work given your situation, and your preferred way of doing things, you could turn the home directory for the domains (e.g. /home/mwoodward/ into a symlink to the appropriate directory under webapps. Follow symlinks is enabled for virtual hosts when you set them up via Kloxo so this will work fine.

I use AJP proxying with Apache and Tomcat, however, so I left the home directory alone and added the proxying information to the virtual host entry. More on that below.

As far as general Apache configuration goes, Kloxo will overwrite the virtual hosts sections of config files, but the basic stuff like enabling/disable modules, etc. Kloxo leaves alone. So you can set up new web sites easily from the Kloxo interface, but still do higher-level server configuration in the config files themselves, which is a nice compromise.

For the AJP proxying, mod_proxy_ajp was enabled by default so I was in good shape there. One thing I do notice is that compared to Ubuntu anyway, the Apache setup on CentOS is a bit odd. I have Apache 2.2.3 installed on CentOS, but this install seems to follow the "older" way of doing configuration. By that I mean there is still a monolithic httpd.conf, and it doesn't have the mods-available, mods-enabled, sites-available, and sites-enabled directories that I'm used to with Apache 2.2+ on Ubuntu.

With Kloxo the configuration files are in a bit of a different place than you may be used to. Most of the files are in the typical /etc/httpd directory, but the virtual host config files are handled a bit differently. The httpd.conf still handles all the top-level server configuration, and it also includes /etc/httpd/conf/kloxo/kloxo.conf.

The kloxo.conf file in turn includes several config files under /etc/httpd/conf/kloxo, most of which you won't have to mess with. One of the files that is included is virtualhost.conf, and virtualhost.conf enables NameVirtualHost on ports 80 and 443, and then includes individual virtual host config files for each web site. The individual virtual host config files are stored under /home/httpd/{domain}/conf/kloxo.{domain}

These individual virtual host files are where you can get into trouble with Kloxo overwriting things. If you want to take full control over the config files yourself and not let Kloxo modify the files, Tim from Viviotech gave me this pointer--you can change the attributes of the file to be immutable:

chattr +i /path/to/config/file.conf

Then when you need to edit it, just change that back before editing:

chattr -i /path/to/config/file.conf

And of course change it back to immutable when you're done so Kloxo can't overwrite anything. As long as Kloxo only messes with virtual host config files this shouldn't be necessary--being able to click a button in the admin panel to get someone set up is definitely pretty nice.

Having individual virutal host config files seems messy at first, but from the standpoint of each site being discrete from all the others it makes sense, and certainly makes Kloxo's job of managing the files a whole lot easier.

So if you don't want to touch the virtual host config files but need to add something like AJP proxying info to a virtual host, you CAN edit the site's virtual host information from Kloxo. Just go to the screen for the domain in Kloxo, scroll to the bottom, and under "Extras" there's an "add extra tags" section. Note that anything you put in this box will not REPLACE what's already in the virtual hosts configuration but will be inserted INTO the virtual hosts block for the host. And if you have typos, etc., be aware that Apache may not restart.

So for adding AJP proxying to my sites that needed it, I just went to the "add extra tags" page in Kloxo and added this:

ProxyPass / ajp://
ProxyPassReverse / ajp://

And that worked fine. The resultant virtual hosts conf file for the site still contains the old DocumenRoot line but that doesn't impact the AJP proxying.

For simple stuff this should be fine; I'm still debating whether or not I like giving up all this control. Maybe I just got too used to editing the files directly but adding the extra tags I need through Lxadmin is certainly working.

Also note that once you're proxying with AJP you may find that you need to tell Apache to restart a couple of times before it actually restarts. My assumption is that this is because AJP maintains open connections between Apache and Tomcat. I notice this same behavior on both my laptops as well so this was nothing new.

Step 6: Test Web Sites
Kloxo has a pretty slick way to test sites before you change DNS over. In the domain management you can click a "DNSless Preview" button that lets you see if the site is more or less working before you change DNS. Obviously you're going to see things like missing CSS, images, etc. depending on how the particular site is configured, but it's a nice way to get a basic idea if the files are in the right place and things are limping along.

If you get a white screen when trying the DNSless preview chances are you have a permissions problem, so make sure that the site's file directory is owned by username:apache, and if you have symlinks in the user's home directory, e.g. a public_html directory that points to the domain name's directory, chown that directory as well. And don't forget the -R flag. ;-)

Step 7: Email
Since the two VPSes involved with this migration have different mail servers installed (Postfix on the old server, Qmail on the new server), and I use IMAP, my mail couldn't be moved over directly.

Rather than trying to deal with mailbox file conversions I decided to create a new account in Thunderbird pointing to the new server and just drag my mail over. I'm not an email hoarder per se but I did have a lot of mail to move, so this was the simplest way to do this. If you have a massive amount of email accounts to migrate you'll probably want to look into other options. I Scroogled briefly and didn't find anything very promising but I'm sure it can be done.

Webmail is another big improvement with the move to my new VPS. On my old VPS, the CP+ webmail interface would corrupt my inbox. With Postfix that's kind of a big deal since Postfix stores all mail in a single file. I finally gave up on CP+ webmail after having to edit my mail file by hand to remove the corrupted bits. Qmail stores individual files for each message, which to me as an email server layman makes a lot more sense.

On the new VPS there are two choices for webmail access: Horde and RoundCube. Horde is actually a PHP application framework with the Horde Groupware Webmail being one of the flagship apps from the project. It's very, very nice from my use of it thus far (though truth be told I prefer Thunderbird to webmail).

I haven't had a chance to try RoundCube yet because for some reason it won't connect to my mail server. I had MySQL permission issues during the migration that caused some mail outages for me, and at this point RoundCube still isn't working. It looks nice from the screenshots on the web site though, and it's nice to have some choices. I'm just happy these won't corrupt my inbox every time I use them.

When it comes to sending mail from a CFML engine, the new VPS requires mail be sent by an authenticated user. So you do have to create an email account on each domain from which email will be sent, and then use that as the username and password when you send mail from CFMAIL. Bit of a hassle but I suppose this is better from the standpoint of keeping the spam relaying potential to a minimum.

Step 8: Update DNS
Last step's the easiest. When you're ready to flip things over to the new server, just put in a DNS change request on Viviotech's site, and you're done.

Step 9: Miscellany
I did run into a few file permission issues. In one case I was getting 403 errors on a particular domain and even though all the file permissions looked correct in a terminal, it wasn't working. I deleted the domain in Lxadmin and recreated it, and that solved the issue.

The sure-fire fix if you run into permission issues is to make sure all the files you want to serve via Apache are chowned to username:apache. Weird thing is I had some files being served fine without being in the apache group, but others didn't, so when in doubt chown to username:apache.

There is also apparently a bug in Kloxo that in some cases when it creates accounts, it will set the file permissions to 711 which means Apache can't read any files. So if the owner and group permissions are correct, set the permissions to 755 on the user directory itself and that should resolve it.

Also, don't forget to migrate other things from the old server to the new one like anything in your crontab, any custom scripts in /etc/init.d, or other assets that may not fall into anything discussed above.

Thanks Viviotech!
Just a couple more comments about Viviotech's support. I've used a lot of hosting companies over the years, and I still have not seen another hosting company even begin to approach Viviotech's level and responsiveness of support. Answers to questions are quick, personalized, and thorough, and other support requests like updating DNS happen extremely quickly.

They also don't hesitate to go out of their way to help with things that technically go beyond what they say they'll support on a VPS with root access. If you have a problem of any sort, they'll help you through it quickly and courteously, and the response is thorough so next time you run into the issue you'll be able to handle it yourself.

So with some hacking around and Viviotech jumping in to help, I'm up and running on the new VPS! Hope others found this helpful or at least mildly entertaining. ;-)