Duffblog 2.0

Cookie handling with Apache XML-RPC

noreply@blogger.com (Brian Duff) — Fri, 10 Jul 2009 02:14:00 +0000

The example on the Apache website that explains how to pass cookies when calling an XML-RPC service is unfortunately... a bit b0rked. It doesn't compile, for starters. It's also quite a bit more complicated (and handwavy) than it needs to be. I don't know if this is because the API has changed over time. I tend to think it has suffered the copy-paste equivalent of chinese whispers from an origin in some mailing list.

Anyway, I needed to send a single sign on (SSO) cookie to an XML-RPC service recently. I'm using Apache XML-RPC 3.1 (I notice in the Javadoc that this code might be slightly different if you're using a later version). Here's roughly what I did:

First, the standard, boring stuff:

XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl();
config.setServerURL(new URL("https://myservice.com/api"));
XmlRpcClient client = new XmlRpcClient();
client.setConfig(config);

Now, the juicy part. It's really, really easy. Look, ma, so much less code than the example on the ws.apache.org website, and it's even syntactically correct!:

XmlRpcTransportFactory factory = new XmlRpcSunHttpTransportFactory(client) {
  public XmlRpcTransport getTransport() {
    return new XmlRpcSunHttpTransport(client) {
      @Override protected void initHttpHeaders(XmlRpcRequest request) throws XmlRpcClientException {
        super.initHttpHeaders(request);
        setRequestHeader("Cookie", myLovelyCookieData);
      }
    }
  }
};
client.setTransportFactory(factory);

Update: Fixed a bug in the code. Oh, the irony. That'll teach me to be so arrogant :P

Find a file inside a zip

noreply@blogger.com (Brian Duff) — Fri, 05 Jun 2009 02:15:00 +0000

Brutally simple shell script I often use to find a class file that I know exists somewhere in a directory tree full of jar files (but generally useful for finding files somewhere in a directory tree of zips):

#!/bin/bash                                                                             
                                                                                        
for zip in $*                                                                           
do                                                                                      
  echo $zip                                                                             
  for file in $(unzip -Z -1 $zip)                                                       
  do                                                                                    
    echo "$zip:$file"                                                                   
  done                                                                                  
done

I put this in a file called zipdump, then do things like this:

find -name "*.jar" | xargs zipdump | grep SomeClass

And get:

./some/random/path/foo.jar:com/google/whatever/SomeClass.class

Listing Chinese Words by Frequency of Use

noreply@blogger.com (Brian Duff) — Thu, 14 May 2009 00:38:00 +0000

A commenter on my previous blog entry, Yong Huang, pointed me to some wonderful research he did using search engine results to compile a list of Chinese characters in frequency order. I managed to miss his comment when he posted it back in March (d'oh. I really should have paid more attention to my blogger settings), but it's an interesting read and technique:

http://yong321.freeshell.org/misc/ChineseCharFrequency.html

Getting serious about Mandarin

noreply@blogger.com (Brian Duff) — Sun, 11 Jan 2009 22:02:00 +0000

I'm finally making a big effort to learn mandarin properly. In addition to taking formal lessons at UC Berkley starting in February, and learning about usage from Cindy, I'm using flash cards to increase my knowledge of Chinese characters and their mandarin pronunciation (including the tones, which I've had a hard job remembering up till now while picking up mandarin informally through random conversation).

I've been using some tricks to memorize characters, and this technique seems to work well for me.

Here's the first set of characters. The first ten are numbers, and mostly pretty easy.

一二三

one (yi1), two (er4), three (san1). These are quite possibly the simplest Chinese characters ever. :)

四

four (si4). This one is kind of easy for me to remember, since I visited sichuan last year, and this character was everywhere :) It's also a box with four sides.

五

five (wu3). I convinced myself that this character has five distinct lines in it, which made it easy to remember (although it actually has only four strokes - the middle horizontal line and the smaller vertical line are combined together as a single stroke).

六

six (liu4). I found this one a bit tough. I sort of convinced myself that it looks like a lion (the sound liu4 is a bit like the English "leo", as in "Leo the Lion").

七

seven (qi1). This was tricky too. Until I turned my flash card upside down and realized it looks like an upside down 7 with a stroke through it. Nice.

八

eight (ba1). No tricks here, I just remember this character because it's pretty simple.

九

nine (jiu3). With the right amount of squinting, this character looks like a roman J and lower case i without the dots and with a weird line connecting the J to the top of the i. So if you can remember that jiu3 == nine, it's pretty easy.

