Weblog Without Honor or Humanity

University of Washington provides some of their colloquia and courses as on-line video:

• colloquia (make sure to change search criteria to see all previous talks)
• courses
• main page

In the colloquia page you can access recent talk by Google where they (supposedly - I haven’t seen it yet) announced Google tech campus in Kirkland.

Google recently launched Google SMS i.e. ability to query Google services by sending an SMS message to a specific phone number. The amount of coverage (a lot) that this new service got was way more than it really deserved. SMS-powered services already stopped being cool in most parts of the world. The only reaction that Google SMS deserves is “what took you so long”?

Now that they have google-via-SMS, the next logical step is google-via-IM-bot. Google used SMS because while it has disadvantage of being the lowest common denominator (i.e. it’s really painful to use) it’s available on almost any phone. But more and more phones have some Instant Messaging client. Google should wire their engine to IM bots on all popular networks. They already solved the hard problems, this would be insanely trivial.

While IM interface is not as good as a dedicated client could be, it would be a step up from SMS, it piggy-backs on a technology that is already quite widely used by customers, not to mention that using IM doesn’t cost a thing, compared to SMS, which might cost a thing.

And no, this isn’t a revolutionary idea. It’s so obvious that Google should have done it long time ago.

I just got spammed by rsscache.com - they want to protect me from a bandwidth usage problem that my rss feed is causing me.

There are only three problems with their business proposition.

a) I really don’t like to be spammed

b) My RSS feed doesn’t cause bandwidth problems. They are obviously trying to monetize the ‘RSS bandwidth problem’ meme circulating recently around the internet. Despite the fact that many intelligent people who actually know how RSS works demonstrated that RSS feeds will cause problems only if either the RSS generator or RSS client are broken. And that assumes that you’re actually one of the lucky few that has thousands of readers of your RSS feed that can start causing problems.

c) Their “technology” is laughably simple and doesn’t work reliably. Basically, they track who requests RSS feed by IP address. If they see another request coming from the same IP address and the feed didn’t change, they only send an empty RSS feed, hence the savings. That is trivial to implement in any RSS generating software. Except you don’t want to do that, because due to proxies, tracking by IP address is extremely unreliable and there are other well known and already implement in well-behaved clients and servers methods to solve the same problems.

And it’s so obvious that they’re selling oil-snake from their marketing copy on their web page.

Use our technology on your server and save bandwidth, and do a lot more cool stuff!

Too bad they fail to mention what exactly is included in the “lot more cool stuff” part.

all requests are stored in optimised tables for efficient response time

As opposed to un-optimised tables for non-efficient response time.

Their idea of making money is by selling their wonderful technology that can be re-implemented by 5-line perl script as “enterprise solutions”. Good luck finding people dumb enough that would actually buy it.

To help their credibility, the only information about the company you can get from their website is that they call themselves “D2Soft Technologies Inc.”, the only way to contact them is through web form, there’s at least one spelling error on the website, and they are so confident that sales of their rsscache enterprise solutions will fly that they put google adwords on their website. Hopefully the masterminds behind this operations will make enough from adwords to buy themselves a beer when they go to a bar to brainstorm why their brilliant idea flopped in the cruel market.

This one will fly through the blogspace: Google released Google desktop i.e. a desktop app that indexes the content of your hard-drive and allows to search it. My only question is: what took them so long?

Anyway, that’s great news and it seems that they did pretty good job with the implementation.

The problem is that while Google Desktop understands a decent number of documents (outlook e-mail, aol im conversations, ie web pages, text files, word/excel/powerpoint docs) it still doesn’t understand a lot of things. How about windows help files? How about pdf, postscript files? How about Thunderbird e-mail? How about gaim files? I’m sure that they’ll pregressively add support for other kinds of documents, at least those most popular ones like pdf but there are plenty of applications out there and some of them are not important enough for Google to write plugins for them.

The solution: Google should provide an interface to their indexing engine so that applications authors could provide indexing of their data to Google. That’s the only scalable solution (used in Dashboard project, I believe).

Dave Winer seems to agree.

I just started using flickr.com and I like it a lot. Here’s an idea for a feature they could implement: photo camera popularity.

Most cameras embed meta-data information in pictures e.g. camera model that was used to take the picture, time when picture was taken etc.

http://flickr.com already has a feature to show this information. What they should add is a weekly “Top cameras” stats which would show what are the most popular cameras used by peple to take pictures. I think the fairest metric would be to track cameras stats per user (as opposed e.g. to how many pictures were taken with a given camera which would tilt the stats towards what cameras are used by prolific flickr users).

It’s fun and could be valuable tool for people deciding which camera to buy.

Besides plain “all time stats” they could show trends over time and/or “hottest camera of the week/month” (doing the same stats but only on pictures taken in the last week/month to better reflect quickly changing landscape of digital photography).

Is anyone at flickr listening?

Update: apparently they do. Stewart Butterfield from ludicorp.com (creators of flickr) e-mailed me to let me know, that this feature is planned and should be available soon.

