Archive for June, 2004

Which encoding?

Tuesday, June 29th, 2004

All of them. I like this approach, and my ripping will probably do this from now on. Saves me trying to figure out all the encoding choices at rip time–I can have large AND small files, and easily apply whatever encoders or listening experience I have tomorrow.

They’re not dead yet…

Tuesday, June 29th, 2004

Something interesting from Sun: their looking glass 3D desktop project. There are some screenshots and a demo video.

This is a major break in desktop presentation, but will it be more than a toy? If I have 30 windows open (as I often do) will I be better off with them on edge than I am with my virtual desktop manager? I was reminded of the greek memorization technique where you physically place stuff in a personal, well-developed mental space like a house that you can move through. What if your 2D desktop were a similar 3D space personalized in whatever way you wanted (or a collection of these 3D profiles)? While the icons and windows were 3D, the desktop itself was conspicuously not, aside from some ability to “panorame” around a bit; why not a more 3D-navigable desktop?

It seems to be potentially a big deal, which brings me to another reaction I had to the demo (obvious, and the Sun presenter bludgeoned us with it of course): wouldn’t we see a lot more innovation with something like this from the open communities, rather than from a single very large company (albeit with enormous resources)? This is all built on java and linux (well, solaris too if you want). Not yet open source, but from the project FAQ:

Sun believes that tapping into the creative and open community of people working on Java will drive innovation. We are evaluating the role of open source development for this project.

Postscript: Sun will be GPL’ing looking glass today. Let’s see where it goes.

Makes the beautiful share with the software of Microsoft

Tuesday, June 29th, 2004

In La Libération today, I learn that MS is concerned about losing the city of Paris (french). Last year, despite very steep discounts and a personal visit from Ballmer, Munich’s 14 000 computers started the migration to Linux. Now Paris is waiting for the results of a study being done by Unilog (who also did the Munich deal), launched by Delanoë in October 2003.

The article suggests Paris is more interested in negotiating down the cost, rather than really making the jump. And indeed, the quote for the 15 000 seats has already fallen almost 60%, from 13,27M € to 5,65M €. Still about 375 € per PC.

Also, it seems the Munich project is in trouble:

But according to Computerwoche there is not enough money and technical difficulties may result in stalling of the LiMux Project. In particular, smaller software vendors seem to be unable to migrate Munich to Linux, simply because they lack open source knowledge.

By the way, just how well does babelfish translate these days? This chunk is not too flattering:

La bataille autour de l’informatique de la Ville remonte à l’arrivée de l’équipe Delanoë à la mairie. Elle y trouve une informatique «vétuste», indique-t-on au cabinet de François Dagnaud, adjoint chargé de l’administration générale. Un nouveau schéma directeur est mis à l’étude pour moderniser le parc qui, à l’instar de la plupart des administrations et entreprises, fait la part belle aux logiciels de Microsoft.

becomes

The battle around l informatic of the City goes up with l’arrivée of l’équipe Delanoë to the town hall. It finds there a data processing “decayed”, indicates one to the cabinet of François Dagnaud, assistant charged with general l administration. A new directing diagram is put at l’étude to modernize the park which, with l’instar of the majority of the administrations and companies, makes the beautiful share with the software of Microsoft.

Strange that it can’t get simple words: arrival, team, study. And the apostrophe seems to cause a lot of trouble, e.g. it understands “informatique” the first time, but not the second.

David Chappell blogging and bpm

Monday, June 28th, 2004

Stumbled on to David Chappell’s blog (he of MS tech fame, not the Sonic messaging guy). His 40.000′ view of .NET was just exactly the entry I needed when diving into All That Stuff last year.

He’s posted a decent slideshow (pdf) of BizTalk 2004, stating:

I believe that as integration morphs into business process management, BizTalk is changing from an edge technology into one that’s much more central for .NET-oriented developers.

Earlier, he argued for careful naming of this new platform, emphasizing ’server’ over ’system’. Anyone arguing the importance of names will usually make me smile in appreciation.

And much earlier, in January, only his 2nd or 3rd blog entry, he restated Moore’s Law in a dramatic way:

My favorite way of expressing Moore’s Law, one that I think better captures the extraordinary impact this rate of change implies, is the realization that we’ll make as much progress in processor speed in the next year and a half as we’ve made in the entire history of computing to date. Who can predict the effect of this level of change? Answer: nobody.

raid

Monday, June 21st, 2004

slashdot had a thread on choosing raid; buried within was a decent overview to the different raid types.

The lyf so short, the craft so long to lerne

Sunday, June 20th, 2004

I stumbled across a couple of old posts from Bruce Eckel, and especially appreciate how much experience he brings to the topics, and how reasonable his tone is, in contrast to some of the (un)checked exception debate, for example. The first is one of a handful of things I just read advocating unchecked exceptions, as is used in C#. For Eckel, someone who’s been looking at exceptions for an awful lot of years, the light went on after using a language with exceptions, but without checked exceptions:

