I was reading a Slashdot article about Google reaching its apex, and I agree in some ways - it’s hard to imagine where Google can go from here. I’ve been disappointed recently by some of Google’s products. GoogleTalk is definitely subpar, and while Google’s Desktop Search was a great first, MSN Desktop Search eclipsed it (I haven’t tried Google’s v2.0 yet). Orkut hasn’t made any waves either.

On the other hand, GMail took me completely by surprise. I regret not pestering people for an invitation sooner. The invitation mechanism itself was incredibly brilliant; at a stroke preventing the Slashdot effect, preventing automated signup, generating buzz, logging useful networking information, etc. Google’s original search algorithm of using the links between webpages was obviously a star, too. In both cases, Google thought of ways to use natural human behaviour to their advantage, using human minds to do the “hard” work, and computers to put it all together.

The final deciding point for me is that Google has a lot of really smart people. Not just PhD holders - that’s only proof of dedication, concentration, and academic “smarts”, though sometimes correlated with useful “smarts”. Google’s culture also seems to be more freewheeling and open than Microsoft, another place with a lot of smart people.

Have you ever had a discussion with others (one or more), where the discussion sparked idea after idea that would never have appeared while separate? That’s a great thing about working with smart people who can communicate. Unfortunately, as you add more and more people, little things creep in, diminishing returns appears in the form of politics (in its various guises).

From what I can see of Google, that hasn’t set in yet. There hasn’t been time for people to rise through the ranks and carve out tiny kingdoms, for seniority to appear to discard good junior ideas with the bad ones. That’s why I still believe that Google has more to go: they appear to have the people, and they appear to have a culture where these people can collaborate on problems and ideas that would never get done alone.

While no secret, it did take some effort to dig up the solution. One drawback of using Subversion is the smaller amount of information and anecdotes available, compared to older products like CVS.

I accidentally committed my changes without a log message. Silly me, click, click, oops.

After due diligence in Google, the Subversion Red-Bean docs taught me that there is a class of properties, like svn:log, that are special.

Some time with svn help propedit showed me that the form I wanted was svn propedit svn:log --revprop -r# PATH.

The error message from that, asking to “define a pre-revprop-change hook”, led me back to Google, and to eventually find that every Subversion repository has a hooks directory that initially carries skeleton versions of the hooks. Copying pre-revprop-change.tmpl to pre-revprop-change (Linux box) and chmod u+x was the last stretch to filling in that gaping hole that I had left in the logs.

All in all pretty painless. If I had been trying to modify another special revision property (e.g. svn:author), I would have had to modify the hook to exit 0 (i.e. exit without error) for properties other than just svn:log.

The last struggle was deciding whether this blog entry qualified as “tinkering” or “development”. Let’s call it “development”, since I think some developers would want to know how to correct that embarassing comment broadcast to the commit mailing list.

I haven’t posted much in this blog recently, which is focused on what I do and learn in computer technology. I can attribute that to three reasons:

• My day job involves almost no coding. I read a lot about software and technology, but it’s difficult to post about results from those endeavours. The material is all public, and what I end up writing from that research is technically confidential.
• My night job, while is coding, is not particularly difficult or novel coding, though it is providing a new solution to a very real problem. The coding’s hard only because of the short amount of time I can spend on it.
• Natural variation in lifestyle. As much as I enjoy computers, I am loathe to say “no” to friends calling on me, either in need or for company. That’s a choice, and one I’m happy to take.

My day job involves some human issues as it pertains to technology, however, so perhaps I’ll write about the frame of mind and intent I use when doing that. I’ll have to be careful not to slip and say something inappropriately specific, though

When I first started hosting my own services in the ‘ol days of university, it was out of frustration with existing service levels. The campus gateway to the outside world would go down periodically, the free webmail services took hours to deliver email, hooking up the Internet cable to someone’s Windows box to do the sharing wasn’t reliable, etc.

So I sallied into the world of Linux I’d heard about. IIRC, I started with RedHat 5. Many man pages, web tutorials, and servers later, I ran my own email server, web server, play server, etc.

As the years progressed though, I’ve noticed:

• I’d rather buy a hardware router than go through the hassle of setting up iptables, even if the router gives me less fancy rules.
• I like gmail’s search, capacity, and reliability enough to give webmail another go, even if I can’t use mutt or do any fancy email processing or bouncing.
• Bloglines’ organizational structure and reliability seems “good enough” to give up running my own server based aggregator.

Am I getting lazy? Less free time? Held expectations constant while technology progressed? Who can say… I was even willing to give up vi (gvim) for a “good enough” IDE that finally appeared (Eclipse 2.1+), though thankfully I cheated that tradeoff thanks to a viPlugin for Eclipse.

Some other stuff I’d like to get off my desktop and into “the cloud”:

• Outlook (calendar, contacts, tasks). I use Plaxo, but it’s not quite the same experience.
• My music collection. This is just a function of cheap, high quantity storage space I guess. If the RIAA cooperated, one could save a lot of space by keeping single copies of songs and sharing them out, though.
• A multi-protocol IM client. With at least a half-decent UI, please.

Since I work with software, what I should be doing is taking the initiative and doing it myself. Alas, that kind of prolonged drive is hard to come by, and [for a mandatory excuse] I’m already embroiled in a software project already.

In the course of developing for the Coconut project (the software project I do on the side), occasionally an intermittent bug that isn’t reproducible shows up. This sets off concurrency warning bells. Doing a visual inspection for concurrency issues is one option, but not very appealing. Other than the continuous burden of review cycles for the lifetime of the project and the danger of missing something, the problem also seems like a well defined, regular task that programs are meant for.

I tried out Lint4j and Jlint, but they weren’t quite what I was looking for. They seem to focus on problems that affect a small scope (e.g. bad programming stye, stupid mistakes, and concurrency problems that are tipped off by the use of the synchronized keyword) rather than the large scale cross-system check I was hoping for.

I also tried out Java Pathfinder, software written by NASA and subsequently released as open source. The examples I read regarded concurrency problems, and the product itself was described as an entire VM that simulates all possible states. I was excited to try this one out and had high hopes. Alas, pointing this product at my main() threw an immediate exception (an invalid constant while calling a createInstruction(), IIRC). The examples included in the package seemed fairly tame in basic concept, too, although some were quite lengthy. It only went open in 2005, so given some time it’ll mature, or at least I’ll be able to usefully search about my problems.

I guess I’m asking for too much: a program to verify that my servlet app is thread-safe, despite any number of HTTP requests and interleaving of operations. Combined with the number of library dependencies being used, it’s not surprising that the tools are either too narrow in scope or have problem with some unexpected condition.

I’ll still look at integrating these tools, as well as some software metric calculations. They’re quite valuable, though it would have been better to involve the checks earlier in the project rather than getting a whole bunch of problems/warnings by putting it in now. For now, however, I’ll have to go with runtime verification the old fashioned way, using HttpUnit and lots of threads.

I did encounter this paper on static code checking, though. I’ll have to read that in more depth later.