5 comments about STL Pocket Reference.

1. Cute, if I may use that term for a computer book! Hopefully, you already are familiar with the constructs described in this nifty little guide. Priority queues, queues, sets, iterators ... The book is strictly an aid to memory. You might consider it the hardcopy kin to online manual pages on each term.

   Which raises the question. If you have the equivalent information already on your computer, why should you get this book? For some, there is in fact no need. But a surprising (and ironic) number of programmers still prefer hardcopy by their desktops. There is still something appealing about the combined visual, tactile and random access of a good concise reference book which trumps a screen, though we all write to the latter nowadays.




2. The O'Reilly Pocket Reference series serves the need of software developers to quickly lookup how to code something that they don't do every day. The formula is quite strict. Like all of these books, this book is a hybrid of introduction, cookbook, and reference in a package that is small enough to easily fit several dozen on your bookshelf. What's good about the STL Pocket Reference is that it provides succinct descriptions of some very abstract concepts that are the lingua franca when dealing with the Structured Template Library. What's missing here is more sample code.



3. This small but succinct reference book is all that I wanted in an STL pocket guide and more! I am using it today while teaching a beginning STL class. It is more useful to me than the many textbooks I have been reading on the subject. GO GO O'Reilly! Your materials are excellent for programmers.



4. I love these little pocket references, since my new job I use custom container classes, but when I was using the STL this was a wonderful reference.
   I actually like these booklets better than Microsoft's electronic documentation, but Apple's XCode documentation system is still faster than paper.



5. I have used stl and think stl is great. I was hoping for a quick programming guide so that I did not have to carry and reference stl books I all ready have. Very few programming examples were given. Found very little use for a book that gives short snippets about stl but avoids showing the use of stl in programming.

3 comments about Beginning SQL Queries: From Novice to Professional (Beginning from Novice to Professional).

1. I'm a computer-savy first time SQL'er. I found this book to provide a quick and complete introduction to SQL that allowed me to straight away get going. It's written from a practical stand point which is really useful if you're like me and just want to get the job done.
   
   I also like the way book tackles the subject from two different angles - she calls it the Algebra or Calculus angles. Sounds mathematical but it simply means that when you're got a complicated problem you've got twice the chance of finding a solution.
   
   This book comes totally recommended. I became quite intrigued by the stuff about how you should design your database right that I'm now reading her book on Database Design.



2. Last year I read and reviewed Clare Churcher's excellent little introduction to database design. Although I learnt enough SQL at the time to write working queries, I could not resist picking up this book when I recently saw it. And true to form, Clare Churcher has written another gem. What I particularly like about the style is that all examples are kept simple while conveying important concepts.
   Two different ways to approach a query are introduced in the book, the "algebra" or "how-approach" and the "calculus" or "what-approach". Why two approaches? According to the book, student classes are equally divided in which approach they prefer. With two approaches to choose from there is a greater chance that anyone reading this book will find it useful. I'm personally greatly helped by the "what-approach" in reviewing old SQL code as well as writing new queries.
   This book is a must for anyone learning SQL for the first time. In addition, it provides a refreshing new way of looking at SQL code for those who already know the basics.



3. Wordy and obtuse. Typical PhD attempt at a user manual.
   If you're a novice, it'll confuse you more than necessary; if you already know SQL, it'll bore you more than necessary.

5 comments about Object Design: Roles, Responsibilities, and Collaborations (Addison-Wesley Object Technologiey Series).

1. Overall very good impression, original presentation with sidebar essential quotes. However after a while seems more of the same: how to identify collaborations in an Object Oriented Design. Special note for Chapter 8, where valuable and interesting information is provided regarding exceptions and errors.



2. I am a developer/programmer for a technical software company and my review contains my perception of this book from that perspective. I must also disclose that I am sceptical of any object-oriented design methodology that involves a lot of writing. We are "programmers", not story writers (read use cases).
   
   When I ordered this book a week ago, I couldn't wait to get my hands on this book because it sounded so promising. My enthusiasm turned into total disappointment so quickly I couldn't believe myself; I had to give another shot in reading this book to make sure. But I am convinced; the authors managed the impossible task of filling its 390 pages without saying anything substantial about object-oriented design for a professional software developer.
   
   The book might be useful for a novice programmer or a manager in terms of defining the object design jargon and process. But other than this, it provides no valuable advice for a professional. These are some of the points that I find ridiculously simplistic and almost idiotic:
   
   - In my opinion use cases and CRC cards all boil down to writing on a piece of paper what classes one should use and what these classes should do. This is not methodology, it is common sense. Any sensible developer would write down his/her ideas about the classes involved in an application before starting to program.
   
   - Although it is valuable advice to think about class responsibilities, the book states nothing more than the obvious in terms of finding what responsibilities should be assigned to which classes. Statements like "Responsibilities come from statements or implications of system behavior found in use cases" are tautologies. Where else would they come from!
   
   - Or the chapter on Flexibility says things like "Find out what you don't know". I can't even begin to elaborate on philosophical implications of such advice!
   
   Although the book looks appealing to the eye, it has no clear content. It states ideas about classes, responsibilities, etc without a clear structure; and after a while, everything said seems to be a repetition of some earlier statements.
   
   If you are serious about object-oriented design as a "programmer" I recommend these three books:
   
   1. Gamma E., et al., Design Patterns.
   2. James R Rumbaugh, et al., Object-Oriented Modeling and Design. A bit dated, but you will get all you need to know about object oriented design from this book.
   3. Bjarne Stroustrup, The C++ Programming Language (Special 3rd Edition). Never mind it is a C++ book. Chapters on OOD (I think chapters 21-25) will tell you exactly what you need to understand to start programming using OO approach.
   
   Do yourself a favor and invest in these books; and ignore all the fab about such trendy books such as the one reviewed above.



3. I have read so many OOAD books, none of which give me a clear idea how and why software design should be designed that way,
   at which situration, according to which external facts should the correct design decision be selected and considered.
   In core OO design stream, we will distributed/assigned each object with their desirable responsibilities, we must select a flexible control and coordation style to allow software for change. it is a system view of our software.
   
   This book given me a best introduction to think a solution all above questions and design views(system behavours).
   When I read and studies this book, it let me consolid and remenber many knowledge above control theory, layer architecture of big software system such as CAD system.
   
   Each project have particular siturations and design constraints,
   how we can design a useful software to solve user requirements is the first thing to consider.
   
   Many formal formalism will not be work for flexiblity, such as RUP CMMI... etc, those processes like a doing documentation not a useful design and devlivery working software that fit our users requests. I think experience programmer, developer should more thinking in system point of view.



4. The authors provides a good introduction to object oriented analysis and design. Some may find that the content is too wishy washy with seemingly vague advice in many areas. The responsibility driven approach along with object stereotypes are indeed a good way to approach OO design however. The concept of object neighborhood and control style are also worthy of praise.
   
   If the reader persists they'll be rewarded with a good understanding of why OO design is needed. There are nuggets of wisdom throughout the book, however many sections seem to be hastily done and glossed over. Too many times the authors resort to bullet listings to explain concepts. That may be acceptable in today's power point age but its not acceptable for a technical book. Reading lists after lists of advice is not a good way to learn and retain concepts.



5. I have to agree with some earlier reviews on this book.
   1. Very Good Text on Object Design,
   2. A great first text on OO design,
   3. Total Disappointment for Programmers
   
   This is a great book on Object Oriented Design, but ONLY for novice and intermediate object modelers. It is not for an experienced developer who already knows how to use some of the design patterns in Gang of Four book.
   
   If we use an analogy to compare this two books, if Gang of Four Design Pattern book is for post graduate students, Object Design is for the student in the second year of the university.
   
   I want to read more on Object Oriented development so I started to read this book, mainly attracted by its cover. Domain Driven Design by Eric Avans falls into the same category but offers much more exercise for your brain.
   
   Hope this is helpful. I have 10+ years in software development, 7+ years in Java, understand OO and Domain Driven Design.
   
   5 Star Book for a beginner.

No comments about Learn Objective–C on the Mac (Learn).

5 comments about Beginning C# Objects: From Concepts to Code.

1. It's good book valuing to read and collect



