5 comments about The Definitive Guide to Interwoven TeamSite (Definitive Guides).

1. First let me say that I have never seen a formalized methodology such as the Rational Unified Process wrapped into a book on Content Management, let alone such a title demonstrate how to incorporate those practices into CMS work. I found this to be a novel concept and one that I feel will add a lot of value to my future projects. The authors share their expertise, not only with technical TeamSite implementations details, but also with some softer skills related to everyday IT/CMS life ( i.e., project management, requirements management, project deployment, and marketing). The book is broken up logically enough into sections which map to the specific RUP phase being discussed. Detailed coverage is given to TeamSite 6.5, with some additional coverage of TeamSite 6.7. Most of the Interwoven products are discussed, explaining why certain products could be selected, what their purpose is, and the value that they may add to an implementation. The authors also provide coverage of how to define a taxonomy in MetaTagger, using OpenDeploy and DataDeploy, using LiveSite, TeamSite Front Office, TeamSite Search, as well as extremely handy FormAPI and FormsPublisher references. Thank you and well done!



2. It is not easy to give an overview of the TeamSite product line in 537 pages, but Hastings and McNeal do an admirable job of covering project methodology, an overview of the entire TeamSite product line, and a deep dive into TeamSite templating and workflow.
   
   This is certainly not everything there is to know. TeamSite is an almost infinitely configurable product, but you will not find as good an overview and introduction to TeamSite as this book. And that is not just because this is the only book on TeamSite out there; you won't find this kind of overview in Interwoven's manuals or Training materials either.
   
   I highly recommend this book now, but if it comes out in an expanded second edition for a little less money it will be a no brainer.



3. This book leaves out allot. Good luck trying to get some of the examples to work. Many of the files are missing. It seems like the main objective of the book is to make a dollar since there are not allot of books on the topic outside of the Interwoven community.
   
   An example of the poor quality of the book is in Chapter 16. The book talks about navigation and says it will go into more detail in chapter 15. However you are already in Chapter 16 and 15 is actually about workflows.
   
   The reality is if you are implementing Interwoven CMS you need to buck up and take their developers series class. If you already know how to program you will be fine. If you try to use this book as a resources it is pretty much worthless.
   
   Save your money and join the devnet community it's free and way more helpful.



4. The book is fairly helpful, and did bring to light a few new ways of thinking about interwoven. However, many of the examples seem to be incomplete and only scratch the surface, leaving the reader needing/wanting more information.



5. You have to understand first that I "grew up" in content management systems with "Joomla!," which is an open-source, fully-integrated application that gives you one pilot seat from which to build your web site. (www.joomla.org) With Joomla!, you create your information architecture, add in components, and pick out a template, and you have a fully-functioning web site in no time. You don't have the versioning and audit trails of other cms tools, but you have a whiz-bang web site that's easy to manage and incredibly extensible. Now faced with implementing TeamSite, I just can't believe that anyone would choose this behemoth over Joomla!. Nevertheless, the question that NO ONE can answer for me, not Interwoven and certainly not the "definitive guide," is "How do you actually build a web site with it?" It seems that Interwoven and this book assume that you have teams of programmers who have always built all their sites one file at a time. They start from scratch and script their little hearts out. This book may explain the installation and general templating procedures of TeamSite, but it doesn't explain the general approach to building a web site with it. There are many, many gaps, and it's not very helpful for non-programmers or first-time CMS builders. So, if you're buying this book as a pre-purchase decision, I'd suggest looking at Joomla!--chances are, you'll be happier with it, and it's free.

5 comments about Project Retrospectives: A Handbook for Team Reviews.

1. "Project Retrospectives" is one of the best written, best edited, most nicely presented, and most useful software books I've ever read. Norm Kerth presents a convincing argument for the value of taking the time to study past projects and learn from them. He then presents a rich tool kit of techniques for helping a project team explore what actually happened, what went well, what caused problems, and what happened that surprised them. Kerth's sensitivity to the complex interpersonal issues surrounding project retrospectives will help any facilitator, participant, or manager get the most out of these important learning activities.

   Despite the value of retrospectives, not every project team will find it possible to spend 2 or 3 full days reflecting on its experience. However, the methods described here can be scaled down so that any team can apply them. If a team doesn't take the time to learn how to improve, it shouldn't expect the next project to go any better than the last one. This unique book is a key enabler for any learning organization.




