4 comments about JUnit Pocket Guide.

1. Quick disclosure - I'm a big fan of JUnit already. :) Anything that will convince java developers to use JUnit is a good thing. JUnit is as powerful as it is simple. To prove it, everything you need to know about JUnit is in this 80 page pocket guide. If you are a Java programmer, this pocket guide will easily convince you to add JUnit to your daily development processes. It covers the entire JUnit API, using JUnit with Ant, Extending JUnit, and plenty of suggestions on how to test various situations with JUnit.
   
   I liked the descriptions on how to run JUnit standalone or within various IDEs (Eclipse, JBuilder and IntelliJ IDEA). I have been working with JUnit in Eclipse for quite some time and recently started a project using IntelliJ IDEA - so it helped me get JUnit going quickly. I also found the short history on JUnit interesting as well.
   
   Whether you're new to Java development or just haven't used JUnit yet, this is the perfect pocket guide to help you get started.



2. This is a short and sweet end-to-end introduction to JUnit. The text is pretty terse and there are a surprising number of a screenshots for a book so small. The book starts with an introduction to testing. It then gives a high level architectural overview of JUnit, along with it's API. There is a short digression into the history of the framework. Then it's into putting a front-end on the tests both on the command line and embedded into IDEs.



3. I got "JUnit Pocket Guide" along with "JUnit in Action" and "JUnit Recipes". I figured I should have Beck's book since he's the father of JUnit and a major force in test-driven development. I figured I'd get a concise explanation of JUint and be able to use the book as a reference.
   
   While the book more or less meets those goals, the writing is terse and mostly fails to provide the illuminating insights I was hoping for. I was also disappointed that the book is not well-structured to use as a reference, and is somewhat out of date with JUnit 4.x at this point. After reading this I moved on to "JUnit in Action", which I highly recommend.
   
   Overall, I'm not disappointed that I got the book given the reasonable price and minimal investment in time reading it. It does serve as a quick introduction to and motivation for using JUnit. However, if you intend to put JUnit into practice, you can easily skip this book and go directly to one of the many excellent and more comprehensive books on JUnit--this book won't be enough and offers nothing indispensable.



4. The philosophies in this book will help me get more out of life.
   I have wanted to learn JUnit for several months now. The techniques in this book will help me write better code and think more clearly in many planning and development aspects in life.

5 comments about Testing Extreme Programming (The XP Series).

1. This book is fantastic. I'm only a tester to the extent that everyone doing XP is a tester but I found many valuable things in this book. There are excellent chapters about how to estimate and plan releases and iterations, including excellent tips on finding hidden assumptions in your stories. I like the book so much that I just bought a copy for a tester who works for me and told him to go home, read it, and not come back until he has so that we can discuss how to put some of the book's advice into practice. Everyone working on an agile project (not just XP and not just testers) will benefit from this book. It is one of the best-written and most useful in the entire series.



2. This book is a professional tester's perspective of being involved into an XP project. The book will invigorate the testers who never worked in XP environment to start doing this practice. The book starts with an introductory overview on XP, which is self-contained and should be easily understood by any tester, unless he or she has prejudices against XP. This introduction is helpful for those who inherently would like to use XP. The skeptical readers should first take attention to Kent Beck's "Extreme Programming Explained".

   For those who don't like to imagine of someone in the tester "role" on an XP project, the authors encourage to think of having a programmer with a "tester focus". The authors define the tester role to fill the communication gap between the user and the programmers.

   For those who are already practicing XP, this book should be a good repetition of the core XP practices. If you like to refresh in memory the essential aspects of XP, read this book. The authors give their own vantage point on XP, which compliments the original Kent Beck's idea.

   This book also contains the introduction to some automated test tools like JUnit (a testing framework for Java) or JWebArt (an HTTP-based web testing tool). However, the JUnit introduction given in this book won't help great deal to the C++ programmers, because the CppUnit, the C++ testing framework, have sufficient differences from JUnit. What the XP community who work with C++ really miss at the date of publication of this book is a good CppUnit manual.

   The book also have essential focus on story estimation and iteration planning, from the tester's perspective. However, from the programmer's point of view, this book contain very few useful ideas. The programmers might want to refer to Ron Jeffries' "Extreme Programming Installed" for some useful testing strategies, tips and tricks.




