Friday, May 26, 2006
Rick Santorum Veterans Chair
Kevin Dellicker is going to be the veterans chair for Rick Santorum's re-election campaign.
Thursday, May 25, 2006
Contributing to Python
I did not get involved in Python development until I'd been at CNRI for a couple of years. If I look at the Python history file and CVS/SVN logs, I did make a single checkin until 1997. My first projects were the resource module and improvements to the zlib/gzip interface.
The resource module exposes the Unix getrusage/setrusage system calls. I created it when we were working on the Knowbot system, because we wanted to be able to limit the resource consumption of hosted programs (Knowbots). I don't recall that we ever made much progress on the resource consumption problem, though. Anyway, this was my first contribution to Python, but I see that I gave it to Guido and he checked it in for me after some editing. I was a fairly novice C programmer at the time.
The other project I worked on at that time was improvements to the zlib interface. These represent my first actual checkins--in the summer and fall of 1997. I can't recall how much of the working was original. Andrew Kuchling had done a lot of work in this area and wrote the original gzip module. Since no one outside CNRI had CVS access, I was checking in Andrew's code. But I think I made some original contributions here, too.
I'll see if I can think of more stories from early development projects. For now, I'll just summarize the raw data from the CVS/SVN log. I have made 931 checkins to the Python project. By year, the breakdown is
The resource module exposes the Unix getrusage/setrusage system calls. I created it when we were working on the Knowbot system, because we wanted to be able to limit the resource consumption of hosted programs (Knowbots). I don't recall that we ever made much progress on the resource consumption problem, though. Anyway, this was my first contribution to Python, but I see that I gave it to Guido and he checked it in for me after some editing. I was a fairly novice C programmer at the time.
The other project I worked on at that time was improvements to the zlib interface. These represent my first actual checkins--in the summer and fall of 1997. I can't recall how much of the working was original. Andrew Kuchling had done a lot of work in this area and wrote the original gzip module. Since no one outside CNRI had CVS access, I was checking in Andrew's code. But I think I made some original contributions here, too.
I'll see if I can think of more stories from early development projects. For now, I'll just summarize the raw data from the CVS/SVN log. I have made 931 checkins to the Python project. By year, the breakdown is
- 1997, 10 checkins
- 1998, 15 checkins
- 1999, 11 checkins
- 2000, 212 checkins
- 2001, 376 checkins
- 2002, 157 checkins
- 2003, 117 checkins
- 2004, 18 checkins
- 2005, 8 checkins
- 2006, 18 checkins
Wednesday, May 24, 2006
My First Python Projects
I joined CNRI in February 1996. I worked with a great group of people: Fred Drake, Ken Manheimer, Roger Masse, Guido van Rossum, and Barry Warsaw. Our first manager was Ted Strollo. I think Fred started just a few weeks before I did, but he knew a lot more about Python and didn't seem like he was new.
The team was working on Grail, a web browser written in Python with Tkinter, and on Knowbots, which allowed you to write Python programs that could ship themselves around to different servers. We spent more time on Grail at first, but I think Guido had written an initial demo to support mobile Python programs before I joined.
One of my first programming tasks was the client-side HTTP cache for Grail. I don't recall what I else I did for Grail. Many years later, I wrote urllib2 to have a more flexible tool for writing HTTP client programs, probably based on some of my early HTTP experiences with Grail. I recall one funny story about the cache: We were having problems with the cache because reading the cache on startup was too expensive. It stored one page to a file and kept a log with all the metadata updates. I had simple code that read and parsed one line at a time to generate a list of tuples with the metadata. I think I tried five or six different ways to make it faster but it was still too slow. I finally struck upon using pickles instead of parsing the data by hand and then I tried cPickle. It was 8,000 times faster than the original log parsing code!
Grail was a really fun project, but surely sounds odd ten years later. Why would anyone want to write a browser in Python? At the time, web browsers weren't mature software and it was useful to have a relatively complete browser for which you had the full source in a high-level language. We did support applets written in Python. I wrote a quicksort visualization applet. Looking at the docstring, it says it was my second real Python program.
Another Python memories post.
The team was working on Grail, a web browser written in Python with Tkinter, and on Knowbots, which allowed you to write Python programs that could ship themselves around to different servers. We spent more time on Grail at first, but I think Guido had written an initial demo to support mobile Python programs before I joined.
One of my first programming tasks was the client-side HTTP cache for Grail. I don't recall what I else I did for Grail. Many years later, I wrote urllib2 to have a more flexible tool for writing HTTP client programs, probably based on some of my early HTTP experiences with Grail. I recall one funny story about the cache: We were having problems with the cache because reading the cache on startup was too expensive. It stored one page to a file and kept a log with all the metadata updates. I had simple code that read and parsed one line at a time to generate a list of tuples with the metadata. I think I tried five or six different ways to make it faster but it was still too slow. I finally struck upon using pickles instead of parsing the data by hand and then I tried cPickle. It was 8,000 times faster than the original log parsing code!
Grail was a really fun project, but surely sounds odd ten years later. Why would anyone want to write a browser in Python? At the time, web browsers weren't mature software and it was useful to have a relatively complete browser for which you had the full source in a high-level language. We did support applets written in Python. I wrote a quicksort visualization applet. Looking at the docstring, it says it was my second real Python program.
Another Python memories post.
How I Learned Python
Guido is working on a paper for the HOPL III conference. He recently asked old timers to post their memories. I thought I'd start at the beginning.
I learned Python on a plane ride from Boston to Baltimore in the fall of 1995. I was interviewing for a job at CNRI. I expected to talk mostly about digital libraries, because my thesis was in that area and I thought I was interviewing with people in the digital libraries group. But I also knew that I was going to meet Guido, and I thought I better know something about Python. I printed out the tutorial and brought it with me on the plane.
I didn't know anything about Python at the time. I knew Perl relatively well, had used Tcl a couple of times, and had heard of Python. I recall one corridor conversation, with John Mallery I think, where he gave me a hard time about using scripting languages like Perl. I said something along the lines of "Well what about Python" and he granted that it was a more reasonable choice.
I got a first-class ticket for the flight. I think we scheduled the interview at the last minute and they were the only tickets available. It was a comfortable, short ride. I spent most of it reading the Python tutorial. I recall thinking that the language was really simple--that you could get the gist of it from the tutorial without writing a line of code. And sample was good! I had struggled a lot with Perl, because I felt like I had never mastered it and I had to look everything up in the Camel book. I could never settle on the right way to solve a particular problem, because there were so many options.
The interview itself must have gone well, although I don't recall many of the details. The only concrete memories I have are talking with Bob Kahn and Ken Manheimer. I don't have any recollection of talking with Guido at the interview, although I'm sure I did.
I learned Python on a plane ride from Boston to Baltimore in the fall of 1995. I was interviewing for a job at CNRI. I expected to talk mostly about digital libraries, because my thesis was in that area and I thought I was interviewing with people in the digital libraries group. But I also knew that I was going to meet Guido, and I thought I better know something about Python. I printed out the tutorial and brought it with me on the plane.
I didn't know anything about Python at the time. I knew Perl relatively well, had used Tcl a couple of times, and had heard of Python. I recall one corridor conversation, with John Mallery I think, where he gave me a hard time about using scripting languages like Perl. I said something along the lines of "Well what about Python" and he granted that it was a more reasonable choice.
I got a first-class ticket for the flight. I think we scheduled the interview at the last minute and they were the only tickets available. It was a comfortable, short ride. I spent most of it reading the Python tutorial. I recall thinking that the language was really simple--that you could get the gist of it from the tutorial without writing a line of code. And sample was good! I had struggled a lot with Perl, because I felt like I had never mastered it and I had to look everything up in the Camel book. I could never settle on the right way to solve a particular problem, because there were so many options.
The interview itself must have gone well, although I don't recall many of the details. The only concrete memories I have are talking with Bob Kahn and Ken Manheimer. I don't have any recollection of talking with Guido at the interview, although I'm sure I did.
Tuesday, May 16, 2006
Pennsylvania Primary Judgement
I worked at a polling station in Pennsylvania today. I was the Judge of Elections at a polling station in Forks Township, Northampton County. It was the first time I was an election worker. It was a long day, but I enjoyed it and was interested to observe the voting process in more detail. My co-workers--Arlene, Dale, Liz, and Ray--were all friendly and hard-working. It's nice to get to know you neighbors better.
The turnout out our polling station was low. We had 141 voters come to the polls and counted nine absentee ballots. There are 1,627 registered voters, so turnout was almost nine percent. A second polling station in the same building had an even lower turnout.
The voting went pretty smoothly, I think. We voted with electronic voting machines for the first time in Northampton County. We used two WINvote machines from Advanced Voting Solutions.
I think it went well, particularly considering that people had never used these machines before.
Most of the voters liked the new machines, and some people were very enthusiastic. They said they loved it or that it was easy or that it was much easier than the lever machines. A handful of people, no more than five, had a strong dislike of the machines. One of the people who disliked them said that they did not show who was an incumbent. I'm not sure that the old machines showed that for a primary or not, so I don't know if that's a valid criticism. Several people--maybe a dozen--were concerned about the security of the machines. Many of them asked why they couldn't have a paper receipt like an ATM machine.
Two voters needed their spouses to help them vote. There's an official form to fill out to request assistance and we turn those all in at the end of the day. One of the women was born in Italy and couldn't read English very well. She was one of the many interesting people I met.
We did have trouble with the machines themselves. One of them hung four times and another crashed while loading a ballot. We had to reboot the machines each time. The machines are operated with smart cards. There is one card for the location that is used to start and stop the machine. There are two ballot cards that are used to load and cancel ballots. One machine hung because its card reader stopped responding to the cards. Reboots took a couple of minutes and fixed the problem. The other machine crashed in the middle of loading a ballot. It showed a memory read error with a standards Windows error dialog box--only with an Ok button. I hit okay a couple of times and the machine hung again.
The problem with the machine crashes was their frequency. Five crashes for 141 votes cast is a pretty sorry rate. Imagine that this had been a contested general election. If we had 1000 voters and one crash every 28 votes, I would have done about 35 reboots.
It also took a long time to load a ballot. If a Democratic voter cast a ballot on the machine and the next voter was a Republican it took maybe a minute to switch to the new ballot. A sales rep who stopped by said that there were several hundred possible ballot configurations that it had to search through. I didn't really understand that explanation. There were only two ballot configurations. Why couldn't they both be cached?
It took about an hour and 35 minutes to close the polls. It took a long time to print out tallies and shutdown machines, and there were four paper result sheets to fill out. There were five different envelopes to return, plus a cellphone and all the materials and pamphlets.
Most of the voters were older, almost all more over 60, many were in their 70s and 80s.
Very few voters were under 35. I think about three were in their 20s.
The electronic voting machines are fairly small and the enclosure is small. We set them on two tables. They offered much less privacy than the old voting machines with the curtains, which was a little awkward at times. It did make it easy for people to ask questions about how to vote. They asked a lot of questions and we could explain it to them or show them using the printed out example ballots. A lot of people got stuck on the review page that showed the votes cast on previous screens.
A few people, mostly older people, spent a long time voting--more than five minutes. Our instructions said to stop people after three minutes unless there was no one waiting, but it didn't explain how to "stop them." We did not stop them, but we never had more than four people waiting. If we stopped them, would we invalidate their ballot? We couldn't force them to cast the ballot without pressing buttons for them, which we're not allowed to do.
I wonder how much testing do these voting machines really get? They are used twice a year. For our primary, no machine executed more than 75 transactions. For a busy general election, we'd probably have 300 transactions per machine. If a machine executes a few hundred transactions per year, how much opportunity do you have to exercise corner cases and have confidence that the bugs are worked out. I wonder if they gathered enough diagnostic data when the machine did get rebooted.
It would be helpful to have a better way for people to learn how to use the machines. For the old lever machines, they had a toy voting machine that you could try out while you were waiting. I remember playing with it when I was a kid. When I voted for the first time, I knew exactly what to expect. We didn't have a PC where voters could try it out and the paper printouts didn't capture the experience at all. I think a video showing all the options would make the most sense. You could put a TV and a video player in each polling station.
The process for election works produces a lot of redundant paper records, which seems like a good thing. You have three lists of the voters who voted--an official list of voters (plus carbon copy), log books with the voters signatures, and throw-away forms where the voters print their names. All three records are numbered, so it's easy to track down record keeping errors. There's some redundancy in the computer records, but only as multiple copies of the final tally. At the end of the day, we print out a summary of the votes and export the data onto two USB memory sticks. I believe there is also a copy on the local hard disk. I don't understand if there is any easily audited record of individual votes, because we only see the totals at the end of the day.
The turnout out our polling station was low. We had 141 voters come to the polls and counted nine absentee ballots. There are 1,627 registered voters, so turnout was almost nine percent. A second polling station in the same building had an even lower turnout.
The voting went pretty smoothly, I think. We voted with electronic voting machines for the first time in Northampton County. We used two WINvote machines from Advanced Voting Solutions.
I think it went well, particularly considering that people had never used these machines before.
Most of the voters liked the new machines, and some people were very enthusiastic. They said they loved it or that it was easy or that it was much easier than the lever machines. A handful of people, no more than five, had a strong dislike of the machines. One of the people who disliked them said that they did not show who was an incumbent. I'm not sure that the old machines showed that for a primary or not, so I don't know if that's a valid criticism. Several people--maybe a dozen--were concerned about the security of the machines. Many of them asked why they couldn't have a paper receipt like an ATM machine.
Two voters needed their spouses to help them vote. There's an official form to fill out to request assistance and we turn those all in at the end of the day. One of the women was born in Italy and couldn't read English very well. She was one of the many interesting people I met.
We did have trouble with the machines themselves. One of them hung four times and another crashed while loading a ballot. We had to reboot the machines each time. The machines are operated with smart cards. There is one card for the location that is used to start and stop the machine. There are two ballot cards that are used to load and cancel ballots. One machine hung because its card reader stopped responding to the cards. Reboots took a couple of minutes and fixed the problem. The other machine crashed in the middle of loading a ballot. It showed a memory read error with a standards Windows error dialog box--only with an Ok button. I hit okay a couple of times and the machine hung again.
The problem with the machine crashes was their frequency. Five crashes for 141 votes cast is a pretty sorry rate. Imagine that this had been a contested general election. If we had 1000 voters and one crash every 28 votes, I would have done about 35 reboots.
It also took a long time to load a ballot. If a Democratic voter cast a ballot on the machine and the next voter was a Republican it took maybe a minute to switch to the new ballot. A sales rep who stopped by said that there were several hundred possible ballot configurations that it had to search through. I didn't really understand that explanation. There were only two ballot configurations. Why couldn't they both be cached?
It took about an hour and 35 minutes to close the polls. It took a long time to print out tallies and shutdown machines, and there were four paper result sheets to fill out. There were five different envelopes to return, plus a cellphone and all the materials and pamphlets.
Most of the voters were older, almost all more over 60, many were in their 70s and 80s.
Very few voters were under 35. I think about three were in their 20s.
The electronic voting machines are fairly small and the enclosure is small. We set them on two tables. They offered much less privacy than the old voting machines with the curtains, which was a little awkward at times. It did make it easy for people to ask questions about how to vote. They asked a lot of questions and we could explain it to them or show them using the printed out example ballots. A lot of people got stuck on the review page that showed the votes cast on previous screens.
A few people, mostly older people, spent a long time voting--more than five minutes. Our instructions said to stop people after three minutes unless there was no one waiting, but it didn't explain how to "stop them." We did not stop them, but we never had more than four people waiting. If we stopped them, would we invalidate their ballot? We couldn't force them to cast the ballot without pressing buttons for them, which we're not allowed to do.
I wonder how much testing do these voting machines really get? They are used twice a year. For our primary, no machine executed more than 75 transactions. For a busy general election, we'd probably have 300 transactions per machine. If a machine executes a few hundred transactions per year, how much opportunity do you have to exercise corner cases and have confidence that the bugs are worked out. I wonder if they gathered enough diagnostic data when the machine did get rebooted.
It would be helpful to have a better way for people to learn how to use the machines. For the old lever machines, they had a toy voting machine that you could try out while you were waiting. I remember playing with it when I was a kid. When I voted for the first time, I knew exactly what to expect. We didn't have a PC where voters could try it out and the paper printouts didn't capture the experience at all. I think a video showing all the options would make the most sense. You could put a TV and a video player in each polling station.
The process for election works produces a lot of redundant paper records, which seems like a good thing. You have three lists of the voters who voted--an official list of voters (plus carbon copy), log books with the voters signatures, and throw-away forms where the voters print their names. All three records are numbered, so it's easy to track down record keeping errors. There's some redundancy in the computer records, but only as multiple copies of the final tally. At the end of the day, we print out a summary of the votes and export the data onto two USB memory sticks. I believe there is also a copy on the local hard disk. I don't understand if there is any easily audited record of individual votes, because we only see the totals at the end of the day.
Friday, May 05, 2006
Faith Healer
We saw Faith Healer, starting Ralpha Fiennes, Cherry Jones, and Ian McDiarmid, last week in previews. The playwright, Brian Friel, is one of my favorites and I had read Faith Healer in college, but didn't really remember the play. I thought the performance was on the best we had seen: All the actors, perhaps Jones most notably, were excellent. The play itself is wonderfully written and constructed. It's a showcase for actors, requiring them to hold the audience's attention for a 30-minute monologue.
We don't see many plays, so I was curious to see what the reviews would say today after its official opening last night. Did we overestimate it because we don't get to see many Broadway shows? I guess we didn't.
We don't see many plays, so I was curious to see what the reviews would say today after its official opening last night. Did we overestimate it because we don't get to see many Broadway shows? I guess we didn't.
Clive Barnes, New York Post: Play or not, "Faith Healer" is, to use one of its key words, a "fantastic" theatrical experience, outdistancing the current Broadway pack by a country mile, with three performances to be treasured in memory, and reinforcing Friel's position as one of the three or four finest living English-speaking playwrights.
Ben Brantley, New York Times: Playing the title role in Brian Friel's great play "Faith Healer," which opened last night in a mesmerizing revival at the Booth Theater, Ralph Fiennes paints a portrait of the artist as dreamer and destroyer that feels both as old as folklore and so fresh that it might be painted in wet blood.
Subscribe to:
Posts (Atom)
Posts
