Amazon S3, JungleDisk, and Me

I have been meaning to buy an external hard-drive to backup a lot of my data. Well, today I decided to try out Amazon S3 as my storage medium instead of an external hard-drive.

JungleDisk has proven a great program to transfer files to S3. In addition to working on Windows, Linux, and Mac, it allow the mounting of S3 buckets as hard-drives. Very good program to work with. Right now, I am backing up my Linux desktop and my Windows laptop.

Whether or not I stick with it, I don’t know. Right now, I have around 40GB of data to backup, which is $6 a month on S3 and $4 for initial upload. I am guessing, I will probably have to spend close to $10 a month for this service. Considering 500GB external hard-drives run about $100 right now, it doesn’t seem extremely cost effective. Then again, I am also paying for data redundancy and recoverability, right? Something tells me, this service will get me to organize my files better and delete files I don’t care about. Either way, I can afford to try it out for a few months, which is something you can’t really say about a hard-drive.

Lastly, here is a good guide on using rsync with S3.

NUnit and RowTest

I have been researching different unit testing tools for .NET lately. Obviously, NUnit was the first I came across, but MbUnit had the RowTest attribute, which allows parameters to be added to tests. This saves a lot of code and is really a must have feature. Luckily, I found an NUnit addin for RowTest here. The latest version here is linked to NUnit 2.4.6, so I rebuilt it from source to use NUnit 2.4.7.

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);
          }
}

C# Destructors and IDisposable

This week I found myself somewhat confused on when to use destructor. Originally I assumed that anytime you implement IDisposable you should have a destructor that calls Dispose().

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.

How to actually use trigonometry in web applications

Disclaimer: my teammate Dellanoce actually coded this, but is too cool to blog, so I am blogging for him.

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.

CallContext isn’t the greatest thing since sliced bread

In ASP.NET, it is quite common to need to store information in the context of a single web request. For example, a NHibernate session should usually exist for one web request. HttpContext is the tool for accomplishing this.

But what happens when you have code embedded in business logic that might not always be running in an ASP.NET web application? HttpContext isn’t valid, so you can’t use it. Why not use CallContext, since HttpContext uses this anyways?

I was starting to convert some of my code to use this, when I found this article. Apparently doing this works most of the time but can cause some nasty bugs since ASP.NET can switch HttpContext‘s without switching CallContext‘s.

Instead, code that could be called from ASP.NET and other applications should first check for context.

1
2
3
4
5
6
7
8
9
10
11
12
if(HttpContext.Current == null)
{
     //Using CallContext example since not in ASP.NET
     CallContext.SetData("blah", new object());
     object contextData = CallContext.GetData("blah");
}
else
{
     //Using HttpContext example since in ASP.NET
     HttpContext.Current.Items.Add("blah", new object());
     object contextData = HttpContext.Current.Items["blah"];
}

In fact, I will probably end up writing a static class to implement this so code doesn’t have to constantly check whether or not in an ASP.NET session.