• MSBuild no longer copys Newtonsoft.Json.dll during build.
• Build does not fail because old copies are in output folders.

8/11 - Newtonsoft.Json.dll 7.x is added to ClientProject.Services

• Build does not fail because this is not yet deployed.

9/8 - ClientProject.Services is referenced by ClientProject.Endpoint

• Local builds do not fail because last copied Newtonsoft.Json.dll is still 6.x
• Dev build copies Newtonsoft.Json.dll 7.x because it is not in the GAC.
• Dev deploy does not fail because 6.x is in the GAC.

9/11 10:00pm - ClientProject.Endpoint is deployed to UAT

• Endpoint fails to start with AutofacDependencyResolutionException and does not display inner exception details; eventually get to underlying dll load exception.

9/11 11:40pm - All projects corrected to use same verison of 6.x

• Build still copies 7.x from dirty output folders.

9/11 11:55pm - Folders are cleaned and Build is run again

• No longer copies any Newtonsoft.Json.dll
• Finally piece together how events of 7/10 are tied to how MSBuild works and how the default copy local=true means only if not GAC'd but copy local=true after being toggled off then on again puts <Private>True</Private> on the reference which really means always copy. No seriously, that's a thing.

9/11 1:00am - Fix reference in the ClientProject.Endpoint by toggling CopyLocal off and back on.

• Confirm correct deployment in UAT!

9/11 1:30am - Discover that a workaround/fix exists in a later Nuget.

• Discussion: https://nuget.codeplex.com/workitem/4344
• Fix: https://nuget.codeplex.com/SourceControl/changeset/0b1c96abc37a5b3d8b482c686741e7b20e545790, btw "Try jiggling it" - is a great description for that commit.

9/11 1:45a - Quit software development forever (or until morning whichever comes fist).

9/12 - UPDATE NUGET in Visual Studio

Introduction

Azure WebJobs is really easy to work with. All you need to is build a console app, put in the functions you want available, and attach it to your website for automatic deployment. Scott gives a great intro in his Introducing Windows Azure Webjobs post, so I will try not to duplicate that here. I've found the Microsoft Azure Blog is the best resource for the latest information and as of the publishing this I'm looking the 0.4.0-beta preview.

One thing I will reiterate is how great the WebJobs control panel is. Through the panel you can see the status of running jobs. You can see a history of the various functions including inputs an outputs. You can choose to replay a particular function or enter the inputs manually and trigger a run. It also understands causality between functions so that it knows when a particular function was triggered by another.

Building an Order System

Azure WebJobs is setup to make it very easy to work with Queues and Blobs in Azure. I thought it would make a lot of sense to separate the actual order process from the website as much as possible in part to be as defensive against failures as I could. I was using Stripe for payments and Mailgun for transactional email. What happens when one of these services is down? Using a queue to manage the orders fits perfectly. A transient failure can occur and the message replayed.

When I first started to develop the order system I had one function that was basically "Order a License". The function would complete the charge with Stripe, create the license, and email a link to the customer. I quickly realized this is less than ideal. If, for example, the email were to fail I would have to come up with a different way to send the email. Replaying the function would either fail or create a duplicate charge and would not be helpful.

The obvious improvement was to separate each step into its own function. This resulted in three distinct functions:
1. OrderLicense
2. GenerateLicense
3. SendLicense
Now if the mail service were temporarily down I could simply replay the SendLicense function.

Order License

This completes the charge with Stripe then passes a message to the next queue to generate the license. I kept this function particularly simple because once someone has decided to make a purchase then completing the charge is extremely important. Everything else can be corrected or done manually, but I can't expect customers to make the purchase a second time.

Generate License

This function takes the information in the order and creates the license file. The license file is stored as a blob. This blob is registered as an output. Now I did overload this function a bit and also use it to store a record of the order and the license. I may need to refine this later, but so far this has been just fine. Once complete this function outputs a message to trigger the next function.

Send License

This function only sends the final email to the customer thanking them for their purchase and including a link to their license.

WebJob Magic

Authoring these functions is really easy thanks to the WebJob SDK. Each one is based on a QueueTrigger to start the function. They also have other inputs and outputs all of which are specified using special attributes on the parameters of the function. The GenerateLicense function for example writes a license entry to a table and generates the license file as a blob. These are simply handled as arguments to the function:

[QueueTrigger("generate")] Message message,
[Table("Licenses")] CloudTable licenses,
[Blob("licenses/{TransactionId}.license")] out string license

This kind of stuff makes working with Azure really easy. Note the use of {TransactionId} in the Blob attribute. This automatically pulls the transaction id from the trigger message and uses it as the name of the blob. I simply set the string before exiting the function and the blob is created.

The send license function takes similar advantage of the WebJob attributes:

[Table("Orders", "{Email}", "{TransactionId}")] OrderEntity orderEntity

