Steve Scheffler

There are plenty of great resources available to show you the ins and outs of securing your azure website with SSL. Here are a few handy links I found which enabled me to secure my azure website.

If you're going the free route then be sure to use Troy Hunt's excellent howto guide for

Pricing for SSL on azure can be a bit confusing, but here's a quick summary:

  1. You're responsible for bringing your own cert (see options above)
  2. Azure will charge you $9 per month per SSL site
  3. You can avoid the $9 per month for your first 6 sites if your App Service is Standard or better

For detailed pricing information see the azure web app pricing info here.

About 6 months ago I moved my ATT account of 10+ years to the Mobile Share Value Plan from ATT, and I'm saving a lot every month thanks to that.

However, when the new iPhone 6 came out shortly after I changed plans, I quickly learned that I needed to read the fine print, closely, when purchasing new phones and adding them to my account.

We have 3 kids that are all at or nearing teenage years, so the need to add or replace phones on our mobile plan is ever present. In the past we've always just purchased phones directly from Apple using the "with 2 year service contract" reduced price. This has worked well for us over the years and given us some hand me down phones for the younger kids.

As I was planning to stand in line the next day for the shiny new goodness that was being relesaed from Apple, my brother cautioned me against buying in the same manner as I'd always done. Unconvinced, and because I'm the older brother, I set out to prove him wrong and show him that my way was still the best way.

As I started to dig into the various plans and purchasing options I discovered that ATT has made the whole comparison process much more complex. I also found that my little brother was right. Drat.

To illustrate the options available in April of 2015, the table below depicts the total cost of ownership of a new iPhone 6 (64GB) when added to an existing Mobile Share Value Plan with a shared data pool of 10GB or greater. At the time of this writing, there are three ways to purchase a new phone:

  1. Contract Free (street price, no strings attached)
  2. 2 Year Contract (carrier subsidizes the up front cost - traditional)
  3. ATT Next (free financing w/ installment payments)

The numbers speak for themselves. As long as you pay out of pocket up front or sign up for the Next plan, then you come out ahead. The service contract approach adds an extra $190 to the cost of the phone. This is very hard to spot unless you comb through all the fine print that is spread across several areas of the ATT site.

The 'contract premium' line was one of the hardest bits to decipher in all of this. If you follow the links below you'll see a table from ATT which states that normally you pay $15 per month for each contract free phone added to your shared plan. If you bring a phone to the party WITH a contract then that monthly price jumps to $40. Thus the $25 premium shown in column 2.

I've included a few links below to the ATT site to support the numbers in table.

In the end, I opted for the Contract Free approach. This allowed me to buy the phone as soon as it became available, rather than waiting 30-60 days for ATT to get them in stock. It also gave me the option to unlock the phone so that I can move it to other carriers or use internationally. While I don't have immeditate plans to do either, the option is worth something there.

Hope this helps.

ATT Next Plan Comparison

Charge for adding phones to MSV Plan

Beyond Management Studio

I've been spending a lot of time recently tuning SQL Server queries in my application development work.

For me, that means crafting SQL statements by hand in SQL Management Studio and reviewing IO and time stats to measure my tuning progress. Once the query gets to a reasonably performant point, then I'll fold it into my application code and move on to the next task. This simple process works for me in most cases; however, sometimes it helps to have access to key SQL perf information programmatically.

A Simple Utility

Enter SqlStopwatch. This utility is modeled after the .NET Stopwach class and is used to reveal how hard the SQL Server engine is working to service individual requests.

The constructor for SqlStopwatch expects an open SqlConnection instance. In between the subsequent calls to Start and Stop/Elapsed, the stopwatch will calculate elapsed time and total logial reads for all work performed on that SQL session.

If you're wanting to measure the performance of individual SQL calls then you should call Elapsed after each call to gather up the impact of each step. Alternately, you can Clear or call Start again on the SqlStopwatch to refresh the 'before' snapshot.

Here's a simple example using the Adventureworks database:

var sw = new SqlStopwatch(con);

// Start will capture a 'before' snapshot of the connection's
// session information. This is needed since some of the 
// counters in the DMV tables accumulate over the life
// of the session

var emps = con.Query("SELECT * FROM HumanResources.Employee")  

// Calling Elapsed will calculate teh elapsed time and 
// number of logical reads since the last time that Start 
// was called. To reset the timer, call Start again or Clear
var elapsed = sw.Elapsed;

// Output example: 
// [SPID 53] Elapsed Time: 28 ms, Logical Reads: 9

The SqlStopwatch class is available on GitHub here.

If you find this helpful, or have change recommendations, please let me know.

Happy coding!

Dates in javascript are weird. There, I said it.

This last week I got stung a few times working with dates that were being sent back from an MVC controller action in JSON format.

I'm throwing together this quick little page to help me remember in the future what I figured out today.

First, javascript dates follow the ISO 8601 standard. That's the one with the "T" in the middle of the long date/time string. This is an example of one


If you take that string and pass it as an argument to a javascript Date constructor, you'll get a live Date object.

Now, the problem I ran into was that sometimes I was getting Date results in JSON strings that looked like this, rather than an ISO string:


This is how Microsoft will encode dates in an HTTP response. It's an integer value representing the number of ticks since the epoch.

After a little bit of looking, I found the reason for the encoding differences. It all has to do with whether or not you're returning a raw C# DateTime object, or a string. Here's an example action method which takes the current date and then encodes it three different ways:

        public ActionResult DateFormatting()
            var thedate = DateTime.Today;
            return new JsonResult
                Data = new
                    RawDate = thedate,
                    JsonSerialized = JsonConvert.SerializeObject(thedate),   
                    DateTimeToString = thedate.ToString("o")
                JsonRequestBehavior = JsonRequestBehavior.AllowGet

Here are the results in JSON format. Note that when we just return a raw DateTime object from MVC it gets Microsoft encoded. If we use the Newtonsoft JsonConvert method then we get a nicely formatted ISO string. Finally, if we use the built in ToString method on DateTime and specify 'o' for iso, then we get a similarly formatted ISO string.

    "RawDate": "/Date(1411707600000)/",
    "JsonSerialized": "\"2014-09-26T00:00:00-05:00\"",
    "DateTimeToString": "2014-09-26T00:00:00.0000000-05:00"

Going forward I'm going to make sure that I just run everything through JsonConvert before passing it back to the client. I've found that it's much easier to work with the native ISO strings in javascript, especially when you start having to deal with timezone differences.

Hope this helps.