DotNetFringe

This week I had the pleasure of getting to attend the DotNetFringe conference. This was hosted in Portland, OR (a place I had never been) and it was an outstanding conference. Thank you to all of the organizers for putting on such a great event.

pips_bounce

I have been a long time fan of OSS and I’m always looking to learn about new ways of doing things. One of those things that I have been thinking about lately is what are the next big changes in software development, specifically for .Net usually. What is the next IoC container for .Net applications? After watching a talk on Reactive Extensions by Amy I continue to be convinced that those who really understand functional programming and state management will be making the systems that I want to work on in the future.

I’ve been playing in Clojure for the last year or so and it has really changed the way I see software. Early this year I started porting all of my build scripts to FAKE (F#) and I can see how powerful F# is and the beauty it brings. I’m also watching with rapt attention the developments on the client side in terms of react.js and the various ClojureScript projects that take this model to the next level. These projects seem to really take something that is normally quite messy and make it simpler. My ability to reason about my F# and Clojure projects is an order of magnitude better than my OO projects from 3 years ago (because my current OO projects have larger doses of a functional aspect to them).

I think that this all dovetails nicely with the discussion around different forms of state management on disk as well. Looking at tools outside of the traditional RDBMS and looking at Graphs and Document databases.

State brings with it a lot of difficulty, its one of the reasons why I like working on Websites more than Native applications. But with these new tools coming about, maybe I should give it a second look.

Thanks again to the entire team running DotNetFringe!

Posted in Uncategorized | 2 Comments

A short note on build tasks

Surely, I’m behind the curve here but I’ve been thinking about the typical build process here at work. For a long time I’ve been operating off of the classic model from back in my NAnt days where it was all about Build -> Unit Test -> Integration Test. Maybe if you are feeling fancy you have some different steps for running database migrations or running other code analysis tools.

However, I’ve been working a lot with the concept of microservices in my side project. Trying to figure out where they break down and where they shine. Also, just trying to figure out the practical issues with running them. There is so much going on in our domain right now that trying to keep up can seem like a tidal wave. So if you are new to some of these concepts, well – so am I. :) The following is a brain dump of ideas for managing all of this crazy.

Package

First, I’ve started adding a few new steps to my build process. First off, is a reminder of how important a ‘packaging’ step is. Rob and I built this into UppercuT but its really coming back to me how important this is. I think its critical to realize that your default build output may not be enough packaging. In Visual Studio (well for me anyways) there is a very common behavior to just grab the ‘bin’ output and run. Because I need to package up my source better, I am now running my build step, then moving/copying all of the deployable content to something like a ‘build_output’ folder.

For those of you doing classic Visual Studio / C# / .Net development, I strongly recommend that you break out of your IDE for this. I would invite you to look at the power contained in your command line tools, even CMD can be used with great good. From there look at PowerShell. For me its bash, but I really need to look at ZSH.

Now that everything is in the ‘build_output’, my next step has been to run various HTML/ASPX/CSS/JS minification programs (and the litany of lilliputian tools arrive) to compress and optimize my application. Next step has been to then package all of this build_output content into a deployable unit. For my .net apps this is a NuGet via OctoPack and for my side project it has been Debian files.

Push

This leads me to my newest build task, push. Push for me takes all of my nice new build output and makes it available to the larger audience. Note that this step could be run by me or by my automated build tooling, but what it does is simply take the assets and for my .Net projects throws them in Octo’s NuGet repo or for my side project uses fpm/deb-s3 to generate my own Debian repository so that I can then pull these assets down and deploy them in testing / staging / production and have a consistent experience.

So, nothing really earth shattering here, but I wanted to share my thoughts. Also, I find these kinds of topics hard to find out there in the interwebs. If you have any great articles around the topic please do share in the comments.

Posted in Uncategorized | 1 Comment

The Business Value of Short Branches

Context: I recently wrote this for an internal email. I thought I would share it with the rest of my friends. :)


In the world of software development, we can’t say it’s done until the code is in production, working, and providing the company with value. It doesn’t matter how pretty my code is, if its sitting in a branch. 

Show me the Money
 

One way to understand the reality that shipping early and often provides more value to the company is to take a look back at Finance 101. Now if you managed to avoid this class, you may have missed out on a very cool concept, the “Time Value of Money”. This concept states, among other things, that $100 today is worth more than $100 tomorrow

In the book ‘Software by Numbers’ the authors discuss just this in quite some detail. If you can get a hold of a copy, even reading chapter 2 is quite eye opening.

But let’s go over a simple example to see what we are talking about. One of the equations that came out of the Time Value of Money is the “Present Value”. The present value (PV) of a sum of money is equal to the future value (FV) multiplied by one plus the interest rate (i) to the power of the number of payments (n) or PV=FV*(1+i)-n 

For example, lets say we have the awesome new feature X. Feature X is going to bring the company a value of $10,000 once it ships, and if you will humor me, the interest rate of this investment is 10% (more than likely this number would be based on another financial term IRR but lets leave that alone for now). The last part is the ‘n’ and this is the one we are going to play with. In terms of shipping software the value of ‘n’ is going to be the number of times we ship. 

So if I said shipping feature X would give the company a business value of $10,000. And we shipped it all at the end the PV of that feature would be PV=$10,000*(1+0.1)-2 or $8264.46. The ‘n’ is a 2 in this case to represent the cost of waiting two releases (the amount the next example is going to use). But what if we broke this up into two releases, each one providing some value but not the whole value. Furthermore, let’s say the first release doesn’t provide a lot of value, so $3,000 and $7,000. Using those numbers then then the first release has a PV of PV=$3,000*(1+0.1)-1  or 2727.27 and the second release has a PV of PV=$7,000*(1+0.1)-2 or $5785.12. If you add that up $2727.27 + 5785.12 = $8512.39. That’s a gain in business value of $247.93, just because we shipped multiple releases. 

Not only that, but there is another part of this story that we haven’t discussed. Let’s say we ship the first part and learn that if we make a few tweaks to the project we could net more than $7,000! If so, then the return for the company goes up even higher further increasing the business value of the project over the original $8,264.46. Conversely, we get the added benefit of the other side of the coin. If after shipping the first iteration we notice that the business has changed and we need to move in another direction, then we have only cost the company for the first iteration, shipped it, got some value and can now redirect onto another, more lucrative, project.

So, enough with the fancy math. How can we actually take what we have learned and apply it to our day to day jobs? One of the simplest ways to detect this is to look at how old your branch is from master. Have you been working on a branch for a week, two weeks, a month? That might be too long, or you may be trying to push too much into one branch. Can you break the work up so that you are shipping code sooner? Teams that practice Continuous Deployment will often ship the database changes way before the application changes. Then they might deploy the new code behind a feature toggle so that stakeholders can review, and then finally they will make it active to the user base. Each one of those is a push towards a specific feature and each one provides value to the business in terms of feedback on the progress, on how the systems will react to the changes, etc.

So think about how you can make smaller branches that will push into master sooner. As a team member, once a PR hits Github take a moment to help the teammate out and give it a code review, the quicker we can give feedback to our colleagues the faster we can all learn and improve the way we work. In addition we don’t want WIP to hang out too long either. A topic for another post as this one is quite long already.

Posted in Uncategorized | 2 Comments

Message Context and MassTransit

Did you know that MassTransit has the ability to ‘smuggle’ data? Now maybe smuggle isn’t the right word, but messages in MassTransit have the ability to carry ‘more’ than one contract of data.

For example, at work, some of our integration partners provide us with extra data that we need later on in the order life cycle. This data is unique to the provider. In the past this lead to the usage of some patterns I dislike such as the ‘mystery meat’ where we stuff data into a dictionary and use magic strings later to get it
back out.

public interface RegisterSalesOrderWithMysterMeat
{
    string OrderId { get; }
    //other properties
    IDictionary<string, string> MysteryMeat { get; }
}

the alternative of course is to extend your nice clean model with partner specific payload

public interface RegisterSalesOrderWithMoreStuff
{
    string OrderId { get; }
    //other properties

    //shopify stuff
    string ShopifyOneOff { get; }

