5 comments about Beginning SQL Server 2000 Programming.

1. i got this book from 15 days ago and i read the first 13 chapter and i didn't like any of it,because it's not informative and he's explain the sql as a program not like an RDBMS and he's telling you about the 10% of anything,i don't think that any beginner want to begin with this book,bad databse example and i advice you to get the professional SQL 2000 programming if you are a programmer want to learn SQL,but if you are a beginner get first the by example for SQL 2000,



2. This is an excellent beginners book. From installation through to triggers all you need to know to get up and running. Shame it is missing about User Defined Functions but I thought this was a really good book.

   Chapter 1 - Good coverage of the versions, whats what. Also liked the installation of SQL Server.
   Chapter 2 Covered areas such as Enterprise Manager well and like the Configuring section. Found out how to set some very useful propreties
   Chapter 3 - Query Analyzer. Went through every item that a beginner should need as well as an intermediate. Helped me figure out and set up as I wanted
   Chapter 4 - This chapter for DB design etc is very clear and concise. I liked the Normalization section as well as relationships as to how these work
   Chapter 5/6/7 - Enough coverage and good warnings about the system databases and building the sample db. Also loved the defining tables and the different data types and finally all about the different indexes you can have. Very useful.

   Chapter 8 - This was my favourite chapter as it showed how to build relationships between tables.
   Chapter 9 - didnt think this was really necessary
   Chapter 10 - Good basics of backups. Not much on network backups.
   Chapter 11 - Good basics again of maintenance
   Chapter 12 - Images!! Yes!! No-one else I know touches this.
   chapter 13-15 - Loved transactions in the Insert chapter. all the others cover good basics of T-SQL
   Chapter 16 - Could have done a bit more on indexing a view but apart from that shows how to create a view well. Also how to use it
   Chapter 17/18 - Would have liked to see more about nested stored procedures but again good coverage. Dealing with errors was my favourite part
   Chapter 19 - XML - The way so much is going. Maybe book needs updating for SQLXML 3.0?
   chapter 20 - A bit advanced for beginners but triggers are a great plus.

   As I say, this is the best beginning SQL Server book I bought (this was my third!) and I loved the authors style and content. Wasnt confused at any point and found all that was being said to be clear. Wish I had bought it first

   Its downfalls? Well images it does say you need a binary stream to input an image but doesnt show any VB code to pass it in. No UDF's or UDT's and no coverage of SQL XML 3. Dedication was interesting but a bit long....
   Excellent coverage on how to complete each action in any method you wish so this does lead to excellent T-SQL coverage.

   Loved it




3. I went through three books (Learning SQL Server in 21 Days, SQL Server Programming by Microsoft, SQL Server 2000 for Visual Basic Developers) before I got to this one. This book beats all those others hands down. This is definitely the best book to get on learning SQL Server for beginners. It touches on all the areas you need to know to become proficient in managing your databases. I highly recommend it.



4. I read this book cover to cover only because I was required to for a graduate level class. Let's be clear about the type of book this is: one of those hand-holding exercises that walk you through every screen of the product, including a fifty-page chapter on installation, and manages to get at least two plugs per chapter in for another book by the same publisher. If you're looking for that sort of thing, it is fairly thorough and well thought-out and does include a significant amount of information on pitfalls to avoid. However, I personally found little here that I couldn't have found myself simply by installing the product and reading the online help. The pitfall warnings could have been condensed into a single chapter (and would have been much more useful than this 700-page tome). If you're looking for database theory, look elsewhere. Those kinds of issues are given short-shrift - normalization, for example, is glossed over in two pages that don't really explain it well, even though this is a key database management concept. I realized something was wrong when by chapter 12 (of 20) I was still reading statements like, "Don't worry too much about the SQL syntax shown here". Really? By the end of the book I was still wondering when we would become concerned. Mr. Dewson is obviously a knowledgeable database developer, and from his picture on the cover appears to be a nice person, but he is not a professional writer, and unfortunately it shows.



