The other day I came across APPLY, or rather CROSS APPLY.

After reading through documentation on how it works and articles about it, I had a bit of trouble understanding it because I couldn’t really find a simple explanation.

I am going to try to explain it as simply as possible so you can start using it right away.

How CROSS APPLY works

The basic idea behind CROSS APPLY is to allow you to join two sets of data together.

If you understand how INNER JOIN works, you already understand CROSS APPLY.

The only difference is CROSS APPLY also allows you to join in a set of data in which that set of data is created or dependent on each row in the first set.

So basically what that means is that for a normal join you would, for example, join two tables that shared a common key.

I could join my customer table to my orders table to see all the orders for a particular customer like so:

SELECT *
FROM
 orders o
 JOIN customers c
 	ON o.customerid = c.customerid
WHERE
 c.companyname = 'Around the Horn'

Notice how the join is operating on a key that exists independently in each table.

We could rewrite this to be exactly the same using the CROSS APPLY syntax instead like so:

SELECT *
FROM
  orders o
  CROSS APPLY (
    SELECT *  FROM
	   customers c
    WHERE
	   o.customerid = c.customerid) AS c
WHERE
  c.companyname = 'Around the Horn'

We can prove these results sets are exactly the same by using EXCEPT to make sure there are no rows in one set that aren’t in the other and then flipping it, like so:

SELECT *
FROM
    orders o
    CROSS APPLY (SELECT *
                 FROM
                     customers c
                 WHERE
                     o.customerid = c.customerid) AS c
WHERE
    c.companyname = 'Around the Horn'

EXCEPT
SELECT *
FROM
    orders o
    JOIN customers c
        ON o.customerid = c.customerid
WHERE
    c.companyname = 'Around the Horn'

Just run this exact query again swapping the SQL above the EXCEPT with the SQL below and make sure it has no results as well.  If both of those queries have no results, then you know the results from each query are the same since EXCEPT will show any results that are in the top query but not in the bottom one.

So when is CROSS APPLY useful?

Remember how I said it can do more than a simple join?  Joins are restricted to only joining two sets of data that could be queries independently of each other.

What if I said give me the three most recent orders for each customer?

Take a minute and think about how you would write that query.  Go ahead and try to do it.  I’ll wait.

There are a few ways to do it without using CROSS APPLY, but none of them are really very easy or perform very well.

Using CROSS APPLY it is simple though:

SELECT *
FROM
    customers c
    CROSS APPLY (
                 SELECT TOP 3 o.orderdate
                            , o.shipcity
                 FROM
                     orders o
                 WHERE
                     o.customerid = c.customerId
order by o.orderdate desc
) as top3;

So CROSS APPLY is useful whenever you have some data that you would want to be able to join against, but are forced to do some kind of sub-query instead because the data you are trying to join is not going to map well against a single key.

The other instance in which CROSS APPLY will be useful is when you are  doing a sub-select that has more than one value you would like to use in your final query.

For example if you were sub-selecting from an Order Details table to match up order ids that had a Quantity greater than 5, that sub-select would need to return exactly one column in order for you to use it in your where clause.  If you wanted to use other columns from the sub-select, you would have to do another sub-select for each of these columns.

If you first try to rewrite the sub-select as a JOIN and find that you can’t, you may be able to write it as a CROSS APPLY.

How to know when to use CROSS APPLY

There isn’t a good solid rule you can use to identify when you should use a CROSS APPLY but having the knowledge of CROSS APPLY and how it works can help you when you are trying to tune queries and you are having a difficult time constructing one.  It is another option you can try.

Here are some general guidelines of times when you might want to use CROSS APPLY:

• A query where the result set you want to JOIN against is in some way related to the data in the first set.  (Example: one column in the first table tells you how many rows in the 2nd table to get)
• A query where you are doing a sub-query, but need more than one value from the sub-query
• Anywhere you are using a Common Table Expression (CTE) could possibly be rewritten as a CROSS APPLY
• A query that has a large set of data it is joining against and then filtering out.  You can change it to a CROSS APPLY that does the filter in the CROSS APPLY statement.
• Any time you are trying to join against a table function (this is actually what CROSS APPLY was created for.)

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.

Finally, I have succeeded in porting the application over to iPhone and it was definitely much harder than I had anticipated.

But I am glad to announce that as of today you can find PaceMaker for iPhone in the Apple App Store.

If you don’t know what PaceMaker is, you can read about it in my original post above or in the description in the app store, but to sum it up briefly, it helps you run at a desired pace by telling you to speed up or slow down when you are running too fast or too slow.

A unique perspective

Having originally written the application and then porting it over to iPhone gives me a kind of unique perspective on mobile development platforms.

Although it was a bit painful at times to basically recreate the same thing I already spent so much time and energy creating, I was able to very realistically contrast the two development platforms in many areas.

One of the major pain points I experienced was in documentation.  Google’s documentation on the Android platform is sometimes lacking, but is much more complete and descriptive than Apple’s iOS documentation.

I am still quite a bit torn on which platform I like more and which platform I think will win out in the end.  I do believe that if Apple improved their developer tools and moved to a new, more modern development language, that they would have a distinct advantage.