2. This book is intended as a manual for software developers intending to hold a project retrospective at the end of a large project. A retrospective is a little like a post-mortem. Much is learned during the course of a large project, and a project retrospective is a way to preserve that knowledge for use in later projects.

   A retrospective is different than a post-mortem in that a post-mortem sometimes implies that the project was a failure. Kerth makes it clear that as long as knowledge is gained from mistakes made, and that steps are taken to avoid the repetition of those mistakes, then no mistake is a total failure.

   Much of what Kerth writes about involves the tools and techniques of a facilitator. A facilitator is something like a psychotherapist for project teams. The facilitator's purpose is to get the members of the team, who sometimes do not work closely together either out of circumstance or preference, to share their opinions and observations about different aspects of the project in a non-threatening way.

   A facilitator must be an excellent communicator and should not offer his or her own opinion, only help others to express their own. In Kerth's opinion, much of what makes a project successful involves interpersonal communication and through a project retrospective a facilitator can help a project team improve their communication skills.

   I felt that the book offered some excellent suggestions. In particular, I liked Kerth's suggestions for illustrating to management of the value of a project retrospective. He provides an excellent checklist for preparing a proposal to management.

   I also liked his suggestions for demonstrating to project teammembers the value of failure. One suggestion is to have everyone watch a movie that involves project management, such as Kerth's favorite, Flight of the Phoenix. Another of Kerth's suggestions is to discuss the explosion of the space shuttle Challenger. Kerth suggests pointing out how the fact that four of the five books written on the explosion are oriented toward children shows how our culture shuns failure, and then discussing how analyzing the causes of the explosion helped NASA prevent similar accidents in the future.

   The book is intended for those intent on performing in-depth project retrospectives or project post-mortems. Much of the book consists of specific tips and techniques for those facilitating retrospectives. If I have a criticism of the book it is that much of the book is at a very practical level and that too little time is spent discussing how to make use of information garnered from project retrospectives in future projects.




3. Project Retrospectives is a must have for anyone who wants(or needs)to understand what happened on their last project. If you plan to conduct a retrospective, the book will show you how with exercises to use with your group. Even if you do not run formal retrospectives, the techniques in this book will help you get a more candid view of how things on your project work.



4. Norman L. Kerth is a professional with twenty years' experience in leading project retrospectives. In Project Retrospectives: A Handbook For Team Reviews, Kerth draws upon his extensive body of experience and expertise to crate an excellent and thoroughly "reader friendly" guidebook showcasing the process of reviewing, and revealing how to learn from the successes and failures of completed business projects. Case studies, preparing for a retrospective, leading a postmortem, and the skills for best learning and sharing knowledge gained from past ventures fill the pages of this down-to-earth and highly accessible guide which is especially recommended to those charged with the responsibility of improving corporate departmental and project team performances.



5. Norm Kerth's book introduces the retrospective ritual and a very good description on how and why to do them. Since published, Norm's book has become a mus-read in the field of software and I predict this will stay that way for quite a while.
   
   Project Retrospectives are review and improvement sessions which the project team does at the end of a project. A typical project retrospective takes a couple of days. During these days, there are a bunch of retrospective exercises which can be follows (and are described in the book). These exercises create a safe environment, help the project team remember the past and help them learn from it. An retrospective is not done properly if it doesn't also result in some improvement actions.
   
   I've used Norm's exercises in my own retrospectives and they work exceptionally well. This book is therefore a treasure of practical advise. If you feel uncomfortable when reading the first description (as some exercises might), try not to discard the exercise, but try it out. Often you will learn and find that they work surprisingly good.
   
   In the world of Agile Development, retrospectives have become an essential part of any agile method. These retrospectives are iteration retrospectives (or heartbeat retrospectives). They are shorter, but the ideas are the same. Much of Norm's exercises can also be used in that context.
   
   As mentioned earlier, a must read for anyone serious in product development.

