Unfortunately, none of the tools I’ve used to import my data provide a way for me to split this combined “workout” into separate workouts. To overcome this, I wrote a little script which reads a tcx file and splits it up into separate workouts based on the amount of time between one lap stopping and the next starting. You can use it online at my Garmin Workout Splitter page.

The source code for the site is included below. It is quite reliant on the structure of Garmin’s tcx files -mostly because Garmin seems to be a bit overly sensitive about capitalization (and maybe spacing too) which meant I couldn’t use BeautifulSoup to do the parsing (I tried, and then realized Garmin wouldn’t have any of that, doh).

Unfortunately, this is a bit of a pain if you want to use UPSERT on many tables, so I wrote a Python method which takes care of the UPSERT logic generically. To use it, you call it with a cursor connected to your database, the schema and table name, a list of primary key field names, and the key-value pairs for each field.

For example, let’s say you have a table which tracks scores (and only the last score counts):

CREATE TABLE MySchema.Scores (
    user_id integer PRIMARY KEY,
    score   integer NOT NULL
);

To UPSERT a row into this table you would:

db_conn = psycopg2.connect("...")
db_cur = db_conn.cursor()
upsert(db_cur, 'Scores', ('user_id',), schema='MySchema', user_id=..., score=...)
db_conn.commit()

Here’s the code for the Python-based upsert method:

fetch_asynchronously(url)

You can also pass fetch_asynchronously() any arguments which urlfetch.make_fetch_call() accepts (e.g., method, payload). You can also ask it for a callback which will conveniently include the RPC object (which contains the results) as well as any other positional or keyword arguments you would like.

At the end of your request, just call wait() to ensures that any pending fetches and their callbacks are completed prior to the request handler terminating.

* Unfortunately, App Engine does not currently provide select() or any other non-blocking mechanism which can check if an RPC has completed.  Once it does, this implementation could be improved to ensure that it only waits on an RPC which has already completed (currently we just have to wait on the oldest one – this is sub-optimal since later RPCs may actually finish first).

One way to discourage this behavior is to limit how often a user can take a certain action to a fixed rate. I’ve created a RateLimiter class which handles the logic of tracking how quickly a user is making requests, and determines when your code (optionally) should challenge the user with a captcha before allowing them to continue. If you simply want to rate limit the user’s requests, you can ignore the captcha business and just return an error to the user whenever they exceed the allowed rate.

The source is available at http://gist.github.com/437051 (including the optional captcha handling code).

Example Usage:
The example code below shows a rate limiter which allows a user to interact with a particular page once every 2 seconds. It also gives the user 3 “tokens” which allows the user to violate this limit by up to 3 requests. Tokens are consumed if a user makes a request within 2 seconds of the previous request. Tokens are returned if the user if the user slows down, or if the user solves a captcha.

This example is written as if the request is expected to be made via JavaScript on your page. The client-side JavaScript would check the response for the 'captcha-show' text and prompt the user with a captcha if that test was present. When the captcha is answered, another AJAX call would be made to send the user’s response to the CaptchaHandler class in rate_limit.py. You are free to integrate the captcha challenge however you like. Just call RateLimiter.captcha_solved() or RateLimiter.rate_limit(uid, captcha_solved=True) when the user meets your challenge (it doesn’t even have to be a captcha).

Beaker is a solid implementation, but it lacks support for memcache on app engine. This means every request must go to the datastore to fetch session data – yuck.

gaeutilities is designed for app engine and takes advantage of both memcache and the datastore. Unfortunately, the code is a bit heavyweight – it is coupled to unrelated functionality (e.g., “flash” messaging) and it is complicated by support for options I do not need (e.g., cookie-only sessions and automatic token rotation). Most significantly, its performance suffers from excess API calls and inefficient model storage.

Since I was unsatisfied with these options, I wrote my own sessions middleware, gae-sessions. It strives to be lightweight, fast (but reliable), secure, and easy to use. I ended up with a pretty small library (200 lines of code) which met these goals. It uses memcache (for speed) and the datastore (for reliability) but only reads and writes when it must. db.Model objects are efficiently stored by converting them to protobufs instead of using the automatic pickling functionality (which is slow since app engine lacks cPickle).

Consider gae-sessions if you need sessions support for a Python web application hosted on Google’s app engine. The project includes demo code which you can run without modification on the app engine development server. The demo shows gae-sessions working with an OpenID-based authentication system powered by RPX (check it out to see how easy it is to integrate with RPX).

Update: I’ve created an in-depth comparison page which compares both the features and performance of alternative sessions libraries (beaker, geautilities, gmemsess, and suas) with gae-sessions.

The best solution I’ve seen is to prefix logging statements with if __debug__: so that they are optimized away by python -O (see this post on StackOverflow). I like it, but it unfortunately requires this statement to be prefixed to every logging statement I don’t want in a production environment. That’s a lot of ugly extra code and it isn’t easy to change which statements it applies to either.

I decided to write a script which automatically parses a Python file and replaces logging statements of a particular level with a pass statement and a commented out copy of the logging code. It can also do the reverse operation. It has some limitations (see the code, or run the script with the --help option), but it should work for most Python files. I used it for the VNS project and it successfully operated on every file in the project. It also improved performance dramatically – the maximum throughput of the VNS simulator increased by 25%! In comparison, running the code with Psyco only garnered a 6% improvement (though pretty substantial for the minimal 13 lines I had to add to take advantage of it).

I think this script is worth using before running your code in a production environment if you are a heavy user of the logging module like I am. You can find the code here (it is hosted on Siafoo, a neat site for sharing code). Here’s the latest version of the code:

Luckily, I stumbled on a module which works on top of the libpcap packet capture library called pcapy. It is simple to use, and thread-safe — and easy to integrate into a Twisted-based project.

I put together a short sample (see below) which shows how to capture raw packets alongside the main Twisted event loop. It would be trivial to extend this example to also write to a raw socket (using an ordinary Python socket). This example can also be downloaded here.

# This sample shows how to run a libpcap-based packet sniffer concurrently with
# the Twisted framework.  The Twisted component is an "Echo" TCP server
# (listening on port 9999) which prints everything it receives.  When a client
# connects, it starts the pcap thread.  When the pcap thread receives a packet,
# it sends a message to the client telling it the size of the received packet.
# Finally, when the client disconnects the program is terminated.
 
# To try this contrived example out, run this script as root (so that it can use
# pcap) and then connect to the echo server (e.g., telnet localhost 9999).  Note
# that the pcap parameters are hard-coded.  This code uses twisted 8.0.2 and
# pcapy-0.10.4.
 
import os
 
from pcapy import open_live
from twisted.internet.protocol import Protocol, Factory
from twisted.internet import reactor
 
# pcap settings
DEV          = 'eth0'  # interface to listen on
MAX_LEN      = 1514    # max size of packet to capture
PROMISCUOUS  = 1       # promiscuous mode?
READ_TIMEOUT = 100     # in milliseconds
PCAP_FILTER  = ''      # empty => get everything (or we could use a BPF filter)
MAX_PKTS     = -1      # number of packets to capture; -1 => no limit
 
def run_pcap(f):
    # the method which will be called when a packet is captured
    def ph(hdr, data):
        print 'pcap heard: when=%s sz=%dB' % (hdr.getts(), len(data))
        # thread safety: call from the main twisted event loop
        reactor.callFromThread(f, len(data))
 
    # start the packet capture
    p = open_live(DEV, MAX_LEN, PROMISCUOUS, READ_TIMEOUT)
    p.setfilter(PCAP_FILTER)
    print "Listening on %s: net=%s, mask=%s" % (DEV, p.getnet(), p.getmask())
    p.loop(MAX_PKTS, ph)
 
# a silly echo server which prints what it receives and sends info about the
# size of each packet captured on DEV
class Echo(Protocol):
    def connectionLost(self, reason):
        os._exit(0) # kill the whole process
 
    def connectionMade(self):
        # run pcap in another thread (it will run forever)
        reactor.callInThread(run_pcap, self.pcapDataReceived)
 
    def dataReceived(self, data):
        print 'echo got: %s' % data
 
    def pcapDataReceived(self, sz):
        self.transport.write('pcap got: %uB\n' % sz)
 
# starts the silly echo server on port 9999
def main():
    factory = Factory()
    factory.protocol = Echo
    reactor.listenTCP(9999, factory)
    reactor.run()
 
if __name__ == "__main__":
    main()

One idea is to put the table in a minipage. This causes the footnote to show up at the bottom of the table (in its own numbering system) — but I wanted the footnote to show up at the bottom of the page like other footnotes!

Another idea was to manually specify the footnote number inside the text and then use the \footnotetext command (outside the tabular) to manually add the footer. Unfortunately, this is not a robust solution since it forces you to manually maintain this footnote number inside the tabular.

Building on the previous idea, I discovered a way to make footnotes appear inside tabulars without breaking the automatic numbering of footnotes. Here is my approach:

1. Include the “fmtcount” package so that you can display the values of counters (e.g., the footnote counter):

   \usepackage{fmtcount}

2. Immediately before your tabular, increment the footnote counter:

   \addtocounter{footnote}{1}

3. Next, specify the contents of the footnote:

   \footnotetext[\value{footnote}]{your text here}

4. Finally, add a reference to the footnote inside the table:

   $^{\decimal{footnote}}$

You can extend this idea to add multiple footnotes within a single tabular by adjusting the counters (using \addtocounter) appropriately. Here is a complete example of how to add two footnotes inside a single tabular (you can see the PDF output here):

\documentclass[12pt]{article}
 
\usepackage{fmtcount} % displaying latex counters
 
\begin{document}
    \title{An Example of Footnotes Inside a Tabular}
    \author{David Gridley Underhill}
    \maketitle
 
% manually add a footnote which exists inside the table
\addtocounter{footnote}{1}
\footnotetext[\value{footnote}]{my first footnote}
 
% add another footnote
\addtocounter{footnote}{1}
\footnotetext[\value{footnote}]{my second footnote}
 
% reset the counter to the first footnote's value
\addtocounter{footnote}{-1}
 
\begin{tabular}{|l|l|}
  \hline
  % this next row references the first footnote I added above, and then
  % advances the counter to the next footnote.
  {\bf First Column} & {\bf Second Column}$^{\decimal{footnote}}$\addtocounter{footnote}{1} \\
 
  \hline
  % now reference the second footnote from above -- don't increment the footnote 
  % counter beyond the last footnote!
  X & Y$^{\decimal{footnote}}$ \\
 
  \hline
\end{tabular}
 
\end{document}

I wanted to use the github API to get a list of those who watch the project, and then send an email to those people. Unfortunately the API does not let you query that yet. Instead, my script lets you specify the recipients manually. Alternatively, a simple mailing list implementation is provided so people can sign up for the post-receive emails through a webpage instead.

The only downside is that the JSON github provides does not include information about how many lines were modified, just files. In this respect, Andy Parkin’s post-receive script produces slightly more informative e-mails (but of course it doesn’t work with github).