Give me your most complex program and I will trump it by presenting you with the program that was responsible for creating the human who created that program.

If you haven’t figured it out by now that program is human DNA and that masterful programmer is the Creator Himself.

Doesn’t matter what religion you are

It is pretty difficult to fail to recognize that a program as complex as a human being’s genetic code was created, not randomly assimilated.

As programmers we have a unique perspective in life.  We are able to truly understand God’s masterwork in the creation of human life.  We are able to grasp loosely the ungraspable magnificence of a program so complicated, yet executed so simply.

We also have the unique position of fundamentally understanding that complex programs could never be created by random chance, regardless of time.  We can look at a piece of code or functioning computer program and we can understand that its creation required an intelligent creator.  Other people and professionals do not have this insight that so many of us are fortunate to have.

Qualities of the code

We’ve been treating data like code recently in C# with the introduction of Lambda expressions and other languages have been doing it for much longer, but the ultimate example of this practice is right there in our own DNA.

DNA is data, a message, and code all together at once.  Just like a data structure in the memory of a computer executing a program, it lacks meaning without the context of the cell that it is in.  Amazingly though, this data is recombined in different ways that are dictated by two separate and different instances of itself to produce a third separate instance of itself that still makes sense.

Just to give you an idea of how insanely complex that idea is (despite the simple execution of it), it would be like if you wrote a webserver that could spawn new instances of itself by contacting another, but different copy of your webserver and getting 1/2 the source code payload from itself and the contacted server, then actually combining that code to create a new copy that is different, yet still passes all of your unit and integration tests.

One of the qualities we often look at for our code is the size of the code in relation to what it can accomplish.

A decent estimate is that the human genome is about .35 gigabytes of data.  That data is stored on such a small space that we can’t even see it with the naked eye.  There is no more compact form of data in the universe that we know of.

Not only is this data compact, but consider how much functionality is built into this small .35 gigabyte package?  If you had to write acceptance tests for the human body, you might spend several lifetimes doing it.  If you had to write acceptance tests for just a single cell in your body, that feat itself could take years and still not be complete.  Imagine trying to write a program that took up .35 gigabytes of data, yet contained millions of acceptance tests worth of functionality.

We certainly could go on and on about the qualities of the human code, but I want to point out what perhaps is one of the most unique and amazing… the ability for the code to create its own hardware.

In actuality the code and that hardware are much the same.  DNA replicates by a chemical reaction that causes the entire molecule to unwind and split.  RNA inside a cell is created from specific portions of the DNA in order to create different protein chains which are used to construct little machines that will replicate the DNA and cells and in turn create machines capable of doing the same.

The process is very complex and not wholly understood, but in effect the end result is that DNA contains the instructions inside of a cell to create the machinery to host another copy of itself and execute that code.

Easter eggs

Let’s not forget the little Easter eggs that have been thrown in by the designer of our codebase.

How about a hiccup or a tear?

Sadness or laughter?

There are some “evolutionary theories” as to why these things exist, but in reality they serve no specific purpose for either our survival or well being.

In my mind these are clearly Easter eggs left by the designer to show His handiwork.

Why am I writing this post now?

I didn’t want to go completely off subject and boast about my wonderful daughter that was born on April 17th 2011 at 2:33 PM, since this is a professional blog. 

But, there you have it.

The amazing birth of my first child reminded my of the incredibly complex code that keeps us all breathing, procreating and living life that we seem to take for granted each and every day.

Welcome to the world Sophia Grace!

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

I just got my first course published on Pluralsight!

The course is called Android Development for .NET Developers and it covers most of the basic knowledge you would need to go from knowing nothing about Android development to being able to create a fairly simple application and publish that application to the Android Market.

If you haven’t checked out Pluralsight, it is a really good site for a wide variety of developer training videos.  They really managed to get some very good content on the site and there are videos on just about every .NET topic you can think of.

I have also really enjoyed working with the guys that run Pluralsight, they are all very friendly and very knowledgeable.  Thanks to David Starr and Fritz Onion for all their help getting my course ready and published.

You never really learn something till you teach it

This simple truth became more apparent to me than ever during the process of making this course.

I thought I had a pretty good understanding of the Android fundamentals, having published a fairly complex application, PaceMaker.

What I became quickly aware of is that there is a huge difference between having knowledge and having understanding.

