3 comments about Refactoring HTML: Improving the Design of Existing Web Applications (The Addison-Wesley Signature Series).

1. The Web means mostly webpages written in HTML. The popularity of HTML is overwhelming. Yet it has well known problems. There is no intrinsic separation of semantic content from presentation details. And the tag syntax is very sloppy.
   
   Harold explains in clear and strong terms why you should clean up your webpages. Mostly by using CSS and by making [and checking] that the pages are well formed and valid under XHTML. This is not a text on CSS, and if you are going to follow the precepts of the book, you will need another book, dedicated to CSS. The strength of Harold's message is in the clarity. He is trying to influence you in a top-down manner. To make these strategic decisions.
   
   For example, by going with CSS, you simplify maintenance. Because files are factored into CSS files, which layout people can work on, and semantic content files, which can be the purview of others who are more involved with intrinsic information processing. The latter files also have the advantage that they can be used with different types of display devices and programs, and not just for the typical web browser. Think of cellphones, or devices for the blind.
   
   The last aspect is another salient point he makes. Writing pages that are also accessible to the blind is not just good for that reason. It lets you focus not on what the page looks like, but on what it means. Why is this good? Because it improves the chance that search engines will look at and positively classify your semantic files. Search engines often deprecate presentation instructions and CSS files. They are also looking for files with high semantic content.
   
   Also, by factoring using CSS files, the resultant set of files gets to be smaller, which reduces outgoing bandwidth from your web server. For large popular sites, this can be a cost saving.
   
   While the writing of well formed and [better yet] XHTML-valid pages increases the chances that different browsers can accurately show the pages. The reason is that browsers have been written to pragmatically show HTML, where the tag structure is sloppy. To do this, a browser has to make certain display assumptions with a badly written file. The problem is that different browsers make different assumptions. And so some HTML files will not display well, or at all.
   
   There are also other smaller level tips scattered thru the book. Like suppose you have an image that shows essentially only text. Replace the image with text. Less bandwidth is consumed. Plus search engines don't really do much with images. [Image analysis is very intensive and hard.] So giving them more meaningful text instead of images helps your page ranking. As a side note, some spammers do precisely the opposite. They have images which are mostly to display text. To evade a search engine or antispam software that keys off suspicious text.
   
   In related wise, your image tag should always have an alt attribute describing the image. Helps the blind visitor. But mostly it helps a search engine classify the image.
   
   There is one unintended ironic aspect of the book's last page. It talks about hiding your email address in the webpage from screen scraper bots run by spammers harvesting email addresses. One way is to use JavaScript to generate the address. The script is run by the visitor's browser as it displays the page. This is to evade spammers. The irony is that a spammer can use this very method, when sending spam email. Many antispam programs now use a blacklist, since spam often has links to the spammer's domain. But the programs usually [always?] check against static links in an email. The spammer can write JavaScript that dynamically makes links, to evade this. Sure, browsers that have JavaScript turned off will not show these links. But in fact, most users turn JavaScript on, because many websites use it. And the spammer might figure that the loss of links due to no JavaScript is greatly outweighed by being able to evade the now almost axiomatic use of blacklists by antispam programs.
   
   Another example of how technology can be used for completely different and opposite purposes!



2. Despite years of progress by web standards advocates, and a significant improvement in the quality of the HTML on the web, many of us still end up grappling with outmoded, broken HTML on a regular basis. When confronted with a large site filled with broken pages it can be hard to know where to start. Elliotte Rusty Harold's Refactoring HTML offers a step by step recipe book for migrating such sites to clean, semantic code.
   
   Harold's is a well known name in the XML world, and that background shows through in how he approaches the book. While a general audience will probably find useful content, the reader needs to be prepared for a series of command-line and Java-based examples. Tools like tidy are featured prominently, as is the use of regular expressions to seek out broken code to fix and, in the music-to-my-ears category, automated testing.
   
   If you're equipped to do so, following these steps will lead to much cleaner, more manageable sites, but I found myself wondering how many of those comfortable with command line tools and regular expressions are in the market for a book like this.
   
   In general I suspect the key audience for this will be IT departments inside large organisations tasked with refreshing or extending an intranet. For those developers, who maybe don't spend much of their time working with HTML and like the idea of using scripting tools similar to those in their regular workflow, this book's worth a look. If you're already familiar with current trends in web development, then there are probably other ways of picking up on the scattering of techniques that might be new to you.
   
   Disclaimer: I was sent a copy of this book for review by the publisher.



