What a find! Land of Lisp!

What a find!Land of Lisp! Don't forget to scroll down. ٩(•̮̮̃•̃)۶

More on more uses for Iterables

Rúnar Bjarnason writes Scalaz Tutorial: Enumeration-Based I/O with Iteratees, an all-singing, all-dancing approach to composable iterators for I/O in Scala. This is a much fuller treatment of I/O iterators than my post, More uses for Iterables.

How to tempt good programmers to work for you

Danilo Campos shows by examples how to tempt good programmers to work for you.

Java ain't got no rhythm, but can it keep time?

I need sub-millisecond timing in Java; I want to measure events in the low microsecond range. What to do? My options seem to be:

1. Use System.currentTimeMillis() and average over long numbers of runs; many problems here.
2. Use System.nanoTime() and time individual events. Great, but the Javadoc is very scary for multi-threaded code.
3. Try out sun.misc.Perf.highResCounter() (many non-official references for this.)
4. Write our own JNI call for gettimeofday().

After months of hitting my head I wised up and looked into the JDK6 C++ source code. Surprise!

The C++ source

Drilling down points me to os::javaTimeNanos() (nanoTime), os::elapsed_counter() (highResCounter), and os::javaTimeMillis() (currentTimeMillis). On Linux these are:

System.currentTimeMillis()

jlong os::javaTimeMillis() {
  timeval time;
  int status = gettimeofday(&time, NULL);
  assert(status != -1, "linux error");
  return jlong(time.tv_sec) * 1000  +  jlong(time.tv_usec / 1000);
}

System.nanoTime()

jlong os::javaTimeNanos() {
  if (Linux::supports_monotonic_clock()) {
    struct timespec tp;
    int status = Linux::clock_gettime(CLOCK_MONOTONIC, &tp);
    assert(status == 0, "gettime error");
    jlong result = jlong(tp.tv_sec) * (1000 * 1000 * 1000) + jlong(tp.tv_nsec);
    return result;
  } else {
    timeval time;
    int status = gettimeofday(&time, NULL);
    assert(status != -1, "linux error");
    jlong usecs = jlong(time.tv_sec) * (1000 * 1000) + jlong(time.tv_usec);
    return 1000 * usecs;
  }
}

sun.misc.Perf.highResCounter()

jlong os::elapsed_counter() {
  timeval time;
  int status = gettimeofday(&time, NULL);
  return jlong(time.tv_sec) * 1000 * 1000 + jlong(time.tv_usec) - initial_time_count;
}

And:

void os::init(void) {
  char dummy;   /* used to get a guess on initial stack address */
//  first_hrtime = gethrtime();

  // With LinuxThreads the JavaMain thread pid (primordial thread)
  // is different than the pid of the java launcher thread.
  // So, on Linux, the launcher thread pid is passed to the VM
  // via the sun.java.launcher.pid property.
  // Use this property instead of getpid() if it was correctly passed.
  // See bug 6351349.
  pid_t java_launcher_pid = (pid_t) Arguments::sun_java_launcher_pid();

  _initial_pid = (java_launcher_pid > 0) ? java_launcher_pid : getpid();

  clock_tics_per_sec = sysconf(_SC_CLK_TCK);

  init_random(1234567);

  ThreadCritical::initialize();

  Linux::set_page_size(sysconf(_SC_PAGESIZE));
  if (Linux::page_size() == -1) {
    fatal1("os_linux.cpp: os::init: sysconf failed (%s)", strerror(errno));
  }
  init_page_sizes((size_t) Linux::page_size());

  Linux::initialize_system_info();

  // main_thread points to the aboriginal thread
  Linux::_main_thread = pthread_self();

  Linux::clock_init();
  initial_time_count = os::elapsed_counter();
  pthread_mutex_init(&dl_mutex, NULL);
}

(The net effect is to normalize to 0-time at JVM boot rather than the epoch.)

The solution

Just use System.nanoTime() and stop worrying so much. It is fine for microsecond timing—even across threads—just RTFM and ignore javadoc.

