#!/bin/bash

#get latest contents from svn and pull out touched files
svn up | egrep "^A |^U " > updates.txt

#start a manifest of files to push
echo "cd /deploy/path/on/remote/host” > sftp_batch.txt

cat updates.txt | while read line
do
   FILEPATH=${line:5}
   #add command to push the files from your local machine to the remote host
   echo “put $FILEPATH $FILEPATH” >> sftp_batch.txt
done

sftp -b sftp_batch.txt user@remote.host

I have a working folder /work/sitename-dev in which I do all of my development, and a clean check-out of the same repo at /work/sitename-deploy. By tossing the above script into the deploy folder I can work and commit to the repo as often as I like from the dev folder without keeping tabs on my changes.

When it comes time to update the live site, just run the script. This updates the contents of the deploy folder, builds a manifest of touched files and passes that manifest to SFTP as a batchfile for promotion.

Caveats

• I know this doesn’t address deletions from the SVN repo, but I don’t need that functionality now, so I didn’t write it. You can thought.
• You need to install your ssh keys for SFTP to work in a scripted manner like this.

If anyone finds this useful, I’d love to know.

In other news:

http://store.nin.com/secure/{transaction id from your receipt}/nin_ghosts_I-IV_mp3.zip

will let you download Ghosts now.

Most of the obvious sources (Flickr/Twitter/Mint/GMail/anything else with a private beta and life-stream) give off “free” data, so I am looking for datapoints that I’ll need to track myself. So far I am logging stuff like mood/stress level, physical activity, ethical decisions, cooking habits. The weirder crap. The stuff that I hope will lend itself to interesting analysis in 12 months time.

If you could look back on a year in your life, what questions would you be interested in asking yourself?

Download the code

or build your own copy from my Google Code repo

jamesv -+- flash-classes --- org -+- json --- JSON.as
        |                         |
        |                         +- jamesv -+- apis --- Flickr.as
        |                                    +- utils --- Core.as
        |                                    +- widgets --- FlickrPhotoScatter.as
        |
        +- flash-source --- widgets --- flickr_photo_scatter -+- flickr_photo_scatter.fla
                                                              +- flickr_photo_scatter.swf
                                                              +- manifest.txt

Builder script

A harness to do a fresh export of the site code, drop the existing db tables, build new ones and stub in some data. (gave me a chance to learn about .my.cnf files too).

