Buzzword Compliance Library

Posted on July 24, 2007 by William Woody

So I’m looking at someone else’s code, and they make extensive use of a particular jar file. Time to poke around and figure out what that jar file is.

To paraphrase the info page, which should tell me what the library provides:

FooLib is an enterprise-class open source library to help deploy and integrate services in a service-oriented architecture. FooLib can help you decrease development complexity while improving end-user experience by coordinating business processes with unparalleled flexibility and reduce overall total cost of ownership.

In other words, FooLib is a module which helps my code maintain buzz-word compliance with most IT pointy-haired managers.

*sigh*

WTF?!?

Posted on July 23, 2007 by William Woody

Java’s Exceptions are an extremely powerful way to figure out what went wrong. Too bad many Java programmers go out of their way to hide what went wrong from their fellow developers.

If you’ve got to recast an exception:

try {
    doThing();
}
catch (RandomLocalException e) {
    throw new OuterException("Some mysterious message");
}

At least have the decency to write

try {
    doThing();
}
catch (RandomLocalException e) {
    OuterException oute = new OuterException("Some mysterious message");
    oute.initCause(e);
    throw oute;
}

That way I don’t have to chase down the rabbit hole that is doThing() to find out why it barfed.

Overheard in a meeting yesterday.

Posted on July 18, 2007 by William Woody

“Why would you want to work on user interface? I mean, it doesn’t take a rocket scientist to build a user interface.”

Which is why most user interfaces suck: because while in fact it doesn’t take a rocket scientist to build a user interface, it does take one to build a good user interface.

Meanwhile, out in the real world, the iPhone continues to sell extremely well despite having fewer features than all those “better” phones.

A realization about web companies.

Posted on July 17, 2007 by William Woody

Web sites are like iceburgs: what you see only represents 10% of the actual work. And the majority of the work looks more like internal business application development in an IT department for a non-computer software related company–which it is: the 90% includes things like fulfillment, customer service, complaint tracking and auditing.

Which is why working at a place like Yahoo!, aside from the whole ‘college dorm’ feel of the place, is really no different than working for Wells Fargo or General Electric or Disney’s IT group. The work is essentially the same.

And it’s why so many developers are excited about AJAX: it represents the ability to do desktop development within the context of a web site. That is, it represents the ability to do something more meaningful with a web site than the sort of development you’d see in an IT shop like Wells Fargo–even though by and large, most web sites do not need to be “AJAXified.”

Things that irritate me.

Posted on July 13, 2007 by William Woody

So I’m looking through some source code and I come across an unsatisfied reference to a library. The import package name starts with ‘org.lwes’. Custom and convention says that when you name a package in Java, you use your domain name to your company or organization, but reverse it: thus, stuff I write for chaosinmotion.com goes into the top level package com.chaosinmotion. If I’m extra tricky (but I’m not) I would create a section on my web page for each component: thus, com.chaosinmotion.UITools would be documented at http://UITools.chaosinmotion.com.

So I go to http://lwes.org, thinking I’d encounter some package maintainer for some random Java tools package–only to be greeted with the message “Living Water International – El Salvador’s web page has moved.”

Given that the code appears to be an event system (I’d guess ‘lwes’ is “Light Weight Event System”), I wasn’t expecting to encounter the Living Waters-El Salvador web site. Grrrrrrr…

The failure of Silicon Valley.

Posted on June 13, 2007 by William Woody

Working for Yahoo! in Burbank, one of the first things that happened to me was the suggestion that I should be transfered to another team–and moved to Silicon Valley. There appears to be an overall theme here at Yahoo! which is not just a problem with Y!, but with other Silicon Valley-based software companies as well: and that is that as the Mecca of high-tech, all really good engineers should eventually move up to Silicon Valley to better serve their corporate masters.

I think this is a cultural assumption which is both incorrect and dangerous.

Sure, it would be very easy for me to land a job and advance very quickly within the hierarchy of any Silicon Valley company if I were not based in Los Angeles. I have no doubt as to my own programming abilities or architectural or (*shudder*) management abilities. And I know that there are so many opportunities up in San Jose which do not exist in Glendale.

Yet–I think this assumption is an extremely dangerous one for companies such as Yahoo! or Google to pursue.

First, a quick background about Yahoo!. Search marketing for Yahoo! was originally invented by a company called Overlook (formerly Goto.com), which was founded and built in Southern California prior to its acquisition by Yahoo! several years ago. Search marketing is essentially those little ads you see on Yahoo!’s search results page or Google’s search results page–and it is the primary cash cow for both companies. (A smaller cash cow is “Content Match”, the little box to the left or right of articles on places such as CNN which provide ads that appear related to the content of the article. But Search Marketing is the big cash cow, accounting for tens of billions of dollars overall.)

There is something deeply ironic to me that despite the huge brains in Silicon Valley, effective monitization of internet ads was done–in Los Angeles. (Google’s Ad Sense product was not built in-house but was also acquired.) Yet–and here’s the meat of my rant–even though the technology was invented down south, the prevailing attitude of the Silicon Valley crowd is that people in Silicon Valley are intrinsically more intelligent–perhaps around 30 IQ points–than their Lala land counterparts. And, of course, if you are bright, you clearly should move up to the City By The Bay where you can then help with the Internet Revolution.

This is a failure for several reasons.

First, one of the reasons why I personally dislike Silicon Valley is that it’s all tech, all the time. You go to some little cafe and the people in the next booth are talking about MySQL. The billboards and the office buildings all sport .COM names or tech company products. And while this is not in and of itself a problem, it does create a culture where distinctly “techy” and user-unfriendly products is considered normal, and where an average IQ in the 130’s is considered average.

