Monday, April 15, 2013

But What If We Run Out of Guids?

There was a bit of programmer humor happening on Twitter today concerning GUIDs.
Sadly, this is only funny because every programmer has inevitably had a conversation that went something like this:
Boss: "We need to make sure these entries are unique."
Dev:  "No problem, we can use a GUID."
Boss: "But we are going to be creating millions and millions of these things. What happens if there is a collison?"
Dev:  "I don't think it will be a problem."
Boss: "But these are going to be used on the web. What if somebody guesses a valid GUID?"
Dev: "They won't be able to guess, and besides, we will be checking security anyway."
Boss: "I'm just not convinced, I think we should..."
At this point, the boss (or other offending party) usually comes up with some cockamamie idea that takes way too much time to implement, and is not guaranteed to be unique.

But I recognize that phrases like "mathematically impossible", "2122", and "a trillion times more than the number of stars in the uinverse" are abstract and difficult concepts for business minded folks. So, for the non-anylitical types. I'm going to let you in on the joke, and attempt to show you why we programmers just stare at you blankly when you reject mathematically sound advice.

A GUID is like a really, really big number. How big? 2122 or 5.3×1036

So what does that actually mean? Let's pretend for a minute we had every single person on the earth generate a GUID every second for one year.

7,000,000,000 ppl * 86400 seconds in a day * 365 days in a year

Exactly how many GUIDs is that?

220,752,000,000,000,000

Ok, that's pretty impressive, but what percentage of the total number of possible GUIDs is that?

~0.000000000000000000042%

That doesn't look too good on a PowerPoint slide though, so how long would it take us to get to just 1% of all possible GUIDs?

2,400,884,200,000,000,000 Years

Great news! It will only take us a measly 2.4 Quintilian years to completely exhaust 1% of all possible GUIDs if every person on earth spends every second of every day generating them!

If you are a developer and you are faced with this conversation in the future, then just pull up this article and show it to the mathematically challenged.

Thursday, April 11, 2013

Angular Modules And Dependency Injection

If you aren't already familiar with Angular.js, then you really owe it to yourself to dig into this amazing framework. Misko Hevery (@mhevery) and his team have done an outstanding job, and I continue to be delighted by just how well designed and flexible the framework is.

At the heart of this flexibility is the Dependency Injection capabilities that Angular provides. However, while this is arguably the most powerful feature in Angular, it can also seem like a bit of voodoo magic at times. You may be wondering just how, or when, you can use this to your advantage.

I'm going to try and shine some light on this subject by showing you the most basic examples of dependency injection in Angular.

Let's imagine we had a simple service like this, and a very simple module that register the service.

function simpleService(){
   this.name = "simpleService";
}

angular.module('foo', [])
   .service('simpleService', simpleService);

Now imagine we wanted to manually grab an instance of that service (which you should almost never do) and use it. To do this we can create a new injector and let it do the magic of creating the service for us.

var myInjector = angular.injector(['foo']);
var service = myInjector.get('simpleService');

console.log(service.name); // 'simpleService'

So that's it... the simplest possible case. But what happens if you have two modules with the same service name defined? What happens then? Well, this is where it starts to get interesting. Let's look at two more examples.

angular.module('foo', [])
   .service('simpleService', function(){ this.name = "foo"; });

angular.module('bar', [])
   .service('simpleService', function(){ this.name = "bar"; });

var fooSvc = angular.injector(['foo']).get('simpleService');
var barSvc = angular.injector(['bar']).get('simpleService');

console.log(fooSvc.name); // 'foo'
console.log(barSvc.name); // 'bar'

This is more or less what you would expect to see. Each injector references only a single module, and therefore the services are isolated. But can't you create an injector that references more than one module? What happens then?

var fooSvc = angular.injector(['foo','bar']).get('simpleService');
var barSvc = angular.injector(['bar','foo']).get('simpleService');

console.log(fooSvc.name); // 'bar'
console.log(barSvc.name); // 'foo'

Did you see what happened there? Basically the last module to execute and register it's services won. It's simply a matter of the order in which they get executed.

But what if one our modules has a dependency? How does that change things?

angular.module('foo', [])
   .service('simpleService', function(){ this.name = "foo"; });

angular.module('bar', ['foo'])
   .service('simpleService', function(){ this.name = "bar"; });

var fooSvc = angular.injector(['foo','bar']).get('simpleService');
var barSvc = angular.injector(['bar','foo']).get('simpleService');

console.log(fooSvc.name); // 'bar'
console.log(barSvc.name); // 'bar'

