The web has evolved and the standards for browser applications have been raised to new levels over the past five years. People just expect more (and rightfully so) from web applications. It used to be that whenever I used any kind of JavaScript (to which, from this point forward, I will refer to as simply, JS, thankyouverymuch) in my web apps that I would pretty much just reference a .js file and randomly jam a bunch of functions in it, and hope someone (a team member, perhaps) didn’t notice them closely enough to attempt to use one in a way in which it wasn’t intended to be used. Knowhatimean? Ever been there, or done that? Perhaps you’re there now.

At some point…not sure exactly when…I guess it was probably about six or eight months ago or so…I finally got to a point where I said to myself, “self…there has GOT to be a better way.” So I did some Googling…and as it turns out, I was right…

About a year-and-a-half ago, Crys and I invested in a new wood burning stove for our home. Last winter and this winter so far, we’ve been burning wood to keep us warm. During that time I’ve built dozens of fires, and if there’s one thing I’ve learned for certain its that building a good fire is easier said than done. I’ve learned a handful of tricks that has made the task easier over time, and I can consistently get one going much better than I could last year when we started this. Most of what I’ve learned has been through bits and pieces from conversation over time, and more than anything, trial and error.

Building a good fire is a skill that I feel every good man should possess, but as time rolls on, fewer and fewer have it. Its a skill that I certainly intend to pass on to my sons. There are handful of things that I’ve learned are important for starting and maintaining a good fire. I thought I’d share some of what I’ve learned here. If you know of anything that I might be missing, share your ideas in the comments.

Every .NET developer I know has war stories about past horrors of deployments gone wrong. My theory is that’s because there’s not a good, universally accepted way to handle deployments of .NET apps on windows. Octopus steps in and offers a solution that, in my recent experience, dramatically simplifies the .NET deployment problem with a really elegant solution.

As most .NET developers do at some point or other, I was recently faced with a need for an automated build tool. For various reasons I’ve come to the point where I’m not really satisfied with any of the ones currently available, so I decided to write one. Pyke is the result of that itch.

I won’t spend a whole lot of time here trying to explain my reasons for why I’ve decided to port my blog over to Octopress…most people that ever see it aren’t going to care anyway, and for the scarce few that might actually read it often enough to recognize the difference, if you’re really curious, I’ll leave it to you to ask if you are interested. The short of it is, Octopress brings a number of things to the table out of the box that I wanted in a blog platform that I’ve long felt I was fighting with WordPress to get. I still think WordPress is a fantastic platform for many, many scenarios…but Octopress does a number of things that are very appealing to a those of us with geek-like tendencies such as myself, which is why I’m making the switch.

The more important consequence of the port is going to be the impact on current feed subscribers (are there any? really?) and search engines, as some of my older content will go away, and my URL structure will end up being at least a little bit different. Different enough that people that find links to posts from my old blog through search engines may not find what they’re looking for immediately. I’ll do my best to get as much of my older content that generated interest ported over here as soon as possible, and maybe more importantly, get a good 404 page setup as soon as possible too.

Ultimately my hope is that some of the things that it (Octopress) brings to the table will make it a little bit less painful for me to actually get on the ball and write some of the things I’ve been dying to write about (though I’m fairly certain that it won’t buy me any more time…which is ultimately one of the biggest hinderances to my writing). I’ve been working on and with some really fun stuff at work, and learning a lot from it, and I’d really like to share some of it and get some feedback on it from people I know are smarter than I. I’d like for my blog to be a two-way street where I can share and learn at the same time. Hopefully I can share enough to be able to make that happen.

I recently started working on a personal ASP.NET MVC project on which I wanted to use Less CSS for styling. I quickly ran into a problem when I discovered that a IIS Express doesn’t have “.less” registered as a valid MIME type, so it won’t serve up the file at all. So that forced me to dig around to figure out how to add a mimetype to the IIS Express configuration. I found a working solution, and thought it could potentially help someone else out.

To add the .less extension as a valid MIME type to IIS express follow these steps:

1. Open a windows command prompt
2. Switch to the directory that IIS Express is installed in (on my 64 bit Windows 7 system, it was installed in C:\Program Files (x86)\IIS Express)
3. Execute the following command:

1

appcmd set config /section:staticContent /+[fileExtension='.less',mimeType='text/css']

Boom. Works great. Now I’m rollin’ with Less CSS in my ASP.NET MVC project developing on IIS Express. Sweetness.

Over the past couple of days at work I’ve been working on getting a progress bar and some other elements of a page updated by making an ajax call with jQuery to an ASP.NET MVC (3) controller action. Everything was working great, with the exception of Internet Explorer (I’m currently using v9, but the issue we’ve been having is also known to exist in IE8 as well). The progress bar and all dynamically updated page elements were getting updated just fine in Google Chrome, Firefox (4) and Safari (5, for Windows), but Internet Explorer wouldn’t update any page elements after the first ajax call was completed.

So, as you can imagine, we spent a good amount of time Googling to try to figure out what might be the problem with IE. Somehow, one of my co-workers stumbled on an article (I actually think it was a StackOverflow thread, but I can’t be sure) that mentioned that the issue might have something to do with browser caching. So, we gave it a shot and disabled caching on the controller action, and everything started working fine in IE. St00pid IE.