WiltChamberlinHeader

What Does Wilt Chamberlain and Many Software Developers Have in Common?

0 comments / July 6, 2016

wilt-chamberlain-03Wilt Chamberlain was the greatest basketball player who ever lived. His most notable achievement (in basketball at least) was in 1962, while playing for the Philadelphia Warriors he scored 100 points against the New York Knicks, a record that still stands today. Even more impressive that night was that Chamberlin, a player known for being a terrible free throw shooter, made 28 out of 32 free throws. The story of this game was recently discussed on the excellent “Revisionist History” podcast. In the episode, Malcolm Gladwell recounts how Chamberlain had switched free throw techniques and began shooting his free throws underhanded (sometimes known as a “Granny Shot“). Suddenly, Chamberlain went from a terrible free throw shooter to one of the best. He was now UNSTOPPABLE!

Except…not long after, he switched back to his old style of free throw shooting and his completion ratio tanked. He went from shooting 87.5% shooting underhanded back to shooting 40% overhanded. His only achilles heel had been his inability to shoot free throws and as soon as he’d mastered them he went back to the old way. Why would he do that? Well, Chamberlain put it this way in his biography, “I felt silly, like a sissy, shooting underhanded. I know I was wrong. I know some of the best foul shooters in history shot that way. Even now, the best one in the NBA, Rick Barry, shoots underhanded. I just couldn’t do it.” Even though all the statistics proved that shooting underhanded was the best way to go and even after he had seen the success first hand in his record breaking game he still chose to ignore it. On the other hand Rick Barry, the greatest free thrower of all time understood the advantage of underhanded free throws and embraced it to great success.

I felt silly, like a sissy, shooting underhanded. I know I was wrong. I know some of the best foul shooters in history shot that way. Even now, the best one in the NBA, Rick Barry, shoots underhanded. I just couldn’t do it.

This may seem unthinkable to many people but as software developers many of us do the exact same thing. I’m talking about creating and maintaining a culture of “Sustainable Code.”

What do I mean by “Sustainable Code?” Sustainable Code is a methodology that intends to build software using proven techniques to ensure a lower defect rate, faster turn around time on features, shorter regression test period and better work life balance for the team.

How is this achieved? There are a couple of core disciplines that over the years I’ve learned can make a huge difference when it comes to building a culture that writes sustainable code, I will be going into these in more detail in future posts.

  • Test Automation
    • These include unit testing, integration testing, automated feature testing.
  • Pair and Squad Programming
    • Working with another developer on a single development task or even having the entire team in a room working on a single ticket.
  • Code Reviews
    • Sharing your work with the team and getting feedback.
  • Quick Iterations
    • Don’t get bogged down for weeks at a time working on a single feature. Write code, check-in and deploy often.
  • Close collaboration between devs, QA and business analysts.
    • We’re all one team, don’t just throw things over the wall.

Now, if you’ve been a developer any length of time you’ve probably run into every item in the list but based on statistics you most likely practice few if any of them. One study showed that TDD lowered defect rates between 40% and 90% when compared to non-TDD projects while only increasing development time 15%-35%. Even in the worst case scenario this is a net-gain!  However, just like in the case of Wilt Chamberlain, most developers chose to ignore the stats and keep doing what they’re doing. Most developers balk at having someone review their code or think unit testing is a waste of time and don’t think they need it.

I’ll be the first to say that early on I HATED writing unit tests. I thought they were so pointless and just took time a way from “real development.” I didn’t want to do code reviews because in my mind I was a good programmer and I didn’t want someone else telling me how to do my job. But as I matured as a developer I came to embrace testing. It lowered my stress level when doing a refactor because I always knew I had the tests to rely on to tell me if I’d done something wrong. The same goes for code reviews. I now look forward to them because its a way to learn new ideas and gain new perspective. I get great feedback and the entire team has a better understanding of what each person is working on.

Most importantly though as our organization has adopted agile practices, I’ve realized that without these things we could not really say that we’re practicing lean. Gone are the days of multi-week regression cycles, hours long deployments, huge backlogs of defects.

As a developer. don’t be like Wilt Chamberlain and ignore proven practices because of pride or other reasons. Be like Rick Barry and use these practices to your advantage.

Project Setup List

Workflow Foundation Tutorial: Part 3 – Project Setup

0 comments / February 16, 2016

Today will be a short post where we review the project structure of our sample project.

  • WarpCoreTechnologies.Activities
    • This is an “Activity Library” project used to hold our Workflows and custom activities.
    • Having a shared activity library allows us to reuse these components in multiple places such as a website or WPF project.
  • WarpCoreTechnologies.Database
    • This is our database project. It will be used primarily for storing configuration and Workflow settings. We want to version control our database schema and will be using DACPACs as part of our deployment. Robb Schiefer has a great post on using MSDeploy to deploy a database project.
      • We set it up using the “SQL Server Database” project type.
  •  WarpCoreTechnologies.OrderProcessing
    • This is our main service and will be the consumer of our workflows.
    • We set it up using the “WCF Workflow Service Application” project type.
    • This will create a new project with a placeholder “XAMLX” file as your endpoint.
  • WarpCoreTechnologies.WorkflowEditor
    • This is a WPF application that we will use to demonstrate the rehosted designer capabilities of Workflow Foundation.
  • WarpCoreTechnologies.Tests
    • At the heart of our system will be unit and integration tests.
    • This is a standard “MSTest” Unit Test project.

This is the last tutorial “foundation” post, in the next post we will begin writing our first Workflow to handle order validation!

Here is a link to the release in GitHub that corresponds to this part in the tutorial.

 

Screenshot_021216_033651_PM

Quick tip: Use AutoHotKey to make writing unit test names easier

0 comments / February 12, 2016

One of the most popular naming conventions for unit tests, and the one that we use is writing out the expected behavior as a sentence with underscores(_) instead of spaces.

The only problem is typing all those underscores is kind of a pain. That’s where AutoHotKey comes in! AutoHotkey (AHK) is a free, open-source macro-creation and automation software for Windows that allows users to automate repetitive tasks. It has a powerful scripting language that can allow us to intercept a key and replace it with another key. I’ve taken advantage of this to create an AHK script that detects if “Scroll Lock” is on and automatically replace spaces with underscores if it is.

Simply add the above code to a new AHK script and run it and you will now be able to toggle underscores for spaces by hitting the Scroll Lock button!

New Workflow Project

Workflow Foundation Tutorial: Part 2 – The Basics

3 comments / February 9, 2016

Before we get heavy into the code I think it’s important we go over exactly what Workflow Foundation is, why you would want to use it and some of the vocabulary used.

What is Workflow Foundation?

Workflow Foundation is a Microsoft technology built into the .NET Framework to give developers a declarative way to model the “flow” of their application. WF also includes APIs for handlling long running workflows as well as the ability to “rehost” the designer inside your custom application to give you an extreme amount of flexibility in building your workflows.  WF was first introduced with .NET 3.0 and completely overhauled in .NET 4.

Why would I use Workflow Foundation?

  • It’s visual.

    • Humans are naturally visual communicators and a lot of times it’s easier to describe complex ideas through visual imagery.
    • One of the hardest part of the development process is not writing code. It’s communicating across a wide range of people in different disciplines to learn and understand what exactly we’re building.
      • This is why the whiteboard has become the Roesetta stone of developers and business people. Business people don’t always  understand the code and developers don’t always understand the business vocabulary but we can both understand lines and boxes drawn a whiteboard.
      • Workflow gives you this same capability except you’re not showing an abstract 2nd hand representation of the code’s implementation of the process, you’re showing the actual code!
      • This makes it much easier to communicate and can help head off confusion earlier in the process.
      • You can even bring up a blank workflow and start dropping code activities on the designer to create a rough outline of what you’re going to build.
    • It just makes complex processes easier to understand.
  • It naturally lends it self to testability.

    • The smallest component of a Workflow is a Code Activity.
      • Each activity should do one thing and one thing only and you can write Unit Tests around them.
      • Code Activities pass data in and out of them through arguments which makes it extremely easy to Mock.
      • On top of that Workflow includes it’s own Service Locator pattern called “Workflow Extensions” which we’ve found to be easy to implement and efficient.
      • The next step up is the Workflow itself.
      • We tend to group all the activities for a particular process into a Workflow. For example in order processing we would group all the taxation related activities like checking if the customer was taxable, determining if we need to apply any special logic for particular tax scenarios.
        • We can write integration tests that test just this taxation workflow.
        • Just like Code Activities, Workflows have arguments that you can pass data into and get data out of so we can easily mock.
        • This can greatly speed feedback from tests because you don’t have to wait on external dependencies. An example is our order processing system.
    • Next we group these workflows into a main Workflow, commonly the Workflow hosting our service. We can then have our automated regression suite test the service from end to end.
  • It’s great for long running processes.

    • Combined with AppFabric you can have long running processes which can spin up and spin down as necessary. This means you can make more efficient use of your resources since when a Workflow isn’t running it’s state is preserved in the database and only processing at the moment an event causes it to reinitialize.
  • It’s built into the .NET Framework

    • There are no frameworks to download and install. It’s just there.
    • It’s built on some of Microsoft’s core battle-tested technologies like WCF and XAML.
    • You don’t have to go in whole hog. On existing apps you can identify a process you want to replace with Workflow and start from there. Workflows can be invoked from your existing code.
  • You’re not “locked in.”

    • If for some reason you decide you want to move away from Workflow you have a visual guide of how your processes are built and all your code activities are written in C#.

For a more in-depth review of why I think you might want to use Workflow Foundation in your solution, check out my appearance on .NET Rocks

Workflow Vocabulary

Next, let’s go over some of the vocabulary of Workflow Foundation.

TERM DEFINITION
Activity A unit of program behavior in Windows Workflow Foundation. Single activities can be composed together into more complex activities.
Activity Action A data structure used to expose callbacks for workflow and activity execution.
Argument Defines the data flow into and out of an activity. Each argument has a specified direction: in, out, or in/out. These represent the input, output, and input/output parameters of the activity.
Bookmark The point at which an activity can pause and wait to be resumed.
Compensation A group of actions designed to undo or mitigate the effect of previously completed work.
Correlation The mechanism for routing messages to a workflow or service instance.
Expression A construct that takes in one or more arguments, performs an operation on the arguments and returns a single value. Expressions can be used anywhere an activity can be used.
Flowchart A well-known modeling paradigm that represents program components as symbols linked together with directional arrows. In the .NET Framework 4, workflows can be modeled as flowcharts using the Flowchart activity.
Long-running Process A unit of program execution that does not return immediately and may span system restarts.
Persistence Saving the state of a workflow or service to a durable medium, so that it can be unloaded from memory or recovered after a system failure.
State Machine A well-known modeling paradigm that represents program components as individual states linked together with event-driven state transitions. Workflows can be modeled as state machines using the StateMachine activity.
Substance Represents a group of related bookmarks under a common identifier and allows the runtime to make decisions about whether a particular bookmark resumption is valid or may become valid.
Type Converter A CLR type can be associated with one or more System.ComponentModel.TypeConverter derived types that enable converting instances of the CLR type to and from instances of other types. A type converterr is associated with a CLR type using the System.ComponentModel.TypeConverterAttribute attribute. A TypeConverterAttribute can be specified directly on the CLR type or on a property. A type converter specified on a property always takes precedence over a type converter specified on the CLR type of the property.
Variable Represents the storage of some data that must be saved and accessed later.
Workflow A single activity or tree of activities invoked by a host process.
XAML eXtensible Application Markup Language

Additional resources:

The Workflow Way: Understanding Windows Workflow Foundation

David Chappell Chappell & Associates April, 2009 Download this article Everybody who writes code wants to build great software. If that software is a server application, part of being great is scaling well, handling large loads without consuming too many resources.


In my next post we will build out our project and start writing some code!

Warp Core Technologies Logo-Updated

Workflow Foundation Tutorial: Part 1 – Introduction

1 comment / February 8, 2016

I’ve found that the best way to learn a technology is to just go build something with it. Over the next several posts we are going to be building a complete order processing system using Workflow Foundation and since we need a fake client to build it for we will be taking inspiration from the Star Trek universe.

Our client: Warp Core Technologies. WCT is the leading provider of warp cores and warp core parts throughout the Alpha Quadrant. While the products they sell are cutting edge, their order processing system is not. We will be building a new order processing system using Workflow Foundation and by the end you should see the value that WF provides.

  1. Order Validation
    1. The Federation Council is always signing treaties or setting up blockades. We need to verify that the order is in compliance with Federation law before we proceed.
  2. Inventory Check
    1. Trade disputes mean we may not always have the requested parts on hand or there may be a delay.
  3. Currency Conversion
    1. WCT deals in Federation Credits but we serve clients using everything from Gold Pressed Latinum to Klingon Talons. We need to convert it.
  4. Taxation
    1. We need to cut taxes for the Federation and the destination planet.
  5. Invoicing
    1. We will generate a PDF (yes, they still use PDFs in the 24th century) and an email invoice.
  6. Payment Processing
    1. We need to take payment and notify our ERP system.

In addition to the basic requirements we also have some service requirements:

  1. Guaranteed delivery
    1. We will be using MSMQ to fire and forget the order. If the order processing system is down we want to hold the message until it comes back up.
  2. Support for user modifiable workflows
    1. We will be building a WPF application utilizing the rehosted designer functionality from WF to allow workflows to be modified on the fly.
  3. Testable
    1. We will be writing unit and integration tests to ensure compliance with business rules.

By the end of this series we should have a good overview of what Workflow Foundation can provide and how it will help our business.

Warnings Featured Image

Treating warnings as errors to help prevent technical debt

0 comments / February 3, 2016

Technical debt is a natural part of any project. Much like actual debt some is healthy to keep things going but you want to make sure you keep a close eye on your debt and you understand exactly what you’re taking on. My team uses SonarQube for helping to track and measure our debt. You can learn more about SonarQube in Samir Behara’s excellent post! However, we can manage a big source of growing debt with a simple project flag!

Most projects over time accumulate a large number of warnings. They aren’t really addressed because they don’t fail the build and they may not cause any perceived problems in your application but they can be sitting landmines. Many are just waiting to bite you during a framework upgrade or they may be trying to help you and show you a better way to implement a piece of code or remind you to remove some unused code.

Warnings box

One way we can address this is to turn on “Treat warnings as errors.”

  • Right click on the project you want to enable this on.
  • Select the “Build” tab.
  • Change “Treat warnings as errors” to “All”.

Treat warnings as errors

We have this option enabled for all our projects and it has made a significant difference in keeping our projects tidy.

One caveat, there are times you may want to exclude certain types of warning. For example, we exclude “Obsolete” warnings. Many times we will deprecate a property or API call and it will need to stay for a while, we just don’t want new people using it, so we mark is as “[Obsolete].” By default this will generate a warning (there is an overload that will generate an error). We don’t want this to prevent the build and luckily there’s a way to exclude it from the “Treat warnings as errors”. This is not to be confused with “Excluded warning type”, these will still show as warnings, they just won’t cause an error. All we have to do is:

  • Right click on the project and chose “Unload Project.”
  • Right click on the project again and choose “Edit”
  • Add ” <WarningsNotAsErrors>612,618</WarningsNotAsErrors>” above “<TreatWarningsAsErrors>true</TreatWarningsAsErrors>”


612: The compiler warning code for the [Obsolete] tag