2. The book seems nice at first but as you pass to chapter4 most of
   his example programs don't compile, I get errors. Also the explanations are getting confusing. You can't assimilate all those
   remarks for 1 line of code. The author surely try hard but
   all the pics and explanations totally confused me. I won't go to chapter 5. I purchased this book & Learning C# 2005 from Oreilly. Oreilly has less examples but at least the example are clear and they compile without any errors.



3. I just finished reading B.C#O.F.C.t.C and it is about the 5th C# book I've read as I try to restart my programming skills (VB5 last tool really used) with C# and .NET.
   
   This book is a very good starting place for those who are new to Object Oriented Programming (OOP) and who want to start developing a strong OOP mindset. Being that I had a sorta-OOP background with VB5, some of the stuff was a rehash, but I think a person totally unfamiliar with these concepts would find the introductory pace helpful and properly paced. Plus the authors strong bias towards how to design (and reconsider/redesign) your classes with business needs in mind and good OOP design methods will well serve such readers into their later experiences.
   
   The C# language introduction is acceptable as long as one understands you are giving up some in depth training (it is a beginning book after all) for the extra emphasis the authors put on OOP design (e.g. the cover UML diagrams while most other C# books barely touch on such design tools/notations).
   
   The example they build out throughout the book (a Student Class Registration program) I found completely uninteresting and that made me prone to skim the code examples, not really thinking them through as I think you need to do to learn from these types of books. I can see why the authors selected such an example when they are explicit about their intention for the book to be useful to college classes in computer science departments. I also see the pros for an example that is built upon bit by bit over the course of the book. But for me, the large structure interferred with my ability to focus on my areas of interest.
   
   In short, a very good book for those coming fresh to C# and OOP, but if you like me have exposure to either, you're probably better off with two books (e.g. Jesse Liberty's C# programming books from O'Reilly for C#, OOP + UML book for training on those items). I do agree with the authors that understanding how to take it from concept to code well means "thinking" OOP from the start. This books will probably help nurture many OOP neophytes into such expert OOP C# developers.



4. The preception of a books quality depends on what the reader wants and needs. For myself, I gave this this book 5 stars.
   
   Dont expect another coding tutorial. They have their place, of course, but this one is more about project design and implementation. Its not about how to make an object, but how to make objects work together.
   
   Its divided into three basic sections. The first part is an overview of C#. Its not for beginner but will be a good refresher for a mid level deveoper. The second part is application design, and the last part shows how to bring it all together. The examples little simplistic at times, but in the end to illustrate some rather abstract concepts
   
   I've worked as a programer for the past 8 years, and I admit I have been lazy in my professinal development. Im sure the noun/verb and UML diagraming can be found else where, but I found it here first. The information was enough to take me to the next level. I feel I now have a fundemental understanding of how OOP is suppose to work. I would recommed it for a mid level programer who is eyeing project management.



5. This is the best book for beginning objected oriented programming I have read. It explains clearly step by step how object are created and used. All of the OO buzz words are explained with clearly written examples that you can actually understand.
   
   The programming concepts to fully utilize OO programming is explained with examples that are understandable so that you can use the concepts for your own programming.
   
   Also explain C# language in terms of OO programming and methodology so that you learn the language while learning how to program OO. Buy This Book!

5 comments about Beginning EJB 3 Application Development: From Novice to Professional (Beginning: from Novice to Professional).

1. Over the course of a couple weeks I read the entire book. I found that the book provides the most value by doing this. I had some limited experience working on existing EJB 1/2.x apps and have developed some prototype apps using EJB 3 also. The book really filled in some gaps in my knowledge including the history of the specs. I don't know that I would use the book for a reference though. I will probably refer to the spec to get the details.
   
   Although I didn't follow the directions provided to get the code samples running in the Glassfish server I appreciate the detail the authors went through to help the reader. The directions seemed to be complete. I didn't feel like I had to go through this step because I already have code up and running deployed to Glassfish using Netbeans.
   
   Sometimes I felt like the book didn't provide enough detail using nontrivial examples in certain areas such as the lifecycle and interceptor methods. Other times it provided too much detail such as the examples using JSF. I'm about to start a project using EJB3 and JSF so I found the discussion of integrating JSF into an EJB3 app interesting but the average reader would probably be better of referring to a book specifically on JSF.
   
   The sections on performance testing were some of the best in the book. They explained how to set up the tests and the important statistics to look for. I was looking for some information on unit testing EJB3 outside of the container and was disappointed not to find any.
   
   Overall I thought the book was excellent and would recommend it to both developers new to EJB3 and more experienced ones that either want a good overview of the subject or are looking to migrate apps using the older specs. The book didn't blow me away but I still found it hard to find even minor points to be critical of. The book has definitely given me the confidence to apply the new technology appropriately.



