Making Fun of Objects

Oh, wait; not that sort of mocking. Fine. Following the talk on using the fixture package, Jeff Younker spoke on using the PyMock package for unit testing with mock objects. Younker spent the first few minutes of his talk talking about unit testing in general; what I initially thought was simply a meandaring exposition on the nature of testing was actually going somewhere: adding tests to existing code can be painful, because of how intertwined things can be. Creating mock objects can help you isolate pieces of the code from the remainder of the application.

PyMock makes this somewhat simpler by providing a way of “recording” what you want your mock objects to return, and the going into “play back” mode to run the test. It provides a way to mock methods, attributes and generators on Python objects.

Things I’m sure of following the talk:

  • The idea of mocking objects seems like a powerful way to isolate pieces of existing code for the purpose of testing.
  • Showing a slide full of code, with near-zero explanation, for only a few seconds before moving on, isn’t long enough for me to grok it; judging by the under-the-breath comments from those around me, I’m not alone in this.
  • Unit tests are hideously ugly when compared to the beauty of doctests.
date:2007-02-25 13:19:22
category:pycon2007, python, testing

Testing with Fixtures

Following Jim’s talk on zc.ngi, I attended Kumar McMillan talk on using Fixtures to test your programs. According to McMillan, fixtures differ from mock objects in one important way: they use real objects with real data. I haven’t used fixtures or mock objects much, so that was a useful distinction.

McMillan is the developer of the fixture package, which provides a way of loading and referencing test data for your application. fixture also allows you to write tests against fixture objects using either a mixin or a decorator[1]_. Fixture supports loading data into SQLAlchemy and SQLObject; CSV and possible Django support are also under consideration.

Fixture is a relatively young project, but it does appear to be useful for testing data-driven applications.

[1]For testing with nose.
date:2007-02-25 12:48:58
category:pycon2007, python, testing

Testing Network Applications with NGI

Following the keynote this morning, I attended Jim Fulton’s talk on testing network applications with the Network Gateway Interface. Jim advocates the use of doctests, in particular doctests which allow you to mix the documentation and narrative together (note to self: write a post about why this is compelling). When programming network applications, writing tests can be really, really hard: there can be sockets, time.sleep(), threads, etc.

In response to running into these problems with testing ZEO, Jim developed a library called the Network Gateway Interface (NGI). The goal of NGI is that application code doesn’t touch socket code. NGI splits the network application into two pieces: the application side and the implementation side. The application side doesn’t need to be thread aware (or even safe) and uses events to communicate with the implementation side. And the implementation side handles the actual socket or transport work.

Jim’s talk used the example of a simple application, z2monitoring, to demonstrate the NGI. The goal of z2monitoring was to monitor and get status from a running Zope 2 application at the time when status is needed most: when the application is bogged down, responding to requests. When testing with NGI, you create a special testing connection, such as a TextConnection (which just uses plain text). The connection conforms to the IConnection interface, which also provides a way to set the connection handler. The connection handler (IConnectionHandler, natch), is used to respond to events like input, connection close and exceptions.

In addition to the async, event-driven interface, zc.ngi provides a simple, blocking file-like API. This is convenient for developing simple, single-task applications.

Jim spent a short part of his talk discussing about the benefits of non-determinism, such as the existing ZEO implementation. One of these was the “opportunity for the unexpected.” Of course, Jim also noted (with an unclear amount of irony) that production is also a form of testing.

NGI 1.0 was released just before PyCon, and this will probably be the last release. [Un]fortunately, Jim recently found that Twisted provides facilities for this style of programming and testing. Given this, zc.ngi will probably only live on (if at all) as a simplified facade over Twisted’s facilities.

date:2007-02-25 12:48:06
category:pycon2007, python, testing

Testing Tools Panel @ PyCon

Matt summarizes the PyCon’s Testing Tools Panel far better than I could here. I was also hoping for some more… depth, perhaps? I think that a problem with both the web frameworks and testing tools panels is that they had too many participants for the half-hour-ish time slot. Regardless it served as a good overview of the available tools (if nothing else giving me a list to start Googling from).

date:2007-02-24 18:06:19
category:pycon2007, python, testing

Scaling Python on the Web