5 comments about Pro ASP.NET 2.0 in VB 2005 (Expert's Voice in .Net).

1. I was looking for a solid, comprehensive, yet approachable ASP.NET 2.0 book for a long time when I stumbled across Pro ASP.NET 2.0. I flipped through it and quickly realized that it is both the learning and reference tool I was wanting. Since getting the book, I have not swayed from that position. This book is a great way to get started and to keep going in your ASP.NET development efforts.
   
   Although large (it weighs in at over 1200 pages), it is well organized and easily accessible. The material builds on itself in such a way that you don't need to read the first 900 pages to effectively use the later chapters. Additionally, the content is organized in a practical approach so you can get started relatively quickly. I find this technique helpful in that it I have more information when it comes time to answer specific questions. I never found myself "wishing" I know more in order to understand a concept.
   
   On the down-side, there are some glaring typographical errors throughout the text. It is pretty obvious in some places that there is a copy/paste error from the C# version to the VB version. None of the errata detracts from the book for me. In fact, in some cases, the little research I did to clarify something actually helped.
   
   All told, I have and continue to highly recommend this book to colleagues and clients alike. It is both an excellent learning tool and a great reference. The fact that one person wrote the entire text and in two programming languages amazes me. The author has an easy writing style that promotes absorbing the information quickly. I anticipate this book becoming tattered quite quickly!



2. I am very pleased with this book. After a couple of failed attempts to find a good ASP.NET 2.0 book I finally found this book. They really did a great job at covering a vast quantity of topics with enough substance that one can actually understand and apply to real life programming situations.
   
   There are some typographical errors and very few examples that don't work but in sight of the great volume of information and examples given, I'd say it is acceptable.
   
   I think I hit a jackpot with this book and I am looking for other books by the same authors that cover more specific topics and I doubt I'll be disappointed.



3. Although this book is only an introduction, the structure and depth are more than fine. After all, to discuss every single thing ASP.NET 2.0 has to offer would require several volume of HUGE books. I would suggest this book to anyone wants to learn ASP.NET 2.0, even with background other than VB.
   
   To the authors, you did a great job!!!



4. I have bought several other books on 2.0 and wish I had discoverd this one first. In each of the different categories, this book is written in order and style to learn and use as a reference. For me, a person with vb6 and asp classic experience this one hit the nail on the head.



5. I am reading this book now for some time. I have worked through the first 5 chapters and I am now in middle of the sixth. The content might be pretty accurate and maybe even comprehensive but there are 4 MAJOR problems which overshadow anything else. They are what I wrote in the title:
   
   A) MISSING: The author almost never starts by stating "add a new class and name it whatever" or "add three textboxes and one label". just throws you something like "heres the complete code" now from the snapshot i am able to figure out how he named the webform, which controls did he add how he named those controls etc. the source code on the Apress site is a must, cuz otherwise you'll be guessing you're head off on every page. Every 2 minutes I'm asking myself:
   should i add a module now? no? maybe soon?
   is this a new namespace?
   do i add that to the previous web form? or is it a replacement?
   is that a table, or div tags?
   other than that he also usually forgets to tell you when a namespace needs to be "imports"ed. probably to leave a challenge to the user why the editor is underlining all the object types.
   
   B) INCONSISTENT: most snippets of code that are more than a few lines will always have some naming conflicts. in line 1 the button is name cmdSave in line 10 it might be cmdSubmit. I mean this didn't happen once or twice it is a constant problem. As i type, i'm indebted to the VB editor in VWD for cathing these booboos.
   
   C) OVERDONE: this might not be a real problem. but as i am not yet such a seasoned ASP.NET 2.0 developer, i find reading pages upon pages of Http pipelines, ASP.NET providers, multiple comparison charts of State management options and custom tracing capabilities before even teaching how to put up a simple data-driven website with simple user and group options, extremely overdone and over comprehensive. if the author wanted to show how much he knows about asp.net 2.0 he could have done so in the preface.
   
   D) THEORETICAL: Everything taught is immediately followed by some code snippet which you could try and figure out where to plug it in and see if it works. he never (so far) builds upon something already done. I am now in the sixth chapter and have a mumble-jumble of techniques to accomplish a variety of odd and end functionality. I haven't the slightest idea of how to build a real world site.
   
   Again, I'm in the sixth chapter only. I'm still hoping to find some useful information in the remaining ones. Just felt I should let people know about it to save them from aggravation.