Elena Yatzeck promotes the agile Army Leadership Field Manual

A positive, fascinating post from Elena Yatzeck on agile leadership as taught in the U.S. Army Leadership Field Manual. The only military members of teams immediate to me are presently serving overseas. Looks like I missed out.

Larval Java

Very cool post from John Rose on larval objects in the VM. How are immutable objects really made in the JVM? How could it be improved? Read and find out.

Nice refactoring example from Bobby Johnson

Bobby Johnson walks us through a nice refactoring example. Its not rocket science or brain surgery, but good old-fashioned craftsman handling of code, great to show journeymen programmers not quite sure what code cleanup looks like.

Pay your debts

Pay your debts or they will eat your project alive. Tea-partying is for code, too.

Come hear me at the Houston TechFest

Come here my talk at the Houston TechFest! I am speaking on Hands-free Coding: Code Generation with Annotation Processors on October 9, 2010 03:45 PM - 04:45 PM at the University of Houston University Center. See you there!

UPDATE: Unfortunately, I spent today laid up at home with a bad back, and was unable to present at TechFest. This is very disappointing. However, as promised, I'll still post sources in the next day or so.

Dick Management

Some Guy's Blog captures dick management perfectly: the difference between good and bad managers. I pursue the former and eschew the latter. You should, too.

Hamlet D'arcy on Mockito

A beautiful post from Hamlet D'arcy on Mockito - Pros, Cons, and Best Practices. My team at work uses EasyMock. I want to use Mockito for my next project; this post makes it an easier sell.

Getting maven dependency sources and javadocs

I found Ted Wise posting on the problem I tackled today: how to download sources and javadocs from command-line maven:

$ mvn dependency:sources
$ mvn dependency:resolve -Dclassifier=javadocs

Unsure why the discrepancy.

The error of group-think

Idris Mootee writes at Blogging Innovation about the error of group-think. My favorite quote:

I see this all the time, one smart person can make a quick decision to solve a problem, two smart persons can frame an issue better and share perspectives and ten smart persons often have no idea of what problems they are trying to solve.

I have seen this all my work life: decision-making by committee produces the proverbial camel instead of a horse.

UPDATE: Fixed article link.

IntelliJ made me $1500 trading on my portfolio today

IntelliJ made me $1500 trading on my portfolio today! No, not really. But is there anything for Java programming it won't do? I read about a "new" (new to me) feature in the IDEA blog, Referencing marked objects in expression evaluation. The post describes cools updates for IDEA X to this already cool feature.

And a picture to save (1000 - N) words:

Agile games people play

3 great agile games from the First Agile Games Conference:

• Packing Peanuts
• The Backlog is in the Eye of the Beholder
• Making Pamphlets: Kanban Game

Thank you Improving Blogs mashup!

Manifesto for Half-Arsed Agile Software Development

Courtesy of Brian Winquist, the Manifesto for Half-Arsed Agile Software Development.

More uses for Iterables

Iterable is one of my favorite interfaces in Java. I love the for-each construct:

for (final Type item : iterableOfItems)
    doSomethingWith(item);

Notice what cannot go wrong:

1. I cannot run off the end, or forget to go far enough (no off-by-one bugs)
2. I cannot forget to call hasNext() before calling next() (iterator misuse)
3. I cannot make the wrong cast or pick the wrong container type

I could go on. It is also concise and conveys programmer intention clearly, both wonderful virtues.

How can I make more use of Iterable?

Here is an example of transforming input into Iterable. First the base class:

public abstract class ResourceIterable<T, R extends Closeable>
        implements Closeable, Iterable<T> {
    private final R resource;

    private volatile boolean closed;

    protected ResourceIterable(final R resource) {
        this.resource = resource;
    }

    protected final R resource() {
        return resource;
    }

    protected abstract T getNext()
            throws IOException;

    @Override
    public final void close()
            throws IOException {
        closed = true;
        resource.close();
    }

    @Override
    public final Iterator<T> iterator() {
        return new Iterator<T>() {
            private T next;

            @Override
            public boolean hasNext() {
                try {
                    next = getNext();
                    return null != next;
                } catch (final EOFException ignored) {
                    next = null;
                    return false;
                } catch (final IOException e) {
                    next = null;
                    if (closed)
                        return false;
                    throw new UndeclaredThrowableException(e);
                }
            }

            @Override
            public T next() {
                if (null == next)
                    throw new NoSuchElementException();
                return next;
            }

            @Override
            public void remove() {
                throw new UnsupportedOperationException();
            }
        };
    }
}

