WPF 4.5 Unleashed Book Review

So, do we stick with a technology that Microsoft has labelled as legacy - WPF, or do we go with the new unpopular WinRT for line of business applications? After the Silverlight fiasco I personally do not trust Microsoft to not throw the baby out with the bath water again in the future. My hope for Microsoft is all placed on the fact that the Steves (Sinofsky, Ballmer) are gone/going. Right now I am sticking with WPF instead of moving to WinRT for new LOB applications. My primary reason is WinRT tablets are still sitting on shelves and I can't come up with any reason why they shouldn't stay there. I want nothing more than to keep WinRT off my laptops and desktops. It is fine for tablets, but I need to run the same app on tablets, laptops, and desktops. Logic would say perfect, WinRT is on all three. In the past I would have believed that would remain true, but I can see the new Microsoft mentality pulling it from desktops and laptops to get people moving off Windows 7. They have a long way to go to earn my trust back. Ok, my soapbox is in the closet. I just thought I would provide some background as to why I am still interested in keeping current with WPF. Like its predecessor, this book is a pure pleasure to read. It is in full color, the content is laid out in an easy to read style, the author's writing style makes it easy to read, and the content is all valuable. There is no fluff like you find in a lot of the books written today. The book starts out with an awesome chapter on XAML, and then moves on to a very thorough treatment of everything WPF. It covers everything and covers it in depth. The book is broken down into 6 parts and an appendix. I have listed each part and the chapters they contain below. Part I: Background Chapter 1. Why WPF? Chapter 2. XAML Demystified Chapter 3. WPF Fundamentals Part II: Building a WPF Application Chapter 4. Sizing, Positioning, and Transforming Elements Chapter 5. Layout with Panels Chapter 6. Input Events: Keyboard, Mouse, Stylus, and Touch Chapter 7. Structuring and Deploying an Application Chapter 8. Exploiting Windows Desktop Features Part III: Controls Chapter 9. Content Controls Chapter 10. Items Controls Chapter 11. Images, Text, and Other Controls Part IV: Features for Professional Developers Chapter 12. Resources Chapter 13. Data Binding Chapter 14. Styles, Templates, Skins, and Themes Part V: Rich Media Chapter 15. 2D Graphics Chapter 16. 3D Graphics Chapter 17. Animation Chapter 18. Audio, Video, and Speech Part VI: Advanced Topics Chapter 19. Interoperability with Non-WPF Technologies Chapter 20. User Controls and Custom Controls Chapter 21. Layout with Custom Panels Chapter 22. Toast Notifications Appendix A. Fun with XAML Readers and Writers Overview The Node Loop Reading XAML Writing to Live Objects Writing to XML XamlServices As you can see by the chapter's titles there are a ton of topics covered. The author's writing style is very clean and easy to understand making the book an enjoyable read. It is actually fun to read. I can't say that about too many programming books. The code samples are well organized, very usable and work as downloaded. I mention the work as download because lately I have been downloads some author's code samples and the time it takes to get them to work is more than they are worth. There is no coverage of the MVVM pattern at all. With all the MVVM material available out there today, to include it may have just been redundant. There is also nothing worth mentioning on networking either. That is not a bad thing, just wanted to mention it. The author sticks to the client. This is a great cover to cover read as well as a great reference to keep close by when working with WPF. All in All I think this book is the perfect book for taking a WPF beginner to a WPF expert.

WPF 4.5 Unleashed

Executable Specifications with Scrum: A Practical Guide to Agile Requirements Discovery Book Review