When I started using Python, all the exceptions appeared, none were accidentally “disappeared.” If you want to catch an exception, you can, but you aren’t forced to write reams of code all the time just to be passing the exceptions around. They go up to where you want to catch them, or they go all the way out if you forget (and thus they remind you) but they don’t vanish, which is the worst of all possible cases [emphasis mine]. I now believe that checked exceptions encourage people to make them vanish. Plus they make much less readable code.

Here’s an entertaining illustration from Heinz Kabutz:

I enjoyed using Together/J, even though it was rather memory hungry. Instead of starting with 512MB as default maximum old generation memory size, I set it to only use 92MB. This made Together work faster and save resources. However, occasionally random threads would simply die, so you could perhaps not print anymore or some other functionality would vanish.

Kabutz’s article also has a good discussion of how java 1.5 helps you catch all unhandled exceptions. And it introduced me to the cool java api diff tool here.

My own experience with exceptions has been one of periodic enlightenments punctuated by sharp realizations that I don’t completely get it yet. I learned SmallTalk and CORBA at the same time, and after getting burned by uncaught exceptions killing worker threads, I got in the habit of wrapping all remote calls and remote call implementations in top-level catches. When I came to java, it became more complicated: UserExceptions were checked but SystemExceptions were not. I slowly grew to appreciate this, but my top-level catching was still swallowing a lot of exceptions, and/or I was spending a ton of time how far up the stack to carry my checked ones. Then I started thinking of RuntimeExceptions as “bugs” or things I didn’t want to catch. Finally a useful rule about what to (not)catch! Except for the SystemException special case, uncheckeds were bugs, not to be caught.

Then I had a subsystem very vulnerable to bad data: I needed a ton of positional string parsing (and therefore RTE handling code), and it was far simpler to take a best-effort approach and swallow all those RTEs at the top. Simple success or failure, and I couldn’t do anything about the badly formatted data anyway. Ah, RTE=bug but with some more intentional special cases, because sometimes it’s so damn much more productive.

Okay, now it’s not such a big step to using RTE (unchecked) any old time, for productivity reasons, because we will find all the problems at runtime anyway, and we’re much less likely to swallow. The tests are key: TDD makes deferral to runtime a feedback loop almost as tight as the compiler.

The second Eckel posting I’m blogging is very related: his emerging preference for strong testing rather than strong typing. Huge experience in C++/Java, but some personal experience with high-productivity, low-problem Python systems has caused him to reconsider a very basic, long-held assumption. Here he makes an analogy to the productivity boost the compiler brought us:

It’s very much like going from old C to C++. Suddenly, the compiler was performing many more tests for you and your code was getting right, faster. But those syntax tests can only go so far. The compiler cannot know how you expect the program to behave, so you must “extend” the compiler by adding unit tests (regardless of the language you’re using). If you do this, you can make sweeping changes (refactoring code or modifying design) in a rapid manner because you know that your suite of tests will back you up, and immediately fail if there’s a problem - just like a compilation fails when there’s a syntax problem.

What will the post-TDD programming shift bring? I want Eckel’s posting where he says “It’s very much like going from old strong-typed languages to weak-typed, test-driven development. Suddenly, your tests were catching all your bugs as fast as you wrote your code. But those tests can only go so far. Now, …”

Oh please God, let it be ready for primetime…

Saturday, June 19th, 2004

Signed up today (well, tomorrow, according to system timestamp–guess that’s Russia) for resharper EAP at intellij’s confluence community site. VS.NET has been a major disappointment since IDEA; I can’t wait for nav, dead-code graying, and at least the push-it-around-and-rename-it refactoring stuff. I’m the proud inheritor of a 4000-line C# class that needs some help bad.

No, I mean I’ve *really* just worked up a demo

Saturday, June 19th, 2004

Those tired of managers seeing demos and assuming the thing’s ’bout done can finally make it look like it was just thrown up, using a napkin look and feel. Here it is in action, for the java webstart swingset app.

(via TW Alan Francis’ blog)

Cringely on blogs

Sunday, June 13th, 2004

Cringely has something to say about blogs. He places it in a long, celebrated history of new media, all sharing a few things in common: it takes about 30 years for new media to find its ultimate value, and during that time, it’s mostly in the hands of amateurs–people who can evolve the idea because they aren’t constrained by the need to make money on it.

Cringely denies his column is a blog, and doesn’t seem to enthusiastic about blogs either:

If I write anything really newsworthy, which I like to think that I do from time to time, the only way Google News will show it is if one of their 4500 REAL news sites mentions me. Otherwise, I don’t exist, or more properly I exist only in a blogosphere that I, in turn, refuse to acknowledge.

I’ve never thought of his column as a blog, but I do keep looking for an RSS feed.

But, he thinks that Joe Reger may be on to something. Reger sees weblogs as having a personal nostalgia-provoking value, supplementing our memories, but maybe more interestingly, he sees the potential for data mining–finding correlations between eating habits and workout performance, for example. I have to admit I was unimpressed with the site aesthetics and the software implementation, and kept thinking this is what happens when you mix Tony Robbins with someone with a modicum of technological awareness. I’m also sceptical about how this much data would be captured and how the analysis models would be developed. I’m disappointed that Cringely didn’t find a more interesting application of blog, though I appreciate that he reminds us how long it takes for new technologies to settle into their final form.