I equate knowledge as possessing a formula to be able to do something, but lacking knowing why or how to make modifications to the process.

Cooking provides an excellent example of this.  There are many people in the world who know how to cook a large number of dishes.  But many of these people only have the knowledge of cooking.  They have a large collection of recipes which they can follow to produce the desired result.

A professional chef on the other hand, has a true understanding of cooking.  This person might have knowledge of many recipes, but they also understand why the particular ingredients are used and can make modifications to those ingredients and steps.  They may even create something without preset steps because they understand what they are doing, not just have knowledge about it.

It was great to have the experience of creating these videos because I was able to acquire an in-depth understanding of Android development, not just a knowledge of what to do.

If you ever have the opportunity to teach, I definitely recommend you take that opportunity.  Even if you don’t think you are qualified to teach a subject, by the time you have prepared what you are going to teach, you will be qualified.  Trial by fire perhaps, but well worth the outcome.  Plus you’ll be helping others in the process.

Much harder than I thought

I do have to admit though, recording training videos is definitely much harder than I had originally anticipated.

In order to get 40 minutes of video, it might take 6 hours worth of work or even more depending on the prep work involved and how much editing after getting the raw footage.

I really expected that it would take about as much time as it takes to record something to produce that something, but I definitely learned that is not the case.

I often found that I had to draw a line and stop trying to refine a video because you can literally spend an unlimited amount of time editing and tweaking a video.

Another revelation that might be apparent to everyone else, but was quite an epiphany to me was that you can edit “umms” out of video very easily.  You can’t even notice where they are cut out!  My first video, I didn’t even realize I could edit anything, and I ended up taking like 50 cuts until I could get it right.

Overall though, great experience, lots of fun

I felt like I’ve been stretched in a different direction, as I had never done any video or audio recording before and had never really spent much time in a room talking to myself pretending to talk to other people, but it was a good kind of stretching.

I really actually enjoyed the process and I will definitely be doing more of this kind of work in the future.  Probably going to take a bit of a break before I start my next course though.  I want to make sure I take some time to get a good retrospective of the process and sharpen my saw a bit so my next videos can be even better.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

First month of sales are over, and it was much better than I had expected.  About 75 purchases in the first 30 days.  Not a huge amount, but that is almost with no advertising, most people who found the app found it in the market.

So what is the next step for PaceMaker?

Well, with the iPhone coming to Verizon this month, I think it is pretty obvious that it is time for the iPhone version.

Only problem is…

I know nothing about iPhone development!

Well I didn’t last week, but I am slowly learning.

I bought my first Mac ever last week, a MacBook Air.

I have to say, the operating system on Macs has come a long way since I last used one.  (Did I mention I also don’t even know how to properly run a Mac?  But I know Unix, so I should be ok.)

I feel like the Mac interface is so much more polished and uniform than Windows, but it is pretty scary inside when you consider all the low level C and Objective C code.

Then again you have to consider that the wonderful .NET CLR is written right on top of a really crusty win32 API layer which is a bunch of scary C code that is about 20 years old.

So I am setting out on a brave new quest to learn Mac, iPhone and Objective-C and somehow port my application over to the platform.

Objective-C is kind of like an alternate universe

I was trying to think how I would describe Objective-C and here is what I came up with:

Objective-C is like one of those movies where there is an alternate universe where the same people exist as in this universe, but in some areas their technology is really advanced, but in others it’s really ancient.  Like a bunch of people flying around in flying cars, but their weapons are still bows and arrows.

I used to be a C++ programmer, so not too many things scare me, but some of the magical constructs in Objective-C are very frightening indeed.

I was just reading about a strange construct today that allow you to basically create the equivalent of a C# interface, but in Objective-C it is called a “Protocol.”  This seems fine and normal until I read the paragraph that says you can define some of the methods as “Optional.”  What?

Let me put it in C# terms so you can understand it.  In C# it would look like this:

public interface ILovePuppies
{
   private void HugThem();
   private void SqueezeThem();

   perhaps Corpse KillThem(); // Implement this one
                              //only if you feel like it.

}

This is not a joke.  I still can’t quite figure out what this is for, but it is kind of interesting.

Another thing I found interesting is Objective-C has this thing called a “Selector.”  It is not a function pointer, it is a variable that references the name of a method.

