jQuery Extensions?

I've been working with jQuery a fair bit lately. Although it gives you a fair number of handy shortcuts, I think it's true value is as an educational tool on how to use JavaScript effectively.

This means diving in to the jQuery sources. This means learning what anonymous functions and closures are all about, letting it settle, and then learning what they're about again. It also means taking 98% of all the JavaScript tutorials on the internets and throwing them out. Well, maybe not throwing them out, but putting them in to context.

What I'm digging in to right now is programming in the jQuery paradigm. What this means is bolting all my own functions onto the jQuery object through an anonymous function. I can then call these functions just as I would call the jQuery functions, making for a cleaner and more reusable codebase.

The basic pattern is this:

jQuery.js

The jQuery library.

myLibrary.js

This is where I attach my functions to the $ object. The template goes like this:

(function ($) {
    var private_var = 1;
    var private_function = function() {return "Only this closure can call me, I'm special."};
    $.cool_function = function(){
      return "Hello jQuery.";
    }
}(jQuery));

doStuff.js

$().ready(function() {
    $("h4").html($.cool_function());
});

That's it in a nutshell. For more info on wrapping your brain around why this works, see this article. I wish I would have read it earlier.

You'll note i'm not handling input from jQuery selectors. I'm going to have to let that one bounce around in my brain a bit longer...

Happy coding!

Call For Web Standard

Developing native apps is a pain. Yes, you have the luxury of fixed screen dimensions and access to hardware features that may not be available elsewhere, but when you're done, you have an app that only works on one platform.

Web apps, on the other hand, work on a lot more platforms straight out of the box. The performance may not be the greatest, but the technology is advancing at breakneck speed.

The single largest drawback of web apps is working with files. The browser has no access to the filesystem, which makes sense in a lot of ways, but I'm surprised that this hasn't been addressed more thoroughly.

What we need is a new web standard and API for remote filesystems. Unlike the popular storage solutions like Dropbox, Box.net and MobileMe, this would be a remote hard-drive that you and your apps have access to. Apps would need to authenticate to access zones of your storage space; you could make some zones public and other zones publicly accessible via login.

Again, this goes back to my idea of content control. I would far sooner use an app that writes to a simple, accessible file-type than one that uses a locked down and proprietary format. The same standard applies to web apps, but the current assumption is that your web-app files live and die with the service that created them. Even Google Docs, probably the best of it's breed, only operates ideally if you only access and edit the files through their service (downloading/uploading strips date, author, etc. ). Interoperability with other web apps? Well, that's just crazy talk!

Crazy!?!

But why is it crazy? What is it about web-services that makes us freely give up the rights to our data? If I downloaded a word processor that password encrypted every file so that only that app could read it, I certainly wouldn't use it! But we are so blinded by the sharing and publishing features of these apps that we throw interoperability and future-proofing out the window.

In fact, I think there's some merit to this idea even in the desktop computing world. By zoning the filesystem, you could download and run apps in a sandboxed environment without worrying that they are messing with your files.

Maybe something like this exists? It seems like the IETF group working on WebDAV has something like this in mind, but it still seems pretty system level, like Samba and afp.

Divide And Conquer

School has started and I've been very busy with projects, but haven't had time to write. And in fact there's not a lot to write about. Sure, I've been working on a lot of cool stuff, but the big picture hasn't come into focus.

Along with getting a grip on the Adobe tools (Photoshop, Illustrator, Flash/AS), there's the programming.

One of the best insights that I've got so far is how powerful pencil and paper can be. Storyboarding, brainstorming and sketching use cases are a great way to think about a project from all angles. If you sit down and start coding without any clear direction, you are wasting a lot of thought on design and abstract principles, when you need to focus that brainpower on making sensible code. Working this way, a lot of coding design patterns start to emerge before you even begin coding.

And maybe that's the one bigger picture that is coming into view: learning to divide and conquer is vital to any project, even if it's just a one man show.

Progress

Technology is advancing, but is it really advancing as fast as it seems?

I might come across as a bit of a Luddite here, but I think that a lot of the emerging software and hardware is ephemeral. And maybe that's the way consumer electronics has to be. In the pre-dawn of the internet, software was developed for aerospace, medicine and government. It had to be robust, provable and enduring.

The landscape has changed completely. Today, developers have embraced the ephemeral nature of apps, iPads and cell phones. They're not worried about building enduring artifacts and code that will be solid and transparent for a generation.

Perhaps hindsight is always myopic. There are plenty of criticisms that judge the UNIX philosophy as being hackish; a virus that spread the "Worse is Better" philosophy of the the open source movement in general. But today, the tools have been honed, pruned and documented so well that it all works together as an organic whole. An organic whole that can be extended or repurposed in ever new ways.

It is this sense of growth that seems lacking in the software and hardware landscape of today. Code and hardware now go into the landfill in a few years by default. Without the organic usefulness of command-line programs, standalone apps have no value beyond a very short life-cycle.

