No comments about Pro PerformancePoint Server 2007: Building Business Intelligence Solutions (Pro).

5 comments about Pro EJB 3: Java Persistence API (Pro).

1. Anything that requires getting a bunch of jars on the server classpath was deemed unsuitable for automated deployments. I wonder how people manage automated deployments and configurations, especially in a multi-server clustered environment.



2. Pro EJB3 is a great book. Having been using it for over last 6 month on my recent project, I can definitely say that this book is invaluable.
   
   Have been worked on EJB 2.x for many years and on several projects with different application servers (Weblogic, JBoss, WebSphere), I understand the basics of EJB. So I want not only understand the basic how-to in EJB3 and JPA, but also want to understand the in depth explanations on transaction, persistence context and different behavior in the new system.
   
   The book explain all these topics very well. I had brought other book (hibernate in action with JPA pdf version), but found that book was too focused on hibernate (even I was a fan of the previous edition of hibernate in action book). This book is well focused on JPA,and I really likes JPA APIs.
   
   The book author is really nice and accessible. I have emailed Mike questions and he consistently replied promptly.
   
   This book worth the money !!!
   
   Chester



3. This is the best book out there that explains in detail how JPA works with some good examples. I found the book to be well structured and easy to read.
   
   I would recommend this book for anybody who is looking to work with JPA.



4. This book is a joy to read. Object relational mapping is explained in a very simple manner. What I like about this book is that it explains a certain concept and then immediately talk about the specific use-cases when that concept/design may not be the best choice. The authors then give excellent suggestions and alternatives.
   
   Very good reading material, simple examples used to explain complicated concepts. Writing style of the authors is also very engaging.
   
   A very good buy.



5. This books seems to achieve the goal it has in mind, that of providing the user with the information necessary to use the Java Persistence API. Unfortunately there are real problems in the execution of this book.
   
   A book like this should not only be full of examples, but it should be structured in such a way that it is easy for someone using the book to duplicate the examples on their own system. This book fails to do so.
   
   In chapter two we are promised a complete application using the new API by the end of the chapter. The source code is provided for the application discussed and it is a pretty good example of the API discussed up to that point. Unfortunately there isn't enough information for the reader to build and run the application on their own computer. There is no reason for this kind of omission this early in the book.
   
   The problems with the book continue as one moves on. I recognize that the target audience for this book includes only professional programmers of reasonable skill. I consider myself a very good Java programmer. That doesn't mean that I want to waste my time filling in gaps that should have been covered by a book I already spent my money on. It isn't any excuse for the omissions in this book.

5 comments about C# Cookbook, 2nd Edition (Cookbooks (O'Reilly)).

1. If you are just coming into C# or have been doing it for a while - it doesn't matter - BUY THIS BOOK!!! Oreilly as we all know, makes very good tech/programming books and this one is one of the best I've had so far. This will be a book that will spend much less time on my shelf and much more time next to me on my desk.



2. I came across a project that had to do with XML, and I came to love this book. It has a lot of suggestions that helped me jump start my project.
   
   I wouldn't recommend this book to learn C#- (pick up John Sharp C# step by step for that.)