First session of the day was on Scaling Python on the Web; rough notes which I may clean up later:

  • How fast is fast enough?
    • Don’t prematurely optimize
    • Know where the bottlenecks are, and optimize those specifically?
  • Orders of magnitude: static (httpd), dynamic (python), db-queried
  • Even 40 req/s in 3.4m pages/day
  • Hundreds to low thousands of dynamic page views is usually good enough
  • Scaling isn’t about the language, it’s about:
    • DRY: cache!
    • share nothing
  • built a sample photo-app, FlickrKillr, for demonstration purposes
    • preloaded with 100k’s users, 10-20 photos each
  • first iteration: CGI
    • roughly 23 requests/second
    • problems:
      • loading Python interpreter for each request
      • all resources initialized for each request (inc. db connection)
    • possible remedies:
      • run a Python web server (long-running process)
      • make one db connection per thread instead of request
    • other remedies:
      • fastcgi
      • snakelets, twisted.web, RhubarbTart
      • mod_python
  • second iteration: python app server (CherryPy used for this demo)
    • roughly 139 requests per second
    • problems
      • global interpreter lock — can only utilize one core on a dual core machine
      • sessions in the database — prefer an in-memory session store
    • remedies:
      • run multiple instances of CherryPy (overcode GIL)
      • but then we need to balance with something like nginx
    • other options
      • cherrypy in mod_python
  • version 3: load balancing with nginx
    • 217 requests/sec
    • outstanding problems
      • static files read from disk every time
      • and they’re being read/written from python
    • solutions:
      • memcached
      • combine with memcached w/ nginx
  • version 4: caching
    • 616 req/sec (benchmarking w/ homegrown tool)
    • 1750 req/sec (benchmarking w/ ab)
  • other notes:
    • don’t forget to index
    • without an index, the fourth iteration falls down to 28 requests/sec

date:2007-02-24 12:35:29
category:pycon2007, python

Keynote: Adele Goldberg

The morning keynote for day 2 of PyCon was given by Adele Goldberg. Unfortunately I overslept this morning and missed the first half of the talk[1]_. Goldberg’s topic was eLearning, and the state of computing in education today. My background working in education is very different from the schools she was talking about: she’s apparently been working with computer-based learning in public schools, and studying the aggregate information about the results. My experience was working for a private, K-12, well-funded (regardless of what administrators ever said, the truism was that if they wanted money to be there, money would be there) school. So a lot of the statistics about teachers complaining about computers being out of date didn’t apply.

But the other things, about what works and what doesn’t, just isn’t a suprise. I wish I could remember the examples through the lack-of-coffee haze, but I was suprised by the similarity — I would have thought “money changes everything” (to quote the Cindi). And two points that hit home: teachers (in the aggregate, I presume) haven’t had a pay raise of more than 1% since the 1990-1991 school year, and that the way to get students to learn is to get them to build things and explain what they built to other students.

I was exposed to the latter theory in my Software Engineering course at IPFW. Dr. Modesitt, on the first day of class, presented the idea that there are five levels of learning, with lecturing being the least effective, up to building as the second most effective, and teaching others being the most effective. Now Dr. Modesitt used this to set the stage for how the class would be structured, with most of the work occuring at those upper two levels. And that class was like drinking from the firehose, but I did learn a lot. So although it was in a completely different context, I can attest that it really works.

It was also interesting to hear that Goldberg had built a course/school system on Zope 2 (hmm, that sounds familiar), and that she’s currently working on rewriting it in Zope 3. And in building that from an “instructional” perspective versus “content management” perspective (which is what STOA definitely has). The new tool, CourseCloud, uses XML to represent exercises and instructional content, with the goal being to present the exercises in multiple contexts.

[1]What? I had two hours of sleep the night before, and wound up buying Age of Empires III for my MacBook at Fry’s and stayed up, well, later than planned.
date:2007-02-24 11:52:25
category:education, pycon2007, python

Web, Web Afternoon

Lunch: tasty “Mexican” food, including those tasty cinnamon-sugar coated crunchy-chewy desserty things. Lots of those.

And after lunch, it’s fun with Python on the Web. The first afternoon talk was Ian Bicking’s Everything You Wanted to Know About WSGI but were Afraid to Ask. OK, that’s just my title; it’s really WSGI: An Introduction. WSGI is a specification for connecting pieces of web applications in Python. It’s something (like Eggs) that I can conceptually understand as being important. But (like Eggs) I have a hard time really groking it.

WSGI provides for this idea known as Middleware, which allows you to wrap your applications in, uh, other applications. Ian actually had a good litmus test for what is middleware: if you code is acting as both a client and a server, then by definition it is middleware. Ian also spent some time discussing the idea of “microframeworks”, pieces of software that don’t provide this full stack but can be combined in interesting ways to build something bigger. So yeah, WSGI: darn cool.

Following the WSGI talk was the Python Web Framework Panel, with representatives from Zope, CherryPy, Pylons, Django, TurboGears, Pyjamas, Spyce and Nevow[1]_. Nothing really ground-breaking, but Bob Brewer of CherryPy did make an amusing comment: “Reinventing the wheel isn’t so bad if you’re really interested in wheels.” What did sort of annoy me is the multitude of comments from creators about “looking at Zope and running away screaming.” Look, I agree that Zope isn’t for everyone. I also agree with Phillip: where Zope leads, Python follows. I don’t know when Zope became the Python web community’s collective bitch.