How is this different than a function pointer?

It is actually the name of the method being referenced.  So if you have a class Dog that has a method “Wag” and you have a class WildGuesser who has a method “Wag”, passing them the “Wag” selector will cause very different results.  How bizarre.

It’s weird to get sucked into the Mac world

It’s actually kind of funny.  Here were all us Java and C# programmers off basically doing the same thing; creating our interfaces and arguing about dependency injection and mocking our unit tests and these Mac geeks with their bow ties and designer jeans were going a totally different direction.

It was only by random chance that our two parallel universes should violently collide.  The iPhone came out and suddenly all these strange “Mac boys” were teaching us this new old language and reminding us to free up own memory again.

FOR GOD’S SAKE I JUST IMPORTED A C HEADER FILE FOR THE FIRST TIME IN 10 YEARS!  THIS IS CRAZY!

But, I have to admit it is actually kind of fun.

Sometimes a change of pace is refreshing

I don’t mean my harsh language to be derogatory towards you Mac heads out there.  You know you are cool, your boy Steve is leading this century’s computing revolution.

I honestly mean that.  Good job guys, you may just take over the world.

I’m actually enjoying this experience and beginning to think that if I come out alive, I will have gained some very valuable insights into programming in C# and Java.  It is good sometimes to view something from a totally completely different perspective.

Who knows maybe I’ll get to write that Objective-C vs Java vs C# post I’ve been dreaming of.

But what about…

MonoTouch?

Meh.  If I am going to program for a platform, I am going to program for that platform.  I’m not going to half learn how to program for the iPhone and learn on the C# crutch.  I didn’t do that for Android and I’m not going to do it for iPhone either.

Why?

Because I am stubborn and cranky?  Partially, but I actually have a few sensible reasons also:

1. MonoDroid and MonoTouch both implement another layer over the phone’s framework.  Adding this additional layer makes it harder to do low level stuff, and with something as low level as a phone, doing low level stuff is often important.
2. You are still using the underlying framework for either Android or iPhone.  It is not like using C# code behind the scenes allows you to write a Silverlight UI that you can use on any of the mobile platforms.  You still have to learn the entire phone development framework, which dovetails into point three…
3. It is much easier to get help and find resources for raw Android or iPhone development than for MonoX development.  Not trying to bash the Mono projects here, but most of mobile programming is spent googling for how to do things.  By sticking with C# you are really limiting yourself in terms of finding answers.
4. Change and learning different things is good.  I’m not sure you can fully appreciate the design of a framework or platform unless you develop against it the way it was designed.  I could be wrong, but I think there is a potential “lost in translation” problem in using C# on the iPhone or Android platforms.

After I learn iPhone development, I might try MonoTouch and see if it makes my life easier, but I need a good baseline first.

Well, I’m off on my journey.  Going to head on to the back of the wardrobe in the “Spare-Oom.”  I have to meet Mr. Tumnus, we are having tea with Mr. Wozniak and Mr. Jobs.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

I consider var to actually be quite a useful language feature to reduce repetition and make your code slightly more flexible for refactoring, but I’ve always had one little problem with it.

What if I want a base class type or interface?

I most often run into this problem when I am working with lists.

Have you ever written some code like this?

var myList = new List<int>();

The problem with this code is that we are stuck with the concrete List implementation for our variable myList, because we don’t have a way of specifying that we actually want an IEnumerable to be our reference type.

The solution is so simple that I am a bit surprised I didn’t think of it earlier.

I had always assumed that I just couldn’t use var there and would have to declare the type like so:

IEnumerable<int> myList = new List<int>();

But we can actually just use as to keep our var in place if we want to.

var myList = new List<int> as IEnumerable<int>

So it’s actually a little more verbose, but I think it is a bit more clear, and it is more consistent if you are using var everywhere else.

There has to be a better use

I’ve been racking my brain trying to come up with more useful ways to use this little combo, but I can’t really seem to come up with anything.

It seems like there has to be something else you could use this combo for.

What do you think?  Any ideas?

Someone mentioned in the comments that it wasn’t very clear exactly what was going on with the final code.  I tend to agree that this:

LogOnError(_riceCooker.Cook);

… is not very clear.

Really, there are two problems with this code that I can see.