618: The compiler warning code for the [Obsolete(“Message”] tag

Now, you must consistently check and make sure your removing calls to obsolete methods or properties on a regular basis but it will be much easier now that we’ve reduced the noise in our “Warnings” window. This is a feature I encourage everyone=

Microsoft GitHub

Porting Workflow Foundation to .NET Core

1 comment / February 1, 2016

When many people hear Microsoft and open source they may think that it’s a contradiction in terms but the new Microsoft has jumped into open source head first! And the best part is they aren’t doing like some companies do open source and simply make annual code dumps onto a public repo. They do open source the right way and engage with the community, solicit support and accept pull requests.

Recently, I came across the thread for porting Workflow Foundation (one of my favorite technologies!) to .NET Core. I really want to see WF ported to .NET Core as it would serve to make WF a more powerful tool in the developer toolbox. If you love WF and want to help drive it’s development please consider leaving a comment on the thread. It can be as simple as letting the team and the community know how you’re using WF or it can be technical and get into the nitty gritty details of implementation.

[Contribution] Port Workflow Foundation to CoreFx/CoreCLR · Issue #2394 · dotnet/corefx

Hello, I don’t see in the plans neither here and coreCLR for porting Workflow Foundation for CoreCLR… We want know how can we start porting it and add PRs for it here. Thanks

Another thread to check out is porting System.Xaml to .NET Core. This is really a necessary step to getting Workflow in .NET Core but XAML also brings with it many other opportunities and would be very beneficial to replace the limited version of XAML that UWP currently uses.

Port System.Xaml to .NET Core · Issue #5766 · dotnet/corefx

Filed as a result of the discussion in #2394. Note: this doesn’t represent a commitment from us to open source System.Xaml or to even port it to .NET Core — it’s simply capturing the community re…

Microsoft has committed to Open Source. Now we must make our voices heard and take ownership of these fantastic products and work to make them better each and every day.

WorkflowIntegrationTest

Integration Testing Workflows

0 comments / February 1, 2016
Integration testing is the phase in software testing in which individual software modules are combined and tested as a group. It occurs after unit testing and before validation testing.

In my last post I discussed unit testing code activities. Now that we’ve verified our custom activities behave the way we want we need to test the workflow as a whole to ensure they work together correctly. This is called integration testing. This is especially important for WF as much of the logic may be encompassed in out of the box activities and thus not have unit tests around them.

The best part is we test workflows just like code activities!

In our test init we will setup our base mock object.

Next, in our “Because” method we will wire up the call to our Workflow.

Finally, we write our test.

This is great for workflows that need to conform to a certain behavior and you want to test to verify it or the integration tests can serve as validation for user updatable workflows to ensure that any specific requirements are still maintained.

You can see this test in action in a sample project available on GitHub.

CodeActivityUnitTest

Unit Testing Workflow Code Activities

0 comments / January 25, 2016
Unit testing is a software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinized for proper operation.

Unit testing is a lot like going to the gym. When you first start out it’s miserable, you question why you’re putting yourself through it but over time you start seeing the results and realize you should have been doing it all along.

I’ve gone through all those phases in my development career and I’ve now reached the point that I couldn’t imagine writing code and not writing unit tests and it’s no different when using Workflow.

First, let’s talk about a few of keys to writing a good unit test and how code activities play into that:

  1. Make each test independent.
    1. Tests should not rely on the result of any other test. Code activities and the visual nature of workflows help to point out where you may be trying to do too much in your code.
  2. Test only one code unit at a time.
    1. Code activities know nothing about other code activities. All data is passed using in and out arguments. While you can still overload your code activities with lots of logic, you should be able to “smell” the bad coding practice.
  3. Mock external dependencies.
    1. Workflow offers a fantastic service location pattern called “Workflow Extensions” (more to come in a future post on this topic).

Writing unit tests for code activities is almost identical to any other unit tests except in how you call the code. In our “Because” method we’re going to use the “WorkflowInvoker” to call the code activity and pass in our mocked up data through the arguments. We’ll use our Loan example from my earlier post to illustrate.

In our test init we will setup our base mock object.


public void TestInit()
{
_result = new bool?();

_loan = new Loan
{
LoanAmount = 100,
DownPaymentAmount = 20,
CreditRating = 700,
HasCollateral = true
};
}

Next, in our “Because” method we will wire up the call to the code activity.


private void Because()
{
//Create a new instance of our code activity
var validateLoanIsCompleteActivity = new WorkflowWebApiExample.CodeActivities.ValidateLoanIsComplete();
//Create a new WorkflowInvoker instance.
var workflowInvoker = new WorkflowInvoker(validateLoanIsCompleteActivity);
//Create a new input argument dictionary
var InputArguments = new Dictionary<string, object>();
//Add our argument to the dictionary.
InputArguments.Add("Loan", _loan);
//Invoke the workflow and capture the result.
var resultDictionary = workflowInvoker.Invoke(InputArguments);
//Cast the result to the appropriate type.
_result = (bool)resultDictionary["Valid"];
}

Finally, we write our test.


public void Should_return_false_for_valid_if_loan_amount_is_0()
{
_loan.LoanAmount = 0;

Because();

Assert.IsFalse(_result.Value, "Expected to receive false when the amount was 0 but _result was true.");
}

It’s just that simple. There’s no real reason to not write tests for your code activities.

You can see this test in action in a sample project available on GitHub.

OrleansActivitiesFeatured

Projects to Watch: Orleans.Activities, Windows Workflow Foundation on Orleans

0 comments / January 25, 2016
Orleans is a framework that provides a straightforward approach to building distributed high-scale computing applications, without the need to learn and apply complex concurrency or other scaling patterns. It was created by Microsoft Research and designed for use in the cloud.
Microsoft Orleans (GitHub)

I just came across a new GitHub project, Orleans.Activities, which combines Workflow Foundation with the Microsoft Research project, Orleans (most notably used by the backing services of Halo). Orleans is based on the actor model and allows developers to build complex highly scalable applications very easily.

Orleans.Activities seems like a natural fit for Orleans as the visual nature of Workflow will make these complex applications easier to understand and model the flow as well as leverage Workflow’s built-in support for long running workflows.

I will be keeping a close eye on this project and look forward to seeing where it goes.

Older