I hate navigating a directory tree. The same scenario plays itself out over and over: you're working on some files in Directory A, and everything starts out great. But then you need to refer to some files in Directory B, which is in some other location and not at all convenient to get to. Your brain shifts to the task of navigation. You mouse click or cd your way to wherever Directory B is. That's the point of annoyance-- changing contexts isn't fluid. It's even worse if you're dealing with multiple applications who have their own notions of where "here" is. Save this file to whatever random directory I was working in last time that has no bearing on what I'm doing now? Why sure, how did you know?

My directory jumping script is similar to the script I wrote about in A Spotlight Alternative With Perl, but it's for visiting directories rather than launching applications. It starts off with a file called .jump_includes.txt in your home directory, which contains a list of root directories to scan. In my case I have things like /var/www in here, as well as my documents folder and handful of others. Next there's .jump_excludes.txt, which should be a list of directories to ignore. Things like .svn directories go in this file, since you don't normally have occasion to interact with them and in terms of navigation they're just distracting dead ends.

When jump.pl is given --crawl as its sole argument, it'll scan the directories listed in the include file and write a cache file in your home directory. By grepping through this cache file, jump.pl can identify the path that best matches your input. If there's any ambiguity, it'll prompt you in a "did you mean..." fashion with a list of possibilities.

This is better than tab-completion on the command line, because you get the whole path in one shot. And it absolutely saves on mouse clicks. I currently have things set up with OS X in mind, so that jump.pl --cd destination will open a new Terminal window and drop you into the specified folder and jump.pl --open destination will open a new Finder window. It wouldn't take much to accommodate other platforms. Best of all, a single-letter bash function can wrap the call to jump.pl and keep typing to a bare minimum.

This doesn't solve the problem of Applications being in different directories than you want them to be when opening or saving files, but it does make it easier to move around without keeping mental track of folder paths.

Jump.pl can be found here.

After reading Dreaming in Code, I went back to the reviews on Amazon.com and found agreement with the one from January 20th, 2007 that cried boredom and the one from March 15th, 2007 that upped the ante by saying, "I'll only read the rest of this if I'm in prison."

I skipped more and more as I got closer to the end of the book. The story of the Chandler project starts off well enough but like the project doesn't ever build much momentum. There was a meeting here discussing problem A, another meeting there discussing problem B, and plenty of characters on hand to stir the pot but no immediate consequence beyond... another meeting. Reading about those meetings is only marginally better than being in them when insight into the participants behavior and motive doesn't go deep enough. There's never any rage against the machine. No chairs are thrown. People just go on sabbatical or leave to pursue other projects. So when Rosenberg pauses the Chandler story and drifts into programming history and theories of project management, the interruption is both reprieve and distraction.

As another Amazon.com review mentions, this might be an interesting read if you wanted a slice of day-in-the-life on a software development project. But if that is your life already, you'll need to dig out all the "Ah ha! That's where things went wrong!" moments on your own.

I like to use the built in features of OS X rather than resort to third party applications. It's rare to find an application that's hands-down better at whatever it does compared to what you get from Apple. More often you find something that's a little better, or just slightly different. Until recently, this was my attitude toward Spotlight. It wasn't as fast as I might like but it more or less got the job done.

I mainly used Spotlight for quick access to applications. Of all the things that Spotlight can index, from Address Book contacts to Fonts to Keynote Presentations, Applications were were the only thing I genuinely needed quick access to. Everything else could be reached through other means when needed. Most of the time it wasn't. Yet even after scaling back Spotlight's purview, it still wasn't fast or precise enough. Perl to the rescue!

My Spotlight replacement, at least for launching applications, is a Perl script that I run from the Terminal. It takes advantage of the fact that applications on OS X live in the Applications folder, and are special folders that end in ".app". When run with --crawl as its first argument, launch.pl will scan the Applications folder recursively and build up a list of all the applications it finds. This list will be written to a hidden text file in your home directory, one application per line.

Once this cache file has been created, run the script again and provide an application as the first argument. The script will grep the cache file, and then launch the desired application via the open -a command. If there are multiple matches in the cache file, it'll prompt you to pick one. For extra convenience, you can use a Bash function like this to shorten the script name to a single letter:

function l() {
    ~/bin/launch.pl ${*}
}

The end result is that when I want to launch Firefox, I type l fox into a Terminal window and Presto! Firefox launches. I can open Safari with l saf or l safari. There's no delay as with spotlight, because grepping the cache file is very fast. There's also no background service left running all the time. The cache file only needs to be rebuilt when a new application is added to the Applications folder.

One thing I've never liked about using Subversion from the command line is that it's tedious to add and remove files. Although the svn status command tells you the state of the files in your current checkout, its output is not used when doing svn add or svn remove. You end up retyping files paths, or copying and pasting. That's not efficient.