十

ten (shi2). If you have Chinese friends, you might notice that sometimes when they say "ten", they make a hand gesture where they cross both index fingers over each other. If you ever wondered why, this character is the answer :)

And here's a random sampling of two more non numeric characters:

问

ask (wen4). This combines the character for door (门 men2) with the character for mouth (口 kou3). Can think of it as opening the door of your mouth to ask a question. The sound (wen2) is also similar to the sound for door (men2).

好

good (hao3). This combines the characters for female (女 nü3) and offspring / son / child (子 zi3). I guess that's good and harmonic.

Anyway, lots more where those came from. Kind of fun to learn.... :)

Still a bit proud

noreply@blogger.com (Brian Duff) — Fri, 12 Dec 2008 04:10:00 +0000

Looking at Steve Muench's blog with its screenshot of JDeveloper 11g production makes me feel a little bit proud of what we built. Somehow I left Oracle with the feeling that I hadn't been very productive for a while, but seeing what Steve posted reminded me that the team really poured a lot of stuff into 11g.

Just visually from the screenshot, you can see the new look and feel I implemented based on a design from our talented visual design team. It got a lot of flak (experience is teaching me that fear or dislike of change is a very common trait), but apart from being unbelievably blue, I think it's quite attractive.

Also shown in the screenshot is quick search (which, honestly, we always referred to internally as "Google-like search". Hehe). This was something I wanted and so hacked together on a lazy afternoon without any kind of design or project plan while we were supposed to be in bug fixing mode. Despite its birth, it somehow made it into the final product in a very visible way. A very talented member of the team (Neil) did some fantastic work improving the visual design of the component while I was buried under classloading related tasks. One of the things I loved about the JDev team in the early days was the freedom to do this kind of innovation. Although that flexibility to innovate had been almost entirely crushed by the time I left, you could sometimes still get away with it and succeed.

Finally, Steve blogs elsewhere about log window search, which people begged and begged for until we finally relented and I was assigned the task late in the day.

I'm still very proud of these things, and even prouder of all the other innovations my old team implemented.

The Consequences of Job Hopping

noreply@blogger.com (Brian Duff) — Sun, 07 Dec 2008 21:57:00 +0000

I was pretty comfortable, and definitely not bored in my old job. Had a lot of stuff to do. The trouble though with saying in the same role for a very long time is that it's really hard to find time, reason, or energy to step outside your main job responsibilities a little bit and learn something new. I must have encountered a gazillion technologies and products that I really wanted to get a chance to play with but never did.

I wasn't sure when I quit my job at Oracle that working at Google would be any different necessarily. I felt like I'd probably swap my old batch of responsibilities for a new batch of responsibilities, and it would kind of be similar (but hopefully more fun). One thing I somehow failed to realize was that the really great thing about changing jobs is that it gives you that rare chance to really stretch a bit and learn something new.

So in my three months at Google so far, I've been able to get to know some fun new stuff. And instead of just reading about this stuff, I actually get the chance to play with it all the time. For me, this experience has reignited my passion for learning. I'm hoping that I can keep up the momentum.

Here are a small subset of the things I've learned about and used so far (not necessarily all Google technologies):

GXP is a templating engine that's really useful for putting together dynamic web pages. I never got much of a chance to play with JSP, JavaServer Faces etc. before. I like that GXP is straightforward and easy to use. Haven't built anything spectacularly complex with it yet, but it works fantastically well for simple dynamic web content.
IntelliJ Plugin API. I'm still getting my head around this. It's familiar to me in many respects (there seem to be only so many ways of designing IDE plugin APIs). The API is a tad on the underdocumented side, and there sometimes aren't enough samples. I'm really learning "from the other side" what it's like to have a plugin API without source code. I really wished we'd been able to do better about that at Oracle with JDeveloper, and I hope one day JetBrains might see the light too, and make it easier for its plugin developers by giving them access to source code. But it's still a nice API, and you can get a lot done with it.
SWT. I've been using Swing for 10 years, and somehow got into the "SWT is evil" mentality without really giving it a chance. It's actually a pretty fine API for most UI problems. Slightly depressing to see that layout seems to be an intractable problem that all widget toolkits seem to have trouble making straightforward.
BigTable is cool :)
Google Chart API makes it really easy to draw pretty graphs 'n charts 'n stuff
Debian package management
GNU Fortran don't ask. hehe.