It seems to me though that whoever integrates the best across multiple devices and gets the highest quality applications built for their platform will be the winner.  iCloud could be a huge step in that direction for Apple.

Sharing the knowledge

I’ve just talked with my curriculum director at Pluralsight and I will be doing a beginning iPhone development for .NET developers course just like the Android Development for .NET Developers course I did earlier this year.

I’m pretty excited to do this because I am going to try and draw some major parallels between the two platforms and also from the .NET perspective.

I hope to create the course just like the Android one, where we will step by step create an application from scratch and then publish it to the Apple App Store.

Look for that in the next few months on Pluralsight.net.

Dailymile.com integration

Also included with this release for iPhone and Android is Dailymile.com integration.  I think this feature is pretty cool!  So I am really excited about it!

Dailymile.com is basically a social site for runners and cyclists.  It is basically a Facebook for runners.

I have added a feature to the Android and iPhone versions of PaceMaker to allow you to post your run details, including the GPX map of your run, up to the Dailymile.com server on your wall.

So when you go for a run you can capture all the information from your run and see it on Dailymile.com.

This was quite a pain to implement as I had to implement OAuth2 authentication in both platforms and integrate with a REST API.  But what a great learning experience!

Anyway, if you are a runner out there and you get PaceMaker, feel free to send me an email or drop me a comment.  I am always looking for feedback so I can improve the app.

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.

This time I am going to try and give you some good tools to enable you to get good at solving programming problems.  (Really algorithm type problems specifically.)

Common mistakes

When most programmers are given a programming problem in an interview, they make several key mistakes.  The most severe of those is the improper allocation of time.

If you have heard the saying “measure twice and cut once,” then you are probably familiar with the idea of spending upfront time to make sure something is done right, rather than diving right in.

The most common mistake I see when conducting interviews or watching someone try to solve a programming problem is they try to start writing code as soon as possible.

You must resist this urge.

You really want to make sure you take enough time to understand the problem completely before attempting to solve it.

Another big mistake is trying to over solve the solution on the first iteration.  Keep it simple, don’t try to get fancy.

A simple set of steps

I am going to give you a simple set of steps to follow which you can use for any algorithm type programming problem.

1. Read the problem completely twice.
2. Solve the problem manually with 3 sets of sample data.
3. Optimize the manual steps.
4. Write the manual steps as comments or pseudo-code.
5. Replace the comments or pseudo-code with real code.
6. Optimize the real code.

As much as 70% of our time should be spent in steps 1-3.

Let’s look at each step.

Read the problem completely twice

This is the single most important step.  You may even want to read the problem 3 or 4 times.

You want to make sure you completely understand the problem.  A good test of this is whether or not you can explain the problem to someone else.

I cannot over-emphasize how important this step is!

If you don’t understand the problem, you cannot solve it.  Do not worry about wasting time here, because the better you understand the problem, the easier it will be to solve it.

If you are given any examples along with the problem, make sure you have worked through the examples and understand why the answers are correct for each one.

Solve the problem manually

I am going to tell you perhaps the biggest secret in programming.

“Nothing can be automated that cannot be done manually!”

Programming is automation plain and simple.  You may have the ability to skip the manual steps and jump directly to code, but there is a manual process which is the foundation of any code you write.

It is very important to solve the problem manually first, so that you know what you are going to automate, otherwise you are just slinging code around.  Which while can be fun, will make you look like an idiot in a programming interview and will probably cause you to sweat profusely.

I recommend that you solve the problem with at least three different inputs to make sure you really understand your solution and that it will work for more than one case.

I often use a Mathematical Induction approach if possible.  Using this approach I might try and solve for 1 first, then for 2, then for n.

Also don’t forget to look for corner cases and edge cases and do any examples for those kind of cases you can think of.

It’s very important that when you solve a problem manually, you recognize what your brain is actually doing to solve the problem.  You may need to write out all the things you are normally storing in your head.  You want to be aware of each step, it is easy to gloss over them.

Let’s look at a very basic example, reversing a string.

If I give you a string “Zebra”, and ask you to reverse it, most people will do the following manual steps.

• Write “Zebra” down.
• Start a new word, and put “a” as the first letter.  (Why –> because it is the last letter, we want to start here)
• Put “r” down as the 2nd letter.  (Why –> because it is the next letter backwards from the last letter we copied)
• Put “b” down as the 3rd letter.  (Why –> same as above)
• Etc

Notice how I write down each little step and why.

Optimize the manual solution

People often don’t realize how valuable this step is.  It is much easier to rearrange and reconstruct and idea or algorithm in your head than it is in code.

It’s well worth the effort to try and optimize the actual solution or simplify it when it is still in the most easily malleable state.

What you want to do here is figure out if there is another way you can solve the problem easier, or if there are some steps you can cut our or simplify.

Let’s look at our string reversal example and see if we can simplify the steps.

We should be able to immediately recognize that we can use a loop here to reduce the manual steps.  Our duplicate why’s for most of our steps tell us that we are doing the same thing over and over for each step, just with different data.

1. Write “Zebra” down.
2. Start at the last letter in the word and create a new empty word.
3. Append the current letter to the new word
4. If there is a previous letter, make the previous letter the current letter and start back at 3.