3. What a great book on Testing in the Xtreme Programming Environment! I expect this book to become the Bible for test engineers and customers who are engaged in formal testing on an Xtreme Programming project. Lisa and Tip walk us through some introductory theory, and then provide a detailed case-study to illustrate their methods. Though appearing somewhat complex to a non-programmer, their chapters 21 through 25 show the important principles of how to automate your acceptance test.
   Though I haven't yet had the experience of working on an Xtreme Programming project, I do have 30 years of hardware, systems, and software testing experience. Prior to reading this book, I read Kent Beck's "eXtreme Programming eXplained", so I had an introduction to Xtreme Programming.
   Once again, this is a great book. My welcome to 2 new authors; I hope we see more books from them in the future.



4. While I yield to no one in recognizing the value of testing software, my first reaction to reading the title of this book was one of skepticism. One of the fundamental principles of extreme programming (XP), is that the software is developed in small increments, each of which must pass a unit test before the next change is made. In fact, in many cases the unit test is written by the developers before they write the code. These incremental tests are also carried out by the two-person coding team, so it seemed strange to be reading about testing XP. From the title and blurbs on the covers, it was a natural assumption that the focus would be on testing other than that done by the development teams.
   After reading the book, that skepticism has largely gone, although I do possess some residual doubts about XP and how it scales. The basic point is that programmers are very good at testing their code at the unit level, but weak when asked to verify it at the system level. I agree with the authors that there should be a dedicated tester who examines the code at a level higher than the unit. However, I am also of the opinion that this is a confirmation of the doubt about XP expressed by so many observers, namely that it does not scale up to large projects well. The testers that they are proposing are more in the realm of a manager responsible for testing rather than a tester.
   This is of course very sensible. Once the programmers start producing code tested at the unit level and the integration process begins, someone must be responsible for the smooth flow and testing of the integration. This is also the level where the ever-present customer, another fundamental principle of XP, really sees the functionality of the code for the first time. While XP proponents speak a great deal about having the customer at the side of the coding team, realism dictates that they will generally be restricted from that level. Only the most technically sophisticated customer will be able to glean any useful information from most of the unit tests that will be performed. This is where the additional layer of the test manager is of use. By creating and demonstrating the higher level tests, the test manager can give the customer information that they will understand and can respond to.
   The authors also put forward a very controversial statement, "No manual tests. All acceptance tests on an Extreme Programming project must be automated." While I am in general agreement with the principle that tests should be automated for easy repetition at each level, the reality is that nearly every use of words such as { "no", "never", "all"} is too extreme. Especially when you are describing something as subjective as the behavior of computer programs and the human response to them. How one can automate the response of a customer to the appearance of a GUI interface is something I do not yet understand, and this is mentioned, but not examined in the book.
   One very positive aspect of the book is the exercises at the end of the chapters, and the authors do the very commendable thing and provide solutions at the end. After years of frustration with math and computer books that list exercises but avoid solutions, any book where they are included must be given a higher rating.
   After reading this book, my confidence in the value of XP has increased, ironically because one of the fundamental weaknesses is examined with an explanation of how to overcome it. The uber-tester is a concession to the problems of scaling, and the inclusion of such individuals will definitely make the development process run smoother. If you are going to use XP and your project is of any size, then you should read this book.

   Published in the online Journal of Object Technology, reprinted with permission.




5. This book explains, in detail, the value of having a tester role on an XP project. Much of what is written on XP focuses on the role of developers in writing tests, and this book will help you understand the value that testing professionals can add to an XP, or other agile, project. The function of a tester changes when a team applies XP; In the spirt of lean software development, this book shows you how to apply the skills of testers in a new environment. One minor flaw in the book is that it is targeted at testers. While testers need to understand how to apply their skills to an XP environment, others such as Coaches, programmers and project managers also need to understand the value of testers.
   
   Get this book if you are a tester, developer, coach, or project manager to understand how testers can improve your XP project.

3 comments about Assertion-Based Design (Information Technology: Transmission, Processing and Storage).

