We’re pleased to announce that the Pragmatic Studio: Ajax event in February has officially sold out. We’re thrilled with the turnout and are focusing on making it the best event we can. Afterwards, we’ll be looking at other venues and dates for holding future editions. If anybody has any votes on where you’d like to see us, please drop us a line or add a comment.

And for those of you coming to the show, can’t wait to see you there!

Came across this little head-scratcher today: added a new migration to our application and, when trying to run it, Rake aborted the migration with an error of “superclass mismatch”. After poking around trying to find out if we accidentally introduced a second copy of ActiveRecord::Base somewhere, I discovered the actual answer.

Imagine if you will that our application has a model class called Foo. This means we have a class:

class Foo < ActiveRecord::Base
# etc.
end

Somewhere along the line, somebody wanted to update the schema for Foo and ran this command:

Which gives us, buried in the db/migration folder:

class Foo < ActiveRecord::Migration
# etc.
end

Thus, the type mismatch problem as Ruby discovers two completely different classes called Foo with mismatching superclasses. This isn’t the odd part. The odd part, which I haven’t figured out yet, is why we only saw the problem now. You see, we just added migration #044. The offending migration was #007.

When I figure out why it worked until now, I’ll report back. Until then, if you ever get a superclass mismatch error in a rake run, look at your migrations.

Mark Haliday raised an interesting question in the comments of my post announcing Pragmatic Ajax. His question: are most of the code samples in the book Java? Without a scientific analysis, here’s my best guess as to how the samples break down across the book:

• 60% JavaScript
• 15% Java
• 9% Ruby
• 8% .NET
• 8% PHP

The extra space devoted to Java is largely due to the section of the Google Maps chapter devoted to carving up the SVG map which was done in Java, but has little or nothing to do with Ajax or Web 2.0. We just thought it was interesting.

No, in fact, the majority of the book is about JavaScript: how it works, how the various libraries for Ajax work with JavaScript, etc. We tried to devote equal time to integration with the four major web development platforms (Java, .NET, PHP, Ruby on Rails). We did that for good reason: I can write a pretty cool Ajax application with nothing but HTML and JavaScript.

Hope that helps clarify the purpose and nature of the book. Thanks for the question, Mark!

We’re pleased to announce that Pragmatic Ajax: A Web 2.0 Primer is complete. We finished the manuscript this week, and the last beta will be pushed out this weekend. Then, its off to the copy editer to find all the spelling and grammatical mistakes that the Apple spellchecker missed. Finally, as fast as the print shop can churn them out (imagine picking up two cinder blocks and trying to run across the deep end of a pool and you get the idea) the book will be released in paperback.

We’re pretty sure the book has something to offer every reader. But if you are looking for a shorthand cheatsheet of what WE learned while writing it, here you go:

1. Microsoft believes that everything has to look exactly like them. Witness their introduction of namespaces, customized inheritance syntax and (shudder) interfaces to JavaScript. I’ll rant more about the interface thing later, but suffice it to say, does this look like the kind of JavaScript you want to write?
2. In 12 months, you’ll never hear the word Ajax again unless you are cleaning your kitchen or taking a survey course in Greek mythology. But you won’t stop hearing the phrase “Web 2.0” until the next bubble bursts.
3. .rjs templates in Rails are a really really cool feature, but using them on a real project is a crap shoot right now because they tend to explode layout rendering at random times. I’m stoked about the feature, but I’ll come back from the edge for now while it settles down.
4. Writing a book about an emerging technology is hard hard hard. Here’s a list of things that changed dramatically while we were writing the book:
   • The PHP library NAJAX changed its name, and all its sources, to XOAD.
   • The Dojo framework changed the way its effects are run, removing the notion of having to “hit play” at the end of creating one.
   • Bugs were fixed all over the place in Prototype, Script.aculo.us, Dojo, DWR, and Ajax.NET.
   • Ajax.NET shut down and was incorporated into BorgWorX.
   • Apple introduced a new DOM inspector into WebKit.
   • Rails went 1.0 and introduced .rjs templates.
   • Google Maps became local.google.com.
   • And probably a lot more I’m forgetting…