In a way, I think it's what had to happen. For most consumers, the only interface that will get used is the one that is blatantly obvious. They feel smart when the computer doesn't make them feel stupid. And so user interface must appeal to the lowest common denominator. I just feel a tiny shiver of remorse when I see the amount of energy poured into technology that will be junked and forgotten in months or years.

Git Whyto

There are plenty of Git howto's on the internet, instead I think many people need a Git whyto. This guide is specifically focused on using Git and GitHub for personal projects like writing, publishing and creative work.

1. Complete Content Control

Git basically tracks any folder you tell it to. As you make changes to files, you can commit the changes, roll back the changes or create branches to try out alternate paths without messing with the main branch. You then push these changes to GitHub, which is simply a mirror of the files on-disk.

2. Responsibile Collaboration

It's easy to add others as collaborators on your project, and easy to see what, when and how much they changed. Any changes that you don't agree with are easily rolled back to previous versions.

3. Tracking Intentions

Each time you commit a change, you write a short description of the change. This helps you to get a sense of where the project is at, what you were thinking, and what still needs work.

4. Scalable Projects

Personal projects start out small, but there is a chance one of them may catch fire and become a big idea. Git works well with a single contributor or thousands of contributors. And if the project takes off, you will have the track record of the entire project right from the first commit.

5. Universal Appeal

Git was designed for software projects but it really has many compelling features for any project, from thesis to portfolio to presentation. System-wide backup plans like Time Machine are great on the large scale, Git allows the same kind of snapshots on a per-folder basis but adds the ability to merge, clone and modify these snapshots across many computers.

One slight problem with GitHub is that the free version only allows public projects (view and download).

If your project is private you can always just use git on your personal computer, zip the folder and back it up to Google Docs. You can then unzip the folder to any other computer and it will work with git exactly as it should. Or, alternatively, you could keep your master on an external hard drive and merge changes from your laptop, desktop and work computers without a problem.

Photo Archiving

Backups and Archives are two different things. Ideally you should have a good archiving system, and your backup would be a redundant copy of that.

In photography, a robust archiving system has between two and four copies of any file. These copies are:

• Camera Card
• Working Copy
• Source
• Backup

In this case, Source and Backup are read-only copies that are exact duplicates of the file off the camera. The Backup copy should be on a seperate physical media and ideally in a seperate physical location.

The working copy is the one you edit, view and share. Once a file is edited, it is important to make a Source and Backup copy of them as well.

It is good to view these copies as layers of mutability.

Camera Card: Changes the most. Every shooting session will create and erase content from the card.

Working Copy: Can change with each editing session and these files can be safely erased once backups are made.

Source Copy: Should never change, it is the copy that is accessed for viewing and making working copies. Any Source copy that is deleted will be deleted forever.

Backup Copy: A mirror image of your Source copy. It will only be accessed in the rare event that your source copies are compromised (HD failure, fire, theft, etc.).

Implementation

The way to implement this structure will vary with the tools that you are using. The first step might be to disable automatic importing when you connect your camera. A better solution when connecting your camera is to make source and backup copies immediately.

If you are using DVD's as your Backup copy, it probably makes sense to use a USB thumb drive as an intermediate backup until you have enough to fill a DVD.

It is important though to do regular integrity checks on your Backup copies. You need to make sure that they aren't compromised without you knowing. If you use an external hard drive, and are command-line savvy you might do "diff -r PictureSource/ PictureBackup/" to compare the entire contents of the two folders. If you are using DVD's you either have to trust the quality of your media, or do periodic checks of your media.

1. Connect Camera.
2. Make Source copy, check file count.
3. Organize Source photos into events, deleting any Absolute Garbage.
4. Make Backup copies, check file count.
5. Make Working Copy from Source copy by importing into your editor of choice.

Resist the temptation to organize your Source folder too much. Use only large, time-based, linear chunks.

• DO: Pete's Wedding, Reception, Saloman Bay Beach...
• DON'T: Flowers, Trees, Close-ups, Saloman Bay Beach...

The attentive reader will notice that the beach name is both in the do and don't list. This is because in the first, I've assumed that it was an afternoon of shooting at the beach. In the second it is a couple shots of that subject interspersed with shots of other subjects.

On a related note, don't rename your files. The filenames from your camera are a very good shooting record of your camera. If you want to attach descriptions and tags, do it in the file's metadata.

Now you are ready to edit your files. A typical editing session might look like this.

1. Make a Working Copy from Source copy (if it's not already done).
2. Edit the file(s).
3. Make a new source copy next to the original (eg. DSC1255-edit1.jpg)
4. Make a Backup of what has changed in the Source.

If you are using DVD's, you probably want to make a new folder for any edited files, because the original folder might already be burned to disc. Again, use the original name with a standard suffix (Pete's Wedding-edited).

Generalized Strategy

Photos are actually quite easy to organize, compared to the myriad of other file types out there. But the systematic logic can be transferred to other types of files as well.

By being systematic, a lot of confusion can be avoided. It also makes it possible to work toward automating the process entirely. But as the number of file types increases, so does the tendency to use different sorting methods or mixing methods.