I have heard good things about O'Reilly's Head First series, and have an interest in advanced learning techniques myself. This was my first Head First book so I cracked it open with high expectations.
I liked the style, an entertaining, easy read. The humour is more zany than funny, but that is fine. I am hopeful the Head First series will have a big impact on instructional computer books and magazines. Annotated source code alone is 10 years overdue.
However I found the repetition irritating: I got the concept the first time and did not need to be told it again and again. To be fair, as someone who can read an 800 page computer tomb cover to cover and not get bored, perhaps I am not in the target market.
The content was good, the examples realistic enough but still short enough to see the ajax. But I have complaints, brace yourselves: there were technical inaccuracies, i18n was spelt U.S.A., spelling errors in the hand-written text and the book is fluffy. By fluffy I mean this is a 400 page book that has less than 100 pages of content in typical computer book terms, not that you can cuddle up to it in bed while sucking your thumb.
Technical inaccuracies? My big complaint here is GET vs. POST. The author advocates GET and spends many pages trying to justify this. The reasoning seems to be that POST is more complex, but as we discover you make the data the same way and it is just one more line to add. His key argument is "POST is only slightly more secure". That argument in itself is lame: no security is perfect and your aim is just to avoid being low-hanging fruit so that the hackers will go elsewhere. Every little helps.
Another argument was the browser decides the GET limit and "IE allows 2000 characters for GET, which should be enough". But servers can set a limit as well. For instance a few years back I used a web server which had a GET limit of 255 characters.
Worse of all he missed some key security arguments in favour of POST. How about log files? All the GET data gets written to the log files, POST data does not. So your user's name and address are ending up in the log file. This is then getting automatically analyzed and posted on a web site that marketing use. And they will throw those reports around not realizing there is user data embedded in them. (Well, marketing will throw them around even if they have been told the report contains customer credit card numbers, but let's not go there...)
And GET makes a wider range of security attacks possible. For one example of what I am talking about see PHP Architect's ( http://www.phparch.com ) security column in Volume 5 Issue 5 (aka May 2006). Incidentally I highly recommend that magazine and suggest you get a year's worth of back issues if only to read Security Corner. This book is aimed at people who are not expected to be reading heavy articles on how to hack web sites. So, instead of the dangerously misleading: "POST is only slightly more secure, why bother?", this book should be advising: "Always use POST unless you know exactly what you are doing."
In summary this book taught me most of what I needed to know about Ajax, but the technical accuracy is not up to O'Reilly's usual standards. And use POST.
Buy this book at Amazon Japan, or at Amazon UK.