Searching stuff

If you have a problem (not only programming-related, but also any other technical field) always start your search at the most trustworthy sources and go down from there.

First try: Search in a programming book

I always keep in my quick access lists a few programming books that I use over and over for references when writing some code for something I haven't tried before, or when trying something I haven't done in a while. This should be the first place to search in, as this is in my opinion the most reliable source of information.
As a side-note, the book I find myself most often browsing is Pro ASP.NET 3.5 in C# 2008, 2nd edition. But keep in mind that (almost) any book can do just fine, read it once to get an idea of its contents and browse it over and over again each time you're trying out something that you've read about in the book, this is in my opinion the best way in which you can improve your code.

Not there? Try an online knowledge base

If you can't find what you're looking for in a book (or don't have a book on that particular field available), try some online knowledge bases. For example, if you're a .NET programmer, you trust MSDN, as long as you make sure that the topic you're browsing is up to date (check the posted date, the target framework and so on).

Still didn't find it? Just Google it!

Or show some love and use Bing! to google it. I haven't tried it in the past months though.
OK, to be honest, this is in many cases my first try, but only for trivial subjects or error messages. In many cases it will send you to a guru's blog (see http://weblogs.asp.net/scottgu/ ) or an online knowledge base, but other times it might send you to a forum.
While I do support forums (i'm an active member in several, including the asp.net forums, The CodeProject, and, my personal favourite, StackOverflow), the wiki-like behaviour of forums decreases their credibility (anyone can answer anything, and there's no higher authority to validate an answer, the community usually deals with rating answers).

Not there yet? Time to develop your own language

If the problem you're seeking did not have an answer in any of these locations, you're either trying a technology too new to have a considerable footprint in books and online sources, or you're trying something that no-one has ever thought to try out before. In both cases, either find an alternative or get in touch with the team behind the technology you're using.
I love this site.

But the most important thing is to search. I've noticed that there are too many developers that rely too much on their own knowledge, and the closest that they get to any documentation is when intellisense kicks in. I've heard there was a time when knowing all ~200 methods of a language was what made you a good developer (I once read a post that stated that someone found about ~13000 classes in .NET 1.1 by using reflection). But that was when dial-up was cutting-edge and horses wore pants. And that's not the case today.

Compare binary data in Linq 2 SQL

I just ran into an interesting problem using Linq 2 SQL. I wanted to compare binary data directly on the server, that means that i wanted a linq query that would translate to sql and perform comparison over a binary column. This isn't as easy as you would expect when using Linq 2 SQL. What i usually ended up with was a mess, either writing my own sql code or just grabbing the entire table in memory and using the SequenceEquals extension method on the binary data.
Now i've found there's a much better way. Although this looks a lot like a hack, the result is so amazing that i encourage it to be used as a standard.
Apparently this guy just dug deep into the linq 2 sql code, and what he ended up with was this:

private static bool IsCompareMethod(SqlMethodCall call)
{
    return (((call.Method.IsStatic && 
             (call.Method.Name == "Compare"))&&
             (call.Arguments.Count > 1)) && 
             (call.Method.ReturnType == typeof(int)));
}

So basically if we provide a static method named 'Compare' which has two parameters and returns an int, then it is a comparison method. This means it will be transformed into a comparison expression inside SQL. Using this information, he suggests just creating an extension method to the Binary (in my case, byte[] data, but it's basically the same thing) method, with the proper signature.

public static class ComparatorBinar
{
    public static int Compare(this byte[] b1, byte[] b2)
    {
        throw new NotImplementedException();
    }
}

We don't need to throw an exception here, but it's just to suggest that this method isn't actually going to be called from inside .net, but it will be mapped to a comparison method in SQL.
We can now use this in any linq query to compare binary data:

var data = GetSomeBinaryData();
var elem = (from e in dataContext.Elements
            where 
            e.BinaryData.Compare(data) == 0
            select e).FirstOrDefault();

Voila! This of course will be translated into T-SQL, which knows by default to compare binary data.
I'm not sure why there isn't a default implementation for comparing binary data btw.
Original source: Linq 2 SQL, Expression Trees and Binary Comparing

Tame that recursive code

If college has taught me anything by now, it's certainly not writing practical real world - ready code.
As an example, let's take the widely accepted academic presentation on recursion.
The first thing that comes to mind to most students or fresh graduates when they think of recursive code is the classic 'Recursive Factorial'. It's supposed to provide them with an easy introduction to the capabilities of using recursion in your code.
So what you end up with is something like this:

public int RecursiveFactorial(int value)
{
    if(value != 0)
    {
        return value * RecursiveFactorial(value - 1);
    }
    else
    {
        return 1;
    }
}

Now that's all fine if you have no practical common sense at all. A much better piece of code would be:

int finalValue = 1;
for(int i = 2; i <= value; i++)
{
    finalValue *= i;
}

I'm sure everyone can agree that this is a much better way of doing things. Some might say that the purpose of the RecursiveFactorial method is not a best practices guide, but to gently show would-be developers what a recursive method can do. But that's just like teaching 7'year olds how to read using Lorem Ipsum quotes. To conclude, i'm definitely not saying that you should ditch recursion altogether, it's a great tool when used wisely. But always keep in mind that, if you have more than one option, the non-recursive one is almost always the quickest.

Good reason to use Factory Methods

As much as i enjoy learning and understanding design patterns, i find it pretty hard to apply them in practical situations and get an improved piece of code from most perspectives, that is readability, testability, maintainability and other 'bilities. What i want to show here is the perfect opportunity for me to implement the Factory Method pattern.
This is the scenario: I had a table in a database where each record represented a specific process that could be performed by an application. I've decided to take the OOP way and create a base Process class and derive all processes from it. Then the processes needed to be instantiated based on records in the database, so i had to connect strongly-typed classes to strings in a SQL table. This is where the factory method came in.
Instead of checking the record name for each record and decide what class type to create, i just created a static method in the base Process class called CreateProcess as such:

public abstract class Process 
{
   //some code here
   public static Process 
CreateProcess(string ProcessName)
      {
         switch(ProcessName)
         {
            case "DoSomethingProcess":
               return new DoSomethingProcess();
            //check all known cases
            default:
               throw new NotImplementedException(
                 string.Format("The process {0}" + 
" does not have a mapped implementation.");
         }
      }
}

The post that is first

Just watched Scott Hanselman's presentation about why i should have a blog. Let's see how far this goes.