How different can we be from a country that has its own top model television program?

Yesterday, Michael Urban had some harsh criticism for Apple’s handling of Java in Leopard. There’s a lot of discontent in the Java world because Java 1.6 (err, Java 6) did not make the cut for Leopard, and Urban says that Java 1.5 (Java 5, if you work for Sun) is broken in Leopard as well.

Ben Galbraith throws a bit of water on Urban’s complaints, pointing out that while Apple did not deliver Java 1.6, they don’t appear to be pulling back on their commitment to Java in general.

What’s interesting to me is that all of this grousing regards client side Java, which I tend to associate mainly with Java development tools. I guess it’s good that there are still people out there who care about being able to write applications in Java that look like native Windows and OS X applications. Everything I write in Java winds up in a WAR file.

Update: Ted Leung posts about open source Java and how it might have made it easier for Apple to get Java 6 into Leopard.

I have a Java unit testing question. First, let me describe a scenario. Let’s say I have a class called IncomeTaxReturn that includes a method, calculateRefund(). That method is public (meaning anybody can call it). I also have a bunch of other methods that are only used by calculateRefund() that package up bits of logic so that the code is easier to understand and to test. The class might include methods like calculateTotalIncome() or lookUpTaxRate().

The methods I’ve written to encapsulate bits of business logic produce a predictable output given a specific input, and I want to write tests for them. I may also have some tests for calculateRefund(), but having tests for the other methods is a good practice because it helps to isolate problems when performing regression tests later.

Most Java projects keep tests in a directory structure parallel to the source for the application itself, making it easy to leave out the unit tests when building the application for distribution or deployment to the server.

I feel like the best practice is to mirror the package names between your application source and your tests. So if my IncomeTaxReturn class is in gov.irs.incometax then I put TestIncomeTaxReturn in the same package, gov.irs.incometax, only in the test directory. Then I just make sure that all of the classes for the application and tests are in the classpath when I want to run my tests.

So here’s the question. If I were not going to write any tests for the methods I was talking about, I’d make those methods private. If I want to test them, how do I handle the scope?

I can’t leave them as private because then my test cases can’t run them. So now I have to alter my code not to improve the application, but to make testing easier.

Obviously I could make the methods public, but that strikes me as a bad idea. Suddenly a bunch of internal methods that are really implementation details are part of the public interface of my class. From a purity standpoint, that’s a bad idea because someone else may come along and wonder what kind of API you’re providing. From a laziness standpoint, this approach stinks because when I reference the class in my IDE, I have to sift through all of those methods when I’m auto-completing a method name.

Protected scope is out, because unit tests usually subclass a generic test case, not the classes they’re testing.

I could leave out the scope entirely, leaving the methods with the default (package) scope. As long as I follow the practice of putting my tests in the same packages as the classes they test, this approach works, and is probably the right answer.

Is there another approach that’s recommended? Or do people generally just test against the public interfaces of their Java classes rather than testing the private methods that test bits of the business logic?

The New York Times Bits blog notes that the whois database may soon be gone. Being listed in whois is definitely a spam and junk mail magnet, but it remains the best way to track down many kinds of impostors, fraudsters, and online lowlifes. I’ll be sad to see it go. There was always something nice about the idea that if you had a problem with a host at a certain domain, you could look up the domain’s owner and shoot them an email to ask what’s up.

In a classic example of the Overton window at work, there seems to be a broad effort to move waterboarding into the realm of the politically acceptable. It’s time for that to end. People advancing this argument should read what Malcolm Nance has to say about it. First, his credentials:

In fact, waterboarding is just the type of torture then Lt. Commander John McCain had to endure at the hands of the North Vietnamese. As a former Master Instructor and Chief of Training at the US Navy Survival, Evasion, Resistance and Escape School (SERE) in San Diego, California I know the waterboard personally and intimately. SERE staff were required undergo the waterboard at its fullest. I was no exception. I have personally led, witnessed and supervised waterboarding of hundreds of people. It has been reported that both the Army and Navy SERE school’s interrogation manuals were used to form the interrogation techniques used by the US army and the CIA for its terror suspects. What was not mentioned in most articles was that SERE was designed to show how an evil totalitarian, enemy would use torture at the slightest whim. If this is the case, then waterboarding is unquestionably being used as torture technique.

I hesitate to summarize, but let me just grab a couple of paragraphs and add that there’s a whole lot more.

Waterboarding is a controlled drowning that, in the American model, occurs under the watch of a doctor, a psychologist, an interrogator and a trained strap-in/strap-out team. It does not simulate drowning, as the lungs are actually filling with water. There is no way to simulate that. The victim is drowning. How much the victim is to drown depends on the desired result (in the form of answers to questions shouted into the victim’s face) and the obstinacy of the subject. A team doctor watches the quantity of water that is ingested and for the physiological signs which show when the drowning effect goes from painful psychological experience, to horrific suffocating punishment to the final death spiral.