Well... that's not a comprehensive list, but I think I've been able to learn quite a bit more over the last few months than I did over about a year or two. Changing jobs is good for your brain :)

Brings back memories

noreply@blogger.com (Brian Duff) — Fri, 21 Nov 2008 18:38:00 +0000

Ah... this brings back memories: Feel motivated yet? (via: http://thebode.blogspot.com/2006/07/demotivation.html)

Shirley that's not Shirley

noreply@blogger.com (Brian Duff) — Tue, 09 Sep 2008 22:03:00 +0000

Warning: herein lie spoilers!

Somewhat surprised to see Shirley Manson, Scottish lead singer of rock band Garbage show up in the second season premier of Fox's Terminator: The Sarah Connor Chronicles last night. Bit of a "holy crap, that's Shirley Manson" double take when the scene opened on her as an evil CEO who actually turns out to be a T-1000 model terminator (T-1000 is the gloopy, liquid metal model that Robert Patrick played so well in Terminator 2) hell bent on bringing about the Rise of the Machines.

Haven't quite figured out yet whether she's a good actor or not... She certainly came across as kind of cold, dominating, fearsome, and a little stiff. At first, I thought her acting was a bit iffy, but the reveal that she's actually a T-1000 sort of changed my perception a bit.

Was really nice hearing a genuine Scottish accent on US network television too. Scottish actors don't get to play the Bad Guy (or Lass) in TV sci fi nearly often enough. Witness the saccharinely well behaved Carson Beckett from Stargate Atlantis (Paul McGillion's accent is also faaar from genuine, probably on account of the fact that he moved to Canada when he was 2)

Nooglerization done (but is it ever, I wonder... ;) )

noreply@blogger.com (Brian Duff) — Tue, 09 Sep 2008 04:12:00 +0000

My first two weeks are over, now I'm taking a quick bout of unpaid leave to take Cindy to Paris and Barcelona. She's never been to europe - and even though I'm from Europe, it's a big place and I've never really spent much time in those two cities. We're also going to spend some time with my parents in the south east of Spain.

Cindy swears that I've put on weight in the mere two weeks since I joined google on account of the free food. This is an assertion which I stringently deny, alas to no avail. I try to convince myself that all of the cycling between buildings (or walking in the fairly regular no-available-bikes scenario) is burning off enough calories to make up for the additional input. I may or may not be kidding myself.

I've been using the convenient excuse that, since it takes some period of time after initial employment before registering for the gym is possible, working out and getting rid of the extra pounds is something I can put off until after our vacation.

Anyhow, looking forward to taking a break, and then getting down to some serious geekyness (er.. geekery?) when I get back. I haven't written code for a while, and my fingers are getting twitchy.

On shortcuts

noreply@blogger.com (Brian Duff) — Thu, 07 Aug 2008 22:07:00 +0000

I made the Big Switch from Windows to Linux at work several years ago, and never really looked back. For whatever reason, our version control system and builds are always about twice as fast on Linux compared to Windows. I'm also much more comfortable in a UNIX-y shell / scripting environment than I am in Windows Command Prompt, probably because of hours spent in various computer labs at university when I really should have been doing something more fun (like drinking beer).

As well as the raw productivity gain from the faster environment, I also customized my environment a great deal to minimize keypresses. For example, where most other people in my team might type something like this:

cd $ADE_VIEW_ROOT/jdevadf/modules/ide/src/oracle/ide
ade co -nc Ide.java MainWindow.java
cd `pwd`
emacs Ide.java MainWindow.java
cd $ADE_VIEW_ROOT/jdevadf
make release

I type:

m ide/src/oracle/ide
co Ide.java MainWindow.java
emacs Ide.java MainWindow.java
jdevadf
mrel

Doesn't seem like much, but over many many months and years of coding, all those extra keystrokes add up... Better still, I had some immensely powerful tools in my box that would invoke compound commands to provide interesting information.

So, if I wanted to quickly find a file in our source control system (an operation that can be sped up by grepping some version control metadata files, chopping the file up to make it readable), I'd type wi SomeFile.java (where is?). If I wanted to know which module (out of about 600 in our system) was responsible for delivering a jar file (again which involved a lot of grepping through multiple files and cleaning up the output), I could ask wm foo.java (which module?).

