I recently had the need to find out how much time elapsed during the execution of just my action, so I created a handy little action filter based on System.Diagnostics.Stopwatch.  This action filter adds the elapsed time to an HTTP header, appropriately named, X-Stopwatch. 

I choose to use a header instead of a response in the content body, so that it could be used both with non-HTML responses (binary, JSON, XML, etc) and HTML response.  I was amazed at the usefulness of this simple piece of code, because it instantly gave me insight in to the actual execution time of my action to see if my optimizations were having any effect.  It allowed me to monitor the execution time of code that I can specifically and easily control the performance of.

Here is the filter if you want to add it to your own projects.

public class StopwatchAttribute : ActionFilterAttribute
{
    private Stopwatch _stopwatch;

    public StopwatchAttribute()
    {
        _stopwatch = new Stopwatch();
    }

    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        _stopwatch.Start();
    }

    public override void OnActionExecuted(ActionExecutedContext filterContext)
    {
        _stopwatch.Stop();

        var httpContext = filterContext.HttpContext;
        var response = httpContext.Response;

        response.AddHeader("X-Stopwatch", _stopwatch.Elapsed.ToString());
    }
}

You can view the full C# File here on my GitHub repository.  This could obviously be modified to suit your own needs.

Note

I cannot endorse the SocketLabs service anymore. Everything below works with any SMTP service. If you would like great alternatives please give the people at:

• Postmark a try for transaction email
• or if you need to send bulk email please try out SendGrid

So you have a GoDaddy server and you want to send email through your newly acquired SMTP Relay. Well “you can’t” is probably what you are going to find if you do some poking around Google.

If you poke around a little more you will probably find GoDaddy’s official solution is to use their internal mail relay.  This is not ideal, because of arbitrary barriers they have set, such as this one:

Our dedicated servers have an outbound email limit of 1000 per day. If you need to send more than 1000 emails per day, please call Customer Support or open a support ticket to request a higher limit.

I shouldn’t have to justify my use cases and business to a company that I am paying over $200 a month for a dedicated server.

But all is not lost, and I could still use the free email relay I created in my previous post. As I was searching around the SocketLabs support site I discovered the solution I was looking for and found that alternative ports have been opened to get past the port 25 filtering that a lot of residential cable companies and internet service providers force upon you.  I found this in the SocketLabs support system:

Using SocketLabs Email On-Demand With a Residential Internet Cable Service and Alternate SMTP Ports

If you are going to be sending email through your residential cable internet service you should be aware that most of these ISPs will block access to third party SMTP servers through the default port 25. In this case you can use the alternative port of 2525 when configuring your SMTP connection to get around this problem.

This seemed to be exactly what I was looking for.

To start, we need to pick up where we left off in my previous smart host blog post, we need to configure the outgoing port that our smart host will connect to.  By doing this we accomplish the exact same goal as when I first setout of not having to change a single thing in your already functioning and setup applications.  To configuration the alternative port, follow these 4 steps:

1.  In IIS Manager, right-click the SMTP virtual server, and then click Properties.

2. Click the Delivery tab, and click Outbound connections.

3. In the Outbound Connections dialog, set the TCP port to “2525” as picture below

4.  Click OK and then then you are done.

To verify that it was working, I sent a test email to one of my email addresses and received an email that contained both receiving headers.  One header from the localhost and then one from my SocketLabs relay server, as was originally shown in my previous post.  Here are the receiving headers from the test email I sent using the alternative port:

Received: from server ([69.59.171.172]) by mxsp2.email-od.com with ESMTP; Mon, 25 Oct 2010 21:44:09 -0400
Received: from server ([127.0.0.1]) by 26294-68734 with Microsoft SMTPSVC(7.5.7600.16601); Mon, 25 Oct 2010 18:44:10 -0700
Subject: Web Site Information Request
From: "Managed Fusion No Reply" noreply@managedfusion.com

I first discovered this setback with GoDaddy, as I was testing my smart host setup on a GoDaddy dedicated server.  This was sort of a pain in the you know what, but it is understandable and appreciated that they go through basic steps to stop spammers on their infrastructure. Luckily for me SocketLabs Email On-Demand has come through with a solution for their customers.

Over the past couple of weeks I  have been slowly planning and revamping my iPhone app to address user concerns, bugs, and problems.  And as part of the rework I decided to support other platforms, in addition to the iPhone, such as the iPad, Android, and Windows Phone 7.  However with this new focus, I had one huge problem, how was I going to learn each new SDK.

This problem led me to struggle with if I should develop for each platform natively in its own language and SDK or use a cross platform programming language that would basically put a shim on top of the native SDK.  The pros and cons of each approach where the following:

Eventually I came to the conclusion that I had to accept the fact that if I wanted to support all the platforms, I was going to have to use a cross platform programming language, because I am one guy with a limited amount of time and don’t really have time to learn Obj-C and Java on top of the SDK’s for iOS, Android, and Windows Phone 7.  So I started browsing around and came up with the following options for developing cross platform:

1. MonoTouch & MonoDroid : I would be able to share the C# code across the platforms with Windows Phone 7 app if I crafted the libraries for accessing the core data, but this choice still required me to use each platforms UI, so I would have to spend the time diving in to each individual platform.
2. JavaScript & PhoneGap : This seemed like a perfect solution, because I know JavaScript and HTML, and PhoneGap would turn them into native applications by running them in a shell browser on the device, however this severely limited me in what I could do with the UI.

I really found the fact that I could continue to program in C# with MonoTouch and MonoDroid very alluring.  But, ultimately I decided I was going to go with jQuery Mobile and PhoneGap, because I lacked the time to even dive in to MonoX frameworks, and I already had a solid grasp of HTML and jQuery so I decided to use PhoneGap as the platform for my next release. If you have never used PhoneGap here is how they explain it on their website:

PhoneGap is an open source development framework for building cross-platform mobile apps. Build apps in HTML and JavaScript and still take advantage of core features in iPhone/iPod touch, iPad, Google Android, Palm, Symbian and Blackberry SDKs. Learn More ›

Sounds great huh?  Well it sort of is, but has some rough spots when reaching outside of the browser.  But so far I have been able to successfully do the following from JavaScript from within the browser:

• Popup Native Alerts
• Get GPS coordinates
• Vibrate The Device

I will be posting updates during the development process here on my blog.  And the nice thing about doing something with HTML and JavaScript, is that I can share them all with you through your browser with out ever having to deploy the app to a single device.  So that part I am completely thrilled with.