Look how close we are getting to code at this point.  You should be tempted to actually write the code for this.  That is good, it tells you that you have solved and simplified the problem well.  Writing code should now become very easy.

Write pseudo-code or comments

Many times you can skip this step if you have a really good handle on the problem or your previous steps already created a detailed enough description of the solution that coding it is already a 1 to 1 translation.

If you are a beginner or struggle with these kinds of problems, I would go ahead and take the time to do this step anyway though.

What we want to do here is capture all the steps we created and now either put them into our editor as comments or write them as psuedo-code that we can translate to real code.

By doing this, we can know exactly what the structure of the code we are going to write is going to look like which makes the job of filling in the actual code later trivial.

Let’s look at some psudeo-code for reversing a string.

// NewWord = “”

// Loop backwards through word to reverse

//   NewWord += CurrentLetter

// Return NewWord

Pretty simple, but the key thing we have done here is outlined the structure of the code we will write to solve the problem.

Replace comments with real code

This step should be extremely easy at this point.  If you have done all the other steps, this step involves no problem solving at all.

All we do here is take each comment and convert it into a real line of code.

Taking the string reversal, we might end up with something like this.

String newWord =””
for(int index = oldWord.Length – 1; index >= 0; index—)
   newWord += oldWord[index];
return newWord;

1 for 1 translation of the comments we created above for real code.

If you struggle here, there are usually two possible reasons:

1. You didn’t break down the problem into small enough steps
2. You don’t know your programming language well enough to do the conversion

If you didn’t break the problem down enough, try going back to the second step and being as meticulous as possible.  Write out each and every single step.  I know it is a pain, but do it, believe me it will be worth the effort.

If you don’t know your programming language well enough to do the translation, you may need to brush up here on some basic constructs.  Any language you expect to be able to solve algorithm type problems in, you should know how to do the following things:

• Create a list
• Sort a list or array
• Create a map or dictionary
• Loop through a list, or dictionary
• Parse strings
• Convert from string to int, int to string, etc

If you don’t know how to do all of these things.  Stop what you are doing now and learn them. It’s not a very long list, and the benefits will be profound.

Optimize the real code

Sometimes this step isn’t necessary, but it’s worth taking a look at your code and figuring out if you can cut out a few lines or do something simpler.

This is also a good place to make sure all your variables are named with long meaningful names.  I cannot stress enough how important having good names for your variables and methods is for helping the person evaluating your code to understand what you were trying to do.  This is especially important when you make a mistake!

I won’t give an optimization for our trivial example of a string reversal, but a word of advice here is not to get too tricky.  Just try to mainly simplify your code and get rid of duplication.

A few final tips

If you follow this template for solving algorithm type problem, you should do very well in programming interviews, but the key to doing so is having confidence in this process.

The only way you are going to have confidence in this process is to practice it.  It takes a good amount of faith to believe that spending 70% of your 30 minutes to solve a problem just thinking about the problem and not writing any code is the right approach, so make sure you have that faith when you need it.

I’ve talked about using TopCoder to become a better programmer before, and I still recommend it.  Codility.com is another great site I have recently been introduced to.

There is one important step I did not include in the outline above, because I didn’t want to make the process any more complicated than it needed to be.

Many times you will find that a problem itself involves multiple large steps or is very complicated.  In those instances, you will want to try and find a way to cut the problem directly in half and then following the process above for each half.

This method of tackling a problem is called “divide and conquer" and is quite effective.  A good way to know where to break a problem in half is to think about what part of the problem if already given to you would make solving the rest easy.

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.

One of the most common misunderstandings and frustrations I see from developers is around sorting.

Almost every developer has faced needing to sort a list of things in some manner in their development careers.  Many developers end up fumbling through it, looking for an example from the web and then copying that example, not really knowing what they did or why it works.

If you fall into that category, or just want to know a little better how sort works, stay tuned, we are going to make it simple.

Sorting algorithms?

Nope.

Great for computer science.  You should have a basic idea of how they work, but unless you are writing some low level bit twiddling code on an integrated circuit, you don’t need to know about them.

Let’s think of sorting algorithms as a black box.  You don’t need to know what the algorithm is or how it works, you just need to know that if you give the two things it requires it will sort your list for you.

What two things do all sorting algorithms, regardless of implementation need?

1. A list of things to sort
2. A method to call to tell if object A comes before or after object B, or whether they are the same.

That is all you need to know and give to a sorting algorithm implementation and it will do the rest.

Every modern programming language has at least one sorting algorithm and every single one of them has the exact two same inputs I mentioned above, a list to sort, and a comparison method.

It doesn’t matter if you are using C#, Java, Ruby or some other language, they all implement a sorting algorithm and need those two things.  And that is all they need from you.

The burden is off your shoulders.

Step 1: Find the sorting method

I’m going to do better than teach you how to sort in each language.  I’m going to show you how to figure out how to sort in a language.

The first step in doing that regardless of the language, is to find the method that sorts things.

A good place to look is the list or collection object itself, since that is the most obvious place to put a sort routine.

When we look up List in C#, sure enough we find Sort on there.