This book is exactly what the sub-title "A Practical Guide to Agile Requirements Discovery" says it is. The book is a very detailed breakdown of the steps that should be taken by Scrum teams that want to succeed. I have listed the chapters below to give you an overview of the topics the author covers in this book. Chapter 1. Solving the Right Problem Chapter 2. Relying on a Stable Foundation Chapter 3. Discovering Through Short Feedback Loops and Stakeholders’ Decrements Chapter 4. Expressing Desirements with User Stories Chapter 5. Refining User Stories by Grooming the Product Backlog Chapter 6. Confirming User Stories with Scenarios Chapter 7. Automating Confirmation with Acceptance Tests Chapter 8. Addressing Nonfunctional Requirements Chapter 9. Conclusion In the first chapter the author covers how the scrum teams can distinguish requirements from the solution. In other words the what from the hows. In the second chapter the author shows how to develop guardrails which are basically the artifacts and activities that will keep the project within its defined scope. The examples that the author uses are a healthy team, involvement of all stakeholders, a shared vision, a meaningful common goal, a set of high-level features, and "can-exist" assumption. In chapter 3 the author really drives home applying the trial and error method for discovering desirements through short feedback loops. In chapter 4, Expressing Desirements with User Stories, the author does a great job of showing how to create user stories. He does a great job of breaking down the structure of the user story and introducing the questions that you ask when creating them- who, what, and why, questions. The author also touches on the importance of establishing Ubiquitous Language. Ubiquitous Language is a shared team language that defines a certain domain. Chapter 6 also touches on Ubiquitous Language. He ends the chapter by introducing how to use a product backlog to record desirements. The next chapter, Refining User Stories by Grooming the Product Backlog, is all about roles and activities that need to be in place in order to managing the product backlog correctly. Topics include Managing the Product Backlog, Collaborating to Groom the Product Backlog, Ranking User Stories with a Dot Voting Method, Illustrating User Stories with Storyboards, Sizing User Stories Using Comparison, Splitting User Stories Along Business Values, Tracking User Stories with a Collaboration Board, and Delivering a Coherent Set of User Stories. Chapter 6 is all about confirming your User Stories by scripting scenarios that validate them. The author also introduces two tools for automating validation. He introduces the Framework for Integrated Test (FIT) and the Given-When-Then syntax the Behavior-Driven Development (BDD) community uses. He also touches on Ubiquitous Language again and its importance. Chapter 7 is all about automating confirmation, which is done by turning scenarios into acceptance tests. This chapter explains how to make the scenarios “executable” by a computer. The author introduces existing BDD automation frameworks which include Cucumber for Ruby, JBehave for Java, and SpecFlow for Microsoft .NET. I downloaded SpecFlow which is a solid framework backed up by very thorough documentation. The last chapter before the concluding chapter covers Nonfunctional Requirements (Quality Attributes). Quality attributes are all about tradeoffs and constraints. The author does a great job of explaining quality attributes, showing how they are broken down into internal and external categories, and then applied through constraints (which he calls restrictions). The two things I like most about this book was the flow of the chapters and the author's recognition of the importance of architecture. The chapters build on each other so I definitely recommend a cover to cover read of the book. The author has a great writing style, so that is easy to do. When the author spells out what roles make up a team he includes architects. He defines architects as members of the development team who are responsible for designing the structural foundation upon which the solution is built. Their role is to ensure the development team builds the software right and delivers quality work. I have seen a lot of confusion in Scrum teams when it comes to architecture, because a lot of the Scrum material out there today discounts it. All in all I found this book a very enjoyable read. If you are involved with agile development teams, you should definitely read this book. The elicitation of requirements is really lacking in most of the agile teams I encounter. This book can help to remedy that.

Executable Specifications with Scrum: A Practical Guide to Agile Requirements Discovery

Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs Book Review

Although this book is written for the Java programmer, I would recommend reading it to any .NET or iOS developer as well. It is a must read for the Java developer, but is also a valuable read for developers of other languages because the guidelines are often built around a programmer's intent. No matter what language you use most, many of the intentions that are targeted by the guidelines are the same. Do I wish there was a C# and Objective-C version of this book? Heck Yeah!!! But, one of the things that helped get to a deeper understanding of the guidelines was thinking about where and how they apply to C# and Objective-C. There is Secure Coding in C and C++ (Second Edition) and The CERT C Secure Coding Standard which are both great too. The guidelines are broken down by chapter. The book also has an appendix that lists all 75 guidelines and whether or not the guideline is applicable to Android development. I have listed the chapters below. I have also included an overview of what the guidelines in the chapters are targeting as described in the introduction to the chapters. Chapter 1. Security 1. Dealing with sensitive data 2. Avoiding common injection attacks 3. Language features that can be misused to compromise security 4. Details of Java’s fine-grained security mechanism Chapter 2. Defensive Programming The guidelines in this chapter address areas of the Java language that can help to constrain the effect of an error or help to recover from an error. A good overall principle for defensive programming is simplicity. If a construct turns out to be complicated to implement, consider redesigning or refactoring it to reduce the complexity. Chapter 3. Reliability 1. Guidelines that help reduce errors, and are consequently important for developing reliable Java code. 2. Guidelines that contain specific Java coding recommendations to improve software reliability Chapter 4. Program Understandability Program understandability is the ease with which the program can be understood—that is, the ability to determine what a program does and how it works by reading its source code and accompanying documentation. Some guidelines in this chapter are stylistic in nature; they will help a Java programmer to write clearer, more readable code. Failure to follow these guidelines could result in obscure code and design defects. Chapter 5. Programmer Misconceptions 1. Misconceptions about Java APIs and language features 2. Assumptions and ambiguity-laced programs 3. Situations in which the programmer wanted to do one thing but ended up doing another Appendix A: Android This appendix describes the applicability of the guidelines in this book to developing Java apps for the Android platform. I really liked the way the chapter on defensive programming brought the goal of simplicity to the forefront. One of the hardest things to do is maintain simplicity when coding. Often times getting through very complex situations ends with a lot of the code being in a state where it can be refactored into much cleaner code. I find one of the biggest mistakes programmers make is saying they will come back to it later and clean it up. They honestly have the best intention of doing that and sometimes even come back to do that. When they do they realize that the big ball of mud they made just getting the problem resolved will take too much time to relearn. What they had done two weeks prior gets left alone with the thought, it isn't broke, so I'll just leave it. Cleaning it up while it is fresh in your head is what needs to become a habit, otherwise never cleaning up will become your habit. One of the really nice features of the book is that the author's include references to the rules that apply from The CERT Oracle Secure Coding Standard for Java. All of the rules are available on line- just google "CERT Oracle Secure Coding Standard for Java". Once there you just plug the code used in the book into the search and you're taken to the rule. The rule has more information and more code samples. They also include references back to the online The Java Virtual Machine Specification- Java SE 7 Edition. Having these references really helps you get any additional information to help you fully understand the topic at hand. Another thing I really like is that they show tons of noncompliant code examples and compliant solutions. It really helps to have the examples along with the explanations. In the beginning of the book the authors say "While primarily designed for building reliable and secure systems, these guidelines are also useful for achieving other quality attributes such as safety, dependability, robustness, availability, and maintainability." I must agree and say that they have really provided a treasure chest of wisdom in this book. Following the guidelines in this book will go a long way in helping you achieve the quality attributes listed above in your architecture. All in all I highly recommend this book to all Java developers. It is a must read for you. I also recommend to developers of other languages that want to gain new insight into guidelines that they can apply in their language of choice.

Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs (SEI Series in Software Engineering)

Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips Book Review

