Wabewalker

location: United States, California, San Francisco

mood: cranky

Paul Graham is whining about the App Store. It’s the whine du jour amongst the blogerati: the review process is broken, developers will flee, the ecology will disintegrate without a constant stream of new applications, the sky will fall, humans will be sacrificed, dogs and cats will live together. You know the drill.

I am sure no one, not even the most loyal employee inside Apple, believes the App Store review process is even near perfect. There are human beings involved and subjective decisions required: mistakes will be made.

So, why should Paul care enough to post?

Simple: the App Store review process throws a big ol’ monkey wrench into the grinding gears of his beloved development process. The key paragraph:

Apparently Apple's attitude is that developers should be more careful when they submit a new version to the App Store. They would say that. But powerful as they are, they're not powerful enough to turn back the evolution of technology. Programmers don't use launch-fast-and-iterate out of laziness. They use it because it yields the best results. By obstructing that process, Apple is making them do bad work, and programmers hate that as much as Apple would.

Paul’s obviously a big fan of the Agile movement. But let’s face some ugly truths:

• Agile is not about quality.
  Agile is not about efficiency.
  Agile is about power.

  The micro-bureaucrat née programmer has never had much control over his life. The deploy-first-deploy-often model cuts the unpleasant QA step out of the development process, which gives the programmer direct power over the end user. A QA department can criticize him, can have his sorry ass fired; all the beta mob can do is whine and beg for updates.

• The review phase is not going to produce bad work.
  The review phase is going to produce work free from unnecessary and untested features.

  This is what programmers hate the most: being forced to work on things that are not fun. That’s 90% of the reason for software bloat: that there is no oversight, no adult to warn about losing an eye. Either the manager of a project is technical, or he is not. If the manager is an ex-programmer, he hates having to manage. He does not want to alienate the developers: he wants to be their friend. A non-technical manager can afford to be aloof, but his lack of technical knowledge allows him to be easily snowed. A technically skilled manager who is able to say “no” is a rare bird indeed.

  Iteration is impossible here: the developer gets one shot, and if he screws it up then the reviews will be mostly negative and his little application will fall off the bottom of the list. Apps for the iPhone may be delivered via the web, but they are still shrink-wrapped software: the rules are different from web-based applications.

• Apple is not going to lose the best developers.
  Apple is going to lose the rockstar programmers.

  Apple is going to lose the programmers that blog, that twitter, that whine, that post to Slashdot and Stack Overflow. Apple is going to lose those Internet celebrities whose sole purpose is to dribble fame onto the nameless hordes that adore them. These are people that have to produce a constant stream of updates lest they lose the spotlight to which they are desperately addicted. Apple will be far better off once they move to the next big thing.

• Apple understands software.
  Apple understands that software is not about the means it is produced.
  Apple understands that software is about the user.

  Granted, they’ve made mistakes in the past. But what we’re seeing is an observer effect: the developers who whine about the review process are the ones who were rejected for an absurd reason. Nobody is going to blog about how they were shot down legitimately. Nobody ever admits culpability: not Apple, not the developer, no one.

• Apple doesn’t give a damn about making life easier for programmers.
  Apple makes life easier for customers.

  One way to appeal to programmers is with software. If you could think of an application programmers had to have, but that would be impossible in the circumscribed world of the iPhone, you could presumably get them to switch.

  This is the same myth that has led Linux, despite its power and economy, to fail time and time again in being the desktop of choice. It does not understand the common man; it is built by developers for developers to develop with and upon. Eric Raymond can blog until he’s blue in the face about how nigh impossible Linux is for the non-technical user, but it falls on deaf ears. Simplicity isn’t fun.

People are whining because Apple is succeeding despite constant predictions that it was destined to fail because Apple does not follow the arbitrary rules set by the “developer community.” Just as the Windows crowd complains that the support Apple receives from its customers is merely from a cult of personality, just as the Cluetrain people gnash their teeth because Apple has huge mindshare despite never holding a “conversation” with their customers, the Agile proponents are livid because Apple is succeeding despite ignoring every tenet of their beloved manifesto.

You can’t argue with success. And in the end, the best developers — the steady, responsible, modest, trustworthy developers — simply demand renumeration for their work. And that, alas, is exactly what the App Store will give them.

Engadget: OpenOfficeMouse isn't free, isn't pretty

Eighteen buttons. Eighteen friggin’ buttons! Good God.

That mouse epitomizes one of the more gratuitous mistakes of the open source movement: overly complicated to the point of being completely unusable. The idea “if X is good, then two of X must be great!” is far too prevalent in the geek consciousness. Complicated messes turn normal people off. Sorry, nerds: my mom loves her single-button Mac mouse, and she’s not alone.

This product should have been aborted in the concept stage. Everyone who greenlighted that monstrosity should be banished to a remote island so that horrors like this are never repeated.