Oh noes!  So confusing!  It has 3 sort methods!  Which one do I call?  Agh!

Don’t panic.  Remember what I said above.  Even though you see three signatures for the sort method, sort methods still only need two things.

Sort(), Sort(Comparison<T>), and Sort(IComparer<T>) still need just a list and a method to compare two of your objects.

We’ll dive into that more in a bit, now let’s look at Java.

If we look up ArrayList in Java, we don’t find a sort method.  Boo.  What were they thinking.  It’s ok though, googling for “Java sort” turns up Arrays.sort and Collections.sort.

Let’s look at Collections.sort.

This time we see two sort methods, sort(List list), and sort(List list, Comparator c).

Again, nothing to be afraid of since we know the two things all sorting algorithms require from us.

Step 2: Find the two things

So if every sorting method needs the same two things from you, then all you need to do is figure out how to give it those two things.

In the C# and Java instances above, the first thing (the list of things to sort) is fairly obvious.  In C# we saw that the sort method was on the list class itself, so we don’t even need to pass it the list of things to sort, it still needs it, but it knows where to find it.

In the Java instance the first parameter to both sort methods is a list.

See how easy we just made things?  We are already 50% there.

So really the only question left is how to provide the method that compares two of our objects.

When we know what we are looking for, it is much easier to find and understand.

Let’s break down each instance and figure this out.

If we look at C#’s Sort() method, without reading the documentation, we can probably guess two things.

1. The list to sort is the list we are calling the sort method on.
2. The objects in the list provide the comparing method.

The first is obvious.  The second one is a little less obvious, but if you think about it, since the method takes no parameters the only possible thing that could be providing the method for comparison is the objects in the list.

If we look at the documentation for Sort(), we find that is true.  The objects in the list have to implement IComparable.  IComparable has one method, CompareTo, which takes one object and compares it to the other.  If you implement this interface on your object, you can sort a list of them.  Simple.

For Sort(Comparison<T>), we can easily deduce that what is passed in there must be the method to compare two objects, and sure enough it is.  If we want to use this method we just pass in a method of type Comparison<T> where T is the type of object we want to compare.

We can see that Comparison<T> is just a method that takes two of your objects and returns an int to indicate which is greater or if they are equal (1 = greater, 0 = equal, –1 less).

The final C# Sort(IComparer<T>) just takes an object that implements IComparer<T>.  Sure enough, IComparer<T> has one method that must be implemented, Compare.  That method has the same signature as Comparison<T> from above.

Now, let’s look at Java.  You’re going to find it is pretty much the same thing.

For sort(List list), we can easily see that the list to sort is passed in as a parameter, but once again we have to find where we supply the method to compare two of our objects.

Since it can’t be passed in, it must be… say it with me… on the object.  That is right!

Turns out we just have to have our objects implement Comparable and then they can be sorted.  When we look at the Comparable interface, we see that it just has one method, CompareTo(Object o) and that method just takes another object to compare our object to and returns 1 if ours is greater, 0 if it is the same, or –1 if ours is smaller.

Now let’s look at sort(List list, Comparator c).  In this case, we can see that the method to compare our two objects is passed in, but since we can’t pass methods in Java, Comparator is just an interface that we can implement that provides the comparison method.

If we look at the Comparator interface, we see it has one method we need to implement compare(Object o1, Object o2).  I’m sure you can guess what that method should return by now.

So regardless of the language, when you are looking at how to use a sorting algorithm, find the two things that it needs.  The list is usually obvious, but the method to compare is almost always implemented in one of three ways.

1. An interface the objects being compared implement.
2. A method that is passed in.
3. An object that is passed in that implements a comparison interface.

Step 3: Implement the method

After you have figured out how to pass your list and your comparison method to the sorting algorithm, you need to actually write the comparison method.

If you learn to write a comparison method you can use it for any sorting algorithm, since all comparison methods do the exact same thing.

Fortunately, this is easy as well, because comparison methods always do the exact same thing.  They take two objects and return whether the first one is larger, smaller, or equal to the second.  That is it.

Don’t worry about sorting.  Remember what I told you about the sorting algorithm black box?  Let that sorting algorithm worry about sorting, all you have to do is decide whether 1 given item comes before a 2nd given item or if they are they same, nothing more.

Can you do that?

Sort people on age? 

If person1.Age > person2.Age return 1

Else if person1.Age < person2.Age return –1

Else return 0

Psuedo-code, but pretty simple.

Wrapping it up

If you can figure out what method you can use to sort in your language, find how to pass in the list of things to sort and provide the comparison method, and implement the comparison method, then you can sort!

Just remember to not get overwhelmed and think logically about the two things that all sorting methods need from you, and you’ll see how simple the whole sorting thing really is. 

You can be the guy that everyone asks about sorting instead of the guy copying and pasting some sorting code from the internet that you aren’t really sure how it works.

By the way, in C#, I would recommend just using the LINQ extension method OrderBy.

Very nice to do something like:

people.OrderBy(p => p.Age).OrderBy(p => p.Name);

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.

We have all heard that our code should be designed in such a way to increase cohesion and be loosely coupled. Is this correct? Is it even possible to achieve both?

