Brian Hicks

STL Python: Class Complete

2014-03-20T00:00:00+00:00

STL Python has just finished it’s inaugural programming class: Intro to Programming with Python. With slightly more than a full class, I’d call it a success.

Why offer a class in the first place?

As a whole, I think programming is an interesting career, and I’ve found enjoyment and employment there. But in a bigger picture, it’s a great “secret weapon” in a non-tech field. Case in point, we had researchers from Washington University join the class because they needed to learn how to program in order to further their own research.

There is a bigger reason to teach programming: tech is monocultural. Diversity of thought and opinion will make stronger people that do more good in their communities. (And as an aside, maybe we can stop making products that only rich white guys will ever want and start doing some stuff that to the benefit of people outside the tech scene.) By teaching people outside our sphere how to program we’re not only increasing their economic opportunity but our own chances of survival. There are a lot of thoughts and organizations working on this: The Ada Initiative’s FAQ, Ashe Dryden’s Blog, Rails Girls, and this article on Color Lines are a few good places to look if you’re interested in learning more about tech’s diversity problem.

It would also show lack of care on my part to not mention that Tony Becker (my co-teacher for this class) has also published some thoughts on this.

Hitting the ground running

Tony approached me about co-teaching a introductory programming class early in 2014. I’ve wanted a class for St. Louis for a long time, but never had the gumption to do alone. We started planning out our curriculum right away. We chose How to Think Like a Computer Scientist by Allen B. Downey to teach the course with since it is written for beginner computer science students. We considered a number of ways to get Python installed on students’ computers and ended up settling on Anaconda Scientific Python Distribution which turned out to be a great option (although nothing is without it’s problems, as we’ll see later.)

We also made a deal with Nebula, a coworking space on Jefferson Street, to use their conference room. I’ve got to give Tony all the credit on this one: he hoofed it around town to find the best meeting place for our class and did the hard work of negotiating agreements, plus food for every week. Hats off!

Once we had secured the space and time, we made a launch announcement on @STLPython and our personal Twitter accounts. Several high profile accounts retweeted and shared our message all over the internet, and within three days we had our initial slate of 40 students filled. I thought we would maybe get half of our cap, but apparently there are an enormous amount of people looking to learn to code. I’m still getting emails at least once a week asking how to join or when the next class starts.

The Class

We went into this knowing that our ideas were not going to be all good. Unsurprisingly, not all of them were!

What worked

Anaconda was a major win. We asked people to download the software before class, then simply distributed a couple of USB sticks around the classroom the first night and we were finished in 15 minutes. Everyone had the same environment and tools. Easy!

The thought behind Light Table as a next-generation IDE means that it works great as a teaching tool. Define something, hit cmd+enter, and see the output right there next to your code. I cranked the font size up so everyone could see, and it suddenly became a giant interactive chalkboard.

Nebula is a great space for a large(ish) group to meet. Jason (the owner) and everyone there were friendly and welcoming, and even agreed to host a regular STL Python meeting while T-REX was moving.

What was not so great

How to Think Like a Computer Scientist turned out to make some assumptions about our students that weren’t valid. Specifically, it assumes that students come from a strong mathematics background, which almost none of our class (including me) had. As an example, one of the exercises had students implementing Fermat’s Last Theorem. It was difficult to teach that and then have to explain to my students that yes, their code did in fact work, but there were no known inputs to get it to do that branch of the conditional. Not a great demonstration of conditionals, which the exercise taught. In addition, there were a number of times when the authors taught an older or obscure way to approach a problem and then in a footnote said something along the lines of “it’s much simpler if you just do it like this” which nearly always turned out to be the way real world code (the goal) would implement the feature.

We tried to set up Google Hangouts for office hours, thinking that the Hangouts On-Air would work and that people would be able to stream it even if they couldn’t join the call. It turns out that office hours need to be much more interactive because beginner students require a tight feedback loop (or at least, tighter than Hangouts On-Air can provide.) We ditched that in favor of Fuzebox which worked a little better.

For next time

This seemed to be a great experience for everyone who participated. We ended up with about 25% of the people we started out with, but most of those who dropped out emailed us to say “it’s not you, I have other commitments on my time and can’t finish the course.”

