Learn to Program, by Chris Pine, is a small, swift introduction to programming for beginners. Despite its short size (150) pages, and conversational tone, LtP covers a lot of ground, including:

• numerics
• strings
• variables
• methods
• flow control
• iteration
• methods
• recursion
• object-orientation (OO)
• higher-order functions

How does such a short book cover so much? By using an excellent language for learning to program (Ruby), by following the Pragmatic Programmer mantra of “Don’t Repeat Yourself” (DRY), and by introducing topics in a sensible order. (The book began as on online tutorial, and benefits from several cycles of use and feedback).

The ordering of topics above is not merely useful pedagogically; it stakes out a position about what is important in software development. Note that recursion comes before OO, that OO is important but has no special pride of place over several other concepts, and that higher-order functions appear in an introductory book. None of this has been conventional wisdom in the past decade, but I’d bet all of it will be conventional wisdom in the next.

Of course there are a few nits to pick. The pace of the book revs up substantially (and suddenly) in Chapter 9. By then, hopefully the reader is hooked and willing to work a little harder. The book has a very personal style, with lots of first-person humor. Such thing are always a matter of taste; while I usually want my tech content straight I have to admit I chuckled a few times. Finally, I’d like to see a chapter on automated testing in all introductory texts; maybe that can get into a second edition.

Last Word:Learn to Program is a solid, cleanly-written introduction to programming for technical people. As a followup to this book, of if you are already a professional programmer, check out the Pickaxe, which is the definitive word on Ruby.

I have posted my slides from the Ajax experience: Prototype, Ajax Architecture, and Ajax on Rails.

Worthy of note is how the slides are built. If you follow the links you will see that I am using a custom DHTML app. I stated out using S5, but have gradually iterated towards my own bespoke JavaScript and Ruby on Rails powered solution. If you want to view the slides in print, you can now do that, thanks to Austin Ziegler’s cool PDF::Writer for Ruby.

A long time ago, I asked the question: what would Rails need to have to be “Enterprise Ready™?” A lot of the answer had to do with Messaging. Well, the fanboys at ThoughtWorks have apparently been working on just that. The really small sample looks interestingly compact, so compact, in fact, that I have a hard time seeing how and where you might configure it to talk to a .NET/MSMQ hub vs. a JMS provider, but I’m sure if I could get my greedy little hands on the code, all would become apparent.

The project apparently utilizes STOMP from Codehaus. It isn’t a full-on MOM backbone, but close enough for government work, and certainly close enough to be useful for many of the needs of message-enabled web sites. If this really comes alive, then, according to my anecdotal research, the other three “must have for Enterprise Readiness” features still lacking are:

• Support for 2PC distributed transactions. But, since only about 5% of enterprise applications, and, like, 0.00045% of web applications, ever actually utilize this, I won’t hold my breath or demand anybody else do.
• Internationalization. Huge problem, must be solved soon, many people working on it.
• A real component-based backend for rendering, a la JSF or Tapestry. While I like Tapestry, I am at best ambivalent about JSF and just don’t see the point in going this route for Rails. Beyond that, I believe that anybody who makes this a pre-requisite for being “Enterprise Ready” is just looking for excuses. What they REALLY want, it seems to me, is a marketplace for buying/trading chunks of reusable code for website generation, for which Rails offers the plugin model and distribution network.

So, while a half-finished, not-officially-announced-yet messaging backend that isn’t a full JMS clone won’t make the Fortune 50 swivel around in their evil chairs and shout “Down with Java! Vive la Ruby!”, it sure could be a giant step in the right direction. Makes me a lot happier, anyway.

I will be giving the MetaRails talk at RailsConf 2006. The purpose of the talk is to expose and document Ruby power techniques that are used in the Rails codebase itself. If you have always wondered how Rails does some piece of seeming magic, drop me a line or comment on this blog entry. I’ll add the most interesting/challenging suggestions to the talk. My current list of topics is

• Three Easy Pieces
  • The to_proc Trick
  • Indifferent Access
  • How nil Became whiny
• How’d They Do That?
  • How Does Rails Guess Names of Things?
  • Where do ActiveRecord Accessor Come From?
  • How Do Variables Get From Controllers To Views?
  • How Do Classes Get Reloaded During Development?
• Deep Magic
  • How Transactions and Versioning Work
  • How breakpoint Works
• Following Their Example
  • Writing Your Own Validations
  • Generating Tests
  • Creating Non-ActiveRecord Models
  • Creating an Internal DSL

I am pleased to announce that we will be partnering with the Pragmatic Programmers to provide a free book for each attendee of Relevance’s onsite training in the following technology areas: Ajax, Ruby, and Rails.

When you schedule a course with use, tell us which Pragmatic Bookshelf book you’d like. (How do you know what books there are? Head over to the Pragmatic Bookshelf and browse their catalog. If you’re coming to a Rails class, then Agile Web Development with Rails would be a first choice. If you already have that book, then perhaps Rails Recipes, or Enterprise Integration with Ruby, or Best of Ruby Quiz. Then let us know which title you’d like, and we’ll have it available for you to pick up at the course.)