Let’s look a little at what cohesion and coupling are in order to better understand their relationship to our code.

What is cohesion?

Cohesion is simply quality of a thing being stuck together well.

We would say that something is highly cohesive if it has a clear boundary and all of it is contained in one place.

For example, a baseball is very cohesive.  Everything that makes up a baseball is in one little round orb.

The internet is not cohesive.  It is hard to define and it is scattered all over the place.

When looking at software, we consider a class or module to be highly cohesive if it has a clear responsibility and all of the implementation of that responsibility is close together or in one place.

A good example in software would be putting all of our logic to write to a database in one class or several classes in a module, instead of letting every part of our application that needs to write to the database implement that logic in its own class.

We consider cohesion to be a good thing because it makes software easier to understand, reduces the effects a change on one part of the system has on the rest of the system, and it allows us to reuse code within our application.

What is decoupling?

Decoupling is the quality of a thing not relying on other things.

We would say that something is decoupled if it does not depend on anything but itself.  Something would be highly coupled if it had many different dependencies.

Consider an iPod.  It is highly decoupled.  It is a very self-contained piece of hardware.  It has its own battery and can be transported around without depending on anything else for it to do its job.

Now consider the motherboard in your computer.  It is not decoupled.  It contains specific slots for RAM, for a CPU, for video cards, etc.  If those components change in their shape or kind, they may not work with the motherboard.

Looking at software we can consider a module or class to be decoupled if it does not have many dependencies on other classes or modules.

Consider implementing a class for a linked list data structure.  Chances are that class will be pretty decoupled, because it really shouldn’t depend on anything else.  (Unless you of course change the granularity of what you consider a thing to be, more on that later.)

We like loosely coupled software because it reduces the impact across other modules of a change in one module.  Loosely coupled software is also easier to reuse, because it doesn’t have many other dependencies to be included.

Sounds like they are trying to achieve very similar goals

And they are.  For the most part high cohesion and loose coupling go together.

If your classes have clearly defined responsibilities with the implementation of those responsibilities located in that class, chances are it we be fairly decoupled from the rest of the system.

In the very general sense, as you decrease coupling, you increase cohesion and vice versa.

The benefits are very much the same also.

But now I’m going to get into some muddy water here and question what we mean by a “thing” or a “module.”

In my next post, I am going to delve much deeper into this topic and look at how granularity affects cohesion and coupling as well as talk about how they can actually be inversely related.

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 shame that many developers shy away from them, because they don’t really understand them.

Adding Action<> and Func<> to your toolbox is a very important step in improving your C# code.

It’s not really that hard to understand what they do and how to use them, it just takes a little patience…

A simple way of thinking about Action<>

Most of us are pretty familiar with finding sections of repeated code, pulling that code out into a method and making that method take parameters to represent the differences.

Here is a small example, which should look pretty familiar:

public void SteamGreenBeans()
{
    var greenBeans = new GreenBeans();
    Clean(greenBeans);
    Steam(greenBeans, Minutes.Is(10));
    Serve(greenBeans);
}

public void SteamCorn()
{
    var corn = new Corn();
    Clean(corn);
    Steam(corn, Minutes.Is(15));
    Serve(corn);
}

public void SteamSpinach()
{
    var spinach = new Spinach();
    Clean(spinach);
    SteamVegetable(spinach, Minutes.Is(8));
    Serve(spinach);
}

Each one of these methods pretty much does the same thing.  The only difference here is the type of vegetable and the time to steam it.

It is a simple and common refactor to refactor that code to:

public void SteamGreenBeans()
{
   SteamVegetable(new GreenBeans(), 10);
}

public void SteamCorn()
{
    SteamVegetable(new Corn(), 15);
}

public void SteamSpinach()
{
    SteamVegetable(new Spinach(), 8);
}

public void SteamVegetable(Vegetable vegetable, int timeInMinutes)
{
    Clean(vegetable);
    Steam(vegetable, Minutes.Is(timeInMinutes));
    Serve(vegetable);
}

Much better, now we aren’t repeating the “actions” in 3 different methods.

Now let’s imagine we want to do something more than steam.  We need to be able to fry or bake the vegetables.  How can we do that?

Probably we will have to add some new methods for doing that.  So we will end up with something like this:

public void SteamVegetable(Vegetable vegetable, int timeInMinutes)
{
    Clean(vegetable);
    Steam(vegetable, Minutes.Is(timeInMinutes));
    Serve(vegetable);
}

public void FryVegetable(Vegetable vegetable, int timeInMinutes)
{
    Clean(vegetable);
    Fry(vegetable, Minutes.Is(timeInMinutes));
    Serve(vegetable);
}

public void BakeVegetable(Vegetable vegetable, int timeInMinutes)
{
   Clean(vegetable);
   Bake(vegetable, Minutes.Is(timeInMinutes));
   Serve(vegetable);
}

Hmm, lots of duplication again.  No problem.  Lets just do what we did to the first set of methods and make a CookVegetable method.  Since we always clean, then cook, then serve, we should be able to just pass in the method of cooking we will use.

Oh wait, how do we do that?  We can’t just extract out Bake or Fry or Steam, because the Bake, Fry and Steam methods are logic and not data.