And a sample using class:

public class LineIterable
        extends ResourceIterable {
    public AmpsResponseIterable(final BufferedReader reader) {
        super(reader);
    }

    @Override
    protected String getNext()
            throws IOException {
        return resource().readLine();
    }
}

The example is trivial (my actual uses are hiding sophisticated readers of data structures from network connections) but clear:

for (final String line : new LineIterable(someBufferedReader))
    process(line);

However, all use of Iterable is similarly trivial: that's the point if it. The complexity is in extracting objects from the input (though not in this example).

I prefer hard-to-write-easy-to-use code when I make libraries; easy-to-write-hard-to-use just feels lazy (the wrong kind of lazy).

Guice moving to Maven

It's not new news, but it was new to me: Maven is switching to Guice to wire itself and plugins. From Sonatype:

1. From Plexus to Guice (#1): Why Guice?
2. From Plexus to Guice (#2): The Guice/Plexus Bridge and Custom Bean Injection
3. From Plexus to Guice (#3): Creating a Guice Bean Extension Layer

The plugin framework is named spice inject and glancing through it's straight-forward glue between Guice and OSGi within a Maven object domain.

It looks very clean. Nice.

Large-scale refactoring

Vikas Hazrati has a nice post on large-scale refactoring on InfoQ. I'm a strangler. You?

Have tools, will code

Thanks to the benevolent JetBrains, I now have an OSS license for IntelliJ IDEA to develop an Android app. I first started using IDEA at ThoughtWorks where it quickly became my favorite development tool.

And thanks to Turbine, I have my data.lotro.com developer key! So I am ready to start an LOTRO Android App. And I've already been getting encouraging words from the LOTRO forums. Go, community!

Nexus out, Android in

My dreams of a Nexus One came to naught. But...

I now have an excellent Samsung Galaxy S with Android 2.1, and I asked JetBrains for an open-source license for their Android plugin to IntelliJ IDEA. I have plans brewing!

Hands-free Coding: Code Generation with Annotation Processors

I'm speaking at Houston TechFest on October 9! My talk is Hands-free Coding: Code Generation with Annotation Processors. Wish me luck. Here's the summary:

Have you ever written hundreds or thousands of lines of boilerplate code, or struggled to write Java idioms correctly every time? There is great way to save time and effort and use to standard code patterns automatically: Code Generation.

In this talk, I will walk you through using the JDK6 Annotation Processor API together with Velocity templates to read your Java source code and write new Java source files for you from code templates. It is magic, but magic you can understand and use to be more productive.

Let the compiler write your code for you!

Please come watch!

Lua coming to LOTRO

With Lua coming to LOTRO I may have to dust off my Lua, last used in hacking at T.o.M.E.. It will be a nice break from Java and work, and give me something nice to do for my wife who doesn't know (yet) about MMORPG add-ons.

JB Rainsberge's 10 things

Courtesy of Naresh Jain comes J B Rainsberge's list of 10 things to stop doing or he will bury you alive in a box (about 1hr30m of video), a really delightful presentation on agile.

For the impatient, the list (which is only about half the presentation):

1. Stop writing comments that describe what the code does
2. Stop working in code bases with compile errors
3. Stop insisting that writing the tests after is just as good as writing the tests before
4. Stop insisting that evolutionary design leads to poor architecture
5. Stop writing tests for "coverage"
6. Stop arguing about whether a story is done
7. Stop trying to increase your velocity
8. Stop breaking up working teams
9. Stop acting as though agile is "what the project teams do"
10. Stop telling your people to "go agile" on their own

Go watch the whole thing, and please, Stop It.