These utilities ran ridiculously quickly, because I figured out tricks that were somewhat specific to our system. For example, grepping the version control files to locate a file is way faster than using "find", since it's a grep on a single file instead of a directory tree traversal. Their real power was in compound commands. I could check out all files with the extension xml that contained the string "brian.duff" with a command like this:

wi '\.xml$' | xargs grep -l 'brian\.duff' | xargs co

This is all fine and great, but there's a huge downside. Every time I sat at someone else's terminal to help them with some problem and attempted to run some commands, I had to remember to type the longwinded versions of all these commands again. Like being thrown back into the dark ages. Worse than that, it actually slowed me down even compared to someone without the shortcuts, since my fingers would frequently forget and type my shortcuts instinctively even though my higher brain was fully aware that they wouldn't work. Finger memory is a strange thing.

AWT Freudian Slips...

noreply@blogger.com (Brian Duff) — Mon, 12 May 2008 23:18:00 +0000

BufferedImage image = new BuggeredImage(...

Newsmap

noreply@blogger.com (Brian Duff) — Sat, 24 Nov 2007 01:56:00 +0000

Newsmap is a really neat way to visualize news headlines available via the Google News RSS feeds.

Configuring Mac OS X Terminal

noreply@blogger.com (Brian Duff) — Fri, 23 Nov 2007 06:20:00 +0000

I recently installed Leopard (Mac OSX 10.5) on a new mac. There are a few factory settings I usually change on a new installation, although by far fewer than I do typically with Windows. One of them is the default keyboard configuration for Ctrl+Left Arrow, Ctrl+Right Arrow, Page Up, Page Down, Home, and End in Terminal. The default settings drive me a bit potty since I'm used to using Linux and emacs every day at work.

Changing them is easy, fortunately. Just visit Keyboard under Settings in Terminal->Preferences, and modify the following keys, so that their action matches the value shown. You can edit the keystroke for an item by double clicking on it, selecting "send string to shell", and typing the indicated keys.

Key	Action	Keystrokes
control cursor left	\033b	ESC b
control cursor right	\033f	ESC f
end	\005	CTRL+e
home	\001	CTRL+a
page down	\026	CTRL+v
page up	\033v	ESC v

Detecting Concurrent Changes with the Decorator Pattern

noreply@blogger.com (Brian Duff) — Thu, 15 Nov 2007 01:36:00 +0000

Recently, our bug tracking system started receiving reports of a ConcurrentModificationException. The API in question was only ever supposed to be used on one thread, and yet a caller somewhere was making modifications on a background thread.

One thing that makes it tricky to diagnose this kind of problem is that a ConcurrentModificationException thrown during iteration only tells you that a concurrent modification was detected. But no information is present in the stack trace about where the rogue write actually happened. Wouldn't it be nice to have something like this?

java.util.ConcurrentModificationException
  at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
  ...
Caused by: java.lang.Throwable: List modified
  at ...
  at org.foo.SomeRogueCaller.writeOnTheWrongThread(SomeRogueCaller.java:30)

It's pretty easy to do this using the decorator pattern. The basic idea is to write a decorator for java.util.List that records a stack trace when modifications are made to the list, and sets the trace of the last modification as the cause of any ConcurrentModificationException thrown while iterating.

I used the Google Collections Library as part of my implementation, primarily because its ForwardingList, ForwardingListIterator and ForwardingIterator base classes make it really easy to decorate the respective collections classes.

So the basic idea is to write a decorator that can audit writes. I created a subclass of ForwardingList that stores a Throwable representing the last modification. The audit method will be used to record modifications, and the setLastModificationAsCause method is used to initialize the cause of a ConcurrentModificationException to the last modification (if any).

final class AuditedWriteList<E> extends ForwardingList<E> {
  private Throwable lastModification;

  protected AuditedWriteList(List<E> delegate) {
    super(delegate);
  }

  private void audit() {
    synchronized (this) {
      lastModification = new Throwable( "List modified" );
    }
  }

  private void setLastModificationAsCause( Throwable t ) {
    synchronized (this) {
      if ( lastModification != null ) t.initCause( lastModification );
    }
  }

  // ...
}

Now, we override all List methods that modify the list, and make them audit. For example, here's the implementation for add(E):

@Override
public boolean add( E object ) {
  audit();
  return super.add( object );
}

Finally, we implement the iterator() and listIterator() methods to return a decorator Iterator and ListIterator respectively that catches a ConcurrentModificationException and calls the setLastModificationAndCause method:


@Override
public Iterator<E> iterator() {
  return new AuditingIterator<E>( super.iterator() );
}

// Inner class
private final class AuditingIterator<T> extends ForwardingIterator<T> {
  protected AuditingIterator(Iterator<T> delegate) {
    super( delegate );
  }
  
  @Override
  public T next() {
    try {
      return super.next(); 
    } catch ( ConcurrentModificationException e ) {
      setLastModificationAsCause(e);
      throw e;
    }
  }
}

Now, if we do something like this:

List<String> list = newAuditedWriteList( Lists.newArrayList( "One", "Two", "Three" ) );
for ( Iterator<String> i = list.iterator(); i.hasNext(); ) {
  i.next();
  list.add( "Four" );
}

We get a helpful stack trace telling us exactly where the modification took place. The beauty of the decorator approach is that the only change we made to our client code was to wrap the creation of our list with the call to newAuditedWriteList. Since this diagnostic is likely to be slow when there are a lot of writes, it could be conditionally turned on in debug environments.

The full source code is available in the dubh-examples google code module.

San Francisco Walk: Bay Bridge to Golden Gate

noreply@blogger.com (Brian Duff) — Mon, 03 Sep 2007 08:32:00 +0000

I've really started to enjoy walking since I moved to San Francisco. A fun, but somewhat exhausting, walk I've done before was from the Bay Bridge to the Golden Gate Bridge. On Saturday, I wandered along the Embarcadero just to get coffee at the Ferry Terminal, but since it was a nice day, just kind of kept on going. Five and a half hours later, I arrived back home with slightly sore feet...

Since I like to engage geek foo with such things, I plotted out the route of this walk (in blue; the red line is another long walk I took last year) on Google Maps:

View Larger Map

All in all, it was a great walk. Had some really nice euphoric moments. My iPod was playing uplifting songs, the sun was setting over the Golden Gate Bridge, and it felt pretty good to be living here...

Java Blooper #2 Solution: Must be a Better Way

noreply@blogger.com (Brian Duff) — Sat, 25 Aug 2007 22:15:00 +0000

Sorry for the delay in this week's blooper solution. On Monday we saw this code:

boolean hasThing( List things, Thing thing ) {
  for ( int i=0; i < things.size(); i++ ) {
    if ( thing.equals( things.get( i ) ) ) {
      return true;
    }
  }
  return false;
}

Can we simplify this? Sure. It pays to know the class libraries well, and the collections framework in Java in particular:

boolean hasThing( Collection things, Thing thing ) {
  return things.contains( thing );
}

As well as being more compact, this idiom is safer if the collection is a synchronized wrapper (as pointed out by reader alex in the comments). We were also able to specify the things parameter as a Collection rather than a List, following item 34 in EJ ("Refer to objects by their interfaces"), since we no longer need the ability to iterate items in the collection by index, which may well have been inefficient depending on whatever implementation of list was passed to us.

Blog readers jeff and Mike Kaufman also pointed out that this code doesn't check parameters for validity. Specifically, if this is a public method, it should check if the two parameters are null, or document the behavior when they are null in its javadoc.

Indeed, the whole method itself is very likely to be unnecessary in this particular example. But only because I super-simplified the original code, which of course contained some side effects. Joy :)

