I have long been a proponent of using HttpHandlers when you need to serve up content which is not HTML or where you desire an alternative to Asp.Net WebForms.  As I am sure many of you know, the standard ASPX page is a pretty heavyweight solution that is really overkill and a performance drain for many scenarios.  As a result, I tend to create a lot of custom HttpHandlers in order to squeeze the most performance out of my applications.

A few years ago, Phil Haack created a great abstract class that I used as the foundation for my HttpHandler implementations.  Over time I found that there was additional functionality which should be abstracted out and thus I have created my own version of the abstract boilerplate.  Even within Phi’s original code I have changed some basic functionality to more closely follow the ASP.Net framework rather than creating a different paradigm.  In Phil’s original code, he passed the context through numerous method calls.  Not only did the original boilerplate pass the HttpContext, but often the methods were accessing properties on the Request or Response objects.   This is very different from most other ASP.Net development where Request, Response and Context objects are all first class properties on the base class.

I have also added additional methods which can be overloaded to handle permission checks and for setting the content MIME type and the content encoding type.  Finally, because AJAX requests often send any data in the body of the HTTP call, I have exposed this data in a Content property.

More...

Keith Elder’s recent post Dear Asp.Net Developers: Stop Making Our Technology Look Bad had a lot of great points but towards the end, I thought he suddenly swerved off the road.  In general, I agree with Keith that developers have a responsibility to provide all of their users with a good experience.  This is not always easy and I give sites lots of slack when I see they made a reasonable effort.  But when I see sites like the CodeZone example in Keith’s post, I have to wonder why those developers still have a job or where were the senior developers on the project.

Where I vehemently disagree with Keith is that his “solution” is for Asp.Net developers to adopt the MVC framework and NVelocity (or other non-webforms or non-Microsoft tools).  To me this is a complete non-sequitur.  You can create perfectly useable, XHTML/CSS compliant websites using WebForms and Visual Studio.  It is not hard.  It is just a matter of caring.  Hundreds of thousands of developers do it every day.  Lazy, uncaring developers will still be lazy and uncaring even if they are using the MVC framework. More...

There appears to me to be a recurring pattern I see on many web sites.  Often you will have a JavaScript library that you want to use which requires certain variables be defined in your web page.  I have seen this pattern repeated for many different widgets that you may want to include on your page.  More...

In his recent post on Configuring the Stack, Jeff Atwood discusses the frustration that comes with installing a complete development environment. 

I'm having a hard time seeing how Microsoft's commercial stack is any easier to configure than the alternative open source stacks these days. Either the open source stuff has gotten a lot more streamlined and mature, or the Microsoft stuff is somehow devolving into complexity. I'm not sure which it is, exactly, but the argument that choosing a commercial development stack saves you time rings more and more hollow over time.

You can read through the comments and see that many people have jumped at the opportunity to bash Microsoft and espouse the virtues of the competing open source offerings.  What I think that Jeff and some of his readers are missing is that his list of tools is an entire stack and once installed is in a useable state requiring almost no additional configuration in order to begin development.  To equal what Jeff has installed you would need:  A compiler (for 4 languages - I'll be generous and let you pick any four compilers for your favorite languages), a code editor, a web server, a database, unit test framework, load testing framework, functional web test framework, a web framework (like Struts or RoR), a version control client, a bug tracker client (if you use a web-based bug tracker then your browser counts), a db comparison/diff tool, a db query tool, a report writer and a UML diagramming tool.  I know that there is a lot more features that I am glossing over, but to think that Emacs represents an entire "stack" or that GCC is somehow equivalent to VS.Net (any edition), as suggested by some of the comments, is pure fantasy.

I lived in the Java OS world for several years and it is no different.  You install Eclipse, Java SE, J2EE, JBOSS, Spring, Struts, a db of Choice, junit, an svn client and whatever you are using for bug tracking.  This is just the installation.  Then you have to actually go through and manually edit several different configuration files.  At that point I would consider that you have a large part of what Jeff has installed.  You might still need to install a diagramming tool, a reporting tool, a few more db tools and some additional testing tools.  Where I think that Microsoft excels is that getting all of those tools to work together is relatively simple.  The same is not true in other environments.  While the Java world is getting better with the rise of Eclipse and the domination of JBOSS, you still often end up with a patchwork of tools and frameworks that are needed for developing the advanced systems that are currently de rigueur in the desktop and web worlds.  If you look at other environments like Python, PHP, or Ruby you still have all of those same issues, except that many of the tools are not nearly as mature as Eclipse or Visual Studio.

Don't believe the hype, OS is no panacea.  We live in a complex computing world and build very complex applications.  We should expect that our development environments would reflect this reality. 

My bigger beef in this whole situation is that Windows has always had a stability problem such that every 12 to 18 months you are forced to re-pave your system just to get back to a re-useable state of existence.  If I could keep my Windows installation from rotting over time then I would gladly pay the installation price one time and be done with it.  However, it becomes hard to swallow having to set aside a couple of days every year or two just to refresh my whole system due to the crud that builds up in Windows over time.

Dare Obasanjo posted about Three Things I Learned About Software in College, which Scott Hanselman followed up with Three Things I Learned About Software WHILE NOT in College.  So here are my lists:

Things I learned about software in college

1. Never close your eyes to learning.  The world of software is constantly evolving and if you don't stay in a learning mode, you will fall behind.  I started college writing code on mainframes and left college coding on PCs.
2. There is no one perfect language.  There are the languages you know, the languages you don't know, and the languages that have yet to be created.  If you are following rule number 1, then the language you use today is likely not going to be the same as the one you use 5 years from now.  Get used to it.
3. Programming is primarily about problem solving.  Improve your logical thinking skills and you will improve your programming skills.

Things I learned about software WHILE NOT in college

1. No matter how good of a programmer you think you are, there is always someone better and faster:  Unless your name is Scott Hanselman.
2. You are not as good a programmer as you think you are.
3. Often, "good enough" is "perfect".

Things I THOUGHT I learned about software in college (but which I apparently need to keep re-learning)

1. Some of my most brilliant code was written in the wee hours of the morning, the night before it was due.
2. Some of my buggiest code was written in the wee hours of the morning, the night before it was due.
3. Good code rarely happens in a vacuum.