Wednesday, February 13, 2008

Automating Google Earth (and Sky)

You know how it is, you're talking to someone over coffee about how things are possible, and the next day you're expected to know intimate technical details about exactly how to do it, and to get it done by close of business that day.

This happened to me at the tail end of last week and as a result I've been taking my first serious look at Applescript and Apple's Automator.

One of the things I needed to do was script Google Earth, and being an astronomer, what I really needed to do was be able to flip between Google Earth and Google Sky automatically. Unfortunately there wasn't anything in the Google Earth Action Pack that allowed me to do this, and Google Earth has a fairly thin Applescript dictionary.

Of course with the release of Mac OS X Panther, Apple introduced features into the System Events process which allows AppleScript to perform some actions in applications that have no, or only partial, built-in scripting support.



So I wrote some Applescripts to drive the Google Earth GUI, and allow me to flip between Earth and Sky modes, but people locally found the idea of Applescript to be a bit scary. So I went ahead and turned these scripts into Automator actions.

You'll notice that these actions use an Applescript delay to wait for image streaming from the server to complete, rather than the built in GetStreamingProgress function. Unfortunately I've not found this function to be terribly reliable, about one time in five it'll get stuck and never report that streaming has completed. This isn't terribly helpful if you need reliable scripts, so I've gone with a delay.

You can download the two automator actions I wrote to switch Google Earth between Earth and Sky modes. If you place these into either /Library/Automator/ or ~/Library/Automator they will show up automatically next time you run Automator, associated with Google Earth. Remember that because these actions reply on System Events you'll need to enable enable UI scripting in the System Preferences before they'll work for you.

Monday, February 11, 2008

Reasons to use loosely typed languages

Any high level language in fact, use Perl, Python, Ruby, or even Javascript. I don't care. Steve Yegge, someone I have a lot of respect for after his talk at OSCON last year, has posted another rant on his blog and given us a portrait of a newbie...

Steve argues that new programmers over comment their code. That they're using comments as a crutch to help them think through their approach to the problem.

He's got a point, it's not that I don't comment my code any more, although to be honest I don't comment my code that much any more. It's not that I don't write extensive documentation, although to be honest I write really lousy documentation these days, far worse that I used to, when I actually wrote several cookbooks and user manuals for my old project that apparently people actually quite liked.

It's not that I can't be bothered, or that I think documentation is unimportant, it's that the sort of problems I'm solving mean that documentation isn't really relevant. The people that need to understand the code already do, and the people that need to use the code couldn't fix it even if I'd spent weeks documenting it. Not because comments and documentation are a bad thing, it's just that you can have too much of a good thing.

Of course Steve's real target isn't comments, it's data modelling, and by extension statically typed languages. Steve argues that over using data models is just like, exactly the same in fact, as over commenting your code. It doesn't actually help you get stuff done.

...data modelers who were overly-concerned about data integrity when the real business need was flexibility, which is sort of the opposite of strong data modeling. When you need flexible storage, name/value pairs can get you a long, long, LONG way.

I find a lot of the data modeling efforts which go on as a pre-cursor to actual work, and in a lot of cases replacing actual work, totally pointless. I've watched people struggle with, in my view totally unsolvable in the general case, data models for months (sometimes years) and not actually produce any code as a result.

...when in doubt, don't model it. Just get the code written, make forward progress. Don't let yourself get bogged down with the details of modelling a helper class that you're creating for documentation purposes.

Which is why I use a loosely typed language. More than one loosely typed language in fact. Because, like a lot of Perl people these days, I'm starting to use a lot of Javascript to solve a certain sub-class of problem. Weakly typed languages help me get stuff done, and more importantly, get it done quickly. As a result my data models aren't that strong, in fact, in some cases they're pretty weak.

However a lot of the time I later hide my weak data model behind an nice fluffy object layer that looks like a strong data modelling. But generally the code underneath has lousy data modeling. You know what? That doesn't bother me in the slightest because data models are constrain what you can actually do with the data, and generally I've found that to be a bad idea. Because someone will inevitably come along next week with requirements you haven't thought about.

Which, as an aside, is why I've never really understood the obsession Java people have with patterns, which mostly seem to be common sense or not very useful.

I'd much prefer to have got lots of stuff done in a certain amount of time, than a little bit of stuff done, but done "properly". Because you can always go back and fix stuff you did earlier if people find it useful. But if you never do stuff at all, then nobody will ever find it useful. It's amazing how much stuff you do, that seems important at the time, and people have been pleading with you to make happen, that nobody ever finds useful.

I guess I'm a prototype and throw it away sort of guy, the data model doesn't seem that important, getting stuff done is more useful.