3. First the good:
   It is an _excellent_ tutorial on modern xHTML for those that have used HTML from its tag-soup beginnings. He methodically gives examples on why we, as web programmers, need to utilize a particular technology (CSS, Accessibility, etc). For example, he doesn't just say "Use CSS" because its the new way of doing things. He gives no-nonsense specific examples in bandwidth savings, alternate devices, etc.
   
   His writing style is easy to read for computer geeks: a signature trait of any Martin Fowler signature series book.
   
   He also provides a series of regular expressions that you can use to search through your HTML code to find problem areas and does a good introduction to the program "tidy". Since I am definitely _NOT_ a Regex geek, these are highly appreciated.
   
   And finally, he shows usage of some xHTML tags and attributes of which I was not aware: such as proper usage of and tags.
   
   Onto the downsides:
   Originally I purchased this book thinking that I would be able to use it to get some tools under my belt to better transform the lousy auto-generated HTML that most graphics tools export and update them to decent, modern xHTML. However, the author is definitely NOT a "graphics design guy." And because of that, I know that several of the solutions he provided in his CSS sections would NOT fly with the designers where I work.
   
   If I had seen his website, I probably would have realized that he was an XML expert instead of a design expert and wouldn't have gotten my hopes up. So far, I've found that websites like "A list apart" are much better for working with CSS-based design.
   
   So for those looking to refactor your HTML code from ancient "Tag Soup" to modern sleek xHTML, this is a great book. If you're looking for how to best refactor from table-designs to table-less while maintaining a similar Look and Feel that you've been given by your designers, I find this book highly lacking.

No comments about SolidWorks 2008 for Designers.

5 comments about Managing Your Documentation Projects.

1. This book contains many years of compiled wisdom, not only from the people JoAnn bases her Publications Maturity Model on, but the many doc managers she interviewed and her own consulting experiences. The PMM is an ideal model and not one that can be applied across all industries. The book and process is heavily slanted toward software development and that's where it finds its biggest application, but the process breaks down for many industries outside of that arena. Most tech writers are paid to produce documents, not create and refine processes to such detail as suggested by the PMM parameters--but that's not the book's fault--it's the fault of engineering/technically driven organizations that would rather force tech pubs groups to reinvent the wheel with each new project than spend the time creating and fine-tuning a repeatable process.

   Perhaps the biggest stumbling block to widespread acceptance/adoption of the PMM is the underlying need of "enlightened" organizations that appreciate (with time, money and resources) and understand the value-add such a process can provide, and those organizations are few and far between. You can have JoAnn's company perform a PMM audit for PMM certification (not sure how much that counts for in the business world--yet), or you can try to be compliant by following the suggestions outlined in the book. But if you're not a software shop, you'll have to make your own adjustments to the PMM requirements and scale appropriately.

   All in all, I think the book provides some great direction for a documentation project management process that has to be scaled to meet your business/industry needs. This book has and will continue to serve as a springboard for more discussions and new initiatives in the technical communications field.