2. EJB 3 took its time to get mass acceptance, primarily because many Java developers did not have great memories of earlier versions of EJB. EJB 3 is however now gaining momentum and a number of EJB 3 books have hit the market. Beginning EJB 3 is a Beginner - Intermediate level book from Apress.
   
   In their letter to readers, the authors say that "With EJB3, the EJB spec developers had at last settled upon a model that really made sense. Coming from EJB 2.x world, it was like a breath of fresh air.." So EJB 3, is widely believed to be a significant step forward in simplifying enterprise Java development.
   
   The book uses several examples to demonstrate the new found simplicity of EJB 3. The free, open source application server GlassFish, which is the reference implementation for all specifications in Java EE 5 is used in the book.
   One of the important changes in EJB 3 was the introduction of annotations. However XML descriptors are still very much around. Java development has a tradition of always taking the most complex approach and if there isn't one, it works at complicating the simple approach. So after the initial excitement about annotations, there's again uncertainty. It's now (Annotations) vs (XML) vs (Annotations & XML mix). On this, the authors say "A simple rule we follow is this - If we need to decouple our entity and bean classes from their EJB 3 metadata, as when we want to use the same entity classes with two different inheritance strategies, we put our metadata in XML. Otherwise, we stick with annotations" "And don't forget...whenever metadata is specified for an element using both XML and annotations, the XML always wins"
   
   Chapter 1 introduces EJB 3 and gives us a quick overview of all that's changed in EJB 3.0. Chapter 2 looks at session beans and dives into using dependency injection in session beans, interceptors, callbacks, local vs remote access even before a session bean example is deployed. So the book kind of works with the assumption that you have tried your hand or as some would say "burnt your fingers" with an earlier version of EJB. The book runs the risk of being too fast for someone who might be trying EJB for the first time.
   
   Chapters 3 and 4 look at entity beans and persistence and Chapter 5 looks at message driven beans. Chapter 6 begins with the basics of Web Services and then moves on to the various web services specs and how you can use the @WebService nd @WebMethod annotations to quickly get your app web services ready.
   
   Chapter 6 to 11 deal with web services, integration, transaction, performance and migration from version 2.1. The good thing about these chapters is that the authors first introduce the concept, the need and the basics and then delve into the actual development. Problems while deploying EJB across applications servers were commonly reported with earlier EJB versions, so it's good that the authors have dedicated a chapter to EJB 3 deployment and planning.
   
   JSF has become more or less the standard for new Java web development. So Chapter 12 is a useful one as it shows EJB client development using a simple JSF + EJB 3 application.
   
   Overall, for a beginner-level book I think it would have been good if there was more content and hand-holding in the initial chapters, as Apress has a book "Pro EJB 3" which could look at the advanced EJB topics in detail. But if you have been on the enterprise Java scene for some time and have tried out EJB earlier, this book will get you going with EJB 3 in no time.