Back on Monday with another blooper...

Java Blooper #2: Must be a Better Way...

noreply@blogger.com (Brian Duff) — Mon, 20 Aug 2007 07:49:00 +0000

It's Monday, which means it's time for another blooper... What's wrong with this code?

boolean hasThing( List things, Thing thing ) {
  for ( int i=0; i < things.size(); i++ ) {
    if ( thing.equals( things.get( i ) ) ) {
      return true;
    }
  }
  return false;
}

Update: Minor edit to add missing parenthesis from if statement that got "lost in translation" en-route to the blog :)

Java Blooper #1 Solution: Ternary Insanity

noreply@blogger.com (Brian Duff) — Fri, 17 Aug 2007 19:29:00 +0000

class Thing {
  private boolean _visible;

  boolean isVisible() {
    return _visible ? true : false;
  }
}

This code is unnecessarily using the ternary conditional operator when it's not needed.

Occasionally developers get so captivated by the expressiveness of this operator that they find it tempting to use it when it's not really needed. In this particular example, it almost looks like the original writer forgot that the type of the _visible field was boolean anyway and could just be returned directly:

class Thing {
  private boolean _visible;

  boolean isVisible() {
    return _visible;
  }
}

The Ups and Downs

noreply@blogger.com (Brian Duff) — Wed, 15 Aug 2007 05:34:00 +0000

