5 comments about Pro XML Development with Java Technology.

1. This book discusses technologies that a Java/JEE developer would use on a regular basis. It keeps it real by providing sample code and discussing the concepts at a technical level unlike other books that bombard you with buzzwords and jargon.
   
   I keep the included sample projects mounted in Eclipse all the time. I found myself copying and pasting from these samples into my own programs. I do this not only for APIs that I am learning but also with APIs that I am pretty familiar with. I do this to save time as I won't have to lookup javadoc or other internet resources.
   
   I have worked as a J2EE Architect and am now working as a Web Services Architect. As part of my job I frequently develop documentation on concepts discussed in this book for providing guidance to my developers. Now all I do is, I give them this book and refer them to a relevant chapters.
   
   In short this is the only book I need for all my XML development needs. A must have in any Java/JEE developer's bookshelf.



2. This book covers all important details of XML technology for use in Java.
   Although all this information exists in various fragments elsewhere, this
   book does an excellent job of bringing a lot of technology together in a
   simple to use, step-by-step description.
   
   This is great book to have if you use java on a regular basis but have
   been hesitating to use the XML alphabet soup. This book is a must-have.



3. This book is titled 'THE EXPERT VOICE IN JAVA TECHNOLOGY'. But this book is full of something like how to use eclipse(window pictures in many pages), which most of experienced programmers already know. It repeats this again and again. Another book 'Java & XML ' is much better than this one.



