No Open Blockers

A coworker sent out the following link to the Spacewalk mailing list.

Vim Recipes

Don’t know what Vim is? Google it, I haven’t gotten around to blogging about it and Emacs yet. After you’ve googled it, install it. Yes, they have a Windows version.

Rather than being a straight user guide, it’s more of a guide on how to do useful shit in Vim. I took to Emacs keys much more easily (to the point that I remapped IntelliJ to use the common ones), but I’m really trying to force myself to get better with Vim. The recipes guide reads much better than any of the other tutorials I’ve looked into for Vim and has already shown me a number of useful tips.

For instance, the one thing that has always bothered me about Vim was how many steps it takes to save a file. I’m the kind of person who instinctively saves whatever I’m working on every time I stop to think. I’ve lost too much time by fat fingering something and closing the window without saving. In Emacs, that’s a very quick sequence:

Ctrl-x, Ctrl-s

It may look a little weird, but after using Emacs for 10 minutes, an easy key stroke to mindlessly use. In Vim, it takes a few more steps:

Esc  (to exit insert mode)
:w
i  (or a, to enter insert mode again so I can, ya know, actually type something)

That’s a lot of movement around the keyboard for something I do several times a minute (I stop to think a lot). Page one of that recipes guide already showed a useful way around that:

Use [Ctrl]+o in Insert mode to switch to Normal mode for one command, then return to Insert mode. For example, [Ctrl]+o gqas enters Normal mode, reformats the current sentence, then returns you to Insert mode.

In other words, it eliminates both the need to press escape as well as having to explicitly enter back into insert mode. So my mindless save now looks like:

Ctrl+o
:w

Much nicer. Even if that was all I picked up from the guide, it’d have been well worth it.

I won’t go into more specifics, but I was able to easily find information on repeating commands. I tend to use a lot of dividers in my text files, so being able to quickly generate 60 hyphens as a section header was a sore spot when learning Vim after Emacs. I’m also a big fan of temporary macros to repeat a sequence of changes, which I’m still figuring out how to do in Vim.

Eventually I want to write a bit more of a general introduction blog on Vim and Emacs (where I may explain the religious war between the two) in hopes I can convince my students to learn a real text editor (no, Wordpad doesn’t count and you ask for help while using Notepad, I’m docking your grade). I can’t stress enough that at some point in your career you will find yourself on some form of Linux/Unix/Solaris box where at least being able to navigate and edit text in Vi is pretty much required knowledge.

1
2
3
4
5
6
7
8
9

try {
    String line = input.readLine();
    while (line != null) {
        line = input.readLine();
    }
}
catch (IOException ioe) {
    logger.debug("IOException...really need better handling here");
}

Everyone, at one point or another, is guilty for just swallowing an exception. Java tends to be a bit trigger happy with its checked exceptions (especially in the IO packages), so it’s inevitable to be in a position of having to deal with an exception that admittedly will probably not happen while trying to get something else accomplished.

The nice part is that I’m cleaning this up and actually providing the better handling. The cool part is that I’m using code I wrote for CodeTurtle to do it.

I’ve been reading Dreaming in Code for the past week. I forget where I first heard of it, but after a recommendation from a coworker on the Spacewalk team (thanks Partha) I finally followed through with checking it out.

The subtitle does a good job of explaining the book’s purpose: “Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software”. I hesitate to call it a case study in software projects because I don’t think it does justice to the book’s relaxed, conversational style. Rather than reading like a formal study, it’s the story of the development of Chandler an open source personal information manager with high goals. Rosenberg also provides a ton of related information to help frame the choices the Chandler team had to make, which increases the book’s audience significantly to include non-professionals.

I wish I was in a position to assign required reading for CSC majors. I’m not sure what class this would fall under (the most likely candidate is Software Engineering). Even then, the bigger challenge is convincing students of the value.

In short, anyone considering a career in programming needs to read this book. It provides an incredibly good insight into what it’s like to work on an actual project, an insight that students normally only get with experience after they’d graduated. Like I said, it’s presented more as a story of what happened rather than a technical manual, so it’s not painful to read.

But I cannot stress enough how much I would have appreciated such a detailed look into a real software project before I started on my career. Software Engineering text books describe what to do “by the book”. This book shows you a more realistic view of how those theories and practices can (and often do) go wrong.

The exceptions lecture of the semester is one of the trickier ones I deal with. Part of the issue is that I try to cram it into a single class, a strategy that has backfired on me twice now. Another difficulty is the fact that while there is quite a bit of technical knowledge as far as throwing and catching exceptions, I could easily spend double that time covering design and best practices.

I took a bug today that covers the error messages shown to a user when they input an invalid channel name. Currently, we simply say “Invalid channel name” without any indication of why… was it too short, did it contain invalid characters, was it already in use, etc. Our name validation is correct, but from a user experience stand point, it could use a little love (this was exacerbated by the multi-org addition where a channel name could be taken without you being able to see that data otherwise).