R0ck on, I say.

I’ve tested many wiki implementations. This post summaries what I consider to be best practices in wiki implementations.

WikiWords must die. To me WikiWords are incidental and harmful property of wiki implementation that is mindlessly propagated in new implementations because that’s how most other implementations work. I think I understand the reason for WikiWords. Web browser is very poor editing environment. WikiWords are a helpful shortcut for implicit links between pages. However they suffer from 2 fatal problems:

• they look ugly
• wiki software has no way to distinguish between intended implicit WikiWord (a link to another wiki page) or unintended link created just because a given word happen to look like a WikiWord (which happen often with company names)

So, implicit WikiWord links are evil. It’s not much more effort to write [A link] than it is to write ALink so WikiWords don’t help that much. Of course, using WikiWordLooking links shouldn’t be prohibited either. Just not enforced or used to create implicit links.

‘New page’ is a must. Amazingly, most wikis still force you to use this incredibly opaque and broken way of creating new pages:

• modify existing page to add a link to new page
• click on this link
• start editing new page

I wonder how many usability studies showed that this is something that an average person can figure out by themselves.
‘New page’ functionality is available in precious few implementations. It should always be there.

Some means of categorizing posts. It already exists but not always and some implementations are better than others. Personally, I would do it exactly the way labels are implemented in gmail.com. It’s a good implementation, the name “label” seems no worse than the obvious “category” and many people will be familiar with it thanks to using gmail. Stand on the shoulders of giants.

Oh, yeah, and writing in a web browser sucks. A lot. But there’s nothing that can be done about it (with the exception of dramatically enhancing web browser built-in editors or writing a desktop client with a decent editing capabilities).

This presentation by Alan Cox, famous for his work on Linux kernel, is worth propagating so I’m doing my part.

Cox doesn’t say anything new. It’s a good thing, because usually new ideas turn out to be wildly incorrect. What he does is a very nice summary of known techniques for writing better software i.e. software with less bugs. You’ll get the same (and more) by reading Code Complete 2nd ed, but it’s a nice summary of a particular topic (Code Complete covers much more, is much bigger and therefore more difficult to digest) and it doesn’t hurt to read about this stuff one more time.

Videos of this talk are also available.

One thing I don’t like is when people willy-nilly hi-jack buzz-worthy words to describe ancient practices.

A recent example is this post on social software weblog which incorrectly (imho) uses ‘podcasting’ for no reason other than podcasting is weblogger’s fad de jour.

Correct me if I’m wrong, but a ‘podcast’ is an audio version of a weblog post. What the author of the post calls ‘podcast’ is simply an audio recording of a conference talk. Yawn.

As to podcasting itself - it’ll never work (in the sense of becoming something popular the way weblogs did).

It seems so easy to invent new ways of blogging: moblogging (mobile blogging), audio blogging (podcasting), video blogging (no fancy name yet but it should be channelXblogging). Just combine two existing technologies and get excited about the possibilities. Except that it simply won’t work.

It won’t work for 2 reasons:

• much more difficult creation of content
• no actual demand for it

Despite proliferation of cheap audio and video recording devices, producing audio and video content (of decent quality) is and always will be much more difficult that producing a written word.

For one, many (a lot, I suspect) just don’t have it in them to be interesting speakers. A simple rule of elimination tells us that. In order to write something good, you just need write well. In order to do good audio recording you need to write well and speak well. There’s a reason they pay Eddie Murphy do voice-overs for a donkey in Shrek. If I did, it would sound terrible.

Second, writting is easy to improve. You can rewrite the whole thing. You can rewrite just a sentence. You can fix a typo here and there. This weblog post, for example, had 3 fairly major revisions. With audio, you either get it right the first time or spend oogles of time editing.

The real reason why audioblogging will remain a niche thing is that there’s no demand for audio since it doesn’t scale the way reading does. Using an RSS agregator I can manage to read hundreds of posts every day because I can skim and not read most of them. I can’t do that with audio.

Furthermore, audio demands attention. From my (significant) experience of listening to audio and video talks from various conferences, it’s very difficult not to get distracted while watching them. And that happens when watching top quality content. I wouldn’t hope that an average audioblog post would approach the quality of a prepared and researched talk given at a conference by a speaker of Jeff Bezos or Tim O’Reilly quality.

Podcasting - just ain’t gonna happen.

Press F2 if you’re using Pocket PC 2003 Second Edition emulator to test how your app handles changes in screen rotation.

Also, vgapocketpc.com is a site dedicated to Pocket PC apps that work well in VGA (640×480) resolution.

I’ve released version 0.3 of scdiff. The fixes in this version:

• Eli Tucker fixed a bug handling directories in cvs
• no longer crash when handling svn remove. Still, handling of deleting files
  is far from perfect (currently they are silently ignored while we should show apropriate diff)
• properly handle file names with spaces. Fix suggested by Raman Gupta