Chocolatey Kickstarter–Help Me Take Chocolatey to the Next Level

I’m really excited to tell you about The Chocolatey Experience! We are taking Chocolatey to the next level and ensuring the longevity of the platform. But we can’t get there without your help! Please help me support Chocolatey and all of the improvements we need to make!

The Chocolatey Experience

https://www.kickstarter.com/projects/ferventcoder/chocolatey-the-alternative-windows-store-like-yum

Posted in chocolatey, Uncategorized | Tagged , | Leave a comment

Hypermedia hangout: Collection+JSON, HAL, and building .NET hypermedia APIs with Nancy and ASP.NET

Yes that title is a mouthful. Recently I had the pleasure of doing a google hangout with Jonathan Channon of Nancy fame and Phil Cleveland on a topic you’ve heard me be slightly passionate about, Hypermedia.

You can find the full hangout which was published on air here, which was recorded for your enjoyment and displeasure :-)

My reasoning for getting in the convo was a bit selfish. I maintain a library for Collection+JSON APIs (which I’ve never blogged about) which I want to be used with Nancy.

Originally the library was built strictly for ASP.NET Web API, however after getting feedback from Andreas, that I should decouple it so NancyFx users could use it. I took his advice and did that! I refactored into 3 packages two of which can easily be used in Nancy. However, no one is doing it. My hopeful result for this call with Jonathan is that would change as he is deep into Nancy and interested in Hypermedia. It looks like I reached that goal :-)

In the hangout we start off (well mostly I was talking) talking about Hypermedia itself and different formats, namely HAL and Collection+JSON. Then we went into looking at a few sample APIs (including out issue tracker example from the book) using Collection+JSON, my CJ library, as well as how to implement a hypermedia API / useful patterns. Along the way we also delved into Profiles and the role they play for hypermedia APIs. Finally we ended the discussion talking about what this means for Nancy and what we could do to enable CJ in Nancy. That led to the creation of this github project! Jonathan and I will be iterating the next few weeks on bringing CJ to a Nancy near you.

Let the hypermedia games begin!

Posted in collectionjson, HTTP, Hypermedia | Leave a comment

Solving Json discrepancies using a JsonConverter

During my day job I am a client developer who is beholden to various back end API’s. Normally these API’s are well thought out and pretty easy to use, and normally their resulting json model make sense. But as we know, normally does not mean always. A few weeks ago I was implementing a feature which and built a object model based on the response from the API and the needs of my feature. Fast forward to present time and I am implementing another feature, similar but different. At first glace of the resulting json coming from the API it dawned on me that I could resume my object model from before (this makes sense since the features are in the same scope and are very tightly coupled).

As I set out to code my solution I hit a point where I needed to desearlize my json document to my object graph. No big deal as I am using Json.net and this is cake. But we know that nothing in software is cake. I immediately get an error while deserializing my graph, but why.

Below is my original json graph

"participants": [
{
  "id": "1ab644ce-481d-443f-a569-202a06cad740",      
  "calls": {
      "id": "c72537f6-af1e-4afe-abc2-5815b25960eb"
    }
},       

This graph looks pretty normal (note that most properties were removed as they were just noise). I have an array of participants and each participant has a calls subobject.

No look at the json graph from the 2nd api hit

"participants": [
{
  "id": "1ab644ce-481d-443f-a569-202a06cad740",      
  "calls": [
    {
      "id": "c72537f6-af1e-4afe-abc2-5815b25960eb"
    }
  ]
},

Do you see the subtle difference? In the second graph the Calls subobject is not an object but rather an array of objects. WTF????

I stared at this problem for some time trying to find the most elegant way to solve the problem and be able to resume my object graph, since the graph is expected to be the same.

The solution I found was to use a JsonConverter which will allow me to custom convert my Calls node as needed.

The first thing I needed to do is decorate my Call property in my object graph as below

        [JsonProperty("calls")]
        [JsonConverter(typeof(VoiceConversationCallsConverter))]
        public VoiceConversationCall Call { get; set; }

The next thing I need to do is create my VoiceConversationCallsConverter. Inside this converter I am going to determine if the node currently being parsed is an object or an array and return back the correct value.

    public class VoiceConversationCallsConverter : JsonConverter 
    {
        public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer)
        {
            if (reader.TokenType == JsonToken.StartObject)
            {
                return serializer.Deserialize(reader);
            }
            
            if (reader.TokenType == JsonToken.StartArray)
            {
                var asArray = serializer.Deserialize<List>(reader);
                if (asArray != null && asArray.Any())
                {
                    return asArray.First();
                }

                return new VoiceConversationCall();
            }

            return serializer.Deserialize(reader);
        }

        public override void WriteJson(JsonWriter writer, object value, JsonSerializer serializer)
        {
            serializer.Serialize(writer, value);
        }

        public override bool CanConvert(Type objectType)
        {
            return true;
        }
    }

Pay attention to the ReadJson method. Inside this method I am looking at the TokenType for the current node and asking if it is an object or an array. once I know the TokenType I can deserialize my reader into the correct type and return it as needed.

Doing this allowed me to have a single object graph (again, which is expected) and process two slightly different json graphs.

Till next time,

Posted in C# | Tagged | Leave a 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

Chocolatey Newsletter

Chocolatey imageChocolatey has some big changes coming in the next few months, so we’ve started a newsletter to keep everyone informed of what’s coming. The folks who are signed up for the newsletter will hear about the latest and greatest changes coming for Chocolatey first, plus they will know when the Kickstarter (Yes! Big changes are coming!) kicks off before anyone else. Sign up for the newsletter now to learn about all the exciting things coming down the pipe for Chocolatey!

Posted in chocolatey | Tagged | 2 Comments