Great news first thing this morning... I'm now a permanent resident of the United States! The whole process was a lot less painful than I'd expected. It was a terribly exciting start to the day.

In other news, I lost $1,000 in my portfolio today as the market continues to plummet. Ouch. My finger is twitching over the sell button ;)

Java Blooper #1: Ternary Insanity

noreply@blogger.com (Brian Duff) — Mon, 13 Aug 2007 06:30:00 +0000

From time to time, we all write code that could be clearer. Sometimes in the rush of solving a problem, we don't pay attention to the micro details of the code flowing from our fingertips. Other times, we refactor some existing code, and don't necessarily take the opportunity to clean up as much as we could.

I find it useful sometimes when reading code to think about whether it could be rewritten in a more straightforward way, and if so whether any lessons can be learned about writing tight and expressive, and most importantly, readable code.

Over the next few weeks, I'm going to blog weekly examples of some Java code bloopers that I've seen. All the examples are real and have been observed "in the wild". However some have been simplified somewhat to make a point. I'll post each blooper on a Monday, and follow up with a rewritten version the following Friday.

Most of the examples are pretty simple, and easily cleaned up - feel free to post observations as comments to the entries, and don't be shy to smack me down on the solutions if there's a better way to express the same thing.

The first installment is called Ternary Insanity.

class Thing {
  private boolean _visible;

  boolean isVisible() {
    return _visible ? true : false;
  }
}

More on email inbox bliss

noreply@blogger.com (Brian Duff) — Thu, 26 Jul 2007 01:41:00 +0000

So far my attempt to maintain an empty inbox is working out pretty well.

One of the most effective things that worked was to get rid of folders. Previously, I was a folder freak: my email was "organized" into a bewildering, ever changing, hierarchy of folders. Rather than making it easier to find stuff, it was actually much harder. Before I could find something quickly, I had to try to figure out which folder I had decided to put it into.

I draw a comparison between this and usage of, say, Google Search vs. a directory service like dmoz. Directory services categorize the web into a wonderful hierarchy. But in practice, it's almost always more effective to just search the conceptual single folder containing the whole web via google search.

I now have a small number of folders. Apart from the inbox, trash, and sent folder, the remaining folders can be categorized as:

A single @Respond folder. Messages that I need to respond to, but can't do so immediately because they require some investigation go here. I treat this like a todo list, and review it several times a day.
A single Archive folder. Anything that I don't need to keep track of actively, but might be interesting for future reference goes here. This is where the vast majority of email that I don't delete ends up.
Important short term projects for which it's convenient to collocate all the messages. I currently have a single folder that falls into this category, for tracking correspondence related to my green card application. Although I have several other important short term projects, none of them really need a separate folders.
High-volume, low value mailing lists auto filters. For instance, I have a folder called Bugs into which gets automatically filtered all notification emails from our bug database system. I rarely have to act immediately on such emails, but it's useful to review them once or twice a day. I usually mass delete the contents of these folders on a daily basis, since they're basically copies of information available elsewhere.

As a result of this, I now have roughly 5 folders (not including inbox, trash and sent). This works well for me. It speeds up the rate at which I can process incoming email, since there are fewer choices about which action to take for each incoming message.

Merlin Mann's 43 Folders site talks about this a lot. His recent tech talk on Inbox Zero summarizes a lot of the useful content related to email management posted on the site.

Google Code Project Hosting Gets Upgrades

noreply@blogger.com (Brian Duff) — Fri, 20 Jul 2007 09:21:00 +0000

The folks over at Google Code have been doing some sterling work in the last few weeks fixing various issues with its project hosting support. Here are some of my favorite fixes:

Issue 250: Issue summaries are unnecessary abbreviated. In the issue list, the summaries would be truncated arbitrarily. This was pesky on a large display, since there was plenty of space to see the whole summary.

Issue 138: projectname.googlecode.com should redirect to project page. So now you can go to jd-ant.googlecode.com as well as code.google.com/p/jd-ant.

Issue 306: IssueTracker: Provide a means of displaying more than 25 issues at a time. Now you see 100 issues at a time, which makes for less paging about in large issue lists.

Glad to see these improvements. Google's project hosting is straightforward, fast, and very useful.

Asserting Control over the INBOX

noreply@blogger.com (Brian Duff) — Fri, 06 Jul 2007 15:48:00 +0000