One part of the value in training is being able to point people to quality sources for more information, and I can’t think of anyone I am more comfortable recommending than the Prags.

The Pragmatic Studio: Ajax is coming to Boston September 11-13. You can check out the site for complete details, but I wanted to mention one thing here: our approach to hands-on exercises.

A big challenge with Ajax training is creating useful hands-on exercises that don’t bog attendees down in the details of setting up some random server on their laptops. For the Studio, we have finessed this problem by providing a shared server. Attendees browse to a page, do “View Source”, copy a file to their local machine, and edit the HTML file to make calls back to the shared server. This keeps things simple (no server setup) and forces everyone to think about keeping their Ajax code decoupled from server implementation details.

Since calling a remote server from a local HTML file isn’t directly legal in Firefox, we provide various versions of the following hack to enabled limited cross-site capability.

// Modifies Prototype so that Ajax requests ask permission to go cross-site.
// Useful for pages that are run from the local filesystem.
CrossSite = {
  wrap: function(original) {
    return function() {
      try {
       netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
      } catch (e) {
        //alert("caught " + e);
      }
      original.apply(this, arguments);
    }
  }
}
Ajax.Request.prototype.initialize = CrossSite.wrap(Ajax.Request.prototype.initialize);
Ajax.Request.prototype.onStateChange = CrossSite.wrap(Ajax.Request.prototype.onStateChange);
Ajax.Updater.prototype.initialize = CrossSite.wrap(Ajax.Updater.prototype.initialize);

As I have said before, Enterprise software is all about flexibility. It is a testament to the Enterprise-worthiness of JavaScript as a language that I was able to so easily find the hooks needed to make the cross-site hack work. Not to say that this particular hack is the best way to do cross-site Ajax in a production setting, but it is the exact fit for our needs.

For the last three years, Justin and I have been speaking on the No Fluff, Just Stuff Symposium (NFJS) tour. Our reason for participating is simple: we like the people. Attendees are typically developers who are passionate about their work, enough so to come to a weekend conference. Speakers are not just talking heads, but real developers who spend most of their time building software, and then give up their weekends to share their interest with others.

This may not sound like conferences you remember. Many developers (including some of the best ones I know) are cynical about conferences, assuming the worst based on past experiences. Well, if you want a low-cost, low-effort way to check out No Fluff content, here’s a possibility to consider. The speakers at NFJS have put together a book, the 2006 NFJS Anthology. My own contribution, on Spring AOP, is available at the book’s site as a free sample. Thanks to Neal Ford for doing the editing, and the Prags for handling the printing. If you are on the fence about conferences, start with the book. If you like what you see, I hope we’ll see you at an NFJS symposium soon.

Pragmatic Ajax, by Justin Gehtland, Ben Galbraith, and Dion Almaer

Reviewer’s Disclosure: I (Stu) own a company with Justin, and am very good friends with Ben and Dion.

Quick Summary:Strong introduction to Ajax; excellent comparisons building simple Ajax functionality with a variety of the best client and server side tools.

I would divide Pragmatic Ajax into five parts:

1. Introduction and Background (Chapters 1-4)
2. The Client Side (Chapters 5-7, with a few asides)
3. Intermediate Concepts (Chapters 8-10)
4. The Server Side (Chapters 11-15)
5. The Future (Chapter 16)

Each part is reviewed below.

The introduction and background chapters are strong. This material is similar to material in every other Ajax books, with a couple of distinguishing features. Chapter Two builds a Google-Maps-like application. While I don’t think most developers will use Ajax to build mapping applications, this is just cool. The other, more important feature is the choice of a very simple example: the Zip code lookup. Chapter 3 introduces a form that automatically populates a city and state as the user enters a Zip code. I like this example (and use it myself when training) because the basic code is incredibly simple. As a reader you can focus on the Ajaxy parts, without getting bogged down in the complexity of the sample itself. Rather than introduce a ton of new examples as the book goes on, the authors re-implement this example about a dozen times throughout the book, comparing and contrasting wire formats, client libraries, and server libraries.

The client side chapters build the Zip code example several times. Along the way they introduce client-side helper libraries, remoting options, validation, bookmark and back button support, visual effects, progress indicators, and update indicators. These chapters are the most important part of the book, in that they (a) make a strong case for introducing libraries and (b) choose good libraries to introduce. The examples are built using Prototype/Scriptaculous and Dojo. When you consider both code quality and integration with server side technologies, these are among the most important libraries out there. Do not build Ajax applications in raw JavaScript!