There are a number of different validations we run against the name. A good sampling of them is found in the following snippet:

1
2
3
4
5

if (cname == null || 
    !Pattern.compile(CHANNEL_NAME_REGEX).matcher(cname).find() ||
    cname.length() < 6) {
        throw new InvalidChannelNameException();
    }

Again, the logic is fine. Any of the circumstances in the if clause represent an invalid name. But now we have the need to carry more information to better indicate why it failed.

I started by editing the exception class itself. The constructor now accepts two parameters. The first is the channel name; if we’re saying the exception represents an invalid channel name then it makes sense it should indicate exactly what was invalid. This also saves the UI some work in remembering what was specified that caused the error.

The second is an enum (defined as an inner class of the exception class itself) that describes the reason for the failure. The enum (currently – I’m kinda writing this as I work on it) looks like the following:

1
2
3
4
5
6

public enum Reason {
    REGEX_FAILS,
    TOO_SHORT,
    IS_MISSING,
    NAME_IN_USE
}

I’m a big fan of the enum for something like this. It’s clunky to make subclasses of InvalidChannelNameException just to indicate the different possible reasons for failure, and frankly a series of instanceof checks to later use that information would just be ugly. A similar if/else structure would be needed if I used a series of String constants stored in the exception’s message attribute.

Some camps would argue against the inner enum (is that the way to say an enum defined as an inner class?). Their reasons would center around the usage syntax. I actually feel the opposite way; the syntax I have to use since it’s defined as an inner enum reads really well in my opinion:

1
2
3
4

if (cname == null) {
    throw new InvalidChannelNameException(cname,
        InvalidChannelNameException.Reason.IS_MISSING);
}

Also realize that using an enum lets IntelliJ only show me the enum values when I get to that parameter. There’s no need to hunt around for the possible constants.

Once the extra information was in there, it was just a matter of getting the UI to display a custom message based on what actually happened, cleanly using a switch statement since I’m using enums.

1
2
3
4
5
6
7
8
9
10
11
12

catch (InvalidChannelNameException ferengi) {
    switch (ferengi.getReason()) {
        case IS_MISSING:
            errors.add(ActionMessages.GLOBAL_MESSAGE,
              new ActionMessage("edit.channel.invalidchannelname.missing"));
            break;
 
        case REGEX_FAILS:
            errors.add(ActionMessages.GLOBAL_MESSAGE,
              new ActionMessage("edit.channel.invalidchannelname.regex"));
            break;
[snip]

Again, IntelliJ can auto-complete here, this time only showing the possible values (i.e. the enum values) each time I start a new case clause.

1
2

// why can't I just pass in a dictionary? sigh, there are
// times where python would make this SOOOO much easier.

To give this some context, this was seen above a manual population of attributes in a bean from a map.

I don’t really have any witty comment on this one. There are definitely times where one language would be nicer than another, so I’m in no way saying the comment is incorrect in any way. It just usually makes me laugh to find conversational comments like this, as if you could actually hear the developer sigh when typing out the wordy bean copying.

Just came across the following:

1

sa.setRemainingTries(new Long(10)); // hmm 10?

Not sure what the issue is with using 10 here, but for some reason it invoked the image of The Thinker.

The Spacewalk team doesn’t seem fond of the @author tag on its Java classes. I’ve heard the mentality before… “No one owns the code”… “Everyone should feel able to change it”… “You can find it out who wrote it from the source control system”… and so on.

The last rationale is especially funny to me, since on both projects where this argument was made, the code was moved to a new repository at one point and all history before that date was lost, including the original author.

I personally find the @author tag useful in finding out who to ask about a particular class. Thankfully, the Spacwalk team is pretty good about remembering who is an expert on what and I’ve never had an issue. So despite my objections, I’m fine with not using @author tags.

Then I come across this nugget in our codebase…

1

// /me wonders if this shouldn't be part of the query.

The /me is actually the way to emote in IRC. It is basically used to indicate you’re “doing” something rather than saying something as in a normal chat. So syntactically, I’m not confused by why the comment is phrased that way.

What I did find myself asking, out loud no less, was who the hell “me” is in this particular case.

I’m a huge fan of these sorts of inline comments as I’ve alluded to before. But one thing I forgot to mention was that I often throw my name or ID after the comment for comments that are expressing a concern or a personal belief. That way, if the code comes under review, you can ask the commenter their mentality or if the issue still applies.

Perhaps even more important is the date the comment was made. With as rapidly as things change in most projects, it’s not a surprise that a thought or comment that used to apply no longer applies. Scoping the comment to a particular time frame helps whoever stumbles upon it realize it may not still apply. It can save the next dev a lot of time wondering why a comment is saying to add something that may no longer exist.

Or, perhaps using /me is just meant as a brainwashing technique. I’m going to add a comment /me buys Professor Jay a beer to my next commit to see if it really works. And if it does, I’m enrolling my wife in my class next semester and teaching her to be a programmer.