David Van Couvering 's Blog

January 2007 Archives

Google plans to take over the Internet

Robert X. Cringely is one of my favorite technical bloggers. He blogs once a week (he calls it an article). Each of his "articles" are fun, smart, well-informed and very enlightening.

Last week he wrote an astounding article where he observed that Google is building data center after data center and took this to its logical conclusion: Google plans to take over the Internet (OK, so I gloss over the details, but read his article).

This week he puts together some ideas on how to compete. Great stuff. I'm sure Google will "neither confirm nor deny" all of it. I know I would if I were them.

Wiki Madness

I have loved Wikis for many years. I first discovered them back in 2000 and tried to convince the engineering team I was working with at the time to start using them. They would have nothing of it. As a matter of fact, I was working with Francois Orsini back then, and I particularly remember him scoffing at it and not understanding the point.

Anyway, as more and more Wiki providers have popped up, various teams I have worked with have adopted one or the other. Within Sun I think we use at least three different Wiki providers across various product groups.

What is amazing is that each one of these has decided they want to define the Wiki format differently. It's just maddening. Right now it's particularly painful because the tools internal Wiki uses Twiki and the external NetBeans wiki uses JSPWiki. When I was offline I wrote an entire page using the wrong format, and now I am spending a tedious half an hour that seems like two hours reformatting the whole thing.

What I want to know is, how could something so popular have absolutely no standard? This is actually not just an inconvenience, it's crucial for export/import that gives you data portability. Does anyone know if a standard is getting defined?

As I write this, I realize there must be somebody who got as tired of this as I did and wrote a translation utility for Wiki formats. Time to do some Googling.

What? Java is better than AJAX on the client?

Sacre bleu! A Java applet - ThinkFree - wins Computerworld's award for best online office suite? What is this world coming to? I thought we had dismissed Java on the client long ago?

Quote from ThinkFree CEO T. J. Kang:

Currently the best way to offer advanced Web Office functionality is to utilize Java. Ajax doesn’t cut it when it comes to advanced functionality. Although in theory you can build it in Ajax, the resulting code will be so big that it will take ages to download stuff and slow the system considerably. So Java is, much more efficient than Ajax when it comes to implementing Microsoft Office-like functionality.

Well, I never. Everyone talks about how fast AJAX is, but here it is taking longer to download than Java for complex applications. Maybe I should check this Java thing out... :)

P.S. Thanks to Chris Adamson and Hari Gottapati for bringing this to my attention. Pretty cool.

P.P.S - Google is in talks to purchase ThinkFree?

Unexpected consequences

When I lost my job at a startup that imploded (another story for another day), I did some serious job searching. This was in 2001, at a time when jobs were very sparse indeed -- I had some friends out of work for over a year; others took up jobs selling shoes or running movie projectors at the local cinema. I posted my resume at many different sites. Somebody warned me at the time this was a bad idea, but I really wanted to find work.

This still comes back to haunt me. Here's an excerpt from an email I got today. I think I must have mentioned back in 2001 that I liked to work from home...

Welcome To Stanford Executive Recruitment
 
Thank you for your interest and inquiring about telecommuting job positions
with us in the past. We have pre-selected you to fill various client positions.
We have you on our independent contractor available agent list to contact you
for any new project notifications per your request.

Job Type : Entry to Mid Level Classification

Typing Clerk Position:

Customer names, phone numbers, addresses, reason of visit, comments, time of
visit, and any pertinent information that will help the client understand the
details about the customer needs in order to retrieve records faster.

Job Requirements:

Typing Speed of 35 - 40 wpm or greater

Must be able to toggle in between screens.

Yipes, data entry! I did that back in the eighties. Even then I knew how to toggle between screens and typed around 75 WPM. Just reading this took me back to those days.

One of my favorites was working for my Dad and Micropaleontology Press, then part of the American Museum of Natural History but now an independent entity. I was entering in thousands of microfossil species names from a paper catalog into their database. I loved it because the names were so incredibly long and complex, and it required complete focus. Names like "Lagena Semistrata" and "Syracosphaera" would fly off my fingers.

By the way, these microfossils can be quite beautiful. If you want to see some of them, my Dad has posted some photos of them on his Flickr site. Gorgeous!

Data portability - Web 2.0 companies just don't get it

I'm tooling around with a Wiki site in my spare time, and I'm trying to find the best Wiki solution out there. I am currently using Twiki, and I really like it. The problem is I have to host it and maintain it, and although it's very powerful, it's not that approachable to newbies (although it probably could be with a lot of tweaking on my part).

So I've been looking at other sites. JotSpot was OK, but not great. Then I read about Wetpaint on Technorati, and it looked really nice.

But then I sent an email with the standard question: do I have the freedom to leave? Specifically, I sent the following email:

I really like WetPaint. I have one major concern, however. It is important to me that wherever I place my content, I have the "freedom to leave." This means it is easy for me to export my content. I am concerned about content stored in some proprietary, closed format, which can "disappear" if the company disappears, or which I can't take with me if the company is acquired or changes business models and I no longer want to work with you. What policies and technologies do you have in place that give me the freedom to leave?

I don't want to pick on Wetpaint, they provide an excellent service, and this is a problem that is very very common among Web 2.0 companies. But here was their response. This is the kind of "they just don't get it" that I see a lot of:

Thanks for contacting Wetpaint. Wetpaint does not have a specific feature built in that is used for importing or exporting at this time, but content on Wetpaint sites is easily copied and pasted to a new location at anytime. Wetpaint sites are designed to be used as a collaborative tool which is constantly evolving and changing. This aspect of the technology doesn’t really mesh with the traditional idea of importing/exporting as is used with more static types of content.

Cut and paste? That's how I get my content out? Well, sighing because I really like Wetpaint, I responded:

If I have a Wetpaint Wiki site with say 500 pages, I don't think cut-and-paste is going to "cut" it.

Just because a site is highly interactive and collaborative doesn't mean that potentially some day the community may decide they want to migrate to a different solution. Currently Wetpaint "locks you in" by not having an export function. Until it does I'm sorry to say I am not willing to put my content into it, because it's my content, and I want to be able to get it back out.

Just as an example of the problems you can get into by placing trust for your content under a certain provider, take a look at this blog on Technorati about the experience of a long-time JotSpot customer when JotSpot was acquired by Google (scary that this blog was deleted). I don't know about whether this particular comment is "viable" or not, but the point is, this could happen to you. The jilted JotSpot customer says "Relying on web hosted application services is much more dangerous than I ever would have assumed." That says it in a nutshell!

This is a real problem, one that Tim O'Reilly also talks about quite a bit - he calls it the need for "open data." I am not sure how to make this happen, but we need standard data formats and import/export support for all the various content types that are getting published out there. There is some hope - the blogging world is starting to recognize this need. I know that Dave Johnson of Roller is aware of this issue and is working on it (he mentions this in this podcast - I know, I was there.

As another good sign of slowly raising awareness, when I searched for Simon Phipp's blog on the freedom to leave, I ran into this announcement by BlogBridge, saying they are committed to supporting bug-free OPML export and import for blog subscriptions. Good for them!

If I were a business, I would be very very cautious about placing my business content in any of these Web 2.0 sites that don't give me freedom to leave. Look carefully, see what service agreement is there for "export control," and don't accept hand-wavy answers like "use cut and paste". These companies need to understand and honor that this is our content and should be treated with respect, care, and openness.

Content Libre!

P.S. java.net: how do I export my blog content, anyway? Gads...

I love open source

I just love open source. Before Derby, all the projects I worked on were closed source, and if you wanted to get something done, you had to scrounge and beg for resources, and usually you didn't get it. All the cool ideas you had to improve the product had to play second fiddle to other priorities.

With Derby, within Sun, it's been the same way. We only have so many resources, and we have to make difficult choices. But because Derby is open source, and the community is active, fairly regularly these things show up that are like Christmas presents, except it can happen at any time of the year.

Last year, somebody dropped in support for DESCRIBE TABLE, something we all wanted but didn't have time for. Then there is XML support, which is valuable, but we just don't have people to work on it. This week, a couple of students sent a link to the derby-dev alias with the results of their project in their database class at NTNU, the Norwegian University of Science and Technology. They produced an incredibly well-done analysis of the performance bottlenecks for Derby when running in SMP environments. They used DTrace for Java and identified key issues and suggestions for improvement, and are even proposing that for their next project they actually go in an fix some of these issues.

Can you imagine someone doing that for Oracle or DB2? Instead, those guys have to hire performance engineers to do all the work. We get it for free. Sure, it's a little embarassing to see how poorly Derby scales on these systems, but now they've shown us how to fix it.

Take a look. The introduction to database concepts at the beginning is worth your time. Anyone developing against or deploying databases should understand some of these concepts.

Thanks, Anders and Petr!

Article on synchronizing local storage

Back in October I mentioned a cool little app I wrote that allows you to manage a calendar of events offline and then synchronized with Google Calendar.

At the time I promised more details and asked you to watch this space. Well, I finally have something for you to look at. It took so long because I decided it was better to produce as an article than a blog, and then I had to go through the process of getting it to meet the requirements of an article. But I think the end result is pretty good.

The article was published today, so take a look. I attempt to describe a general model and set of principles for synchronizing web client storage to a central store, with a specific example of LocalCalendar.

The code is available for download with the article. It's also checked in to the Apache Derby codeline as a demo, so if you like this and find things to fix or improve, you can submit your patches back to the Derby team.

Happy Syncing!

My First Week at NetBeans

I have been spending the past few weeks doing a fairly random walk through the NetBeans code tree, documentation, and web pages (internal and external). For the most part it has been like wandering through a completely foreign city (Prague?) with just a nominal understanding of the language and a couple of maps.

However, I am starting to get some context and learning the lay of the land. I have had good meetings with the database folks and there may be a good chunk for me to work on for Netbeans 6. I need to do this, need to get my hands dirty and learn this code base, or I really won't have a leg to stand on when I'm thinking about the larger picture of what we're doing here.

In terms of the larger picture - well, I have some ideas, but I'm new to this space, and I think I need to discuss these ideas internally and get them exposed to the cold hard light of "yeah we already thought of that but here's why it won't work," "we already do that," and "great idea, but have you thought of this?" before I even think about blabbing about them here.

This work is licensed under a Creative Commons License.