Apr 10 2006


Relevance Review #3: Foundations of Ajax

This is a review of Foundations of Ajax, from Apress. Full disclosure: I have met, and really liked, Nathaniel Schutta, not least of which reason is he quotes me.

Quick summary: Chapters 5-7 worth the cover price. Rest of the book could be shortened, and replaced with more of chapters 5-7.

The Foundation series from Apress seeks to give readers the fundamentals of a given technology. This book delivers very literally on that premise; perhaps too literally. The authors give the readers a long treatise on writing Ajax code using raw JavaScript while ignoring all of the higher-leverage frameworks that are typically employed. While instructive, it leaves the book feeling somewhat less than practical.

Chapter 1 is a history of the Universe through the lens of distributed programming. As a person who has tried to deliver that story in front of a live audience, I can readily attest that such a history is often lacking in detail and perceived as redundant by the audience. This chapter suffers from those problems, and while interesting, would have been better as a prolog than a whole chapter.

Chapters 2 and 3 introduce and explain the usage of XMLHttpRequest. These chapters are both the central premise of the book, and its greatest weakness. The authors explain in detail the vanilla JavaScript required to invoke the XHR object, to interact with the request/response streams, and to navigate the DOM (of both the web page and the response data). This is where the authors choose not to discuss the Ajax frameworks that can help you with the boilerplate code, and instead focus on rolling your own. And we really like for folks to understand the inner workings of a technology, so I say 10 out of 10 for effort. The balance of code and explanation is also spot on, with just enough of each to keep the reader interested.

However, there are some problems. The code presented in these chapters is brittle. The authors gloss over some rather important complexities. I'd give them a pass if they were then introducing frameworks that took care of the complexities for you; but since they don't, it would have been nice for the code to go into more detail. Examples are ignoring the MSXML version of XHR when showing cross-platform invocation, failing to account for multiple concurrent asynchronous requests, and robust error handling. In the last case, the authors show how to inspect the status code of the XHR response, but don't examine issues like request timeouts and corrupt data.

Chapter 4 really starts to pick up. This chapter introduces a ton of Ajax techniques in code format. It shows, in detail, how to implement your own Ajax effects like auto-complete fields, page polling, interacting with web services, and many more. The code is useful, but perhaps more useful is the effect of seeing so many techniques laid out for you, expanding your idea of what is possible in your web application. Very well done.

Chapters 5-7 should be mandatory reading for every Ajax programmer. These chapters lay out the toolkit of the series Ajax developer, introducing and explaining the uses of tools like: JSDoc, for code documentation, JSLint for error checking, JSUnit for testing, Venkman and the Microsoft Script Debugger for stepwise debugging, and a slew of tools for helping verify your XHTML/DOM/CSS. These chapters show how to treat JavaScript with respect and act as though it is a real programming language, which is exactly what it is.

In all, I think the book's code focuses too much on plain JavaScript to be really useful for a working developer, and if the code-focused chapters had been condensed to a single chapter to make more room for extra details about the toolset introduced in 5-7, the book would be much stronger. However, it probably wouldn't have been a good fit for the Foundation series, then, so it is hard to fault the authors. Recommendation: get the book, read the first half, and live the second half.

Apr 09 2006


Relevance Reviews #2: Ajax Hacks

This week, I am off to Vancouver to teach Ruby on Rails Today's in-plane reading is Bruce Perry's Ajax Hacks, published by O'Reilly.

Quick summary:Chapters 4 and 9 are excellent and may justify buying. Skip the rest.

The "hacks" format breaks the content of a technical book into (in this case 80) individual entries. As I mentioned in an earlier review, I like this format because like most developers I learn best by example.

Unfortunately, the "hacks" metaphor breaks down in this book. Chapters 1-3 are not really hacks at all; they are mostly a raw-JavaScript Ajax tutorial, disguised as hacks to fit their form of the book. This is unfortunate because inexperienced readers may choose to use "intermediate" steps of the tutorial as "final" hacks in their applications. We have a bunch of great Ajax libraries; very few people should have to write raw-JavaScript Ajax. That said, it is definitely still worth learning raw JavaScript Ajax. You should always understand one level of abstraction underneath your primary work. Once you've learned, pick a library for your production work.

Chapter 4 ("Power Hacks for Web Developers") is much better -- a grab bag of techniques that will have something new for most readers, even if they have Ajax experience. This chapter also benefits from multiple authors, as you get to see different stylistic choices being made. Also, this chapter encourages more thinking about "what can I do?" instead of just "how can I do it?" There are several examples of mashups that combine existing web services under a single Ajaxy front.