3. I'm an intermediate coder, familiar with programming and I have about 1.5 years programming C#. I've already used this book(C# Cookbook 2nd edition) to write C# code navigating in and around directories and files. The examples in the book regarding "Directory Info" and "File Info" were so clear and concise, I was able to complete my programming task with almost no lost time to the learning process. What I like most was that there was not one example, but many examples for the most used functionalities. This book has already paid for itself when I consider the time it saved me the first time I needed it!



4. This is a good intro book that eliminates the need for some of the first books I bought on C#. When compared to other "cookbooks", however, this book is incredibly weak (see: XSLT Cookbook, SQL Cookbook). If you have used C# for more than 6 months, you will know how to iterate over an array, to use String.IsNullOrEmpty, get the index of a value within a string, and use a generic arraylist. These are just some of the junior "recipes" you'll see in this book. The "recipes" just exercise the fundamentals (i.e. how to boil water) rather than how the fundamentals work together to solve complex problems in elegant ways. The easier the concept, the more information. There isn't really any analysis or best-practice justification present. I'd like to see some performance analysis of generics or at least some depth on partial methods. Nothing to see here for mid-level developers. Not written or organized poorly, just simple. If it were titled "Intro to C# by example", I'd give it a higher score.



5. [Reviewed by XPSD member Steve Grubbs]
   
   Summary
   
   I wanted to check out a C# cookbook after developing in C# for almost a year. I figured I should get a basic understanding of the language and the .NET framework by using it for awhile before I buy such a book. That said, I wish I could go back in time and tell myself to get the C# Cookbook the day I started developing in C#.
   
   Overall Review
   
   I see two main criteria for reviewing a programming language cookbook.
   
   1. The quality of each "recipe"
   2. The recipes chosen for the book
   
   The C# Cookbook handles each recipe very well, which we should definitely demand of a cookbook. It has a very simple 4-section format, Problem-Solution-Discussion-See Also. The problem is briefly stated first. The solution is almost entirely code samples, with minimal commentary. The discussion is usually short and sweet, with a few exceptions. The "see also" points to reference topics in the MSDN help, which is of questionable usefulness, since you can search the topics yourself; but, is short enough to skim over easily.
   
   The recipes chosen for the C# Cookbook range from very useful to trivial. One of the trivial examples would be something like, converting degrees to radians. The only language specific feature here is Math.PI, which I don't think is worth the page it's printed on. What I found surprisingly useful were some code samples that I spent time coming up with on my own before reading this book, like a custom trace class that outputs in XML. Fortunately, most of the examples were in the useful category.
   
   A few glaring topic omissions are remoting, ADO, and advanced object serialization.
   
   Per-Chapter Review
   
   * Numbers - somewhat trivial
   * Strings and Characters - good introduction to the C# string
   * Classes and Structures - good stuff on interfaces, casting, converting, COM interop
   * Enumerations - simple, but short and useful
   * Exception Handling - an underrated topic that I'm happy to see covered
   * Diagnostics - a surprisingly useful set of tools to help with debugging
   * Delegates and Events - very good intro for the new C# programmer
   * Regular Expressions - very good intro for the new C# programmer
   * Collections - a little simple, could have more useful samples
   * Data Structures and Algorithms - simple, but good if more advanced types are required
   * Filesystem I/O - very good examples of file I/O in C#
   * Reflection - a necessary intro to reflection, but a bit simple
   * Networking - biggest complaint: Why is there no remoting?
   * Security - a good survey of various security issues in C#
   * Threading - a good intro to threads and basic synchronization in C#
   * Unsafe Code - I tore out and burned this section
   * XML - good intro to reading/writing XML in C#

5 comments about Death March (2nd Edition) (Yourdon Press Series).

1. It is mostly a synopsis of ideas from several better books (e.g. Peopleware). I'd suggest reading them instead. Of course, the bibliography from this book is very useful. It is a decent guide to what resources are available for dealing with Death March projects.



2. The very first page of this book defines what the author means by a "Death March"; any project whose project parameters exceeds the norm by more than fifty percent. In essence, this book is meant to help you in those unpleasant circumstances when you've got half the amount of time, half the amount of staff, or half the amount of money that you would rationally need to finish a project.
   
   Unsurprisingly, Yourdon advises anyone reading the book to avoid these projects as much as possible, even counseling that it is sometimes better to resign early rather than sacrifice your health and professional reputation trying to do the impossible. But if you feel compelled to embark on a Death March, this book is an invaluable guide to the pain that lays ahead.
   
   One of the reasons the book is so valuable is that it articulates many of the things we would like to think are common sense. These are items that, when you read them for the first time, make you think "of course that's true". But if you ask yourself whether or not you would have instinctively and firmly followed the advice, the answer is often no. I found the chapters on politics and negotiation (2 & 3 respectively) to be particularly helpful in this way. OF COURSE I should negotiate the scope and the specific team members needed at the start of a death march project, but reading Yourdon's words I came to the realization that my first reaction is instinctively "we'll make it happen" rather than the sometimes appropriate "we've only got a chance if I can have..." It's important to get gut checks like this before you find yourself in the middle of a tense situation so that you can anticipate your own feelings and counter them when necessary.
   
   Another very interesting concept is the Triage system described in chapter 5. This is based on the idea that, no matter what else happens in a death march, the team will not be able to deliver 100% of the features that are initially asked for. I actually see a very strong argument here for using some of the newer Agile project management methods, where the items that deliver the most value are implemented first and evaluated by the end users. Combining such a system with a triage effort on behalf of the project manager and management could, on occasion, allow a death march project to produce nearly 100% of the value required without completing 100% of the features.
   
   There is much else in here that is useful, especially on the subjects of why people participate in these sorts of projects and what they expect to get out of them. If it's impossible for you to avoid a Death March, make sure you've read this book before you plunge in.



3. I was required to read this book for a Masters-level class in project maanagement. Overall, it provides good insight into the challenges facing IT projects and why they often fail. At times Yourdon shows a slight engineering know-it-all slant in his writing, but in the end Yourdon accurately portrays the fact that IT projects alone do not provide panacea for organizational, social, and business problems.



4. Mediocre. Uninspired writing, much like his other books. I keep hoping for better but he never delivers. About 200 pages, padded by notes for each chapter that repeat things in the main text.
   
   Occasional interesting points, but not enough to make it a keeper. Borrow it if you can for a quick read.



5. Definitely a must-read for anyone involved with project or technical management.
   
   Yourdon exposes a series of reasons that move organizations into death marches, and also the reason why many employees still embark on those projects.
   
   He also tries to propose some solutions, although many times you will be facing a no-win scenario.
   
   An short book and an eye opener for those who don't have time to read (beacause they are already involved in a death march)
   
   [...]

5 comments about Documenting Software Architectures: Views and Beyond (SEI Series in Software Engineering).

1. After reading my colleague's comments I rushed out and purchased this book. I, too, am trained and certified in Information Mapping© and was impressed at how closely the approach in this book is aligned to that method. However, what I like most is the fact that this book can be used as guidance for a wider scope than just documenting software architectures because it shows how to organize your documentation requirements, develop clear documentation and manage the entire process from start to finish.

   I also like the clearly articulated and illustrated advice about how to augment text with graphics, and how to select the views and associated graphics to document requirements, specifications and the finished architecture. An example of how this book goes beyond documenting just architectures is a project in which I was engaged two years ago. One of the major deliverables was a set of operations guides. While this is related to architecture with respect to how its used after it's in production, there were no books that fully described how to go about it in a coherent way. Using the advice and techniques in this book I could have greatly improved upon what I did produce. While I cannot change the past, you can be sure that I'll use this book to its fullest the next time I need to write ops guides, especially when it comes to showing component and connector views, and elements and relations.

   If you do technical writing either professionally or as a part of your job get this book and keep it nearby. If you read and use the material you're ability to communicate will surely improve, and you'll be able to tailor your documentation to each segment of your audience (business and technical), as well as to clearly communicate information. You'll also learn much about managing the documentation process itself.




2. This is not a bad introductory documentation book, but quite skimpy in the amount of information and examples it contains.
   Not sure it is worth buying at that price. I bought it after reading the previous reviews - I think they overrated it!



3. Software architecture really is unlike any other aspect of its design. The architecture has deeper meaning and larger scale than any other aspect, and can't be discussed in the same ways.

   This book opens that discussion. Among the "architecture" books I've read lately, this is the only one to offer concrete advice on describing, presenting, and analyzing archtiectural features of a system. It identifies a number of documentation types and variations. It also identifies a number of different readers - developers, future architects, users, etc. - and addresses their different documentation needs.

   The authors use a little UML, but not a lot. For one thing, standard UML works at too low a level for architectural discussion. Classes, and even hierarchies of class inheritance are such fine-grained entities that architecture gernerally won't address them. Instead, the authors offer a number of diagramming styles of their own. For once, I agree with the need for non-standard notation.

   Even so, I think they under-utilize the existing standards in favor of their own terminology and notation. They could have used a UML profile for lots of the discussion. It would have had to be a new profile, however, not just a force-fit of the real-time profile. They also under-used the existing architecture standards (IEEE/ANSI, DoD, NASA, and more) in favor of their own discussion. Maybe their approach can be used in any of those frameworks, but that should have been more explicit.

   I see only one major flaw in this book, the assumption that a software system's architecture describes the program delivered to a customer. That's way too narrow. A large system includes things like test harnesses, debug instrumentation, application-specific QA tools, and user documentation of many kinds. Those can be major undertakings of their own. They are intimately tied to the delivered software, and may constrain the actual product.

   On the postivie side, this book offer an extensive real-world case study. That probably doubles the book's value, by putting a concrete face on the otherwise abstract discussion.

   There are two ways to use this book: you can agree with it, or think about it and disagree with it. If you really think about it, though, you get it's full value whether you agree or not.

   In other words, you can't lose by reading this book.




4. Clements shows how to use various notations to document your software design. Of these, perhaps UML is now the most common. The advice in the text can be used to first design your code, before programming. Certainly, you should somehow have a design laid out first. You do, don't you?
   
   The book offers structural advice about how to do this. From the low level "mechanical" details of the UML notation, to more general conceptual issues. Various possible architectures are outlined. Client-server, n-tier and peer-to-peer. Enough to get you started in implementing these ideas.



5. Simply put, I think this book represents the best thinking about documenting software architectures. You can find other books that include different aspects covered in this book (documenting views, 4+1, ANSI/IEEE-1471-2000, etc). However, you will have a hard time finding a book that pulls it all together, provides the rationale and includes the "beyond" part which discusses other approaches to documenting software architectures and how they relate to the "Views and Beyond" (V&B) approach. For instance, the book discusses how to use V&B to comply with ANSI/IEEE-1471-2000.

3 comments about Introduction to the Personal Software Process(sm) (SEI Series in Software Engineering).

1. I originally bought this book to improve my own software engineering habits. While this book has its merits, I am afraid that it is geared more toward the first and second year college student than the professional engineer. It specifically addresses student issues, and most of the lessons are not applicable to professional work environments. However, if you happen to be a college student in CE, then I would suggest this book as a primer. Humphrey is very detailed in his explanation and extremely epxerienced in this field.



2. This is a great book if you have never, like me, had any type of process education or formal time management training. I wish this book was available 15 years ago when I took my first CS class in college.

   For the working programmer, especially in today's visual integrated environment, applying alot of the material is hard. The Lines of Code (LOC) measurement used is not considered the best judge of program complexity, plus in a visual environment where one can spend days laying out forms or reports that generate no lines of code can skew numbers. I understand its use: It is easy to explain and calculate for beginners, but is lacking for working programmers.

   There is also an emphasis on distinct phases of program development, particularly the compile and test phase. For those of us who work in a visual environment (be it C, Pascal, or Basic) the phases blur together and tracking time spent on compile is negligable. Also not mentioned is should intentional syntax errors (such as going to copy a variable name) that automatic syntax checking catches be tracked?

   The extreme academic bend of the book also begins to annoy after awhile. The use of "small programs" to work with on the job is rare. Tracking number of lines changed can be tough in large programs, even with source code controls in place. The base code review checklist is extremely simple (intentionally) and aimed at C or Ada programmers, leaving other languages hanging.

   One last annoyance: Many of the forms talked about are not available to print or use in a spreadsheet. The one form most working programmers would use, the time log, is the most glaring example.

   If you meet either of the requirements in the first paragraph, read the book. You will find something of use. Just about anyone in the field would benefit from chapters 3 and 7 (in particular) since we all tend to have problems estimating how much time things will take.

   Lastly, most of the data used to show how things improved after using the Personal Software Process was from 2 groups, one "real world" company and a group of students. Both groups only had around 15 people. Even combining both groups a sample of 30 programmers is not overwelming evidence. A larger sample is needed.

   Although only 3 years old, to me the book needs to be updated. Larger samples for the improvement examples, handling non-code artificts such as forms and program documentation, and making sure that all of the forms are available on standard size paper (8.5x11 or A4) would be a good starting place.




3. The Personal Software Process (PSP), which is a registered service mark of Carnegie Mellon University, is all about measuring and recording. Nearly everything is measured, from lines of code produced per unit time to the time spent playing/watching sports. Charts are everywhere in the book; some plot the progress of software development projects and others the weekly schedule of a college student. Therefore, there are charts that are headed "Student Y's Fixed Weekly Commitments."
   The initial premise of the book is that of a college student who must plan their time in order to complete all that needs to be done. Of course, the point is to emphasize that planning major projects, such as your life, requires that you set reasonable goals that are compatible with everything else that you want to do. Once the goals are set, the next step is to order your time so that all activities are allotted an appropriate time slot.
   The second segment deals with tracking a software development process from start to end. It is all about time, how much you expect to spend on each section and how much was actually spent. The goal is to track now so that your future projections are more accurate. With so many charts and entries, there is nothing that can be measured that does not appear somewhere in a chart.
   While I am a proponent of measuring and recording the significant characteristics of any project, one must take care to avoid an over reliance on the act of measuring. Even though software development is a team game, it is still very much an individual effort. There is a great deal of room for the occasional "brilliant stroke", where someone has a flash of insight into a problem that solves it in a new, unique and more efficient manner. The best programmers are still in many ways artists and regimentation can stifle their creative sides.
   The PSP is also different from the agile processes, which reduce the software planning cycle to a few weeks rather than a longer term. Very little is also written down in agile processes, and planning to the minute is considered counterproductive. However, even if you are a firm believer in the agile approach, reading this book will be of value. When you write down very little, you must make sure that what is written down is important, so by studying the PSP, you have a better chance of recording what is critical.
   Humphrey is on one end of the software development spectrum, in that he sets down a process with extensive planning. Agile processes are on the other end, where there is a minimum of planning. Most development groups will find their best location somewhere in the middle. Since the best way to find your location is to study the extremes, all software developers will find value in this book.

1 comments about An Object-Oriented Approach to Programming Logic and Design, Second Edition.

1. This author is imprecise in her use of terminology. She switches between similar terms for the same thing without signaling. She uses the same term for different things without signaling. She even uses incorrect terms.
   
   The author tends to use a concept in a discussion and then, later, she introduces the concept formally to the reader. Sometimes she never introduces the concept, and youstruggle with the text before you realize that a new concept is involved and you must set about untangling the spaghetti on your own.
   
   On a positive note, the author makes good use of analogies to illustrate abstract programming concepts. Overall, however, this text is a monument to mediocrity.

5 comments about Object-Oriented ActionScript 3.0.

1. I expected to see more coding techniques aside from just learning the newly structured AS 3.0. Much of the way Actionscript is coded is still done in the same way nestled in newly structured class files. And here is the new structure: package { import your library(s) class { some code } } all wrapped up in its own .as file. The SWF remains completely empty except for your class path hidden in the publish settings. And I'm still discovering this isn't the only way to organize your class files and paths. Just when I start to get comfortable with AS 2.0 and they go off and do something like this, and totally redeem themselves.
   
   Some new concepts I noticed involve Manager Classes and Interfaces. I'll be sure to master those when I start my Ph.D.
   
   The book had plenty of code to comb through which was great , moreover, it discussed a good number of practical examples. I liked that it focused on important topics and not just the title OOP AS 3.0. The book covers hot topics like Flex, XML frameworks, and web services. We all know when you mix AJAX and SOAP you don't get a good cleaning, instead you equip yourself with the coolest, latest, and greatest web thingy.
   
   I felt like some of these AS files were rather bloated compared to what I'm used to seeing in AS 2.0. If you don't have your foundation of class file after class file established, then you won't be seeing any fast implementation any time soon. You sacrifice time for decoupled, yet less simple, reusable, and robust code that makes more efficient use of processing power - cuz, users pay attention to that kind of stuff. For instance, I thought I would incorporate the source files included with the book in developing a solution for displaying video on the website here at work. After an hour or so looking at the files and testing the result in the browser, there was no evidence of button control functionality. So, I went back to my AS 2.0 help and copied code for a video object, found the corresponding methods I needed under the netstream class, and a few moments later I had a streaming video player with complete functionality. Note to self, for small fast implementation projects refer back to AS 2.0 and for large scale multi-coder headaches apply AS 3.0.
   
   Getting good exposure to AS 3.0 in prime examples really helped me transition to using it where I can find place. And what's great is that you get to see all of the code, not just a snippet shrouded by the author for his own purposes. Take a long peek at the gravity class. Admit it, you know it's what still makes Flash cool.
   
   This book definitely isn't for someone wanting to learn "programming". You should have a good foundation in basic programming concepts - method, property, constructor, function, modifier, object, etc. If you've done any JAVA programming all you need is the API documentation and you're off and running in AS 3.0. The way books are written these days you can't find a "has everything" book, so you're definitely left wanting a little more. The book totals some 597 pages but if you take out the code and empty pages you're left with maybe 200 pages of explanation. As the number of books out there continues to climb, you may question the authority and quality of each volume.
   
   This book is great for those who want to go to the next level of web programming - which is web application programming. You'll learn to program apps like Buzzword at Buzzword.com.



2. this book will help you to code more properly in actionscript,
   to get the maximum of this book you must know actionscript 3 and basic object-oriented programming.
   it is not an easy book, but if you will grasp all the concepts and implement them then you will be the perfect as3 programmer



3. Title: Object-Oriented Actionscript 3.0
   Authors: Peter Elst, Sas Jacobs, and Todd Yard
   Publisher: Friends of ED (July 23rd, 2007)
   ISBN: 1590598458
   [...]
   I figured this book would be next logical step in learning actionscript. I will state this book is not for those who are just beginning actionscript as the depth will make your head spin. If you are just beginning AS I suggest you pick up the Foundation Actionscript for Flash 8 by Friend of Ed or head over LearnFlash to check out their Introduction to Actionscript 3.0 videos. The thing that I looked forward to most about this book is the OOP discussions. As a developer, I am always looking for a better explanation of a very important aspect of development.
   The book is divided into five sections. The first section deals with OOP and Actionscript. It throws in a basic programming concepts and an introduction to Actionscript. Part two deals Flash OOP guidelines. It contains chapters dealing with best practices, planning, and project workflow. They decided to stick a Flex chapter in this section which seemed odd to me. Part three deals with the core OOP concepts such as encapsulation, classes, inheritance, Polymorphism, interfaces, and a section on design patterns. Part four deals with building and extending dynamic frameworks. They talk about manager classes, UI widgets, and OOP animation/effects. The final part deals with data integration. The authors provide details on exchanging data between components, communication with the browser, and various forms of server communication (XML and web Services. The book concludes with an example of a slideshow engine.
   The layout is very reminiscent of other books in this series. I wish they would have found a better way to make the code examples stand out from the other text a little better. It would have broken up the monotony. I think the book could have used more color.
   What I liked about the book
   I thought the authors did a great job of covering OOP concepts. Part three really provides a terrific explanation of the foundation and core fundamentals. I recommend reading part three if you need a refresher on the topic. If you don't get lost in the rhetoric then the case studies are excellent. The Slideshow engine in the final part really brings together the concepts discussed throughout the whole book. I enjoyed the coverage of Flex 2 and its capabilities.
   What I didn't like about the book
   I did not care for the way the code examples were presented at all. In most cases, it made the book hard to follow and many times I would have to reread the paragraph before the code just to make sense of what they were trying to relay to the reader. I think some of the chapters were very confusing and fuzzy on the topic at hand. I am sure the manager classes discussed in part four are integral part of AS 3.0, but I felt like I was running up hill in quicksand. There are several topics in the book that would have been clearer if they had their own chapter. This being said it would have helped me master the codes examples a bit better if the explanation was a bit clearer. The examples would be easier to follow if they built upon each other as well. I enjoyed the Flex coverage, but it would have been great to have more material relating to Flash.
   Conclusion
   I don't think this is a horrible book by any means and if were organized clearly it would be a must read. I am hoping they come out with a foundation book on AS 3.0 which will benefit beginners and intermediates as well. If you are well schooled in AS than I imagine you will find this book helpful if you are not then you will be left scratching your head. Personally, I think it time back track and pick up on some things that I must have missed.
   
   {[Jeff Smith]}



4. The intended audience is for readers who "...have some previous experience developing in Actionscript...", and that "Some familiarity with the Flash or Flex authoring environments...".
   SO - why do we get a whole chapter dedicated to a section on using Flex, but assumes that the reader already knows the Flash IDE?
   Furthermore, why is there a whole chapter on coding standards and practices?
   These are just two of the wastes of paper, therefore MY MONEY before getting down to the OOP concepts.
   If you do buy, watch out for the errata, and the publishers (Friends of Ed) have errors on their reporting page, which is, possibly, the reason there is no corrections sheet for this book
   
   Once we get to the OOP stage, there is a major dearth of answers to the question WHY? I'm a newcomer to true OOP, so this book is not a good way to delve into OOP.



5. As someone new to AS 3.0, coming from a designer background and previously using AS 2, I was looking for an explanation of ActionScript 3.0 and an introduction to OOP. I was hoping for simple to understand explanations using "big picture" generalities that then moved down into specifics and offered code to illustrate each point. This book is partially that, but unfortunately it is technically over my head at this point in my development. I will definitely revisit this book after I get more coding experience. That being said, it does an excellent job explaining differences between AS 1 through AS 3, as well as many other concepts. In general, the book's "readability" would be improved if some chapters were in a different order and short, simple projects were added along the way to better illustrate each new concept. I'm thinking specifically of the chapters on Planning, Patterns and Workflow. It isn't until the middle of the book that this begins to happen. I think the book bogs down in detail early on, for example, the chapter on Flex is written with the assumption readers are not only familiar with Flex, but prefer using it over coding directly in the Flash application. Simply stating Flex's advantages immediately and briefly would improve the rest of the chapter. Also, highlighting new blocks of code as they appear would make them stand out immediately. I found myself searching blocks of code to understand the point being made.

5 comments about Cost-Based Oracle Fundamentals (Expert's Voice in Oracle).

1. This book gets a prized spot on my technical shelf. It is a challenging read, and has taken the most time of any book I have to get through, but it is quite good. The optimizer is such a core part of what makes Oracle worth the investment, that any DBA who does not understand it is doing a disservice to the company investing such capital into the product.
   
   Lewis' use of proof through example is second to none, and leaves me feeling confident about the knowledge I've gained. His insights are not only theoretical, but quite applicable. I learned much about manipulating and using the DBMS_STATS package, about data model design and why data knowledge is so critical to the DBA.
   
   My nervousness about hints and about upgrades was reinforced with concrete examples that have improved my test plans, upgrade methodologies and overall made me a more competent DBA. I've directly used this knowledge to support my clients in better ways than I would have before it, and that is well worth the price of admission and the time to get through such an in-depth work.
   
   Thanks Jonathan!



2. Each quarter my team of DBA's has one book that we read and discuss in team meetings. This quarter, Cost-Based Oracle Fundamentals is it. This book is a wholly remarkable book for the moderate to advanced DBA. It is a deep dive into the Oracle optimizer, providing some wonderful insights into not only how it works, but why. It is not a book for the faint of hart, or those waiting breathlessly for retirement. It is a book for those who want to understand the CBO in more depth.
   
   Within the book, Jonathan provides insights into how the CBO *should* work. He follows up often by demonstrating the maturing (or devolving as the case may be) of the CBO from version to version. Beyond his own experimentation and results, he leads the reader into the process that he has followed to come to understand the internals of the CBO, providing a road map allowing the reader to continue to explore the optimizer in future releases.
   
   However, I must take Jonathan to task, for he is a nasty tease. This book was released about two years ago. In it, he leads us on with promises of forthcoming volumes 2 and 3, dangling the carrot out there for us to follow. Sadly, these volumes are yet to be seen. Jonathan! Quit running to and fro filling our heads with knowledge at various conferences and write those books man!
   
   A caution for the new DBA or the cursory SQL developer, you may find this book overwhelming at first glance. For the new or even intermediate DBA, it might be hard to derive practical application of what Jonathan is teaching at first glance. Take your time with the material and the insight that you will gain will be invaluable.
   
   Overall, if you want a book with meat, then this is the book for you. It will expand your mind and the way you look at the Oracle CBO.



3. It doesn't mean you won't love the book. I found it to be far too narrow and, even as an Oracle OCP, boringly written. That may say more about me than it does about Jonathin Lewis, who I know is brilliant and has written brilliant stuff before. I just didn't get as much out of it as I thought I would.



4. Jonathan Lewis has perfomed an invaluable service to the Oracle community. He doesn't just offer opinions of how the CBO makes decisions from his vast experience. He also offers the scripts he used to verify behavior of the Oracle CBO. This equips the user to replicate Jonathan's work with newer versions of oracle and adapt the scripts to your circumstances.
   
   Dennis Williams



5. This book contains a wealth of information about how to evaluate and test the Oracle Cost Based Optimizer. Jonathan presents the material in a very easy to follow style. All the examples and scripts that he provides work as written. I would highly recommend this book.

1 comments about A Comprehensive Introduction to Object-Oriented Programming with Java.

1. This book is similar to another one on the same subject - Introduction To Computer Science Using Java, Student Edition. However, the current book seems to cover the matter at a slightly more advanced level.
   
   It does help that, for instance, when dealing with widgets for programs using graphics, that the widgets lend themselves to an inherently object oriented mindset. Thus the pedagogy of teaching graphical programming in java is self reinforcing.