The other day I received this email message, and yes, I’m pedantic enough to insist that they are “email messages”, not “emails”, or heaven forfend, “e-mails”. Oh, and on behalf of the C programmer community, thank you, gcc, for teaching us the word “pedantic”. I’m also pedantic enough to have written an application for spell-checking Javadoc and strings in Java doc.

Back to my rant, here is the message:

So … what is a “-11% decrease”? Isn’t a negative decrease an increase? But that down arrow before the minus sign is bothersome as well. So, is it a down -11% decrease?

The subject of the email message was

Add skills like “Swing” to make your profile easier to find

Just very quickly: “like” doesn’t mean “such as”: like means “similar to but not x”, whereas “such as” means “x or similar”. Second point: “Swing” should be in quotation marks if it’s a quote. Quotation marks are not for emphasizing words. (Yeah, and it’s ironic that this them (Reddle) precedes block quotes with an open quote, leading to me wondering whether posting this would fail with the message “error: missing unterminated ” character”.)

Oh, and if you’re curious about my LinkedIn profile, here it is, but if you don’t like it, please decrease your negative feedback to me, such as “you are “pathetic”.”

Reading Matthew Might’s article on console hacks inspired me to use that to quickly and easily find candidates for aliases and functions in Z shell.

The following command sorts the history by frequency of use:

% history -1000000 | cut -c8- | sort | uniq -c | sort -n | tail -15

The output from my recent work with DoctorJ is:

     11 cd ~ijdkproj
     12 gitpullall
     12 myprod.rb
     12 rake
     13 ..
     14 gitdfs
     15 c
     15 la
     20 sd
     24 scrub
     27 git status
     28 git push -u origin master
     37 git diff
     39 ls
     51 gct
     52 gitdelta.rb

(If you’re wondering what the “..” command is, that’s an alias for “cd ..”.)

In the frequency list the salient command in terms of length is “git push -u origin master”, executed 28 times. So we can consider an alias for it, such as “gpom”, and see whether it already exists as a function, alias, or program:

% which gpom
gpom not found

Since it doesn’t already exist, we can add it to the list of aliases (mine are in ~/System/Zsh/aliases.zsh):

alias gpom=’git push -u origin master’

On Github I’ve posted my Z shell configuration, with the updated aliases file here.

That is where unit tests are their most valuable, in keeping the project stable. The tests provide something that is often no longer on the project: the original concept. That is, the programmer who wrote the first version years before may now not even be at the same organization/company, so only the unit tests he wrote can “speak” for his intent.

Having rewritten DoctorJ and DiffJ lately, I was very thankful to have a full set of tests, which allowed me to refactor the projects with more confidence.

Unit tests should be written starting by testing the most basic functionality first, with the assumption that even the simplest code does not work. I thought it was overkill when I was writing tests like:

    Foo f = new Foo(x, y);
    assertEquals(y, f.getY());

until the first time I saw something more or less like:

    public int getX() {
        return x;
    }

    public int getY() {
        return x;
    }

That is one reason to avoid copying and pasting.

A guideline that I like is to try to have a test case per main (meaning non-test) classes, and to have the overall test code exceed the size of the code being tested, in number of lines. That makes writing tests a goal in themselves, as opposed to just being a means.

One of the problems with some unit test frameworks – notably, in my experience, Ruby’s Test::Unit and Java’s JUnit – is that assertions tend to be so low level that one has to read the original code to understand the context. For example, this output from JUnit doesn’t provide enough information:

junit.framework.AssertionFailedError: expected:<8> but was:<null>
	at junit.framework.Assert.fail(Assert.java:50)
	at junit.framework.Assert.failNotEquals(Assert.java:287)
	at junit.framework.Assert.assertEquals(Assert.java:67)
	at junit.framework.Assert.assertEquals(Assert.java:74)
	at org.incava.ijdk.util.TestListExt.testGet(TestListExt.java:30)

All that is known from that output is that the ListExt.get() method was being tested, and that the null was returned instead of 8. Looking at the source provides some more information:

        assertEquals(new Integer(8), ListExt.get(NUMS, -1));