For the next class, we’ll be making a few changes. First, we’ll be trying to find a new textbook. How to Think is a good textbook for introductory CS students, but it’s not too great for what we’re doing and some of the examples and code samples are a little dated. In addition, we want to be teaching our students “real world” Python. How to Think alludes a little bit to the idea of something idiomatic Python but didn’t define the concept to our satisfaction. If we can’t find one we’ll write our own (but we’d much prefer to use an established book. If you know of any, please drop me a line.) This is intended to be more of a reference material, because…

Second, I’d like to try different kinds of assignments. Practical application of Python being a core tenet of the course it seems necessary to do similar things to what you’d create in real life. Or at least, things the students find interest in doing. The last night of class we did a group exercise on Markov Chains which everyone in the class got a laugh out of (we used The Adventures of Sherlock Holmes as source text.) Things like that will probably play a more central role in future versions of the course.

And lastly, we intended the in-class sessions to be Q&A about the material covered during independent study. That turned out to be an OK fit but throwing someone into a new field and expecting them to ask good questions in a group setting is maybe a little daunting for the learner. We will be carefully considering our course format, and maybe making a few changes there.

To finish up, if you were in the class: thank you for coming. I learned as much from you as (I hope) you did from me and Tony. And of course tons of thanks to Tony, who did so much of the administration for this class. We’ll see you again soon!

Temptation of Pypy

2013-09-24T00:00:00+00:00

So last week I attended Strangeloop (which was excellent, by the way, and you should go if you ever have the slightest chance.) I had a couple conversations with people about performance and JIT compilers and stuff like that, and right now I’m really tempted to try out Pypy. The target project which I’m thinking about has the following properties:

Mostly Python (i.e. few C extensions)
Needs to be fast. (last week NewRelic measured it at 11.9ms response time)
Calls the same methods over and over with the same types.

BUT, it also has this going on:

The DB persistence is pymongo/hiredis (the only two C extensions here)
Those few methods are called with complex types (specifically, Django’s request objects.) I’ve heard this can be a problem for JIT compilers, and if it is I don’t know that we’ll fully realize the speed gains.

So I’m torn, and that’s why I’m putting it up here: can anyone with experience running Pypy in production shed some light on these concerns, or am I going to have to just try it and measure performance?

Post Script

2013-09-03T00:00:00+00:00

After reading this Scott Hanselman post on keystrokes I’ve realized that while I’ve tweeted quite a bit in the past couple of years I’ve hardly ever blogged, when that would be much more useful (not to mention sustainable.)

So, here’s a little script wrapper for posting quickly to a Jekyll blog hosted on your filesystem.

Aliases are helpful to use this - I have this particular blog aliased as:

alias blog="post ~/code/sideprojects/brianhicks.github.com/_posts -c -p 'git push'"

Then I can just blog "Post Script" to generate some boilerplate for this post, for instance. When I save and quit vim, it’ll get pushed to GitHub pages automatically.

Hopefully I can remember to “post more in the future” although that’s an empty promise of many a personal tech blog.

Without further ado, the wrapper (the irony of this being written in Python is not lost on me, for the record):

#!/usr/bin/env python
"Wrapper for posting to a Jekyll blog from the command line"
import argparse
from datetime import datetime, timedelta
import operator
import os
import re
from subprocess import call

parser = argparse.ArgumentParser(__doc__)

parser.add_argument(
    'where',
    help='Which directory to post to'
)
parser.add_argument('title', help='Title of the post')
parser.add_argument(
    '-d', '--date',
    default=datetime.now().strftime('%Y-%m-%d'),
    help='Date the post should be published (ex: 2013-06-19)',
)
parser.add_argument(
    '-o', '--offset',
    help='Days to offset post by, based on latest post (ex: +2 or -5)',
)
parser.add_argument(
    '-n', '--offset-now',
    action='store_true',
    help='If present, offset from current date instead of last post'
)
parser.add_argument(
    '-c', '--commit-after',
    action='store_true',
    help='If present, add and commit to git afterward'
)
parser.add_argument(
    '-p', '--post',
    help='Extra command to run after hook, if committed'
)

