In Lab 3, we’re doing a lot more with Boto. It’s useful to have a configuration file and put everything there so that AWS keys, SimpleDB domains, and SQS queue names don’t have to be embedded in the source code. In this post, I’ll talk about using a system-wide config file for Boto.

The config file
The config file itself is very simple. It has several sections, each with a heading. Under the headings are key=value pairs. Here is a simple example:

[Credentials]
aws_access_key_id={redacted}
aws_secret_access_key={redacted}

[simpledb]
imagedomain=picture
commentdomain=comment

You could make other sections for S3 and SQS if desired (those will be used more in Lab 4). Finally, put that file in somewhere it can be accessed by the whole system. Mine will go in /etc/boto.cfg.

Using the config file in Python
You can use the ConfigParser module to get the key/value pairs out of the config file and use them. That code might look something like this:

import ConfigParser
config = ConfigParser.ConfigParser()
config.read(["/etc/boto.cfg"])

Now, whenever you need to get a value from the config file, simply call get() on the ConfigParser object, passing it the section and key you want. For example, if I want to get the imagedomain key out of the simpledb section from the example config file above, I would write this:

imagedomain = config.get('simpledb', 'imagedomain')

Conclusion
The advantage of doing it this way is that all your Boto configuration is stored in one location out of the web root where all your scripts can access it. You don’t have to hard-code all that information into the website code itself, making maintenance easier.

Lab 3 for CS 462 requires you to read from and write to SimpleDB. Using Boto in Python makes this pretty easy. Here are some simple examples:

The templates look like this (pretty simple):

This semester I’m a TA for Phil Windley’s CS 462. (I’m sure you are aware if you’ve been following my blog for any length of time recently.) This is the first time I’ve ever been a TA. All the other work I have done has been programming, an occupation that requires occasional interaction with team members and clients but is largely isolated and personal. Being a TA has really put me out of my comfort zone in a lot of ways, but it’s been a growing experience.

Phil has me teach the lectures whenever we talk about the class project. There are six labs total, and so far I’ve given two lectures (the next one is tomorrow night). Those have probably been the hardest parts of this job for me. Standing in front of a class of 30 people trying to explain things while appeasing the demo gods and not making a fool of myself is a whole lot different from sitting with someone one-on-one in a cubicle working through his questions. It’s been a nerve-wracking assignment. (Didn’t help that last time I all but lost my voice. Lapel mics to the rescue!)

Another complication is that I’m taking this class for the first time as well. Sometimes I’m not able to answer people’s questions because I simply haven’t had enough experience with Python or with some particular part of the lab that they’re having trouble with. It becomes a delicate dance between telling as much as I know, faking it, and owning up to the fact that I just don’t have all the answers.

The survey

Those are my perceptions of myself, however. I wanted to know what the students thought. So I put together a midterm evaluation survey on Google Docs and sent it to the class mailing list. Only seven people ever responded; whether their responses are at all indicative of the rest of the class I may never know. But the results are worth analyzing anyway.

The survey had ten questions. The first eight had a statement about the me, to which the students could indicate their agreement on a scale of 1-5 (strongly disagree -> strongly agree). The last two questions were free-response, asking what I am doing well and where I can improve.

There were only two questions for which all the responses were 4 or higher (“The TA knows the course material” and “The TA is able to answer my questions about the project”). Two others rated fairly high: one 3 with 4′s and 5′s (“The TA understands the project” and “The TA is responsive on the mailing list”).

What I found interesting were the questions “The TA does a good job explaining the project requirements during the lab review lectures” and “The TA is approachable”. These both elicited rather varied (often less favorable) responses. They both serve to confirm my own impressions that my public speaking and interpersonal skills are somewhat lacking. While this is not surprising to me, it indicates that it is an area that sorely needs improvement.

I’m giving another lecture tomorrow on Lab 3. I’ve spent a lot of time preparing for this one, so hopefully I will improve and be able to explain things better this time. I’m really enjoying this job, and I’m excited to develop and become the best TA I can.