« August 2005 | Main | October 2005 »

September 30, 2005

All Your Keystrokes Are Belong To Us

Listen to this articleListen to this article

I stumbled upon this paper while doing my weekly browse through articles on CleverCS. To quote from the abstract:

... a novel attack taking as input a 10-minute sound recording of a user typing English text using a keyboard, and then recovering up to 96% of typed characters...

They even run the recovered text through a spell-checker which successfully corrected a mistake in the text as it was originally typed lol.

Pretty cool idea although I figure if you can sneak a microphone into a building—say by sending someone a bunch of flowers or a promotional desk-lamp, etc.—you can probably just as easily "upgrade" someone's "faulty" keyboard and record keystrokes that way instead.

September 19, 2005

ActionScript: JavaScript in Flashy Pants?

Listen to this articleListen to this article

One of the jobs I'm doing at the moment involves Flex—and consequently Flash—for the front-end and Java at the back-end, most of which involves writing ActionScript.

If you haven't used ActionScript before, you'd be forgiven for thinking you were writing JavaScript. Well, in fact you are writing JavaScript with a few changes, not necessarily for the better IMHO—If you read the documentation you'll discover that ActionScript is indeed based on ECMA Script, the same specification that was retro-fitted to JavaScript.

From what I can tell, ActionScript 1.x was pretty much exactly JavaScript. Version 2 on the other-hand adds some syntactic sugar to the language; no doubt an attempt to make a prototype-based language appear more like a class-based language in the hope of attracting all the Java developers. I'll get into these additions in a bit but in any event, I find it highly amusing when Macromedia proclaim that version 1 was somehow a functional language and that version 2 is now a fully-blown O-O language.

(As an aside, I interviewed some potential developers the other day who said they loved ActionScript but thought JavaScript was a language for doing hack-work. I can only assume that opinion comes from having only used JavaScript for handling onXXX events in a browser rather than any objective comparison of the langauges themselves.)

So, on to some of the more notable changes to the language starting with type-safety. JavaScript is weakly typed. This is a topic of biblical proportions so I'll leave alone the merits or otherwise of weak-typing suffice to say that I like it. In their infinite wisdom, Macromedia decided that what was needed was a bit of strong (or strict) typing. This is enforced by the compiler with a combination of type declaration after variable and parameter names:

var foo : Number;

Unfortunately this type-safety is limited to compile-time checking—nothing happens at runtime, much like Java's generics. Not so much of a problem I guess—I didn't want the strong typing in the first place—but amusing nonetheless.

So the next question is, how do you know what functions are available for a given type? In JavaScript these are essentially defined at runtime by adding behavior to a prototype. Well why not add some more syntax to the language?

class MyClass {
    private var num : Number;
    public MyClass(num : Number) {
        this.num = num;
    }

    public getNum() : Number {
        return this.num;
    }
}

Ok, so that's probably a little easier for most people to understand than:

MyClass = function(num) {
    this.num = num;
};

MyClass.prototype.getNum = function() {
    return this.num;
};

But I actually find the "new" way actually involves a lot more typing than the good-old-fashioned way—which once you're used to is easy to read anyway—and hides the fact that it is still a prototype-based language and NOT a class-based one. (I also quite like the way prototype declares "classes" but I haven't found the time to start doing it that way just yet.)

You can also declare property accessors just like in VB/C#/etc:

class MyClass {
    private var num : Number;
    ...
    public get num : Number {
        return this.num;
    }

    public set num(num : Number) : Void {
        this.num = num;
    }
}

Again, great if you like that kind of thing; I'm still not convinced I do.

The other thing that gets people is the scoping rules. JavaScript has some pretty funky scoping rules which once you're used to and understand work just fine. Again, because ActionScript looks like Java, developers don't realise the importance of understanding the scoping rules.

ActionScript also introduces another new keyword: dynamic. This can be used when defining a class and indicates to the compiler that it should NOT do strong type checking when invoking methods and accessing properties of the class—either from within or from outside the class. Again, I find this a highly amusing construct as I can always defeat the type checking the old-fashioned way anyhow: myObj["doSomething"](15);. Yes, I agree, that's a bit of malicious code but what I'd prefer is an option to turn on/off strict typing at a project level and not on a per-class basis.

Interestingly, someone recently pointed me at an open source compiler for ActionScript. I wonder if I could just download the code, remove the strict type checking and be done with it ;-). Oh and there's also a unit testing toolkit as well.

All in all, I quite like using ActionScript. I've only played around a bit with Flash/Flex bindings but they seem quite nice too. I actually think it would be pretty easy to build a Cocoa—JavaBeans the way they should have worked—like framework (eek there's the word!) which I thoroughly enjoy using at the moment.