Waterboarding is slow motion suffocation with enough time to contemplate the inevitability of black out and expiration –usually the person goes into hysterics on the board. For the uninitiated, it is horrifying to watch and if it goes wrong, it can lead straight to terminal hypoxia. When done right it is controlled death. Its lack of physical scarring allows the victim to recover and be threaten with its use again and again.

The fact that there is an even debate about this shows just how far the window of acceptable discourse has shifted on the topic of torture. If you think waterboarding is acceptable, you must admit that you’re in favor of ordering American soldiers or government employees to torture prisoners. You don’t get to have it both ways.

Link via FP Passport.

Yeah, I know that everybody has already blogged John Siracusa’s review of Leopard, but I’m not going to let that stop me. The depth and breadth of his reviews consistently astound me, as does his ability to explain highly technical features in terms any user can understand. He also does an excellent job of not just describing new features, but also explaining how esoteric changes to the kernel will make life better for users, or affect third party application developers. I’m pretty sure he knows more about the Mac than I know about anything.

Anil Dash had a strong negative reaction to Apple’s little joke at the expense of Windows in Leopard. If you haven’t seen it yet, Apple’s icon for PCs on your network (or anything that looks like a PC) is a CRT monitor displaying the dreaded blue screen of death.

It’s funny how Apple’s perception of itself differs from Anil’s perception of it. Apple obviously still sees itself as the struggling computer company, trying to build better products to compete against an incompetent but incredibly powerful Goliath. Apple has always seen itself that way, and still does, apparently, even though it’s now worth more than IBM.

For Apple, it will always be 1995. Microsoft was just coming out with Windows 95, which aped many of the best features of System 7, and Apple was in the doldrums, not shipping software upgrades and creating hardware that was ruinously expensive and mediocre at best. I have still never forgotten the famous “C:\ONGRTLNS.W95” that Apple ran, mocking the old file naming limitations from the DOS (and Windows 3.1) days. Back then, Mac users felt like they were under siege. Apple was doing poorly, nobody would let you use a Mac at work, and Microsoft was garnering a ton of publicity for releasing features you already had on your beloved Mac.

What the icon indicates to me is that Apple’s perception of itself hasn’t changed much since those days, even if the company’s circumstances have.

I should mention that in an ironic twist, some people trying to upgrade to Leopard are running into blue screen problem themselves. Hubris never stops amusing.

Earlier this week I posted about how many people use file sharing because the experience is so much better than the experience provided by people selling goods that can be downloaded. To further bolster my case, I offer this anecdotal evidence:

What was astounding: a full 80 percent of those we talked to (in all, about 30 people) said that despite grabbing Leopard off BitTorrent, they a) had already ordered a copy that wasn’t in yet, or b) were planning on buying one regardless. In other words, BitTorrent activity was high, but as we have seen so often, it’s not indicative of how many people are taking Leopard without paying for it.

As one user said, “BitTorrent delivers faster than FedEx, dude.”

Last week I had to handle a couple of requests for new projects to be added to our bug tracking system, because adding new projects requires administrative privileges. In both cases, I wound up just giving the people who made the requests administrator privileges themselves, but I was reluctant to do so.

The thing is, my reluctance had nothing to do with not trusting the people in question, it was strictly due to the psychology of using the software. We have maybe ten people who use the system, and after promoting two more administrators, I think seven or eight of the users are administrators. Given a system that provides various access privileges, it felt odd to me to basically let everyone be an administrator. There’s a little voice in my head that said that maybe only 25% of the users of a system should be at the top, and honestly I’m not sure where that comes from.

What I find interesting about that is that when I’m using a wiki, I love the fact that all of the users can do whatever they want — edit anything, delete articles, and generally make a mess of things. So I can’t help but think that the simple existence of user roles drives me to think in terms of those roles and who should be in them.

I think there’s something deep here about the way software is designed. When you provide users with features that define structure in some way, there is some compulsion to adhere to that structure, whether or not it makes sense. If your mail system provides folders, people feel like they ought to organize their mail in folders. If your bug tracking system provides a highly granular system of access control, people feel like they ought to assign privileges in that way.

That’s the reason Google was so reluctant to include a “delete” function in Gmail. They wanted to relieve users of the “delete” or “keep” decision when it comes to every email message. They give you plenty of space and make it easy to just archive your mail. Don’t bother filing it, and don’t try to figure out whether it’s something you need to keep. Of course, they added the “delete” function after users clamored for it, but I think that leaving it out was a pretty interesting experiment.

These considerations add a layer of complexity to software design. As developers, we tend to think of adding new features simply as adding optional ways of usage that users can ignore, but there’s more to it than that. As users, we feel like we should use the options that are provided to us, whether it makes sense or not. I suspect this is one of the reasons for software spoilage.

William Gibson on the allure of conspiracy theories:

Conspiracy theories are popular because no matter what they posit, they are all actually comforting, because they all are models of radical simplicity. I think they appeal to the infantile part of us that likes to know what’s going on.