The intermediate chapters answer the question “I can build a basic Ajax application, what happens now?” Chapter 8 introduces a variety of tools for debugging Ajax applications inside various browsers, including logging, DOM inspection, and step debugging. Everyone should learn these debugging tools—I am constantly surprised to discover developers troubleshooting their Ajax apps with nothing more than their browser and intuition. Chapter 8 also sneaks in yet another cool Ajax framework, MochiKit. Chapter 9 shows how to make your Ajax application “degradable,” i.e. functional in non-Ajax browsers. Chapter 10 introduces JSON and JSON-RPC as an alternative to XML.

The server-side chapters compare and contrast different server-side choices for Ajax: PHP (Sajax and XOAD), ASP.NET (Atlas and Ajax.NET), Java (with DWR), and Rails. The authors made three smart choices that make these survey chapters work better than similar chapters in other books:

1. These are the right four choices to cover
2. All the examples are the same Zip code lookup, so you can focus on the language and tool differences
3. You don’t have to wade through pages of setup instructions unrelated to Ajax

The futures chapter covers several emerging technologies and standards that haven’t hit their stride yet, e.g. E4X, Canvas, and SVG. At least one of these technologies will be very important in the next generation of Ajax apps, but I am not sure which. :-)

Last Word:Pragmatic Ajax and Ajax in Action (reviewed here) complement one another nicely. As of today (May 3, 2006) I believe these are the two must-have books for Ajax developers.

We’re adding a new Rails Recipes course to what we think is already the most comprehensive Rails training curriculum anywhere . Rails Recipes is based closely on Chad Fowler’s excellent book of the same name. Like all Relevance training courses, you will get to pick and choose the exact topics your team wants to cover. (Recipes are pretty bite-sized, so expect to be able to cover 5-6 in a day). And of course, every attendee will get a copy of the book!

Professional Ajax, by Nicholas C. Zakas, Jeremy McPeak, Joe Fawcett

Quick Summary:Emphasis on irrelevant Microsoft technology plus unlucky timing weaken an otherwise solid book.

Pro Ajax starts strong. The first chapter, “What is Ajax?” is a nice conceptual introduction. Chapter Two, “Ajax Basics”, rightly treats the “A” in Ajax as the most significant evolutionary step. The authors work from basic HTTP, through frames, iframes, and XMLHttpRequest. Chapter 3, on Ajax Patterns, shows you a variety of ways asynchronous invocation can be used. Taken in isolation, Chapters 1-3 make a nice mini-book on Ajax.

Chapters 4-6 cover XML. These chapters are not nearly as useful as the first three, for two reasons:

• The coverage is basic, and belongs in an XML book, not an Ajax book.
• The conceptual clarity of the first three chapters disappears when the authors are talking about XML. Particularly mystifying is the coverage of Representational State Transfer (REST) on pages 163-166. A reader not already familiar with REST might come away thinking “REST is just like plain old HTTP, except you have to manage links with XLink.”

It is nice to see a chapter on JSON (Chapter 7). The explanation is clear, and the authors quickly get to an important point: You don’t have to eval JSON! You can (and probably should) use Doug Crockford’s library to avoid evaluating arbitrary code in the browser.

Chapter 8 teaches how to create widgets. This chapter is worth reading, because it takes four examples from concept to working widget, including HTML, CSS, client-side, and server-side code. Most Ajax programmers will be widget consumers, but if you plan to be a widget author, or just want to understand how the pieces fit together, you will appreciated this chapter. Chapter 9 builds a more complete example (AjaxMail) and is also worth reading.

As you can probably tell from the individual chapters above, I wanted to like this book. And I do like the Ajax parts (about half the book IMO). The problem is the authors’ approach to the server side. Ajax is a client side technology, but to use Ajax you need a server to talk to. This poses a problem for authors, who have to make a choice:

1. Don’t talk about the server side, and let readers make their own choices
2. Pick a single server side technology and stick to it
3. Present a variety of server-side options

The authors of Professional Ajax chose to present a variety of options. This approach backfires, as you have to wade through page after page of server-side configuration unrelated to Ajax. Here are some of the topics I found inappropriate in an Ajax book:

• Configuring Microsoft IIS
• Installing ASP.NET
• Creating a .NET Web Service
• Connecting PHP and MySQL using Microsoft ADO (?)
• Installing the Java SDK
• Using Microsoft ODBC to connect to Microsoft Access from Java (?)

There is a bizarre Microsoft bias here. I wouldn’t be surprised by a book that said “We’re gonna use .NET because it rocks.” But what we have here appears to be an honest attempt to use a variety of different technologies, ruined by an unspoken assumption that servers run Windows.

Would the book be better if the authors dropped the non-Microsoft examples, and just came right out and titled it “Professional Ajax for .NET Programmers?” I think so. Unfortunately for the authors, the Microsoft world changed out from under them between writing and publishing. Microsoft’s Ajax strategy now appears to be built around Atlas, which does not appear at all in Professional Ajax.

Last Word:Useful for developers building Ajax with yesterday’s Microsoft technology. Would be nice to see a new edition of the book that covered Microsoft’s Atlas.