1. It is not clear what this is going to do or whether or not LogOnError or Cook is the method we are concerned about.
2. It’s not very self-discoverable at all.  If we had a library of useful wrapper methods like these, we wouldn’t have a good intellisense way to know what they are.

I can solve both of those issues, but doing so starts to move us into a weird zone where I am not quite sure I feel comfortable.  But, nevertheless, in the name of science…

Let’s start backwards

Liking fluent interfaces, here is the kind of syntax that I would prefer to be able to use:

Wrapper.Wrap(_riceCooker.Cook).With.LogOnError();

It is a little bit longer syntax, but I like it for a few reasons:

1. It clearly indicates what is going on here.  We are wrapping a method call using a wrapper.  We are wrapping with a method called LogOnError.
2. You get intellisense all the way.  The correct implementation of this, should let me Type With + ‘.’ and then see a list of all the possible wrapping methods I have implemented.  This makes the wrapping set of methods self-discoverable.

I really like the idea of being able to easily change the functionality of the wrapping just by changing the last part of the line.  For example, if we had implemented a wrapping method that was LogAndAbortOnError(), we could change our code to use that pretty easily.

Wrapper.Wrap(_riceCooker.Cook).With.LogAndAbortOnError();

If we implement this correctly, intellisense will give us our options.

Making it so

Creating a fluent syntax in C# can often involve quite a bit of magic and voodoo.  I always like to gather my reagents before embarking on such a journey.

So grab a live chicken, a stapler, and a sharp knife and let’s go!

First step, let’s simplify this.  The With is nice, but it is just for flow, we don’t really need it.  So let’s figure out how to implement our syntax without the With and add it in afterwards.

Wrapper.Wrap(_riceCooker.Cook).LogOnError();

First the easy way.

1. Create a static Wrapper class with a Wrap method that takes an Action and returns an Action.  (We’ll use this to convert whatever we pass in to an Action, so that we can use a Lambda expression or any method call there.)
2. Create a static extension method that operates on an Action.  Call it LogOnError.

public static class Wrapper
{
    public static Action Wrap(Action action)
    {
        return action;
    }
        
    public static void LogOnError(this Action action)
    {
        try
        {
            action();
        }
        catch (Exception exception)
        {
            // Log the exception here
        }
    }
}

Not too bad.  Not a large amount of magic going on here.  Just using an extension method.

But, we already have a problem.  Using a plain old Action is going to give us too many choices in the intellisense drop down.  It could make it hard to know what our real options are and when we try and add the With syntax later, we will need to use a property off of an object we return from the Wrap method.

Making it better

We can fix this by actually wrapping the Action with a custom type that we can add our methods to.

Instead of Wrap returning an Action, it will return a WrappedAction.

public static class Wrapper
{
    public static WrappedAction Wrap(Action action)
    {
        return new WrappedAction() {Action = action};
    }
        
    public static void LogOnError(this WrappedAction wrappedAction)
    {
        try
        {
            wrappedAction.Action();
        }
        catch (Exception exception)
        {
            // Log the exception here
        }
    }

    public class WrappedAction
    {
        public Action Action { get; set; }
    }
}

Looking better.  Now when we put a ‘.’ at the end of our Wrap call we only see LogOnError as an option.

We can be sure now that if we create an extension method for a WrappedAction, we will make sure that method is self-discoverable.  Before, the generic Action extension  method could make our method show up places that we don’t want it to and can get lost in the other methods on Action.

Making it done

The last thing we need to do is add the With.

Ideally, when we hit the ‘.’ on the end of the Wrap method, we want to see With as an option.  When we hit the ‘.’ on the end of the With property, we want to see LogOnError as an option.

In order to accomplish this we need to:

1. Add a With property to the WrappedAction.
2. Have the With property be of a new type (WrappedActionTarget) so that we can add our extension methods for that new type.
3. Change the extension method to operate on the new type.

Here is what we end up with:

public static class Wrapper
{
    public static WrappedAction Wrap(Action action)
    {
        return new WrappedAction() { Action = action };
    }

    public static void LogOnError(this WrapperMethodTarget target)
    {
        try
        {
            target.WrappedAction.Action();
        }
        catch (Exception)
        {
            Console.Write("Logging this error");
        }
    }
}

public class WrapperMethodTarget
{
    public WrappedAction WrappedAction { get; set; }
}