Again, it's all about the order in which they execute, but in this particular scenario, because our bar module has a dependency on the foo module, foo will always get invoked first. This is where you can start to take advantage of this system to change how services operate, or replace them wholesale.

Imagine we were testing, and wanted to replace the $httpBackend with a custom one, or a mock implementation that we can precisely control? This becomes trivially easy to do because of how Angular is designed. All you would have to do is create a module that is dependent on the ng module, and override any service you wanted to. Indeed this is exactly how the ngMock module works.

Now, replacing a service is great, but one especially nice feature in Angular is the ability to intercept a service just after it has been created. This can be achieved easily by using a decorator.

angular.module('foo', [])
   .service('simpleService', function(){ this.name = "foo"; });

angular.module('bar', ['foo'])
   .config(function($provide){

      //$provide was injected for me automatically by Angular
      $provide.decorator('simpleService', function($delegate){

         //$delegate is the service instance, and is
         // also injected automatically by Angular
         $delegate.name += "|bar";

  return $delegate;
      });
   });

var fooSvc = angular.injector(['foo']).get('simpleService');
var barSvc = angular.injector(['bar']).get('simpleService');

console.log(fooSvc.name); // 'foo'
console.log(barSvc.name); // 'foo|bar'

I won't go into all the gory details on this, but basically we are able to intercept the simpleService from foo and do something with it before returning. You can check out the documentation on both the config and the decorator methods.

I hope this sheds a little light on modules, services and dependency injection in Angular. The ability to replace and intercept services opens up a whole world of possibilities and makes testing much easier.

Wednesday, April 10, 2013

PowerShell Equality Gotcha: Not Always Commutative

PowerShell is awesome! However, it also has its share of maddening quirks.

Jim Christopher (@beefarino) has highlighted one such quirk in the form of a brain teaser on his blog. The question is deceptively simple, but unless you have done a dance or three with PowerShell it might leave you scratching your head.

Query: In PowerShell, when is the following statement true? Explain why.
     ( $a -eq $b ) -ne ( $b -eq $a )

Know the answer? Try assigning these values to $a and $b

$a = 1
$b = '01'

If you run that expression again, it should come up as true.

Why?

It all has to do with what PowerShell is doing automatically for you. Since a string and an integer are disparate types, PowerShell is attempting to cast the values to the same type in order to do a comparison. In order to determine which type to cast to, the left operand is used.

If we write our expression out the way it is being interpreted, then it becomes pretty obvious what is going on.

([int]1 -eq [int]'01') -ne ([string]'01' -eq [string]1)

See what's going on? Obviously casting '01' to an [int] is not the same as casting 1 to a [string].

This is one of those things that makes sense when you look at it directly, but when it is an obscure bug buried deep inside one of your production scripts... it can drive you insane.

Just remember that equality comparisons in PowerShell are not always commutative.

Happy Scripting, and thanks @beefarino for a fun challenge, and being the guy who made me want to learn PowerShell in the first place :)

Friday, August 31, 2012

Prototypal Inheritance in C#

The other day an interesting question was posed on Stackoverflow. Sumarizing:
"How can I add methods to a type dynamically at runtime and have them be available to all other instances of that type?"
That is certainly an interesting question. Of course this is similar to how JavaScript works via the prototype property that all objects have. So I set out to see how easy it would be to simulate prototypal inheritance in C# using the new Dynamic Language Runtime features introduced in C# 4.0.

Now let me preface this by saying this solution is an answer in search of a question. That is, there is no particular problem I can immediately think of that this solves. It is a decent demonstration of the dynamic capabilities available to you in C#, but if you find yourself needing this kind of behavior, you might be a closet hipster.

What would such an implementation look like? Imagine the following class structure:

public class Foo {}
public class Bar: Foo {}

And now we would like to be able to dynamically define methods for Foo and Bar at runtime like so.

var foo1 = new Foo();
var foo2 = new Foo();

Foo.Add = new Func<Int32,Int32,Int32>((a, b) =>; a + b);

var result1 = foo1.Add(5, 5); // result1 == 10
var result2 = foo2.Add(10, 5); // result2 == 15

As it is written, this is impossible since it won't even compile. However, if we leverage the DLR and the dynamic keyword, then we can begin to make some magic happen. ExpandoObject is certainly an attractive new addition to .Net, as it allows us to dynamically add members at runtime, but they are local to that instance only. So for our purposes we are going to have to turn to the low level DynamicObject. DynamicObject gives us hooks into the new dynamic features of the runtime, but we are forced to write all the necessary plumbing to get the functionality we want. At a minimum we need to be able to:
  • Add new properties
  • Add new methods
  • Retrieve the value of dynamic properties
  • Invoke dynamically added methods
This turns out to be pretty easy by overriding just three methods from DynamicObject. TrySetMember, TryGetMember and TryInvokeMember.

public class ProtoObject : DynamicObject
{
 private Dictionary<String,Object> _members = new Dictionary<String,Object>();

 public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
 {
  Object member = null;
  result = null;

  //Check to see if we have a member of this name
  var success = _members.TryGetValue(binder.Name, out member);

  //Check to make sure it is a delegate that can be invoked
  if (success && member is Delegate)
  {
   //Execute the member with the passed in arguments and assing the result
   result = ((Delegate)member).DynamicInvoke(args);
  }

  return success;
 }

 public override bool TryGetMember(GetMemberBinder binder, out object result)
 {
  //Attempt to get the saved value with specified name
  var success = _members.TryGetValue(binder.Name, out result);

  return success;
 }
 
 public override bool TrySetMember(SetMemberBinder binder, object value)
 {
  //Add the new member name and value to our dictionary
  // or override the existing value
  if (_members.ContainsKey(binder.Name))
   _members[binder.Name] = value;
  else
   _members.Add(binder.Name, value);

  return true;
 }
}

Now we have a custom object that will act similar to how ExpandoObject works. However, we still haven't solved the issue of inheriting members across all types. What we need is a shared collection of members that are specific to that type.
 
I've chosen a static Dictionary<Type,ExpandoObject> for this solution. Obviously we want to use Type as a key since the members should be specific to a type, and ExpandoObject already gives us all the functionality we need to store a collection of arbitrary properties and methods.

In order to make this work properly, we need to initialize the Dictionary with each new type in the inheritance chain, and provide a humane way of adding new members to a specific type. The constructor can be used to ensure that new types are added to the Dictionary, and by getting creating with the dynamic keyword, we can add a Prototype property that will give each type access to it's corresponding ExpandoObject.

private static readonly Dictionary<Type,ExpandoObject> _prototypes = new Dictionary<Type,ExpandoObject>();

public ProtoObject()
{
 if (Prototype == null)
 {
  _prototypes.Add(GetType(), new ExpandoObject());
 }
}

public dynamic Prototype
{
 get
 {
  if (_prototypes.ContainsKey(GetType()))
   return _prototypes[GetType()];
  else
   return null;
 }
}

Finally, when a request for a member is made, we need to first check to see if there is one defined on the instance. If we can't find one, then we can begin looking for a matching member in the prototype object, walking the inheritance chain until we find what we are looking for.

Since finding an appropriate prototype member by walking the inheritance chain is recursive in nature, a helper method can be added to make this easier. While TrySetMember remains unchanged, TryInvokeMember and TryGetMember need to change slightly to accommodate the new functionality, but not by much.

public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
{
 Object member = null;
 result = null;

 var success _members.TryGetValue(binder.Name, out member);

 if (success && member is Delegate)
 {
  result = ((Delegate)member).DynamicInvoke(args);
 }

 if (!success)
 {
  member = FindPrototypeMember(binder.Name, GetType());

  if (member is Delegate)
  {
   result = ((Delegate)member).DynamicInvoke(args);
   success = true;
  }
 }

 return success;
}

public override bool TryGetMember(GetMemberBinder binder, out object result)
{
 var success = _members.TryGetValue(binder.Name, out result);

 if (!success)
 {
  var member = FindPrototypeMember(binder.Name, GetType());

  if (member != null)
  {
   result = member;
   success = true;
  }
 }

 return success;
}

//Walk the inheritance chain using recursion to find a suitable
// prototype member
private object FindPrototypeMember(string memberName, Type type)
{
 if (String.IsNullOrWhiteSpace(memberName) || type == null) return null;

 if (!_prototypes.ContainsKey(type)) return null;

 var prototype = _prototypes[type] as IDictionary;

 if (prototype.ContainsKey(memberName))
  return prototype[memberName];
 else
  return FindPrototypeMember(memberName, type.BaseType);
}

Putting this all together allows us to inherit from this object and dynamically add members and properties at runtime that will be available to all instances of that type. In other words, given this class structure:

public class Foo: ProtoObject {}
public class Bar: Foo {}

This code is totally valid:

dynamic myFoo = new Foo();
dynamic yourFoo = new Foo();
dynamic myBar = new Bar();

myFoo.Prototype.Name = "Josh";
myFoo.Prototype.SayHello = new Action(s => Console.WriteLine("Hello, " + s));

yourFoo.SayHello(myBar.Name); // 'Hello, Josh'

Again, I can't think of any practical use for this off the top of my head, but it is interesting to see just how much flexibility you can squeeze out of C# with very little code. 

For those who are interested a more robust version of this code is available on GitHub. The unit tests are the best documentation of the additional features, mainly:
  • Ability to check for "undefined" members by returning a special value instead of throwing an exception
  • Ability to access the current instance from within dynamically added methods.
  • Allows original exception with full stack trace to propogate instead of a RuntimeBinderException.

Saturday, April 21, 2012

Validating "Read the Source, Luke"

So recently Jeff Atwood quoted wrote a pretty nice article about why learning to read source code is so important for developers. I absolutely could not agree more with that post.

As a tribute, I thought I would share a recent example where this principle would have settled an argument on Stackoverflow, and perhaps not lead to me using two unwitting souls for fodder in this blog post.

The question itself was pretty trivial. "How to select List<> by its index and return the content?"

One of the answers suggested using the ElementAt extension method as an alternative to using the standard indexer. No big deal, but what ensued was a pretty fun little comment argument. I've changed the names to protect the innocent:


So Bob is making a legitimate claim that using ElementAt would be inefficient compared to using an indexer. Unfortunately he also makes a pretty wild claim about ElementAt not returning the same value that calling the indexer on a List would.

Larry then decides to defend himself in a way that every programmer has probably done at some point; he writes a small test program. You can see the code here: http://ideone.com/H0A2X

Despite the test program being fundamentally flawed (see fixed program here: http://ideone.com/hooQB), Larry got the numbers he was looking for. Armed with a helping of confirmation bias, and his new numbers, Larry decides to respond back to Bob.


And what else did Larry have to say about his results:
"When it comes to errors, the MSDN documentation and a wealth of empirical evidence suggests that such concerns are wholly unfounded... The ElementAt() method is definitely faster... I have tested Lists of type double, float and string with similar results..."
In the end... both of these guys are wrong!

So what is the truth? What does the source code say? Let's use DotPeek and find out:


Turns out that ElementAt is optimized for anything that implements IList<T>and simply calls the indexer. A 30 second look at the source code would have ended this argument before it started. In reality ElementAt is 3 times slower when called on a List<T> because of the cast.

If you need to know how something works, then you need to go to the source code and see for yourself. Without this skill, you will never know for sure how stuff works. Don't waste your time arguing about how you think things work when the answer is right at your finger tips.

Follow Jeff and Brandon's advice and Learn to Read the Source, Luke





Wednesday, February 1, 2012

Whine Less... Code More

Developers are a whiny bunch.

Today I was reading one of Scott Hanselman's latest posts on some improvements being made in WebForms, and was pretty amazed at how generally whiny the comments were.

You could read all the comments, but they can pretty much be broken down into 3 categories of whiny trolls.

The Hater

Dear Scott,

You suck! WebForms sucks! Microsoft sucks! And pretty much every technology they produce is total garbage. I still program using the MS stack of course... cause you know... I'd rather complain than learn a new technology.

The Righteous One

Dear Scott,

How can you even look at yourself in the mirror after writing such filthy code. I realize this is just a blog post... meant to be a simple demonstration of a new feature, but how dare you not follow all 5 of the SOLID principles, complete with a full suite of unit and integration tests (written first of course). You didn't even use an IoC!!!! And you call yourself a programmer! 

All .Net developers are pretty much worthless, incompetent boobs... except for me of course. I would write a better example myself, but I'm too busy telling people like you how crappy a programmer they are :P

The Hipster

Dear Scott,

Whoa dude! WebForms is so primitive man. Only old people and corporate shills program in WebForms. Everybody knows that MVC is what all the cool kids are using. That internal corporate app I wrote is like... blowing minds... all five of them. 

Besides, everybody knows that WebForms is way too much abstraction, and the ViewState, oh man was it terrible. I never knew what the ViewState was for, but I know it was bad! With MVC I can get down to bare metal baby! I still don't know what a Handler or Module is, and I never really touch the form collection or HttpContext... but it's so much less abstract than WebForms.

So, to all you whiny programmers out there, I have a some people you should meet. I know you know these people. You probably troll their blogs regularly.


Bob Martin, Michael Feathers, Ron Jeffries and Martin Fowler were doing awesome things while you were still drinking from a sippy cup.

David Heinemeier Hansson liked Ruby and needed a web framework. So he wrote one.

Rob Conery didn't like big heavy ORM's so he wrote a tiny one. He also created a startup using ASP.Net MVC... and then rewrote it using RoR just because he could.

Phil Haack helped bring MVC to the world of ASP.Net

Jeremy Miller and Oren Eini wake up in the morning and pee new frameworks that are awesome.

Joel Spolsky's company wrote an awesome bug tracker in classic asp. ASP FOR GOODNESS SAKE!


Jeff Atwood wrote Stackoverflow when MVC was still in beta.

Damien Edwards continues to rock out ASP.Net

Glenn Block is infusing WCF with web enabled awesome sauce.

John Resig made the entire web take Javascript seriously.

Steve Sanderson brought MVVM to web apps using Knockout.js

David Fowler is making realtime web stupid easy with SignalR

And last but not least... Scott Hanselman was pimping ASP.Net and make it look good back when it was still 1.0


So what do they all have in common?

They can't hear you over the sound of how awesome they are!


Not all of them work on the same technology stack, but all of them have been consistently awesome at what they do regardless of the technology they were using.


Technologies do not make awesome applications. Awesome people make awesome applications.

Stop spending so much time and effort complaining and start doing something amazing... right now!

Less Whine! More Awesome!

Monday, January 30, 2012

It's The Principal...

In ancient times... at least according to web standards, I wrote a couple of posts about unit testing with declarative security attributes. It turns out that while using declarative security is pretty awesome, it's clear nobody was thinking about people doing TDD :(

Getting around this was easy enough by simply overriding the Principal using the built in GenericPrincipal and GenericIdentity classes. We even refactored the security setup code into the Initialize method for our unit tests. However, we still had to think about security for every test class!

I can tell you right now that that is a big fat suck! I don't want to see any security related code in my unit test because I'm not testing security right now! What I really want is for my test to look like this and just work.

[TestMethod]
public void ShouldGetSuperSecretFromAgent()
{
    var agent = new SecretAgent();

    //This line will esplode!!!
    var secret = agent.GetSuperSecretStuff();

    Assert.IsNotNull(secret);
}

Fortunately, we still have one last trick up our sleeve that we can use to solve our problem once and for all. Writing a custom implementation of IPrincipal and IIdentity. This is so braindead simple, that I'm not even going to explain it... just show you the code.

public class StubPrincipal: IPrincipal, IIdentity
{
    public StubPrincipal(String name = "TestUser", Boolean isAuthenticated = true, String authenticationType = "Fake")
    {
        Name = name;
        IsAuthenticated = isAuthenticated;
        AuthenticationType = authenticationType;
    }

    //IPrincipal Members
    public IIdentity Identity
    {
        get { return this; }
    }

    public bool IsInRole(string role)
    {
        return true;
    }

    //IIdentity Members
    public string AuthenticationType { get; set; }

    public bool IsAuthenticated { get; set; }

    public string Name { get; set; }
}

This still leaves the business of wiring it all up. Since the whole point of this refactoring was to not have to worry about doing this for every test!

All your base class are belong to us!

The simplest approach I can think of is to create a base class that will wire up your custom StubPrincipal object in the constructor, and then derive all your test classes from it. Again, this is so braindead simple... just look at the code.

public class SecurityEnabledTest
{
    protected StubPrincipal Principal = new StubPrincipal();

    public SecurityEnabledTest()
    {
        Thread.CurrentPrincipal = Principal;
    }
}

And now our goal above is reached with one tiny modification.

[TestClass]
public class SecretAgentBehavior_UsingBaseClass: SecurityEnabledTest
{
    [TestMethod]
    [Description("Test relying on base class to set principal")]
    public void ShouldGetSuperSecretFromAgent()
    {
        var agent = new SecretAgent();

        //It works... WOOT!
        var secret = agent.GetSuperSecretStuff();

        Assert.IsNotNull(secret);
    }
}

Voila! Now you can go on your merry little way and focus on the actual method behavior instead of the security meta-data.

But Wait! There is even more awesome!

If you are thinking to yourself "Ok, that is great dude, but what if I actually want to test MY FREAKING SECURITY!"

I've got you covered. Here is a slightly more robust Principal object that will give you a lot more control over how it behaves, which should cover any testing scenario you can think of. It allows you to add roles, and has three modes of operation:
  1. Always Return True
  2. Whitelist
    1. This is how a normal principal operates. If the role is in the list, then you get access.
  3. Blacklist
    1. This works opposite to a normal principal. If the role is in the list, then you get denied access. This is useful for when there are multiple roles needed to perform an action (think nested calls), and you want to see how your code behaves when the user doesn't have one of them.
In the end I hope this helps unit testing efforts, and maybe demystifies the Principal/Identity objects a little bit. You can even use these same techniques to write your own custom security Principal for actual production uses. The concepts are identical.

Cheers,
Josh