OCamlPAM 1.0 Released!

PAM is a slick policy-based authentication mechanism. It abstracts away the method of authentication from applications and makes it possible to change the authentication method for a deployed application/service while running instead of making that decision at compile-time. I've come to love PAM because it makes single sign-on a possibility and lets me focus on my application logic rather than the details of, say, LDAP authentication.

Since I've been playing around with Objective Caml lately and I needed to do some authentication, I wrote an OCaml wrapper for PAM. Take a look, give it a go, and authenticate away!

Power Profiling: Saving Energy in Software

I came across a pretty nifty profiling tool a little while ago called PowerTOP. It gives you a live view of the power consumed by applications running on your Linux machine in an interface that resembles top. As a system-level power profiler, it gives you an idea of which applications or drivers are waking up the CPU or preventing it from entering a sleep state.

I think this kind of tool is awesome for both developers and end-users. As a user, it tells me which applications are draining my laptop's battery so I might close those applications if I'm not using them or I might find an alternative altogether. From what I understand, some people have gained significantly higher use-times for their laptops by just killing innocuous-looking apps that don't let the processor enter a deeper sleep state. As a developer, this is good news because it will give me a quantitative measure of my application's power consumption, giving me a means to determine the power-efficiency of different designs. This tool has also managed to expose bugs in a few applications!

Check out PowerTOP, fix your applications, and keep this planet green (and my laptop running longer and cooler)!

Google Web Toolkit: a quick look

While writing the last blog post, I had a miserable time trying to get the Java snippets formatted correctly. I suppose the problem is that I'm using Blogger instead of a full-blown publishing platform like Movable Type which has plugins for code highlighting. Once I got the post up, I decided to build a web service that would take a code snippet in your language of choice and return highlighted HTML code.

Along the way, I found a neat package called GeSHi, a generic code highlighter that would make my life a lot easier. I then got the idea of making an AJAXed front-end to that along with other useful web services... Eventually, I came across the Google Web Toolkit and it looks like the Google folks are really on to something!

Now, I'm sorry to say that I've done my share of AJAX code before, both client side and server side, and it has been one of the most painful coding experiences of my life. The runtime errors, the lack of decent developer tools, the browser incompatibilites, the ridiculous workarounds... web development has been just one enormous nightmare. The guys and gals at Google managed to take a large part of that away with GWT; they're actually compiling Java code to JavaScript with all of the compile-time checks (hooray, no more typo-bugs rearing their heads at runtime!), development tools (including a debugger!), and patterns kept intact! The really nice bit is that they abstract all of the cross-browser differences via their core library. Now this is a step in the right direction for web development!

Of course, it's not a perfect system. They're building this on top of Java 1.4 so we still don't have safe container classes or enumerated values (sigh). What's more, since AJAX is event driven by nature, I think it would be so much easier to use a functional source language so we can pass functions and closures around instead of anonymous inner classes.

When goodbyes aren't enough...

The Java core classes have a pretty nasty habit of throwing IOExceptions in close methods. Since IOExceptions are not derived from RuntimeException, you either have to catch them or declare them as thrown from the method calling close. Now, suppose I have a class that holds a couple of resources, r1 and r2. Let's see what happens if I try to release them together:

try
{
    r1.close();
    r2.close();
}
catch(IOException e)
{
    // Do whatever I need to here...
}

If r1's close happens to throw, r2's close will never be called and I might (in a long-running application) leak resources. The same problem occurs if I don't bother catching the exception and declare it thrown from my method. Putting the close calls in the finally clause won't fix the problem either. A working solution could be:

try
{
    r1.close();
}
catch(IOException e)
{
    // Do whatever I need to here...
}
try
{
    r2.close();
}
catch(IOException e)
{
    // Do whatever I need to here...
}

This code looks worse than checking for return codes! What's more, I, as a programmer, am getting rid of a resource. I have decided that the given resource is no longer of any use to me. I am throwing it away. And it's coming back!

I can't think of a single reason an exception (checked or unchecked) should be thrown from a method that is releasing a resource. In situations like this, a return code should be used instead of exceptions because the programmer has, by the very act of calling your method, declared that she is no longer interested in the resource.