    //bigcommerce stuff
    string BigCommerceOneOff { get; }
}

I am not a fan of either of these approaches. A third approach creates a message per integration partner, not a bad approach either in my book, but today I want to show of the Message Context in MassTransit, so I am going to ignore it.

Check this out

public class RegisterSalesOrderConsumer :
    Consumes<RegisterSalesOrder>.Context
{
    public void Consume(IConsumeContext<RegisterSalesOrder> context)
    {
        //normal payload
        var salesOrder = context.Message;

        IConsumerContext<RegisterShopifySalesOrder> shopifyDataContext;
        if(context.TryGetContext<RegisterShopifySalesOrder>(out shopifyDataContext))
        {
            //do stuff w/ shopifyData
            var shopifyData = shopifyDataContext.Message;
        }
    }
}

How sweet is that?!

How do you do it?

First you define your contracts with an interface rather than a class.

public interface RegisterSalesOrder
{
    string OrderId { get; }
    //other properties
}

public interface RegisterShopifySalesOrder
{
    //shopify stuff
    string ShopifyOneOff { get; }
}

public interface RegisterBigCommerceSalesOrder
{
    //bigcommerce stuff
    string BigCommerceOneOff { get; }
}

Then at your edge you have a class implement the correct interface.

public class RegisterShopifySalesOrderCommand :
    RegisterSalesOrder, RegisterShopifySalesOrder
{
    //implement the properties
}

public class RegisterBigCommerceSalesOrderCommand :
    RegisterSalesOrder, RegisterBigCommerceSalesOrder
{
    //implement the properties
}

and then publish the concrete class

bus.Publish(new RegisterBigCommerceSalesOrderCommand());

MassTransit will take care of routing the message for you, and now you can add additional content that may or may not be required. This isn’t a feature I recommend abusing, but its one more sharp tool in your toolbox.

Posted in MassTransit | 1 Comment

MassTransit and Interface Contracts

 MassTransit interface-style messages

Did you know that in MassTransit you can use interfaces for your message
contracts rather than classes? If not, you can and here is how.

Let’s take the following example:

public class RegisterSalesOrder
{
    public string OrderNumber { get; set; }
}

public class Program
{
    public static void Main())
    {
        var bus = BuildNewBus();
        bus.Publish(new RegisterSalesOrder { OrderNumber = "abc" });
    }
}

Nothing too surprising here I hope. We get our bus instance and then publish our
message. Later someone will consume it. Like so:

public class Program
{
    public static void Main()
    {
        var bus = ServiceBusFactory.New(sbc =>
        {
            //ignoring a bunch of setup
            sbc.Subscribe(subs =>
            {
                subs.Handler<RegisterSalesOrder>(msg =>
                {
                    //do stuff
                });
            })
        });
    }
}

more configuration options here

Why interfaces?

So this is great and all, but if our contract was that messages should be immutable
it would be nice to have that enforced by the compiler. But with classes that can
be tricky if we want to support being able to easily build the messages when
we need to as well. We could just use private setters, but now they are a pain
to build and would require constructor parameters which further makes
serialization a pain.

public class RegisterSalesOrder
{
    public string OrderNumber { get; private set; }
}

MassTransit support interface based contracts like this

public interface RegisterSalesOrder
{
    string OrderNumber { get; }
}

Now we have an immutable contract, and we can subscribe to this interface in
our subscription setup part of the bus. The trick is now in the publishing.
How do you create an interface and set its properties and publish it?

I simple create a class that implements the interface (outside of the contract dll). I usually make them in the publishing system as they are a private implementation detail of that system.

public class MyRegisterSalesOrder : RegisterSalesOrder
{
    public string OrderNumber { get; set; }
}

Now I can create an instance of the contract w/ ease and it can be made in whatever
way my publishing code needs it. It can be built using a ctor, a factory method,
through the container, whatever my app wants or needs. Then I can simply publish it

bus.Publish(new MyRegisterSalesOrder { OrderNumber = "bob" });

And subscribers to the interface will get the message as it conforms to the interface.

Boom.

Posted in MassTransit | 24 Comments