Tuesday, December 08, 2009

Continuous Quality of .py files on app engine experiments

I've been working on a few small experiments with appengine capabilities (sending e-mail, receiving e-mail, sending and receiving instant messages over xmpp) . It has given me the chance to try Ale on some projects smaller than Flexvite, and I've really enjoyed it.

Typically I get the skeleton of the experiment up in about 60 seconds by using the helloworld quickstart, then adding pyflakes and watcher into the mix with 'ale install pyflakes' and 'ale install watcher'. Once I have spun up 'ale watcher', I've got something that is continuously checking my .py files for extraneous imports, undeclared vars, etc. It's really very nice to be told that you can loose two or three imports and simplify your codebase -- even when your codebase is small! Of course 'ale watcher' can also be used to trigger the running of unit testing or other checks, but for the experimental nature of these projects, that didn't seem necessary.

So for these experiments, my ale setup looks like:

$ ale

Syntax: ale <command>

Core commands:
list list commands currently recipes_installed
create create -- create the skeleton for a new command
install install
remove remove Uninstalls a command
search search commands available for install

Additional Commands:
gae google app engine .ale
pyflakes run pyflakes (lint tool) against the project or pyflakes [dir]
watcher monitors files matching a filespec for change and triggers command(s)

$


which is something I'm liking a lot.... you can see the commands I'm using with the project without a lot of extraneous stuff.

Starting it up is as simple as 'ale gae start' (which launches the server, and a browser to the app), and deploying it to the google cloud infrastructure (appengine) is as simple as 'ale gae deploy'.

It also turns out to be pretty simple to add these to the ale 'createapp' command (using the tarballs generated by github), so I went ahead and did that so that it's easy to pull one down quickly when you need it:


$ale createapp

createapp [templatename] -- create an app from a template
available app templates:
helloworld -- simple helloworld app
helloworldwebapp -- simple helloworld app using webapp fmk
xmppsendandreply -- simple xmpp (instant message) send and reply
emailreceive -- simple e-mail receive example
emailsendui -- simple e-mail send example

$

Friday, December 04, 2009

App engine [local] hello world in 60 seconds

I'm toying around with a little experiment at http://github.com/mpstx/Ale It helps you get a tool stack configured quickly to do appengine development without affecting your system's default python environment or installed apps -- something I spent more than a little time rolling by hand during the development of Flexvite. Here's a little preview:

To create an _Isolated_ (no global installs/sudos!), local App engine hello world on OS X in 60 seconds, do this:

  1. Environment setup :
    mkdir aehello; cd aehello

  2. Install Ale :
    git init; git submodule add git://github.com/mpstx/Ale.git .ale

  3. Init Ale :
    .ale/init.sh

  4. Install appengine :
     ale install gae

  5. Install createapp :
    ale install createapp

  6. Create a basic app :
    ale createapp helloworldwebapp

  7. Start local server and browser :
    ale gae start



You can now edit helloworld.py and refresh the browser...change should be reflected instantly.

To delete everything just rm -rf the aehello directory and you'll be totally clean again.

To Deploy it to the cloud...

  1. Go create a google app engine account.

  2. create an appid

  3. modify your app.yaml to reflect your new id

  4. To deploy to yourappid.appspot.com :
    ale gae deploy

Tuesday, September 22, 2009

I'm tired of typing "self." before every assert method in a python unit test

If you've spent anytime using the python unittest framework, and you have any appreciation for things being succinct, perhaps you will find something useful in this approach to co-opting the basic assert methods and making them available in a global context (as opposed to them only being available on the TestCase instance (through a 'self.' reference). It seems safe enough since these methods are generally not using a lot of instance state anyway -- just raising a particular exception. Enough talk. Here's the stuff:


class FakeTest(unittest.TestCase):
"""
only purpose is to provide a surrogate for providing global assert methods below
"""
def testNothing(self):
pass

assertMethodStealerTestCaseInstance = FakeTest(methodName='testNothing')

assertEquals = assertEqual = assertMethodStealerTestCaseInstance.assertEqual
assertNotEquals = assertNotEqual =assertMethodStealerTestCaseInstance.assertNotEqual


After typing 'self.assert...' hundreds of times, I can attest that that 10 lines is well worth it - besides the typing, it makes your tests easier to read too!

Saturday, September 19, 2009

A small jquery+iso+timezone+browser recipe

So, on my current project (Flexvite), I wanted dates and times to adjust themselves to the browser's timezone on-the-fly throughout our site and without any extra steps for the user (like setting a timezone on their account). HTTP posts will include a datetime with a timezone that you could parse out, but I wanted it for HTTP gets also, and without having to do any hidden frame or secret post or redirect tricks.

Perhaps some jquery guru will tell me this is horribly non-performant, but for now it works and meets our need so I sharing it here.

Here's the basic recipe:

Step 1: Go grab these excellent 2 libraries for javascript iso8601/rfc3339 datetime parsing and javascript date formatting. Include them in your page.

Step 2: When serving up your page, wherever you want a date or time localized to the user's timezone, create a div structured like this:


<span class="dateToLocalize">
<span class="dateIsoDate" style="display:none">2009-09-18T11:30:00-05:00</span>
<span class="dateFormat" style="display:none">h:MM tt</span>
<span class="date">11:30 am</span>
</span>

// Notice that it includes a hidden copy of the datetime in iso8601/rfc3339 format, as well as

// parameters to pass to the client-side datetime formatting function


Step 3: Use some jquery magic to find these structured div's on the client side, and adjust to the user's local (browser) timezone if necessary:


$('.dateToLocalize > .date').each(
function() {
d = new Date().setISO8601($(this).parent().find('.dateIsoDate').text());
format = $(this).parent().find('.dateFormat').text();
formattedDateHtml = d.format(format);
$(this).html(formattedDateHtml);
}
);

Step 4: Just run that function when your page loads and every date/time in the page (that is layed out with the aforementioned structure) will be automatically localized to the browser's timezone. sweeeet.

Wednesday, August 19, 2009

Hotkey screen capture and post to Campfire with Spark + Pyro + Applescript + OS X screencapture

I found something _reallly_ handy with applescript (finally!).

Here's the applescript to do an interactive screen capture (os x style) and post the result immediately to a campfire room.

property N : 0

set N to N + 1

set picPath to ((POSIX path of (path to desktop)) & "Picture_" & N & ".png") as string

do shell script "screencapture -i -tpng " & quoted form of picPath


tell application "Pyro"

upload picPath to room "roomoncampfire" in campfire "yourcampfiresubdomain.campfirenow.com"

end tell


I tied this to a keystroke with my tool of choice 'Spark':
















Pretty handy, and thanks to some of the existing articles out there, it didn't take long to put together either. Applescript win!

Inspired by: