Pro .NET Best Practices Book Review

I personally do not find software development an art form. It is not an unpredictable activity driven by crazy business users that come to work every day inventing a new way to operate their businesses just to savagely changing your requirements. Project teams that use changing requirements as an excuse for their dates constantly slipping and bugs being pushed to production are simply not good development teams and they are poorly managed. Even when you're in an environment where requirements are volatile, proper architecture and process engineering can level the playing field. One of the reasons for incompetent software development teams is what I like to call home brewed enterprises. A company that does not welcome external resources to the table when they are changing to meet the demands of today's hi-tech requirements for doing business will usually create a home brewed mess. The attitude that 'we have figured out how to run our business over the past 30 years and can figure out how to move forward on our own', is shortsighted and destine to fail. If your people are not continuously learning what the newest industry standards, best practices, programming language features, process engineering techniques, and management skills that have become available are, then you need to turn to outside consultants that are doing that to help you through changing times. One other thing, you have to actually take and execute their advice. I don't know how many times I have seen consultants brought in, asked for their opinion, only to have their advice ignored because the internal team did not have the skillset to execute their advice. If you don't have the skillsets available for building software right, you should not be building software, period. There is a much bigger gap between the professional software engineer and the average company software developer than most companies realize. They miss it because they have no one on their team that has experienced an actual software development project run right. Most company's IT departments are hitting about 10% of their potential. The reason the business doesn't know any better is because some improvement, no matter how little, is better than no improvement. The business simply believes the productivity gains they are getting for the half million dollar projects are what they have to pay. When in reality a shop that is practicing best practices could deliver five to ten times more functionality with a much higher quality for the same cost. Getting the message through to them after years of developing garbage is tough cookie to crack. That would mean a lot of people, from IT to the business, would actually have to say I was wrong. It would also mean that things would need to change, and home brewed enterprises hate change. The author of this book has done every software developer who does not want to be just another home brewer a great service. He has taken today's best practices from the .NET world and compiled them into one place. Granted a lot of the topics he covers will require further reading, but he has done a great job of introducing a ton of best practices along with the tools and resources you need to implement them. He does not just give you a bunch tools with an example, he also gives you sound advice on how to determine whether or not the tool or practice is right for your environment. This author has a very clear understanding of the fact that there are different teams with different skillsets in different environments and not every practice is right for every team. An example is his advice with agile processes, which is that you must have an open and trusting environment for agile to succeed. I have repeatedly seen agile process jammed down team's throats that couldn't handle it. They were not mature enough. They should have first been run with an experienced architect and project manager in place under the unified process in order to gain experience. The book starts out with a chapter that introduces several healthy concepts that should be understood about best practices in general. They include Practice Selection, Target Areas for Improvement, and Overall Improvement. The book continues with 12 more chapters. They include .NET Practice Areas, Achieving Desired Results, Quantifying Value, Strategy, .NET Rules and Regulations, Powerful C# Constructs, Automated Testing, Build Automation, Continuous Integration, Code Analysis, Test Frameworks, and Aversions and Biases. The book covers a ton of topics some of them include Technical Debt, Retrospective Analysis, Prospective Analysis, Application Lifecycle Management, Patterns and Guidance, Research and Development, Microsoft Security Development Lifecycle, Success Conditions, Documented Architecture, Improving Manageability, Increasing Quality Attributes, Personal Process, Commitment to Excellence, Coding Standards and Guidelines, Code Smells, Brownfield and Greenfield Applications, Boundary Analysis, Test Code Maintainability, Unit Testing, Automated Integration Testing, MSBuild Fundamentals, Automated Deployment, The CI Server, CI Lifecycle, Static and Dynamic Code Analysis, Mock Object Frameworks, Dunning-Kruger Effect, Ostrich Effect, Gambler's Fallacy, Ambiguity Effect, and Focusing Effect. The downloadable code is very well organized and usable. Each chapter includes a readme document that describes the code samples. The download also includes an Excel spreadsheet of the .NET Best Practices Scorecard that is found in Appendix B. Appendix A is a nice collection of all the resources used in the book including books, articles, guides and tutorials, and tools. My wife has accused me of going to work and speaking a foreign language and that is why no one understands what I am saying. The foreign language I have been use is called Best Practices and Industry Standards. It is a language that is constantly evolving. This book has the most current version of it as it relates to .NET. If I get my way, this book will be mandatory reading to be able to join my team. I suggest your team do the same. I highly recommend this book to any role involved with developing .NET software.

Pro .NET Best Practices

XAML Developer Reference Book Review

I have read a lot of the WPF and Silverlight books out there and there are some good ones. The difference I find with this book is that it is XAML centric so the scope is more isolated. A few months ago a fellow developer of mine had to build some XAML forms to integrate with a third party shell. This book would have been the right level of information he needed to knock the project out. The first chapter offers an overview view of XAML. The introduction is followed by 8 more chapters and two appendices. The chapters include Object Elements and Attributes, XAML Properties and Events, Markup Extensions and Other Features, Resources, Styles, and Triggers, Layout and Positioning System, Form and Functional Controls, Data Binding, and Media, Graphics, and Animation. Each chapter goes in-depth into the topic at hand. Each topic is defined and then demonstrated through a practical example. There are not 10 examples showing the same thing, and they are explained in a way that makes them easy to understand. The authors also do a good job of making use of tables, screenshots, and diagrams without going overboard. I have seen a few books that went way overboard. The two appendices are Major Namespaces and Classes and XAML Editors and Tools. The Major Namespaces appendix give a nice list of all the major namespaces in Silverlight and WPF. It includes the class and the description and makes for a nice summary of the available tools found in each library. The author does a good job of pointing you to additional information by including links where appropriate. Although the author touches on the Silverlight Toolkit, I would have liked to see more coverage and coverage of the WPF Toolkit features. The downloadable code is all there, but is a little confusing some places. Most of the samples are in projects and those ore well organized, but they also include text file snippets. The author names the snippet files by number, but the book does not label them at all. An example is chapter 9 has 33 snippets of code which is nice, but you have to use a file searcher to find the one you want. Not that big of a deal, and I would rather have them, than not. I found the authors writing style made the book an easy cover to cover read. The book also includes a nice index which helps to make it a nice reference. I think this book is perfect for those people looking to get into WPF, Silverlight, or XAML for Windows (Windows 8) development. It gets you up to speed fast on the ins and outs of XAML.

XAML Developer Reference

Continuous Integration in .NET Book Review

I still remember the first time I was on a project that used NAnt and CruiseControl.NET. It was years ago and both were new tools with plenty of bugs. The project manager took one of the team's architects and dedicated him to getting CI up and running. I didn't work with him for another 9 months. It was a complete nightmare. Every morning was dedicated to finding out why the builds failed, fixing the issue, and then manually rerunning the builds until successful. Then it was off to show management the new build reports. It didn't take long for them to not want to be hassled with the process. A year after it all began the code base was removed from the CI process and went back to manual builds. Not a very good story to start the review of a book on CI that I highly recommend you read. Times have changed, the tools have improved, and with books like this available you have no reason to not give CI a go. You may have plenty of excuses, but no reasons. Luckily this book contains a nice summary of excuses commonly used and does a nice job of debunking them. The book starts off with a chapter titled Understanding continuous integration which gives a nice overview of CI and introduces the CI tools. They include source control, CI server, feedback mechanism, build manager, unit test framework, documenting, and code-analysis tools. The book continues with chapters on Setting up a source control system, Automating the build process, Choosing the right CI server, Continuous feedback, Unit testing continuously integrated code, Performing integration, system, and acceptance testing, Analyzing the code, Generating documentation, Deployment and delivery, Continuous database integration, and Extending continuous integration. One of the things I like about the book is that it is .NET centric and not Microsoft centric. It introduces the Microsoft tools, other vendor's tools, and open source tools. For example Subversion, TFS, SourceSafe, Git, and Vault are introduced as source control options, Nant and MSBuild are introduced as build tools, and CruiseControl.NET, TFS 2010, and TeamCity as CI servers. The authors do a great job of providing in-depth examples of the different tools and technologies. The example's accompanying downloadable code is very well organized and usable. Although implementing CI can be a big change for a team, this book will definitely help educate you and your team on all the different tools available in the context of .NET projects. That give a big advantage when planning your team's path to CI. All in all I highly recommend using CI on your projects, but I recommend reading this book first even more.

Continuous Integration in .NET

Experiences of Test Automation: Case Studies of Software Test Automation Book Review

Every once in a while a book is put together that should be read by every person with a relationship to software development. This book is one of them. Everyone dreams of automating their software testing, but few make it a reality. This down to earth book is the stories of 28 teams that went for it. It includes both successes and failures. That is not something you see everyday. Many books simply provide you the success path. This book also provides you with the steps you could possibly be taking that could lead to failure helping you to change your path before fully failing. The book starts with a nice overview of the case studies and an introduction to the key issues addressed by the case studies. Besides each case study being summarized, it also includes introducing the topics and pointing out the chapter they can be found in. They are broken down into management and technical issues. The management issues include Objectives for Automation, Management Support, Return on Investment and Metrics, Automation in Agile Development, Skills, Planning, Scope, and Expectations, Relationships with Developers, Triggers for Change and Getting Started, Tools and Training, and Political factors. The technical issues covered include Testware, Abstraction, Architecture, Test Execution Tool, Automation Standards, Reusability, Documentation, Flexibility, Results and Reporting, Testing the Tests, What to Automate, Failure Analysis, and Finding Bugs. The book includes a really nice table of Case Study Characteristics. Some of the characteristics include location, lifecycle (process used), number of team members, time span, tool types, pilot done, ROI measured, was it successful, and is the project still going on. This table really helps you hunt down topics you are interested in reading about first. The index of this book is really nice also. I mention that because I have seen some books lately where the publisher didn't want to foot the bill for a nice one. That can be very aggravating. The book's last chapter is titled Test Automation Anecdotes. It is filled with experiences from the field that the authors felt were worth repeating, but did not constitute an entire chapter. The book also has a nice table in the appendix that lists all the tools mentioned in the book. It includes which chapter they are in, where or not they are open source, and a link to the tool owner's website. I have repeatedly seen attempts at test automation fail for a verity of reasons. This book included them all from lack of management support, to believing the tool is all you need, to trying to automate tests without documenting them, to trying to automate every test. It the level of difficulty and effort is almost always underestimated. This book definitely puts the level of effort into perspective. Almost every story's environment is unique. I really like the way the stories provide solutions to problems that could not be solved by simply purchasing a tool. These solutions are not the industry's best practice solution, but rather home grown solutions to problems unique to their environment. Now that this book is out they may become best practice solutions? The primary thing they do is make you think out of the box. It is really refreshing to read such a real world book. Every story is well written and well edited. This is one of the best resources available for helping expand your experience level without having to make the mistakes to learn from along the way. I wish this same format would be done with just software projects in general. That is with the same level of honesty. I see failing projects constantly being touted as successes. Buggy, over budget, late projects, are not a success. Kudos to those authors who stepped up to write about the failed projects!!! The authors come from a wide range of technologists. You can check out the 28 case study summaries on the author's web site. I only have one word of warning. These stories suck you in. You may find yourself saying "Just one more", and then suddenly look at the clock and realize it is 3 am. All in all I highly recommend this book to everyone in the business of building software. Before you attempt to automate your testing, read this book!

Experiences of Test Automation: Case Studies of Software Test Automation

Building Enterprise Systems with Open Distributed Processing Book Review

