Derik Whittaker

March 2007 - Posts

• Using Anonymous delegates as a replacement for a Switch Statement

  Recently I was writing some code that interacted with a third party API for doing searching.  This API would return me a single result object fore each found result for my search, but the result object it returned me was a dictionary style object.  This object would contain 1-n different key/value pairs that would contain all sorts of data.  After examining the results for a few searches I realized I only needed a few pieces of data from the result.  Like I said before since the result was a Disctionary object Dictionary<string, object > I knew that in order to grab all the values out of the object I would have to implement my own switch statement and look for each key one by one. As I started to write this switch statement I started to wonder if there was another way of doing this.  After some brain storming with a co-worker we decided it could be done using Anonymous Delegates.  Below I will show the old way (using switch statements) and the new way (using delegates)   Here is the fake result object model that I will pull the data out of. public class ValuesClass { public ValuesClass( string key, string value ) { Key = key; Value = value; } public string Key = string.Empty; public string Value = string.Empty; }   Here is the object model that I will populate with the data from the fake result (yes i know, not well formed, but this is a POC after all) public class DataClass { public string Property1 = string.Empty; public string Property2 = string.Empty; public string Property3 = string.Empty; public string Property4 = string.Empty; public string Property5 = string.Empty; public string Property6 = string.Empty; } Here is the code needed in order to use a switch statement /// <summary> /// Will loop though the values and populate the given data class /// </summary> /// <param name="values">This is my fake result object.</param> /// <param name="dataClass">The data class to be populated</param> public void SetValuesInProperties_WithSwitch( List<ValuesClass> values, DataClass dataClass ) { ActionDelegate actionDelegate; foreach ( ValuesClass value in values ) { switch( value.Key ) { case "A": dataClass.Property1 = value.Value; break; case "B": dataClass.Property2 = value.Value; break; case "C": dataClass.Property3 = value.Value; break; case "D": dataClass.Property4 = value.Value; break; case "E": dataClass.Property5 = value.Value; break; case "F": dataClass.Property6 = value.Value; break; } } } Here is the code using the anonymous delegates: Setting up the needed variables // The delegate that will perform the setting action. public delegate void ActionDelegate( DataClass x, string value ); // The mapper object that holds my keys that i am looking for and my delegate // for performing the mapping Dictionary<string, ActionDelegate > _mapper = new Dictionary < string, ActionDelegate >(); Building the needed mapper object public MapperClass() { // Build up my mappers _mapper.Add( "A", delegate( DataClass dc, string value ) { dc.Property1 = value; } ); _mapper.Add( "B", delegate( DataClass dc, string value ) { dc.Property2 = value; } ); _mapper.Add( "C", delegate( DataClass dc, string value ) { dc.Property3 = value; } ); _mapper.Add( "D", delegate( DataClass dc, string value ) { dc.Property4 = value; } ); _mapper.Add( "E", delegate( DataClass dc, string value ) { dc.Property5 = value; } ); ; _mapper.Add( "F", delegate( DataClass dc, string value ) { dc.Property6 = value; } ); } Performing the actual mapping public void SetValuesInProperties_WithDelegates( List<ValuesClass> values, DataClass dataClass ) { foreach ( ValuesClass value in values ) { if ( _mapper.ContainsKey( value.Key ) ) { _mapper[ value.Key ]( dataClass, value.Value ); } } }   Now, I know that using the switch statement is easy to read and very easy to understand compared to the anonymous delegates, but this was just an fun little exercise to see if there is a different way to do this.  I would consider using the anonymous delegate route if my setting actions were simple and if the case block would be very lengthly.  Has anyone else done something similar?  Have any suggestions on how to do this better?     Posted Mar 31 2007, 02:44 PM by Derik Whittaker with 5 comment(s) Filed under: Development, .Net

• Great post about Cutting Corners from Jeremy at CodeBetter

  Over at CodeBetter Jeremy has posted a really great article about cutting corners and how that leads to more problems down the road.  It has been my experience that when it comes to software development we all have to cut corners from time to time to meet deadlines, give demos, etc.  But choosing which corners to cut is what matters.  It is also important to document the corners you cut and put in place a plan to fix the mess you left behind at a future date. At the end of the day it is as simple as this.  In software development it is 'Pay me now, or Pay me more later'  We all know there are deadlines to meet but if we don't stay aware of the escalating cost of development for the corners we cut today, those cuts could become the downfall of our application tomorrow. Great post Jeremy... You can find it here. Posted Mar 12 2007, 08:15 AM by Derik Whittaker with no comments Filed under: Development