Unless… unless we can make them data.  Can we do that?

We sure can, check this out:

public void SteamVegetable(Vegetable vegetable, int timeInMinutes)
{
    CookVegetable(vegetable, Steam, timeInMinutes);
}

public void FryVegetable(Vegetable vegetable, int timeInMinutes)
{
    CookVegetable(vegetable, Fry, timeInMinutes);
}

public void BakeVegetable(Vegetable vegetable, int timeInMinutes)
{
    CookVegetable(vegetable, Bake, timeInMinutes);
}

public void CookVegetable(Vegetable vegetable,
   Action<Vegetable, CookingTime> cookingAction,
   int timeInMinutes)
{
    Clean(vegetable);
    cookingAction(vegetable, Minutes.Is(timeInMinutes));
    Serve(vegetable);
}

We got rid of the duplicated code the same way we did when we did our first refactor, except this time we parameterized method calls instead of data.

If you understood this, you understand Action<>.  Action<> is just a way of treating methods like they are data. Now you can extract all of the common logic into a method and pass in data that changes as well as actions that change.

Congratulations, you are doing the strategy pattern without having to create an abstract base class and a huge inheritance tree!

So when you see Action<>, just think “ah, that means I am passing a method as data.”

It really is as simple as that.

Action<Vegetable, CookingTime> translated to English is: “A method that takes a Vegetable and a CookingTime as parameters and returns void.”

What about Func<>?

If you understand Action<>, you understand Func<>.

Func<X, Y, Z> translated to English is: “A method that takes an X, and a Y as parameters and returns a Z”.”

The only difference between Action<> and Func<> is that Func<>’s last template parameter is the return type.  Func<>s have non-void return values.

Bonus: Predicate<> is a Func<> that always returns a boolean.

That’s all there is to it.  There really isn’t a need to know much more than that to make sure of Action<> and Func<> in order to start using them.

If you are interested in some other ways to apply Action<> and Func<>, here are some posts I have written which focus on them.

• Pulling out the Switch: It’s Time for a Whooping
• Parsing Columns Like a Ninja
• The Power of Func<>
• Super Combo: Map + Function Pointer

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.

The book goes through creating an Android application using Eclipse. It contains many source code examples that are very complete. The book really seems to be focused more on getting going vs going in-depth with the APIs.

The good:

• Great jump start diving right into Android development without wasting much time.
• Very complete examples that can get you going and can be modified for your own application.
• Balances basic examples with more complex architectural constructs well. There is a good mix of examples that build on basic concepts and show how to implement more of an MVP style of development.
• Covers a pretty wide breadth of the Android platform, which makes it easy to know what exactly is capable.

The bad:

• Although the beginning of the book was very interesting and informative, some of the chapters seemed to drag on.
• A whole huge chapter devoted to search.  Search is not something that most applications would need to make use of.
• A whole huge chapter on 3d application development.  Not something I felt should have been in the book.  Pretty boring and actually really scary.  I don’t think I’ll ever develop a 3d application for Android.

What I learned:

I had already started building my Android application before reading this book, so not very much of it was completely new to me, but I definitely learned some things from the book.

I was really surprised to see how easy 2D animation is with Android.  The book does a good job of explaining it and providing examples.  I feel like I could very easily implement 2D animation after reading this book.

I learned about  to create and use content providers.  This aspect of Android development is a bit tricky, but I felt like Pro Android 2 did a good job of explaining it and providing examples that I would be able to use.

I also learned to create a home screen widget.  The examples in the book were really good and provided a complete usable implementation that could be easily used as a base for creating your own.

Towards the end of the book, Titanium Mobile is mentioned.  Titanium Mobile is a WebKit-based native application development framework which allows developers to write applications that target multiple platforms.  It looks really cool, and I kind of wish that was the first chapter in the book, so that I could have explored that before getting so far into actual Android development.

Overall, I would definitely recommend the book.  I feel pretty confident that someone with no Android experience should be able to pick up that book and get going with their first application.  I definitely learned some things the hard way, before I read the book.

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.

Today I am going to show you how to refactor the switch statements to alleviate that problem.

There are some varied opinions on refactoring switch statements which I believe derive from trying to treat all switch statements as the same.  I want to look at the kinds of switch statements that exist and why I recommend to refactor each one in a particular way.

Data to data

The first most obvious kind of switch statement is one that maps one form of data to another form of data.

switch (state)
{
    case "Florida": return "Tallahassee";
    case "Idaho": return "Boise";
    case "Arizona": return "Phoenix";
    case "South Carolina": return "Columbia";
}

This example is clearly mapping one piece of data to another.  The best refactor for this situation is to use a map.  In C# it is a dictionary, in Java a map.

var stateToCapitolMap = new Dictionary<string, string>()
{
    {"Florida", "Tallahassee"},
    {"Idaho", "Boise"},
    {"Arizona", "Phoenix"},
    {"South Carolina", "Columbia"}
};

return stateToCapitolMap[state];

I cannot believe how many people argue against this refactoring.  It doesn’t look like much, but we have greatly separated logic from data and increased the maintainability of the code.

