Downloading your code from Google App Engine

Constantinos — Thu, 17 Apr 2008 14:42:23 +0000

I've started using Google's App Engine since it launched, mostly playing around with Python (always wanted to learn), and setting up a small app to deal with my Desktop Photo Feed script. One irritation I had was that I wanted to share my code with a friend, but the app engine doesn't provide any way of downloading the source code.

One way around this that I found, was a blog post by David Burger on Download Your Code from Google App Engine, where he created a Makefile to do the dirtywork. Because I don't like Makefiles (and have it from good authority that Googlers hate Makefiles too, but that's besides the point - just to reinforce my position), I modified his method to make it slightly more versatile so that it can work well with OS X (tar includes ._* resource fork files which are annoying), and also turn it into a shell script.

There are two steps to the process. First, save this code as a file called something like update.sh in the base folder where your app code is located, and make it executable:

ARCHIVE_DIR=archive
ARCHIVE_NAME=`basename $PWD`.tgz
 
rm -rf ${ARCHIVE_DIR}
find . -name "*~" -delete
find . -name "*pyc" -delete
export COPY_EXTENDED_ATTRIBUTES_DISABLE=true
export COPYFILE_DISABLE=true
tar -czf ${ARCHIVE_NAME} --exclude .DS_Store --exclude ${ARCHIVE_NAME} -C ../ `basename $PWD`
mkdir -p ${ARCHIVE_DIR}
mv ${ARCHIVE_NAME} ${ARCHIVE_DIR}
appcfg.py update ./

Download this script

Then, you would probably want to password protect the resource that points to this archive file, so add this to your app.yaml file:

- url: /archive
  static_dir: archive
  login: admin

Now, whenever you wish to update your app, just execute ./update.sh instead of ./appcfg.py update ./, and the archive of your source will be created and uploaded with your changes. To download, assuming the folder your application is in has the same name as your application, just visit http://yourapp.appspot.com/archive/yourapp.tgz where yourapp is your app's name, and yourapp.tgz is your app folder's name if it's different from your app's name, and you will be prompted to download the archive assuming you're logged in as administrator. That's it!

Hints and code snippets for a more sane OS X Terminal experience

Constantinos — Mon, 13 Nov 2006 11:06:56 +0000

Pretty long title, huh? Well, I’ve finally made the decision that there’s no way I’ll ever be able to keep a journal. So instead, I’ll start posting code snippets and general hints that I mostly harvested online (and try to cite wherever I can – remember that is -), but also modified to suit my purposes… First up is seamless integration of X11 in OS X with the Terminal application.. Read on for the code

First off, the reason I got started in this: I HATE xterm. Really dislike it, to the point where I would actively avoid any xwindow apps. That’s until I came across this hint at macosxhints.com. Really nice hint, but to get the best possible approach you have to shift through all the comments, and merge some bash with some csh scripts in order to get the most seamless approach. So this is my solution, for the bash shell, derived from that hint on macosxhints, and explicitly avoiding any modifications of master files (which might get overwritten with an OS X upgrade).

First step, is to prevent X11 from opening up an xterm window. That’s fairly easy. Simply create a file called .xinitrc under your home (~/) directory with your favorite editor (like TextMate ), and paste this code in it (lifted straight off the aforementioned hint):

PATH=/usr/X11R6/bin:$PATH
 
# surpress starting of an initial xterm
xterm()
{
    return 0
}
 
# remember the display name
echo "$DISPLAY" > $HOME/.tmp/X11-display-`hostname -s`
 
# run system-defined xinitrc (doesn't return)
source /etc/X11/xinit/xinitrc

Now what this does, is redefine the function that calls up the xterm window, and make it do nothing. Then the master file is sourced, so no harm no foul. This modification will survive across upgrades too.

Now to the more tricky part. In your .bash_profile file, insert this little gem of a code:

if [ !$DISPLAY ] && [ !$SSH_TTY ] && [ !$REMOTEHOST ]
then
    export DISPLAY=`ps xw -o command | sed -n '/^\/.*X11.*\:/s/.*:/:/p'`
fi
 
if [ $DISPLAY ]
then
    if xwininfo -display "$DISPLAY" -root >/dev/null 2>&1
    then
        echo Using X11 display $DISPLAY
        export DISPLAY
    else
        unset DISPLAY
    fi
fi

This piece of code simply tries to capture the $DISPLAY given by X11, so it can be used in the Terminal. This is usually :0, but not if you’re running it over ssh. This should catch either.

So far so good. Whenever I need xwindows, I can start X11, then open a new terminal window and voila. But wait a minute. Why would I have to manually start X11? When that app is idle, it’s using up almost zero resources. I could very easily place it in my startup items. That’s a good solution, with the problem being that I rarely need X11, and I don’t want to have it in my dock all the time.

This is where the magic happens (btw this same method can be used to hide the dock and menu-bar of pretty much ANY app). Find the X11 app in the finder under /Applications/Utilities/. Ctrl-click on it, and “Show Package Contents”. Then navigate to Contents/Info.plist, open it up in the Property List Editor, and add a new sibling under Root called LSUIElement, set it to boolean, and give it the value ‘Yes’ (or set it to string and give it the value 1). Save the plist file, and close it.

Almost there. Now in the terminal, give the command touch /Applications/Utilities/X11.app/, and you’re all set. Double click on the X11 app to start it, and… nothing! The only way you can know it’s running, is if you look for it in the Activity Monitor! This won’t survive across upgrades of X11, and in fact if X11 gets upgraded you will have to open Activity Monitor to kill it before the upgrade, but I feel it’s an easy change to make, and a change that’s almost a second nature to me.

So that’s my solution for this. Right now I have X11 running in the background at all times, and terminal simply captures the display and uses it whenever it needs it. And since all the modified files are in the user’s home directory, this solution will survive across OS upgrades. As a final note, I do have the capture script for tcsh, but it’s the same as the script listed in a comment of the previously mentioned macosxhints hint, so I won’t enter it here again. Just look for it there.

Voodoo Programming » Hack

Downloading your code from Google App Engine

Hints and code snippets for a more sane OS X Terminal experience