5. Nice all around book for getting to know SQL. Covers all the bases. Basic database administration, inserting, updating, and deleting data, views, stored procedures, triggers and XML.
   
   My only complaint is that the grammar is a little rough in spots. On at least a handful of occasions I found myself trying to mentally rebuild a sentence due to words being left out or misplaced.

5 comments about Oracle Insights: Tales of the Oak Table.

1. Declaration of Interest: I was lucky to have worked alongside one of the authors. So that's why I bought it.
   
   Glad I did. Read it on the beach over Easter weekend. Dipped in and out. Learned and laughed. Certain to re-read some chapters, and to refer back to it. The very different styles of the contributors make it all the more readable - you just don't know whats coming next.
   
   Its worth the price for pretty much any 3 of the 11 chapters, even if you chose them at random. And you can hit your SAN manager over the head with it, he probably won't feel a thing anyway.
   
   Thank you OakTable.
   
   But its not in your shopping cart yet is it, because I've marked it down a star. Look, there are some minor bugbears. Don't be put off, just setting expectations:
   
   1) There's some heavy name-dropping, perhaps in keeping with the project. Perhaps I'm jealous my brain isn't the size of a planet; these chaps' are.
   
   2) You can see from (1)that HHTTG was funny once, about 20 years ago. My dad has been citing it as the answer to everything ever since; its worn a bit thin. I'm sure he would love this book for exactly that reason.
   
   3) I'm the sure the sequel will be even better.
   
   You can put me down for 2 copies of "Seeing Double: Tales from Under the Oak Table" while I'm here.



2. I have 14 years of Oracle Experience with some of the busiest and largest transaction systems in the world. This book really hit home for me and brought back a lot of memories of painful times as well as gave me new insights. I have re-read this book twice since getting it amonth ago. It is that good.
   
   The Tales of the Oaktable is a skeptic's work of technological history that is funny and hard to put down, but which also provides experienced database professionals roadmaps to solve their pressing problems ( or even see that they have a problem.)
   
   The authors take an empirical, rational approach to diagnosing and discovering the most serious problems while providing amusing revelations about the people and organizations they have worked with. Along the way they lift Oracle's skirts and take us out back to show us the dirty laundry and other junk in Oracle's back yard. They provide methods to diagnose and reapir problems in oracle performance as well as enumerate the known pitfalls in project management and database design. Seasoned IT types will groan and laugh during these chapters.
   
   They also look at larger architectural, economic, psychological, and philosophical issues which have a direct impact on databases and large information systems. Norgaard's history of computing is quite depressing. And I agree that many of the "new" blood wants to focus on .NET and J2EE - when the real heart and soul is still the data.
   
   Oracle Insights DOES require both deep thought and deep, hard-won knowledge of Oracle in order to fully enjoy it. So, if at first you don't like it, then you don't know what you don't know.
   
   
   
   