Again this uses special notations {Email} and {TransactionId} to automatically use values from the trigger message as the PartitionKey and RowKey for the table. The SDK then supplies the function with the matching row in the argument.

Ultimately, the Azure WebJobs SDK does a good job of letting me describe the function with its inputs and outputs in terms of Azure components. This creates expressive code and reduces boilerplate.

Beta Blues and Some Tips

• There are some caveats to using WebJobs right now. It's a beta preview. I haven't found any particular issues with bugs, but the behavior can and will change from release to release. When releasing 0.4 for example, the Azure service was updated to use new connection string names. Use at your own risk and be attentive to changes.

• As of this writing beware of using slots. I recently deployed a staging slot and a production slot. I eventually switched to move staging to production but this left the old version of my continously running job side by side with the new version. This can lead to bad things.

• Failures in functions didn't always work as I expected. By design, a blob will be created as an output even on failure. Read the blog posts from the team carefully and test! Version 0.4 seems to handle some scenarios better and introduces automatic handling of poision messages (those that repeatedly fail).

• When upgrading to 0.4 my orders started taking a lot longer to process. By design, the new version of the SDK will back off checking the queue when its empty. This can be controlled in configuration with the MaxPollingInterval setting.

• Version 0.4 of the SDK includes a way to automatically deploy the WebJob project along with the website. Prior to this I used the WebJobsVs extension. Update regarding my publishing problems - DO NOT CHECK "Exclude files from the App_Data folder". At some point I did this and only on the production settings (smacks head), but App_Data is where jobs are published! Unfortunately for me the website included an unneeded reference to the webjob project so I would see the DLL copied into Bin during Publish and it didn't click right away that this wasn't the right place.

• I used the Windows Azure Configuration Manager for all settings and connection strings. This allows me to keep my development settings in the config files, but use the Azure settings upon deployment.

• Google around for some good information on debugging, but at least know that you can just run the console app locally in the debugger as long as the config is pointed to the right storage account. Don't forget to stop the jobs on any development slot pointed to the same account.

Wrap up

Be cautious about the beta preview status, but the Azure WebJobs SDK provides a powerful way to express the functions "jobs" that your website needs to perform in the background. I can imagine that it will become even more useful as it approaches release and seems like a no-brainer option if you are already using Azure.

There are still plenty of features in Dash (the inspiration for Velocity) that I plan to be working on and I have plenty of other ideas too. It would be great to get feedback on what you would find most valuable to help me prioritize what is next. I've already been speaking with Gerard Delmàs and testing his new release of the IntelliDash plugin, so I think something will be available soon. I will also be looking into a Visual Studio integration as soon as I can.

I'm committed to this product, but nothing gives a bigger vote of confidence than buying a license. My hope is that you'll find Velocity a tool worth paying for and if you don't please let me know how I missed the mark so I can continue to make improvements.

If your interested in the backstory of Velocity then please read the The Velocity Origin Story. It tells a little about me and how Velocity came to be.

Let the journey begin.

Updates

• Bogdan posted Meet Velocity for Windows on his blog.
• The extension for Visual Studio, Search in Velocity, is available now.

How Did I Get Here?

I've been an independent developer since 1997. That's a long time to be on your own. I've had good years and bad, but I've felt for quite a while now that I was doing it wrong.

I build products, but a lot of my work has really been bespoke development. I'm proud of the work I've done and my products have been successful for my customers. My form design software has been used to design the industry standard insurance forms since 1998.

The problem with my business is that it was never really a sustainable business. My products are licensed to a single or handful of customers at best. Many times I was lucky enough to secure a contract just when I needed it, but I've spent a lot of time wondering if I would be able to pay my bills and I can't even imagine what it would be like to go on vacation anymore.

Near the end of 2013, I finished a four year fixed-cost project that left me realizing I needed a change.

Keep Moving Forward

"Around here, however, we don’t look backwards for very long. We keep moving forward, opening up new doors and doing new things, because we're curious… and curiosity keeps leading us down new paths" – Walt Disney (as displayed at the end of Meet the Robinsons, a lesser known but endearing Disney movie.)

I've had that posted on my desk for quite some time with the words "keep moving forward" underlined. I feel like I'm someone prone to getting stuck and this serves as a reminder to just keep taking that next step.

I started to look over contract and job opportunities and soon realized how beneficial it would be to have a public reputation. But it was more than than that too, because for many years I watched others write blogs, participate in open source, and grow businesses from nothing (like StackOverflow or Balsamiq). I wanted to be doing these things. I've been watching this community of people like me do awesome stuff and I wanted to join in. It quickly seemed like a no-brainer; do some things you want to do and maybe help your future in the process.

I wanted to be doing these things. I've been watching this community of people like me do awesome stuff and I wanted to join in.