A little interactivity would be much more helpful, and that's what svnask.pl provides. It's a short and very simple Perl script that runs svn status, looks for files with a state of "?" or "!", and prompts for a yes-no on whether to add or remove each one from the checkout. Since "yes" is the default, you can operate on a whole mess of files with barely any effort.

Another efficiency problem I've come across with Subversion involves keeping track of multiple checkouts from multiple repositories. I have numerous projects in various states and bounce around from one to another. Sometimes I forget to do a check in, especially if I've only made a trivial change to one file. Weeks can pass before I notice I have outstanding revisions. With svnstatus.pl run daily via cron, this is no longer a problem. The script examines one or more directories and runs svn status, producing an accumulated status report of all known repositories. If there are outstanding changes, cron will deliver the details in an email.

About a year ago, I replaced the Squid proxy on my home network with Apache's mod_proxy. I wanted to continue blocking annoying ads on web pages without keeping an additional service running. It seemed like an obvious choice since Apache was already in the picture and ready to serve.

Things weren't all they were cracked up to be with mod_proxy. Setup and configuration took a lot of fiddling and fusing, and there was a bottleneck somewhere along the way that often made pages load more slowly. I had all sorts of URL rewriting power at my disposal, but not a solution that worked all the time, every time. So I scrapped the whole thing and did without.

Web page ads are still annoying though, and I still want to block them. Now I think I've got the right mix of simplicity and reliability. It's essentially the solution described at Superior Ad Blocking on OS X: add the hostnames of known ad servers to your hosts file, then configure Apache's ErrorDocument to return a blank page rather than the default message.

The one change I made was to point ErrorDocument to a 1x1 pixel GIF rather than an empty HTML page. This prevents broken image icons from appearing, and doesn't appear to create any problems with requests that expect to receive text.

I'm also adding the names of ad servers to my hosts file by hand, rather than grabbing one of the lists available from Wikipedia's page on the Hosts file. This way I'm only blocking the ad servers I've actually encountered, and not hundreds or thousands I'd never otherwise come across (if they're still in fact active).

Some of the job ads on Craigslist really stand out. How often do you see brotherhood, drivers licenses, web development, and the Bahamas in one paragraph?

Web designer / Web developer Business Partner Needed!
Date: 2006-12-10, 11:30PM EST

I am not looking to hire a web developer/web designer to just build a web site.

I am looking for a business associate well versed in web developing and web designing , that I can TRUST. You must be local, I must know where you live, I must have a copy of your drivers license. You must know where I live and have a copy of my drivers license. We must literally become brothers. Trust is the most important aspect of a partnership especially in business. Before looking for a great web designer/ developer I'm looking for a trustworthy, honest, loyal hard working associate. The frame work of my site is complete it has been copywritten and trademarked. I need a Developer to complete back end work , some graphic changes and then be my site administrator and assoicate. What a golden opportunity to make unlimited funds with me. I have the financial backing and attorneys, All you must do is meet the criteria mentioned above. If you do, then we will be spending many weekends in the Bahamas celebrating our fortunes.

SQLite is an introduction to the SQLite database. Whereas other databases match complex features with complex setups, SQLite is all about simplicity. The database is a single file. There are no usernames and passwords to fuss with. SQL queries are largely understood the way other databases systems understand them. You can get yourself up and running without any of the minor yet annoying puzzles that come up when you're first getting acquainted with a new database. It's all so... easy.

SQLite covers its namesake both directly and within the context of several programming languages. The former comes first, and Newman points out many aspects of SQLite that give you a good grounding on what you can and can't do. It's easy to think you can just skip over this material once you see that queries are standard SQL, but that's missing out on the underlying details. I liked the suggestion of using a temporary table to compensate for the lack of an ALTER TABLE command, and was surprised to read that SQLite's COPY command was based on an equivalent in PostgreSQL and could therefore work with the output of pg_dump.

It's also good to know about SQLite's more advanced features, even though you may not have an immediate need for them. The ON CONFLICT clause falls into this category for me, as do user defined functions and triggers. I'm happy enough being able to bring a complete SQL environment into my projects as a single local file.

SQLite's coverage of the PHP, C/C++, Perl, Tcl, and Python interfaces is necessarily redundant, and will be at least partially skippable unless you're working in all those languages. I even skipped through most of the PHP material, because I prefer to use PHP5's PDO extension for ease of migration.

Finally, SQLite predates the release of SQLite version 3, and so due to the book's age some things will necessarily be out of date. Still, the book is a short one and still well worth consideration.

On the heels of my recent review of a book on AppleScript comes a small utility I created to automate SWF publishing.