5 comments about Hunting Security Bugs.

1. I first have to admit to some bias - I wrote the forward, and work down the hall from Tom and Lawrence. So you may want to just read it yourself and see!
   
   These guys really know their stuff. While few people have the fiendish mindset that the authors bring to finding security bugs, the techniques that they lay out in this book will help anyone get very close to the same results.
   
   I've been wanting a book that helps testers as much as Writing Secure Code has helped developers, and it's finally here.



2. If you are looking for a great book to start / or to enhance your library on security this is the book. I was looking for a book that brought depth to the subject but didn't assume that I was an expert already. When I browsed this one in the bookstore, I was impressed that it started off with how you should think about testing your application and what the difference is when it comes to security testing. Funny thing now is that when ever I encounter a situation I think about how vulnerable. Believe me, thats pretty scary.
   
   The authors proceeded to give a logical path for working toward looking at all the areas where an application might be open to an attack. The authors uses thread models to help flush out the design of an application and explains why they are valuable and how to use them. They then get into looking at entry points and point out areas where you might not realize that you have one. They continue with a discussion on how a malicious client and server could be use to comprise your security. Next they cover ways that someone could fool the user into giving up information such as with spoofing and information disclosure, They then get into discussions about techniques such as buffer overflows, stack and heap manipulation, format string attack and script attacks including XML issues. Along with this you'll find information on permissions, areas for denial of services as well as ActiveX attacks. Finally, you find a very good checklist for doing a systematic approach to checking your security. The topics are well written and provide plenty of examples as well as thoughts about how to deal with the topic.
   
   Even if you don't read every chapter there is plenty of information for any particular area that you are interested in. It makes a great book to have on your shelve when you need to brush up or learn about a particular topic.
   
   After reading the book, I contacted one of the authors and asked him to present to my team. Yes, I work at the same company but that didn't influence my decision to buy the book especially since it was my own money going to purchase the book. He consented to giving us a presentation and his talk has inspired my entire team to ask for a copy of his book. Being that I had already read about half of it, I knew what he was talking about so it reinforced my opinion of the book. I would say that is a pretty good indication of how good the book is when an entire team asked for a copy.
   
   You won't be sorry if you purchase this book.



3. As with other reviewers of the book: in an attempt at full disclosure, I also work at Microsoft. I am a Test Lead in the Office organization.
   
   One of the challenges that faces any quality assurance engineer or Test engineer, or whatever our industry has chosen to call us this year is that we are constantly tasked with trying to "test in security" or "find the flaws in the product" after it has already been coded. While this is clearly a PART of our jobs, it is by no means the most important part. This book addresses what I consider to be a much higher priority for the Test Org generally, and Test Engineers specifically: helping reduce security vulnerabilities before they are coded into the product to begin with: as features are being spec'd and as code is being designed.
   This book is not a simple check-list testers can use to say "Yes, my feature is secure, Ship It". Rather, it helps place Test into the frame of mind of a hacker, it gives test a set of tools to help find security issues, it outlines an approach to software Test that will cause fewer security issues to be coded at all, let alone have to be fixed post code-complete (or in a Service Pack). Used in conjunction with other test books like _How to Break Software Security_ by James A. Whittaker, this book will help ship more secure products.
   Incidentally, I expect hackers will be reading this book in an effort to better understand the science of hunting security bugs, as well as the tools we use to do so - so if you're not using it, I'd expect your attackers will be thankful...



4. Beside Bruce Schneier books, this is the second software security book that I am reading. The first being Building Secure Software: How to Avoid Security Problems the Right Way and I have prefered this one because it provides more concrete examples. The book consists of over 20 chapters covering different security areas. As a software developer, some chapters appeared less relevent and less interesting to me and I guess that it is because these chapters are geared principally toward testers. However, at least 2 chapters should be extremely interesting and valuable to developers like myself. It is the chapters that demonstrate with step by step tutorials how a hacker would do to exploit buffer overflow and format string problems. I was already familiar with buffer overflows and I had read a similar chapter about them in Building Secure Software: How to Avoid Security Problems the Right Way but the format string exploits were new to me. As expected since the book is published by Microsoft Press, the book has a strong bias torward Microsoft products (ie.: .NET and ActiveX controls security) but the presented topics are general enough to make this book very valuable even for users of other OSes and/or development tools.