So the first thing a did was dust off a project I had started and stopped a few times over the years and decided it was interesting enough to turn into an open source project. Thus ProxyFoo was born. It's a library I had wanted much earlier for my large project, but unfortunately couldn't spend the time on it then. I hope it's useful for others and I get excited every time I see my download number go up on Nuget (a paltry but "cool to me" 127 as of writing this).

I also started this blog. As I mention in my first post, this was something I wanted to do for a long time. I know me, I know I'll never be a writer on a consistent schedule, but I do enjoy it. For me, this has always been one of those "do something that scares you" activities. I get very uncomfortable very quickly when sharing things about myself. This post is huge for me.

And now, at the very least, someone can take a look at my work, can take a look at my writing, and get some idea of who I am, but I still need to make a better living.

Serendipity

One project I think I've managed to spend a week on over the last few years is a little football pool app I use on the iPad for a family SuperBowl party. In the course of working on it I discovered Dash. Now, I tend to spend far too long researching products, so even before I downloaded it I had a pretty good idea of its reputation. I used it for a day or so and went back to work on Windows.

I was lucky enough to find the post on Bogdan's blog. He was looking for developers to bring Dash to other platforms.

I am actively looking for developers of other platforms (iOS, Android, Windows or Linux) that would like to work on a Dash-like app, as their own project and for their own profit. – Bogdan Popescu Dash for iOS, Android, Windows or Linux

The bottom line was that in return for linking back to Dash he would allow access to the docsets on his servers.

I printed the page and let it sit for a couple of weeks. On February 12th 2014, I filled out the form on his website and let him know I was interested.

His permission to work on the Windows platform was not exclusive which I knew made this risky. I had thought about developing some product ideas of my own, but I felt the thought of starting something from scratch was even more risky. I needed to do something and at worst I felt Velocity would be a great product to add to my resume.

The first month I split a lot of my time between Velocity, ProxyFoo, and existing support work. It was a slow start. I emailed Bogdan again, and found that I was not the only developer making progress.

Shortly after, around April 2014, I began to focus on Velocity exclusively. I ran into some interesting problems but managed to work through them all. I'm sure there is good material for a blog post or two. Eventually I was the only developer updating Bogdan, and after three long months, on June 23rd, I released the first Beta of Velocity. Bogdan was great to work with and very helpful.

Finding Joy

Over the past month, a funny thing happened. I've realized just how right this decision was. I wanted to have my own business making software since I was a kid and this is bringing back that feeling.

Every download, every page view, brings me excitement. When Bogdan (@kapeli) re-tweeted my Beta announcement I got more traffic to the Velocity website in an afternoon then I see in weeks on my company website. I was literally running around the house screaming new country names at my family. I got hits from all over the world and over the next few weeks I saw error messages reported to me in Swedish, French, and Chinese. This is Awesome! In the grand scheme of things my page view numbers were still very small, but even if this never gets bigger I have absolutely loved the ride.

I also found that it's a pretty cool experience to have a person you don't already know appreciate your work. I got a positive email from one user who ended up as my first customer for Velocity, and it felt pretty darn good.

All In