Let's say you've just finished working on your latest masterpiece. Now you need a companion HTML page to go along with it. Out of habit, you might reach for the HTML file that Flash usually creates for you automatically. After a little bit of fiddling with the HTML, you'll probably be all set. Or will you?

From a programming standpoint, no. Flash's default HTML is enough to get your SWF file to display properly in a browser, but it's long-winded and repetitive for esoteric reasons. There are better approaches-- I particularly like SWFObject because it takes care of displaying the movie as well as doing version detection and also copes with recent changes to Internet Explorer related to the Eolas patent dispute. From a presentation standpoint, meanwhile, the default page is pretty plain. It could look much more professional if you added something as simple as a header and footer, or at the very least centered the movie horizontally.

None of this stuff is particularly interesting when you've just finished working on Flash movie. You're done, or at least you want to be. The rest should just be minor details. So how can we automate this last mile into something that you don't even need to think about?

SWF Templater is an AppleScript droplet and web service meant to do just that. The AppleScript accepts any number of SWF files that have been dropped on it and passes them to a PHP script (more specifically, it invokes curl via the "do shell script command", and curl performs an HTTP post to the remote script). The PHP script figures out the width and height of each movie, then creates an HTML page from a standard template. It's similar to the process that Flash goes through when you publish a movie-- by doing the templating remotely, though, we can have more control over what the templates look like and be less bothered by having to keep track of SWF files and HTML files.

AppleScript was the first programming language I came across when I was first learning to use a computer. Being the de facto scripting tool that every Macintosh computer came preinstalled with, AppleScript was just right there ready to be used. But somehow I never really did.

There was always disparity between the things you could do with AppleScript and things you necessarily needed to do. I still find that to be the case today, even after reading AppleScript: A Comprehensive Guide to Scripting and Automation on Mac OS X. I have a better sense of the language and can go further with it than I would have otherwise been able, but hesitations still remain.

The first of these is whether AppleScript is even the best choice. Written in 2004, AppleScript precedes the debut of Automator in OS X Tiger. Automator makes it extremely simple to write scripts ("workflows") by mixing together a palette of pre-defined commands. Although it doesn't do everything, Automator can be the superior choice in some cases. Why fuss with AppleScript's syntax if you don't need to? Even if you do, Automator has provisions for executing arbitrary AppleScript code.

AppleScript assumes little or no programming experience, and I think that contributes to a second hesitation: how to jump from theory to practice. The book starts off with introductions to AppleScript's basic data types and control structures. It isn't until Chapter 13, Working with files, that we get into more pragmatic subjects. Chapter 13 also happens to be quite longer than other chapters. This was the real starting point of the book for me-- everything prior was more like the inevitable drudgery you have to slog your way through for your own good. Sure, it's important to understand coercion and other fundamentals. Rosentahall's coverage is both thorough and gradual. At the same time, it's much more exciting to move and manipulate files and folders than it is to do date arithmetic.

After the main course of Chapter 13, there were a few more meaty chapters but also many places that I skipped away from for lack of immediate need. The material on scripting FileMaker was interesting, but not something I needed from a reference to the language overall. Likewise for the final chapter, The Business of Automation, which offers some career advice for would-be professional AppleScripters.

Aside from these pockets of filler-in-the-eye-of-the-beholder, reading AppleScript can help you pick up some good script writing habits and give you a solid grounding in the particulars of the language. But when it came time for me to write my first significant AppleScript, I still found myself trawling through Google and Macscripter for missing clues and example code more in line with what I was trying to accomplish. AppleScript was a good started book, but I think I'll want to turn to other sources for just that extra bit more.

For the longest time, I've had a cron job running on my server at home that used ipcheck (apt-cache show ipcheck) to update DynDNS with the current IP address of my cable modem. Just in the off chance that said address would change at an inconvenient time, leaving me without a path back to home base.

That script and service did a fine job. Unfortunately, my cable modem's IP address rarely changes. And even if it did, I probably wouldn't be all that inconvenienced. Maybe a little. If the address did change, I'd really only need to know the new one. I'm definitely not in need of any fancy service monitoring. What's the simplest solution then?

If you have a website and access to its access logs, the answer might just be curl. By switching my cron job to something like this:

curl -I -A "hostname of my server" http://example.com < /dev/null

I'll end up with easily identifiable entries in my webserver logs. Using HEAD requests (-I) keeps the request and response lean, and I can grep based on that and/or the hostname of my server. As an added bonus, I also end up with a basic availability heartbeat. If there's nothing in the log files after a certain point in time, something has more than likely gone wrong.

I should have gone this route all along. DynDNS is a better choice when dealing with IP addresses directly would be otherwise inconvenient. But I'm not exactly in that boat.