3. I really don't know where I should begin writing this review to give the book a proper credit that it deserves. Hmm...FUN - I think that this word best describes this collection of essays (eleven prominent authors instead of more usual one or two, certainly helped a lot).
   Can't remember when was the last time that I read technical book that kept me reading and reading, and reading - simply because all essays were *fun* to read. To be clear, yes I'm an Oracle geek, but I don't think you have to be an expert to understand 'the point' in the majority of the book, on contrary, if you're by any chance an Oracle newbie you have an opportunity to learn from the true experts (from their work done on the "projects from hell") and pick up some good habits and techniques to start your Oracle career (this book is not really about internals as much as it's about proper design and importance of understanding technology before using it - and using it to the full extent - you'll probably never again write DB agnostic applications, if this was your sin in the past :-).
   So, being an expert or not, I'm sure you'll get the true 'message' from this book that will stick with you for the rest of your life (of course experts will enjoy reading it slightly more, they'll finally learn, what AFIEDT.BUF is really all about ;-).
   Finally, thank you guys for writing this book, and Mr. Mogens Noorgard (you lucky *****), thank you for "networking" Oak Table members together.
   Thank you for reading this review.



4. As an Oracle and SQL Server DBA for the last seven years I found this book an excellent and very refreshing change from technical manuals and books on Oracle database design and administration. The first few chapters are priceless from Oracle history to the useful read on Oracle tuning using Wait events. I really enjoyed learning how the product evolved from inception to the new version of 10g. All in all money well spent and nice to know that even such gurus as the Oak Table guys are human and have shared tough DBA experiences. Someday I want to meet and work with these guys!



5. The book starts off with "A Brief History of Oracle" that lasts 68 of the 395 pages of this book...
   
   Then it proceeds with various chapters by noted Oracle gurus which have serious flaws of being too superficial and random in their coverage of Oracle technologies. No aspect of Oracle is covered in depth.
   
   Worse yet, some of the authors have devoted far too little of their time on their chapters. Some of the chapters are nothing more than a bunch of philosophical rantings about Oracle and database management.
   
   If you are interested in Oracle performance tuning, I recommend books specifically devoted to the subject by a highly regarded author (Cary Milsap and Jonathan Lewis comes to mind). If you are interested in reading half motivated essays by Oracle gurus, then this book fits the bill.
   
   If you are unfamiliar with Oracle performance tuning and architecture, this book will offer a lot of interesting insights. But finding good technical nuggets of Oracle architecture and performance tuning will require some lengthy, and often unneccessary, reading.

5 comments about Find the Bug: A Book of Incorrect Programs.

1. 
   I am a programmer . I find this book helpfull. A must have for security specialists.



2. If you're a programmer who has to look at code that others have written, you'll appreciate this book... Find The Bug by Adam Barr (Addison-Wesley).
   Chapter list: Bug Classification; Tips on Walking Through Code; C; Python; Java; Perl; x86 Assembly Language; Classification of Bugs; Index of Bugs by Type; References; Index
   
   This is a excellent text to help you improve your skills on reading code and mentally debugging it. There are 10 short program or routines for each of the five languages. Your goal is to walk through the code and figure out what is the hidden error in it. There are three or four suggestions if you need help thinking it through, a couple of direct hints to focus your thoughts, and a complete explanation at the end. Even though you may not be familiar with some of the languages, Barr gives you a basic coverage of the fundamentals at the beginning of the chapter so that you can see if you are able to spot the error. Add to all that some good information on how best to walk through code, and you end up with a book that should be part of every developer's training. If you're part of a development group that does code walkthroughs, this would be an excellent guide to help everyone become more effective during the process.
   
   A good way to step outside your normal thought processes and improve your skills... good stuff.



3. Adam Barr steps you through code analysis in a logical fashion, guiding you around some obvious and not so obvious pitfalls. His writing style makes it easy to understand his concepts. Adam's selection of languages benefits programmers of all backgrounds. I especially enjoyed looking through the Python examples. The language summary at the beginning of each chapter is a great idea to acquaint newcomers to a language. Experienced programmers as well as hobbyists will find great value in the examples. Not only will you become a better debugger, you will become a better programmer.



4. This book has a set of bugs to work through in C, Java, Perl, Python, and Assembler. The bugs range from rudimentary syntax mistakes to more complex and subtle bugs. Hints are given to help you along the way. These will definitely give you brain a spin. Much link the C lint bugs in that have been printed in Dr. Dobbs for years. If you enjoy logic puzzles and bug hunting you will like this book.



5. While this book does something that I am in strongly in favor of, I don't agree with the approach. Barr presents a series of code segments that contain bugs and the reader is challenged to find the error(s). The bugs introduced into the code are fairly common, so finding them will be excellent practice for coders at all levels of experience. The segments of code are short, generally less than two pages, so finding the bugs does not require a great deal of searching.
   The problem is that the programs are written in C, Python, Java, Perl and x86 assembly. If you are experienced in a particular language, then the bugs will probably not challenge you. However, if you are a novice in a language, the ten pages devoted to introducing the language will not be enough to get you up to speed. I have taught all of these languages and I found it difficult to shift from one language to another. The syntax differences between the languages are enough to confuse even people experienced in all of them. I am also unconvinced that finding bugs in a language you are not using and are unfamiliar with will make you a better programmer.
   The general sequence of the bug presentations is:
   
   *) A textual explanation of the problem.
   *) The source code.
   *) Suggestions of questions to consider.
   *) Hints of operations to perform when stepping through the code.
   *) Explanation of the bug(s).
   
   Which is certainly a sound approach.
   I dithered a bit when trying to settle on a ranking for this book, largely due to the multiple languages. In the end, I settled on three stars because I believe that if you go through this book, it is more likely that instead of doing a few things well, you will do many things poorly.