This is a very well put together book. It includes a single example company that the book grows and changes throughout the book. Sometimes examples get on my nerves. They are either too lightweight to mean anything, or sometimes too complex, and end up distracting you to the point of not wanting to continue read the book. The authors do an awesome job with the case study in this book. It really made it an enjoyable read. The book begins with a nice introduction to ODP. It introduces viewpoints, viewpoint languages, viewpoint correspondences, fundamental concepts, and UML4ODP. After a nice introduction to ODP the book has a chapter covering each viewpoint. They include the Enterprise Viewpoint, Information Viewpoint, Computational Viewpoint, Engineering Viewpoint, and the Technology Viewpoint. This part ends with a chapter titled Correspondences—Joining It All Up. The correspondences link the viewpoints together providing traceability between the viewpoints. The third part of the book is dedicated to showing how the ODP can help resolve common issues and risks when developing distributed systems. This section has some really practical advice in it. The chapters in this part of the book are Conformance—Does It Do the Right Thing?, Transparencies—Hiding Common Problems, Policies—Tracking Changing Requirements, Federation—Talking to Strangers, Using Existing Products, and System Evolution—Moving the Goalposts. The forth part of the book is about the theoretical basis of ODP and the tools used with ODP. It includes the following chapters- Modeling Styles, Sharp Tools, and A Broader View. The book includes two appendices. One of them is an abbreviated version of the Specification created for the example used in the book. There is an online version of this specification available that includes the entire specification. My one complaint about this book is that it did not include the entire specification in the appendix. I hate buying a book only to have to print a bunch of extras to get the full benefit. The author says there were space limitations. This book is no where close to being to big to print, and at the price the publisher is charging for the book, it should have been included. I won't ding the book for this. It is not the author's fault the publisher decided to cut corners and penny pinch. Over all I think the book offers valuable information. Using viewpoints (or views) is a best practice that is used throughout many enterprise and software architecture practices and processes. This book does a great job of showing the power viewpoints have when trying to approach different stakeholders. It also does a great job of showing the importance of tractability between the viewpoints. A big plus for the book is that the models are available online and can be opened with Magicdraw's reader. I would love to see a SPARX EA version of them posted. I highly recommend this book to the software and enterprise architect looking to improve their modeling and design skills.

Building Enterprise Systems with ODP: An Introduction to Open Distributed Processing

Dependency Injection in .NET Book Review

Uhg. Sometimes my ability to be a complete ignoramus really annoys me. When I first saw this book on the upcoming list of books to be published I thought, "That sucks, I just got done reading Dependency Injection by Dhanji R. Prasanna last year. I don't need to read the .NET version", and so I ignored this book. As time went on I saw all the great reviews coming out about the book and it made me curious. A buddy of mine had purchased it and I know that Manning gives ebooks with there book purchases, so I asked to borrow it. I ordered the book the next day. I have nothing bad to say about Dependency Injection by Dhanji R. Prasanna, it was a great book. The difference is this one spoke my language of choice, .NET. It made the read so much better for me. Plus all the coverage of the popular DI Containers for .NET rocks. This book is broken down into 4 parts the first part introduces DI. Part two is a catalog of patterns, anti-patterns, and refactorings. Part three covers Object Composition, Lifetime Management, and Interception. Part four covers all the popular DI .NET Containers which include Castle Windsor, StructureMap, Spring.NET, Autofac, Unity, and MEF. One of the coolest things about the book is that it uses poor man's DI in the first 3 parts of the book to teach you how it all works, and then covers the popular DI .NET Containers in details to help you be more productive. Coverage of the popular DI .NET Containers is nice deep coverage which also highlights the advantages and disadvantages of each one. Each popular DI .NET Container gets its own chapter. There are also some nice feature and lifestyle comparison charts to help you zero in on which DI Container will fit your needs. The chapter on Object Composition is pretty cool too. It include coverage of console applications, ASP.NET MVC, Windows Communication Foundation, Windows Presentation Foundation, ASP.NET (Web Forms), and PowerShell. The chapters on patterns and anti-patterns are a really big help in making sure you are using DI correctly. The patterns covered include Constructor Injection, Property Injection, Method Injection, and Ambient Context. The anti-patterns covered include Control Freak, Bastard Injection, Constrained Construction, and Service Locator. Both include nice code samples. The chapter on DI refactoring covers mapping runtime value to abstractions, working with short-lived dependencies, resolving cyclic dependencies, dealing with constructor over-injection, and monitoring coupling. This book is packed with diagrams that help you visualize the topic at hand. The author includes just the right amount. Over all I found this author's writing style made the book a nice cover to cover read, but I will also be keeping it near to use as a reference. I have been on projects that use Castle Windsor, StructureMap, Unity, and MEF, so having coverage of each handy will be nice. All the downloadable code is very well organized and usable. This book is not only about DI, it is about proper object oriented programming. Every .NET architect and developer should read this book.

Dependency Injection in .NET