Sort of. We have yet another step now, to look at the declaration of NUMS:

    public static final List<Integer> NUMS = java.util.Arrays.asList(new Integer[] { 2, 4, 6, 8 });

Thus it took three (or four) steps to get from the JUnit to what the failure actually meant, that “using the list ’2, 4, 6, 8′, ListExt.get(-1) returned null instead of the expected 8″.

The test case can be significantly improved by following the guidelines for tests, that their output consist of:

• the input
• the expected result
• the actual result

(Actually, that goes for bug reporting as well, or any kind of testing.)

One problem with unit tests is that they tend to consist of repeated code, such as:

        assertEquals(new Integer(2), ListExt.get(NUMS, 0));
        assertEquals(new Integer(4), ListExt.get(NUMS, 1));
        assertEquals(new Integer(6), ListExt.get(NUMS, 2));
        assertEquals(new Integer(8), ListExt.get(NUMS, 3));

Custom assertions – an assertion for testing a single method – reduces the repeated code:

    public <T> void assertListExtGet(T exp, List<T> list, int idx) {
        assertEquals(exp, ListExt.get(list, idx));
    }

        assertListExtGet(2, NUMS, 0);
        assertListExtGet(4, NUMS, 1);
        assertListExtGet(6, NUMS, 2);
        assertListExtGet(8, NUMS, 3);

Also note that autoboxing with JUnit 3.x and Java 1.5+ means that we have to resolve the ambiguity between whether assertEquals(Object, Object) or assertEquals(int, int) should be called, leading to the “new Integer(x)” calls in the first case, whereas with the refactored code, autoboxing is done with the call to assertListExtGet.

With that, we can refine the custom assertion to produce a more informative error message:

    public <T> void assertListExtGet(T exp, List<T> list, int idx) {
        String msg = "ListExt.get of '" + idx + "' in list: '" + list + "'";
        assertEquals(msg, exp, ListExt.get(list, idx));
    }

And the resulting output is very much like what we earlier had to discern by going through the code:

junit.framework.AssertionFailedError: ListExt.get of '-1' in list: '[2, 4, 6, 8]' expected:<8> but was:<null>
	at junit.framework.Assert.fail(Assert.java:50)
	at junit.framework.Assert.failNotEquals(Assert.java:287)
	at junit.framework.Assert.assertEquals(Assert.java:67)
	at org.incava.ijdk.util.TestListExt.assertListExtGet(TestListExt.java:21)
	at org.incava.ijdk.util.TestListExt.testGet(TestListExt.java:40)

The output is much more informative, and allows the debugging to start by bypassing the unit test code and going to the source.

To illustrate the difference, some examples, from least to most informative:

	invalid account data
	Email invalid
	Email address invalid
	Email address in invalid format
	Email address not in the correct format
	Email address not in the correct format: foo.bar@baz
	Email address "foo.bar@baz" not in the correct format
	Email address "foo.bar@baz" not in the correct format: invalid domain name
	Email address "foo.bar@baz" not in the correct format: "baz" is not a valid domain name.

	User name invalid
	User name invalid: john gallagher
	User name "john gallagher" not valid: invalid character.
	User name "john gallagher" not valid: invalid character: " ".

Quoting the arguments is valuable, especially when they are strings and on the end of a message. For example, the second message below makes it clear that the cause of the error is that there are trailing spaces in the URL:

	Invalid URL: http://www.foo.com   
	Invalid URL: "http://www.foo.com   "

The principle of being precise means that error messages should not be of the format “x or y occurred”, for example, “The database could not be connected to or there was an error during initialization.”

As a programmer, I can clairvoyantly read that code:

    try {
        db.connect();
        db.initialize();
    }
    catch (Exception e) {
        throw new DBException("The database could not be connected to or there was an error during initialization.");
    }

That’s just irrational laziness, leading to user frustration (and calls to support). The basic principle is: give the user the information to solve their own problem.

Setup is trivial. Just grab the zip file, unzip it into ~/.emacs.d, and add the following to your ~/.emacs file:

(setenv "ERGOEMACS_KEYBOARD_LAYOUT" "us") ; US

