Awhile ago, I embarked on an effort to build yet another build tool, this one in Scala. I shelved that effort, and I’ve switched to SBT, instead.

(Each line was a single subject from my spam folder, on May 16, 2009.)

I’ve been using Unix-like systems for a long time, and one of the attractions of going with a Mac (aside from being able to run Photoshop on a platform other than Windows) is that Mac OS X is, essentially, a flavor of Unix.

Naturally, as befits someone who’s been using Unix systems for nearly a quarter century, I spend time a lot of time at the command line, even on a Mac. But there, my muscle memory betrays me.

Scala’s command-line interpreter (its REPL) is highly useful, but if you’re accustomed to readline, you’ll find it lacking and frustrating. Scala 2.8 is enhancing the REPL, but in the meantime, here’s a handy trick.

Instead of typing

$ scala

try this, instead:

$ rlwrap scala -Xnojline

By disabling JLine and invoking Scala via rlwrap, you get full readline capabilities in the Scala REPL.

On Windows, you can install the Cygwin version of rlwrap; it seems to work just fine in my tests.

Thanks to Tony Morris for posting this tip to the scala-user mailing list.

Introduction

I’ve been using Python in a large-scale, high-throughput, high-availability network application. Scalability is an issue: We ultimately have to be able to process a large number of requests a second. The JVM seems easier to scale than CPython, at least for what we’re doing; it has real threads, for instance, instead of the crippled threading in CPython. But our code base is already large, it’s almost entirely Python, and it makes heavy use of the Twisted Python libraries.

This article describes a small series of benchmarks I ran, to test how many requests per second I could process using deliberately naive servers written in Python and Scala. I chose Scala, rather than Java, because:

• Like Java, Scala compiles directly to JVM byte code.
• The Scala language is, in my opinion, a much better language than Java. (Having written Java exclusively for nearly nine years, I have some experience on which to base that assessment.)
• It’s easier and faster to write concurrent programs using the Scala Actor library than it is to use the java.util.concurrent library.

These test programs are deliberately simple-minded. They accept incoming socket connections and send back canned HTTP results.

I’ve decided to write a build tool in Scala.

(Update: No, I haven’t. See below.)

Because I don’t like Ant

For awhile now, I have truly disliked Ant, the standard build utility for Java. Ant (and Maven) use XML build files, which means you’re often standing on your head to get around limitations imposed by the choice of XML as a syntax.

We live in bizarre times. I got home around 10:00 PM last night, having worked late, to find that the furnace was out. The problem turned out to be minor and easily fixed, but that wasn’t much help last night. It was 45 degrees Fahrenheit inside the house, and probably 10 degrees outside. I put a call into the company that services the oil burner, but I didn’t expect a callback that night (and I didn’t get one).

So, I lit a fire in the wood stove and sat down with my laptop to read email and watch a (legally) downloaded TV show. Given the age of my house (it was built circa 1870), it felt like an odd mixture of modern day and Victorian times (a la “Brazil”).

I slept in the living room, near the fire, thankful for the extra body heat imparted by my canine buddy, Basil.

Primitive heat, but modern Internet access. Go figure.

In nearly nine years of programming Java, it never really occurred to me to use it in an interpretive fashion. If I needed to test an API, I typically wrote a quick and dirty throwaway tester, compiled it, and ran it. That was my mindset at the time.

However, for the last year, I’ve been programming Python almost exclusively, and I find I’ve grown accustomed to running quick tests in the ipython command-line interpreter. Now, with my mindset suitably changed, I want the same capability when I’m doing Java work.

There are, of course, many Java-based scripting languages, and many are perfectly suitable for this kind of thing.

For example, I wanted to test a Java JSON library (the one at json.org). What better way than with Jython?

$ jython
Jython 2.5b0+ (trunk:5882, Jan 8 2009, 12:18:58) 
[Java HotSpot(TM) Server VM (Sun Microsystems Inc.)] on java1.6.0_03-p3
Type "help", "copyright", "credits" or "license" for more information.
>>> from org.json import *
>>> j = JSONObject({'a' : 1, 'b': [1, 2, 3], 'c': {'x': 0, 'y': 'a'}})
>>> j
{"a":1,"b":[1,2,3],"c":{"x":0,"y":"a"}}

That sure beats writing and compiling a tester, just to verify how something works. Plus, Jython/Python’s brevity of syntax is great for this kind of thing. The {} dictionary in Python translates to a HashMap. The last line (”j”) just tells the interpreter to call Python’s str() method on “j” – which Jython translates to a call to JSONObject.toString(), which is exactly what I want.

