Journal/9 Thermidor CCXIV from Evan Prodromou

Mark Jaroski asked if I had any recommendations for Web hosting. I thought I'd share them here.

Mostly I find Web hosting really difficult to evaluate -- there are just too many options. It's a really competitive business, and the hosting companies have SEO-saturated the Web hosting keyword at Google. On top of that, there are a ton of fake "hosting comparison" sites -- really just fronts for the bottom-feeders of hosting.

When you get to even a good hosting company's Web site, there'll be a lot of flashing lights and gewgaws. A lot of companies try to sell you add-on features you don't need, and they'll have abusive UI to get you to click on the wrong thing, like:

 You're eligible for a big discount on our
 blogging software! Only $3.95 a month! 
 [Continue] Cancel

... where the "Continue" button adds the add-on to your account and "Cancel" is what you need to go on with your order. I think this is borderline fraud, but as far as I know nobody's been shut down or fined for it.

For contrast, there are a lot of really good community-oriented and Open Source-friendly hosting services out there, like Montreal's Koumbit. They'll usually be able to devote more time and energy to individuals' technical needs. Often, though, small companies and community groups can't get the same economy of scale and thus price level to compete with the big guys.

Of course, what you usually trade away for that $0.75 a month is any customer service or friendliness or control of your own site. The big guys are organized around selling hard to inexperienced people on price, then ignoring their requests for help and treating them like idiots for asking until they go away. Getting help with real problems like server downtime or misbehaviour can be as humiliating as having someone explain what "Cut", "Copy", and "Paste" mean, and probably get you as many over-the-phone eye roll pauses. "My Web site is down!" <eye roll> "Did your AOL Chat window get in front of your browser window, sir?"

I think the best option for people is to look around, find a group or company that has a price you can live with and business practices that don't turn your stomach, and give them a try. Make frequent local backups of your site, and be ready to leave if you need to.


Dumb Contest

Julien has started a dumb bug reports contest (you be the judge of what "dumb" applies to here). What's the point? I guess if it catches on we can humiliate Debian users and keep them from filing bug reports at all. And as we all know, no bug reports means no bugs, right?

Being abusive towards users has never helped a project improve the quality of its software. Our bug tracking system is one of the things that's made Debian a top-tier operating system. Making fun of Debian users for using it is a very bad idea.


Yay Akron

The Akron Beacon Journal has an article about suggested Akron-related topics to add to Wikipedia. That seems like a great idea.



Douglas Self has some cool items in his Museum of Retro Technology about old technology -- like this rocket bicycle and this gyro-stabilized monorail. Thanks to Nick Moffitt for the links, even though he probably cribbed them from somewhere lame like Slashdot or Boing Boing.



So, I have two blog items about technical support people looking down on those who are reporting problems. And I was thinking how much I work to gain the respect of technical support people so they'll listen to my problems when I have to make a phone call. As little as I like it, I find myself working to qualify to get my questions answered and my problems fixed.

So I wonder: what if there were some kind of standardized computer user certification? You could take a series of increasingly-harder tests at some training centre, and you'd give your certification level (or -- better -- your standardized identification number) when you register software or hardware or when you report a bug. People will then know that when you say, "I think postfix isn't accepting connections!", you might actually have a point.


JAM on it

Maj, of course, was the one who pointed me to the page for a new Wiki engine in development. Ho-hum, I know... there's already too many wiki engines.

But this one is interesting in that it aims to be MediaWiki compatible and run in a Java Servlet container. That seems like a killer combination for those people who want "the wiki that Wikipedia uses" but with an "enterprise-strength" Web technology.

I've only tried the software a little bit, but it definitely looks like it's already more featureful than 70% of Wiki engines. Taking MW as a model is a great idea for a new Wiki engine -- it's an extremely featureful wiki engine that "fits well in the hand" of writers and users. Already the use of images and the special support pages look good on JAMWiki. And the integration of lucene means an excellent search engine -- something MediaWiki lacks out of the box. The Roadmap looks to have some good plans in the future.

Anyways, Maj likes JAMWiki since JAM is MAJ backwards. I can't tell you what to make of that, though. What I do know is that the project needs a logo real bad.


Ajax in 10 weeks

So, AJAX is no longer as bonerific a word as it was six months ago, but it's still pretty hot. I mean, we've all stopped nattering about how fantabulous Ajaxical UI is, and just started writing code to make it work. It seems like nobody even uses "Ajax" and "Web 2.0" as synonyms anymore (well... I guess only the people who still call it "CGI/PERL".)

But I was interested to see when I was looking for the Java Servlets link above that Sun is part of the cryptic Open Ajax Alliance. They've got an Ajax project incubating called jMaki to integrate Javascript programming on the server and on the client. Neato, say I.

Most interesting was an external link to a 10-Week Free AJAX Programming Online Course. Starts August 4th, seems like a nice self-training tool.


Stuck in ol' CGI again

So, I've been getting some non-deterministic 500 errors from WiLiKi, and I'm starting to think they're concurrency problems with searching the database the WiLiKi pages are stored in. I also think there may be a FastCGI tie-in, so I've rolled-back to CGI for a while to see if it cuts down on the errors.

Annoying, indeed.