Over the last several years DotNetNuke has maintained a policy of providing an upgrade path for users running previous versions of the platform.  Only in rare instances will we intentionally break a feature or an API or do something that would cause 3rd party extensions to break.  Customers have expressed to us over the years how important it is to maintain an upgrade path.  This concept is not unique to DotNetNuke.  Various projects and companies will take a different stance on the topic.  I was reminded of this recently with the Windows 7 launch where XP users were forced to make a tough decision – go through the hassle of installing a clean version of Windows 7 and then installing all of their old software and migrating their data (I hope grandpa had good backups), just stick with Windows XP, or move to a competitor.  Even Apple recognized the problem with the Windows 7 approach as evidenced by their Mac vs PC commercials.

More...

This past year I had the pleasure of being asked by Jim Minatel at Wrox to write a Wrox Blox covering the basics of jQuery for ASP.Net Developers.  Having co-authored 2 previous books, I realized that writing a book, regardless of the size, is a lot of work, but something that I also find gratifying once you have a finished product.  Over the last 2 years, I had gotten more and more into jQuery and really loved its simplicity and power, and thought that this would be a great opportunity to share some of the knowledge I had gathered.

For those that are not familiar with the term, a Wrox Blox is a short e-book (30+ pages) which covers a narrow topic.  They are not intended to be an exhaustive discussion of a topic, but rather to cover one particular aspect of what is often a much broader subject matter.  Because of their narrower focus and the fact that they are only available as e-books, Wrox is able to keep the cost of the Wrox Blox very low.  Wrox Blox generally include a lot of code examples rather than being a purely theoretical discussion of a topic.

After a couple of months, several missed deadlines and a page count that greatly exceeded what was originally requested, I finally finished the Wrox Blox which was subsequently published last September.  I am very pleased with the final product which comes in at 66 pages and is a great introduction to jQuery and ASP.Net.  jQuery for ASP.Net Developers  includes sections on the jQuery API and its usage, and on using jQuery with ASP.Net WebForms and ASP.Net MVC frameworks.  I had a great time writing the book and like all writing assignments of this size, it really forced me to dig into jQuery much deeper than I had previously.  It also gave me a greater appreciation for why Microsoft chose to ship jQuery with Visual Studio 2010.

More...

Why you shouldn’t learn MVC

Earlier today Rob Connery posted about why he thinks You Should Learn MVC.  Rob is a great guy and we always have lively discussions whenever we meet at conferences.  I was in the middle of writing a long comment on his blog when I decided it might be better as it’s own post.

I have to say Rob, once again, another great post!  Another great use of straw man arguments and red herrings.  Come on really?  You are going to trot out jQuery as a reason to try MVC?  Why not say “Use MVC because it runs on Windows and works with IIS”.  Come on, at least use real arguments if you are going to make the case for MVC.  I’m sure you know that jQuery works wonderfully with WebForms.  People like Rich Strahl, Dave Ward and others have a ton of great blog posts on the topic.  I even have a few myself.  jQuery is a valid argument if you are trying to sell people on adding more JavaScript, but the argument as framed does not make the case for MVC.

More...

In 2006, Neal Ford wrote a blog post on the topic of Polyglot Programming which foresaw a future where applications will be increasingly built using multiple general purpose languages and domain specific languages.  Ted Neward has a recent article from MSDN Magazine which follows up on this theme with a discussion of Polyglot Programming in .Net.  Both Neal and Ted address some of the issues with Polyglot Programming, but I think there is one that they have missed.  Polyglot Programming can quickly lead to performance rot in application development.

In DNN Tips and Tricks #10, I presented an example of how you can use the DotNetNuke Report Module to display you data using the advanced capabilities of XSLT.  Greg Lahens pointed out an issue with my SQL code which is really highlights one of the downsides to Polyglot Programming.  As programmers, we often employ a variety of tools to solve a particular programming challenge.  Many of these tools are DSLs – XSLT, SQL, CSS, HTML are just a few of the many DSLs in common use throughout the web development world. 

More...

In my previous post on the DNNMenu and SEO, I discussed testing user-agent strings and creating custom browser detection files.  As part of my testing I created a simple web-app that allows you to validate your browser capabilities.  By navigating to the test site, you can see exactly which features are enabled for your specific browser.  To alter how ASP.Net reports the capabilities for a specific user agent, create a custom .browser file and add it to the App_Browsers folder in your website.  See MSDN for a complete discussion of the browser definition file format.

The below sample shows the capabilities I have configured for the Yahoo! Slurp web crawler.  This is not a definitive list of capabilities, but rather some custom values that I needed for my testing.  Feel free to alter this file as needed to more fully emulate the features supported by the Slurp engine.

<browsers>

    <browser id="Slurp" parentID="Mozilla">

        <identification>

            <userAgent match="Slurp" />

        </identification>

        <capabilities>

            <capability name="browser" value="Yahoo!Slurp" />

            <capability name="crawler" value="true" />

            <capability name="cookies" value="false" />

            <capability name="css1" value="true" />

            <capability name="css2" value="true" />

            <capability name="javascript" value="false" />

            <capability name="tables" value="true" />

            <capability name="w3cdomversion" value="1.0" />

            <capability name="xml" value="true" />

            <capability name="tagwriter" value="System.Web.UI.HtmlTextWriter" />

        </capabilities>

    </browser>

</browsers>

The screen below shows a short list of capabilities detected for Firefox 3.

  Download the BrowserCaps web application

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.