I'm about to release v1.0 in the next day or two and I'm quite nervous. I don't think it was as clearly defined when I started my business, but it seems obvious to me now that what I really want is to be an "indie" developer. A guy that makes small products people enjoy using and makes a living do so. Time isn't exactly on my side (which is why I'm still looking for contract work - see my careers page) and I don't know what the future holds for this, but here I am - all in.

Background

Early on in development I would occasionaly save a generated assembly and run PEVerify on it. As the project got further along I would simply rely on tests to determine if the generated code worked as expected, but I knew eventually I would want something more robust.

Code generation in ProxyFoo always takes place in a dynamic assembly managed by the ProxyModule class. In order to create an easy to use API all of the static methods will create and use a common default module. The library provides a way for this default module to be cleared which I take advantage of for test seperation. I wanted to use PEVerify as part of every test too.

PEVerify in Testing

To make it easy to reuse, I created ProxyFooTestsBase as a base TextFixture for tests with generated code.

The SetUp configures the default ProxyModule with a unique assembly name for the test and with flags that allow it to be saved.

[SetUp]
public virtual void SetUp()  
{
    string assemblyName = "ZPFD." + TestContext.CurrentContext.Test.FullName.Replace("ProxyFoo.Tests.", "");
    foreach (var c in Path.GetInvalidFileNameChars())
        assemblyName = assemblyName.Replace(c, '_');
    var assemblyPath = assemblyName + ".dll";
    if (File.Exists(assemblyPath))
        File.Delete(assemblyPath);
    ProxyFooPolicies.ProxyModuleFactory = () => new ProxyModule(assemblyName, AssemblyBuilderAccess.RunAndSave);
    ProxyFooPolicies.ClearProxyModule();
}

I prefixed the file with 'Z' for the simple reason of having them be listed last when reviewing build output. The next to last line overrides the default factory method to use the custom name and allow for saving; the last line clears any static content related to the ProxyModule. I had never used TestContext before this, and was glad to find it.

[TearDown]
public virtual void TearDown()  
{
    if (!ProxyModule.Default.IsAssemblyCreated)
        return;
    ProxyModule.Default.Save();
    if (TestContext.CurrentContext.Result.Status==TestStatus.Passed)
    {
        var assemblyPath = ProxyModule.Default.AssemblyName + ".dll";
        Assert.That(PeVerifyAssembly(".", assemblyPath), Is.EqualTo(0));
    }
    ProxyFooPolicies.ProxyModuleFactory = ProxyFooPolicies.DefaultProxyModuleFactory;
    ProxyFooPolicies.ClearProxyModule();
}

TearDown does the real work. If the test passed it saves the assembly, runs PEVerify, and asserts that no issues were found. This is also convenient when debugging issues with generated code, because I know have a unique assembly as part of the output I can load in Reflector (or other dissasembler) to review the code. If necessary the passing test condition can be commented out, but I haven't needed this very often.

When I first added this to my existing tests, I did to my surprise find several instances where everything ran fine but failed verification. In my case I found failures for not calling object's ctor from a generated class and a couple of cases where castclass was needed.

Conclusion

My original concern was for compatiblity. What the CLR lets slide now might not be allowed next time, and after reading Marc's article it was good to see there was even more reason to be this strict. There's nothing earth shattering here so I'm sure this pattern could be adopted for testing generated code in other situations. Sigil also looks really interesting, but in the case of ProxyFoo I wanted to avoid dependencies if possible.

I've recently taken the leap to start using Git, mostly so that I could share ProxyFoo on GitHub, but I've been happy enough with it to start using it on an internal project also. I wanted a simple way to have a central GIT repository for my internal projects. I didn't find the any of the "server" projects that appealing or overkill and since I'm a lone developer I'm choosing to go with the simple file sharing approach for now. I'm using SourceTree as a client on Mac and Windows.

Why

My development machine is backed up daily and I work alone so I don't absolutely need to have a central repository. However, I've always felt there should be a central repository that is the "master". I run an in-office server for backup, file storage, and builds so this fits in well. Once the project matures a little bit I'll probably set up a continuous integration server like TeamCity. No requirement for building a product should only live in your development workspace. You should be able to pull down from your source control, maybe install a few prequisites (which I store centrally) and build.

I also have some projects on Mac OS X on my laptop that I would like to backup as well and this machine is not backed up regularly. (On the Windows partition I do not have anything on my laptop that is not mirrored from my desktop machine.

What I did

Note that this is for when you have an existing local repo first. Replace Server with your server name, Git with your share name, and Repo with your repo name.

1. Setup the master repo

• I created a file share called Git with full access permissions and then adjusted the file permissions for my account to have access to the folder.
• I used git init --bare //Server/Git/Repo from the command line to create the bare repo. (A bare repo has no workspace which is precisely what I want for master repo.)

2a. Connect a Windows repo

• Using SourceTree, add a new remote. You can do this from the main menu Repository->Add Remote... or from the Remotes header in the repo view and right click New Remote... Select the Add button on the Remotes tab and you should see the following dialog and enter the Remote Name as "origin" (or check Default remote) and enter the server path as //Server/Git/Repo.

2b. Connect a Mac repo

• Connect to the Windows file share using the Finder. From the menu Go->Connect to Server...
• Set up an automatic connection to the network drive on login.
• Using SourceTree, add a new remote. You can do this from the main menu Repository->Add Remote... or from the Remotes header in the repo view and right click New Remote... Select the Add button on the Remotes tab and you should see the following dialog and enter the Remote Name as "origin" and enter the server path (this is important) as /Volumes/Git/Repo.

3. Push

Well here it is. I registered this domain in 2007, so it has only taken me 7 years to get to this point. I'm not making any promises about posting regularly or often, but I do hope to provide value to anyone patient enough to read what I write.

I'm hoping to do at least a small series of posts on ProxyFoo which is my first open source project. I've had several open source projects that helped me along the way and I'm trying to increase my participation.

I've had the pleasure of working with the great libraries listed below (and more including the projects that some of these works depend on) and I am very greatful to the authors.

• Autofac
• Castle.Core
• Dapper-Dot-Net
• DotNetZip
• Jekyll
• Json.NET
• Mono.Cecil
• NPOI
• NuGet
• NUnit
• Protobuf-Net
• ServiceStack v3
• Windows Installer XML (WIX) Toolset
• Word Lists Collection
• Zlib

*Number 1! by Dave Mc Clear is licensed under CC BY 2.0