5. This is a very impressive book on finding security issues in software, especially because it really can serve as a book for almost all audiences. If you are not an expert, you can still gain a good understanding of what sorts of issues you need to be considering when writing secure software. At this level, it is valuable to know what a buffer overflow, format string attack or SQL injection are, for example, and how to prevent them. If you are interested in diving further into the details, this book will take you as far down as you are prepared for, including an exploration of buffer overflows at the machine register level. This is a great book to read through once, and then keep as a reference for when you need to review something you've covered, in greater detail.

2 comments about Inside Microsoft Dynamics AX 4.0.

1. I found this book helpful when trying to figure out how to do a variety of development tasks such as debugging, reverse engineering, compiling, etc. The section on the development tools was helpful because it provided a guide on what's available for developers. It's easy to understand and provides some good background information on a lot of the tools and techniques. Very useful for either developers or consultants.



2. Microsoft Dynamics AX is another of the very high end development system that Microsoft has been developing to make the implementation of sophisticated applications relatively easy. Specifically Dynamics AX (which has gone by several names during it's development cycle) is oriented to enterprise resource planning (ERP) applications developers. It might be viewed as a library of subroutines that perform the fundamental actions needed by an ERP system. It is then up to the developer to simply connect these subroutines together in order to produce application.
   
   The end result can be viewed as a very high level language that contains many functions written to perform the actual work. As with any other computer language, it is something non-trivial that has to be learned. And this book is basically a tutorial on the language. It probably is something that could be learned as a language by itself, but experience in other languages, particularily C++ and SQL will ease the learning task. Obviously the reader should have some experience in ERP.
   
   This book is written by members of the development team. It is complete and thorough, but it is a book on the Dynamics AX system, not on ERP.

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 Beginning Object-Oriented Programming with VB 2005: From Novice to Professional (Beginning: from Novice to Professional).

1. This book is an excellent resource for anyone new to vb.net, or anyone transitioning from vb6 to vb.net. It covers the foundation of object oriented programming neccessary to successfully code in the .net environment.
   
   There are samples and a case study, which help cement the concepts covered.
   
   I recommend using this book as a foundation before moving on to more advanced material.



2. I have to admit, has some interesting stuff and information on how to make the theory of Classes to Programs, but I can not agree that is novice to professional, in my opinion I would say just novice.
   
   Leaves many un-answered questions.
   
   But can work as a reference.



3. I performed some programming in Visual Basic 6 a few years ago and then my job was changed so that I was maintaining a Unix program for a few years, which entailed putting fires out each day and very little programming of any type. A few months ago I was fortunate enough to get transferred to a great job programming web sites and some Windows applications. I've been able to write some fairly complex programs, but I knew I was missing some large piece of the puzzle. I'm really a novice programmer. I wasn't creating classes and I wasn't doing a lot of things that were efficient. If my programs needed to do more or scale, they were very difficult to adjust. During these months I've purchased a lot of books, and they had good stuff in them, but I still wasn't able to put things together. I would see things like "WithEvents" and ask what was that for. I had to do some threading and succeeded, but only by trial and error and I didn't understand the "why" of why it worked. For that matter, there was a lot that I didn't understand the "why" about.
   
   I then thought that, even though I was using objects, that I didn't really understand object-orientated programming enough. I looked on some User Group sites and saw this book listed as a good one.
   
   I held high hopes for this book. It's my first book from Apress. I started reading the first 4 chapters, which were on how to design and plan an OOP program. I'm convinced his information is important but ugh! It was horribly boring! I was mostly through the 2nd chapter when I thought I'd committ suicide . I had to quit reading chapters 2-4 and tell myself I'll get back to that later. Yes, it's that boring. It's worse than hearing your girlfriend talk for hours about makeup and dresses! So I skipped to Chapter 5 which gave basic instructions on using Visual Studio. I thought, "Why put this beginner's crap in this book". If you need to know the basics of VS, then get a beginner's book on VS. It shouldn't have been here.
   By this time I'm thinking I bought a book of garbage. But I went on to Chapter 6, and I'm glad I did. It finally got to the point and started talking about OOP and classes, constructors, overloading - and I was getting some of the elusive "why" explained! Chapter 7 got into inheritance, derived classes, overriding and overloading, etc with more of the "why". Chapter 8 got into the stuff like "WithEvents" and delegates, and how delegates work with threading. You will need to use threading and you will see "why". In geekspeak, threading is cool! Chapter 9 shows how to work with Collections (arrays, dictionaries, etc). This chapter didn't explain much "why" but when I need Collections there is enough to be able to implement them. Chapter 10 starts explaining some "why" regarding databases, such as connected versus disconnected data access. The examples use SQL Server. Chapter 11 looks at forms in a different light from other books, looking at them as objects instead of just sticking controls on them, and works with using databases more.
   
   Now I feel better about going back to the first 4 boring chapters as I will now have something to build with.
   
   To a complete beginner, I would say to first get a basic VB.NET beginner's book and get familair with VB and Visual Studio. If this is your very first book you will be very lost. The book is made for a novice.
   
   This book is one of the most important I have read. I am making progress very quickly over the last week or two, while previously I sputtered for several months. I've tried to convey how I felt, and if you feel similar, you must get this book.



4. This book is in very good condition. Shipping very fast. Overall I'm very satisfied with my purchase.



5. I thought the first 4 chapters were boring, but in fact the idea was to build your skill before you code the application! This book was written in a way that readers should already be familiar with OOP terminologies because it does not go into detailed explanation like those for dummies books do.Instead, it shows you how to analyze a problem, draw the diagrams and design the application! This is so far the best book i've read about object-oriented programming using VB, toppling Deb Kurata's or Alistaire Mcmonnies' books on my list. This book will teach you how to do UML/USE CASE so you can design a robust application. This is not a beginner's book on object oriented VB. I've had some knowledge in Java object programming and I know a little of object programming, but reading this book the first time has confused me as the author seemed to have tried to squeeze the discussions in short chapters and programming codes are not explained well, delving right into OOP design and techniques. As the author mentioned in the book, he doesn't know the skill level of a 'beginner', so he added some short intro to programming at the back of the book (Appendix A), so I believe the audience of this book are those 'beginners' to OOP but not to programming. I applaud Dan Clark for the way he laid out the teaching concept of this book, and how I wish he would follow this up with an advanced book with lots of case studies and applications starting from analysis to coding again. Highly recommended!

1 comments about Requirements Management Using IBM(R) Rational(R) RequisitePro(R).

1. SAP devotes its software to running manufacturing processes and the like. In contrast, this book shows how IBM's Rational software is used to manage software development itself. It marries documents written in Microsoft Word with a backend database. The intent is to make seamless the transition between usages of both types of data.
   
   The code provides a framework within which you can apply the Rational Unified Process. A somewhat heavyweight development approach. But one which has claimed many adherents in the software industry. So you can read this book as an explanation of RUP itself, along with an elaborate development environment for it.
   
   One measure of how heavyweight RUP is can be this book, and its description of the RequisitePro package. Exceedingly detailed.

5 comments about On the Way to the Web: The Secret History of the Internet and Its Founders.

1. The book deals with the years leading up to the internet revolution, and all the technologies that eventually came together to become what is now the World Wide Web.
   
   My own personal experience with online services began in the mid 90's, so I missed out on quite a bit of the excitement. I used Prodigy, and had heard of America Online and CompuServe, but really didn't understand the events leading up to the information superhighway. My goal in reading this book was to understand some of the things I missed out on, and to get a better picture of how the web really got started.
   
   The book is arranged reasonably chronologically - chapter one takes place mostly in the 1960's; until reading this, I never even considered the possibility that computers could do anything that long ago, let alone do any networking. As the chapters go by, we see the growth of networks, online services, bulletin boards, and email. We see CompuServe, Prodigy, AOL, and The Source, as well as several other unsuccessful products and companies. They even throw a few screen shots from some of these services back in the 80's - ridiculously lame by today's standards, but they were all the rage back then.
   
   The book ends in the mid-1990's, when the one single web really replaced all of the individual online services. In addition, there's a summarized timeline from 1945-1994, showing each of the major advances leading up to the web.
   
   I really enjoyed this book. It provided a lot of information that I never knew about how online services evolved throughout the past several decades, and gave me a better understanding of why some things are the way they are. The tone of the book is mostly dry facts and stories, but with a little humor and light-hearted fun thrown in on occasion to keep it entertaining as well as informative. And I don't believe Al Gore's name was mentioned once. Maybe he didn't invent the internet after all...
   
   Highly recommended if you are interested in the topic...or if you were around for this stuff, and are just looking for some nostalgia.



2. On The Way To The Web is one book which I highly recommend to anyone who wants a definitive history on the internet. The amount of research and time which was obviously spent on compiling and organizing the short but colourful history of this wonder known as the Web is very worthy of recognition.
   
   For those of us who remember the coming of the internet, On The Way To The Web is a journey back in time, revisiting many events, products and ideas which seemed so futuristic and impossible twenty years ago which have now become common place or fallen by the wayside. I personally had forgotten all about ventures such as GameLine - the innovative download service for Atari 2600 games and game updates. While I'm sure that many of today's gamers think that XBLA, Wii Shop and PlayStation Network were all 21st century inventions, GameLine was here first. Reading about GameLine again, I have to wonder where our games industry would be today if Atari hadn't experienced the downslide it did right at the time of GameLine's launch.
   
   Like spelunkers finding their way through a deep dark cave, technology innovators such as Bill Louden, William Von Meister and others lead the way forward from the days of ARPANET, primitive BBS systems and proprietary communication software to the birth of ISPs, TCP/IP, global email, portals and that entity we all love to hate, AOL.
   
   On The Way To The Web presents a comprehensive time line of where we started and the complicated path we took to get to where we are today in our global internet community. This book is a must-read for anyone who wants to understand how we became such an inter-connected society, the wonders and miracles of communication technology.



3. Having graduated from high school in the late 80's, I was not "around" the online scene. At that age we had better things to do, or so we thought at the time, so my awareness did not develop until the early to middle part of the following decade. What a joy it was to read Michael A. Banks' On The Way To The Web to fill in the gaps.
   
   We met some interesting characters on the way. The most memorable character whom I had never heard of before was William F. von Meister, or "von Scheister", the serial entrepreneur and son of European royalty who started CompuCon in the late 70's, which became The Source in 1979. From there, we also learned about the origins of CompuServe, and we experienced how the entire online industry developed, given the technical and competitive constraints. We learned what made CompuServe popular, and what differentiated AOL (as if this weren't obvious).
   
   In Chapter 2 "In the Money" Banks introduces us to timeshare computing, but most importantly he introduces us people like Larry Roberts, Vint Cerf, and Bob Kahn, who were major players in the early days of the ARPA/DARPA project that became the Internet. In the opening chapters of the book, my main criticism is the shallow portrayal of these people. Where did they work? What did their offices look like? Or smell like? What restaurants did they frequent? Such details, while seemingly mundane, turn these legends into real people with real thoughts and real limitations. Banks deflects this criticism in the Afterword by emphasizing the intent to focus on the services that preceded popular adoption of the Internet, but this gap still feels real to the reader.
   
   Similarly, having built up a wonderful cast of characters and companies, Banks kills them off rapidly and ungraciously in the final Chapter 15 "Moving to the Net". The same deflection applies--by 1994 the web was well established and hence outside the scope of the book--but Banks would have done well to spend some more time on how these pre-web pioneers dealt with the Internet, how they adjusted their competitive strategies, and how and why those strategies succeeded or failed.
   
   While the first two chapters and final chapter were weak, the center of the book provides a fascinating journey through a period of time that has not been well discussed elsewhere. The book fills in gaps, but it also puts our current Internet into context.