1. Once again, after "Principles of Verifiable RTL Design" written with L. Bening, Harry Foster wrote the book that made new level of standards in ASIC community. Even with notice that, as a Verplex Systems guy, he evidently advertise specific Formal Verification techniques, this book could not get anything then 5 big stars. Not only that this is the only book on the market that cover important topics like Assertions, this is also well and systematically written book, full of examples in OVL, PSL and SystemVerilog. And whatever ASIC designers say that they don't have time for Assertions, future is going in this direction. Book is written equally for design and verification engineers, but also for system architects and everybody involved in ASIC development. This book probably will not shake ASIC design world as previous bestseller from the same author, but it presents state of the art in covered area from the man who knows his job very well ...



2. Comprehensive and serious, it is worth reading.
   Some comments (for the first edition):
   -Assertions and white-box checkers are not exactly the same.
   (sometimes white-box checkers are more natural in say `e' than is PSL or SVA that are mostly temporal based)
   
   - Ooops , In all SVA examples "disable iff (rst_n)" ... ;-)
   
   - A small one, Page 204 example 6-46 :
   " assert property (@posedge clk) disable iff (rst_n)
   not ( SMQueNew -> $isunknown( ... ))) "
   
   The `not' should have been after the `->' , the current semantics is wrong.
   
   
   The book also lacks mentioning of assertions inside dynamic TB objects.
   (`e' supports it, maybe other languages too).
   
   
   Though, my key comment is that there is a lot more to verification than assertions ( e.g. Testbench implementation ).
   
   Ran Keren



3. The topics are discussed in a too generic way to let the reader take advantage of the book.

1 comments about Embedded Software (Newnes Know It All) (Newnes Know It All).

1. The book is like a catalog of Newnes' embedded series. Content of each of the chapters is basically taken from Newnes book. For example,Chapter 2 Device Drivers is taken from the book "Embedded Systems Architecture" and Chapter 7 Techniques for Embedded Media Processing is taken from "Embedded Media Processing". Well, it is not difficult to guess which books they were taken from, as the books are shown on the page on the back of the front page.
   
   Alright, so what is the consequence of different writers writing on different topics without knowing what others were writing? The result is, a lot of inconsistency and yet overlapping between chapters. The wide range of microprocessor examples used in this books includes Rabbit, TI DSP, Freescale. However, many common topics such as code optimization, real time system appear in 2 or more chapters. I quickly ran through the table of content and found MMU in Chapter 3 and 5, Code optimization in Chapter 7,8 and 9.
   
   If you are a fans of Newnes embedded series, or would like to find out what is this like, then maybe this is the book for you.

5 comments about Practical Software Metrics For Project Management And Process Improvement.

1. Whether you're a fledgling company trying to design quality software with no guidelines to go by or a well-developed organization with processes in place, this book offers up many ways that you can improve your software quality.



2. I was introduced to Mr. Grady's work when I borrowed a copy of Software Metrics: Establishing a Company-Wide Program. Where that book interwove a storyline into metrics and how they support mature process improvement, this book is more like a desk reference. Mr. Grady has divided this book into two parts: tactical metrics, which are project-oriented, and strategic metrics which address process improvement.

   The first part starts with a collection of practical rules of thumb for software managers. This collection of heuristics covers every phase of the development life cycle and are backed up with data gathered during 125 software projects at Hewlett-Packard. An example of one of these rules of thumb is that you will find 1 defect after software has been released into production for every 10 defects caught during testing. This, of course, is purely empirical, but is an interesting rule that I mentally filed away. Some highlights of the first part are: a good introduction to the goal-question-metric approach to determining what to measure based on your objectives, and a focus on project goals of maximizing customer satisfaction while minimizing project schedule and costs, and product defects. This is followed by chapters that address each of these goals. One of the best chapters in the first part of this book is work analysis. While I am more focused on the service delivery side of metrics (after the project has produced something that has been released into production), some of the metrics were very valuable to me - especially the ones that revolved around testing and QA.

   Part 2 is squarely in my domain - production and application support, and service delivery. The best chapter, Dissecting Software Failures, was one of the most insightful descriptions of the defect life cycle I have ever read. It fully addresses defect data collection and analysis, and how to use this data to effect process and product improvement. Even better is the chapter on investing in process improvement. Here Mr. Grady gives a workable approach to using the defect data to developing a business case for process improvement. He guides you through developing a plan, selecting from among an array of solutions, and case studies.

   This book is a quick read. It's main value lies in the many tables and facts provided on nearly every page. I use it as a desk reference, especially the appendices that summarize defect origins, types and modes, and metrics definitions. It spans both project and production metrics, and is as valuable to project managers as it is to application support professionals.




3. This is Grady's first book and it sets the tone for his later two books, Successful Software Process Improvement and Software Metrics: Establishing a Company-wide Program. What makes this book so important is that it is one of the first to integrate software metrics with project management metrics.

   What I particularly like about this book includes:

   (1) Complete view of metrics that matter, and the chronicle of how these metrics evolved in a large company (Hewlett-Packard).
   (2) Recognition that any software metrics initiative extends beyond the project that delivers the software - Grady examines post-production metrics and ties them back to not only the development life cycle, but the product life cycle as well. Ten years after this book was published there are still large organizations that are struggling with doing this, yet Grady's book provides a clear roadmap to achieving this elusive goal.
   (3) Continuous improvement is the central theme in this book. Grady does not stop with collecting and analyzing metrics, but how to effectively employ them to spot improvement opportunities and develop a strategy to effect those improvements.

   The book is written as both a story of how a successful metrics program evolved, complete with anecdotes that will prove helpful, and as a collection of data that illustrates what is and is not important to a comprehensive metrics program.

   Among all of Grady's books I like this one the best; however, I recommend that his other two also be carefully read if software process improvement is your goal. He has much to say and backs it up with data and a chronicle of his experiences from real projects.




4. Although this book is over 10 years old, it could have been written this year. The concepts are still relevant.
   The author concludes that there are 2 primary reasons to undertake a metrics program for software development -- 1) tracking progress and 2) identifying improvements. The book is divided into 2 parts, with the first part discussing project management metrics and the second part metrics to improve your software development processes. I particularly liked the goal/question/metric approach to validate the metrics you are collecting. The text is loaded with examples from the author's experience at HP. There are several charts and diagrams. This is not an academic read, but as the title says -- practical. The author also covers people issues, such as selling your metrics program to management and staff. It is a quick read and a very useful reference book.



5. I bought this book about 5 years ago after getting certified as a project manager. This book give me a holistic view of how to intepret data collected from tracking the entire software lifecycle and manage and integrate best practices into a software business.
   
   The author's vast experience in HP helps to provide good assurance that his concepts used were tried and robustly tested. Therefore, software failures, internal flags and customer feedbacks can immediately give you a fairly visible prognosis to the robustness of a release and flashes early warning signs of how you should manage that product to reduce damage to your business, etc.. Practical for technical managers having to manage the business operations.

5 comments about Concepts in Programming Languages.

1. While I cannot speak to the quality of Mitchell's course, having only read his book, the earlier criticisms of his use of ML in the book are missing the point of a programming languages class. It's not meant to teach you a random sampling of the 2500+ computer languages that are out there. The idea is to learn about the fundamental paradigms of programming, with a focus on the functional and logical approaches since students are generally already familiar with imperative and object-oriented programming.
   
   ML is one of several good choices for illustrating functional programming, and is actually one of the more popular functional languages (especially the OCaML dialect.) There are many well written books and tutorials on the ML family of languages freely available on the web if you need more examples or detail than he provides in this text. However, the point isn't to learn ML, but rather that once you understand functional programming in any language, you can take advantage of its power, not only in languages like perl and python which offer some limited but nice functional features like map and anonymous functions, but also in imperative languages like C via function pointers and callback techniques.



2. As a grdauate student, I feel compelled to write honestly about this book in the hopes that what I'm writing might influence some teacher's decision in the future. Granted, the topic area this book is covering isn't trivial, but in the light of its complex nature it is even more paramount that someone attempting to explain it to those who don't understand it be well-versed in, frankly, English. This book is quite possibly the worst textbook I have ever encountered. The writing is atrocious, the "flow" is like mud, and the explanations make even things that could be simple, dreadfully complex. Avoid it like the plague, there are a lot better options.



3. The excessive reliance on ML and poor language skills exhibited are well covered in the other reviews. I'd just like to add that Mitchell has a terrible habit of explaining things out of order (for instance, activation records are explained on page 165, but you are expected to know them on page 148), and his "This is beyond the scope of this book." handwaving makes many of the explanations completely incoherent.
   
   I have never sold back a textbook before, but I'm taking this back to the bookstore right after my final, and then I'll get a real Comparative Programming Languages textbook.



4. It's a good review book if you know your material and just need a quick refresh or need the same concept explained differently. However, this book will intimidate you if you're new to computer science. An example would be in Chapter 1, the words "stack memory management and recursive functions or procedures" were thrown at the readers without any explanation.



5. I can't speak to John Mitchell's skill as a lecturer, but some of the complaints here seem to betray a misunderstanding of the purpose of the book: to serve as an introduction to programming language theory, such as can be found in Mitchell's other book *Foundations for Programming Languages*. Mitchell is taking you *out of* the marketable skills zone and into abstract computer science, and he's being pretty nice about it -- the book contains friendly precises of topics like lambda calculus and denotational semantics, which make up the formal core of programming languages. What you will learn has applications in all popular programming languages, even if it's not spelled out in the text.
   
   ML was a good choice as an example language, because it includes many of the features a programming language might have (being both imperative and functional), and furthermore is a serious research language on account of its well-understood semantics and type system. Focusing on it to explain core concepts was not a mistake. Mitchell knows how to do it the other way, too: explanations of the basic elements of object-orientation are parceled out over several notable OO languages, providing a way to compare and contrast how the major OO concepts can be implemented. (I didn't find the final chapter, Apt's summary of Prolog, as helpful: the declarative paradigm is too far removed from what was developed in the rest of the book.)
   
   On account of its relatively gentle explanations and the importance of its concepts for all aspects of CS, this would be a good book for a relative beginner in CS to pick up (provided they can comprehend more than just code). But if you find it too repellent, you're probably not going to be much happier with more advanced treatments: its character just reflects the nature of the field.

5 comments about Using csh & tcsh (Nutshell Handbooks).

1. The five reviews of this book that have come in ahead of mine range from 1 star to 5! The reason is simple, but the people panning the book didn't explain (or understand?) the problem very well.
   
   Here's the dope: a Unix shell is both an interactive command interpreter, and an environment for writing scripts, which are basically programs using the interactive commands and some logical control structures to automate tasks that don't really need to be run interactively.
   
   The author of this book, Paul Dubois, is of the opinion that neither csh nor tcsh are appropriate environments for shell scripting. I happen to disagree with him, at least insofar as I teach a little shell scripting in tcsh in my sophomore level software course. However, his opinion is worthy...making the argument that csh and tcsh shouldn't be used for shell scripting. Dubois recommends sh and perl for scripting.
   
   So it boils down to this: this is an excellent book for learning how to make the most of the interactive environment of csh and tcsh. It's loaded with neat tricks and good insights. And it's a particularly good reference for tcsh, which usually gets little mention in other books.
   
   If, on the other hand, you want a book about shell scripting, save your money: THIS IS NOT THE BOOK FOR YOU. It has no material on shell scripting.



2. I've seen many books on unix shells, however almost all the other books focus on shell programming instead of actually using shell to work more effectively and efficiently. This book fills the gap (hence the name "Using...". I personally recommend Zsh if you are looking for the most comprehensive shell. However zsh is too comprehensive and there is no book on it. Tcsh shell is an EXCELLENT shell to do your work (type in commands, listing files, and etc). It has all the essential goodies: command line completion, command-line editor, history, and etc. It found it more friendly than ksh and less complex than bash and/or zsh. This book teaches you step by step how to use the shell to do your every day work effectively. The author explains everything clearly which is more than what I can say about many books that just touches a little bit of using the shell as a command interpreter aspect of the shell as if everyone spend more time writing the shell scripts than using the command line. These aspect of the csh/tcsh are the basis for similar utilities in the other shells: ksh, bash, and zsh. I find that even if you use bash or zsh, you'll appreciate the information in the book. The other reason the author didn't write much on programming is because c-shell is less frequently used in shell programming because of the now famous posting of "C shell programming considered harmful", which is also on the book's homepage. If you have the patience to read through the book, you will find it an excellent investment of time. (The only other book I would say this for sure is the "Learning the vi Editor."



3. What the heck ? This book omits MOST of the commands of csh/tcsh.
   I later realized that I could have found this from the other
   reviews, but I fundamentally DON'T understand the purpose of a
   book that leaves MOST of the details about csh/tcsh OUT of the
   book. What is this, csh/tcsh for ignorant people who wish to
   remain so ? Grrrr !



4. A book for the basic UNIX user. Does NOT include anything about writing scripts for this shell! Worthless! Don't waste your money.
   
   Amazon likes to bury bad reviews because it negatively affects the sales of an item. When considering a product on Amazon you should ALWAYS look for the bad reviews. This will give you a more realistic impression of the quality of the product.



5. This book is for learning how to use the tcsh and csh shells from the command line, not for scripting. If you want scripting look elsewhere. You will be as disappointed as all of the one and two star reviewers you see here. However, in particular if you want information on the turbo C shell (tcsh), this is one of the few books on the subject, even if it is 13 years old. As with all O'Reilly books on Unix, in particular the ones written before the year 2000, this one knows its audience and has plenty of practical information. Turbo refers to speed though, not clarity. If you are not willing to memorize some shortcuts that are not exactly straightforward looking, maybe you should stick with plain old C shell (csh). The table of contents can be hard to find for this old book, so I include it next:
   
   Part I, Learning the Basics
   Chapter 1, Introduction, discusses the purpose of the shell and describes how to change your login shell to one of those discussed in this handbook.
   Chapter 2, A Shell Primer, provides a summary of introductory essentials. If you already know something about running commands, you can skim this chapter as a review or skip it.
   Chapter 3, Using the Shell Effectively, is an overview of many of the facilities that the shell provides to help you work more efficiently--easy, practical ways to get more out of the command line. Often, even experienced users are not aware of all of these features. This chapter gives you a glimpse of the kinds of techniques that are covered in detail in the rest of the book.
   
   Part II, Becoming More Efficient
   Chapter 4, The Shell Startup Files, describes ~/.cshrc and ~/.login, the files that the shell uses to initialize your working environment. This chapter also provides guidelines for modifying the startup files to suit your preferences.
   Chapter 5, Setting Up Your Terminal, discusses how to find out what your terminal's special characters are (e.g., for backspacing) and how to change them if you don't like the default settings.
   Chapter 6, Using Your Command History, discusses how to type less by using your command history.
   Chapter 7, The tcsh Command-Line Editor, describes the facilities offered by the editor which enable you to edit commands interactively.
   Chapter 8, Using Aliases To Create Command Shortcuts, discusses how to type less by using the shell's alias mechanism to create command shortcuts.
   Chapter 9, File-Naming Shortcuts, describes ways in which the shell can supply filename arguments for you so that you don't have to type them all out yourself.
   Chapter 10, Filename and Programmed Completion, describes how to use the shell for completing filenames after you type just the leading prefix. It also discusses how tcsh can complete other types of words besides filenames and how to set up programmed completions.
   Chapter 11, Quoting and Special Characters, describes the shell's quoting rules. By following these rules, you can type any characters in a command line, even special ones, without having them misinterpreted.
   Chapter 12, Using Commands To Generate Arguments, discusses command substitution, a facility that lets you construct pieces of a command line from the output of other commands.
   Chapter 13, Navigating the File System, describes how to move around in the file system efficiently.
   Chapter 14, Keeping Track of Where You Are, describes how to stay informed about your current location in the file system.
   Chapter 15, Job Control, shows how to suspend, resume, and kill jobs; switch between jobs; and move jobs between the foreground and background.
   
   Part III, Appendixes
   Appendix A, Obtaining and Installing tcsh, describes how to make tcsh available on your system if you don't have the current version.
   Appendix B, csh and tcsh Quick Reference, is a summary of those features and capabilities of csh and tcsh described in this handbook.
   Appendix C, Other Sources of Information, contains pointers to other documentation. The most important of these references is the tcsh manual page. It's available in several forms, one of which can be navigated via hypertext links with a World Wide Web browser.
   
   All readers should start with Chapter 1. If necessary, change your login shell to csh or tcsh, using the instructions there. If you're a beginner, unfamiliar with the shell, or just want to review the basics of executing simple commands, you should then proceed to Chapter 2. If you're also having trouble figuring out how to do things like getting your terminal to backspace correctly, you may find it helpful to read Chapter 5.
   
   Chapter 3 is designed to "jump start" you into better use of the shell by presenting lots of shortcuts that save you time and effort. You'll quickly become a more fluent command-line user by applying the information you find here. For a more systematic and topical approach to the shell's capabilities, look at the chapters in Part II. They explain in greater detail the features of the shell that were briefly demonstrated in Chapter 3.
   
   Finally, use the index. The shell's features interrelate, so you'll often find that a particular capability can be applied in many different contexts, and most likely will be discussed in several places.

3 comments about Sams Teach Yourself UML in 24 Hours, Complete Starter Kit (3rd Edition) (Sams Teach Yourself).

1. The book is interesting but the author spends much time (many pages) explaining "obvious things or other matters" and not enough on UML...
   
   Anyway this book might be enough to know some on UML... and on gathering of Business Requirements.
   
   Gabriel



2. Useful book for getting familiar with initial syntax and semantics of UML, but I found did not manage to connect the ideas between the types of diagrams together well.
   
   Use of more real world examples would have helped.



3. This is a good introduction to the greatness of UML. I gets you up to speed quickly on what UML is, the various types of diagrams, and how to use UML in the real world. If you are looking for comprehensive coverage of the topic you will probably want to read some books by Martin Fowler and/or Scott Ambler next.

2 comments about Data Structures and Algorithms in Java, Second Edition.

1. I was looking for a latest edition of a book on data structures using Java. Lafore, Martin etc. are good texts but since collection API has introduced in jdk 1.2, those books seems to be obsolete. This book discusses new API and classes provided by java environment, so we need not to be bogged down by writing the unnecessary code. I feel this book is good for professionals in the industry as well as students of computer science. Algorithms are dealt with in detail with all the mathematical proofs involved, regarding efficiency and complexity. Various data structures are discussed with sufficient number of examples. Its a language specific book on data structures and algorithms, so if you are looking for a general book ar if you are working with any other language you will be dissappointed but surely a good book for java programming language.



2. I got another one of my text books online for cheap, which save me a lot of dinero!

5 comments about Pure Corba (Pure).

1. I am not sure why this book gets such good reviews. I have read most of it (from front to back) and found myself skipping alot towards the end. Like you'd imagine, by doing both C++ and Java examples it ends up covering neither well. If Bolton absolutely had to have examples in both languages, I think he would have done better by splitting it up into two books and then going into the level of detail that Henning and Vinoski do in their seminal book. It's a bit ridiculous to buy a book this size and still feel like you are not getting enough information.

   The main selling point that it has is it includes information on later CORBA features (like Components and Objects by Value) that aren't in other books. If you REALLY want to understand what is going on, go with the Advanced Corba Programming with C++, though it is starting to show its age a bit.




2. It's a pretty good book, though, not really comparable to "Advanced CORBA programming with C++". If you really want a good CORBA reference book get Henning and Vinoski's book. The best thing about this book is that it also includes Java which makes it a pretty good buy. Not all of the code is available electronically on the book's website which can make it cumbersome if you want to actually try to run some of examples....



3. As a Sr. Java developer, I was looking for a good CORBA book with a Java slant. Until I found this one, I wasn't having much luck. Look no further. There are lots and lots of examples in Java (and C++). I've only read 100 pages, but so far, I really like this book.
   
   Money well spent.



4. This book is great for beginners in CORBA, however you have to be a little more than advanced in JAVA or C++ to understand the underlying material. It provides good examples and I figured out how to better manage my IDL files/functions.



5. The content of this book is very good with plenty of explanations and examples in Java and C++. My biggest complaint is that the book looks like the pages were printed using a cheap laser printer and then glued together in a very poor binding. Pages in my copy are already starting to come loose after only a month of use.