• Clean Slate - Creating a Good Hierarchy in a Source Repository

  It is not everyday that you get the luxury of starting from scratch when setting up a Source Repository.  So when our team found out that with the installation of our new VSTS server we would also be able to create a new hierarchy for the repository we were excited.  Like most source repositories, a few years, and no policing of the repository has lead to one big ugle of a repository.  When we started to plan how the new repository would be structured, we wanted to try to look to the future as well as plan for the other teams that would be migrating to VSTS over the coming months.  Our goal with the new structure is to set up a simple, yet effective hierarchy that can be easy to follow and easy to extend. Here is the structure we have come up with so far //ROOT     /Shared         -> Shared Project         -> Shared Project's Test     /Group A (this is a team withing the department)         -> Project A             -> Sub folder         -> Project B             -> Sub folder         -> Shared Project (would be any common libraries shared at the team level)         -> Sandbox     /Group B         -> Project A             -> Sub folder         -> Project B             -> Sub folder         -> Shared Project (would be any common libraries shared at the team level)         -> Sandbox     /Group A Branches         -> Project A         -> ...         -> ... The rational behind this structure is that we want each team/group to have their own space, but still have a location for any department wide assemblies to go.  We wanted to move all branches out of the dev directories in order to allow us to do a get from the root of a group/teams folder (i.e., do a get on //Root/Group A) and not worry about getting all our branches. Let me know what everyone thinks.  Is there a better way, is this too complicated. Thanks Posted Mar 09 2007, 07:15 PM by Derik Whittaker with no comments Filed under: Development

• Adobe Photoshop team goes agile, and WINS

  Looks like Adobe and their new VP has introduced Agile to their Photoshop team and WON big time.  I think it is great that an established software company like Adobe can give Agile a try (a real try, not a 'we are going to try, but not really try') and had success with it.   I personally like this because I work for a company that does not 100% buy into agile (although are team follows a lot of it principles) because they think that it will mean less features and less control.  Hopefully as more and more companies publish their success with agile, more and more people/companies will start to believe.   Go Adobe....   Link to the original article here       Posted Mar 09 2007, 10:13 AM by Derik Whittaker with 1 comment(s)

• Code Branching on a Mulitple Project Team

  Everyone that has worked on any type of long term software project has had the need to branch their code at one time or another for one reason or another.  Currently the team that I am on had to branch both projects (1 team, 2 projects) in the same week.   Normally branching can be a pretty straight forward concept.  You take the code base from the trunk and move all needed code into a branch so that if you need to make changes to the branch you can and allow yourself the ability to continue forward progress on the trunk. My question for everyone is this.  If there are multiple projects sharing some level of the same code base how should the projects be branched. Here is a idea of how our code is laid out in VSS. //root     -> Common project 1 -- company wide project     -> Common project 1 Test -- Company wide test project for Common Project 1     -> Application 1 Root     -> Application 2 Root         -> Note: There are directorys here that are used by application 1 as well When Team A did their branch, they ONLY branched the source that was under -> Application 2 Root folder and nothing else.  Since they did not branch any of the shared code, the modified their build project to pull the code out of the trunk.  This caused a big problem for our 'home grown' build machine (yea, i know... why home grown.  We are in the process of switching to TFS).  After about 3-4 hours of playing around we finally fixed the issue with the build machine. When Team B did their branch, they moved EVERYTHING over into a new structure.  By doing this they did not encounter any issues with our build machine. Having never really worked on team that had multiple projects that are independent, but share the same code base I have never really given it any thought as to how to branch properly.  In my opinion, when you do a branch ALL source that is needed for that branch should be moved.  This will allow for NO contamination of code and less headaches.   What does everyone think?  Did team A do it right or Team B?  HELP Posted Mar 02 2007, 06:59 AM by Derik Whittaker with 2 comment(s) Filed under: Development, Methodology