Meaning products produced in such an in-bred setting are going to lean towards being overly “techy” and hard to use by your average non-tech-head consumer, unless you have someone like a Steve Jobs running rough-shod over the tech instincts of the developers there.

Second, by encouraging everyone to move to Silicon Valley, which has become one of the most expensive places in the world to live, you encourage people into a “must become millionare so I can buy a house” attitude which, while it may be a powerful incentive to create, becomes a destructive force at a company such as Yahoo! if, after working like crazy, rolls out a new product only to watch the stock price drop.

Silicon Valley has become its own black hole–sucking engineers into its environment, while creating an environment where it is assumed everyone is a tech-head, and where adding 20 extra buttons to a cell phone is seen as a way to create flexability and choice, rather than as a bewildering set of options that make the phone less valuable to its owners.

What’s wrong with Safari for Windows

Posted on June 12, 2007 by William Woody

Much has been made about Safari for Windows looking like hell.

Here’s my take, as a Mac fan: it looks like hell.

Here’s what’s wrong:

(1) The Gamma on Microsoft Windows is considerably darker than on the Macintosh. To review, the gamma is essentially the exponent used to adjust the color (from 0 to 1) for display. Windows monitors use a gamma of 2.5, while Macintosh systems (which were targeted towards graphic artists) use a gamma of 1.8, which is similar to that of paper. This means that for a middle gray of 50% (0.5), the resulting luminance on Windows is 0.176 (=0.5^2.5), while on the Macintosh it is 0.287 (=0.5^1.8). The eye, like all organs on the body being sensitive to the log of the energy rather than being linear, detects 0.287 as roughly “half as bright” as 1, and perceives the 0.176 lumanence level as darker.

Now it appears Safari was ported by creating a packaged version of the Cocoa libraries to run on Windows–and it appears Apple’s engineers have not gamma corrected for Windows. This means the Safari window looks depressingly darker than the same window on the Macintosh.

(Sadly this would be an easy fix: a 256-byte array mapping from Mac RGB levels to Windows would help make the window ligher and more ‘natural.’)

(2) Because it is darker, Apple’s carefully tuned font anti-aliasing technology, which they also ported to Windows, looks like hell: the letters look heavy and unnecessarily bolded.

(3) Because Safari uses essentially Cocoa on Windows, it doesn’t do a few things correctly–like allowing resizing of a window by grabbing any edge or corner. Instead, Safari only allows resizing the window by grabbing the lower left corner. The result is a window that doesn’t behave like any other window on the screen.

Oh, and to address Joel’s concern about the initial startup time of Safari: on the Macintosh, when I installed the 3.0 beta, I experienced a nearly two minute delay before Safari started for the first time. I suspect Safari was doing a hell of a lot of book-keeping behind the scenes–which apparently needed to be done only once. So like Safari on Windows, the first time you start up the beta, it takes for freakin’ ever to start. The second time–just a few seconds, as usual.

Welcome to Hell.

Posted on June 4, 2007 by William Woody

Me: I’m just interested in getting a local sandbox going on my dev box so I can build your component, that way I can scope out the level of effort needed to make our recommended changes.

Them: I don’t understand, you want to make changes to the dev build?

Me: I just want a local sandbox; I don’t want to check anything in. That way I can better understand the code.

Them: Uh, that’s not the way it works.

Me: Huh?

Them: When a developer wants to make a change to our component, they first check out the file, edit it, then check it back in. Then a nightly build recompiles the product and deploys it on a test harness where, after the nightly runs, the product is smoke tested to make sure there are no problems. Of course a developer can trigger the build process manually if they need to; this triggers the nightly to run early.

Me: You mean there is no local developer sandbox?

Them: No; that’s the way our development process works. You check in your changes and our test harness compiles and verifies the changes work.

One reason why I hate beans.

Posted on May 9, 2007 by William Woody

I’m now poking around some source code for a project that was built with a bunch of little beans. I understand the theory of a Java bean: by segregating your code into small and self-contained modules it makes development easier (the person developing the bean should only worry about just that bean), and it makes debugging easier (you can host the bean in a test framework and test it in isolation).

However (and there is always a ‘however’ in my rants), I’m reminded of a post on Cocoa development: Thoughts about large Cocoa projects:

My app isn’t huge compared to Photoshop or Word—it’s teeny in comparison—but it’s large compared to some Cocoa apps. (It has 345 .m files and an executable size of 3.2MB when stripped.)

It’s big enough that, were you to ask me how _____ works, I’d have to go look. There’s no way I can remember, with any level of detail, how every part of it works.

I call it the Research Barrier, when an app is big enough that the developer sometimes has to do research to figure things out. (“Research” just means reading the code and following some paths of execution, sometimes running in the debugger.)

To summarize my problem with beans and the Spring framework and other systems which are designed to encapsulate your Java program into a bunch of small objects interconnected with a mechanism that uses Java reflection to hook things together is that it breaks the “research barrier.” It makes answering the question “who calls this?” and “what does it call?” much harder–if not impossible–to answer. Rather than making the answer ‘who calls this’ a matter of right-clicking on the method call in Eclipse and doing a search, you cannot answer the question anymore in a reasonable way: the entire application has been reduced to a complex dance of dozens or hundreds of jar files. Worse: the overall ‘flow’ of the application is no long encapsulated in a handful of classes but instead lives in some configuration file which–by design–can change without notice.

So here I am with a bunch of beans and all I want to answer is “what database tables are queried to generate a report?” The answer? With all these beans scattered around, apparently the answer changes with the phase of the moon.