if __name__ == '__main__':
    args = parser.parse_args()

    # transform the parsed arguments
    slug = re.sub('[^\w-]', '', re.sub('\s+', '-', args.title).lower())

    date = args.date

    # do relative posting dates, from the latest post. Override date if provided.
    if args.offset:
        if args.offset_now:
            base = datetime.now()
        else:
            latest = sorted([x.split('-') for x in os.listdir(args.where)], reverse=True)[0]
            base = datetime(int(latest[0]), int(latest[1]), int(latest[2]))

        op = operator.sub if args.offset.startswith('-') else operator.add

        date = datetime.strftime(op(base, timedelta(int(args.offset[1:]))), '%Y-%m-%d')

    title = '%s-%s.md' % (date, slug)
    filename = os.path.expanduser(os.path.join(args.where, title))

    text = "---\ntitle: %s\ndate: %s\nlayout: default\n---" % (args.title, date)

    if not os.path.exists(filename):
        with open(filename, 'w') as post:
            post.write(text)

    call([os.environ.get('EDITOR', '/usr/local/bin/vim'), filename])
    if args.commit_after:
        os.chdir(args.where)
        call(['git', 'add', title])
        call(['git', 'commit', '-m', 'Add %s' % title])

        if args.post:
            os.chdir(os.path.abspath(
                os.path.join(args.where, '..') if '_posts' in args.where else args.where
            ))
            call(args.post.split())

Graph Task Dependencies with Python

2012-05-29T00:00:00+00:00

I’ve finished a little script for graphing taskwarrior dependencies with GraphViz and Python. Have fun with it.

Notes

2012-05-02T00:00:00+00:00

I’m taking the Coursera machine learning course, and I will be taking notes and putting them up here. Access them at the notes section in the navigation.

javascript dates

2012-03-19T00:00:00+00:00

I’ve just spent half an hour wrestling with this, and for the benefit of those to come…

d = new Date(2011, 12, 08)

Will produce a new datetime object, right? No biggie, if you look inspect it, it displays like this:

"Thu Dec 08 2011 11:33:05 GMT-0600 (CST)"

But lo, the beast lurks. calling getFullYear and getDate work fine, and return 2011 and 8, respectively. But getMonth is a bit different. See, the Date object thinks of January as month 0, February as month 1, etc. So converting from one date to another (to get the first of the month at midnight, for example) would be done like this in Python:

>>> d = datetime.now()
   >>> month = datetime(d.year, d.month, 1)

But has to be done like this in Javascript:

d = new Date()
   month = new Date(d.getYear(), d.getMonth() - 1, 1)

Yes, I know that methods like setDate exist, but constructing a new object with only what I need seems more efficient.

By the way, here’s the way that MongoDB deals with this in their ISODate:

var year = parseInt(res[1], 10) || 1970);
    var month = (parseInt(res[1], 10) || 1) - 1;
    var date = parseInt(res[3], 10) || 0;

Django test settings

2012-03-19T00:00:00+00:00

Recently I was setting up Sentry logging for an app I was working on, and needed to turn it off for tests, as it was sending logs to a remote server. Here’s how I ended up doing that:

import sys

LOGGING = {
    'version': 1,
    'disable_existing_loggers': True,
    'root': {
        'level': 'WARNING',
        'handlers': ['sentry'],
    },
    # ... snip formatters ...
    'handlers': {
        'sentry': {
            'level': 'DEBUG',
            'class': 'raven.contrib.django.handlers.SentryHandler',
            'formatter': 'verbose',
        },
        'console': {
            'level': 'DEBUG',
            'class': 'logging.StreamHandler',
            'formatter': 'verbose',
        },
    },
    # ... snip loggers ...
}

if 'test' in sys.argv:
    # redirect default errors to NullHandler
    LOGGING['root']['handlers'] = ['console']
    LOGGING['handlers']['console']['class'] = 'logging.NullHandler'

Now I don’t get logging messages in my test output when tests pass, and the tests don’t spam the logging server with messages.

dict syntax

2012-03-19T00:00:00+00:00

I just found out something neat about Python’s dict syntax. First of all, of course this works:

>>> d = dict(a=1, b=2, c=3)

But you can also stick dictionaries in there as the first argument. Go ahead, try it:

>>> d = {'a': 1, 'b': 2}
    >>> d2 = dict(d, a=2, b=3)
    >>> d2
    {'a': 2, 'b': 3}

It’s as if you called update on the dictionary. Neato, eh? It’s especially useful in ming migrations.