Chapters 5-8 cover a variety of Ajax libraries: DWR, Prototype+Rico, Ruby on Rails, and Scriptaculous. First let me say that I think the choice of which libraries to cover is spot on. The only obvious omission is Dojo, and Dojo is so big and ambitious that a chapter overview in "hacks" format would be useless. And that leads me to the problem: These chapters are not collections of hacks, rather they are introductory chapters that have been wrestled into a "hacks" format. All of these topics have much better coverage online and in other books (which I will be reviewing as this series continues).

The Rails and DWR chapters have particular issues: Chapter 7 (the Rails chapter) is way behind on Rails, claiming coverage of Version 0.9.4. Thomas and Hansson's excellent book Agile Web Development with Rails has a more up to date Ajax chapter, despite having a publish date that is nine months earlier. The DWR hacks (Chapter 5) miss almost everything that is cool about DWR. Hack #48 demonstrates accessing a custom object by having the object store values in a Map and do its own toJSON work. There is no mention of DWR's ability to automatically marshal real-world Java beans, which are typically not backed by Maps. Hack #49 commits the cardinal sin of RPC, doing in multiple roundtrips what could be done in one. This is ironic, since DWR supports a batching operation which automates doing the right thing.

Chapter 8 rocks. Read it. Hacks #68 and #69 demonstrate not one, but two, different ways to "fix" the back button in Ajax applications. #70 adds timeouts to Ajax invocations. #75 and #77 begin to embrace the browser as its own MVC environment, creating client side caches and search indices. This is almost the opposite of what most people think of Ajax -- using the flexibility of JavaScript to reduce communication with servers. Finally, my personal favorite, #73, clearly explains how to use dynamic script tags to cheat the browser security model, letting one page invoke services from multiple domains. (Use with caution, of course.)

In summary: Intermediate to Advanced Ajax developers should read chapters 4 and 8, and beginners should read something else.

Apr 05 2006


Best Ajax Books

Over the next two weeks, we will be reviewing Ajax books, and putting together our list of "must-have" books for developers. The first review is already posted here. We'll be raffling off a set of the must-have books at the next run of the Pragmatic Studio: Ajax

Let us know what books you'd like to see reviewed.

Apr 05 2006


Relevance Reviews #1: The JavaScript Anthology

My in-plane reading for the NFJS Omaha trip was the recently published JavaScript Anthology from SitePoint. I picked up a copy specifically looking for resources to recommend to Ajax developers.

There is a lot to like about this book:

  • The authors clearly know their stuff, and in detail. Everything is demonstrated with code.
  • The individual tips are well-organized, with a statement of the problem, solution, and discussion. I found the format easy to skim (for stuff I already basically knew), and easy to dive in where necessary.
  • The authors provide lots of links to additional resources.

More than half of the book is devoted to effectively using the APIs that are present in a modern web browser, for manipulating the Document Object Model, forms, windows, ranges, DHTML, CSS, XHR, etc. These items will be of great value to anybody who has to write effective JavaScript in the face of browser variabilities. Most of the tips are captured as JavaScript procedures which you can easily adapt for your own programs.

Relatively less time is spent on the language itself--the intro chapter, plus concluding chapters on OO and performance. While these chapters are reasonable as far as they go, I wish they went a lot farther. Like most authors writing about JavaScript, the authors sound a bit apologetic in comparing JavaScript's prototype-based inheritance to class-based OO. There's no need to apologize! JavaScript provides very powerful abstractions. The best Ajax developers are embracing these abstractions, without constantly looking in the rear-view mirror at classes.

The most troubling part of the book, particularly for an Ajax developer, is the disconnect between the "procedural" style of most of the sample code, and the object-based (and functional) style of JavaScript you will see in libraries such as Prototype. Hidden in the Ajax wave is a set of programming techniques which go far beyond Ajax in their utility and importance:

  • closures
  • internal iterators
  • metaprogramming
  • AOP
  • Duck Typing
  • Functional Programming
You won't find much on these topics here. In fairness, I am not aware of any JavaScript book that hits these. Your best bet for today would probably be to learn Ruby and transpose Ruby->JavaScript in your mind.

To sum up, this is a well-organized, solid book. It will be most useful for people writing and supporting "raw" JavaScript. Most Ajax developers should be using libraries to handle much of this low-level detail. That said, you always need solid knowledge of at least one level of abstraction beneath the one where you are working. Read the JavaScript Anthology to learn that next level down, and stay tuned for future reviews where I'll cover some books that target Ajax more directly.

Mar 21 2006


James McGovern: WTF???

From the tagline of James's blog: "James McGovern is an industry thought leader whose focus is on the human aspects of technology around open source, enterprise architecture and agile software development."

I suppose that anybody can call themselves a thought leader, and, as I can readily attest, anybody can write a book. But it takes major cajones to be both antagonistic towards and completely ignorant of a technology while calling yourself a thought leader.

James is on a double rant against Ruby as not being ready for the enterprise. Others, such as DHH, have addressed his convoluted logic with respect to architecture in previous posts. But James's latest missive, whereby he demonstrates that Ruby isn't even technically ready for the "enterprise", is so funny that Carrot Top wouldn't be allowed to use it as a joke.