Using Cobertura within a NetBeans project is not that difficult, but there are a few subtleties that I often miss. This setup will use Cobertura if the library is part of the test classpath; otherwise, it will silently skip the instrumentation step. For shared development environments, developers that do not wish to instrument will have to create an empty Cobertura library to avoid the dreaded “Missing Reference” problem.

The majority of the heavy lifting is done within build.xml. After NetBeans has set up Ant with its own macros, check to see if the Cobertura library is installed, then load the Cobertura Ant tasks:

<!-- If the Cobertura library has been added to the classpath and it is the right library, set the flag -->
<target name="-check-cobertura-availability" if="libs.Cobertura.classpath">
<available property="cobertura.available"
    classname="net.sourceforge.cobertura.coveragedata.HasBeenInstrumented"
    classpath="${javac.test.classpath}"/>
</target>

<!-- Load in the Cobertura tasks and set runtime properties to reasonable values -->
<target name="-load-cobertura-tasks" if="cobertura.available">
<taskdef classpath="${libs.Cobertura.classpath}" resource="tasks.properties"/>
<property name="test-sys-prop.net.sourceforge.cobertura.datafile" value="${build.dir}/test/cobertura.ser"/>
<property name="build.test.coverage.dir" value="${build.dir}/test/coverage"/>
</target>

<target name="-post-init" depends="-check-cobertura-availability,-load-cobertura-tasks"/>

The following step is annoying, but it helps insure that stale instrumented classes do not shadow fresh compiles:

<!-- Flush all previously instrumented code -->
<target name="-pre-compile">
<delete dir="${build.test.classes.dir}"/>
</target>
<target name="-pre-compile-single">
<delete dir="${build.test.classes.dir}"/>
</target>

This is the most important step. Since we are interested in instrumenting the application classes but do not want to ship instrumented code, we need to dump the instrumented class files somewhere else instead of using Cobertura’s default behavior to modify in situ. Since NetBeans complains if classpath directories are missing at start time (“Missing Reference”), it is best to dump them in a known location. The test build directory is a perfect candidate:

<!-- Instrument the application code -->
<target name="-pre-compile-test" if="cobertura.available">
<delete file="${test-sys-prop.net.sourceforge.cobertura.datafile}"/>
<cobertura-instrument todir="${build.test.classes.dir}"
    datafile="${test-sys-prop.net.sourceforge.cobertura.datafile}">
    <fileset dir="${build.classes.dir}">
	<include name="**/*.class"/>
	<!-- any classes that will not be exercised ("too simple to test") should be listed here -->
    </fileset>
</cobertura-instrument>
</target>

There is still an issue here: by default, NetBeans searches the classpath used to build tests before it searches the test build directory. This means that the default behavior is that the test runner will load the non-instrumented application classes instead of the instrumented ones. Changing the search order for running tests in the project properties solves this problem, but will not affect developers running tests without instrumentation.

Finally, generate a human-readable report (and a test report as well):

<!-- Produce the coverage report -->
<target name="-cobertura-report" if="cobertura.available">
<cobertura-report srcdir="${src.dir}" destdir="${build.test.coverage.dir}"
    datafile="${test-sys-prop.net.sourceforge.cobertura.datafile}"/>
</target>

<!-- Produce the coverage and JUnit test reports -->
<target name="-post-test-run" depends="-cobertura-report">
<junitreport todir="${build.test.results.dir}">
    <fileset dir="${build.test.results.dir}">
	<include name="**/TEST-*.xml"/>
    </fileset>
    <report format="frames" todir="${build.test.results.dir}"/>
</junitreport>
</target>

Happy happy joy joy: now test coverage reports will be generated for those that care, and silently skipped for those who don’t.

location: home

mood: amused

I have found a replacement for the late, lamented Fake Steve Jobs:

Linux Hater’s Blog

Excessive swearing, but charming in its anger; and dead-on, especially describing design problems that could have been fixed years ago had egos not been in the way.

Amazon’s a priori data mining algorithm is always a source of entertainment. Take their latest missive:

Dear Amazon.com Customer,

We've noticed that customers who have purchased or rated "The Andromeda Strain" have also purchased "Philippine Fighting Arts by Julius Melegrito Vol. 1: Single-Stick Tactics and Applications" on DVD. For this reason, you might like to know that "Philippine Fighting Arts by Julius Melegrito Vol. 1: Single-Stick Tactics and Applications" will be released on June 17, 2008. You can pre-order yours by following the link below.

Wanted: a content analyzer and classifier for Amazon.

Disclaimer: May only be fun for math nerds.

Puzzle: At a party, someone comes up to you and offers you odds that some pair in the room share a common birthday (month and day, ignoring the year and leap days). Should you take that bet?