Before our refactoring, consider, how you would be able to read all the states and capitols from a file and insert them into the switch statement?  The only possible way would be through code generation.  Clearly this indicates a coupling of code and data.  The switch statement is formatted in such a way that it almost looks like data, but don’t let that fool you, it is code.

Consider the refactored example.  If we want to read the values from a file, it is simple.  So simple, that I’ll even show the code right here.

var stateToCapitolMap = new Dictionary<string, string>();
foreach (string line in File.ReadAllLines("StatesAndCapitols.txt"))
{
    string[] stateCapitol = line.Split(',');
    stateToCapitolMap.Add(stateCapitol[0], stateCapitol[1]);
}
return stateToCapitolMap[state];

Data to action

This kind of switch statement appears different than data to data, but it is actually very similar.  In this case we are mapping some data to a direct action that should be performed given that data.

Often this form of logic can be disguised by multiple actions happening in a case statement.

switch (move)
{
    case "Up": MoveUp();
        break;
    case "Down": MoveDown();
        break;
    case "Left": MoveLeft();
        break;
    case "Right": MoveRight();
        break;
    case "Combo":
        MoveUp();
        MoveUp();
        MoveDown();
        MoveDown();
        break;
}

We can take the same approach here because really this is a form of mapping data to data.  The second data item is essentially the name of a method to call to perform an action.  We can illustrate this intent easily in C#.  (In Java, you will need to wrap the action into a set of classes with a common interface.)

var moveMap = new Dictionary<string, Action>()
{
    {"Up", MoveUp},
    {"Down", MoveDown},
    {"Left", MoveLeft},
    {"Right", MoveRight},
    {"Combo", () => { MoveUp(); MoveUp(); MoveDown(); MoveDown(); }}
};

moveMap[move]();

What we are essentially doing now is a dynamic look-up of the method to call based on the data.  We could even make this example data driven from a text file that specified how to map a move to a method name or list of method names, but that is far beyond on the scope of this post, and I don’t think I would recommend it unless you have a really good reason.

Data to multiple actions

If you are familiar with the techniques of refactoring switch statements, you make be shaking your head by now saying “that guy is wrong, he needs to use a factory.”  Okay, well now we are going to do it.

In the data-to-action refactoring, I opted for the simplest solution that can work, instead of trying to over solve the problem by adding complexity in the form of a factory.

But, what happens when you have multiple switch statements in your code that operate on the same set of data?

switch (move)
{
    case "Up": MoveUp();
        break;
    case "Down": MoveDown();
        break;
    case "Left": MoveLeft();
        break;
    case "Right": MoveRight();
        break;
    case "Combo":
        MoveUp();
        MoveUp();
        MoveDown();
        MoveDown();
        break;
}

// ... somewhere else

switch (move)
{
    case "Up":
        moveName = "Basic Up Move";
        break;
    case "Down":
        moveName = "Basic Down Move";
        break;
    case "Left":
        moveName = "Basic Left Move";
        break;
    case "Right":
        moveName = "Basic Right Move";
        break;
    case "Combo":
        moveName = "Up Up Down Down Combo Move";
        break;
}

Sure, we could refactor these both into maps or dictionaries.  But what will happen when we try and add a new move?  We’ll have to remember to add logic in both places or we’ll have a problem.  In the prior example we recognized that data was being mapped to an action, so we represented that as succinctly in code as possible.

In this example, the same data is being mapped to some data that describes a move and actions to perform.  We need some way to house these attributes that belong to the data we are switching on together, and we would like to have this all in one place, so we don’t have to change the code in multiple places.

Our best solution here is to use a factory that gives us the right kind of object that implements the behavior that should be tied to the data we are currently switching on.

public interface IMove
{
    void DoMove();
    string GetFriendlyName();
}

public class UpMove : IMove
{
    public void DoMove()
    {
        // Do the move
    }

    public string GetFriendlyName()
    {
        return "Basic Up Move";
    }
}

public static class MoveFactory
{
    private static Dictionary<string, Func<IMove>> moveMap = new Dictionary<string, Func<IMove>>()
    {
        {"Up", () => { return new UpMove(); }},
        {"Down", () => { return new DownMove(); }},
        {"Left", () => { return new LeftMove(); }}
        // ...
    };

    public static IMove CreateMoveFromName(string name)
    {
        return moveMap[name]();
    }
}

You can see here that we are creating a factory which contains a dictionary which maps a move name to what kind of object to create.  Each move implements a common IMove interface.  (I only show some of the implementation here.)

Now in our code we can replace those switch statements with polymorphic behavior from our object returned from the factory.

IMove move = MoveFactory.CreateMoveFromName(name);
move.DoMove();
String friendlyName = move.GetFriendlyName();

The nice thing about this implementation is that if we try to add a new move the IMove interface will require us to implement all the proper methods.  We make a change in one place and the compiler reminds us what we need to do.

Don’t jump straight to the factory

You may have heard the argument between using a factory or a dictionary for refactoring switch statements before.  What I am trying to show in this blog post is that it depends on your situation.

The simplest solution is a dictionary or map.  Once you have a second place you are mapping the same data, you should move to a factory.  The factory then contains the mapping between a piece of data and a class.