4. This is a very decent book on XML with Java. Lots of examples and it is pretty well organized. Good coverage of SAX, StAX and JAXB. Be aware that if you are looking for in depth coverage of XSLT or XPATH this is not the book ( and doesn't purport to be). Although examples are for Eclipse IDE I was not fazed by this at all and readily translated them to my IDE.



5. 
   Information in the book is great.
   
   Author's sarcastic tone of voice often mocks/belittles the 'dumb reader'
   
   "We will not describe this schema definition in great detail. By now, you should be familiar with schema constructs; if you need to review this material, please refer to Chapter 1." pg. 375(ch 14)
   
   "At this point you may be wondering ..how it knows what this message is requesting. From an intuitive standpoint, the answer to this question is that the.... pg 361
   
   "If you examine the response message, again from an intuitive standpoint, you may notice the following points" pg 362

5 comments about Applications Programming in ANSI C (3rd Edition).

1. The authors give a truly indept lesson for a person learning C with little or no prior knowledge of C/C++ programming.

   A background of some other language is pretty important. The authors don't waist time explaining the basics of all programming languages to you.

   I only really have one problem with this book. It was a little too expensive; but all college books seem to be that way.

   It may seem to be a little outdated (Published in 1996) but the information is still current. I have seen few in depth books written for C since that time. Most new books talk about C++ and now C#.

   I strongly recomend to anybody wishing to learn C++ to first read this book.




2. I am taking a community college class in which this book is the main textbook used. We are less than a month into the course, and I can tell it will be somewhat of a bear. I understand that the C Programming Language is not a trivial thing to learn, taking years to fully master, but with books like this, I can see why.

   The book begins its preface stating that it "assumes no prior programming experience in C or any other language", yet after reading perhaps six pages of the introduction, we find ourselves knee-deep in hexadecimal explanations of internal represen-tations and binary two's complement integer conversions. Which emphasizes one of my sticky points with this book: the overemphasis on clever, higher math tricks while at the same time using confusing, logically bewildering code with your occasional typo. Some of the examples this book choses to use are just plain brutal, which I simply skipped over until I found something written by a human for humans. Compounding all of this is the underlying attitude that a beginning computer science student ought to be familiar with all this high-brow stuff, and if not, then you're probably a lowly undergrad.

   It's not that the book is worthless, it's more like it's an ego trip that some mathematically savvy C professor wrote who isn't interested in TEACHING what he knows, just demonstrating in an obscure way that he knows a lot.

   Fortunately, I had previously worked through a few C tutorials on my own and read other less-mathematically-laden introductions to the language before I took this class with this book. Otherwise, my situation would have been even worse.

   So, if you are considering taking a college class in which this is your main book, or you are considering buying this book, be prepared to buy another book for background/additional explanations of obscure points this book glosses over, or simply for better examples. I found the Dummies series (hate the name, but the content is good) helpful, but what works for your particular learning style may be different. Good luck, and GodSpeed.




3. The book was in amazingly great shape eventhogh the price was very low. the transaction was fast and so the shipping.
   Very pleased and happy with my deal.



4. For those that had a tough time with this book, I can certainly understand. I had no prior programming experience in C or any other medium to high level language prior to this course.
   
   My title is obviously misleading and I found this book to be amazing... after I read it for the second time. That's right - in one semester I read it three times in total and later went on to scan through it for an approximate 3.6 times reading through it.
   
   My first time reading it I said, "..you've got to be kidding.., this isn't a book.. it's a paperweight from an unknown galaxy..". I did my best to stay optimistic as I had a great teacher who pushed us to excel... teachers do make a difference as Im sure most of you know. So I went back and this time took longer to read it, did the example programs in each chapter and walked through each one step by step til I had migraines... I also attempted the programming questions( not the harder exercises ), and kept a log book of each chapters questions so as to grade myself. It was after reading it this time around that I had come to understand what was going on... which is hard to explain in words. It's the "aha!" and, "that's it!" realization you all of a sudden get. The third time I quickly scanned through the worked example programs again... and attempted the exercises which are extremely difficult and you have to use your own discretion as there's no answers to them in the back of the book. Needless to say I did not do as many I wish I could. The fourth scan through was for tests preparation.
   
   I think what I'm trying to convey here is that this book is not going to do the programming and learning for you. You can't pick up this book/course/science and expect to know how to do it... unless you're a phenom in the minority. It's an applied field, you need to get your hands dirty and slam that keyboard. Who knows, it might only take you two times through the book. When you come out of the course and know you put in a valid and sincere effort, you'll look back with amazement at how far you've come. Anybody can do this. You can't do this if you don't want to. You can't do this if you don't apply yourself. This is isn't policical science, sociology or criminal justice where you get to talk alot and not do alot. In this field, you talk less and actually do alot. I think you get the picture.
   
   In hindsight, after about the second or third read I realized this book was actually written well and organized appropriately but you can't expect to understand it if you don't make the effort. This book has no fluff, this book is all business.. after recieving a practically new book, and putting in through the ringer, the book is 65% marked up, heavily marked with blue and red pens and yellow highlights, pages falling out and binding broken. You can't take it lightly, it's not a 'for dummies' book, but the 'dummy' can do it if given the time, motivation, and will to succeed. You can do it.



5. I have been teaching computer science classes for 18 years and have also professionally reviewed and edited about 20 textbooks during this period. This is the most thorough and accurate C textbook I have ever seen. It is not written at an "easy" level. The style is clearly for computer science majors, professionals, and others who are serious about programming. If you want a book with that in mind, that is extremely accurate and covers everything you may want to know with excellent, real-world, and high-level, non-trivial application examples, then you cannot find a better book than this.

4 comments about Programming on Purpose: Essays on Programming Design.

1. Few books I review get 5 stars. This is one of them. Programming on Purpose is a collection of essays originally written for Computer Language magazine. Although the original publication of this collection was in 1993, the materials in the book date back considerably further. Are Plauger's observations and nuggets of advice still relevant? Absolutely.
   
   When you read modern classics like Design Patterns (Gamma, et. al.) you might mistakenly think that such works are revolutionary instead of evolutionary. Going back and reviewing books like this should correct any such misconception. Here's an example:
   
   In his discussion "order out of chaos", Plauger writes "When you encounter a situation where data is presented in chaotic order, but must be processed in some definable order, you have a sorting problem. Forget about data structures or structured programming for the time being. Instead, cast the problem in a form that can be handled by known sorting technology, then apply it."
   
   In short, Plauger urges you to "see the patterns" in the problem. If books that purport to teach design patterns were so pragmatic and clear they might be more successful! Plauger has many such clear, lucid thoughts, elegantly expressed. Here's another:
   
   "My major concern here is the Principle of One Right Place--there should be One Right Place to look for any nontrivial piece of code, and One Right Place to make a likely maintenance change." Of course. Good OO design, indeed any good system design, should support this notion. Yet, how many systems and their designers do not?
   
   UML design tools and other wizard-like code generators may produce the superstructure of our programs (under our design and direction, of course), but what goes between those curly braces often, if not always, dictates the final quality of our work. Plauger provides powerful insight into our craft that shouldn't be missed by anyone who codes for quality.



2. Definitely a must have. One thing to keep in mind while reading this book is that it is a collection of essays taken from Plauger's column in Computer Language. Mr. (or should I say Dr since he has his PhD) has an easy and enjoyable reading style. The book's main thrust is collection of design methods each with a specific purpose. These design methods are used at various stages of developement on specific type of problems typically faced by programmers. Thankfully, P.J. also provides an overview chapter of when these various design methods must be used as well as their strengths and weaknesses.

   This is not an OO methods book. Although P.J. does mention OOP, he is not focused on this subject. However, he does remind us that abstraction, encapsulation, and inheritance existed long before OOT. While this is rather obvious, it is something many of us need reminding. This book convinced me that understanding pre-OOT design methods (i.e. structured analysis, data-structured design) would enable me to better apply OOT.

   Although Plauger mentions near the end of the book that he is not a text book writer, I sure wish he would reconsider turning this material into a textbook. The essays are really good, but some lack enough detail to be applied strictly from the knowledge imparted in the essay. Plauger also cheerfully reminds us that there is no one-size-fits-all method to solving a problem and that sometimes experience might lead us to do things we previously thought we shouldn't. In the end, software development is still as much an art as it is anything else. Thanks Mr. Plauger for an excellent read.




3. Maybe because, unlike Plauger, most authors tend to advocate for their particular methodologies and do not really teach how to make the best use of the available design techniques. (Well, maybe it is just that way and it will never become easier. That's part of its charm.)
   
   There are no silver bullets (that is, no "one-size-fits-all" method) and "we often cannot articulate why we do what we do when we do it." Plauger tries to address this problem not by proposing yet another silver bullet, but discussing useful design principles.
   
   Despite some dated examples, Plauger's observations and advice are still relevant. You will find interesting essays on stepwise refinement, the use of grammars to parse input data, and structured design techniques.
   
   If you think these are not "hot topics" today, pick this book just to enjoy yourself reading about "software design heresies" (apparently counterintuitive ideas), the authors' curious approach to teaching, or his peculiar comments trying to demystify [and even debunk the hype behind] object-oriented programming (written at a time when object-orientation was something completely new for the standard software developer.)
   
   I'm sure you will not regret the time you spend reading this book.



4. This book contains, in rougly equal measure, both valuable information and nonsense.
   
   In Plauger's view, "a [design] method tells you what to do when you don't know what you're doing" (p. 63). This means that programmers need design methods because we do not always know what we are doing. According to this view, if we knew what we were doing, we would not need design methods. Stated a different way, we need one or the other, design methods or real understanding. What does it mean to know what you are doing? It means to have a complete and integrated understanding of the principles that apply in your field. With such an understandng one is able to choose an approach without the help of prescriptive methods. But this is a book about prescriptive software design methods. It is not primarily concerned with helping the reader to grasp the fundamental principles of software engineering.
   
   The design techniques presented in this book are essentially rules of thumb that apply in specific situations. They are based not on precise facts but on a kind of "folk" wisdom of approximations and intuition. Plauger is certainly not alone in his approach to this subject, though he is undoubtedly more forthright than most. It is probably fair to say that a majority of popular books on software engineering treat it this way.
   
   In his first essay, "Which Tool is Best," Plauger denounces "rigid thinking." But this notion is a red herring. He is really referring to blind faith, which is not thinking at all. One is not properly called "rigid" or dogmatic for one's intransigent belief that the earth is spherical rather than flat, assuming that one holds that view in a proper context, that is, with a full understanding of precisely what the words mean, in what senses they are used, and the body of background knowledge upon which their meanings rest. Real facts are categorically true and must always be held by "rigid thinking" with the proviso that they are also held contextually. The true principles of software engineering are in this category. By contrast, Plauger's programming methods derive primarily from intuition and rest on vaguely defined terms, approximations, and floating abstractions. As presented they can be neither understood in any full context nor properly integrated with the rest of one's knowledge. Without an understanding of their underlying principles these methods can only be applied in blind faith. What Plauger means by "rigid thinking" is simply a failure to recognize the proper scope of application for each technique. If one's views are based not on facts but on impressions and approximations, one must admit that they cannot be universally applicable. One cannot even precisely define their scope of application. But when engineers apply their methods in blind faith, they tend to just keep doing whatever has worked for them in the past.
   
   Plauger's analogy of design methods with carpenters' tools sounds pithy but thoroughly obscures the real issue. Knowledge and physical tools are not equivalent. Both carpenters and programmers employ both knowledge and physical tools. Professionals in both fields need to understand precisely why their chosen methods are optimal in given situations, not merely approximately why they seem to work. Programmers do not need more flexibility in their thinking; they need a precise understanding of the true principles of software engineering, which do not change. A carpenter needs to know why a jigsaw is not the right tool for cutting a pane of glass, but this does not constitute flexibility; it constitutes understanding. In short, what we need is not memorized methods or practices but to know what we are doing.
   
   Much of the philosophical content of this book is evidently aimed at upholding the implicit view that software design is much too complex to approach with plain, ordinary conscious reasoning. On page 12 Plauger tells us approvingly that many truths come "packaged" as precepts that appear to be mutually contradictory. He is essentially saying that he prefers not to untangle fallacious equivocations and context dropping; he would rather leave his understanding--and the reader's--muddled with apparent contradictions. In this and other passages Plauger evinces a Zen mentality by trying to demonstrate (fallaciously) that nothing is as straightforward as it seems.
   
   Beyond these errors, which a great many writers about software commit, this book has its own unique flaws. Much of Plauger's rhetoric is clearly off the cuff. For example, on page 108 he mentions the acronym SAPTAD but says he has forgotten what it stands for! In many places he does not even seem to know exactly what topic he is writing about. It looks as though he chose a topic for the essay and then just started writing about whatever came to mind.
   
   Despite these flaws, most of the design techniques in this book will be valuable to the engineer who understands the unstated rationales behind them. The nature and complexity of modern software problems along with advances in design methodology are such that these old structured design techniques are generally no longer useful for designing whole systems; but they have specialized applications within larger object-oriented designs. For example, often once a class has been specified, one must design one or more complex data transforms to implement its methods. Hence even modern programmers need to understand the principles of data structured design, and this book presents a thorough survey of its essentials. Nonetheless, the reader must seek out their underlying principles in order to ascertain their proper scope of applicability. And some of Plauger's ideas, particularly those associated with object-oriented techniques, are just plain wrong.
   
   The first few mentions of object-oriented programming in this book are markedly antagonistic in tone. When Plauger finally gives in and decides ostensibly to advocate object-oriented programming, he attempts to trivialize it almost out of existence. He maintains that the popularity of object-oriented programming is mainly caused by hype but grudgingly concedes that certain object-oriented language features can be useful.
   
   Plauger devotes essays twenty through twenty-two ("Abstract It," "Encapsulate It," and "Inherit It") to attempting to demonstrate that there is really nothing new about object-oriented programming, but he is attacking a straw man. It is clear that he does not understand, even on a rudimentarly level, what object-oriented design is. In "Inherit It," on page 199, he confuses the inheritance relationship with the class/instance relationship. Not only does he think an instance inherits functionality from its class, but he even thinks a function can be said to inherit the functionality of the primitive language types and run-time routines that it uses. He endeavors to demonstrate what he clearly believes--namely that object-oriented programmers merely attach fancy new names to existing concepts--but he only succeeds at showing his ignorance of object-oriented concepts.
   
   Plauger also talks somewhat excessively about himself in this book. A significant share of its content is about the author, not the subject. The final essay, "Remedial Software Engineering" (p. 215), is nothing but a story about some of his teaching experiences, though he does not even seem to realize that he has not been expounding great truths about the state of the art. On the other hand, his self-deprecating remarks in the early chapters are tiresome. One finds oneself thinking, "If he's really so insignificant, why am I reading this?" As the book progresses his tone grows more authoritative. In "Which Tool is Best," on page 8, he says that he does not pretend to be a software engineer; but in "Remedial Software Engineering," on page 220, he claims to have successfully taught graduate students everything they would need to know in order to call themselves software engineers.
   
   According to the preface, these essays were professionally edited for publication in the magazine "Computer Language," but Plauger went back to his originals and re-edited them himself for this book. That is unfortunate. A good editor could have enhanced the value of this book considerably. On page viii of the preface he also mentions "a certain colloquial illiteracy" that he finds "comfortable." This is certainly evident in the numerous occurrences of downright bad grammar that distract the reader's attention from the material. The effect is merely one of shoddiness. What excuse can a professional author of technical books have for not being "comfortable" with proper written English?
   
   This book could have also benefitted greatly from the services of a good designer and professional typesetters. Here again, Plauger has chosen a do-it-yourself approach, and it shows. Some of the diagrams look like bad photocopies that are several generations old and almost unreadable. The typographical style, though not awful, is not up to the usual standards for technical books.
   
   This is a book of classic "folk" wisdom from the age of structured and data structured design. It is valuable because it surveys many of the key design techniques from that era, and these are still useful to modern engineers employing object-oriented methods. Some of the insights in this book are very good. But one must read this book critically and be prepared to wade through irrelevant material about the author, to disregard flawed philosophy, and to ignore bad grammar and substandard typography.

5 comments about Shell Scripting Recipes: A Problem-Solution Approach (Expert's Voice in Open Source).

1. If you are using a Bourne-type shell, and BASH in particular then you will find a lot of valuable information in this book. Author Chris F. A. Johnson provides an extensive education on scripting including scripts for viewing, editing, and manipulating files, manipulating strings, altering the path variable, monitoring the file system, filtering spam, backing up, archiving, deleting, and many other common tasks. How far can you go with a shell script? He even gives a working example of a database application written completely in script. On the other hand if you just want to have some fun there are even scripts for creating anagrams, fitting words into a crossword, or finding words that contain a given set of characters.
   
   While the book is really written for the technically oriented reader, even the very basics that most users should already know are still covered. The format is more typical of what computer technicians want - this is the item to be discussed, this is how it works, this is an example, move on to the next one. When I am looking for answers this is the format I prefer and I found this book extremely useful. It will be on my bookshelf as one of the first to grab when I want to do scripting in Linux. Advanced and powerful, a real resource for the power user of the Bourne shell, Shell Scripting Recipes is highly recommended.



2. Shell Scripting Recipes provides the reader with a handy reference for shell tasks that range from the common (how do I extract a portion of a string?) to the complex but sometimes entertaining (find words that fit together on a grid aka make your own crossword). The author does a great job in his layout by presenting the problem, listing the solution and then explaining how it works. The script solutions and examples are broken down by topic and each chapter is indexed on the side of the book for easy reference by the reader.
   
   The book was written for those who have had some Unix/Linux experience under their belt and now want to explore some of the power of the shell itself. Seasoned BASH shell users know that one of the most powerful aspects of the system is the ability to create applications that perform necessary tasks or functions just by using shell scripting. This book would be ideal for anyone who wants to get more out of their system that just using the GUI-interface that has become so common.
   
   Most of all, it covers a lot of problems that occur everyday and that we sometime spend hours looking for a solution for. Things such as removing excess linefeeds from a file, reformatting text, retrieving data automatically and other related tasks -- things that shell scripting excels at providing a mechanism to solve.
   
   Not for the beginner, but a must-have for the experienced Unix (particularly BASH shell) user.



3. This book was kind of an epiphany for me. I've been writing shell scripts for nearly as long as I've been writing programs, but I've always drawn a mental distinction between the two. There was programming, and then there was scripting.
   
   After coding in languages like Perl and then Ruby, the distinction has become increasingly blurred. Many of my "scripts" have proven far, far more useful than anything I've written in a "proper" programming language! They back up my servers, they keep me informed of problems, they've saved me a minute here, a minute there, for perhaps ten years now! So what, really, is the distinction?
   
   I think, to some extent, a shell script is ultimately just limited by a lack of any libraries of code. It lends itself well to simple tasks, but if you do anything even moderately complex, you have to stop and switch to Perl or Ruby. But now Mr. Johnson has written a book that more or less creates a library in your shell script. And the tasks he writes about are so incredibly common, and his recipes so well organized, that you can just flip to a chapter like "Backing Up the Drive" or "Good Housekeeping," and find a dozen solutions to questions you're guaranteed to run into when writing your shell scripts. This book also does an excellent job of showing examples that rely on as few external programs as possible - making them perfectly portable.
   
   This is the most useful book on shell scripting out there, and I wish I could have picked it up ten years ago. If I had, it would still be on my shelf today.



4. While the Bourne shell is listed as a full fledged programming language, few people use it like that. Some of it is that they prefer more commonly acknowledged languages like Perl, Python or the like. However, with a book like Shell Scripting Recipes: A Problem-Solution Approach, they'll want to thin twice about it.
   
   I remember my first forays into shell scripting. I didn't want to learn Perl (then the clearly dominant scripting language), and worked hard to learn shell, awk, and sed so that I could do the things I needed to do and automate as much as possible. It paid off, and even impressed a few die hard Perl fans. Less code to do simple tasks, faster to write, and always present. While I don't do nearly as much shell scripting as I used to, I still enjoy seeing someone do neat things in /bin/sh, ksh, or bash.
   
   Chris Johnson's book is in the traditional line of a reference book, much like the O'Reilly cookbook series or, more accurately, the old tome, UNIX Power Tools. It's got a couple of non-recipe chapters, and the rest of it is a lot of fun, useful shell scripting.
   
   Chapter 1 is an invaluable reference to large portions of the POSIX shell language. Johnson covers things like built in commands and program flow, special variables, and variable expansion. He also clearly covers the differences between the Bourne shell and the POSIX shell where they differ. If you're worried, using Bash will almost always work with the examples, I think.
   
   At this point it's easy to think, "I can call out to external commands for a good chunk of the functions he develops." You can, but Johnson makes a compelling argument that shows the impact of a fraction of a second can add up quickly in loops. At this point, you're either agreeing with him and seeing the joy of a direct language like shell or you soon will.
   
   Chapter 20 is a small set of recipes but they serve a different function, namely helping you manage all of these new shell scripts and functions. You can copy, instantiate new shell scripts more easily (by automating the redundant bits), or package them up with simple scripts. Handy tools, and a decent approach.
   
   The recipes run the gamut from the simple to the uncommon, but they all illustrate how do accomplish useful tasks in a shell script. They include file conversion (DOS, UNIX, and Mac), string handling bits, filename management, complex date calculations, screen control capabilities, and even HTML processing. Some of my favorite recipes include the Postscript generation tools (!) and the database management tools. While some people have done these in shell scripts, I've usually seen them done using sloppy or confusing approaches. Johnson's code is clear, direct, and applicable.
   
   That's probably the biggest strength to the book, Johnson's clear writing and examples. Some programming and scripting books try and show you neat tools to accomplish a task, but they don't do a good job of showing you how to translate it to your specific task. In Shell Scripting Recipes, Johnson chooses his code carefully, articulates how it works, and continually builds on a theme. If you pick a few scripts and study them, you'll see tips and tools you can use in your own shell scripts. He also has nicely abstracted scripts that let you recycle his functions in your own scripts with ease.
   
   Overall I quite like Shell Scripting Recipes, I think that while it's easy to think less of the Bourne shell as a language, Johnson has done a good job of writing a concise set of examples, usable code, and in a format that is continually useful and clear. If you've been thinking about improving your shell prowess, this is the book for you.



5. Useful. Good examples (but not for the absolute beginner). Korn shell users might want to also consider "Korn Shell: Programs for Your Survival at Work" by Larry L. Smith. Bash users might want to consider "Bash Shell: Programs for Your Survival at Work."

2 comments about Algorithms & Data Structures: The Science Of Computing (Electrical and Computer Engineering Series).

1. "Algorithms and Data Structures: The Science of Computing" is designed as a second course computer science textbook for colleges. At this level most computer sciences classes tend to focus on programming and programming theory. While it does have some programming examples (all in Java), this book takes a more overall view and deals with the basics of algorithms and data structures. Why is this an important difference? I have seen a lot of bloated code over the years where a programmer writes a hundred or more lines of code to do something that a couple of lines could do if they only had a better understanding of algorithms. This course gives you the conceptual knowledge you need to be able to adapt to other computer languages and coding techniques as they are developed.

   The book does make some assumptions about the reader. First, it assumes the reader has had an introductory course in an object-oriented programming language. As indicated earlier, all examples are in Java, but you should be able to follow along if you have had a course in any object-oriented language. Second, the book also assumes a good (but not necessarily college level) background in mathematics.

   This is a foundational course in the design of algorithms, and data structures and mathematical theory to predict and verify, as well as empirical analysis to test the results. "Algorithms and Data Structures: The Science of Computing" is a recommended book as a second course in a computer sciences degree as well as a foundational course for those who are trying to develop a broad basis of computer knowledge at home.




2. Algorithm and Algorithm design is a difficult topic to talk about or to learn. It is probably one of the most complex topics in the field of Computer Science and Mathematics, mostly due to its abstractness. Proof after proof, theory after theory, and complex mathematical expressions make the topic very difficult to grasp at times. The authors of Algorithms and Data Structures have taken this notion into account, and wrote this book in such a way that a Computer Science major student can relate popular programming and problems that we come across everyday to the notion of algorithm and complexity. The Java programming language is utilizes throughout the book, and the authors, D. Bladwin and G. W. Scragg, write pseudo-Java-code to demonstrate how, for example, various versions of the quicksort algorithm are coded. Programming is obviously not the focus of this book, but the code snippets are certainly a good teaching aid for the novice readers.
   
   The book starts off with the basic ground work surrounding algorithms: what is a proof? Computer Science, Mathematics and theory, etc.. It basically answers the question why anyone should bother learning about algorithms and the complexity that surrounds this topic. The authors then take a rather unique approach to the theory behind algorithms by discussing program recursion and iteration. It seems a little odd, but it turns out to be a very good way to introduce readers to topic algorithms. Recursions is a topic covered in CS1 courses, and using that as the basis and introduction to algorithm design and correctness proof really reels in the reader and makes the topic easier to grasp.
   
   After discussing algorithms basics, and showing the readers what algorithm efficiency, etc is, the authors take on the second part of the book which covers the data structures aspects of things. List, Queues, Stacks, Trees, etc... are all covered in detail. Algorithms that were discussed earlier in the text are applied to the data structures, and the complexity of each algorithm is actually depicted thru examples, pseudocode, and followed by its mathematical analysis. The text, in general, is focused around the concept of objects, abstract data types, and core object orientation techniques, and the presented material is targeted as such.
   
   Towards the end of the text, the authors give the readers a brief but concise overview what's to come. Topics such as complexity, the undecideability, nondeterminism and the surrounding problems such as the HALTing problem, the Traveling Salesman Problem, etc... are touched. The authors pose some very interesting questions for the readers in the context of the HALTing problem as it pertains to complier design. These problems in their general form are unsolvable, and the authors make a very good case on why we care about such problems and issues.
   
   In addition to being a very easy text read, the authors have filled each chapter with sample problems, examples, and techniques. For the second year computer science student, or a professional interested in the field of algorithm design and complexity analysis, I highly recommend reading this text.

5 comments about Win32 API Programming with Visual Basic.

1. First, this seems like mostly a C book, not a VB book as the title implies. Sure, the C structures and function call variables are usually provided w/translations (but not always!). And there is a whole chapter on VB strings. But I got the impression the author doesn't know a ton about VB and why a VB programmer might want/need to concern himself with the API function calls. This didn't phase me a ton because I know C, but I thought a lot of the text wasn't much about VB at all.

   First-and-a-half, the author is running Windows NT, so if you're like me and on Win 95/98 you may at times feel like you're being left out. He does go to some lengths to compare and point out the differences between the two OS's, but (again) I felt like he was a C/NT programmer rather than a VB/9x programmer.

   Second, even though the intro says its for both VB5 and VB6, I use the former and couldn't get the crucial examples on the CD to run without first hunting down and finding the needed DLL's on the I-Net one-by-one. This was a tedious process because after a program would clear past one error message on startup it'd hit the next one. And so on. This was a huge hassle. It probably didn't help that the one bad spot on my CD was the dll.readme file (maybe all this was pointed out in there) -- I probably should have taken the book back, but then I would have had to wait for them to order another one and for it to come in, go back a third time to get it, etc...

   Third, the book is not any sort of complete reference to the API functions. Some of the chapters only mention a couple of the functions relevant to the topic, or at least give you the feeling there's more out there that you might want to know about. The functions that are mentioned sometimes only have one or two of their parameters explained (as if the others don't matter). So if you're looking for an API reference book, this probably isn't it.

   At least most of the typos in the book can be found at O'Reilly's website, though a careful reader can find a couple that haven't been flagged.

   I expected a better book. At least the writing is clear.




2. This is an excellent book to learn about Windows from a developer's perspective. It has the most lucid explanations I've read on the Windows operating system, covering topics such as processes, threads, synchronization, memory architecture, Windows messages, DLL injection and device contexts. There is a whole chapter dedicated to strings where the author cleary explains ALL types of strings used in Windows (there are very few books that include this important topic). For those who complain about not enough coverage of the Win32 API, *READ THE PREFACE!*. The author states very clearly that the book is "...not intended to be an encyclopedia for the Win32 API...", the goal is to present "...enough information to get an overall feel for the Windows OS and the Win32 API...". I think he went beyond the stated goal. As for the reviewers complaining about the book heavy slant towards C, it escapes me how anyone would want to read about the Win32 API without expecting to find C all over the place. This is not a book to learn VB syntax or VB tricks, it's about how to interact with the Win32 API from VB, so it's important to learn the details about the API, not about VB. Last but not least, do not expect this to be a hardcore guide to Win32 programming, that's something you just can't do with VB.

   Added Dec 12, 2001: After studying the new .NET platform I realize that this book is sadly outdated. You can still use the Win32 API in VB.NET, but there's no good reason to do that anymore because the .NET framework provides equivalents for just about every API call you can think of, and more.




3. This is a very hard book (for VB programmer with no C experience) BY NECESSITY.
   Normally, you would like the programming book to have some explanation and plenty of code examples. In the case of Win32 API
   for VB programmer, once you get all the intricacies, you just need to find the API function from API viewer applet that comes with Visual Studio.
   Why is the book hard by necessity?
   C and VB have enough differences (e.g. variable type size differences, signed and unsigned type differences etc) to make the interoperability of languages difficult. Add to this the complexity of the Windows architecture itself and C + VB + WIN32
   becomes much more complex, than just C + Win32, which makes me wonder, why use VB at all, if you are planning to make an extensive use of WIN32. Much easier to code in C or C++!
   Back to the book.
   It does excellent job explaining C + VB + Win32 API interaction
   thoroughly. He leaves no stone unturned. If you absorb the book cover to cover, you can consider yourself guru in the area.
   You want need anything else than API function declarations.
   In short, this is a book for ONLY DEDICATED, serious programmer, intending not just to spice up his code with occasional API calls, but ending up with FULL UNDERSTANDING OF ALL ISSUES.



4. This book in no way is a reference book or a how-to book. This book is designed for people who don't have previous knowledge about windows architecture and windows API.

   I find this book as a fantastic tool since it gives me initiative and direction to understand the overall picture. I can use the knowledge that I gained in this book and know what I can do with win32 API. I also purchased the dan appleman's book for win32 api which consists of more examples and it is more a reference book .

   If you have not programmed in win32 before --> this is the book for you.




5. I would beware of ordering this through Amazon. I have had to return this book after several attempts of getting the order right. They keep sending me the book without the CD-Rom.. yet the cover and their site states one is included.

5 comments about Sams Teach Yourself Microsoft Visual Basic .NET 2003 in 24 Hours Complete Starter Kit (Sams Teach Yourself).

1. Great beginner book - incorporates a bit a humor throughout to keep things interesting. Nice book to transition from VBA to VB .NET.
   Errata is posted on authors page as well as user forum.
   
   The book also acclimates you to the Visual Studio IDE very well.



2. This is an excellent book and Yes, you can learn to program in Visual Basic.Net in 24 hours. This book gives you the details the other books leave out. The book flows well and builds a solid foundation. This is better then the college text I am using for VB.Net. Buy it, you won't be sorry!



3. The title could rather be given as sams teach yourself VB.NET "for" 8 hours....All what has been presented here can be mastered in just 8 hours. This book lacks essence in conveying the concepts. It does not also cover all parts of VB.NET. The author could have dedicated some more topics on ADO.NET and database programming.
   This book sounds good to novices in VB.NET but a money waste for experienced programmers.



4. I have had many years in IT. I wanted to understand what .net was about and VB (.net) to get through the brochure speak and be able to manage developments in the .net environment effectively.
   
   This book was excellent.
   
   Taking each lesson in turn, the pace and instruction was clear and exact. At the end of the 24 hours I more than satsified my aims. I now have a good grounding in vb.net and understand the .net environment much better.
   
   Well done to James Foxall



5. This book is so well written, if you are just starting out with VB, then this book is a must. Where my tutor does not make sense, James Foxall does. James you are a genius, Thank you.
   
   So this book is a must, you don't need to think about it, just buy it.

5 comments about Data Crunching: Solve Everyday Problems Using Java, Python, and more..

1. Gregory Wilson likes Python and bash but doesn't particularly care for XSLT (or Perl, and possibly Java as well, either), doesn't express a preference in the great Emacs vs. Vi(m) holy war, and divides programming languages into two camps - agile, like Python and Ruby, and "sturdy", like Java. He's an adjunct CS professor at the University of Toronto, a contributing editor with Dr. Dobb's Journal, and is developing "Software Carpentry", which is either a basic course on software development aimed at scientists and engineers for the Python Software Foundation or a project to develop a newer, easier-to-use set of software development tools.
   
   In the book, "Data Crunching: Solve Everyday Problems Using Java, Python, and More", data crunching is explored through a series of examples. The closest that Wilson comes to giving a definition is when, at the start of the first chapter, he refers to data crunching/munging as the "other 10%" of a programming task that takes up the "other 90% of the time". The first example that he gives is his experience helping a high school science teacher convert PDB (Protein Data Bank) files containing the coordinates of atoms in various molecules into a format that a Fortran sphere-drawing program could process.
   
   From the introduction, he moves on to the manipulation of text and text files using Unix command-line tools and Python, with Java work-alikes following most of the Python scripts. Although the book's subtitle, "Solve Everyday Problems Using Java, Python, and More", gives Java first billing (possibly for marketing reasons?), Wilson's preference for Python over Java is never in doubt. After presenting the Java equivalent of a Python script that counts the number of times every email address appears in a list of email addresses, he writes:
   
   All right. It's two-and-a-half times longer than the equivalent Python program, it isn't as fast on small files, and we have to compile it before we can run it, but other than that, it's almost as easy...
   
   With a table of useful commands, explanation of redirection and piping, and some guidelines on how to make sure that your command-line tools follow convention, the text chapter could actually be viewed as a pretty passable introduction to the philosophy of Unix.
   
   The chapter on Regular Expressions is great. So good, in fact, that I wish I could go back in time and give myself a photocopy of those thirty-odd pages at the point that I was struggling to get a handle on RE's some years back. Also included in this chapter is a brief, but very lucid, discussion of character encoding and a bit on using grep.
   
   Although the Text and RE chapters were my favorite, Wilson's clear and concise writing style makes th eentire book, including the coverage of XML, binary data processing, and relational databases, a joy to read. With segues like "But wait a second. Wait just one pattern-matching second.", lists of email addresses to munge that include entries for Alan Turning, John von Neumann, and Grace Hopper, and the like, he also manages to inject some pleasant, if a bit groan-worthy, humor here and there into what could otherwise be a rather dry book.
   
   He uses the last chapter, titled "Horshoe Nails" to quickly address a number topics, like encoding, the pitfalls of floating point arithmatic, and unit testing, which (not a surprise in a title coming from the Pragmatic Bookshelf) he likes, going so far as to say that the spread of test-driven development has been the "real revolution in programming in the last decade"). Diff is introduced and he brings the venerable make to the table as a tool for automating test running.
   
   He doesn't say it in so many words, though his retooling the old saying that "two years of hard work can save you an hour in the library" as "an hour of hard work can often save you sixty seconds on Google" comes close, but the message is to work smarter rather than harder. Use industrial-strength tools and processes when industrial-strength solutions are called for and agile, simplest-things-that-work solutions whenever possible.



2. Data Crunching by Greg Wilson.
   
   The book opens with a statement of purpose: transmuting data from one form into another. The focus is on problems where the hardest part is extracting the data, not problems where the hard part is processing it. Simple transformations and data grazing, rather than data mining, as the ideal problem for these techniques is small, separable, and useful in a variety of contexts.
   
   Major book sections include: Text, Regular Expressions, XML, Binary Data, Relational Databases, and a twenty page miscellaneous section. As usual for Pragmatic Programmer's books, the text is short, coming out at 187 pages, with source code on the web site. That regular expressions come up pretty much immediately tells us that the text will be unix-heavy. Not a bad thing, really, as a few simple unix tools can often save hours of anguish.
   
   Introduction:
   
   The introduction is clear on the intended audience. Read the nine pages, and you have a darn good idea whether the book is worth reading for your tasks. Among other things, the tools he strongly suggests installing - Python, Java, a command line xslt processor, a relational database, and unix command line tools - make it clear the level of this effort. No GUIs, no complicated database reverse engineering tools. Note also, no Perl. (For me, a bonus, but a deal killer for some.)
   
   Text:
   
   Early in the text chapter, the author spends some time examining a data file, then writing out the result. He makes a point of looking up a spec, then ignoring most of it. The YAGNI (You Will Not Need It, for grammarians) says that detailed interpretation of the spec is not as important as carefully making sure it reads the files you actually have to process. After all, your files may be misformatted, or may only use a small fraction of the specification. His example showed that three iterations through some samples got him just about everything he needed, in a very short time. He looked at the input file spec to see if there were corner cases he would need to solve, then focussed on the actual conversion he wanted to make. This theme recurs often - simple data cruncher programs need to be correct, but they do not have the same needs as a general data parsing tool. Do not try to solve every conceivable problem, try to solve the one you actually have.
   
   Interestingly, the author lumps Python, Ruby, and Java on one side, and Perl/C++ on another as far as 'thought collisions' go. Examples thus far include both Python and Java, with more Python than anything else. The Java examples are 1.2+ - using Java 1.5's autoboxing would have simplified several examples to roughly the Python complexity.
   
   The author is not sloppy, but he does take judicious shortcuts. Trimming a file extension in python, he uses a hardcoded three character extension, rather than the more correct .splitExt(). He then mentions that the more correct function required an extra library include, which would have cluttered the text. (The text does mention the more correct function in a sidebar.) A page later, he points out the perils of repeating yourself, and the kinds of errors it can produce. In other words, a bad file extension is likely to cause a visible failure early, while repeated code can lead to subtle bugs. This kind of tradeoff comes up a lot when coding; I was glad to see him make a point of it.
   
   Regular expressions:
   
   Regular expressions are, to my mind, one of the more convoluted topics that programmers encounter on a regular basis. Getting a deep understanding is worthy of a book in itself, and using Perl or Ruby properly _requires_ that understanding. Java now has regex support, though python's is easier to use. He references the standard book on the topic.
   
   The author tries to cover the 10% of the topic that you will regularly use. This will not turn you into an RE-master ready to tackle any Perl you happen to see, but it will be enough for the tasks he is describing. He spent quite some time describing character encoding, Unicode, ISO Latin-1, and the like, which was a welcome surprise.
   
   I note further that not a single Perl example showed up in the RE chapter. Many Python excerpts, some Java excerpts, a lonely-looking Ruby script, but no Perl. Made me happy, but this might infuriate a Perl aficionado.
   
   XML:
   
   The XML chapter goes into a great deal of detail on SAX. The author compares SAX responders to GUI event responders, which felt a bit strained. Most GUI responders do not hove quite the order dependency that SAX responders do. That said, the introduction was clear, and the limitations were explicit. While he did discuss the need to keep state, the discussion came later than I liked.
   
   The DOM section wisely uses language-specific APIs, like Java's JDOM and Python's minidom. I find tree-based APIs more useful than stream APIs in general, and this was a good, if brief, introduction to my most commonly used XML API.
   
   The XPath section is also brief, but clear. Much like the DOM section, the author mentions language-specific APIs. Since many DOM-like APIs have an XPath module, even programmers not planning on doing much with XML will still find it useful. The author draws a paralell to regular expressions - a rich, dense language that can select small pieces out of a large mass of data.
   
   Since I find XSLT a Martian space language, despite having used it heavily for several projects, I was pleased that the author's impression of it matched my own: "I don't really like XSLT that much". The introduction is clearly written, but unlike the other technologies, an introduction does not provide enough meat to accomplish a real problem.
   
   Binary Data:
   
   My rules of binary data: do not use it if you can use text, and if you must, try to find a library. This chapter mentions that on the second page.
   
   The 19 pages of this section cover binary integer representations, string representations, bit shifting, designing self-contained comprehensible binary data formats, and packing as much data per byte as you can. The author did not mention recognizing and parsing gzipped textual data, but other that that, this chapter had a good collection of useful ideas. I have found text, xml, and databases to be more important in my work, but binary files do come up. This chapter reminded my why I always get a sinking feeling when they do.
   
   Relational databases:
   
   This 30 page section gives a good introduction to the practice of SQL databases, using sqlite as the engine. Simple joins and normalizing tables showed up by the fifth page of the chapter. Between aliases, nesting, and negation, the author claims that you should be able to do perhaps 90% of the queries you will need. I rather agree - with the caveat that you do need to understand left and right, inner and outer joins, which are not covered. (They are footnoted to a reference, so expect to snag a good SQL book.)
   
   After joins, the chapter covers aggregation functions, views, and nulls. I give the author credit for bringing up the "Does NULL mean not present, or does it mean unknown" war. Most books take one side or another as gospel, or do not bring it up at all.
   
   A section on creating tables, inserting/updating data, deleting data and tables, and transactions follows. The examples are typical, and appropriate for simple CRUD apps, like many web apps. The author points out that data crunching is far more likely to involve selection than complicated create/update/delete logic.
   
   Finally, the author covers using SQL from python and from Java/JDBC. He also described the impedance mismatch between object oriented programming and the relational model. Wisely, he suggests well tested packages to handle that. I note that the vast majority of my sql has either been in scripts to set up test data or when I was writing an Object-Relational Mapping tool. The vast majority of my code that accesses databases uses well tested ORM packages like Hibernate. (I might have brought Hibernate up earlier in the chapter. Then again, for this book's target audience, perhaps not.)
   
   Odds and Ends:
   
   The final chapter has 19 pages on a variety of tools. The unit testing section discusses JUnit, Make, diff, and TDD. The encoding section discusses HTML escapes, base 64, and others. The section on floating point arithmetic answers the basic questions seen daily on Java discussion lists. Date parsing is discussed in sufficient detail, though I might have added an extra sidebar on just how bad Java's date handling can be. I have little to say about this section, save that it is worth the read.
   
   Final Thoughts:
   
   All in all, this book was well written, well proofed, and well designed. Like all Pragmatic books, it is available as both a downloadable PDF and a bound book. Errata and updates live on the Pragmatic web site. This is an extremely keen system - dead tree form for reading on a plane, PDF form for early access and up to date information.



3. The book presents the topics in conjunction with showing some practical data mining examples that any person might encounter. This book is recommended to people who are interested in basic parsing of data (text, XML, binary, etc) using python.
   
   I got the impression that the author was trying to cover too much in too little space. The title, for example, mentions Java, Python, and more. This is deceiving since the book uses python for about 99% of its examples. And while the book does present Java, it only does so to show that it would be easier to use python. Almost no other languages are covered, although there are some examples in Ruby and Bash.



4. This book is mainly concerned with scripting as a 'glue' between applications: processing various input and output formats. The book is divided into 5 main categories of data handling: plain text, regular expressions, XML, binary data and SQL. There is a final chapter on various miscellaneous topics. Most of the examples are given in Python. Some of the code is demonstrated in Java, although, disappointingly for a book published in 2005, none of the Java 5.0 features are leveraged. However, if nothing else, it demonstrates why Java is not anyone's first choice for such activities.
   
   If you've read any of the O'Reilly cookbook series, you will know what to expect, although the chapters are more cohesive and less episodic. Beginning programmers will get the most out of this book, although intermediate programmers should find at least some material here that's new to them.
   
   The XML chapter is a pretty good introduction the use and advantages/disadvantages of SAX and DOM, and XSLT is also described, although the discussion is not so clear. Those without experience with databases will welcome the chapter on SQL. The discussion on dealing with plain text files in chapter 1 was highlight for me, a subject not often covered in much depth in cookbooks; if, like me, you still regularly need to convert between various plain text formats, this chapter will help formalise approaches that you may already be carrying out in a less than rigorous fashion.
   
   Additionally, the paragraphs on floating point arithmetic were intriguing but all too brief. The chapter on dealing with binary is fairly good, although rather dry. Peter Seibel's discussion of binary data in the context of writing a Shoutcast server in Practical Common Lisp shows that the subject can be dealt with in a more compelling fashion. That said, for the most part, author Greg Wilson is a genial companion; the writing style is chatty, but doesn't overdo it.
   
   Overall, if you own any cookbook-style books, there is little here that you don't already know. Even for a beginner, it's hard to see how anyone who decides they need this book hasn't already been exposed to some of the material here. In particular, does anyone really need yet another introduction to regular expressions? The treatment here isn't bad, it's just that this material is already covered in many introductory programming books (especially those that cover scripting languages like Perl and Python). As this takes up nearly 20% of the book, and there's less than 200 pages, it's a bit of a waste. Personally, I would have preferred more discussion of the less well-treated subjects, some of which are too sparsely described, but this would have detracted from the book's main aim.
   
   This would be suitable for a beginner Pythonista, who for some reason didn't want the bulk of the likes of Python Cookbook. Otherwise, if you feel that some Pragmatic Programmers books can be rather lightweight and somewhat overpriced, this will not change your mind.



5. Some of the best technical books are short, clear, easy to understand, and practical. Greg's book falls into this description. This a great book for exploring algorithms in the python language. The book assumes the reader has at least a basic understanding of the python programming language or some programming experience. I was delighted that topics were presented in a concise and unambigous way and that the book was short. There should be more short books published!

2 comments about SugarCRM Developer's Manual: Customize and extend SugarCRM.

1. There is little here that can't be derived from a review of the online sugar documents and a little self-motivated tinkering. Its hard to believe that this book is the result of something other than just that. Based on how much additional information is available here that's not in the public domain, the $49.99 is a little hard to believe.
   
   While the text goes at 269 pages, there's really about 30-40 pages of actual beef here. I was able to condense all of one chapter into 5 lines on a wiki page. Fully 60 pages of this book are un-annotated schema definitions of the sugar database; a waste of paper that verges on criminal. This information is readily available and in a more usable format through the phpMyAdmin tool that is bundled with the Sugar installer. Reprinting it here seems to serve no other purpose than to increase this books heft; and thereby its saleability.
   
   Completely missing is information on what a sugar customizer might actually find difficult, like debugging sugar when something goes wrong, linking custom modules with existing modules (like notes), or adding custom columns to advanced search screens.



2. Note: this book addresses versions 4.5 and below. I'm finding out that things are a bit different in the version 5 beta, so the utility of this book is greatly reduced.
   
   As a point of reference, I have about 10 years of PHP experience. I have used the PEAR and Smarty libraries extensively. I was drawn to SugarCRM based on my familiarity with those libraries and the fact that SugarCRM uses them, to some extent. I bought this book because it was the only game in town that addressed custom module creation.
   
   The book begins with customizing the interface via SugarCRM Studio. It progresses to the creation of custom modules, with a pretty large section in the middle on database diagrams, as noted above. The meat of this book, in my opinion, was in chapters 8 and 9 (the last 2 chapters). Bain explains how to set up and edit the files to create your own basic module and workflow in them.
   
   My main complaint is that Bain doesn't adequately explain the interaction with other modules, ACL for example, which in my opinion is one of the more important ones.
   
   In Bain's defense, SugarCRM is a very complicated web application. Try doing a print_r($GLOBALS) and you'll see what I mean. On an example page, that one line of code resulted in over 15,000 lines of output.
   
   The newest version of SugarCRM has a Module Builder (MB) component that will automatically create the files for you, as well as the database tables. If you're using v5, you're probably better off using the MB and examining the files.
   
   The only other option is to use the wiki (spotty) and the official documentation (inadequate). I'm hoping the people at Sugar put out their own reference book, and the sooner the better!!!

5 comments about Visual Basic for Testers.

1. This book is long overdue for too long QA resources have been limited by others and themsleves to not look under the bonnet, so to speak or have payed for inflexible third party tools to do a simple job. I have developed entire smart'newbie' QA technical teams that just couldn't believe how easy it was to use code to test an application. It also adds to there skill set, gets them to really think 'how' best to test the application from a code point of view and even improves their test cases.

   Mary Sweeney's book "Visual Basic for Testers" is the starting point for any Manager who wants to do the same and give his/her team that extra weapon for finding issues.




2. This book is really a primer on Visual Basic for someone who has never programmed before. Testing is just an afterthought.
   If you're a developer trying to improve processes through testing this book is not for you.

   If you're a software tester who knows absolutely nothing about programming, nice to meet you, I didn't know you existed, take a look at this book.




3. I've had several college-level courses now in Testing and this is the only book we used that actually had anything to do with testing and programming. This is an absolute essential text for a college curriculum in testing. I checked out several curricula and found that most of them use it. I wonder about those that don't. In our course we also explored the use of .Net for testing and in my opinion it's a lot easier, more clear and way less expensive to use the techniques in this book. If you're trying to learn it on your own, this is still a good book. It's got exercises and examples.

   My wife's been a tester for many years but didn't do programming and she loved it. She said it gave her a lot of ideas. Maybe if you've already been an automated tester and/or developer for many years, this book isn't going to help, since it has a lot of basics. But if you are trying to learn, where else would you go? I liked the way you could just sit down and read it from cover to cover. It's unpretentious and doesn't talk down to us. It does expect you already know testing terminology and basics, but before you read this, you should.




4. This book is exactly what the title says: an introduction to Visual Basic for testers. It succeeds wonderfully at that.
   It is not a book about testing. If you already know VB and want to know how to test your application, there are a few chapters near the end that you will find useful but this book is not really intended for you.



5. This book neither teaches Software Testing nor programming. And is intented for VB related Programmers/testers who know some VB and Testing. There was a possibility of being little more specific, I mean the early chapters of the book talk about VB projects, creating them and the very basic information about IDE rather than testing. There could have been a possibility of taking up a real project implementation, lets say testing/automating the entire MS Office testing using VB.
   But again, this has been a very serious effort for automation and deserves a lot of appreciation.
   
   Abhinav Vaid