Now, off to my friend Vern’s talk about teaching with Python (and dumping that tired hag “hello, world”), then a nap, lightning talks and finally Shawn and I make our annual pilgrimage to Fry’s.

[1]Apologies if I missed one; this is from memory.
date:2007-02-23 17:10:01
category:pycon2007, python, wsgi

PyCon Keynote: Ivan Krstic

I finally made it to the conference hotel this morning at 4AM. I expected to arrive around midnight. Five minutes before we started boarding in San Francisco, our plane was pulled from service due to infestation. Gross. So two hours later we finally boarded, and after sitting on the tarmac for another 40 minutes, we finally took off. Half an hour for luggage, and hour to get my rental car, and then the drive to the hotel (did I mention I had to blow a toll because I only had $20s, and the promised bill changer apparently only does $1s and $5s?). And its 4AM.

So this morning after what can really only be called a nap, and a big-ass cup of coffee, I’m in the first keynote at PyCon. The speaker is Ivan Krstic[1]_, from the OLPC (One Laptop Per Child) project. If I wasn’t convinced that the OLPC is cool before, I am now.

Let’s assume for a moment that OLPC is a miserable failure at its primary goal of creating a learning machine for children. Even then, after hearing Ivan speak about the technology that’s been developed to support the project, it sounds like a success to me. Some highlights:

  • A dual-mode display that works in either black and white, low power, reflective mode, or a medium-resolution, color backlit mode. And you can switch between the two.
  • A touch pad that’s both capacitive and resistive. Since I didn’t know exactly what that meant myself, I’ll share what Ivan demonstrated. It’s a three-panel touch pad that stretches the width of the laptop. The center section is capacitive, like the touch pads you’re used to. You put your finger on it and the pointer moves. But the entire pad can operate in resistive mode, which means you can grab a stylus, a stick, or any sharp, pointy object and use it like a mini-tablet. Darn cool.
  • Experimentation with battery chemistry. Chemistry was my nemesis in college, so I promptly blocked out the checmical formula. But Ivan passed around two batteries with the same capacity. One a traditional NiMH, and the other Super-Duper-OLPC. The weight difference was really amazing. Apparently it also runs cooler than the NiMH.

So while all of that is really darn cool, you might wonder why Ivan was invited to keynote at PyCon, which is, afterall, the Python conference. Sugar, the OLPC user interface model, is written in Python. In fact, as Ivan describes it, the OLPC is rife with Python. Non-Python components consist of X11, the kernel and the sound driver. The file system is written in Python as an object-store of sorts, and therefore supports things like n-way syncing, versioning, deltas, compresion and metadata tracking.

In addition to talking about the technology developed for the OLPC and the use of Python in OLPC, Ivan spoke about the state of software development today. In particular, he lamented the fact that coding small does not seem to be a priority anymore. Ivan gave the example of an anonymous CD-burning package for Windows. When he recently recommended it to a friend recently, he found that it had grown by an order of magnitude from about a 40 Megabyte download to a 400 Megabyte download. And just what has changed so dramatically in the world of CD burning in that time period?

Ivan’s solution to this epidemic of growth is something near and dear to my own heart: plugins. He posed the question, why aren’t we building decomposable software that can be extended via plugins or extensions? Using the CD burning example again, if there is some crazy huge feature that 5% of the population will use, why not decompose it so that those users can download it as a plugin[2]_? As Ivan put it, “plugins are the new #ifdef.”

[1]His last name has a diacritical mark on the final letter, but I can’t figure out how to do that on my MacBook.
[2]I’m definitely guilty of the “disk space is cheap” argument, and it is; part of Ivan’s point was with respect to memory usage in general, not just disk space.
date:2007-02-23 12:03:41

Heading to PyCon

I’ve spent the first part of this week in San Francisco for some face time with the rest of the Creative Commons staff and participating in what I believe are our first all-staff meetings [1]. This afternoon I’m flying to Dallas for PyCon 2007. The program looks really strong this year, and I’m looking forward to a few days of what you could almost call a vacation. A really, really geeky vacation.

My goal is to blog the sessions I attend, but that’s been my goal every year and I usually end up doing about 25%. We’ll see just how well it works this time around.

[1]“All-staff” including San Francisco, Berlin, South Africa, Boston, and (of course) Fort Wayne.
date:2007-02-22 14:11:54
category:conf, geek, pycon2007

PyCon 2007 Early Bird Registration Closing Soon

So I’m registered and have my plane ticket for PyCon 2007, taking place once again in the lovely Addison, Texas. Early bird registration ends in 12 days, so save US$65 and register now.

I’m actually really excited about this years conference: the slate of talks looks really good, and for the first time I’m not speaking. Why is this a good thing? Because in the past last minute preparations and general public-speaking-nervousness have made it difficult to really enjoy things. So taking a break seems… welcome.

See you in Texas.

date:2007-01-03 17:41:00