But when it comes down to it, It has been my experience—and no doubt the experience of others in the JavaScript/Ruby/Smalltalk/Objective-C world—that I can achieve a lot more in fewer lines of readable code without all the syntactic sugar and strong typing. (The caveat being that I'm also a big fan of automated testing.) Moreover, understanding that JavaScript uses prototypes opens up a whole new world of possibilities that further increase my productivity—a fact that became apparent to the attendees of a mini presentation I gave on this subject just recently.

My Biggest Peeves With JavaScript

Listen to this articleListen to this article

There's really not a lot to dislike about JavaScript; It's object oriented—in a way Java can only dream of; weak-typing coupled with dynamic property objects make mocking and testing a breeze; the list goes on. But there are two things about the language that continue to irritate me: Exceptions; and undefined/null. Ok, so I guess that's three things but the last two are really in the same category.

First up, undefined/null. Let me start by saying that I love the fact that these are actually objects—go null object pattern— but the fact that they silently gobble up any calls made to them is less than helpful. Even less helpful is the fact that I can't override this behaviour. Unlike every other object in the language, these two don't seem to have a prototype I can mess with. At least in Objective-C/Smalltalk you have the option of finding out when messages are sent to null objects or to objects that don't understand them. Thankfully, testing catches most of these problems but where it can't, I resort to my tried and tested method: runtime assertions. Which leads me to my second peeve.

Exceptions. Well at least JavaScript has them I guess, even if they are called Errors. Sure I can throw them, I can catch them, I can put code in a finally block but I can't get any information about them. I use runtime assertions all the time in Java, Objective-C and even JavaScript to catch things I haven't managed to test for or more importantly, things I can't necessarily predict. Whenever an assertion fails, an exception is thrown which usually dumps a stack trace giving me everything—well almost everything—I need to track down the source of the problem. Unfortunately in all web browsers I use regularly—Safari and Firefox—all I seem to get is the message "Error" printed to the JavaScript console. Great! So I know there is a problem but I don't know where, nor importantly why? This usually leads me to the JavaScript debugger—probably the best thing that ever happened to the language. Not that I mind using the debugger but a stack-trace is extremely useful!

September 09, 2005

Managing Sensitive Data on Mac OS X

Listen to this articleListen to this article

One of the clients I'm working for at the moment mandates—quite rightly so—that any data taken offsite must be encrypted. Mac OS X provides two ways to achieve this: FileVault; and Encrypted Disk Images. (If you want to know how to encrypt emails, see this article.)

FileVault (System Preferences>Security>Turn On FileVault...) is kinda cool: It allows you to encrypt your entire home directory. This might be handy if you're super paranoid but I'm not; neither do I want the overhead of having everything I write to disk encrypted.

Encrypted Disk Images on the other hand are super cool for this kind of thing. If you're familiar with Mac OSX then you've no doubt used plain disk images before. They're the .dmg files that are used for distributing most of the software you install. The neat thing about them is that you can mount a disk image and use it just like any other disk on your machine. On top of this, you can encyrpt them so that unless you have the password, no one can peek at the data.

To create a blank disk image:

  • Open Applications>Utilities>Disk Utility
  • Select File>New>Blank Disk Image...

To create an encypted disk image:

  • Open Applications>Utilities>Disk Utility
  • Select File>New>Disk Image From Folder...
  • Choose the folder you wish to use as the source of your disk image; and
  • Press Image

In either case:

  • Enter a filename and location and choose an initial size—disk images dynamically resize so don't worry too much about this
  • Select AES-128 (recommended) for Encryption; and
  • Press Create

You'll then be prompted for a password with which to encrypt—and decrypt—the file. You're also given the opportunity to save the password in your keychain. This just means you won't have to remember the password when mounting it on your own machine—If you move the file to another machine or send it to someone else, a password must be entered manually.

Now anytime someone tries to mount the disk image, they'll be prompted for a password; if they don't have the password the data is protected, even if they try to read it using another tool.

Once mounted, you can use it as you would any other drive: as a mounted image in Finder; or under /Volumes/ using the filesystem.

September 05, 2005

MT 3.2 Atom Feed Template Problem

Listen to this articleListen to this article

Updated 17 October 2005: Seems there are all sorts of problems with the template. I ran it through a feed validator service and I'm frankly staggered anyone can actually read my blog. It seems the content type can be left as "html" after all but I needed to change a whole-lotta other stuff to get it to pass. Interestingly, Safari now sometimes manages to read the whole feed just fine. Go figure? Luckily I recently switched to using PulpFictionLite as my news reader. Safari just doesn't cut it I'm afraid. Anyway, it's just another example of what can happen when I try playing with things about which I understand very little. *Sigh*.

I noticed that since I upgraded to MT 3.2 my atom feed—the main one since the switch—wasn't being displayed correctly in Safari's RSS Reader. The culprit: a slight problem with the content-type in the template for atom.xml.

To correct the problem, find where it says <content type="html" ... and change "html" to "text/html" and all should be fine again.

The index.xml template works just fine though I've yet to bring either the comments.xml or index.rdf up-to-date. The former is just laziness—I need to remember how I converted the original index.html template; The latter is because MT seem to have dropped support for RSS formats <2.0. Neither of these is really an issue as they worked before and continue to work now.

FWIW, I'm considering removing index.rdf sometime soon anyway as I'm pretty sure almost every RSS reader now supports at least RSS 2.0 and most-likely Atom as well.

September 02, 2005

Multiple Mac (Tiger) Logins for Testing

Listen to this articleListen to this article

I do all my development on my mac powerbook which, up until today, has had only one account: mine. But this morning, as we were trying to solve the last of the MT issues, I needed another login with which to quickly try something out.

It seem as though there was something peculiar about my login that was causing some of the problems so, I open Accounts and created a test user. So far nothing special about his—I'm sure you create test accounts all the time— however it's always annoyed me that you have to logout to switch users. I mean really, this is supposed to be unix right?.

Tiger (OS X 10.4) has a nifty "Fast User Switching" option which allows you to switch between users while leaving all the applications running. I had heard about this feature some time ago and thought to myself "phe! what do I care?" but I'd never thought about it in the context of testing.

To enable fast user switching, open "Accounts" in "System Preferences" and and click "Login Options". Tick the box titled "Enable fast user switching" (it's down the bottom). You should then see a list of accounts in the top-right of the menu-bar.

The great thing about this for me is that I can quickly blow away the account and re-create it; or have multiple accounts all logged in to my apps at once, all from the one machine. Of course the fact that I need to get down to manual testing says more than anything but alas, in this case, I didn't have much choice. Besides, as James has berated me for in the past: Just because you have automated tests, doesn't mean you can avoid manual testing as well.

On a side note, I also love SSH as it allowed me to install a public-key for the MT support guy to login to my shell account without needing me to create new users—which I can't do anyway because it's not my server :)

Update (2 September 2005): I noticed today that Redstone Software have a new version of OSXvnc that supports this, allowing you to view (and control) the other logins without even switching! It's a free download; as is Chicken of the VNC—A VNC client—which you'll also need.

September 01, 2005

MovableType Weirdness Again

Listen to this articleListen to this article

Some of you may have noticed some decidedly odd behaviour with the blog the past couple of days: you couldn't post comments; and I couldn't post new entries. Somehow—I't's still a mystery—things just stopped working. The suspicion I have is that there was some problem with the Berkeley DB files after a server upgrade but I can't be sure.

For the most part, MT behaves itself pretty well—to-date I've hardly had any problems—but when I do have a problem it usually requires quite a bit of effort to work out what went wrong and fix it (if possible).

So anyways, after unloading, reloading, repairing, upgrading MovableType and performing all manner of other unix witchcraft—most of it performed at 3am—things are finally back up and running again. The next step will be to migrate from Berkeley DB to Postgres in the next day or two so there may be a few more minor interruptions a long the way.

The upshot of all this is of course that I'm now running on the latest (and hopefully greatest) version of Movable Type. Having said that, blogging ain't my profession—god save you all—so I'm not sure that an upgrade of MT actually buys me much except some more long nights attempting to work out why things stopped working.

Everything seems to be in or-der but if you notice any more weirdness please let me know, otherwise I'll get back to eating my orange sher-bert

Update (1 September 2005): Ahh yes, I knew it was too good to be true. Robert kindly informs me that comments are still busted: you can read them just not post them. After a little investigation, it looks like there is some problem with the new version of SCode. It worked for me because I'm authenticated on my own blog but it doesn't seem to work for anyone who isn't authenticated. Sheesh! Maybe I need to write a suite of tests for my own blog!?

Thankfully, the solution is pretty simple. Thanks to the author of the plugin who responded to my forum posting: The file SCode.pm contains the "$app->{requires_login} = 1;". This should probably read: "$app->{requires_login} = 0;".

Update (2 September 2005): All converted to PGSQL now thanks to the truly awesome support people at MovableType. They ironed out the last little issues with upgrading and now I'm off Berkely DB. Hopefully this now means no more file corruptions.