5 comments about Flash 8 Cookbook (Cookbooks (O'Reilly)).

1. Hardly any information that would constitute as worthwhile if you have a decent grasp of Flash. There is entirely too much elementary information here. One recipe is a small excerpt on how to create an invisible button by only putting content in the hit state of the button. Also, although the cover reads "Using the Flash IDE to build Flash animations and applications", it includes entirely too much information on Swift3D in a Chapter discussing 3D in Flash. The chapter should probably have been renamed "Creating 3D in For Flash using Swift 3D" instead of the misleading name "Simulating 3D in Flash".



2. As an intermediate Actionscripter, I find this book incredibly useful on a daily basis. It's well-organized and well-written, with several juicy tips and tricks.



3. This is a book for beginners, not even intemmediate level readers. If you are familiar with any other design software like Illustrator, Photoshop, CorelDraw, etc. you will find that much of this book is useless since you already know it! This is a perfect exapmple, quoting the book:
   
   "1.1 Drawing Straight lines
   
   Problem: you want to create a straight line segment or a shape made out of multiple straight line segments.
   
   Solution
   Use the line tool[...], the pen tool[...] or the pencil tool."
   
   This is by no means a "cookbook" and I'm very disappointed with O'Reilly being the publisher, since most of the time their books are great.
   
   The book probably focuses on REAL ACTIONSCRIPTING up to 15% its entire content!
   
   Only consider it if you never worked with a design application in your whole life and don't have the time or patience to read more than 2-page long chapters.



4. Flash 8 Cookbook
   Joey Lott ISBN: 0-596102402
   
   Cooking with Flash 8??
   
   Reading the Flash 8 Cookbook is a painful experience considering you pay $44.95 for it. If you need answers to real-world problems don't look here. This book is a semi-helpful reference guide for those designers who are just beginning to branch out into Action Script. They try to make everything in the book very easy for you to the point that some of the chapters talk down to the reader.
   
   The meatiest information is concentrated from page 200-340 of an almost 500 page book. Some of the information in this section is about fading movie clips in and out, the key word "this", working with Java Script in Flash, and adding event listeners.
   
   This book features one of the best explanations I have seen on how to create a listener object and add an event listener on page 346. They break all the code down there with samples.
   
   A bonus to reading this book is that you can download a number of great low file size components written by Joey Lott . Some of the unique components are the form controller, slide show, and window controller.
   
   This book even introduces you to 3d Max and how to use it in conjunction with Flash. There is info on video and mobile but, surprisingly no chapter on Office Yoga for the Flash Action Scripter. They lumped together a number of topics that could have individually comprised a number of 500 -1000 page books.
   
   I think too many cooks spoiled the Action Script in this case. I consider this to be an easy fast read. Great to take to the gym or the beach. If you had to buy just one book on Flash 8, this wouldn't be the one you would choose.



5. 
   I am not keen on any book that has Cookbook in the title. This book however is more of a Hanes manual for your old Volvo 240. You will have lots of shop spills (coffee not oil) and dog eared pages on this when you finally move on to a future version of flash. Even then this will become a great tool.
   
   The book has four main solution sections: creating content, building interactive interafaces, using projects (I never get around to actually doing that!) and adding multimedia and data.
   
   O'Reilly put a lot into this book, with a load of solutions, with the if, how, why and here you go.
   
   Best if your up to speed and know your way around Flash well. For me, its a matter of understanding and implementing solutions as I encounter them. "Damn, how do I best deal with that problem? - Dunno? Read the book".
   
   Short and too the point, you will need this if your a professional - either from the design side or the programming side of Flash. Not much use to students, though educators should read it through and get up to speed to increase the amount of knowledgeable students coming out of courses (enough of the bouncing balls already).

1 comments about MCSE 70-293 Exam Cram: Planning and Maintaining a Windows Server 2003 Network Infrastructure (2nd Edition) (Exam Cram).

1. I wish there would have been a review for this book before I bought it, but there wasn't. I bought this book to help with studying for the 70-293 exam. I understand that the book is an exam cram....meaning that it is a more abridged version of the exam topics, but this book leaves a lot out. And further more, the exam cram for the 70-291 exam was great.
   
   I am not too sure where to even start. Most of the exam topics in this book are given from a 500 foot overview. Network load balancing and clustering cover about 3 pages in this book...and that is a big topic on the exam.
   
   And the book doesn't read very well either. It reads more like a bulleted list than a book with paragraphs. Each paragraph is seemingly unrelated to the paragraph before it.
   
   Also, the practice exams at the end of the book are terrible. Each practice exam is comprised of 60 questions, which is good as when I am studying for an exam, the more questions you encounter on the material, the better prepared you are. But not with these questions. Some of them where well written, but others were flat out terrible. One question was trying to get at network troubleshooting. The general gist of the question was "Computer A on subnet A cannot talk to computer B on subnet B". The question then goes on for a page and a half as to elaborate on all the troubleshooting that the admin took. The question is then something like "What would be the best tool to use to figure out where the problem is? and the answer is tracert.exe. Ok, do we really need 1.5 pages of troubleshooting that you did to ask a question about tracert?
   
   Another bone of contention that I had with the practice exams were with the questions again. This time, it seemed like there were 10 questions, all back to back (ie... question 11, question 12, etc) that were all the exact same thing. They were the same word for word, and then one piece was changed at the end to make them "different". They were all DNS questions....I understand that you need to come up with 120 questions, but if you are going to make all the questions the same, and least put them in different spots in the practice exam so we aren't reading the same thing over and over. It makes the exam very boring.
   
   But the final straw for me was practice exam #2. I gave up in the middle of it. There was a question on collision and broadcast domains. Throughout the question, the states that "hubs are used to connect the machines". Then it asks what you would use to form the domains. So you pick your answers, and then check it with the answer guide in the back, and find out that you got it wrong. And the explanation says that switches....yada yada.....So in the question he talks about hubs, but then in the answer he talks about switches. They are not the same thing.
   
   Also, many questions were just flat out wrong. You answer them correctly, and then check the answer to find out the book is wrong. Too many times this happened. I finally put the book down and vowed to never pick it up again. Simply because it is terrible and you can't trust the information in it to be correct. Possibly no technical editor was employed?!?
   
   A much better choice is the 70-293 book by Syngress. It is much more complete, and each topic is given anywhere from 50-80 pages.
   
   Do yourself a favor, and buy a different book.

2 comments about Documentum Content Management Foundations: EMC Proven Professional Certification Exam E20-120 Study Guide.

1. This book is a great introduction and overview of the Documentum platform. I wish I had something like this available when I started working with Documentum years ago. It not only introduces Documentum concepts to beginners, but it also serves as an excellent study guide for those wanting to become Documentum certified. It can also be an excellent reference book for even experienced Documentum users and administrators.
   It is easy to read, with helpful self test questions at the end of every chapter.



2. Passed E20-120 with great score. As intermediate-level Documentum
   professional I found the E20-120 exam very challenging and your book was
   enormously helpful during my prep time. All in all, I have found your set of questions very brain teasing, rich and well thought.
   
   Being under pressure to deliver and meet company's deadline it was essential to effectively bridge conflicting demands (work, family) and outperform when it is needed the most. Your book evidently boosted my performance. Furthermore, your book revealed many bottlenecks in my knowledge and significantly helped me to eliminate them, one by one, in time effective way. What I fancied was your clear, concise, focused writing style and the content of the book structured in manageable and digestible chunks. Of course, it is an extra effort to study in the evening but it pays off and now I am motivated to go
   for E20-405.
   Pawan, keep up the good work!

5 comments about Software Requirements and Specifications: A Lexicon of Practice, Principles and Prejudices (ACM Press).

1. How many technologies have you survival from? How many do you think you still gonna live? The best tool to survival technology change is *discernment*. Jackson's book the is best source of discernment I know. His point of view about so many technologies and software engineering themes are enlightening. The book organization is also a plus: any subject has links to other corelated themes. I've been referencing this book for 3 years and it seems not to get old.



2. Folks who like this book (like me!) will want to know that Jackson has published a follow-on book in which he expands on the central themes of this book. The follow-on book is called "Problem Frames", and of course it is available on Amazon.



3. In Software Engineering, a book that is a good read is a rare find.

   Most books bore you to tears, so you are asleep before you learn anything.

   Jackson's book is well written, interesting, and EXTREMELY informative. I strongly suggest ALL Software Developer's read this book.




4. I bought this book based on the rave reviews listed here. I was looking for insights into the requirements specifications process based on case studies, experience, etc. The topics discussed are very abstract, and the organization of the book (in alphabetical order of topics) contributed to this abstraction. One of the topics I found extremely interesting throughout the book was the use of mathematical notation to accurately specify relationships and concepts. In my own software engineering consulting practice with Fortune 500 firms, the use of mathematical notation in requirements specifications, such as is used for mathematical and logical proofs, is rarely used, primarily because most users, stakeholders, and developers cannot read or understand mathematical notation with respect to logic! Nevertheless, the book's treatment of mathematical notation in software specifications is refreshing and a keen reminder that the purpose of requirements specifications is precision and to eliminate misinterpretations. If you are looking for a textbook that provides insights into the practice and successful techniques of requirements engineering through case studies and anecdotes, I recommend reading other texts that are aligned with methodologies and techniques such as UML, CRC, etc.



5. This book needs structure. Themas are alphabetically sorted, but are not organized according their semantical contents.
   
   The following sentence from "Jules Henri Poincare" may be the best description for this book:
   
   Science is built up of facts as a house is built of stones, BUT an accumulation of facts is no more a science than a heap of stones is a house.
   
   This book gives you all ingredients, but does not tell you how to be a good cook. It does not give you the aim.
   
   Problems are isolated, but not related. They are just sorted in alpabetical order without context, like the heap of stones...

2 comments about Enterprise SOA: Designing IT for Business Innovation.

1. Being a student of business and information management, I had heard about SOA before, both from a technical perspective (XML, Web services) and from a business standpoint (shiny visions of flexible processes). This book is like the missing link between the two areas! It does not only tell you that SOA will change organizations but it also shows *how* exactly this is going to happen. The authors describe all relevenat aspects, starting from organizational change down to the SAP tools that can be used to model processes and to create your own service-oriented applications.
   What surprised me most was that ESA - SAP's flavour of SOA - is business-ready today! This is illustrated with numerous real-world examples from a wide range of corporations. The case studies give a good idea of useful ESA applications and show how the transition to a service-oriented infrastructure could take place.
   "Enterprise SOA" is suited for everybody interested in information management, even without any previous knowledge in the SOA field. After reading through the book, you'll finally know how SOA is changing the business environment and how SAP is bringing the concepts to life based on open standards. Although you won't know every technical detail, you'll have learned enough to plan your organization's future in a service-oriented world.



2. This is a very helpful book on SOA because it provides the business case for SOA, an excellent technical overview, and real-life examples of how to use it.
   
   While it is written from an SAP perspective, any IT group that is investigating SOA will find value in this book -- as it describes how SOA impacts different layers of the IT stack (from persistence to business objects, to process orchestration, and uesr interfaces). It also provides actual case studies.

No comments about AppleScript: The Comprehensive Guide to Scripting and Automation on Mac OS X, Second Edition.

No comments about Object-Oriented Software Engineering.

2 comments about Structured Finance Modeling with Object-Oriented VBA (Wiley Finance).

1. I had been waiting for this book for more than 5 months (preordered since December 2006). The content is excellent, but I expect to see a complete VBA code as a wrap up. It should also help if the code is provided in soft file so that the readers can see how the model actually runs without the need to merge all the examples and manually type the code into the computer first.
   
   Montri



2. This is an outstanding textbook on how to master the intricacies of a structured finance (especially, home-equity ABS) deal. It teaches ABS from several angles: modeling (chapter 1-4), structuring (chatper 5), and ABS analytics (chapter 6).
   
   Although definitions and explanations about any given deal can be readily found from prospectus and prospectus supplements, for practitioners like myself, this book improves one's understanding of what's, how's and why's of any particular feature of a typical RMBS structure. This is a book I wished I had read when I started in this business.
   
   In this book, the process of modeling a RMBS deal was shown step-by-step, with definitions, equations, tables and figures accompanying easy to understand explanations. The equations are written in a way that if is straightforward to be coded into VBA (or any other language) and be implemented.
   
   This is a book about learning about modeling and implementing an ABS. End of chapter programming excercises reinforce the notion of learning by doing. To respond to the prior reviewer's desire of having a complete program to run and test, I believe that the only way one is going to learn a complex structure is to read, follow, implement and experiment with self-written codes. This book provides you with all the tools and explanations you need to get started in this interesting field.
   
   

1 comments about Software Abstractions: Logic, Language, and Analysis.

1. This book describes Alloy, a tool for specifying and analyzing data structures and other relationships within your programs. The book walks you through a tutorial, showing you how you can find the bugs in your specifications before you actually write any code, and then goes into the details of the language and its semantics.
   
   I think I was exactly the target audience for this book (and the Alloy language), as I write a lot of Java software and have been looking for a practical specification tool. I've heard of other people who were less happy with this book, as they were trying to learn _about_ Alloy rather than learning Alloy itself. There is some material at the beginning and end that compares and contrasts Alloy with other specification languages, but the real value of this book comes in the middle where it teaches you how to use Alloy effectively.

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.