#!/bin/bash
# get latest from SVN
rm -rf /path/to/htdocs/*
svn export http://www.svnrepo.com /path/to/htdocs

# purge and rebuild db and data
mysql < /path/to/htdocs/db/schema.sql
mysql < /path/to/htdocs/db/stub_data.sql

/db/schema.sql

I found it more convienient to throw away the old structure and start fresh with each change to the db (if nothing else, it makes me update my stub data file and test harnesses. You could just as easily have stacked “alter table” statements to denote changes between versions.

...

----------------------------------------------------------------
-- incoming data feeds
-- -- rev 61: added "video" and "photo" to `feed_type`
-- -- rev 76: changed `name` VARCHAR(50) -> VARCHAR(255)
----------------------------------------------------------------
DROP TABLE IF EXISTS `feeds`;
CREATE TABLE feeds (
    id INT UNSIGNED AUTO_INCREMENT,
    project_id INT UNSIGNED NULL,
    name VARCHAR(255),
    src_url VARCHAR(300),
    feed_type ENUM('rss', 'atom', 'video', 'photo'),
    active BOOLEAN DEFAULT true,
    created DATETIME DEFAULT NULL,
    modified DATETIME DEFAULT NULL,
    PRIMARY KEY  (id, project_id)
) TYPE=MyISAM;

...

/db/stub_data.sql

By giving all developers on a project a common set of starting data, it makes it easier to replicate issues uncovered throughout the site. If one coder finds that a section of the codebase is soft against a certain type of data (unicode, html entities, etc) they can add sample data of that kind to everyone’s stub file. By making everyone feel the pain of the insecurity it tends to get addressed faster.

...

----------------------------------------------------------------
-- stub data feeds
----------------------------------------------------------------
INSERT INTO feeds 
    (project_id,name,src_url,feed_type,created) 
VALUES
    (1, "Google News", "http://news.google.com/?output=rss", "rss", NOW()),
    (2, "Fine Hypertext Products", "http://feeds.kottke.org/main", "rss", NOW()),
    (1, "Yahoo! Interface Blog - dev", "http://feeds.yuiblog.com/yuiblog/development", "rss", NOW());

...

This approach is still really early in its development and will almost certainly be revisited a number of times as it is used more, but so far it has fared quite well for deployment and replication across a number of machines.

All appeared notably above:

This was after an initial quick sort of items based on perceived pain to myself if I neglected to pack said item,

Not shabby for a $75 road bike from the 80s. Though this little slice of heaven has been calling my name…

The DOM however is fair game. Anything you want to screw with on the clientside (so long as it’s crossbrowser compatible) is A-Ok in my book, once a document is in-browser gets pulled apart any way.

To that end, I wrote this (which uses a very basic set of MooTools methods):

function wrapper(selector) {
    $$(selector).each(
        function(element) {
            var wrapper = new Element('div').setProperty('class','outer').injectBefore(el);
            element.injectInside(wrapper);

            var before = new Element('div').setProperty('class','before').injectBefore(element);
            var after = new Element('div').setProperty('class','after').injectAfter(element);
        }
    )
}

which takes all elements on the page with a given selector and wraps them in DIVs for styling.

Before:

<img src='foo.jpg' alt='Some image' class='to-be-wrapped' />

After:

<div class='outer'>
    <div class='before'></div>
    <img src='foo.jpg' alt='Some image' class='to-be-wrapped' />
    <div class='after'></div>
</div>

or

You could just as easily use this same method to throw rounded corners around blocks of text or create some really nice pull quotes.

This approach is pretty similar to the CSS before and after pseudo classes, but is properly supported across A-Grade browsers. Also, I think this gives you a little more flexibility, as you can could embed checks on the content you are about to wrap and make slight tweaks. For example, if you were wrapping blog comments, you might want to call out the post author’s comments in a slightly different way.

I wasn’t fooling anybody, all systems designed and implemented by man are susceptible to catastrophic failures, anyone would stopped even for a second would immediately realize that. By trying to brush them under the rug and pretty like they never happened, I was doing myself a disservice. The first place I end up looking whenever I start a new project is my past, and by hiding my previous flubs, the chance of me pulling the same bone-headed move again kept going up and up. By sucking up my pride and making notes of where I had gone wrong in the past, it’s been a boon in a number of ways:

• I only make a mission critical error requiring me to sleep at my desk once. Usually.
• Anyone else who reads or uses my code can hopefully avoid a couple of late night sessions of their own head scratching.
• It proves to the world that a real live person wrote and is actively maintaining the site/tool/app, and moreover that they are continually looking for ways to make it better and enhance the experience.
• Also it serves as notice of common points of failure to watch out for in future endeavors. (ie: always sanitize every field you let a user fill into their profile).

This “revelation” came to me when I was fixing a pair of pants. I used to routinely skip wearing a belt and thusly blew buttons off my fly left and right. After a couple years of patching them up with nicely matching thread, and subsequently popping them right back off my trousers, I had enough and needed to find a better way. I figured if I cared enough to put the effort into continually fixing them, there was no reason to hide that, so I switched over to bright orange and hot pink thread. Almost immediately I stopped trashing clothing because the trigger of seeing where I had gone wrong in the past, and reminded me to put on a belt.

So, I say to you, relish in your botches, slip ups and fubars. Hem your pants in lime green and you’ll stop buying stuff a size too large, in more ways that one.