About Punkcoder

I am a Software Developer with a passion for ALM, Agile, and Coding Practices. I have been working in .NET as a developer for over a decade, a network admin for years before that. I have worked for large companies and small ones, many that you would recognize some that you probably interact with. I am opinionated and deeply curious about the world. If you have a problem there is a good chance that I would be interested in hearing about it. More than that I want to help others, mostly because I believe that helping a single person raises the quality for everyone.

 

Other Things of Interest

Blog Posts

7/28/2016 - How to make enemies with peopl...
7/14/2016 - Technology and the Red Queen
6/9/2016 - Building Analytics with Data L...
7/22/2014 - Building Resilient Networks
11/15/2013 - Your warranty will expire soon...
11/8/2013 - The dangers of supporting Lega...
7/15/2013 - The challenges of working with...
6/1/2013 - Good News Everybody...
8/3/2012 - Agile development and database...
2/9/2012 - Tools for Visual Studio
2/8/2012 - I Love my Mac... but,
1/26/2012 - American Lobby for the Future ...
12/23/2011 - Migrating the Website
12/21/2011 - Managing offshore work.
12/20/2011 - Encryptr
12/14/2011 - Source Control, seriously peop...
12/2/2011 - No. No. No. No. No.
6/24/2011 - Things I Wish I Learned in Col...
5/11/2011 - Guess where I will be next wee...
12/10/2010 - Why can't we all agree... VBA ...
12/10/2010 - Stupid Developer Tricks : Prox...
12/9/2010 - Review: Applied Architecture P...
6/2/2010 - The Upper Limit Number of Appl...
5/15/2010 - Reflection on my own faith fol...
5/10/2010 - An interesting use for Skype
2/11/2010 - Parallel namespace in .NET 4.0
2/10/2010 - The joys of SPAM
1/5/2010 - Another post from the couch.
1/5/2010 - The Introduction of the Revere...
1/5/2010 - Redefinition of Religion
8/14/2009 - Become the Media
8/13/2009 - The Bane of Developers Existan...
5/6/2009 - Breakdown of the Social Order
4/23/2009 - Fiber to the Home
4/22/2009 - Creating an iPhone Ringtone
4/22/2009 - A gem from the old site... the...
4/22/2009 - Every once and a while...
4/22/2009 - Crazy people and public transi...
4/21/2009 - Hold tight...
1/16/2015 - Migrating the site to umbraco.

Latest Blogs

How to make enemies with people who use TDD...

Created On: 7/28/2016 3:18:00 PM

So I have been working on a project that requires the use of the NEST framework for working with ElasticSearch, and I have to tell you I am absolutely maddened by the lengths that I have to go through to get good tests.

The problem is that someone in their INFINITE Wisdom decided that all of the setters on response objects should be private or internal. For example:

public interface IGetMappingResponse : IResponse, IBodyWithApiCallDetails
 {
   Dictionary<stringIList<TypeMapping>> Mappings { get; }
 
   Dictionary<IndexName, IDictionary<TypeName, TypeMapping>> IndexTypeMappings { get; }
 
   TypeMapping Mapping { get; }
 
   void Accept(IMappingVisitor visitor);
 }

Which means that in order for for me to perform a simple mock, I have to create a WHOLE NEW CLASS, further bloating my code and making the process of creating my unit tests even more complicated. In order to use the following code:

var clientResponse = new MockedGetMappingResponse();
var calledGetMapping = false;
 
client.GetMapping(Arg.Any<IGetMappingRequest>()).Returns(clientResponse).AndDoes(x=> { calledGetMapping = true; });


 I have to create a whole, new object that's now bloating my unit test project just so I can get the damned unit test to work:

public class MockedGetMappingResponse : IGetMappingResponse
   {
       public IApiCallDetails CallDetails { getset; }
       public bool IsValid { getset; }
       public IApiCallDetails ApiCall { getset; }
       public ServerError ServerError { getset; }
       public Exception OriginalException { getset; }
       public string DebugInformation { getset; }
       public void Accept(IMappingVisitor visitor)
       {
           throw new NotImplementedException();
       }
 
       public Dictionary<stringIList<TypeMapping>> Mappings { getset; }
       public Dictionary<IndexNameIDictionary<TypeNameTypeMapping>> IndexTypeMappings { getset; }
       public TypeMapping Mapping { getset; }
   }

So the next time that you get the bright idea that all return objects shouldn't be able to be set... don't do it. If it says that it's a response object and someone is dumb enough to set the value then they are the idiot, we will give you a pass on it. But remember there are LEGITIMATE reasons that we would want to use those set values, and by removing them your aren't making your code any better... your just being an asshole.


Technology and the Red Queen

Created On: 7/14/2016 12:00:00 AM

TL;DR: Technology in your business needs to continually evolve or it will become toxic, doing more damage to your business than any advantage you originally gained.

The red queen problem is a problem that is modeled in nature as a reality; that there are two species that are in continual evolution fighting to get the upper hand. The name comes from a line in Alice and Wonderland. But is serves as an example that in order to survive one ground must struggle to get the upper hand, once that species has the upper hand they have to defend it. This is a parallel that can be pointed directly to business to business competition. Through the course of this blog post I will explain not only how this relates to the field of computer science and business. I will attempt to lay out the problem with the method of thinking.

I have worked in technology for well over a decade, and I find this to be one of the reoccurring topics that we can't seem to escape. If you are looking to interact with technology and make it a central part of your business, realize that you are entering into an evolutionary race. As a business you have to come to grips with the fact that the amazing solution that you put into place today is not going to be silver bullet. Today's advantage is tomorrows liability. This is one of the reasons that I have realized that consultancies for technology are a failure. The Idea is that you can hire someone today and then you won't need them tomorrow.

In the business to business case the number of times that I see someone come to us asking for a feature similar to a feature that exists on the site of a competitor is too many to count.  In every case that I have seen they have spent enough time playing with the functionality that they generally have a better understanding of the user experience than the people that initially developed it (this excludes the testers, those poor souls). So in this case we see that we have one group of businesses setting the path, but if it's the right path it isn't long before your competitors will follow your lead, and it's likely that they will take it to the next step.  Leaving you in a place where you are open to poaching.  In the event that this isn't the case, people become complacent and a whole new breed of creature comes up to eat you.  A great example of this is the Uber vs Taxi, and no matter how many stories that you hear smearing Uber ask any hard core traveler if they would rather get into a taxi or an uber and I think you will find that they opt for the better experience every time.  Think your business model is immune to this? So did the taxi companies.

In the management vs workers case we are seeing a constant battle between the expansion of workers rights and the desire for lower wages.

The take aways from this:

  1. If you are still running your business on Windows XP, or Internet Explorer 9, or anything behind the curve, please evolve or I will cease to care about you.
  2. If you think that you are a special case, your not.
  3. If you have too much invested into the infrastructure, and couldn't possibly think of upgrading. I hope someone eats your lunch.
  4. If you are still doing this, you are the reason we can't have nice things.


Building Analytics with Data Lake

Created On: 6/9/2016 12:00:00 AM

As part of a project that I am working on I was doing some work with Azure Data Lake.  As part of the solution we need to analyses large amounts of data that will be generated by users and condensed into some interesting analytics. As part of the PoC we decided to look at two different directions in attempting to solve the problem.  The first was to build a solution in data lake that would take all of the generated data and summarize it into something that would make some sense. The second was building an application to run the analytics.

At the current moment I think the hardest part of working with the toolset is the lack of documentation that exists.  I'm sure this will improve over time and is something that is normal for pre-release software.

So... what was I attempting to do?  The idea is simple we wanted one of our applications to publish a message to an event hub to capture that the event happened, we are expecting there to be several thousands of these messages over the course of an hour (not really too ambitious but it's a place to start and the key is making sure that we can scale when we need to). From that point we would have web workers that would take those messages off of the event hub and push them over to table storage (cheap storage is always a good thing), then we would move them from the table storage over to data lake and run some processes for aggregating the data. Nothing to complicated, after working through all of the steps needed to make it happen we were successful.  The whole process worked fairly well and would have done what we needed and the pricing on it was much less than I expected for the demo.  Even with all of the services parts spun up I was still going to come in well under my $50 allocation for MSDN.

The application direction ends up exactly where you think it would, too much yak shaving to make it worth while, so there's nothing really interesting to talk about there.

In the end we decided not to go this way because we decided that part of the underlying architecture was the problem and that we would be able to get better analytics out of fixing that part. But in the end I have to say that I was really surprised about the quality of the product that's out there and I'm extremely interested to see where the final version ends up.