Posts from "August, 2008":

Re: Attention & Ambiguity

I’ve begun reading 43 Folders pretty regularly and typically I agree with what is written there or at least find in it an interesting perspective. The article Attention & Ambiguity: The Non-Paradox of Creative Work struck a nerve of sorts with me.

In particular the following paragraph bothered me:

Most all makers with longevity talk about a process that involves regular, scheduled work periods that allow generous time for warmups and getting into what Csikszentmihalyi himself has called, “Flow.” For as long as he or she can stay in that Flow state, a good artist is capable of synthesizing unbelievably disparate material and ideas in a way that’s often satisfying and productive. For those who cannot, it means another morning of video games, Facebook, and binge eating.

The reason it tugged on my reply strings is pretty basic, it seems to attribute the state of “Flow” solely to artists. I realize this is not the most significant part of the article, in fact it seems almost like an aside but reading those sentences colored the rest of the article for me. I focused on this so much because I disagree with it, it is not simply artists who get into a “Flow” but I would say any individual who is focused on creating or producing something tends to get into a “Flow”. When I’m talking about “Flow” I’m thinking of a specific mental state which I can most easily describe as focused on a task or action with something akin to tunnel vision. Given a definition such as this arguments could certainly be made for expanding it’s applicability far beyond an association with people creating things.

Other than the above bit though I generally agree with what Mr. Mann is saying. Talent and brilliance does not occur in a vacuum. Producing great works requires a number of things including attention, refinement, and criticisms.

August 24, 2008

MooTools Builder Script

Back when MooTools 1.2 was released I decided I would upgrade/update a number of scripts I had written which were dependent on MooTools and then release them to the open source community. However, with work and some other things going on in my life it has taken a much longer time than anticipated to get things started. Plus there have been other distractions, I would call the subject of this post one such distraction.

I created a script called MooBuilder which examines the javascript objects loaded into memory to determine which components of MooTools are included when MooBuilder loads. The included modules the MooBuilder is aware of can be manually refreshed later if desired. In addition to testing what is already loaded the script will also include new MooTools modules and dependencies if the location to the source trees has been provided. For example I have mootools-core and mootools-more gits on my server so I can point the script at, for example, http://static.bryanjswift.com/mootools-core/Source and it will know where to find the appropriate scripts based on the script name. The script names are determined by the core and more builders and the dependencies are determined by a slightly modified version of scripts.json which is included in each of the source trees.

An example use of MooBuilder to include the Accordion script:


var builder = new MooBuilder('http://static.bryanjswift.com/mootools-core/Source',
                             'http://static.bryanjswift.com/mootools-more/Source');
builder.include('Accordion');

The last feature of the script is the ability to register your own scripts. Registering a script is done by passing the MooBuilder::register an object with a name, a path, a test function to determine if it is already included, and an array of dependencies. For example to register and then include the Fx.Position script I posted about previously I would:


var builder = new MooBuilder('http://static.bryanjswift.com/mootools-core/Source',
                             'http://static.bryanjswift.com/mootools-more/Source');
builder.register({
    'name': 'Fx.Position',
    'deps': ['Fx.Morph'],
    'test': function() { return typeof Fx !== "undefined" && typeof Fx.Elements !== "undefined"; },
    'path': 'http://github.com/bryanjswift/mootools-plugins/tree/master%2FSource%2FFx%2FFx.Position.js?raw=true'
});
builder.include('Fx.Position');

Obviously registering the scripts you need in every page and then including them seems silly, but I envisioned to use of the script to be creating a builder in the site’s main js file and registering all possible components and then on each page including just the ones needed for a given page. Another scenario would be having components themselves tell the builder what they needed before defining them.

I’m certainly open to any feedback!

August 16, 2008

Using Gist to Keep Task Synced

The folks at GitHub recently launched Gist which may well be the best code sharing/pasting tool ever. It has nice syntax highlighting and a plain user interface plus you can share more than one file in the same paste or gist. In addition to this you have the ability to create a ‘private’ gist. The quotes are because they are private only by obscurity not by any authentication logic. A SHA1 (I think) key is created and they use that as the url to you new, small git repository but they don’t show up in the view of all gists and a SHA1 is pretty unlikely to have it’s value guessed correctly.

Gist by itself is great news and a useful tool but the thing I find really appealing is that I can use it to keep simple text files in sync across multiple computers. This is incredibly useful to me because I typically track my work hours in a simple text file because our timesheet application is pretty horrendous to use and I want to deal with it as few times a week as possible. So I created a new private gist and added this time tracking text file and now I don’t have to worry about having my hours at work but not at home or vice versa because I can just pull from the private gist. Not only that but now my time tracking sheet is versioned so I don’t have worry about losing notes I make about how I spent my time in the unlikely event someone asks I can find it.

This was a grand breakthrough for me and I was quite pleased. Lately though I got to looking at some task tracking software and found some great ones but I am reluctant to pay for software I know I’m likely to stop using after a little while. Of the free options I didn’t find any which would allow me to easily sync my todo list from my home computer to my work computer. About this time I remembered a shell script I had used about a year ago which tracked all the information in simple text files. After a little looking I found Todo.txt – Task tracking for command line lovers. I dug around for the script on my computer and tried to update it but whenever I listed out my tasks I had this -e being printed in front of the first one. I’m fairly certain it was a misplaced sed argument but with all the regular expressions in the shell script I didn’t want to break things worse. I tried to search for the problem and came up empty on the mailing list but did find a link to a todo manager called Task which even provided an installer for Leopard!

Once I installed the package it was a simple matter of updating the configuration to write files to the directory where my time tracking gist was already located and TADA! easy syncing of time and tasks across multiple computers using the magic of the command line.

August 13, 2008