3. I thoroughly enjoyed reading the "Beginning EJB 3 Application Development" book. (I'm a senior programmer, have been using Java since 1995 and am co-founder and co-leader of the Austin Java Users Group.) The book started off with a nice executive overview of EJB 3 and the usability problems with EJB 2 that it solved.
   
   On a side note, I have been impressed by the EJB 3 working group for making such a bold move forward while remaining backward compatible with the old specification. Typically as a given software technology matures and becomes well established, the software infrastructure and APIs develop a lot of inertia that leads to significant resistance to large improvements. The EJB 3 working group overcame this pressure and produced a bold new elegant design that should be a pleasure to work with. It always takes time and a lot of work to create a clean simple design and I think the team has done that finally with EJB 3.0. The authors captured the advantages of the new specification and leveraged the new capabilities and simplified approaches.
   
   I appreciated the section on setting up the environment and the mechanics of compiling and deploying the EJBs using the free GlassFish application server. Just enough detail of the incantations to work with the server was given in order to get started without getting bogged down in lengthy setup descriptions. The authors provide examples up front to get you quickly up to speed with the new paradigms. They continuously mix clear examples with explanations to ensure that you gain an incremental understanding quickly.
   
   Stateful and stateless session beans are covered. Comparisons are made between annotations and the XML descriptor files and the rules to override are clearly defined. I enjoyed the section on interceptors and was impressed how easy it is with annotations to intervene with preinvoke or postinvoke operations. I liked that the authors are succinct with their explanations. The authors get to the point quickly, which I appreciate given the volumes of material one needs to absorb to keep current in this industry. The examples start off simply and gain complexity as more features of the spec are added to the application. Useful process flow and database schema diagrams typically accompany the examples to clarify the problem.
   
   Early on I found a couple of small bugs in the sample code (mostly caused by a moving specification), but the authors have been very proactive about posting erratas on the website.
   
   JMS and message driven beans are discussed as well. A quick overview of JMS and MDB is given with a succinct, but very relevant status-notification example. The mechanics of setting up a JMS topic and a JavaMail resource is described, as well compiling and deploying the MDB.
   
   There is a nice brief overview of web services and the associated standards. A useful credit card verification example is provided complete with the mechanics of compiling and running the code.
   
   I thought the sections on the Java persistence API were well done. I felt the authors covered most of the typical issues that you run into when mapping Java objects to a relational database schema. Advanced sections covers hierarchical modeling and the advantages of user-defined primary keys for instance. Concrete table definitions and their associated Java mappings are illustrated.
   
   The authors demonstrated that they have solid design experience since they intermingle practical sage advice and admonishments througout the book.
   
   I thought that there should be more advice on forward versus reverse engineering of the database schema since there are a lot of lousy database schemas out there that have been generated directly from the Java object model.
   
   The authors provide a good overview of container versus bean managed transactions. The mechanics of using each approach and the associated trade offs are illustrated. I like that the authors included some of the basic information on transactions such as the definition of ACID for instance. (I need to refresh my memory every so often.)
   
   The performance benchmarking section was very well done. A clearly thought out methodical approach to performance testing is given with what I thought were surprising results between the two mapping approaches (single table inheritance and inheritance through joins). An overview of a very useful load testing tool is given as well. Salient performance comparisons between EJB 2 and 3 are also presented.
   
   For the seasoned EJB 2 folks, there is a chapter on migrating the EJB 2 applications to EJB 3. This chapter may help in understanding what EJB 3 does for you compared to EJB 2 as well.
   
   In summary, the book was definitely worth my time to read. Beginner and advanced programmers will learn from this book. I'd definitely recommend getting the book and I look forward to working with EJB 3 in practice.



4. The book is a good summary of the specs and gives a nice introduction to the new things in the world of EJB 3. The section on converting your v2 apps to v3 was particularly useful. Appropriately marked "From Novice to Professional" the book touches on many aspects of the J2EE world in a manner that treats the novice with care and the professional with grace and insight/direction.
   
   On the negative side... The book has a lot of repetition. Many pages are nearly identical (especially the sample building) and could have been condensed and made more useful by sticking to use of Ant and examination of the scripts. The same can be said for the "copy-and-paste nature" of some of the writing. However, one can tack that up to "consistency in writing style."
   
   The book is not what I would call an "easy read," but was informative none-the-less. It serves as a starting point and base reference.
   
   The authors have provided a generally well-rounded book and I would definitely recommend this to others.



5. Seems like a good book when you skim it in the book store. After you buy it and start reading, you realize that (a) there are many errors, and (b) APress (publisher) has "disappeared" the errata from their web site. Nice. I'll be contacting APress about a refund (unfortunately, I write in my tech books :-)

5 comments about Windows Forms Programming in C# (Microsoft .NET Development Series).

1. "...I had hoped it would be a convenient and quick reference to such questions as "how do I use FolderBrowserDialog and/or OpenFileDialog to open a file in my C# program?" but although these standard components are indexed in the book the discussion of them in the book is shorter than this review I am writing. What I would want is some kind of sample code, maybe a step-by-step description of how to add the components to my program..."
   
   There's no way I could have said it better. The book seems to want to cover "everything" but actually manages to say "nothing".
   
   The only part in which I would have to disagree with the previous reviewer is his rating. He gave it three stars. I think it deserves one.



2. I got this book after having already done quite a bit of WinForms programming and found it a compelling read. I'd have read after a platform/language primer but before doing any actual WinForms work, had I had it in my possession at that time.
   
   Its the first programming book in some time that I read as a 'page turner' - it's that well-written (in prose terms).
   
   It's also very well copy-edited, which shows that a lot of effort went into getting the book just right, which can't be said for all books (I guess the gap between release of .NET 1.0&1.1 and this book allowed for that more than in other books).
   
   As for the relevance of the information, I believe it to be very relevant to a wide variety of application types, regardless of that being the main criticism I see in other reviews here. I guess that comes from the fact that you can't please all the people all the time. Still, I'd venture it comes as close as any other book is going to come.
   
   For me it's very near the top of the must-have books if you're going to be writing non-trivial production WinForms apps.
   
   One thing to be aware of is that the .NET 2.0 version is on the way in the coming months, making it Essential unless you're not in a position to use 2.0 stuff.



3. 
   
   The second edition is out that covers Windows forms V2, you may want to buy it instead.



4. I'm a Java programmer who finished reading O'Reilly's "Programming C#" (very good book), and wanted to get started in Windows Forms programming. Chapters 1 and 2 were decent and Appendix B was an excellent introduction to Delegates and Events.
   
   The rest of the book, however, was very weak. All it did was give a brief summary of some of the windows forms components (and the coverage was very weak). If you want to learn about a component you are going to have to look it up it on MSDN.
   
   I was hoping the book would give me something other than what I can get by looking at an API. I was really hoping there would at least be a few chapters on how to design Windows Forms applications - there was nothing. The easy part is learning how to use a component. The difficult part is learning best practices about design an application - something this book didn't touch.
   
   Also, I'm not sure how the rest of the books in the "Microsoft .NET Development Series" are, but I think it's very cheap and dishonest to make a book 'appear' weighty. The book is 680 pages, but the margins, line spacing, and text are all very large. This book easily could have been half its size.



5. Contains all the essential information and a little bit more but not much more. Over all a pretty good starter book.

5 comments about Use Cases: Requirements in Context (2nd Edition).

1. Programmers naturally hate use cases. They seem boring, and having seen hundreds of them (written by others and handed to me) over the years, I had lost hope that this practice would ever be of any benefit. I had grown tired of constantly reading varying levels of abstraction and `use-case-itis'. All this, despite the fact that Jacobson's original work and the UDP incorporation of use cases as central to that process was clearly a better way to go than wading through hundreds, sometimes thousands of pages of `shall' statements that accompany most projects (and too often, lead to their failure).

   Then I read this book. I now use it regularly in every requirements-related class I teach, and I tell every programmer I meet to buy this book. Imagine a use case book that programmers can actually get excited about! This book blazes new territory and its practical insights and humor make it a fun read, as well.

   Here are the great highlights:
   1. Properly scoping and relating use cases
   2. Introducing Business Rules as 'first-class citizens"
   3. Applying UDP iterations to the use case development process.

   These last two items make the book stand out. Understanding the importance of business rules as enterprise-wide invariants that span use cases is ground-breaking. The four UDP iterations are ingenious because they can help to enforce the proper level of abstraction, which is a big problem area for use cases. Try it, you'll like it!

   In addition, the book is loaded with great practical advice and examples of good (and bad!) use case text. And finally, the authors present the most compelling arguments I've ever heard for ditching traditional requirements-gathering methods (which have clearly FAILED), because use cases are, after all, requirements IN CONTEXT (like the title says). If every use case writer read this book and followed it's advice, the software crisis would be dealt a serious blow.

   Bottom line : If you write use cases (or worse, are forced to implement bad use cases at gunpoint), get this book!




2. I saw this book in a stall, while searching for some other book. I had a glance at it and really liked the simplicity and practical approach. Once I bought it and read it completely, I felt happy to find such a great book on Requirements Study. To read and understand this book you need not have a lot of experience or a Requirements Specialist. I feel anyone from Programmer to Project Manager will find this book very useful. The authors teach you in a very practical manner, how to come out with good Use Cases. I enjoyed reading this book, applied the concept in my projects while doing Requirements Study and now can happily recommend this book to others.

   Three cheers to the authors for a great work.

   Note: I found Craig Larmen, while talking about Use Cases in his best selling book on UML and Patterns talks highly about this book.




3. Being in the middle of a messy project this book came to me a little late. I consider is one of the best introductions to
   the understanding of what a use case is and WHAT things you should put in it. Everbody has suffered for long endless meetings discussing which is the scope of the use cases and how it should be used, I strongly recomend to read this book before start arguing.
   I give it four starts because it lacks in some way of paths that can work as guidelines trough the process, although is not the focus of this book, it would very useful to include a couple of pages reviewing this subject.



4. Very interesting stuff and fluid understanding..Could have more topics though



5. Too often you find books on these subjects that tend to talk theory, leaving it to you to determine how you'll apply that theory. This book in excellent, not only in presenting the theory, but even more so when it deals with interviewing, testing and taking a Use Case artifact through the various iterations to the Finished (polished) state.
   
   If you've never done Use Cases, start with this book.
   If you've used Use Cases, but not studied the theory, continue with this book.
   If you want to teach others, apply this book.
   
   It is great all around.

3 comments about Creating Adobe Acrobat Forms with CDROM.

1. This book reveals one of the best kept secrets of Acrobat 5.0 - easy to create forms handling and workflow. Actually the features aren't secret, but the Adobe documentation is so confusing that only the most technically inclined users made use of it. The author clearly explains how to create forms and employ them as business solutions.

   What I like is the way you're introduced to all of the features of Acrobat, including products that are only available through direct purchase from Adobe, that places forms development into the context of the much larger picture of Acrobat's features and capabilities. The book then proceeds to systematically step you through creating basic forms (dynamic and static), and all of the associated details, such as field types and properties, calculating data and workflow considerations.

   After you've mastered the basics the book shows how to use Javascript to create sophisticated forms and handling applications. In this section of the book the author does not assume any knowledge of Javascript on the part of the reader. The tutorial is clearly written and explains the basics of Javascript, but unless you have prior programming experience you may want to skip this section. On the other hand, if you understand the basics of programming or have used some of the user-oriented languages, such as SQL or Visual Basic, you should have no problem with this section of the book.

   The most valuable part of the book is in Parts III and IV, which cover distributing and working with forms. The chapters in these two parts of the book show you how to apply forms to business solutions. In addition, the CD ROM contains example forms and a valuable collection of Javascript routines that you can either use as is, or modify to suit specific requirements. There are also trial versions of various Acrobat plug-ins, and the entire book reproduced in Acrobat format (plus two ebooks titled "101 Acrobat 5.0 eTips and Techniques" and "101 Acrobat 5.0 Forms eTips and Techniques").




2. I wish I had known that this was not going to cover Acrobat 6. The current version of acrobat does forms completely different than version 5. This is a dinosaur now.



3. This book is horribly outdated! If you have Acrobat 5, - fine. Or maybe not so fine... use the money you would have spent on this book and upgrade to the current Adobe version: Acrobat 7 as of Sept 2006.
   ..and beware of Wiley Books that don't specifiy the application version - - Wiley is notorious for this -- remember, when purchasing a Wiley book -- think twice if the version of the application is not specified..

5 comments about Agile Modeling: Effective Practices for Extreme Programming and the Unified Process.

1. For those few places left that steep themselves in documentation and don't have a legally-required reason to do so (do they exist?), this book should help motivate why producing too much documentation and doing too much modeling up front can hurt rather than help. Even for a company that sees itself as lightweight, he's got some rough assessments you can do to see if you're overdoing things, which were relevant even where I work.

   The only bad thing is that it was a very theory and ideal oriented book. It didn't contain concrete examples of what Agile Modeling would look like on a real project, how it would feel, and how what models were produced would evolve. This made it a bit difficult to verify my interpretation of the book.




2. Good book with lots of behind the scenes process info about how to implement agile modeling techniques. If you are looking for step by step instructions to modeling or how to model, look elsewhere. It doesn't cover specific modeling, but techniques. Some of the techniques are common sense, but there were lots of suggestions of how to apply them in a difficult political environment. I did not completely agree with the often repeated
   statement that unless you apply all of the techniques you cannot truly claim agile modeling success, which I think is a somewhat arrogant statement. Agile modeling is a huge cultural change and implementing as much as possible, if not all, is still a great idea.



3. Agile modeling is about the latest approach to the modeling of Business Information Systems. This book focuses on the Agile method and also describes how to incorporate the strong points of UML. The book will be an aid to "survive" in the jungle of developing modern BI Systems. There are IT decision makers that are not aware of Agile, since Agile is a mind shift, be careful how you introduce the new ideas to these decision makers. The book is for the IT professional (all levels), who wants to be in the forefront of software development. If you are in the "nuts and bolts" of systems development, do yourself a favour and look also at "Agile Database Techniques", by the same author.



4. This is a mix of good, bad, and annoying
   
   Good: the author really does know a lot about modeling (except data modeling, see "Bad") and gives good explanations and examples of many aspects of modeling at many stages in the development process. If you can plough through his 350+ pages, you will have found many stimulating and practical concepts and some good advice on implementing them.
   
   A very good chapter is Chapter 29 - a discussion of how to implement Agile Modeling - or really, any agile practice - in a usually hostile world. Some battle scars showing here!
   
   I also like that he does not consider the UML the be-all and end-all of modeling tools. Like him, I've found good use for the trusty old DFD (Data Flow Diagram) of the 70's, where appropriate.
   
   And his overall message - that the agile approach can extend to your design and modeling task, not just code, and the implications for minimizing the documentation effort - is very strong.
   
   I find his reference to quick diagrams "on the back of a napkin" a bit overdone. Sure, the quick informal diagram is excellent, but paper napkins are not the best medium! Hand-drawn on a piece of paper, or a card, sure...if you are discussing models in a bar or restaurant with that degree of focus...get a life!
   
   Whiteboard and digital camera can certainly be used much more than they are. But the overall point is excellent: that when you are documenting (and he has some difficulty separating out "modeling" from "documenting" and acknowledges the problem) you are not creating the end-product, and there is a cost for that. "Travel light" - yes. As Einstein said "Everything should be as simple as possible, but no simpler."
   
   Bad: his data model example is terrible. What's with adding surrogate keys to every table? This is a pernicious practice that has become all too common from people who never learned relational theory and try to fit relational into the object model. A giveaway is that he calls his "identity" columns "persistent object identifiers." Yes, sometimes they are necessary or useful, but in general the natural key is way better. In his Customer table, there is a customer number - but it's not the primary key, a pesky OID is! He himself acknowledges that this may give performance problems, or at least not be optimal. It implies more indexing and triggers...oh well, enough already. Just don't let RDBMS gurus like Fabian Pascal or Joe Celko see that chapter.
   
   Slightly annoying: A few little niggles about English usage etc - by now you would think that any publisher's editor would know that "supersede" has no "c" in it, and that you can't be "reticent to" something - the word is "reluctant. Odd. On the other hand, thank goodness for someone who understands why it's "co-located" not the bizarre "collocated" that I see far too often.
   
   Really annoying: Basically, Einstein's phrase above could have replaced about half the book. It's incredibly repetitious, and also over-organized, over-conceptualized, over-categorized, generally over-inflated. We need a discipline of Agile Communication! An end to ListMania! A thoroughgoing refactoring of the contents is in order. His four Parts and thirty Chapters contain massive redundancy. The matching of agile modeling precepts, in finest detail, to the equally excruciating detail of the RUP, is really an unnecessary exercise. We don't have TIME for this!
   
   As someone else said, a short White Paper could have replaced the entire book. Hence the two stars, good though some of the material is.



5. Not much information other than what you can read on his website. I was looking for something much more prescriptive in terms of how to model in an agile way and how to communicate the model.