5 comments about Microsoft Windows User Experience (Microsoft Professional Editions).

1. C'est un excellent ouvrage pour tout ce qui concerne l'interface graphique Windows. Il est relativement bien illustré. Il comporte de très nombreuses expériences d'utilisateurs pour permettre de développer des logiciels conviviaux et parfaitement adapté à l'environnement Windows.



2. I haven't finished this book yet, but so far I'm very pleased. It's very comprehensive, and contains many screenshots. It also contains information about integration w/ Internet Explorer, which is important to me. The only downside is that it's written by Microsoft, so some of Windows' shortcomings aren't really discussed.



3. Great book on how to design a graphical user interface correctly. Very useful if you want to follow Microsoft's user standards (and why wouldn't you).



4. While the MS Windows User Experience will be a necessary reference book for MS UI developers, it fails as a general guide for creating a "great user experience." Scaning the first chapter, for example, I just had to laugh: I had been just reading a text on the new Macintosh OS X interface then switched to the Windows book. The Mac OS X UI guide was simplistic and bland, while the first chapter of the Windows guide was verbose and unnecessarily complex. How stereotypical is it possible to get? Also, in chapter one of the MS book there are less than 2 introductory pages of positive text, then 16 pages on what NOT to do.

   If you are looking for a book which lists MS Windows UI elements, and contains the official MS explanation of what to do with them, this book would be handy to keep around. However, if you are looking for an excellent book on user interface and "user experience", I highly recommend going to the Macintosh web site and downloading, for free, the "ancient" (by computer standards) 1995 Macintosh Human Interface Guidelines (which differs greatly from the Mac OS X book mentioned above).




5. This book is a frame by frame, widget by widget, menu item by menu item prescription for "proper" Windows application etiquette. By following this book's advice, your applications will look and feel just like a member of Microsoft Office. You'll learn everything from how many units to space a button from the border of a box to how to select multiple discontinuous pieces of text and then copy and paste them across applications. There's even instructions on editing the registry so that your documents can be printed from the explorer.

   It's essentially a style guide for Windows GUIs the way the Chicago Manual of Style is a style guide for writing English. It won't make you a good writer, but no one will correct your punctuation.

   I actually found this book useful from a Windows user perspective. It tells you how all the controls are supposed to work. If you use MS apps a lot, you've probably intuited a lot of this, but it's interesting to see it all laid out.

   This book does not explain how to use the Windows APIs to create GUIs. Get a book on Visual C++ or VB for that. This book does not explain how to design a usable application. Read Jeff Johnson's GUI Bloopers or Alan Cooper's About Face. This book does not teach you to be a visual designer.

   This book is about as interesting to read as a typical user's manual. It's one unforgiving piece of advice and description after the next without a single case study in the entire 500+ pages.

   Even so, if you want to understand how Windows apps are "supposed" to behave or you have to write such applications yourself, this book is a must-have.

1 comments about Hollywood Secrets of Project Management Success (PRO-best Practices) (Best Practices (Microsoft)).