The first thought that came to mind when I saw this book was, "Uhg, another Scrum book, you've got to be kidding me." Then the title of Scrum Shortcuts really gave me a sickening feeling. The majority of the Scrum teams I have watched work do nothing but take shortcuts. They sure as heck don't need a book on how to take more of them!!! Luckily, throughout the book, the rest of the title holds true - without Cutting Corners. Personally I would have titled the book "Agile Tactics, Tools, & Tips for Real Scrum Teams - No Poseurs Allowed". One of the first things the author covers is the Scrum sales pitch. He points out that it is a pretty simple sale to make. I have witnessed that personally several times. I was sitting in a meeting some time ago with a company that was embracing Scrum like a ten year old being offered a warm plate of chocolate chip cookies. They were grabbing at it as fast as they're little hands could reach out and grab the goodies. Watching this made me wonder what is was about Scrum that made them embrace it so emphatically. They had claimed to be an Agile shop for years, but were still failing to deliver quality software on time within budget. In past years they refused every single proposed process improvement recommendation made by dozens of consultants. They literally went from zero process (using the name Agile to execute no process at all) to zealot Scrumbots overnight. What I like most about this book is that it is really down to earth. The author does not pull punches when it comes to pointing out that it might be easy to sell Scrum, backing up your pitch with a highly effective Scrum implementation is a very different story. The team I mentioned above crashed and burned after a few months. They were still using Scrum vocabulary, but were the farthest thing from an effective Scrum team as you could get. The author hits it on the head with shortcut 2 when he says -- one of the most frustrating comments that I hear when speaking to novice software teams is, “We do Scrum—we work in sprints, we have a daily scrum, and we even have a product backlog.” In addition, although they may not explicitly say it, you can often add, “We don’t write any documentation, we release haphazardly, we plan on the fly, and we don’t care about buggy code because we’ll just fix it up with a bug iteration.” ARGH! These people give Scrum a terrible name, and worse still, when their projects inevitably fail, it is very difficult, if not impossible, to win back the senior stakeholders who have been burnt by a badly warped Scrum implementation. The author packs a ton of wisdom into this fairly short book. I have listed the chapters below with the shortcuts they contain. Chapter 1. Scrum Startup Shortcut 1: Scrum on the Pitch Shortcut 2: Fragile Agile Shortcut 3: Creative Comfort Chapter 2. Attitudes and Abilities Shortcut 4: Masterful ScrumMaster Shortcut 5: Rock Stars or Studio Musicians? Shortcut 6: Picking Your Team Line-Up Chapter 3. Planning and Protecting Shortcut 7: Setting the Scrum Stage Shortcut 8: Plan the Sprint, Sprint the Plan Shortcut 9: Incriminating Impediments Chapter 4. Requirement Refinement Shortcut 10: Structuring Stories Shortcut 11: Developing the Definition of Done Shortcut 12: Progressive Revelations Chapter 5. Establishing Estimates Shortcut 13: Relating to Estimating Shortcut 14: Planning Poker at Pace Shortcut 15: Transitioning Relatively Chapter 6. Questioning Quality Shortcut 16: Bah! Scrum Bug! Shortcut 17: We Still Love the Testers! Shortcut 18: Automation Nation Chapter 7. Monitoring and Metrics Shortcut 19: Metrics That Matter Shortcut 20: Outstanding Stand-Ups Shortcut 21: Taming the Task Board Chapter 8. Retros, Reviews, and Risks Shortcut 22: To-Dos for Your Sprint Reviews Shortcut 23: Retrospective Irrespective Shortcut 24: Risk Takers and Mistake Makers Chapter 9. Managing the Managers Shortcut 25: Perception Is Reality Shortcut 26: Our Lords and Masters Shortcut 27: Morphing Managers in the Matrix Chapter 10. Larger Lessons Shortcut 28: Scrum Rollout Reckoning Shortcut 29: Eyes on the Prize Shortcut 30: Shortcut to the Final Level The author's realistic view of Scrum is a refreshing one. He is not one of the many Scrum zealots, mindlessly regurgitating Scrum mantras and bashing every other process that came before Scrum hit the mainstream. He presents a realistic view on how difficult Scrum is. Scrum is not easy and the author makes that very clear. Shortcut 5 was the only one I felt was a bit off. He made his point, but I have had a different experience with people. Maybe because I have family members that are Rock Stars and I know the best musicians are those that can handle being a rock star on tour, but also make excellent studio musicians. They put on the show for the live fans, but also lay down the tracks for their producers. In order to be successful in both roles they need to have the confidence to play live and be humble enough to let someone else guide them through the creation of a record. They are also team players in both roles. I think shortcut 5 would have been better explained as the No A-hole Rule. I personally have met many more unskilled arrogant people, than I have highly skilled arrogant people. The unskilled people are usually insecure in their abilities, so they attempt to camouflage it, which comes off as defensive or arrogant. Chapter 3 touches on team stability and working environments. Since I left the electronic engineering field I have not had an office with a door except at my home office. I have sat at tables where all the printers were for the office. The printing noise wasn't bad, but the people standing around talking, waiting for the slow printers, was a problem. At work I am currently in a cube that is noisy 25% to 75% of a given day. I share it with one of the main application support guys on our team, and he often has a line waiting to see him. While they wait I am an open target for them to kill the wait time talking to me. Another thing about the office is they keep it hot in the winter and hot in the summer. I have to keep a fan blowing on me and by the end of every week my eyes are wind burnt and bloodshot. My chair I have at work has me going to the chiropractor. They were going to buy us new chairs, but discovered they were too expensive, and we aren't allowed to bring our own chair in. I work from home on Mondays. My home desk provides me twice the area I have at work. I have the room at a cool 68F. I have a great ergonomic chair. If I get a call I can put it on speaker phone, instead of having to hold it to my ear with my shoulder. Context switching is always a big problem. The book refers to it in the context of fractional assignment. I work from home on Mondays and I would estimate I get 20 - 80% more work done on Mondays than any other day of the week because I have the isolated environment I need to think. To get hold of me people IM, email, or call if needed, but I can queue them until I am done with what I am working on. At the office if you don't answer right away they come to your cube and interrupt your thoughts. Once you start context switching like a pinball you become ineffective at everything. Some days are just fire days. I would have literally been a day ahead of where my day ended if I would have just called off. I thought that every chapter in this book contained wisdom worth reading and learning. Two chapters that stand out are Requirement Refinement and Establishing Estimates. Of all the problems I see with Scrum teams these two things are always a big problem. They are never properly address because the misconception that requirements change all the time in agile environments, and therefore the timelines change too, seems to be a mantra of immature teams. Scrum is not a one size fits all process. The author does a great job of pointing out that it is a framework. Scrum would be a fine team level project management process for one of the projects I am currently on, because the developers on the team are awesome. We are actually not using any defined process. The reason for that is the primary developer builds everything with modifiability in mind and we have very solid requirements. The architecture make use of some very well-known patterns and open source libraries that including MVC, DI with Unity, repository, unit of work, using Entity Framework 5. Architecture done right allows for agile practices to happen without effort. The developers code the project and I document it by creating a Developer's Builders Guide. As a team of 3 that has worked together often, and with solid requirements in place, we just build it. Other projects I have seen that do not qualify for Scrum alone, are some of the large COTS and development projects that have requirements that are not just fluid, but are like a Class VI rapid. They need the structure of Disciplined Agile Delivery or the Scaled Agile Framework (SAF). These processes can use Scrum as the development management process, but they supplement it with architectural and enterprise level activities. Over all this is a great read. The author’s writing style makes this a pleasure to read and he crams a lot of wisdom into 200 pages. I would recommend this book to anyone involved with Scrum in anyway. Do not be lured in by the desire to find a silver bullet process, there is none. Books like this can give insight into what you are up against before you have to learn the lesson the hard way, by going through it yourself.

Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips