Nov 22, 2013 Posted by John MacIntyre

The *hidden* Obamacare website code.

I just saw this video of Congressman Joe Barton questioning Cheryl Campbell of CGI about the Obamacare website’s *hidden* code. http://youtu.be/N54gSI4Aft0 It really doesn’t bother me that the congressman doesn’t understand that he’s looking at a ‘comment’, not ‘code’. And it doesn’t bother me that he doesn’t understand that it was probably commented out because of the dynamic, incremental, nature of software development with decisions being made and unmade continuously on the fly. And it doesn’t bother me that he doesn’t understand this commented code doesn’t affect compliance since it’s not functional, not displayed, and completely ignored by the computer. I can almost guarantee how this played out; An overly defensive business analyst decided to add this in as a CYA tactic. The developer added it then somebody realized it was not to spec and told the programmer to remove it. The programmer commented it out instead of removing it because they’ve seen the flip flopping on functionality like this in the past (possibly multiple times in this project). The comments were never removed (are they ever?), and it was promoted to production. Then somebody with enough knowledge to be dangerous, but doesn’t know what they are looking at found it, and pushed it through the ranks until if finally wound up being questioned in a Congressional Hearing. What bothers me is that nobody was able to clear up this misunderstanding. There was nobody to step in and say, “Hey, this is a non-issue”. It’s a non-threat. I was a little disappointed that Cheryl Campbell didn’t chime in and say “Actually, Mr. Congressman, I understand your concern, but it’s not what it looks like”, then explained what it was. Ok, she obviously doesn’t have the skills to understand or explain it, but you would think the solution architect would’ve rode shotgun to clear up misunderstandings like this. I’m also embarrassed that programmers are still commenting dead code instead of removing it. It’s not 1990 anymore, the source control tools we have are awesome, so don’t be scared to delete anything which is no longer serving a purpose, it will live in your source repo history forever. Don’t be a hack. Once it is understood this commented out code is a non-functional historical artifact of an extremely dynamic process, it could also be asked “Why was this added in the first place?”. And that would be a valid question, to which I would answer, “It doesn’t matter since that functionality... read more

Nov 20, 2013 Posted by John MacIntyre

How to keep your Get & Post ViewModels DRY

I’ve been convinced that I should not be using the same view model class for both loading the view and the posted controller action parameter. The trouble is it allows data to be transferred back which may not be necessary and it needlessly increases our attack surface. Don’t get me wrong, I’ve always had unit tests specifically monitoring that only necessary view model properties are being pushed back to the entity model, but still, seperate viewmodels will allow me to eliminate that risk completely and even remove those tests. To be honest, the idea of having 2 view model classes that are nearly identical is not very appealing, especially given that if the structure deviates, the default model binder will no longer work with those properties which are out of sync with its partner view model. Don’t get me wrong, I’m very liberal when it comes to class quantities, but this was enough to make me uncomfortable. So I’m happy that I realized the post view model class can always be used as a base class for the get view model class. I mean it has to be in order for the default model binder to work. Using inheritance for these classes will a) keep these classes in sync so the default model binder will always work, b) follow the DRY principle and c) keep my sanity. In a nutshell, rather than having 1 2 3 4 5 6 7 public class FooViewModel { public int Id { get; set; } public string Name { get; set; } public FooStatusEnum Status { get; set; } public DateTime CreateDate { get; set; } }public class FooViewModel { public int Id { get; set; } public string Name { get; set; } public FooStatusEnum Status { get; set; } public DateTime CreateDate { get; set; } } We can instead have 1 2 3 4 5 6 7 8 9 10 11 public class FooPostViewModel { public int Id { get; set; } public string Name { get; set; } }   public class FooGetViewModel : FooPostViewModel { public FooStatusEnum Status { get; set; } public DateTime CreateDate { get; set; } }public class FooPostViewModel { public int Id { get; set; } public string Name { get; set; } } public class FooGetViewModel : FooPostViewModel { public FooStatusEnum Status { get; set; } public DateTime CreateDate { get; set; } } So FooGetViewModel is loaded and passed into the view.... read more