Let me just take his points on one at a time:

1) "Let's say I decide to hire folks from one of the more prominent agile consulting firms who will charge me a higher hourly rate and uses Ruby whereas the other insulting firm who practices Java and Agile Methods but is from India takes a lot longer but has cheaper hourly rates, which one will be cheaper? The real answer is when I receive the "bids" from both parties, they will be competitive."

We here at Relevance have already thoroughly answered this. We can charge more and STILL be cheaper. Simple as that.

2) "Costs within the enterprise are not in software development anymore. Have you seen the electrical costs within most data centers do to all those inefficient but rapidly coded applications? Maybe you have figured out that within most large IT shops that if only 25% of the folks there know how to code then productivity gains here aren't as significant as say realizing savings from say operations where more folks reside. How does one save on operations costs? The answer is easy, one may choose languages that exhibit better performance and scalability characteristics than one that doesn't."

If he's serious, we can all stop thinking about agile software. For that matter, we can quit wasting time on Six Sigma, ISO90001000001010230231013, streamlining the sales process, getting better phones, and hiring smart CEOs. I suppose he has a point, though: ask the guys from Enron if the power bill is the only thing that matters in a company.

3) "Continuing the thought, Ruby currently doesn't realize the above characteristics. Maybe if it added native thread support, this aspect may go away."

Even if you assume that his point #2 is true, native threading is hardly the first place you would go to make Ruby more efficient. Try having a compiler, or more caching, or, well, almost anything.

4) "Another deficiency that Ruby needs to consider is that not everyone on the planet speaks the same language. Enterprise applications (I really should post a definition for this but will save for another blog entry) in many shops and as written by many large software vendors need to support multiple languages simultaneously. Ruby needs to address multilingualization quickly."

Well, he's right, Ruby is deficient in this area. Score: James - 1, Sanity - 3.

5) "In my career, I have noticed that folks who know Visual Basic tend to not get multiple threading architectures and will make design level mistakes. Ruby folks as another predictor (different from guarantee) tend to not design (Yes, I know the agile party line here) and are successful in getting applications to work quickly but tend to skip out on long term maintainability. Maybe the best thing that Java folks can do for the Ruby community is to bring more of a software engineering mindset to development."

Wow. I didn't know that the Ruby community was made up of ex-VB developers. Exactly who does he think makes up the Ruby programmers of the world? I will be willing to bet a year's salary that a higher percentage of Ruby developers know how to design a reasonable application than Java developers. Ruby programmers that I know tend to come from Unix and C/C++ backgrounds, and have a pretty deep understanding of how software works. There are a lot of Java programmers who can't even compile a program without Eclipse.

6) "Ruby is going down a path of creating their own Virtual Machine. It seems to me, that they should simply put Ruby on the Java VM and not waste efforts in reinventing the wheel."

WTF?? JRuby?Ruby.NET? Here's an idea: open Google. Type "ruby jvm" or "ruby clr" into the little white box in the middle of the page. Press "Enter". Read about JRuby, Ruby.NET or even possible Parrot integration. Then get back to me.

7) "Ruby should support the notion of being about to be embedded into other platforms vs. simply being standalone."

Isn't this is point #6, but shorter?

8) "Ruby seems to be missing something that is otherwise fundamental in other languages which is support for Regular Expressions."

Ho. Ly. Crap. Ummm --- James, Ruby not only has a RegExp class you can use to model regexes and match them but also has the good old /^[aeiou].*/g style constructs to boot. And, you know how you could have found out about that? By opening up one of those "mediocre" books about Ruby, turning to the index, and looking under "R".

9) "Does anyone agree that the notion of packages / namespaces should be a part of every modern language?"

Ruby has an explicit construct called a Module. The entire purpose of a Module is to provide lexical scoping for classes, variables and functions and act as a unit of deployment. It has no other purpose, it is the purpose for which it was intended. Again, want an easy way to verify this? Open up the index of Programming Ruby. Look up the word "Namespace". You will see the following entry:

"Namespace. see Module."

It doesn't get any more succinct than that.

10) "I also couldn't find the equivalent of instance variables. Wouldn't that make reuse at an enterprise-level somewhat problematic?"

I think this is just a translation problem. Let me tell you what James was actually trying to say: "I've never looked at Ruby, written a line of code in it, or read a blog entry about it. It threatens my Java-based hegemony, though, so I'd better get out in front of the issue right away."

Because there is no other possible explanation for being a "thought leader" on software and being unable to ferret out the exemplars of the Big Three (inheritance, polymorphism, encapsulation) in any object oriented language in under 30 seconds.

Who IS this guy?

11) "Shouldn't the notion of methods being public, private and protected also be a part of every modern language?"