public class WrappedAction
{
    public Action Action { get; set; }

    public WrapperMethodTarget With
    {
        get
        {
            return new WrapperMethodTarget() { WrappedAction = this };
        }
    }
}

Now we can use the syntax of:

Wrapper.Wrap(_riceCooker.Cook).With.LogOnError();

We can move that LogOnError method out to another class, or create new extension methods somewhere else.  I just put it in there to avoid creating another class.

Is this really practical?

I don’t know.  To be honest, I was playing around with creating extension methods that work on Actions and I came up with this way to use them.

I could see making a wrapping library that had different kinds of ways you would wrap method calls built into it.  It could allow you to specify how you log in a configuration and then you would get all of this common stuff automatically.

Even if it is not practical, it’s pretty fun, and it demonstrates the power of Action, or rather functional programming in general.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

It is a little difficult to implement though.

To be honest, I don’t think I’ve ever really seen it successfully implemented.  I mean sure, I’ve seen examples of how you could use it for “cross-cutting” concerns like logging.

The problem is it is usually pretty difficult to use, and the only real practical application I can ever come up with is logging.  I know, it is probably just my lack of knowledge in the area, but if you bear with me I’ll show you a neat little trick you can use to address cross-cutting concerns by doing something similar to what AOP does using Action<>.

Putting it all in one place

The main problem AOP tries to solve is taking aspects of your software that exist in many different places and condensing them into one place for you to maintain.

Exception handling and logging tend to be the most infamous of these cross-cutting concerns.  Many places in your code you no doubt have many instances where you catch an exception and the only thing you can really do is log it.

I’m going to show you a little easy way to do that using Action<>.

Giving credit where credit is due, I got this idea from some code that a coworker of mine, Subha Tarafdar, wrote.  (He is a genius.)

He wrote some code to basically do what I am going to show you, but with retrying database queries.  He was able to reduce many places in the code base where we had repeated logic to retry executing database queries when getting a deadlock or timeout.

Does this code belong to you?

public void MakeRice()
{
    try
    {
        _riceCooker.Cook();
    }
    catch (Exception exception)
    {
        // Don't care if this fails,
        // there is nothing we can do about it.
        Logger.Log(exception.Message);
    }
}

Ignore that I am catching a general exception here.  It is a bad practice, but sometimes all you are going to do is log whatever bad thing happens and move on.

It’s pretty common to do something in a try block and catch an exception only to log it.

Think about how many times this code or something similar to it might be sprinkled throughout your code base.

Action<> to the rescue

If you’re not familiar with Action<> take a look at this post I did that gives a very simple explanation for how it works.

We can take the logic of the try, catch, and log exceptions and put it into a method that only varies by what action we do.

public static void LogOnFailure(Action action)
{
    try
    {
        action();
    }
    catch (Exception exception)
    {
        Logger.Log(exception.Message);
    }
}

I’m not a big fan of static methods but in certain cases they make sense.  The alternative is to have all of this code sprinkled throughout your code base.

Now that we have this method, we can do anything we want and know that if there is an error it will be logged.

Check this out:

LogOnFailure(_riceCooker.Cook);
LogOnFailure(KickACat);
LogOnFailure(() =>
                    {
                        Wakeup();
                        SmellTheRoses();
                    }
            );

And if you decide you want to change how you log the error or what you do on it, you can change it all in one place.

Not just for logging

You can apply this kind of solution in many places where you have cross cutting concerns in your code base.

Here are a few suggestions for places you might consider this kind of a solution:

• Retrying on failure logic
• Using an alternative service for a failure (web service “A” failed, but we can use web service “B”)
• Database connection and connection closing logic.  (Open connection, do something, close connection.)

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

After spending the last two years or so writing mainly Java code, getting back into Visual Studio felt a little awkward and painful.

Where did all my keyboard shortcuts go?  Why can’t I navigate to members in a class?  Oh, yes Resharper… ah that’s better.

But then it happened.

I was minding my own business writing some code… la la la

public bool IsYummy()
{
    if(!areOverridesLoaded)
    {
        LoadOverrides();  // loads the override from the database into this.theOverride
    }

    if(this.theOverride != null)
    {
        return theOverride.IsYummy.GetValueOrDefault(food.IsYummy);
    }

    return food.IsYummy;
}

