At first, this may seem counter-intuitive. Isn’t this gong to cause more work in case you do need that function? No. Delete it. Don’t think twice. Here is why.

Unused code isn’t being tested. Used code is tested everyday, by your users if nothing else. The last thing you want is a developer to use code that might be completely wrong.

It reduces your code base. The less code you have, the less probability for problems exist. The less code you have, the easier it is to learn the code base.

Lastly, your developers should be learning everyday. If given a second chance, many developers would develop the same function completely differently a year apart. They would code a better function, that is more thoroughly tested and uses best practices.

So, don’t worry about it. Delete it.

When I first started coding in VB6 on Webmail.us’s corporate website, I never imagined the day I would help organize a conference for all their developers (PS – That is the corporate website when I started found via archive.org. You have to check it out). Then, communicating a new concept was as simple as turning around in your chair or waiting till everyone met up for dinner and drinks after work. With the growth of the company, communication isn’t as easy.

Our goal was to spread knowledge to everyone, and even more specifically the new people. One of the key topics today was on MySQL, a topic some of us can talk about for hours. Too often, we take that knowledge for granted. Not everyone has had as much experience with MySQL, especially hires right out of college. Getting everyone on the same page with certain topics was the goal today. Hopefully screen casts of the talks can help future hires ramp up faster as well.

But, there are always things we can improve upon. Here a list of 5 things that we can do better for next time:

• Plan the setup better. Make sure everyones files are on the presentation machine, and have breaks setup so there aren’t lulls between talks.
• Don’t rely on the internet. Holiday Inn’s free wifi isn’t geared towards 30 developers.
• Don’t eat mexican for lunch. It is delicious, but takes away from the second half of the conference if you know what I mean.
• Give every speaker enough time, and push them to fill it but not go over.
• Lastly, I would like to figure out how to go more in depth with some of the topics. Maybe have different tracks so people can choose? We might need 30 more developers before this is feasible though

Thanks to Lindsey, Matt, and Kevin for making it all happen.

public void Foo(IEnumerable<string> strings)
{
	IEnumberable<string> stringsInDb = strings.Where(s => this.QueryTheDbAndTakeALongTime(s));
 
	foreach(string str in stringsInDb)
	{
		//Where clause in LINQ is actually executed 
	}
 
	foreach(string str in stringsInDb)
	{
		//Where clause in LINQ is actually executed  AGAIN
	}
}

Luckily, some unit tests detected this behavior. It actually isn’t surprising when you think about it though. The proper thing to do for this case is actually call ToList() after the Where().

IEnumberable<string> stringsInDb = strings.Where(s => this.QueryTheDbAndTakeALongTime(s)).ToList();

Don’t let this behavior bite you.

Well, shouldn’t the same be true for documents, specifically those that describe some sort of process? For example, a document describing the steps to setup an IIS web server for a particular application is perfect to convert to an automated script. So, today, I started on a simple script to setup IIS compression using MSBuild.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
 
  <!-- Types -->
  <PropertyGroup>
    <adsutilPath>C:\inetpub\AdminScripts\adsutil.vbs</adsutilPath>
    <cscriptPath>cscript</cscriptPath>
    <StaticFilesToCompress>html htm js txt</StaticFilesToCompress>
    <DynamicFilesToCompress>aspx asp dll exe axd</DynamicFilesToCompress>
  </PropertyGroup>
 
  <Target Name="IisCompression">
 
    <Message Text="Turn on static and dynamic compression for all of IIS." Importance="high" />
    <!-- http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/502ef631-3695-4616-b268-cbe7cf1351ce.mspx?mfr=true -->
    <Exec Command="$(cscriptPath) $(adsutilPath) set w3svc/filters/compression/parameters/HcDoStaticCompression true" />
    <Exec Command="$(cscriptPath) $(adsutilPath) set w3svc/filters/compression/parameters/HcDoDynamicCompression true " />
 
    <Message Text="Select files to compress for static and dyanamic compression." Importance="high" />
    <!-- http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/d52ff289-94d3-4085-bc4e-24eb4f312e0e.mspx?mfr=true -->
    <Exec Command="$(cscriptPath) $(adsutilPath) set W3SVC/Filters/Compression/Deflate/HcFileExtensions $(StaticFilesToCompress)" />
    <Exec Command="$(cscriptPath) $(adsutilPath) set W3SVC/Filters/Compression/gzip/HcFileExtensions $(StaticFilesToCompress)" />
    <Exec Command="$(cscriptPath) $(adsutilPath) set W3SVC/Filters/Compression/Deflate/HcScriptFileExtensions $(DynamicFilesToCompress)" />
    <Exec Command="$(cscriptPath) $(adsutilPath) set W3SVC/Filters/Compression/gzip/HcScriptFileExtensions $(DynamicFilesToCompress)"/>
 
  </Target>
</Project>

Not only does this script automate the process, but it serves as a living document for the process. By doing this, the documented process is now coupled to the task itself.

