I am one of the co-founders of the Birmingham .NET Meetup alongside Robb Schiefer. Several people have asked about our process for recording videos of the meetups so this post will give a rundown of my equipment and explain the process.

There are two facets of the video portion, the footage of the speaker and the footage of the presentation.

I use a Panasonic LUMIX GH4 for the video. I chose this camera as I was looking to replace my existing DSLR and wanted a camera I could use for both photos and videos. While doing research, I discovered the vast majority of DSLRs and mirrorless cameras limit video recordings to 30 minutes due to EU regulations 1. Now, I am a videophile so I wanted a pretty nice camera but if you’re just getting started the camera is one of the less important aspects of your video since the main focus is the presentation itself so don’t get to hung up on thinking you need a super high end camera. One thing to invest in is a decent tripod. Amazon Basics has a good, fairly rugged, inexpensive tripod that I use a lot. You’ll be amazed at the difference a good tripod will make!

The second piece is recording the presenter’s screen. I use an AV.io HD USB capture device. It includes a DVI input and I use a Y-splitter to send the video signal to both the capture device and the projector. I also have various adapters for handling DVI, DisplayPort, MiniDisplayPort, HDMI and the venerable VGA. The capture device connects to my computer via USB and shows as a webcam. I can then use any software that can capture webcam output to record it. I use a MacBook Pro and use QuickTime to capture the video however you can do the same on Windows with any number of software packages including VLC. I’ve had issues withe PowerPoint forcing a different resolution than the desktop which causes weird artifacting so make sure and do some checks before you start.

One thing that is very important to make life easier when editing is before you begin is to point the camera at the screen and put up a slide with an instant transition and change slides a couple of time so that you have a reference point to sync the videos. In your editing software you just need to move the videos until the slide changes are insync 2.

Another very important part of video production is audio. It doesn’t matter how good the video is if your audio is poor it can ruin the whole thing. Don’t use the onboard mic! The best way to get good audio is a wireless lapel/lavelier mic I have several different wireless mic systems but a good starter system is the Saramonic Wireless Lavelier. You have two options for recording your audio. Depending on your camera you can use an audio input. High end cameras will have an XLR input, lower end and DSLR/Mirrorless will often time have a 3.5mm TRRS input (A.K.A a headphone jack). The Sarmonic listed above comes with a “mixer” to feed the mics into and plug into a 3.5mm jack. A second option is to record the audio separately and mix in during editing. This is good when you want to have the camera in a location that is not practical to have audio sent to it or you’re tapping into a live mix and the camera is not nearby. I use a Zoom H5 for this. Before we begin, I start recording audio on the Zoom and the onboard audio on the camera and give a loud clap. The clap will show us a spike on the audio waveform in the editor and it gives me a good place to sync 3 . Some editing software can do the syncing automatically. Protip: Always have extra batteries on hand!

For editing I use Adobe Premiere. It is a fantastic cross-platform video editing platform and is included in the Adobe Creative Cloud Suite. Ideally, I try to do as little editing as possible. A single camera angle in the bottom corner with the presentation full screen. In general editing takes 10-20 minutes and the rest is just encoding. I encode at 1080p H.264 and upload to YouTube.

Overall the process isn’t that complex and you can get started with fairly inexpensive equipment.

NOTE: This applies to all editions of Visual Studio 2017 exceptCommunity. RC2 is slated to have Workflow as a separate install-able component and it will then be supported on Community.

I was recently trying the Visual Studio 2017 RC to test out the new features. To my surprise, when I loaded it up one of my Windows Workflow projects it just threw build errors. What was going on?

As it turns out, it’s not a bug, it’s a feature! One of the headline features of Visual Studio 2017 is a smaller footprint and a MUCH faster install experience. A basic install of Visual Studio can now be stood up in less than 5 minutes. The only problem is that many features that previously “just worked” on a brand new install of Visual Studio now throw cryptic build errors since the supporting components aren’t installed. Thankfully, it’s easy to install these components.

In the Start menu click the Visual Studio Installer.

Then click “Modify” for your version of Visual Studio.

For Workflow Foundation we need to go to the Workloads tab and click…Office/SharePoint Development (Workflow is heavily used in SharePoint). For other components click on the “Individual components” tab and check the boxes for anything you want to install.

Once the installer completes we can rebuild your solution and now our Workflow project builds!

Hopefully Microsoft will improve the experience and prompt to install missing components instead of just displaying cryptic messages but until then it’s very easy to correct.

For a more in-depth review of the new Visual Studio install process check out this post from Samir Behara.

Last week I attended the AWS Re:Invent Conference in Las Vegas. It was a great week filled with lot of information and cool announcements from Amazon. As part of the event the Alexa team ran a contest to see who could make the best new Alexa skills. My colleague, Robb Schiefer and I decided to enter the contest with a skill that allows you to manipulate Trello using your voice called Trellexa.

Unfortunately, we did not win, however, we learned a lot about building Alexa skills and we even built it with .NET!

First, here’s a list of the steps we took to create this demo.

Create a new project in the Alexa Developer Console

Develop an intent schema and sample utterances

Create an ASP.NET project to host our skill web service

Install the AlexaSkillsKit.NET Nuget package and configure with Alexa

Setup hosting in EC2 with a valid FQDN and SSL certificate

Install the Manatee.Trello Nuget package and configure with Trello

Test HelloWorld to prove connectivity between Alexa and service

Add logic in the service to handle each intent/utterence

Configure account linking to link the user to their Trello account

Next, let’s review some of the basic concepts of Alexa. An Alexa skill is simply a web service that responds to the REST calls made from Amazon when your skill is invoked. To control your skill you define “utterances” with all the possible things that a person might say (ex. “Create a new todo item”).

These utterances map to an “intent.” Intents are defined using a simple JSON schema. The intent data is sent to your service where you can then take the appropriate action. You can also collect additional info from the user by using “slots” in your utterances (ex. “Create a new todo item called {ItemName}.” Your utterance list should contain as many possible ways to trigger the intents as you can think of. At its core this is what is required to make a skill!

To ease our efforts we used the fantastic AlexaSkills.NET Nuget package created by a really cool service called FreeBusy. This package wrapped the Alexa calls into a nice friendly API which matches method for method with the official Java API.

Let’s take a look at how we handled a “CreateItem” request.

As you can see there is very little code needed to wire up to Alexa. Here is the code that builds to speech response.

Now we did run into a handful of issues, however, none of them were related to .NET. Amazon requires that all calls be made to an endpoint secured with TLS, even in dev. This added some complexity to our setup but were ultimately able to resolve it. Also, our application needed to link with Trello using OAuth. Amazon only supports OAuth 2 and unfortunately Trello only supports OAuth 1. This required us to get a little creative and build a wrapper to pass the request from Amazon to Trello.

Overall this was a very fun project and I was amazed that in around 2 days between conference sessions, Robb and I were able to learn two different APIs and build a working product. I will certainly be looking for other opportunities to build skills and I encourage you to give it a try too!

We love Trello and us it to manage everything. From our daily todo list to more specific project work with a full Kanban board. So naturally we wanted Alexa to help us manage that via spoken word instead of always typing on a physical device.

Wilt 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.

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.

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.

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!

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:

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!

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 Trekuniverse.

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.

Order Validation

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.

Inventory Check

Trade disputes mean we may not always have the requested parts on hand or there may be a delay.

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.

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”.

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:

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=

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.

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.