public bool IsFruit()
{
    if(!areOverridesLoaded)
    {
        LoadOverrides();
    }

    if(this.theOverride != null)
    {
        return theOverride.IsFruit.GetValueOrDefault(food.IsFruit);
    }

    return food.IsFruit;
}

public bool IsVegetable()
{
    if(!areOverridesLoaded)
    {
        LoadOverrides();
    }

    if(this.theOverride != null)
    {
        return theOverride.IsVegetable.GetValueOrDefault(food.IsVegetable);
    }

    return food.IsVegetable;
}

Oh my, repeated code!  What ever shall I do?

Hmm… It varies by property names only.

Surely I can refactor out the override loading code.  Can’t put it in the constructor, because the goal is to lazy load the overrides from the database.

Func<> to the rescue!

This is the power of Func.  Of delegates really.  You can’t do this in Java folks… Hold on to your chair.  Here we go…. Whee…..

private bool ReturnValueOrDefault(Func<Food, bool?> FoodProperty, bool defaultValue)
{
    if (!areOverridesLoaded)
    {
        LoadOverrides();
    }

    if (this.theOverride != null)
    {
        return foodProperty(this.theOverride).GetValueOrDefault(defaultValue);
    }

    return defaultValue;
}

public bool IsYummy()
{
    ReturnValueOrDefault(o => o.IsYummy, food.IsYummy);
}

public bool IsFruit()
{
    ReturnValueOrDefault(o => o.IsFruit, food.IsFruit);
}

public bool IsVegetable()
{
   ReturnValueOrDefault(o => o.IsVegetable, food.IsVegetable);
}

Good has won…

Evil has been defeated…

Code has been deleted…

Thank you Func<>

Don’t forget the Super Combo!

Also, check out the new page I created, a compilation of useful posts I have written about building software in an Agile way.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

I’ve seen many people get taken to the mat when trying to merge.  Today, I’m going to give you a simple technique that can help save you the embarrassment of your favorite source control program kicking you right in the head.

Bring the plate to the food

Often as a kid, the table would be set and dinner would be ready.  I would try and take some food from the kitchen over to my plate on the table.  (Grab the hamburger and carry it over to the plate.)

My dad would often tell me,  “Bring the plate to the food.”

Which would mean that I would have to take the plate from the table.  Bring it to the kitchen.  Put the food on the plate.  Bring the plate back to the table.  Oh, what a hassle.

Less food ended up on the floor that way.  Now it seems obvious to me.  But, back then it didn’t.

So it is with merging

It is exactly the same way with merging.

Wise-man once say:

If you want to merge to a location, you must first merge from the location

Anytime you are about to merge to some branch, always merge from that branch first.

Let’s say that you created a branch off of your trunk.  You started working in that branch and you are done with whatever you are doing there.  You are ready to merge it back up to trunk.

• First merge trunk to your branch
• Resolve any conflicts
• Test on your branch
• Then merge your branch (that has the trunk changes already) into trunk

Why can’t I just merge to the destination, why merge in first?

It may seem like a bunch of overhead, but if you’ve ever merged to trunk or a release branch and broke it for everyone, then scrambled to try and fix it, you’ll probably see the benefit in making sure that all merges to release branches or trunk are trivial.

A trivial merge is a merge that can be automatically done by your source control.  It doesn’t require human interaction.

If you merge in, and then merge out, the merge out will always be a trivial merge.  So in reality you’re not really adding any overhead at all.  You are just handling the possibly difficult merge on your branch as opposed to the trunk or release branch.

Another important reason is that you want to be able to test your changes with the other changes that have happened in the system since you branched off.  Most of the time other changes will be happening at the same time you are making changes.

The only way to know what the interactions will be is to test them.  The best place to test them is on your local branch so that you don’t interfere with everyone else.

Derick Bailey provides an excellent detailed description of what I am talking about in his post on merging.  He calls it the merge dance.

My dev cave

Without further adieu, here are the pictures of my dev cave I set up for my new job.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

Took me awhile, but I finally finished reading: The Definitive Antlr Reference: Building Domain-Specific Languages (Pragmatic Programmers)