4. As someone who went through quite a few phone cords on my trusty Vic Modem and remembers my first acoustic coupler modem for my Texas Instruments computer, I was very interested in this book and boy, it did not disappoint! I have been online in some form or fashion since 1979/1980, operated my own BBS in the dial-up days, and helped establish the first download software store on Prodigy, so this book was a great stroll down memory lane. Even if you can't recall what it was like to not always have a computer in your home and always be online, this is a great book to learn about where things started and how we got to the now ubiquitous world wide web.
   
   The book starts out with a great foreword by celeb-nerd (I say that with the greatest fondness!) Orson Scott Card, which made me laugh out loud at some of the antics we all did back then. Who didn't go into stores after learning some BASIC to do a silly print statement with a goto to watch your handiwork repeat over and over? It jumps quickly and pretty much in chronological order to ARPANET, TeleNet, CompuServe, and GEIS, among others with some pretty interesting trivia tidbits (do you know what the first internet message was or why the @ sign is used in email addresses?). It then progresses into what most folks in their 30s who were on the scene will remember such as Delphi, Q-Link, The WELL, and into America Online, Prodigy, and onto the onramp to the information superhighway as we now know it.
   
   One of the things I liked best about the book was its coverage of some of the "colorful" personalities that built and/or worked on the various online systems of the day--there are many others besides Steve Case. Often when one reads histories related to subjects like this, they are dry and much of the personality of various players are lost--this is not the case with this book. I also enjoyed coverage of some of the great ideas that eventually failed and reasons why (anyone remember Plink or eWorld?).
   
   For anyone that was a participant of the scene during these times, or simply wants to know how the web as we know it got to this point, I heartily recommend this book. I have read several books on this subject and they either miss too much or start with America Online/Prodigy as if that was the genesis of the web. As with any book of reasonable length on this topic, some things are not covered which I would have liked to see more of such as the early days of the Microsoft Network (MSN), WIX (Windows Information eXchange), and early IRC implementations, but this is no way detracts from the book and is more of a personal interest since I was a user of them back in the day. Overall, I would give this book a 10/10 without hesitation, especially considering the depth/breadth of the author's knowledge of the subject matter and easy-reading manner in which the author communicates it.