Sometimes I'm a bit disorganized. Last week, after purging my INBOX of some 15,000 messages (discovering quite a few that I had read but not replied to in the process), I decided that it's finally time to assert control over my INBOX.

It's not the first time I've tried this. The lofty goal of maintaining an empty INBOX is very appealing in theory, but it's easy to get lazy. Before you know it, you end up with thousands of disorganized messages again.

The first step in this was turning down my "autocheck" frequency. I think a big part of the reason that I'm a bit disorganized is that email messages arrive in a constant stream throughout my day, and so I'm always processing them while doing other tasks.

My approach now is to set aside 5-10 minute periods every hour or so specifically for triaging email. Any email I can respond to, or action, within that period, I do so immediately. Anything else, I add to my TODO list on the excellent Remember the Milk service, and then archive the message to a folder.

The second part of this is making it easy (and I mean really easy) to archive messages. For any message I read in my INBOX, I must do one of the following immediately:

Delete it if it's spam, or automated email that I don't care about
Reply to it if it can be actioned within the 5-10 minute email period, then archive it to a folder or delete it.
Add a TODO item, then archive it to a folder.

I've pared down my list of folders to a minimum (3 main folders, with some extras for server side filtered automated email) so that it's easier to figure out the destination for any given message. Thunderbird makes it really easy to search for messages within a folder, so I realized that having a gazillion hierarchical folders was actually making it harder to find old messages.

To make it really easy to quickly move messages into a folder, I'm using the excellent keyconfig extension for Thunderbird to map a single keystroke to moving messages to a folder. For example, I can now hit Ctrl+J on a message to immediately move it to my "JDeveloper" folder. I can't overstate how useful this is. It's probably the single most effective thing I've done to make it easier to control my INBOX.

Scary Statues

noreply@blogger.com (Brian Duff) — Sun, 10 Jun 2007 13:06:00 +0000

It may have something to do with that odd tradition they have in the USA of completely shutting down all decent television programs for a block of about four months in the summer and the result that my DVR is being seriously under-used at the moment, but I'm really getting into the latest series of the new Doctor Who.

I've been an unabashed fan boy of Doctor Who since I was small enough to effectively hide behind our rather brown, early-eighties sofa in Edinburgh watching Tom Baker, Peter Davison, Colin Baker and Sylvester McCoy do their turns as the Gallifreyan time lord. I'm pretty sure it was the seed of my life long addiction to science fiction books and so-called telefantasy TV shows.

When the series came back a few years ago, I was desperately excited. That excitement carried me through most of the first two series. Even though to be frank, some of the storylines and episodes were pretty poor, with the odd gem here and there (Dalek, Father's Day, The Empty Child, The Parting of the Ways, New Earth, School Reunion, The Girl in the Fireplace, and Love & Monsters).

I don't know what changed in the third series. Certainly, the Doctor has a new companion in the form of Martha Jones (played with wonderful enthusiasm by Freema Agyeman). But the episodes in series three seem to be consistently better than the previous two series. The episodes have that creeping, mysterious fun and fear in exactly the combination that was common in the golden days of the old Doctor Who.

Take this week's Blink for instance. Statues. Terrifying, monstrous, looming, weeping angel statues that "kill" people by sending them back in time.

In common with one of my other favorite episodes with the new Doctor, Love & Monsters, this episode doesn't actually feature the Doctor and his companion much at all (they're stuck in 1969, having been transported there by the statues while the TARDIS remains in the present day). Thanks in great part to the fine acting of guest actress Carey Mulligan as Sally Sparrow, the episode remains riveting (not to mention sofa-hidingly scary. I actually yelled out in fear at one point, which isn't something I'm taken to do on a regular basis).

And last week we had seriously spooky scarecrows... This new series just keeps getting better :)

Test From Adobe Contribute

noreply@blogger.com (Brian Duff) — Mon, 04 Jun 2007 14:35:00 +0000

Just a little test entry. I just took the plunge and upgraded my Macromedia Studio 8 to Adobe Creative Suite 3, so I'm testing out Adobe Contribute (which was completely dysfunctional in its previous incarnation with blogger).

Seems pretty nice so far. Rather scarily, I'm sort of editing this blog entry in-place (or at least, that's the intent of the UI illusion it creates). Quite nifty.

Notice that there's no spell checking though, which is definitely a step down from regular blog posting via an HTML form with Firefox. Boo.