It is hard to separate reviewing ANTLR from reviewing this book, which is written by the author of ANTLR.  ANTLR is a fantastic tool, which really opened my eyes to the capabilities of creating DSLs to solve what otherwise would be very difficult problems.   I looked up many resources on ANTLR, and by far this book is the best resource available.  If you are going to try to learn to use ANTLR buy this book.

Good:

• First few chapters start out very simple and easy to understand.
• Very good examples of how to use ANTLR with real code and real programming languages.
• Excellent coverage of each feature of the tool, and why it was built that way.
• Builds on concepts of language parsing while introducing ANTLR features.

Bad:

• Gets a bit complicated near the end of the book.  Some of the examples and concepts get pretty deep into complex language parsing, although there is a warning about it.
• Missing information on best practices for using ANTLR.  (Would have liked to see a chapter dedicated to that subject.)

What I learned:

I had no idea that creating a DSL could be so easy.  Language parsing really is not that hard.  It is intimidating to think about creating a DSL, but with the right tools, it is not really very difficult at all.

I learned how to use ANTLR, and got most of my questions answered about how to accomplish pretty much anything I would need to do in ANTLR.

There was a topic about using string templates, that made me realize how useful it is to not hard code the code generation into the tree parsing when creating a language.  By separating out the code generation into templates, it is possible to target several different languages easily.

I got a much better understanding about general language parsing and design, as well as a good understanding of Abstract Syntax Trees (ASTs), why you would use them, and how to use them effectively.  I got a good understanding of why you would need a multi-pass parser for parsing a language.

This book will change the way I look at many problems.  I feel pretty confident in implementing DSLs to solve the right kind of problems after reading this book.

I have implemented hand written language parsers in the past, but after reading this book, will never do that again and would highly recommend reading this book and checking out DSLs in general.  It is easier than you think.

I don’t own a mac for the sole purpose of running Windows in a virtual machine so that I can actually do my work.

In fact, I bought a Droid.

But I bought an iPad on Saturday anyway!  Why?

Well, like any good software developer, I don’t like duplication.  I don’t like two devices of similar size taking up space and having to be charged.

Sometime last week, I realized that my Kindle DX and my netbook, could both be replaced by an iPad.  (At least I realized my Kindle DX could be, and once I actually used the iPad, realized the netbook also can be.)

I bought the device expecting it to be basically a replacement for my Kindle DX with color.  I thought that for almost the same price, I might as well get a device that is color, since I am really using the Kindle DX for mainly reading PDFs.

Even with just that functionality, it is a very good bargain. Both the iBooks application and Kindle’s own iPad application provide a better user experience than the Kindle or any other eReader that I know of.  There is just something about being able to turn pages, and have color images in your books, that makes it feel so much more like a real book.  You don’t really realize how much better the eReader experience can be until you try an iPad.

In addition, I have been pretty impressed with other aspects of the iPad that I had scoffed at before the release.  Perhaps the most impressive thing about an iPad is the screen.  It really does feel “magical”.  It is hard to explain, but the viewing angle, combined with the crisp colors and very responsive refresh are like nothing I have ever seen before.

Browsing the web and typing are much easier than I would have expected.  I can actually hold the iPad landscape and thumb type.  (Which might not be possible for some.)

I spent a good amount of time this weekend staring at my netbook, trying to figure out why I would not put it on Ebay.

I didn’t come up with a good answer.  There were some things that I might want to do on a laptop, that I couldn’t do on an iPad, but for pretty much everything I would want to do on a netbook, I could do it easier on an iPad.

One of the really important features of the iPad that makes it smack down netbooks is that it turns on instantly.  Having to boot up the netbook is enough of a deterrent to make it sit over in the corner unused, unless it is worth waiting 20 seconds to boot.  (Which most uses of it are not.)  The iPad is also another device that you don’t really have to manage configuration on.  If you are like me and have a home PC and a laptop, you probably aren’t thrilled with managing configuration on a netbook on top of all that.  The iPad just works.

After seeing how good Plant’s vs. Zombies runs on the iPad, and how nice it looks, it may turn out to be a good gaming platform also.  Time will tell.

All in all, I haven’t had the iPad for more than 2 days so far, but I am liking it.  I intend to give a more in depth comparison between Android OS and iPhone OS, now that I have a device running each.  I highly recommend at least going out and demo-ing one, because it is kind of difficult to understand why the device is so neat until you’ve actually played with it yourself.