Browser Compatibility, IE, FireFox, Standards

One of the biggest challenges to web developers is accomodating the browser. Standards with the DOM and CSS have come a long way, and so has the implementation. (Before you start harping about "Internet Exploder vs. Firefart", do yourself a favor and review the over 200 behavior and other changes they baked in as of IE 7 RC1, which was released today, at the IE7 blog page and see for yourself).

So now that you have an RC for IE which basically means no more code changes until the next release, it's time for developers to start zeroing in on the defects and anomalies and workarounds for rendering, positioning and behaviors between different browsers.

I for one would appreciate some sort of a site that highlights the differences between say IE, Firefox and Opera, one-by-one according to type (CSS, DOM, script, etc) with workaround examples for each. A community site wiki - style, with some developer participation, would go a long way toward helping the community as a whole and cut down on the incessant flame - throwing from one camp to the other (which is currently reminiscent of the Middle East).


Mashup Hype Cycle and Web APIs, the HtmlMeta tag, and Round Manhole Covers

"Adults are just obsolete children and the hell with them." -- Dr. Seuss

I follow ProgrammableWeb in the API space just to try to keep track of what other people are doing, and found an interesting tidbit from Gartner:

"According to the just released 2006 Emerging Technologies Hype Cycle mashups are nearing the hype cycle peak. They get a rating of moderate and Gartners analysis is that:
Mashup is rated as moderate on the Hype Cycle (definition: provides incremental improvements to established processes that will result in increased revenue or cost savings for an enterprise), but is expected to hit mainstream adoption in less than two years. A mashup is a lightweight tactical integration of multi-sourced applications or content into a single offering. Because mashups leverage data and services from public Web sites and Web applications, theyre lightweight in implementation and built with a minimal amount of code. Their primary business benefit is that they can quickly meet tactical needs with reduced development costs and improved user satisfaction. Gartner warns that because they combine data and logic from multiple sources, theyre vulnerable to failures in any one of those sources."

This is certainly true - especially the vulnerability aspect. If a single page web-scrape can fail because the site changes their CSS layout, then obviously a multi-source mashup has n * source chances to get mucked up.

Of course, an interesting side-note on this is that the "Gurus of Gartner", in their never-ending quest to hype their own brand of "holier-than-thou", "We are the experts" drivel, have now apparently coined YABW (yet another buzz word), "Hype Cycle"!

Recently there was some fluff on Digg over an article about "How to provide a web API". Besides simply stating the obvious and providing no real added value (at least, not to me) the article itself was not revealing. In addition, the post about it was littered with comments about how "REST" is the way to go, and "why aren't there SOAP extensions for REST", etc.

Fact of the matter: REST isn't an API or a specification. Its a TECHNIQUE, and the implementations of it vary widely. SOAP, on the other hand, IS a specification.

Essentially REST is saying, Look- I know you're a dummy, so just put all your shit on the querystring and I'll take care of it and send you back well-formed XML anyway. And, Whoopee -- you don't even have to peel off the SOAP envelope, cause it won't be there!

REST is a technique, not a standard (or even a specification) and there is no such thing as machine discoverable REST as there is industry standard WSDL for SOAP.

So, before we go "hyping off the cliff" with more buzzwords and no parachutes, let's get our facts straight - and make an effort to keep our Hype Cycle Mashups from jumping out of the frying pan right into the fire.

The new HtmlMeta Tag

In Asp.Net 2.0, dynamic SEO on pages gets easier. Consider this code which dynamically writes the META description, keywords, and the page Title tags, all of which could come out of a database record:

 protected void Page_Load(object sender, EventArgs e)

// Create two instances of an HtmlMeta control.            
HtmlMeta hm1 = new HtmlMeta();
HtmlMeta hm2 = new HtmlMeta();

// Get a reference to the page header element.            
HtmlHead head = (HtmlHead)Page.Header;

// Define an HTML element that is useful for search engines.
hm1.Name = "keywords";
hm1.Content =
"words, that, describe, your, web, page";

// Define an HTML element for description tag.
hm2.Name = "description";
hm2.Content =
"This is a description of this page!";

// populate the page Title element            
this.Title = "A brand new way to populate META Tags!";

-- I distinctly remember being impressed when I heard there are twice as many classes in .NET 2.0 than in .NET 1.1. Everything in the above example is new in .NET 2.0!

Why Are Manhole Covers Round

You may or may not have seen this recently; it used to be a popular interview question at Microsoft if you wanted to get hired:

Why are manhole covers round?

Pick your poison:

1) Manhole covers are round because manholes are round.
2) A round manhole cover cannot fall through its circular opening, whereas a square manhole cover may fall in if it were inserted diagonally in the aperture.
3) Round covers are much easier to manufacture.
4) Circular covers do not need to be aligned to put them back.
5) A round manhole cover can be more easily moved by being rolled.
6) Round tubes are the strongest and most material-efficient shape against the compression of the earth around them.
7) The Three Stooges wanted them that way, and people have been doing it ever since.

And the correct answer is .... (Nyuk nyuk) -- they're all correct; there is no "right" one!


Observations for .NET N00bs: Developer Paralysis,Exceptionless Programmer Syndrome, and Googleless.

Over at one of my favorite hangouts, eggheadcafe.com, we get lots of forum posts from people just starting out, and many of these posts remind me of when I first started with .NET and ASP.NET back in 2000.

There are two major themes that seem to dominate many of these posts. I call them "Developer Paralysis" and "Exceptionless Programmer Syndrome":