Groovy also has both power and syntactic brevity:

$ groovysh
Groovy Shell (1.6-RC-1, JVM: 1.6.0_03-p3)
Type 'help' or '\h' for help.
-------------------------------------------------------------------------------
groovy:000> j = new JSONObject(["a" : 1, "b": [1, 2, 3], "c": ["x":0, "y": "a"]]
===> {"a":1,"b":[1,2,3],"c":{"x":0,"y":"a"}}
groovy:000> j
===> {"a":1,"b":[1,2,3],"c":{"x":0,"y":"a"}}

And, of course, you can do the same things with Scala, my new favorite language on the JVM.

Frankly, I don’t know why I didn’t think of using these tools more when I was programming Java full-time. However, I’ll sure use them now, when I find myself working in Java. The ability to run quick tests without writing a full-blown tester is just too useful to pass up.

A short time ago, colleague and friend, Mark Chadwick, put together an interesting little Python tool he calls eventter. Basically, it’s a small API around a simple UDP broadcast messaging protocol. An eventter sending process emits a message, and all eventter listeners on the local network receive it.

If that were it, eventter wouldn’t be all that interesting. However, Mark wrote an example receiver that forwards any message it receives to DBUS. Run that receiver on a Linux machine under Gnome, and any message sent via the eventter framework shows up as a small, temporary Gnome notification.

I added two more sample receivers, one for Growl (for Mac OS X machines) and one for Snarl (for Windows machines). So the eventter distribution has adapters for Growl-like services on three major platforms.

“But what’s the point?” you ask. Well, we’ve actually found some interesting uses for eventter at the office. For instance:

• Mark installed an eventter command client as a subversion post-commit hook. Now, whenever anyone commits anything to our source code repository, everyone running an eventter receiver sees the commit message for a few seconds.
• I added a similar command line client to our CruiseControl continuous build server. Now, whenever a build completes, the name, version and status of the build (success or failure) are emitted via eventter.

I also modified my local copy of the Growl and DBUS receivers so they log received messages to a file. That way, I can quickly review what’s happened over the last hour or so, just by looking at that log file.

The UDP broadcast messages even propagate over our VPN, so someone working from home can still see them.

I’ve become rather fond of this tool. It’s simple, clean, well-written, easy to adapt, and surprisingly useful.

Introduction

I installed Wireshark on my MacBook Pro via MacPorts, because the prebuilt Wireshark package didn’t work on my machine, due to some dynamic library version conflict. However, I still wanted a Wireshark icon I could drop into my dock, to permit single-click launching of Wireshark. Long-time Mac enthusiasts no doubt could wrap a “naked” executable in their sleep, but doing so was a new exercise to me. This article describes what I did. It should work for any executable that isn’t wrapped in a Mac OS X application bundle.

Create an AppleScript application to run the program

Pull up the AppleScript editor (Applications/AppleScript/Script Editor) and enter the following script. Replace /opt/local/bin/wireshark with the full path to whatever executable you want to run.

to run
    do shell script "/opt/local/bin/wireshark"
end run

Then, save the script as an “application bundle”, as shown in the following dialog box (which comes up if you select “File > Save As” from the Script Editor’s menu).

Add an Icon

You can stop here if you want. The application you just saved will run the executable you specified in the script, and you can drag that application to the dock. However, it’s much nicer if there’s an application-specific icon. So, assuming you’ve already downloaded a PNG or some other image, here’s how to create an icon.

Convert your Image to an Icon

Your final icon will be 128x128 pixels. It’s not absolutely necessary to scale your image to that dimension, but doing so gives you more control over how the scaled image looks. In any case, once you have the image ready, bring up the Icon Composer, which you’ll find in /Developer/Application/Utilities. Drag your image into each of the boxes in the second column. In the top three rows, you will be asked about a 1-bit mask. (See below.) Select “Extract Mask” in all cases.

When you’re done, save the resulting icon to a file.

Convert the Icon to a Resource File

Download and install the open source Icns2Rsrc utility. Once its installed, run it, open the icon file you created above, and save the result as a resource file.

Change the Application’s Icon

The simplest way to change the application’s icon is:

• Right click on the icon resource file, and select Get Info.
• Right click on your wrapped application, and select Get Info.
• In the info window for the icon file, click on the small icon in the upper left. Then press Command-C to copy it to the clipboard.
• In the info window for the application, select its small icon, then press Command-V to paste the new icon.

That’s all there is to it.