1. When I saw this book, I was excited. I'm a Business Analyst and in my spare time I work on writing, producing and directing low-budget short films. Most of my friends also work in the industry in various capacities. I have always maintained that there were many things that `Hollywood' did better than IT.
   
   However, much to my disappointment this book misses the point entirely. Mr. Persse makes a couple of good observations in some of his chapters but fails to develop his themes. He also becomes obsessed with the idea that the Producer is somehow entirely responsible for bringing a movie in on time and on budget, which is nonsense. Yes, they are huge contributors but in the end it does come down to the Director. The Director, along with the AD and various department heads, must drive the shoot through to a wrap. The Producer can do little once things go into production, except be supportive and take drastic action if things are seriously out of control. Unfortunately Mr. Persse glosses over the key role of the Director entirely (probably because there is no analogy to this role in IT).
   
   Finally, because Mr. Persse is talking from a purely theoretical knowledge (visiting a film set for a few hours and interviewing people does not an expert make), he fails to realize how the practical side of filmmaking influences a shoot. For example, the reason that a shoot is completed in 30 - 45 days is that the average working day on a set is 12-14 hours per day, six days a week. Crew members do not wander off to pick up their kids from school or leave to have some work/life balance. Everyone stays. For the entire time.
   
   With my feet in both worlds, I know that the primary differences between IT and `Hollywood' are the people and the attitude. If I want to feel like I did something worthwhile, work hard with talented and amazing people and get a project in on time and on budget, I go and put together a short film. If I want to feel incredibly frustrated (while being paid for it), I go work in IT.

2 comments about Object-Oriented Program Development Using Java: A Class-Centered Approach, Enhanced Edition.

1. If you are a hardcore "geek" type where you love programming and books with a dry technical nature then this is for you. If you're like the rest of us, you'll have to move on from this. I'm using this in my Java class and it's just got me lost because it's pretty boring and I'm a visual learner. My background is web design but moving my way into development and programming. I have done some programming and when it's laid out to me properly, I don't have any problems. However, when it's very boring and "just there" then there are problems. I purchased "Head First Java" and even though I'm only part way in, page 40, I'm gotten more out of it than the class has given me. Not to mention my teacher is dry so that's a lose lose combination. I had to go beyond that class and class' book to get the information I need!



2. Okay, I've bought many books to teach me Java Object Oriented programming (at least 15 books; honestly I'm not kidding! From Java for Dummies to O'Reilly to Core Java and many others). The thing about those books is that they didn't teach you the fundamentals (if you're a beginner programmer) of programming. Although do not get me wrong this book is a SERIOUS book for a SERIOUS reader. I can guarantee that if you read this book you'll have a better understanding of OOP in Java. But one thing is I don't recommend reading it tired or drowsy simply because of the complexity it goes into. But, most definitely if you want to learn OOP, this is the book for you.

5 comments about J2EE Platform Web Services (Java 2 Platform, Enterprise Edition Series).

1. When I obtained this book, I would looking for some in the trenches guidence on how to code web services using Apache Axis. The table of contents suggested that this might be an appropriate book for my needs.
   
   I should have read the Amazon reviews first. This is not a programmers guide, but a guide for architects and managers.
   
   This was a huge disappointment for me.



2. Have a look at the code snippet on pages 138-139. It's terrible. I've let go of a couple of coders over the years on the basis of their poor coding practices, and this reminds me of their stuff. Yeah, I know... the thrust of the book is big-picture high-level architecture, so nit-picking on coding style may be missing the point, but in the design and architecture area as well, I'm seeing impressive-looking diagrams and hifalutin claims of superior insights that, on closer examination, reveal a disorganized and indiscrimate jumble. Right now, I'm inclined to return the book. This book might impress your managers, but it shouldn't impress you.



3. I have bought 50+ java books and this is probably the only one that will survive the bookshelf. This book is to J2EE/Webservices what Kernigan and Ritchie is to C and Bjorn Stoustroup is to C++.
   
   Unlike the other java book Ray Lai blends the Enterprise Architect point of view with the technology. This is especially important in an organization such as the one I work for where java and webservices are new. I've cited Mr. Lai's section "Establishing a Business Case" and and the chapter "Web Services Architecture and Best Practices" in peer reviews and the subsequent white paper which I've written.
   
   There's also something in the book for the code warriors. An unexpected gem from trying the coding examples was the discovery of sun/server included with the java webservices developers kit (JWSDP). This java server from Sun is the most lightweight and administrator friendly java server that is freely available. If you're simply wrapping a java class with webservices, you're repeating this on multiple computers/platforms and you are inside the firewall this is the perfect technology choice. Unlike other application servers like jboss, weblogic and websphere, it is lightweight (doesn't hog cpu bandwidth and memory) and administrator friendly (works with other apps and quick/easy to install).



4. I agree with the previous reviewer of the book - This is a classic. If I go by other reviewers' comments, I may probably buy not buy this book but I read the book at a local bookstore for almost an hour. From the writing, one can tell that the book is written from an experience author with hands on experience in web services.
   
   This book has a lot of practical insights and not about theory of web services. It also covers areas such as how to integrate with legacy applications. This book is definitely written by experienced author. This is not just a book for ordinary Java programmer but a Solution Architect.



5. If you are Java developer, don't get carried away by this book title. This book has no conceptual relevance to j2ee or jwsdp. The book is also poorly written and the code examples are completely not usable at anyform. I did a big mistake picking this title.

5 comments about Developing Online Games: An Insider's Guide (Nrg-Programming).

1. In an industry still in its infancy, but with more of a history than most people realize, comes a couple of experienced pros to share their experiences and understanding of the phenomena of online games. This book is chock full of real numbers and real documents as well as anecdotal material to back it all up. Jessica and Bridgette give the floor to some well known designer/developers to let them share their experiences with us, too. And most of it is in Ms. Mulligan's slightly ascerbic but eternally hopeful-that-we'll-finally-get-it, wit that we have come to know and love in her Biting the Hand online games column. If you are about to spend several million dollars on one of these modern epics or have some part of the responsibility of getting one to market, you have to have this book right by your side all the way through the process. Great forward from Raph Korsten (Ultima Online, SWG), good stuff from Gordon Walton (Kesmai Games, EA, SOE), Jonathan Baron (XBox Online), Damion Schubert (Meridian59, Shadowbane), and several others. Looking forward to her next book in the series - how to manage one of these beasts!



2. The know-how of professional in game programming are like a gold mine. You can buy this one and take some for you. Great book.



3. I've always been curious as to what is the appeal of online games. It seems to be a thinly-veneered way of getting anti-social computer users to interact in a pseudo-social environment. My roommate is a big fan of Dark Ages of Camelot, and the devotion he places into playing the game on a regular basis confounds me.

   I picked up this book to try and see what the key ingredients are that make some games flop and others flourish. I learned that it's service. Most computer games leave the publishers office, and are never dealt with again, except for patches and such. Online gaming requires a certain amount of devotion after publishing that many game publishing companies don't understand. A persistent world requires persistent staff, running servers, customer service, etc.

   The book is excellent for developers; they will see the pitfalls and dedication they must place into a game during and after placing them on the retail shelves. I was more interested in the social aspects of gaming from the point of view of the player, and I wasn't that impressed with the book. If you use my review as a basis to purchase/not purchase this book, understand that I wasn't the target audience that this was directed to.




4. Developing Online Games: An Insider's Guide is worth reading if you are making an MMOG because the cost of admission is low relative to the cost of making an online game. I know this because of the three useful facts presented in the book:
   
   MMOGs are expensive to make
   MMOGs require expensive support and development after launch
   MMOGs are complex
   
   You probably knew this already though - in which case you would be wondering why you should buy the book? The answer is that the book drills these facts into your head through repetition over 500 pages. If you plan to spend 20 million to make an MMO it's good to get these facts clear.
   
   If you were looking for practical information from which to build an MMO you won't much in this book. While the the technical reviewer's qualifications are strong the authors have only worked in management positions.
   
   Developing Online Games wasn't useful to me as a developer but producers and managers should pick up a copy.



5. This book focuses on the elements necessary to develop a successful launch of an online game. In order to have the successful launch, the book looks at what needs to be considers in creating the game from the development team's point of view. The assumption is that you know how to code, you know what kind of game you want to create and you have the resources to create one. But this is the toolbox for the pre-launch, launch and the post-launch. It is an interesting look at the theories behind creating your game for longevity. The post launch is probably the most interesting phase from this point of view.
   
   "It isn't your game, it's the player's game."
   
   This has been written more for Persistent World Games as they need a community for them to thrive. There are chapters that look at how to build these communities and nurture them so they continue playing your (or is it their?) game. One chapter looks at the different players you will encounter that can help, hinder or downright sabotage the success of a game (the 3 broad groups are aptly called Barbarians, Tribesmen and Citizens).
   
   This book is also worth a look for the Online Timeline starting in 1986 and the anecdotes from games that worked and games that didn't. You might chuckle a bit in remembrance of some of the events mentioned, like the first testing of Quake in 1995. If you are looking to develop a game that has a following, there are definitely some tips here worth knowing about.
   
   Ghada
   www.ZoDAL.net
   New Zealand

5 comments about The Korn Shell: User and Programming Manual.

1. This book will get you up and running faily quickly. All the information you will need is in there somewhere, the trouble is finding it. I was not at all impressed with the layout. There are however some useful tables which list related syntax, it is a pitty that they are scattered all over the place.



2. This is the best Korn Shell book I've seen I presently have at least 5 different books on shell programming in Unix. I actually was able to read this book cover to cover AND am able to use this as a reference. The O'Reilly Korn shell book is good BUT, you have to read TOO MUCH to find what you're looking for. I found this book to be very complete.



3. This is a great book. It has a couple of typos, but nothing major (although it may confuse a few novices). If you need a book that gives you all the syntax and commands for programming the korn shell then I would recommend this.



4. People who write compter books often make one classic error -- in explaining a topic they refer to other commands and topics briefly, with no explanation. If you are new to the subject you are left bewildered. If you have some experience you know what they are talking about.

   Apparently most authors find it impossible to comprehend that people are reading their books to learn. They write as if people already understand most of the material.

   This is a good book if you already have worked with another book on shell programming, have taken a class or have some experience. But if you are just starting out try Teach Yourself Shell Programming in 24 Hours. The author of the 24 Hours book has the rare ability to have each of the chapters cover one topic, without dropping references to other topics he has yet to explain, so you keep learning and learning, one thing at a time.

   If you already have a knowledge of the basics this is a good book. I found many of the explanations to be clear and crisp, and understood with ease a few things I was fuzzy on. But that was only because I already had enough knowledge so that when the author just dropped some command into the discussion without explaining it, I already knew the command so I could follow along.




5. I purchased this book ten years ago and it is still my go-to book for UNIX shell scripting in the Korn Shell. It contains everything you need for shell scripting including quick lookups when you just can't remember what switch you need to use for a particular command.

5 comments about Requirements Engineering: Processes and Techniques (Worldwide Series in Computer Science).

1. This book is broken down into requirements processes and techniques, which makes an ideal reference for companies that are implementing requirements engineering, for consultants who are developing and implementing requirements processes and procedures for clients, and for individuals who are seeking to improve their professional skills.

   I like the way this book starts with a frequently asked questions (FAQ) about requirements. In my experience requirements and the processes and techniques that are associated with eliciting and analyzing them are not clearly understood. Too often requirements spill into design, and this part of the book will show you what a requirement is and what it is not.

   The requirements process models covered in this book are complete, and serve as a complete life cycle of a requirement from elicitation to analysis, validation and management. Some strong points about this approach include the need to test requirements, as well as to manage changes as they are refined. Moreover, the authors' approach to constantly assuring traceability is a mature practice and the key, in my opinion, to effective requirements management.

   Part two of this book covers the requirements engineering techniques that are the "moving parts" of the processes. Some are outdated or cumbersome, such as Structured Analysis and Design Technique (SADT), while others are interesting, such as Viewpoint-oriented System Engineering (VOSE). Some highlights of this part of the book include: definition of non-functional requirements (another grossly misunderstood aspect of requirements management), interactive system specification approaches and transitioning to object-oriented design. I also found the case study at the end of the book both useful and interesting.

   I think this book is an excellent starting point for understanding requirements engineering. It covers a wide range of methods and does not advocate any particular methodology, which makes it valuable for generalists who do not want to lock themselves into a single way of managing requirements. The processes provided are excellent and complete. I recommend this as a first book on requirements engineering because of its unbiased and straightforward treatment of this discipline.




2. Since the publication of this book, newer software development methodologies have either hit the marketplace or become more popular including the Rational Unified Process (1999), eXtreme Programming, Scrum, etc. This book needs to be updated to incorporate these newer approaches to software development. The principal drawback of this book is a lack of treatment on how to manage the requirements change during the iterations that are the mainstay of these iterative development methodologies.

   Even though this book is not aimed at detailing any particular methodology, I believe a newer edition should address this last concern from a general perspective. To prove this point, there are only a few pages that briefly talk about a couple of aspects of the Use Case approach to requirements which is now here to stay.

   Other than that, this is an excellent book that takes a text book approach to requirements engineering and explains everything you ever wanted to know about this topic from an abstract and general perspective. It also has a lot of practical techniques.

   For a book dedicated to best practices, you should look at Software Requirements by Karl E. Wiegers. Managing Software Requirements Leffingwell and Widrig is part of the Object Technology Series and does a better job of addressing the Use Case approach and is more recent. Effective Requirements Practices by Ralph R. Young takes a more step by step approach to the whole requirements gathering process and is worthwhile looking into.

   Now that I have outlined what's missing and what the competitor books on this topic address, back to the book being reviewed. The book is divided into two parts - The Requirements Engineering Process and The Requirements Engineering Techniques.

   The chapters in the process section are very useful. The first chapter starts off with an FAQ approach to explaining requirements and outlines the basic requirements document and how to write it. The other chapters in the first part are Requirements Engineering Processes, Requirements Elicitation and Analysis, Requirements Validation, and Requirements Management. All are very well written and quite thorough.

   The chapters in the Techniques section are a mixture of excellent and okay topics. I found Chapter 6: Methods for Requirements Engineering to be very interesting as it addresses data-flow modeling, semantic data models, object-oriented approaches, and formal methods (I am directly stating the different sub-sections of this chapter). Chapter 8: Non-functional Requirements is a must-read! Other books haven't done such a good job of addressing this critical topic that seems to get neglected in many a project. The last chapter is a case study.

   Overall, this is a good book on requirements engineering but in my opinion, you are better off reading this book as part of a classroom course and not as recommended if you are taking a self-taught approach. The other books I mention are better suited for that purpose. Do read Linda Zarate's review on this book as I did not address some things that she does a better job of explaining.

   It is absolutely critical that requirements engineering be mastered in order to have successful software project and product. Overall, this book is pricey for the value added but worth looking into if it is part of your company's project management library. Good luck!




3. Wiley should be ashamed to publish this book; every page shocks me with careless grammar errors and convoluted logic. Tonight's bombs included "This are stable features of the system" (page 116) and "Surprisingly, Davis does not mention what we consider to be the most important traceability information namely information which records the dependencies between the requirements themselves" (page 129). The diagrams are extremely simplified, usually a handful of boxes with arrows, some labeled, some not. The print looks as if it had been delivered as "camera-ready" out of an aging departmental laser printer; entire lines are skewed to italic, and the grey backgrounds behind "key points" and other focus boxes are very dark with distracting vertical stripes. Getting useful information out of this book is very challenging, as I have been constantly tripping over run-on sentences, oddly phrased summaries, and incorrect assertions about the state of technology as it applies to the practice. If you can find ANY other book that may suit your needs, get it instead of this one. It's offensive to have to pay so much for a book that doesn't even meet high-school standards for composition. If it weren't required for a class, I'd be trying to get a refund right now. You can bet I'll be selling this paperweight at the first opportunity.



4. This book is severely out of date, which is obvious from the techniques and methods it discusses that nobody uses any longer. It is, in general, poorly written. However, it does make a good doorstop. It would be better if it were a little heavier.



5. This book should not be the primary text used for a Systems Engineering course, yet it was. I read several reviews that stated this book had errors. Indeed the author must not have proof read his text. It is poorly written with so many spelling and grammar errors you have to wonder how accurate the information in the text is. Additionally I have noticed that the author has half-facts or contradictory statements. If you are forced to purchase this book for a class, sorry to hear about that. If you have an option to not buy this book, don't.