In all, it was a great experience, and I’m really looking forward to seeing the final release in print. If for no other reason than to have a book with my name and a big sword on the cover.

JavaScript is an easy language, full stop. It isn’t perfect, but if I had to teach a language to eager newbies, I’d prefer JavaScript over C# or Java. But apparently, some folks think JavaScript is too hard. With Atlas, you are encouraged to use helper libraries so that you can write code like this.

Type.registerNamespace("Demo");

Demo.Person = function(firstName, lastName, emailAddress) {
    var _firstName = firstName;
    var _lastName = lastName;
    var _emailAddress = emailAddress;

    this.getFirstName = function() {
        return _firstName;
    }

    ...

    this.dispose = function() {
        alert('bye ' + this.getName());
    }
}
Type.registerClass('Demo.Person', null, Web.IDisposable);

Demo = new Object();
Demo.Person = function(options) {
  this.firstName = options.firstName;
  this.lastName = options.lastName;
  this.emailAddress = options.emailAddress;
}

Humor aside, there is a serious question here. Does it help to make one language look like another, like the C#-izing of JavaScript shown above? If it does help, is it a short-run, “training wheels” kind of thing, or a long run plan? If you’re building Ajax apps, drop a comment and let us know what you think.

Ad: Fortunately, there’s more to Atlas than the misguided C# veneer. We’ll be talking about some of the better parts at the Pragmatic Studio in Reston, VA, Feb 9-11.

We’ll also be speaking at The Ajax Experience in San Francisco, May 10-12th. Brought to you by No Fluff, Just Stuff and The Ajaxians, the show promises to be a fun conference filled with talks by the people working on all the new hotness.

We’re in the final run-up to the inaugural Pragmatic Ajax Studio. We’re putting on the show in conjunction with the Pragmatic Programmers, following the format of their celebrated Pragamatic Rails Studios. And, like those guys, we’ll be talking about Rails at the show. However, enlike those guys, we’ll be talking about Java and .NET too. Because we understand that Ajax isn’t tied to a single server-side framework, and that many of you will have to work across multiple platforms to get your Ajax apps finished. So we cover it all, in three days. For more, just visit the official site, where you’ll find the entire curriculum and all the information you’ll need to come join us.

She’s got a brother We don’t get on with one another But I quite fancy her mother And I think that she likes me

and I think there’s wisdom there for all of us.)

One of my favorite sub-memes of this major meme is that 2006 will show that dynamically typed languages are a fad and Java and .NET will again rule the day, and especially that 2006 will be the year that we see one spectacular failure of Ruby in the enterprise and this will be the death knell of this trend.

I have two words in response: “duh uhhhhh”. Of COURSE we’re going to see a massive public failure of a project written in Ruby or Python or Lisp or SmallTalk or Perl or whatever. It is inevitable. We’ll see massive flameouts on a grand scale. You know why? Because for all that Rails or Ruby or Python or what have you attempt to solve a lot of the problems of modern software development, none of them can solve the underlying problem, that software is written by people and is often written by uninterested people. Now that the hype machine has generated enough attention on these dynamically typed platforms, it is only a matter of time before they are adopted by teams who are uninspired by or uninterested in their technical merits, propensities, and features. These teams will use them because they think they can get the same paycheck with less work, and their projects will fail. Loudly.

Does this mean that these languages, platforms and frameworks will be demonstrated to be the emperor’s clothes? Not at all. It will merely announce their ascendence into the time-honored tier of Tools that People Use. Nobody has ever claimed, for instance, that using Ruby will make all projects succeed. Just that, in the hands of developers who care, projects can succeed faster and be better. Arguing that a large failure of a Ruby project in 2006 will be a death blow overlooks two important facts:

1) there will be many more loud failures of Java and .NET projects in the same time frame 2) there hasn’t been a loud failure of a Ruby/Rails project yet.

Do either of these facts mean that Java and .NET have failed? Nope, but it sure is interesting, no?