Yes, which is why Ruby has them. All three. Although, I can totally understand how he missed them. They're called "Private", "Protected" and "Public" in Ruby.

12) "Let's say that Ruby steps up to all of the things I listed above and does so in a rapid manner, wouldn't that break all applications that used Rails? I believe the answer is that it would cause a trainwreck for any enterprise application that was built on top of it?"

There isn't anything, not a SINGLE THING, that he's suggested that would break Rails, because Rails is already dependent on every single one except native threading, which wouldn't hurt to have but certainly wouldn't hinder Rails apps in any way.

It really looks like he thinks Ruby is some kind of hybrid of bash scripting, BASIC and Lincoln Logs, that Rails is nothing but a naming convention built on top of it, and all of it is used by monkeys with pointed sticks. Its as though he's completely and totally ignorant about anything and everything in Ruby and Rails, but feels confident in declaring it unfit for "real companies".

13) "Does anyone in the community acknowledge that software vendors and even many large enterprises don't build on top of scripting languages because they don't want their intellectual property so discoverable?"

Yes, that's why Java is such a great alternative! Because bytecode totally hides programmer intent! (Forget about all those reverse engineering tools, because there are obfuscators too!) I won't even mention that most "enterprise" code lives entirely within the enterprise that wrote it, so from whom are they hiding it?


Look, I like Java. A lot. And, I like .NET. A lot. I think they're great. I also think Ruby is great. And VB6. And bash scripting. And Python. And Perl. And even Lisp. So, don't get me wrong, here. I'm not saying that there is no argument that can be made against Ruby in the enterprise.

I just wish that the people making those arguments would either know what the hell they are talking about, or admit that they are ignorant and just out for your money. I am sorry that this blog post seems angry and tense. But, really, if nothing else, this guy makes us other Java people look bad.

Mar 20 2006


Ajax, Flash, and Uncertainty

Richard makes some good points in PB&J: The Flex-Ajax Bridge that I'd like to follow up on a bit:

[Re: Ajax] More importantly, there are something like 50 open source libraries to choose from. Which one do you choose?
The swarm of Ajax libraries is a hard problem, but an exiciting opportunity too. It reminds me of the early days when there were 15-20 EJB containers. How do you pick a library? Here's some tips:
  • You gotta know JavaScript. Deeply and thoroughly. JavaScript is not Java, nor is it similar. I'd rather have a bunch of good JavaScript programmers and pick the wrong library, than a bunch of bad JavaScript programmers pick the right one.
  • When choosing a library, consider excellent development process at least as important as corporate backing. Look at the winners and losers in Enterprise Java--it strikes me as a rough split between established players and newcomers who executed well. Ajax will be the same, and some new big names will emerge.
  • But how do I evaluate the development process of closed-source frameworks? Hmm... Nuff said.
  • Pick something with ties to a strong server-side stack.
  • Can you just recommend something? Sure: Prototype, Scriptaculous, and Dojo. That's what we use, and what we teach people to use. Are they the best? Dunno--but they score well on all the criteria above.

Richard goes on to say:

Now to the point about the Flex-Ajax bridge developed by Ely Greenfield. In my opinion, this bridge is the single most important advancement in Ajax this year.
The year is pretty young so I won't go that far yet, but I totally agree with Richard that Ajax and Flash are (at this stage) complementary. If you're serious about [insert web hype term], you need to be looking at both.

We'll be talking about all this stuff, and more, at the next Pragmatic Ajax: Studio on April 25-27 in Chicago.

(Via Richard Monson-Haefel.)

Mar 20 2006


Pragmatic Studio: Ajax, Second Edition!

Comin' atcha, baby! Pragmatic Studio: Ajax is coming back, this time in Chicago, April 25-27. Seats are moving quickly, so check out the website and sign up your team now. We're more focused than ever: Prototype, Scriptaculous, and making usable, useful Ajax apps with today's technology. We love JavaScript, and so will you at the end of the Studio. Take a look at the syllabus, and sign up today! We'll see you in Chicago.

Feb 02 2006


Rails Guidebook

This is just ridiculously cool. There are some people and ideas in this world that just slap you right across the face while you are walking around in a half stupor. They wake you right up, bring things into sharp focus, and leave your cheek stinging with the pins and needles of righteousness.

Dave and Mike have already been on the cool train for a while. Their books and the Prag Studio are models of technical and publishing excellence. But this takes the cake. Awesome training, and civic involvement, plus self promotion! Its like a J.J. Redick three from center court! A trifecta of awesomeness!

Way to go, guys.

Jan 31 2006


Pragmatic Studio: Ajax sells out

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!

Jan 24 2006


"superclass mismatch" and migrations in Rails

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.

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

  script/generate migration Foo

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

  class Foo < ActiveRecord::Migration
  # etc.

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.

Popular Tags