5. This book is in the same vein as the Hackers book by Steven Levy (Hackers: Heroes of the Computer Revolution). For a lot of people, this is a peek under the covers during what a few lived through. This peek gives the backgrounds and some of the ins and outs of what happened during the very heady days of "home-based" internet access.
   
   Being an early user of the internet myself (I had a university account in the mid-80's), and a user of CompuServe, Prodigy, and various BBS's, this was quite the trip down memory lane and explains why they did not survive.

4 comments about M Programming: A Comprehensive Guide.

1. M is a delightful applications language. Recently I've been struggling with C++ STL, trying to use the "map" container to get perhaps a tenth of the functionality you get from an ordinary M variable, and, believe me, I miss M.

   This is the M book we've all been waiting for, and it delivers exactly what it promises. It is, as the blurb says, "the only source M programmers at all levels need."

   The style and presentation reminds me a little of Stoustrup's book on C++: the organization and style are tutorial, but not elementary. It is up-to-date with the current standard.

   What I particularly admire about it, and what is all too rare in computer books (especially those written by professors of computer science) is that it displays an intelligent awareness of real-world commercial implementations of M. Too many books either describe a pure-standards abstraction on the one hand, or a specific vendor extension on the other. Walters identifies popular M implementations by name and calls attention to variations where appropriate. Like M itself, Walters' book is directed at real programmers trying to solve real problems in the real world.

   There are a few places where one can see that the book is an (extensive) rewrite of his older book, rather than a completely new work. I thought it was harder to locate the "argumentless DO" than it should have been, and I felt there should have been a coherent discussion in one place explaining the (historically weird) relations between the various forms of DO, and when $T is and isn't stacked. Similarly, it is disconcerting to see on page 199 that the "NEW" command is described as a "recent extension... not yet formally included in the standard." These are cosmetic problems that do not seriously mar the book I've been waiting for.




2. This book provides the needed instruction for a beginner with no knowledge to learn the fundamentals of M programming. Combine the book with a free M program downloaded from the internet and you are on your way to becomming a beginning programmer.



3. This book does a good job of explaining the reasoning behind the language's (sometimes strange) behavior--most of the time, anyway. The book suffers from numerous typos in the code fragments. Also, it would be nice to have a nice reference section where each command's syntax is explaned succinctly; this is important, especially because M is not a free-form language, i.e., the white spaces are significant.



4. Was trying to write a mumps interpreter. This book ended up being not so useful. Early in the book, he has a completely wrong definition of "bootstrap loader." This bothered me, because mumps is such an old language, you would think someone that knows mumps would know about the meaning of that phrase. In any case, I believe the author knows Mumps completely, but I did not find the book energizing or inspiring.