I also wanted to note here that I didn’t use enumerations.  In real code you should.  I avoided them here to prevent adding one more layer of abstraction so that my example would not require as much explanation.

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 wish I could take a time machine back to the year 2000 and read it then.

So much of the information in the book seems to be concepts that many software developers understand and take for granted as general knowledge now, that wasn’t at the time of its writing.

The book is very much a collection of knowledge from years of practical experience writing code.  It is very specific in stating what kind of specific coding practices should be carried out and which ones should be avoided.

The content of the book lays somewhere between the low level software construction in a book like Code Complete and a book targeting a higher level methodology or project management.

Good:

• Years of experience packed into a small package.
• Most of the advice in this book is timeless.
• Practical real world truth instead of theoretical talk.
• Excellent focus on automation for everything you can automate.
• Technology independent advice.

Bad:

• There were definitely some dated pieces of advice that I wouldn’t recommend following today.
• If you are already familiar with many of the software craftsmanship or general agile principles, much of this book will echo what you already know.  (Can’t fault the authors for that since this book is probably the origin of much of that information getting out, yet if you haven’t read the book, you should know what to expect.)

What I learned:

I really liked the section of the book that talked about using “tracer bullets” in software development.  Basically the idea is that you can either prototype the software or build what you know and then adjust your aim to reach the user’s real requirements instead of trying to specify up front.

I think many times in development we get hung up on knowing all the details, but sometimes we need to fire “tracer bullets” first to see if we are hitting the target.

I also realized that I am guilty often of programming by coincidence.  Sometimes I will have put a magic incantation into the code and not really understood why it worked.  It is very important to understand why something works, not just make it work.

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.

Well, I was having my head rearranged by JQuery.  I have to admit, I am pretty late to the party.  I haven’t really been using JQuery at all the past few years.

I missed a lot.

Goodbye type safety

This part scares me a little bit.  I already made a few typos that were pretty hard to detect.

Debugging javascript is not much fun considering that data and methods are both first class citizens.

But, the trade-off just might be worth it.

What we are losing in type safety, we are making up for in productivity and speed.  It is really fast to manipulate a page using JQuery and to hook up events.

I still wish there was some way to have some sort of type safety when using JQuery or Javascript in general, but it really hurts my brain to try and think about how that would be possible.

Perhaps some kind of Script# / JQuery bastard child?

I know some people are doing Javascript unit testing.  That would certainly make me feel safer not having type safety.

Functional thinking

I like the functional thinking paradigm.  One of my co-workers was saying that he likes JQuery because it helps him to write Lamba expressions and LINQ queries.  I tend to agree with him.

I’ve said it before, but I believe the next high abstraction of programming is thinking functionally.

So many pieces of code that I would have used code generation to produce in the past, I can now produce with Lambda expressions.

It’s not all roses

I do have some major issues with JQuery and Javascript in general.  One of the big problems is that JQuery is not a language, and it’s not a library.  It is a DSL built on top of a language.

Bleeding all the way through the stack

The downfall of this is that it is a very leaky abstraction.  Abstractions are good because they allow us to think at a higher level.

Leaky abstractions are bad because they force us to context switch from a higher level of thinking down to a lower level.

In order to understand JQuery you must understand Javascript, the DOM and CSS to some extent.

Think for a second about all the “languages” or technologies you have to know to develop an ASP.NET web page using JQuery and MVC.

• ASP.NET MVC
• HTML
• C# or Visual Basic
• JSON
• Javascript
• JQuery
• CSS
• Web Services / Rest
• HTTP (You need to be able to debug all the coolness you are flinging back and forth.)

When you have it all working, it is pretty slick.  Very slick indeed, but it is not a sustainable model.  It is complex and sprinkled with errors and gotchas.

Debugging / readability

When I am writing JQuery, although I feel like it is magical and cool, I also feel a little bit dirty.

Why?

Well, as clean as you try to write JQuery code, it can be pretty nasty.  There is a lot of magic going on, and it is not very easily understandable.

Perhaps I’ll get better at expressing my intent clearly in JQuery code, but I am pretty sure it has to due in part with the leakiness of the abstraction layer, and that can’t really be cleaned up easily.

Debugging is also hell.  I tried debugging through the validation library to see why my error messages weren’t showing up, and it was no picnic.

Javascript itself is notoriously difficult to debug, because objects can have methods dynamically added to them, and all the other little tricks, make it hard to look at a watch window and get anything useful out of an object.

View logic

One of the things I really enjoyed while writing JQuery code was putting the view logic where it really belongs.  It is nice to have a language and a server separating the view logic from the model and presentation.

JQuery really allows you to put all the code that manipulates the view in one place, and on the client side, where it really belongs.

JQuery will make your HTML code so much cleaner and helps to actually plug the leaks in the HTML abstraction layer.  (Although it isn’t perfect, especially when working with ASP.NET Web Forms.)

Better late then never at all

So I know I’m really late to the JQuery party, but I’m here now, and I am liking it.

Overall, I’d recommend taking a look at JQuery if you are like me and hadn’t really used it until now.  It definitely is a valuable skill to develop and is growing at an extremely rapid pace.

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.