1 Mar 2006 titus   » (Journeyer)

Lightning talk / screencast

After a nice blurb or two about my lightning talk at PyCon '06, I thought I'd practice my screencast fu by recording (a version of) my lightning talk. Without further ado, here's a screencast of a rerun of my lightning talk. (Yeah, I know it kinda sucks; I'm still working on the process!)

This took a fair amount of investigatory work. I started out by using SnapZ Pro X, for Mac OS X, which produced hideously large files of generally low quality. After lots of wasted effort, I gave up and switched to pyvnc2swf. I knew (from Chad Whitacre's efforts) that it could work, I just didn't know how well it worked.

Well, the short and sweet of it is that pyvnc2swf is a fantastic piece of software, and with only a minor amount of geek fiddling, I recorded the screencast above. (I actually gave up on using pyvnc2swf directly on my Mac; the screencast was recorded over the network, which is a pretty nifty feature of pyvnc2swf...)

Audio was more of a problem. I ended up recording with Quicktime Pro at the same time as I was doing the screencast, then saved as AIF and re-encoded with LAME before overlaying it onto the SWF file. There were a few mishaps in this process, because QuickTime doesn't save as MP3 (!?!?) and the AIFF file it generated doesn't contain good header info. Amusing nonetheless.

wsgi_intercept & mock_http

While I was at PyCon, an old acquaintance from Reed, Marc Hedlund, contacted me about wsgi_intercept. Apparently he needed to build a mock HTTP server to test client HTTP code, and upon discovering wsgi_intercept thought two things: (a) this is perfect! and (b) hey, I know this guy! Weird, eh? Pity he wasn't at PyCon...

Anyhoo, he very kindly donated a simple mock HTTP example to the project, and I just checked that in. So now you can mock not only the TCP connection but also the entire server side. Heh.

twill and django

In addition to Michael Twomey's overnight hack using wsgi_intercept stuff to test Django, some other people appear to be using twill with django.

Googling about, I found this interesting discussion of unit tests and twill. That led to this file (it's a download link) which was probably not meant to be entirely public, but too late, google finds all...

I looked over the source to understand how they were using twill. A few comments and thoughts, some for them, some for me:

  • twill's browser.get_html() doesn't actually return the tidy-ed or BeautifulSoup-ed HTML. It probably should, or it should at least have an option for it.

  • twill.set_output(fp) will now endeavor to redirect all output to the given fp, so they don't have to do the (painful!) stdio remapping any more.

  • I ended up writing my own test_follow_links for our MailOnnaStick app. Good idea. Should probably be in the std twill extensions lib at this point...

  • I was also thinking of adding in hooks to require that page visits be successful, etc. Looks like they could make use of those; good to know.

  • It would be cool to have random generators for forms that would let you fill in things like name, address, and zip fields with syntactically correect (or intentionally incorrect... hmmm...) input.

  • Use coverage.py to look at the code coverage of your twill tests. That way, you can pretty easily figure out what parts of your Web app are completely missed by your Web tests.

Anyway, no good idea how to find these people, but I'd be interested in hearing their success/failure stories with twill.

--titus

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!