You know, there is a lot of grumbling in the blogsphere about webhost4life. I wanted to relay an experience that I had with them today; an experience which resulted in them keeping me as a client.

Late yesterday evening, I transferred a client’s website to webhost4life because they are now looking at using SharePoint Team Services for their collaboration needs. All emails were transferred over and the transition went very smoothly … until this morning. My clients started receiving emails mentioning that emails were not deliverable because they had reached their quota.

I did some reasarch into this and found that for some reason, webhost4life has a very low email quota (only 20mb). This particular client has a requirement that their email be available on multiple shared computers, so the only way to get around this is IMAP. Now, you can imagine how quickly 20mb gets chewed up if you store all of your email on the server.

To make a long story short, webhost4life was very sympathetic to my needs for this client and ultimately ended up moving me to another email server which allowed for a greater quota. Talk about fantastic customer service. Thanks to everyone who helped make this happen for me today.

The only thing that would have made this better would have been for webhost4life to prominently display the fact that their mail accounts have a quota (and that they are *not* tied to your disk space). I’m using blogomania.com for this blog, and your email accounts are only limited by the amount of disk space that you have.

Are you looking for a good ASP.NET or Sharepoint host? Give these guys a look today… Incredible…

A sad day for football… The “Minister of Defense”, dead at 43. His accomplishments, both on the field and off, were remarkable.

I’ve heard a few different causes of death so far, none official. His wife’s statement said that it was respiratory failure due to his sleep apnea. Another site said a massive heart attack. We probably wont know for sure until the autopsy results are released.

My thoughts and prayers are with his family…

I wanted to wish all of my readers a very Merry Christmas. I hope you find everything under your tree that you wanted. If you dont celebrate Christmas, then I wish you a very happy holiday season.

I know that http://www.noradsanta.org has been online for a few years now, but I dont believe Ive linked it before. You should check this out if you havent before. It’s quite a bit of fun.

Most of all though, be safe.

Ever want to drop all of the stored procedures in a database? I typically use this technique to do database updates (drop them all, and then recreate them) to make sure that I dont have any left over procedures and so I dont have to maintain different scripts for creating and updating my databases.

Try this script…

USE myDatabase
GO
 
declare @procName sysname
 
declare someCursor cursor FOR
    SELECT name FROM sysobjects WHERE type = 'P' AND objectproperty(id, 'IsMSShipped') = 0
 
open someCursor
fetch next FROM someCursor INTO @procName
while @@FETCH_STATUS = 0
begin
    exec('drop proc ' + @procName)
    fetch next FROM someCursor INTO @procName
end
 
close someCursor
deallocate someCursor
go

For the love of God, make sure that you dont run this against your master database. :)

Update: Changed declaration of @procName to sysname as per Raymond’s comment.

Earlier today, while at the gym, I was talking with a trainer about how to get the most benefit from my cardio days. He introduced me to the Karvonen Formula, which may be old hat for some of you. For those that havent seen this before, hopefully you’ll find it as interesting as I did.

Basically, the Karvonen formula calculates your target training zone based on your maximum heart rate and resting pulse.

The formula works like this:

220 – age = Maximum Heart Rate (MHR)
(MHR) – (Resting Heart Rate) = Heart Rate Reserve (HRR)

Your target training zone is anywhere between 60% to 90% of your Heart Rate Reserve plus your resting heart rate.

HRR * 60% + RHR

So, lets take me:

220 – 31 = 189 (MHR)
189 – 70 = 119 (HRR) I determined my resting heart rate by taking my pulse just after waking up in the morning.

119 * 60% + 70 = 141
119 * 75% + 70 = 159
119 * 90% + 70 = 177

So, my target training zone is between 141 and 177 beats per minute. This is easy enough to count off using a second hand. Divide the number by 6, and you know how much you need to be during a 10 second span.

The idea here though is to mix things up. If you always train at 60%, you’ll develop endurance with no top end speed. Conversely, if you train hard most of the time, you’ll never recover completely and your performance will be poisoned by chronic fatique. The best idea is to stay below 80% on the easy days to build a good base and push above 85% when its time to really go hard to improve high level performance.

Thanks to Chris Pirillo, I now have a desktop free of Post-It®s. The other day, he mentioned that he started using Stickies, which is a fantastic, free utility which aims to cut down on the number of Post-It® notes that get stuck to monitors.

From the website:

The design goal behind Stickies is that the program is small and simple. Stickies will not mess with your system files, or write to the registry. Stickies stores all information in a single text-based ini file.

Stickies will never support animated dancing figures, or play “Greensleeves”. They are instead yellow rectangular windows onto which you can put some text notes. Once created, they will stay on screen until you take them away. Just like a real sticky piece of paper.

The stickies can snap to each other’s edges. I have them all lined up down the right side of my desktop now. This tool is awesome. Make sure you take a look at it.

Why do golf courses have 18 holes?

During a discussion among the club’s membership board at St. Andrews in 1858, a senior member pointed out that it takes exactly 18 shots to polish off a fifth of Scotch. By limiting himself to only one shot of Scotch per hole, the Scot figured a round of golf was finished when the Scotch ran out.

[via No Three Putts]

Wow… That’s gotta make for an interesting round. I imagine I would have a tough time even *seeing* the course after 18 shots of scotch… :=)

*Update:* According to the fine folks at snopes.com, I’ve been had… :(

Sometimes, it may be desirable for you to create dynamic HyperLinks in your markup files. For whatever reason, you may not want to create the link for the hyperlink in code behind. Maybe you want to tweak it later without recompiling.

However, if you just try to put <% %> tags into your NavigateURL property, you’ll notice that it takes that text literally, instead of parsing it prior to calling ResolveUrl.

There is a way around this though, using DataBinder and a little known naming container called Page. Most of the times the syntax you’ll see for DataBinder.Eval looks something like DataBinder.Eval(Container.DataItem, "SomeProperty"). This works great when you’re using a DataList, DataGrid or Repeater.

To solve our problem though we’re going to use this syntax:

<asp:HyperLink id="link" runat="server" NavigateUrl='<%# DataBinder.Eval(Page, "SomeProperty", "newpage.aspx?prop={0}") %>'>Click Me</asp:HyperLink>

Now, the only thing that we have to do in our codebehind is set the control up to use data binding. In this case, it’s as simple as adding a line that says link.DataBind();. Make sure that your code-behind also has a property named the same as the second parameter to the DataBinder.Eval method and you should be ready to go.

It’s also worth mentioned that you can still use the ~ operator in your format expression (ie: “~/newpage.aspx?prop={0}”).

Enjoy!

David has posted a great little tip about parsing page parameters, using ASP.NET. This is a very basic example of the Pull Up Method refactoring. The important thing to take away from this example is how David has managed to eliminate code duplication using this refactoring.

David is sharing some of his favorite ASP.NET tips over on his blog, so make sure you stay tuned over there. Going along with that, Id like to share one of mine.

Sometimes the last configuration section handler I’ll ever need is just plain overkill. Sometimes, its easier to just throw a couple items in the appSettings element and be done with it.

<configuration>
    <appSettings>
        <add key="myApp.ConnectionString" value="myConnectionString" />
    </appSettings>
</configuration>

Add ConfigurationSettings.AppSettings["myApp.ConnectionString"] wherever you need access to the connection string, and you’re off. Or are you?

One thing that I’m sure everyone agrees is bad is using magic number constants. Equally evil, though not as oft mentioned, are magic string constants.

Given the above example, what happens when you change the name of myApp.ConnectionString to connectionString? You have to manually (or using your favorite grep tool), go through and identify each place that this constant is used. Talk about an accident waiting to happen.

How about a static Configuration class to wrap these calls for you?

class Configuration
{
	public static string ConnectionString
	{
		get
		{
			return ConfigurationSettings.AppSettings["myApp.ConnectionString"];
		}
	}
}

Now, throughout your code, you reference the connection string with Configuration.ConnectionString, and should you want to change the name of your setting, you are only changing it in one spot (the Configuration class).

A very handy technique, and one that I adapt slightly to deal with query string parameters as well. How often have you seen a method riddled with lines like: Request.QueryString["foo"]

Every page that I work on that has query string input, gets a protected get accessor for that item:

protected string Foo
{
	get { return Request.QueryString["foo"]; }
}

Again, the same priniciple applies here. If I change the name of the querystring parameter, I only change it once, instead of relying on a find/replace to do it correctly.

As we come full circle here, we can combine this technique with David’s to get something like:

class MyPageBase : System.Web.UI.Page
{
	protected string ParseRequiredParam(string paramName)
	{
		string value = Request.Params[paramName];
		if (value == null || value.Length == 0)
			throw new ArgumentNullException(paramName, "Parameter is required.");
 
		return value;
	}
}
 
class MyPage : MyPageBase
{
	protected string Foo
	{
		get { return ParseRequiredParam("foo"); }
	}
}

At this point, we now have access to all of our query string parameters. The benefits:

• These will be validated for null and length on access, rather than when the page loads.
• We’ve also done a Self Encapsulate Field refactoring on David’s original code base, and we no longer have the module level variables.
• We’ve declared the accessor as protected, so our markup file (*.as?x) can also access the variable if needed.

Not bad benefits for a bit of defensive coding…

Implementing the singleton pattern when you are using a single class is trivial using C#. The following chunk of code will accomplish that in a thread-safe manner.

class MySingleton
{
    private static MySingleton instance = new MySingleton();
    public static MySingleton Instance { get { return instance; } }
}

What happens though when you want to use singletons with inheritance (ie: each subclass needs to be a singleton as well)? This was the best I could come up with.

using System;
using System.Reflection;
 
abstract class MySingleton
{
	private static MySingleton instance = null;
	private static readonly object padlock = new object();
 
	public static MySingleton GetInstance()
	{
		lock (padlock)
		{
			if (instance == null)
				SetInstance(typeof(ChildSingleton));
 
			return instance;
		}
	}
 
	public static void SetInstance(MySingleton instance)
	{
		lock (padlock)
		{
			MySingleton.instance = instance;
		}
	}
 
	public static void SetInstance(Type type)
	{
		if (type.IsSubclassOf(typeof(MySingleton)))
		{
			MethodInfo register = type.GetMethod("Register", BindingFlags.Public | BindingFlags.Static);
			if (register == null)
				throw new InvalidOperationException("Instance must have a static Register method.");
 
			register.Invoke(null, null);
		}
	}
 
	public virtual string Info { get { return this.GetType().FullName; } }
}
 
class ChildSingleton : MySingleton
{
	private static ChildSingleton instance = new ChildSingleton();
 
	private ChildSingleton()
	{
	}
 
	public static void Register()
	{
		MySingleton.SetInstance(instance);
	}
}
 
class OtherSingleton : MySingleton
{
	private static OtherSingleton instance = new OtherSingleton();
	private OtherSingleton()
	{
	}
 
	public static void Register()
	{
		MySingleton.SetInstance(instance);
	}
}
 
class EntryPoint
{
	public static void Main(string[] args)
	{
		MySingleton singleton = MySingleton.GetInstance();
		Console.WriteLine(singleton.Info);
 
		MySingleton.SetInstance(typeof(OtherSingleton));
		singleton = MySingleton.GetInstance();
		Console.WriteLine(singleton.Info);
	}
}

I’m using this pattern for a project that I have going where resource items can be stored in either a database or on the filesystem. While developing, I would prefer to not have to go through the hoops of updating the database everytime I make a small change to a resource item.

So, while developing, I would use the SetInstance method to initialize the singleton instance to a Type that can read from the file system. Once Im done, I change it back to initialize the singleton instance that can read from the database.

The only thing that *kind of* bugs me about this is the dependency of the Register method on the derived singletons, but I dont see any other way to do this. Is there a better way? I’d be glad to hear peoples thoughts on this.