2. Joanne Hackos is widely acknowledged as a leading authority on technical publications management, largely because (a) she has some good things to say and (b) her _Managing Your Documentation Projects_ is one of the few books on the topic. This book offers some valuable insights about basic project management, but tries to shoehorn publications project management into a particular software development methodology -- Carnegie-Mellon's Capabilities & Maturity Model. Hackos acknowledges her debt to CMM and warns that trying to implement the model described in this book is tough sledding if the development organization is not using CMM.

   After 20 years as a technical writer and publications manager, I've come to believe that all publications lifecycle systems are doomed unless they map directly to the development methodology engineering management supports and uses.

   (I've also come to believe that most development methodologies are more often than not honored in the breach.)

   If, as a publications manager, you're not aware of the development methodology your engineering managers have adopted, you need to get over and talk to them now. Even if they haven't adopted a formal, academic model, they do have some idea about how they produce technical products. Tailor your publications lifecycle to their lifecycle -- don't seek to impose an alien "order" on their process.

   (If your engineering managers can't articulate a methodology or say things like "We just code until we're done", you have bigger worries than your publications lifecycle, such as the near-term viability of your company.)

   Too often I've seen tech pubs managers adopt the "Hackos model" and fail because it doesn't fit the organization's development style. A organization that adopts the Rapid Application Development (RAD) or "Extreme Programming" model, for example, isn't going to be too thrilled about endless sign-offs on planning documents that take nearly as long to write as the manual itself.

   Instead, tailor your approach toward the high degree of interactivity inherent in such methods -- quick review cycles of small portions of text, for example, instead of waiting for a full draft of the book to be ready.

   Too many erstwhile pubs managers skim this book, then adopt the project documents provided as models in the book as "fill-in-the-blank" busywork for their writers.

   Tech pubs managers might be better served by learning the basics of project management (especially the interplay between resources, time, and scope) and reviewing the development model of the engineering organization than adopting the CMM-inspired approach Hackos describes in this book.

   There is no one-size-fits-all method for producing documentation. And Joanne Hackos would be the first to tell you that.




3. Joann T. Hackos's book offers some interesting concepts, such as information plan, project plan, and content specifications, to name a few. Her concepts are well hidden under mountains of text that the unfortunate reader has a difficult time finding or understanding her intentions. Her book is information technology-centered, and technical communication has so much to offer other industries, such as oil and gas, healthcare, and financial, regarding project and documentation management. This book is not a good choice for college-level courses.



4. Another classic in need of updating, the 1994 book Managing Your Documentation Projects still provides good information about the basics of managing a technical writing project. It takes you from defining the project to completion, and on into the normally neglected phases of evaluation, and maintenance. This is a great tool for a writer who wants to formalize and add supporting structure to what he already does by instinct, for an experienced writer who is used to working alone and discovers he has no idea how to manage a team, or for anyone who wants to understand the mechanics of a well run team.



5. This book was verbose and not as helpful as I had hoped. It has some good information, thus my three stars but I think it is too long and not the best.

5 comments about Pro Apache, Third Edition (Expert's Voice).

1. Why a third edition? Wainright's first edition was well received and Apache was improved after the edition was published. So he produced a second edition. Guess what? The open source Apache has continued to accrue infalling upgrades. As Wainright explains, there are now two main versions, 1.3 and 2. Apache 1.3 is essentially the direct descendent of earlier versions. Very stable on unix/linux, on which it was originally developed.

   But the key thing about this new book is its descriptions of Apache 2. Apache 1.3 had inferior performance on Microsoft computers, when it was ported. Some people got fed up with this state of affairs and recast crucial portions, to produce Apache 2, which now directly uses native MS threads. It has much better performance than 1.3, on MS computers.

   The book goes into this in fuller detail. Plus it has the usual voluminous descriptions of what you can tweak for most web server needs. Luckily, if you want to deploy or use a vanilla configuration, the early chapters should suffice. Then consult the later text for more specialised needs.

   If you are already running Apache 1.3 on a unix/linux computer, it seems from this book that there is little incentive to migrate to 2. Relatively little to gain.




2. In this voluminous title author Peter Wainwright covers the Apache web server in detail. Chapters include Installing Apache and basic configuration, building Apache the way you want it, configuring Apache the way you want it, deciding what the client needs, delivering dynamic content, hosting more than one web site, improving Apache's performance, monitoring Apache, Securing Apache, Improving Web Server Security, and Extending Apache. It has some excellent sections on advanced configuration, handling robots, dealing with errors and handling them correctly, name-based and IP-based virtual servers, and improving the performance of your server. The section on securing Apache covers authentication (including digest and LDAP) and using SSL (including some advanced configuration techniques).
   
   There are better books that deal with some of the specific areas of this text (for example, Hardening Apache is much more thorough on the subject of securing your server) but you won't find a more comprehensive text in a single volume than this one. Pro Apache, Third Edition is highly recommended and my first choice for anyone looking for a single book to learn how to setup and configure an Apache server or serve as their primary reference.



3. The book is very well written it has helped to go through with the apache server i will recomended it to manyone who is interested in these kind of books. Very explicitly described the content of the book.An excellent purchase



4. This is by far the best standalone book on Apache I've seen. It really is a very good reference for professional web server admins, as well as developers and others, who need help in managing Apache web servers. It's well-written too, something that is becoming increasingly rare in the technical book area.



5. This book contains some meaningful information but is largely obsolete.
   
   Some fairly informative chapters contain introduction to common configuration, authentication, configuring SSL, using WebDAV and subversion.
   
   But lot of space in the book is wasted on topics that were cool in the last century like compiling apache and compiling single modules, but not relevant anymore. Today you are likely not going to recompile you server every week, but you SHOULD install security patches every week, if you take your job seriously. IMHO there is only one possibility - to rely on the services of your linux distribution.
   
   By the way, Debian and derived distributions also do a great job combating the mess in the httpd.conf by meaningfully dividing it in multiple configuration files, so you have a good place to put your specific settings making an automated upgrade to the newer apache version easy. So do not listen to the author, never edit your httpd.conf. ;-)
   
   The author describes in detail topics, that are not relevant anymore in the web application development (assumed that you are creating an application, that goes besides "hello world"). Delivering dynamic content (chapter 6) used to be server-side includes and cgi but it is NOT anymore because of poor programming model and poor performance.
   
   Typical scenario nowadays is to use apache as a front end web server, letting apache serve the static content like pictures and providing a wrapper or proxy to a high performance application server (for example mongrel if you using rails) or using mod_python for python or using zope etc. In this context I would wish elaborative description on mod_rewrite, that is pretty complicated.
   
   My conclusion: if you are beginner, search for a better introductory book. If you are advanced developer/admin/hacker, then use primary resources like [....]

2 comments about Visio 2007 For Dummies (For Dummies (Computer/Tech)).

1. As usual the Dummies series is pretty good and gives you a general intro and easy to build on concepts and how the product works and how to work it as you need it.



2. I recommend against buying this book. I read only about a third of it and found two errors on fundamental points. On p. 67, there is a glaring misstatement about the use of Wizards that suggests that the authors never even tried the feature they are "explaining." And on page 98 there is a section on "Nudging" shapes where in half a page of text the authors do not reveal the one thing that one must do in order to "nudge" a shape -- namely, hold down the Shift key while using the up and down arrow keys. It appears that nobody bothered to proofread this book after it was written.

5 comments about User Interface Design for Programmers.

1. This book has a number of problems.
   
   First, the writing is amateurish - hardly what I'd expect from someone trying to impart knowledge on a professional audience. It reads as a high school book report, not a reference for software engineers. I expect elegance in material I read, if for nothing else but to gain confidence in the author's intelligence and experience.
   
   Second, much of the information is clearly lifted from books such as 'Tog on Interface' (which I highly recommend). Take for example chapter 10 from User Interface Design for Programmers - 'People Can't Control the Mouse'. Spolsky's ideas on the problem of small mouse targets, as well as his solutions, are almost a direct copy of Bruce Tognazzini's (which I might add were presented much earlier). As another reviewer mentioned, not only are the ideas un-original, but they are presented haphazardly and with little supporting information.
   
   Overall, this book is not worth a penny. It is simply the ineloquent regurgitation of other's ideas.



2. This thin book is a good introduction to the idea of that you should make good software interfaces, but doesn't tell you how to do that. For that, Spolsky provides an excellent bibliography at the end.
   
   If you already have even a little bit of experience with good interface design, this book isn't for you. It's there to enlighten the programming masses that so far don't care or haven't been told that users matter.
   
   You can get this book for free online starting at Joel on Software (I think Amazon deleted the URL I put in there, but google for the book title and you'll find it).



3. I rarely give out 5 stars, but this book deserves it.
   
   Well written, on the light side, but serious about providing best practices for UI design with good examples to back it up.



4. First off, I'm not a (professional) programmer, and I'm not particularly interested in user interface design. I decided to read this book because I've read quite a bit of Joel's other work and I find his thought process illuminating, regardless of the subject. Also, most of the other stuff I've read by Joel is generalist in nature, and I wanted to see if his style would work in a deep dive into a subject. This book isn't a silver bullet in UI design, but it gives a few hints as to how to adjust your thinking to sympathize a bit more with the user. And despite the title "...for Programmers", there isn't much in the book that is programmer-centric, so it's useful for testers, product managers, and others in software development communities who aren't UI designers.
   
   It's interesting reviewing this book in 2008, seven years after it was originally published. Visual design is such a time-sensitive thing, and this book being pre-Web 2.0 looks dated. It's nostalgic in some ways (screen shot of Napster!) but that doesn't diminish from the overall value of the book. While some of the examples Joel uses are no longer novel, most of the principles that Joel writes about still hold true. The messages that are constantly reinforced basically come down to using real life metaphors and respecting the user.
   
   But therein lies my only real criticism of this book. Joel is prone to calling out statements like "users can't read" and "people can't control a mouse" as chapter titles, section headings, and even on the cover of the book. These statements run counter to his overall message of respecting the range of users of an application. What he really means is that "users don't have time to read all your documentation" and "people aren't always using a good pointing device". Reading the full text makes the positive messages obvious, but they are a bit overshadowed by the bolder, more negative statements.
   
   And a point on Joel's writing: Joel is at his best when he's taking examples from his life experience and applying them to whatever he happens to be writing about. There's plenty of that in this book, starting with his experience working in an Israeli bread factory and extending to studies of well designed non-software products. Joel is a master at putting his inspiration into words, and he doesn't disappoint here.
   
   Whether you're a programmer or not, if you're looking for a primer on UI design, this is a solid choice. It's a light, easy, entertaining read and packs plenty of value into it's 140 pages.



5. This book is aimed at programmers who don't have the time or inclination to do research on user interface design, and it has some good suggestions, but you shouldn't take anything he says on faith because he is flat out wrong a good 25% of the time. Spolsky is very intelligent and the book can be fun to read at times, but he also comes off as really really arrogant and narrow minded. He is particularly and undeservedly venomous towards the Linux / OSS community, and this is really inexcusable.
   
   Here is the executive summary: users can't read dialog boxes, they can't use the mouse, the don't read instructions, they have an idea of how the program is supposed to work, and most of the time they can't be bothered to learn how the program "does things differently," so be consistent and imitate programs your users are already likely to be familiar with.
   
   You can lump all of this under the general heading "reduce user effort" which is a pretty good design philosophy. It really only breaks down when your users include other software developers. Developer software has its own set of user interface rules that are completely different (use man pages, don't produce output if everything is OK unless you are testing or the program is doing version control) but Spolsky doesn't appear to understand or appreciate this, so you'll just have to learn it on your own (you can start by googling unix philosophy).
   
   This book gets 4 stars because the average computer book is AWFUL, so this book easily gets into the 80th percentile.

5 comments about Oracle JDeveloper 10g for Forms & PL/SQL Developers: A Guide to Web Development with Oracle ADF (Osborne Oracle Press).

1. This book served well our need to train Oracle Forms developers in JDeveloper/ADF. The first part is a good technological review, the second a hands-on to build an application that not only tells what to do and how to do it, but explains it fully. It was useful even after attending formal Oracle training.



2. This is an excelent book for begining web development, it explains you step by step how things work and "glue" together. The only reason for me to give it 4 stars is that, in the book it explains how to build part of an application (tuhra) and it tells you to look for the rest (of the app.) on the web site..... I looked for it but it is nowhere to be found... (they only have the parts of the app. that you develope while doing the books excercises).



3. Great



4. exellent Book
   
   Goods Tips for programming Oracle ADF
   
   greetings from Toluca, EdoMex, Mex.



5. Being a traditional pl/sql developer, I was drawn to the title of the book immediately. I know I need to eventually buckle down and learn Java, but what better way than by drawing parallels to pl/sql and Forms.
   
   I like the hands-on examples that has you build a fairly complete application from scratch. I say fairly complete because its only a 500 page book and it allows the reader to go out and research ways to improve it.
   
   One of my favorite parts of the book is a summary section that shows up after a large chunk of instructions called "What did you just do?" This sums up what the reader just performed - explaining in layman's terms what you actually just did.
   
   Although I'm sure you can get similar tutorials on OTN somewhere, having a book to flip back through is always nice.

5 comments about Project Arcade: Build Your Own Arcade Machine.

1. I like the book. but i wish to warn buyers about outdated parts. in the book and on the cd it lists many links. but many of the website have gone down and are dead. in the description for the book it says it gives details on making controls, but some cases it just gives links. some of are dead. but it does give good info on emulator, encoders and many other things that are hard to find on the web. but i think the man should have cut some parts short and added controle construction.



2. This book covered so much more than what I was expecting. If you have never built an arcade cabinet before then I would recommend this book if only to see how many different ways it can be done.



3. This book is a lot more "Techie" than I expected. It involves taking apart and reconfiguring quite a few things to get what you need. Sure it shows where to buy the components if you wish, but then why not just buy the arcade game already made. It does show you how to build the case. I thought it would show how to take your X-Box or Playstation and build an arcade enclosure to get the arcade feel. That is not what this book is about. You take a computer and several components, plus a moniter to make an arcade game. It is very informative but not quite what I expected. It is not a 1 or 2 weekend project. Do a search for mame to see what I mean. Mame is very important to this project.



4. This is a good book.
   My only thing is most of this is on the internet and may even be more updated if you find the right websites.
   
   But it is helpful as for the beginner will help you plan things out in advance. Would be nice to have a few more illustrations like some sample wire diagrams of the controls etc.
   
   But again..it has lots of reference websites listed in the book that can also assist.
   
   My suggestion is -> don't build a Mame Cabinet if you don't have the internet...because you will need it.
   
   Seems to have covered all the basis and the added cd is a nice touch.



5. Following the Arcade scene for a few years, I've been promising myself this book once I'm ready to sit down and start building my own MAME Arcade cabinet.
   
   After getting the book and skimming through the pages, I was disappointed to find it's either information I've already discovered on my own by surfing the Internet, or the links to additional content or files are severely outdated and a number of external links no longer work. The copy of MAME they provide you is ver 0.7x (Latest incarnation of MAME is over .100)
   
   Don't get me wrong, this book is great for those who haven't already done the research and want an all-in-one book on how to do it. For me however, I gained nothing from the book.

5 comments about Hibernate in Action (In Action series).

1. This is not a bad book. I'm glad I bought it and glad I read it. Its problem is that it doesn't live up to its hype. It is not "the ultimate Hibernate reference" by any stretch. In fact, it's not much of a reference at all, so if your expectations of it are too high, you may end up disappointed.
   
   If you are serious about learning Hibernate and want to get as much depth and background on as many aspects of it as possible, this book is definitely worth reading. The text is well-written and clear, and the information is straight from the most qualified Hibernate committers.
   
   On the downside, this book is missing most of the important administrative and troubleshoting information you will want when you are actually using Hibernate, the book isn't organized so you can easily find any particular detail, and Hibernate is moving on, so some of the information is dated.
   
   Ultimately, if you want practical information or a good reference on Hibernate, I don't think the question you want to ask is "what book should I buy?" You want to ask "why should I buy a book at all when I get much better info for free from google search?"
   
   When you are first getting started, the "getting started" example from the online doc distributed with Hibernate is comprehensive and useful. By contrast, the "Hello World" example in this book is superficial and missing information you need. For example, the very first thing when you work with Hibernate you'll have to include about a dozen .jar files into your project, and you have several choices among alternative jars that you won't care much about `till you become more advanced. Some help is online, little or none is in "Hibernate in Action."
   
   I think Hibernate is all-in-all a great piece of software. Object-to-relational mapping is a hard problem to solve, Hibernate does a great job at the basics of it, and the world is a better place because the boys from jboss donated us their solution. When it works it's like good magic should be. But when it fails, it fails hard, horks all over itself, and spews out a bunch of mostly unhelpful junk. Hibernate suffers from having been developed by an insular group of developers who are too close to their problem, and who have lucrative day jobs as consultants they need to get back to. The result is not much in the way of troubleshooting help, and troubleshooting help is what you'll find you need most. Hint 1 - you won't find such help in "Hibernate in Action" so go to google and type in the text of the error message you get. Hint 2 - you will find a lot more people asking the same question than people answering it. Perservere and be a good detective and you will figure out what you need.
   
   References are organized so you can easily find that one little detail of information you need right now. References have things like short sections with short clear titles that are language keywords or clearly intuitive concepts. References also have long, detailed indexes with a lot of repitition. "Hibernate in Action" has none of this, and it is devilishly hard to find details in it even though you know they are in there somewhere. My copy has about 25 little sticky note bookmarks to help me find things, but most often I don't bother and I just go straight to google.
   
   Finally, Hibernate has evolved since this book was published. My favorite change is that it now includes support for Java 5 annotations as an alternative to XML or XDoclet configuration. Hibernate is notable, like Struts, in helping you get out of J2EE-EJB hell, and into XML configuration purgatory. Annotations rock in relieving you of the keeping-the-XML-in-sync-with-the-Java torture, and you need a reference that doesn't steer you towards doing it the old way. AFAIK, as of this writing, that's only available online.



2. With this book, we have the rare circumstance where the founder and principal developer of the technology has authored the material. Moreover, the back jacket promises that the text would build on a single example to show how to use Hibernate in practice.
   
   Sorry, dear reader. This book falls far, far short of its promise. Yes, you can download a single cogent example. But the authors make only loose reference to that example, choosing instead to offer dozens and dozens of snippets, out of context with the example. A first-class book, such as Mastering WebLogic, not only provides a robust example, but also walks the reader entirely through the example, from design choice, through coding practices, and ultimately into implementation decisions. In stark contrast, this book offers nothing more than a progression through various topics, illustrated via pieces of java classes, leaving the reader to hunt for the relevance to the downloadable application.
   
   The book does have its uses. As you dive into various real-world situations, this book should serve, after some digging, to reveal an optimal approach to solving the problem at hand. The topics are covered to a healthy depth. I suspect this is the best treatise available on abstruse topics such as caching, transaction handling, and mapping to legacy data stores.



3. I found this book useful and readable, and it helped me develop my first (and second) Hibernate applications. It begins with a brief overview of the kinds of problems which ORM solutions need to address. It then introduces Hibernate along with a couple of examples, upon which subsequent chapters build. (Some reviewers have criticized the examples, but I thought they were useful, and I didn't have trouble following them) One thing you should be aware of: while this book is a good narrative, it's not as useful as a reference. I find myself paging back and forth among several chapters which cover topics in different levels of detail. That shouldn't be a show-stopper since reference material exists on the web. You might be concerned is the book covers Hibernate 2.1, while Hibernate 3.x and Ejb 3 are out; the book is still relevant and valid, and I've used it along side Hibernate 3 with no problem.



4. This book is for Hibernate 2. Hibernate 3 is covered by the same authors in Java Persistence with Hibernate



5. A great book for getting going with Hibernate quickly.
   Some parts are heavy going because it is packed with info. This pays off because there is little or no padding/rubbish.

5 comments about Exceptional C++: 47 Engineering Puzzles, Programming Problems, and Solutions (C++ In-Depth Series).

1. This book is a collection of silly, unusable tidbits. The author discusses unimportant issues that most programmers have no need to know in order to create excellent c++ code. If this is how one becomes a C++ Guru, then count me out!



2. There seems to be a bit of confusion about what level this book is at. Based on some of the reviews I've read, I was a bit concerned that much of this book would fly right over my head, exploring advanced and obscure features. So let's get one thing straight: this is pitched at the same level as Effective C++, and has a similar structure and style.
   
   And it's not just a 'puzzle' book - although it does highlight some tricky issues to do with templates and name lookup, which might conceivably appear in an unimaginative job interview.
   
   And it's not just about the language feature of exceptions. All aspects of the language are covered, but the section on exceptions is particularly good.
   
   Nor is it 'advanced' in the sense that many practitioners of C++ would consider, e.g. template metaprogramming, or non-portable hacks that take advantage of memory layout of compilers. Instead this is advice at an intermediate level, assuming you know the syntax and purpose of C++, but exploring their most appropriate use.
   
   The structure of the book does involve a series of posed questions, but they differ wildly in how specific or general they are. You can see them more as a rhetorical device to frame the subsequent discussion, rather than questions you must answer (unless you want to retrospectively crown yourself guru of the week, of course).
   
   Each question is followed by a significant discussion of a particular language feature, and summarised advice and recommended principles. Therefore the book is similar in structure to Effective C++. There is some overlap between the books, although even where similar material is included, there is differences in how much detail is given.
   
   To some extent, this book is a victim of its own success. A lot of the advice given here can now be found in other books. But its legendary status means that like Effective C++, this is still essential reading as soon as you've graduated from introductory tomes.



3. This book presents advices more or less in the same format than books from the Effective C++: 55 Specific Ways to Improve Your Programs and Designs (3rd Edition) (Addison-Wesley Professional Computing Series) serie. What is similar is that topics are divided in 47 small items of few pages each. The difference is that the author first ask questions to the readers or propose exercises and encourage the reader to put down the book and to take the time to think about the problem and then come back to read his answer. This format is more or less original as I have seen something similar in Tom Cargill C++ Programming Style (Addison-Wesley Professional Computing Series) book.
   
   I have read this book pretty fast which is a good sign of my interest in a book but in the same time this book did not leave me a strong impression that will make me remember this reading for a long time. It is hard for me to say exactly why but I think that it is because most items focuses on very small details of C++. Some of these problems are very hard and probably is an indication that the book targeted audience is advanced C++ users which is not a bad thing by itself but I am not convinced that mastering these small details actually has a high impact on someone programming skills. It is probably just a matter of topic choices as I really appreciate much more the sequel than this book.
   
   My review will probably not affect your decision to read or not this book. You will have to read it to find out if you like it but hopefully I have been helpful to let you know what to expect from this book.



4. Just finished it. It may not be so apparent at first, but definitely you need it to find how to write a "perfect" C++ code.
   Of course, before reading this book, several intermediate books demand reading, such as "Effective C++", "More Effective C++", "Effective STL". Some system programming book may also need to be read. Otherwise, you may have no idea why you need this book.



5. This book and exceptional c++ series are the best book series, I have ever read. Its language and presentation of material is exemplary. I learned a lot from this book and suggest to anyone to leverage his/her knowledge.