Developer Paralysis

This is when a programmer (even sometimes an experienced programmer) is faced with a request or requirement to create something that they have never done before. The programmer becomes consumed with doubts - doubt about whether they can do what is requested, doubts about how to do it, doubts on whether they'll be able to do it in the timeframe requested, and so on. This process of self-doubt becomes so all-consuming that the developer is literally paralyzed to the point where they are virtually unable to even begin a project. Days can go by with nothing happening. If this ever happens to you, there is a very simple solution:

Get To Work and Start Writing Code!

I have always found that the process of starting a new solution, adding a project and starting to write code -- ANY CODE -- has a settling effect and within a short time, you will find you are no longer paralyzed. Your self-doubts will begin to fade as you start implementing a solution to the programmatic problem with lines of code. Sure, the code will change. Miuch of it may be thrown away later. That's unimportant. What's important is that you are being paid to write code and as long as you are writing code, your frame of reference has changed from being a victim of Developer Paralysis into one of being a working coder who solves problems. As you become a better and better coder, you will throw away less and less of the code you write. You'll develop reusable libraries of classes and solutions that you will be able to draw from later. Even if you haven't a clue where to start, just start anyway.

Exceptionless Programmer Syndrome

This is just what the title sounds like. I wish I had a dollar for every time I've answered a post where there was a virtually 100% chance the developer could have solved their own problem by simply instrumenting their code with try/ catch/finally blocks.
You can save yourself countless hours of debugging time by surrounding ANY CODE that could possibly throw an exception with a try / catch block, and doing SOMETHING with the caught exception- even if its as simple as just outputting the Message and StackTrace properties to the debug output window.

Wire up your applications with global exception handlers that will log unhandled exceptions so that you can easily find out why your app "blew up". In an ASP.NET application, for example, you can flesh out the Application_Error in Global with code that calls Server.GetLastError().GetBaseException(). You can call Server.ClearError() after that if you like.

But the important thing is to NEVER assume that any code you write will work. ALWAYS assume that something you didn't think of will go wrong, and code defensively with logging code to tell you about it. And I mean wire up EVERYTHING - every method. If you aren't sure where to put your try / catch block, then just start out by wrapping the entire method body in one. But, don't leave anything out.

At eggheadcafe.com, I have several articles on this subject; you can find them by putting the word "Exception" in our search tool.

Now that I think of it, there is actually a third major handicap, and that is the

Googleless Affliction

This is the developer who spends an inordinate amount of time making posts to newsgroups and forums with questions that almost invariably could have been answered very quickly by placing a few keywords into the Google or MSN search engine pages and pressing the SEARCH button. As I've often discovered by taking a few well-chosen keywords from their question and searching on them, often the best answer comes up in the first page of results. So you are going to post and wait around for a couple of hours for answers, when all you had to do is ask the question to Google, and you'd have gotten answers right away, no?

Having said this, knowing about Google does not equal knowing how to use Google -- or any other search engine for that matter -- effectively. Today's search engines are not evolved enough to guess what we mean when we type in a single-word search query while looking for answers to complex questions. Yet research has shown that the majority of users employ such limited strategies when using search engines. The better a Googler you are the more knowledge you can aquire, faster. Here's an article that pulls together most of these google search tips and tricks.

Ponce DeLeon Syndrome

This is a smaller but active category of developers who seem to take delight in finding what they think are "bugs" in either Visual Studio or the .NET Framework by means of finagling non-standard coding snippets and other subterfuge. Rarely, they do find actual bugs, but in the vast majority of cases it is just "mental masturbation". Then they gleefully post their discoveries on the newsgroups for all to see (Instead of using the Product Feedback site, and searching to see if somebody has already posted it). These people will never amount to much since they are so preoccupied with narcissistic attempts at recognition rather than accomplishing anything. In addition, recognition (which is what they are really seeking) never comes.

(In other news, dark matter is real, scientists say, and 9 million sizzling singles await you on True.)


Written in "PURE C#", Google Code and Conspiracy Theories

How many times have you run across this, usually by some component vendor?

Is there any way for C# to be anything BUT "Pure"? What the fyook is the point of this?

Rest my case. More later!

Google Code

Google Code is google's new twist on Sourceforge.net and it looks promising. At first blush, after only a week, there are already 89 projects just under the "C-Sharp" Section.

I checked out one using Tortoise SVN with little trouble, and I just added the Ankh SVN SCC plugin to Visual Studio 2005, as well as installing SVN locally. I"ll post more about my discoveries as I get a chance to spend more time with this.

Conspiracy Theories

I like to entertain myself a couple of times a day by visiting Digg.com. I've noticed a distinct leftward slant in the politically charged atmosphere there, and it appears to have gotten pretty bad. I'll give you an example:

There was a post with an article about the fact that the air quality after the 9/11 attack in New York was much worse than people thought. Lots of people who were nearby but who weren't victims got sick, etc.

Now, you could see it coming. This, that and the other left - wing anti-government conspiracy theorist and his brother all got in their comments about how it was the US Government that actually blew up the World Trade Center, it wasn't because of the planes that rammed into it and so on and so forth, ad-nauseum.

Folks, WHAT is your fyookin' PROBLEM? Weren't you all supposed to move to Canada when Bush got re-elected? What happened, Ann Coulter came in the middle of the night and stole your car keys?

Jeesh! If you don't like it here, have the guts to go live somewhere else, OK?