The next step to coding processes is coding tasks that can’t be automated. For example, during a deployment, if some sort of fatal error occurs, the next task might be to call your boss and clean up your resume. Why not code a message in the deploy script to give you the list of people and phone numbers to call in case of an emergency, then load up your resume in Word? Again, the documented process is now coupled with the task itself.

Obviously, this article grows out of my dislike of documentation. I dislike it, not because it isn’t useful, but because it takes a lot of time and, in my personal experience, isn’t used very often. By integrating the documentation with the task itself, I think we gain more value from it.

Automation

Automate everything. Automation limits the ability for bugs to creep into a process and it also makes processes easier to follow. After reading this book, I was really motivated to automate everything and so far it has been a great decision. Some good examples of things that should be automated are:

• Tests
• Environment setup and teardown, especially databases
• Code inspection
• Deployment

Databases

Very often, databases are not part of a build process or version control. This allows differences between different environments to potentially cause bugs. Putting database schemas and test data in version control can help prevent this. But, what I like the most, is it documents the setup of the database so potentially any developer could setup a new one.

For example, when a new developer starts, I can show him the NAnt or MSBuild task to execute in order to generate a new developer DB. This is much easier than having to guide someone through MySQL, MSSQL, or any other database for the first time.

Transparency

Lastly, the biggest thing I learned from this book is how easily continuous integration can provide project transparency. In my experience, all to often the developers and the rest of an organization get out of touch regarding a project’s status. Continuous integration, combined with more agile development practices, allows a project to be completely transparent throughout an organization, from developers, to QA, to designers, and even senior leadership. No longer does a looming release date bring surprises for those outside the development team.

This…

int count = 0;
foreach (string email in this.emails)
{
    if (email.EndsWith("@mydomain.com")) count++;
}
return count;

becomes this…

return this.emails.Count(email => email.EndsWith("@mydomain.com"));

In some weird kind of way, I feel like an emo Ruby developer. Maybe I’ll start wearing some tighter clothes.

To install for TestDriven.NET, just create an addins folder in the %install root%\TestDriven.NET 2.0\NUnit\2.4\ and copy NUnitExtension.RowTest.AddIn.dll to the newly created folder. Then in your test project, just reference NUnitExtensino.RowTest and you are set to go.

Here is an example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

namespace TestExample
{
     [TestFixture]
     public class Tests
     {
          [RowTest]
          [Row(-4,4)]
          [Row(-5,5)]
          [Row(-6,6)]
          public void TestAddEqualsZero(int x, int y)
          {
               Assert.IsTrue((x + y) == 0);
          }
}

This is not the case though. The only time you really need a destructor is when a class directly contains unmanaged resources, like file handles.

A good example of when not to use a destructor is a wrapper class. For instance, if you have a database connection class wrapped with some sort of adapter class, the adapter class doesn’t need a destructor. It still needs to implement IDisposable to enable early disposal of resources, but the destructor of the underlying database connection class will handle any potential leak cases if Dispose() isn’t called.

Here is a quote from a very good article on C# traps:

The destructor should only release unmanaged resources that your object holds on to, and it should not reference other objects. If you have only managed references you do not need to (and should not) implement a destructor. You want this only for handling unmanaged resources. Because there is some cost to having a destructor, you ought to implement this only on methods that consume valuable, unmanaged resources.

The really powerful statement is “it should not reference other objects” which basically backs up my previous statement on wrapper classes.

Here is another good article on destructors and IDisposable.

Mailtrust has many different customers, some of which like to have their own branded control panel or webmail interface. We allow them to customize many different facets of the user interface, including colors. This has some unintended consequences though. Sometimes, a user might select a white font color on top of a white background. This in turns causes support to get involved in fixing the problem, which wastes time on such a trivial problem.

But there is a better way. Use trigonometry, or more specifically the Pythagorean theorem! I had no idea how this worked, but Dellanoce coded up a few lines of C# to compare two colors. It returns a distance value which can be compared to a threshold value you can set.

1
2
3
4
5
6
7
8
9
10
11

        private static double ColorDifference(string htmlColor1, string htmlColor2)
        {
            Color color1 = ColorTranslator.FromHtml(htmlColor1);
            Color color2 = ColorTranslator.FromHtml(htmlColor2);
 
            double rDiff = Convert.ToDouble(color1.R) - Convert.ToDouble(color2.R);
            double gDiff = Convert.ToDouble(color1.G) - Convert.ToDouble(color2.G);
            double bDiff = Convert.ToDouble(color1.B) - Convert.ToDouble(color2.B);
 
            return Math.Sqrt((rDiff * rDiff) + (gDiff * gDiff) + (bDiff * bDiff));
        }

I was quite impressed with the simplicity and elegance this solution provided. I should probably go give my, or his, trig teacher a hug.

If you want to learn more about how powerful Pythagorean theorem is to compare distance values of really any type of object, check this article out.