Trypticon: Tag programming

Just Another Monday Morning

Trejkaz — Mon, 14 May 2007 10:13:00 +1000

Monday morning came with a request to change the company web site to American “English”.

My first thought was that we’re not a US company, so we shouldn’t need to conform to US spelling. The reasoning I got back was that US companies got scared off by British spelling.

This reasoning sounds pretty ludicrous to me, and besides, if we switch to American spelling, won’t that “scare off” the entire rest of the English speaking world?

So I thought, OK… maybe we can do this and yet not do this.

#!/usr/bin/ruby
#
# Breaks proper English spelling for the benefit of yanks.
# Word list is incomplete, but covers enough to be useful for now.

ARGF.each_line do |line|
    line.sub!(/\b(amort|apolog|author|capital|critic|emphas|general|harmon|initial|maxim|minim|optim|real|recogn|visual)is(e|ed|es|er|or|ation)\b/, '\1iz\2')
    line.sub!(/\b(anal|catal|paral)ys(e|ed|es|er|or)\b/, '\1yz\2')
    line.sub!(/\b(arm|behavi|col|flav|harb|hon|hum|neighb|sav|savi)our(s?)\b/, '\1or\2')
    line.sub!(/\b(defen|licen|offen|preten)ce(s?)\b/, '\1se\2')
    line.sub!(/\b(calib|cent|fib|kilomet|lit|meag|met|theat)re(s?)\b/, '\1er\2')
    line.sub!(/\bpractis(e|ed|ing)\b/, 'practic\1')
    puts line;
end

My only concern is that it might match an ID somewhere in the HTML which will mess the CSS up, but otherwise, it’s looking like a damn good idea.

Higher Order Messages for Mapping

Trejkaz — Fri, 04 Nov 2005 10:29:00 +1100

Say you want to convert an array of strings to uppercase. You could write

result = names.map { |name| name.upcase }

PragDave suggests an alternative which uses the Ruby Extensions Project’s Symbol#to_proc method to pass a symbol.

result = names.map(&:upcase)

This is all well and good, but can you really call it elegant? Suppose you want to add 1 to all elements in a list. How can this method let you pass in that parameter? It seems that it can’t.

Higher Order Messages (HOM) provide a better way, although a way which seems even more like magic.

The Homer project offers HOM for Ruby, and although it didn’t have a method which did something like map, it was relatively simple to whip something together.

My own version of the above functionality:

result = names.map_using.upcase

Isn’t that better? I couldn’t call it map without causing a little mayhem, having to alias the old version and still provide complete compatibility was a bit much for me at this point in time.

But better yet, this version does permit you to use parameters:

costs_with_gst = costs.map_using * 1.1

Don’t bother asking for the source code for this… I’ll be shuffling it up to the Homer project as soon as I hit submit. ;-)

Weak References Save Lives

Trejkaz — Tue, 15 Feb 2005 16:45:00 +1100

(Or, How MVC Ate My Memory)

Part of the problem with using excessive MVC in any language, and particularly with using Swing in Java, is that if you create and destroy a large number of GUI components over the lifetime of your application, you will end up with a lot of deadweight.

A na

Relative File Path Anomalies

Trejkaz — Fri, 28 Jan 2005 13:29:00 +1100

Sometimes the subtlety in Java is almost enough to be annoying.

For instance, let’s take the java.io.File constructors for today. Ignoring the versions of the constructors which take File objects themselves, you basically have a choice between three ways to construct your File path.

Use an absolute path (almost never used if you want portability, since an absolute path inevitably requires knowing what OS you’re using before you create it);
Use a relative path, providing the base path to resolve it relative to.
Use a relative path, providing no base path.

The last option is where problems will occur. Suppose you create a file:

File file = new File("foo.txt");

As you can probably guess, this is supposed to point at the file called “foo.txt” relative to the current directory. But what you might not expect, is that this is not always the case.

Suppose you have a native library loaded at some point in your application. This native library then does the unthinkable, and changes the current working directory. As soon as this happens, everything goes to shit.

System.out.println(System.getProperty("user.dir"));
File file = new File("foo.txt");
System.out.println(file);
System.out.println(file.getAbsoluteFile());
InputStream stream = new FileInputStream(file);
stream.close();

If you run this after some cretinous native library has changed the path, you’ll see something like this:

/home/trejkaz/test
foo.txt
/home/trejkaz/test/foo.txt
java.io.FileNotFoundException: Cannot find the file: foo.txt

As far as the first three lines go, everything looks okay. And looking in the current directory, you’ll see that “foo.txt” is indeed present. Yet, the file doesn’t exist… why?

Well, it turns out that non-absolute file paths are resolved relative to the new current directory. And what’s funny, and perhaps wrong on the part of the Java API, is that calling getAbsoluteFile() on that File object actually results in Java resolving it relative to the value of the “user.dir” property, instead of the real current directory. So it will appear that the file path is right, even though it’s wrong.

So this is why you should always call getAbsoluteFile() on any paths which are created which weren’t already absolute, and/or construct them relative to some other explicit path.

And I suppose it’s also why native libraries are bad, and why everything should just be implemented in Java in the first place. :-)