After some recent restructuring of my business (I'm now 100% owner of Pragmapool) and ongoing problems with the server that this and my other sites sit on, I'm migrating all of my sites over to Mosso. I'll probably go into why I chose them and why I'm willing to recommend them even before I've moved all of my sites over at a later date. What's relevant for today is that one more than one of those domains, the email is actually more important than the site on that domain.

With several accounts that average 2000-3000+ spam messages a day, dealing with the email on the new server didn't exactly appeal to me. Having heard about how some plenty smart people enjoyed the switch over to outsourcing their email to Google, I figured I'd give it a shot.

The thing about Gmail (and Yahoo mail and Hotmail) is that lots of large companies actually block them. When you do the contract development gig like I do, that can get in the way of actually doing your job. None of those companies block any of my domain names.

So, I followed all of the instructions for changing the MX DNS entries to point things over, set up the email accounts and was able to send and receive email. However, even when setting up webmail.example.com, the browser still gets forwarded to Google's domain.

Fortunately, Google recently added IMAP access. When you combine that IMAP access with a copy of Squirrelmail installed directly on the domain, you can use any of:

• The GMail interface that many know and love
• IMAP access using Thunderbird, Outlook, etc.
• Squirrelmail access

This weekend, I was doing a bunch of digging into how to use some of the open source ORM (Object Relational Mapping) packages out there. That process of technical research follows a pretty predictable pattern:

• do a few Google searches
• open the best results into a bunch of tabs
• read the info
• come up with a few, more detailed questions
• repeat

As that loop progresses, the questions I end up asking Google get more and more specific. By the time I've been digging for an hour or 2, the bulk of the results are starting to come from forums, mailing lists and other discussions of the technology in question.

That's when one of my pet peeves rears its head. You put a fairly detailed question into Google, get a page from a forum where someone asked your EXACT question (including most of the nuance for your specific needs) and, after a few people saying they don't know how or aren't sure, the original questioner pops back in and says, "Nevermind, I figured it out".

And that's it. Nothing else.

Particularly gnarly questions yield more than one such incident. Even worse, there are often 5 or 6 people just as frustrated, asking this person exactly HOW they figured it out. 

To me, this is an online etiquette and/or karma thing. If you go asking other people to explain how to do something, and you figure it out on your own, telling them "Nevermind" is just the first step. It is now your responsibility to explain back to the forum/mailing list/etc. what you did to figure it out. 

Sure, your solution might not work for everyone who will stumble across the discussion, but it's a whole lot better than being mocked by someone saying they *have* the answer, but haven't shared it.

Photo: Dan Zen

I make a swing past a bunch of sites like Freshmeat, C Sharp Source, CodeProject, Codeplex and Sourceforge
every week or 2, looking for new and updated C# (and PHP, etc) projects and libraries that are up to interesting stuff.

One article on CodeProject today caught my eye. The article is entitled: Generate Complete Web 2.0 Applications in Minutes. That sentiment is all over the software development industry. The Microsoft Windows Server 2008/SQL Server 2008/Visual Studio 2008 launch last week showed the attitude at several different points.

Basically, it boils down to excitement at the ability to quickly build "applications" with little more than a wizard. That exact sentiment was expressed to me multiple times at a consulting company I worked with for a while. The person in question believed that if we just used one of these magical tools, our projects would go from a couple of hundred hours down to a single day.

The problem with this whole approach to software development is not that the tools themselves aren't great or that they promise something they don't deliver. It's that they're asking a question that doesn't matter in the context it's getting asked.

That's because neither I nor any software developer that I know is collecting a paycheck or getting an invoice paid for "building applications". At least, that's not what the payment is in exchange for in economic terms. Rather, I am getting paid for *solving problems*.

And, the thing about getting paid to solve problems and magic tools that make some kinds of problems easier to solve this year than last year (which is what most of these tools actually do) is that that just changes the problems that people pay for.

When tools that do easy CRUD generation or data entry applications show up in the marketplace, that doesn't mean that software developers magically get to use those tools to only work 2 hours a week and then coast for the rest. It just changes the kinds of problems that earn developers money.

I love this chain of progress. That's because it lets me solve ever-increasingly difficult problems with the same effort. That's very cool. However, it doesn't promise easy street and it bothers me when that's what's implied by this whole attitude.

There are a lot of common patterns in data that appear over and over again. When we can recognize patterns in our reality and match them to these known and documented patterns, we can much better understand what's actually going on and

Anyone who has sat through an intro to economics course even at the high school level has spent their fair share of time drawing and looking at supply/demand curves.

Similarly, if you've ever gathered statistics on nearly anything, you've seen a bell curve.  For those who have been following the book The Long Tail and the subsequent media frenzy, power law curves are likely very familiar.

It's that very media frenzy that can be described by a graph that I'm fond of and tend to see in lots of places. It's called the hype cycle and describes how lots of things, technology in particular, go through a pattern of enthusiasm, disappointment and maturation.

What's wonderful about this curve is that once you know about it and start looking for it, it shows up all over and really puts lots of breathless technical press into perspective.

Basically, the idea of the curve is this:

1. Someone invents new technology. (Hey, here's this thing called XML)
2. Some people start using it and telling everyone how great it is. (Look what you can use XML for)
3. People start buying into the hype and looking to use the new technology EVERYWHERE they can. (XML cures cancer)
4. Some of those places are deeply inappropriate and those who didn't recognize that end up disappointed. (Umm, no it doesn't cure cancer)
5. Backlash that leaves people rejecting even valid uses.
6. Things settle down and the technology lands in its permanent niche.

The trick is that when you realize that a given technology or product is on this track, it's much easier to avoid getting caught up in it.

All of that is to explain why, when I was reading this article at Techcrunch that I laughed out loud when the graph loaded. The article is about a technology was hyped heavily last year and the article talks about whether it's demise is happening or not. However, what I found funny was that the graph was fairly close to the hype cycle.

And, for the record, I see many things in today's tech world that are teetering on the edge of falling into the trough of disillusionment at this point. Among them is that I've seen a new outcropping of backlash articles on Twitter, Lifehacking, etc. These are pretty much right on track and predictable.

Nothing to see here.

For a while now, I've had a project on the back burner for a different set of tools for RSS reading, writing and publishing. I'd like a single toolchain that lets me keep everything together in one place. I've got piles of notes, a few proof of concept projects and the start of several of the components.

Last night, when I couldn't sleep, I decided to check something off of the list that I wanted to see as a proof of concept for the Atom Publishing Client part of the toolchain: HTML Tidy cleanup to XHTML of HTML before putting it into an Atom entry document.

I currently do most of my writing for this site in Windows Live Writer. However, that's more of a compromise than an ideal choice. While I could probably hack a plugin together that would make Live Writer a more suitable long-term choice, I really want a very specific set of features that includes getting away from the XML-RPC API that all of the server-side engines Live Writer works with are based on.

So, I've been tinkering with a multi-tabbed Windows app for editing posts. The WYSIWYG tab for quick editing uses the MSHTML engine from Internet Explorer. I've looked around and unless you're willing to pony up $299 for a commercial control, that's the most reasonable choice.

However, the HTML that MSHTML spits out is horrible and really needs to be cleaned up. So, I set out to figure out how to use HTMLTidy in a C# project.

I tried to find a .NET wrapper for HTMLTidy and thought I had scored right away when I found one here. However, when I tried to use it, not even the sample code would build without errors on my development machine.

So, I dropped back to trying the COM object version. The last update to it was back in 2000 or so, but it looked like all of the features I needed were in that version, so I decided to give it a shot.

To use the TidyCOM library, you add it as a reference and insert your "using TidyCOM" statement in your class. The actual usage is fairly straightforward.

Example:

TidyObject TidyObj = new TidyObject();
TidyObj.Options.Doctype = "strict";
TidyObj.Options.DropFontTags = true;
TidyObj.Options.OutputXhtml = true;
TidyObj.Options.Indent = TidyCOM.IndentScheme.AutoIndent;
TidyObj.Options.TabSize = 2;
String CleanHTML = TidyObj.TidyMemToMem(HTML);

That code assumes that the "HTML" variable has your messy HTML in it and at the end, "CleanHTML" has your cleaned up XHTML in it.

My little multi-tabbed prototype is using a buffer object to keep the "current" HTML in it. Whenever you switch tabs, the old content is scrubbed through this code before the new tab gets updated out of the buffer. That means that whether it's the WYSIWYG tab that messes it up or you in the HTML editor, you still get valid XHTML in the eventual output.

I also extended my CleanupHTML method (that contains the above code) to scrub out the HTML header tags, body tags, etc. Since the HTML will actually end up as one part of the Atom xml file and not as a standalone HTML file, I only want the content from the editor and both MSHTML and HTML Tidy will always put that stuff back in unless you strip it out.

While I'd still like an assembly that's a little more current, this clearly does the job well enough to check this feature off of my checklist. Now, on to RESTful services on IIS with C#.