;; load ErgoEmacs keybinding
(load "~/.emacs.d/ergoemacs-keybindings-5.3.9/ergoemacs-mode")

;; turn on minor mode ergoemacs-mode
(ergoemacs-mode 1)

Among the first things to do is, at least if you’re running with the default Gnome keyboard shortcuts, is to disable alt-space from raising the menu within terminals (at least, this is the case for gnome-terminal). To do this, change or disable the shortcut via Preferences > Keyboard Shortcuts > Desktop > Show the panel’s main menu. Select that, hit backspace, and it should now read “Disabled”.

ErgoEmacs is actually two modules in one: it first is, as its name says, a more ergonomically friendly version of Emacs, where commonly-used commands have easy-to-type shortcuts, that is, with the use of Alt instead of Ctrl, and by favoring the keys in the center of the keyboard, as opposed to [, ], \, ~, etc.

The second module is that it uses the now-standard (for lack of a better word) editor shortcuts for operations such as opening files, copy, cut, and paste, which is much more intuitive and consistent with other editors.

I like much of it, but have some issues. I agree that the default Emacs keybindings and behavior are difficult, overwhelming and inconsistent with other editors, and should be updated. However, as with the Qwerty keyboard, we’re essentially stuck, by “we” I mean Unix-based programmers using Emacs, especially the most experienced ones. ErgoEmacs seems designed best for people experienced with mainstream editors such as Notepad and TextMate.

Emacs is so second-nature to me that I don’t consciously know some (most?) of the key shortcuts. If you’re like that, chances are that ErgoEmacs will force you to think about the shortcuts, causing cognitive friction that will interrupt your flow. If you have RSI issues, then you’re more likely to benefit, although as a programmer, I’m typing the oddball keys ([], {}, ()) so much that it is not significant to me to have the less frequently used commands a bit easier to type. (I’d never thought of that before, but it’s another reason to like Ruby: fewer special characters, since for example blocks are delimited with “begin” and “end” instead of “{” and “}”.)

The tipping point for me against ErgoEmacs is that my shell, Z shell, does not have the equivalent shortcuts, so I would essentially have to remember two separate (and conflicting) sets of commands.

That brings me to my final point: I dislike that ErgoEmacs provides no bridge or transition period for going from standard Emacs to ErgoEmacs. I’ve read that one can provide hints (in the same way that vanilla Emacs suggests shortcuts after you’ve executed a command via the traditional (M-x whatever). Having this with out-of-the-box ErgoEmacs would have been nice.

That said, I like the principle behind ErgoEmacs, and I’ll certainly be taking some ideas from it. On that note, I’ve finally posted my Emacs environment, 16 years of cruft and all, on GitHub here. I’ll be actively refining it over the next few weeks, and intend to have it up to date and stable by the end of January.

The connection between Lisp and Emacs? In this sense, they both became the standard-bearer for their field (programming languages, text editors), and reached that point very soon after the inception of the field. Each of them was so far ahead of the others that even decades later, one could argue that neither Lisp nor Emacs has been matched. If anything, progress in the fields has just been that the mainstream (meaning, widely accepted) products are more and more like Lisp and Emacs.

This doesn’t seem atypical, that there is this quantum leap early in the field. Among guitarists the Gibson Les Paul and Fender Stratocaster are probably the two most popular electric guitars, even a half century after their initial release in the late 1950s, when the electric guitar originated. In my non-expert vantage point I don’t perceive a fundamental difference (as in performance and function, not appearance) between the newest guitars now and the original Strat and Les Paul.

As Graham does, the same argument could be made for Ruby and Lisp, that of “modern” programming languages, Ruby is one of the closest to Lisp in terms of functionality (although its form is somewhat different). About Emacs, I don’t know what other text editor could be considered close, but it seems that Emacs is the most imitated – for example, it seems that the Eclipse editor is much closer to Emacs in behavior than it is to, say, vi. (On that note: is any other text editor similar to vi?)

It seems that the cycle is somewhat like this: the field originates, there are a few competing lead products, one dominates clearly, then there are relatively few imitators for the next decade or two (or more). After a while, the imitators become better and more like the original, to the point that they are essentially just re-badging it.

I’ve tried several times to really learn Lisp in the past, but had difficulty hurdling the syntax, probably in part because of my background in C, Perl, C++ and Java. But having now read of the similarities between Lisp and Ruby, I’m eager to see the difference in my perspective as I go through the excellent Emacs and Emacs Lisp tutorials at Xah Lee’s Emacs Blog).

I’ve been building it from scratch, with a core of commands wrapping those in svn, and new commands. At this point the only more-or-less fully working subcommand is log, which extends svn log to use “relative revisions” (explained below), and displays colorized output. I plan to add the functionality so that a user can set the format and colors for log output.

What is probably the most innovative functionality in pvn is that revisions may be “relative”, meaning that +N is the Nth revision, and -N is the Nth revision before the most recent one. In a large project, revision numbers can get into the six and seven digits, and it’s much easier to think of “the latest checkin I did”, as opposed to “my checkin with revision 317127″.

I don’t have a timeline, but my goal is to have the functionality of the log and diff subcommands implemented by the end of the year.

import java.util.Map;

public class TestSystemExit {
    public void methodOne() {
        methodTwo();
    }

    public void methodTwo() {
        methodThree();
    }

    public void methodThree() {
        methodFour();
    }
    
    public void methodFour() {
        System.exit(0);
    }

    public static void printStackTrace(Thread thread, StackTraceElement[] stElmts) {
        System.err.println("thread: " + thread);
        for (StackTraceElement stElmt : stElmts) {
            System.err.println("\tat " + stElmt);
        }
    }

    public static void main(String[] args) {
        Runtime.getRuntime().addShutdownHook(new Thread() {
            public void run() {
                Map stMap = Thread.getAllStackTraces();
                
                // only dump the stack trace with the method "exit":                
                for (Map.Entry stElmt : stMap.entrySet()) {
                    for (StackTraceElement st : stElmt.getValue()) {
                        if ((st.getClassName() + "." + st.getMethodName()).equals("java.lang.System.exit")) {
                            printStackTrace(stElmt.getKey(), stElmt.getValue());
                            break;
                        }
                    }
                }
            }
        });
        
        TestSystemExit tse = new TestSystemExit();
        tse.methodOne();
    }
}

The output is as follows:

thread: Thread[main,5,main]
	at java.lang.Object.wait(Native Method)
	at java.lang.Thread.join(Thread.java:1203)
	at java.lang.Thread.join(Thread.java:1256)
	at java.lang.ApplicationShutdownHooks.run(ApplicationShutdownHooks.java:97)
	at java.lang.Shutdown.runHooks(Shutdown.java:106)
	at java.lang.Shutdown.sequence(Shutdown.java:150)
	at java.lang.Shutdown.exit(Shutdown.java:195)
	at java.lang.Runtime.exit(Runtime.java:107)
	at java.lang.System.exit(System.java:923)
	at TestSystemExit.methodFour(TestSystemExit.java:17)
	at TestSystemExit.methodThree(TestSystemExit.java:13)
	at TestSystemExit.methodTwo(TestSystemExit.java:9)
	at TestSystemExit.methodOne(TestSystemExit.java:5)
	at TestSystemExit.main(TestSystemExit.java:46)

DiffJ 1.2.0 also has significantly rewritten code, and also uses the IJDK module. This version adds (on terminals that support it) colorization of differences. It too uses Gradle for its build.

Both projects are now distributed only in zip format, and I welcome offers to repackage them for various package managers.

The distributes are available for download:

• DiffJ 1.2.0
• DoctorJ 5.2.0

Buy.com had a replacement keyboard here for $20.

So with keyboard in hand, it was time to replace the old one. It was easy enough to find instructions online, but several links returned by Google for “replacing laptop keyboard asus k50ij” had misleading and incorrect directions, or seemed to be simply generic templates for laptop keyboard replacement, but not specific to the Asus K50IJ.

This site had the most accurate and thorough information, including annotated photos, making it (literally and figurative) a snap to install the new keyboard, in just a few minutes.

Now, back to coding, and to wondering why Gradle does not seem to apply exclude patterns during compilation, and thus complains about Emacs temporary files being unreadable files.