My experience of OSCON is very different from Eric's. Eric wrote that it's a good forum to get exposed to unfamiliar topics. For me it's a time to renew contacts. I spent a lot of time in the hallway talking to People like Tim Bunce (who wrote and maintains the perl DBI module) and Michael Schwern (Perl testing expert). On Monday I gave a tutorial on Higher-Order Perl techniques, which seemed to be well-received, but I've seen a couple of blog posts from people who were disappointed that when they went to the Higher-Order Perl class given by the author of the Higher-Order Perl book, all they got was stuff from the Higher-Order Perl book. Tutorial attendees surprise me every year. On Tuesday, I went to see Tim Bunce's "advanced Perl DBI" class. Some takeaway tidbits: @fields = $sth->fetchrow is slow $record = $sth->fetchrow_hashref is faster $record = $sth->fetchrow_arrayref is faaster still but $sth->bind_columns(\($a, $b, $c, ...)); $sth->fetch is fastest of all, because the data is fetched directly into the bound variables, with no copying. Tuesday afternoon I took off with Lorrie and Iris and went to a German food store. The potato salad was excellent. We returned in time for me to catch Larry Wall's "State of the Onion" talk, which was thoughtful and metaphoric as usual. I skipped out of the Tuesday evening keynotes early because Conway was coming up and although he's fun and entertaining he never says anything important, and I wanted to get to bed early. Wednesday ********* The conference started for real on Wednesday. I went to Theo Schlossnagle's talk about "Big bad Postgresql," hoping to learn something about PostGres that might be usefu lto us since we've had ongoing difficulties with MySQL. Theo's business depends on storing his clients' data in a multi-terabyte Postgres database. A lot of what he talked about was using triggers and stored procedures to enforce business rules in the database. He also mentioned that after twenty critical system failures in four months, his company dumped Linux and turned all the servers into Solaris 10 servers, which are much more reliable. Then I went to Peter Scott's talk "Mind Like Water: the path to Perl Bliss". Scott interviewed a bunch of Perl experts on development techniques and was going to talk about the commonaliities; I was one of the experts, so I had to go to the talk to find out what he was going to say about me. Two things I remember from the talk: Peter asks why it took us fifty years to figure out that you should write the tests before the code, instead of after. It's a good question, and I don't think he had an answer. The other thing: all the Perl experts said something akin to "I don't know why people ask so many questions about stuff that they could just try it out themselves with less trouble." Yeah. Tim Bray (he invented XML, maybe you've heard of it) gave a talk on the Atom publishing protocol. This is a protocol for people with web browser software to publish stuff to a web site. I really like it. In a world of overcomplicated, overfeaturized protocols, this one makes me happy. Basically, the browser issues a POST request to the server, saying what material it has that it wants to publish, and delivering the bits; the server then returns a response that gives URLs at which the browser can view the published item, edit it, or supply metadata. This can be used for all sorts of things. For example, it could be used to post articles or comments to a blog, or to deliver pictures to a picture-sharing web site. The requests and responses are all Atom-format XML files, so there is plenty of space for hooks for future expansion. In contrast to existing publishing protocols the APP is very simple. DAV, for example, requires that the client understand and navigate the server's namespace. This is rather silly, since the server is going to make its own policy decision about where to store your post and where to install it in the namespace, so why make the client go through a lot of rigamarole to come up with a location that the server is probably going to disregard anyway? On the other hand, I've seen some complaints on blogs that dealing with XML is too much work and that Bray doesn't understand which parts of the problem are the parts programmers will actually find difficult. The last talk on Wednesday was about Plagger, which is a pluggable RSS aggregator. The author, Tatsuhiko Miyagawa, had written half a dozen applications for converting X to RSS or RSS to Y for various values of X and Y. (One example is that you might like some RSS feed to show up in your gmail mailbox as individual messages; another is that you might like bloglines.com announcements to appear on your IPOD. He then gave many examples of similar sorts of applications that other people had written.) Finally he got fed up and wrote Plagger. It has a fairly simple model: one perl module generates a bunch of entries. Another perl module filters them. A third perl module does something with them. There are about thirty choices for each phase, with more coming along as people write them. You write a little configuration file, telling plagger which modules to use, and bang, you have an RSS or Atom aggregator application. For example, here's what you would have to write to get a thing that watches bloglines.com and sends its announcements to your gmail account: plugins: - module: Subscription::Bloglines config: username: you@example.com password: foobar mark_read: 1 - module: Publish::Gmail config: mailto: example@gmail.com mailfrom: miyagawa@example.com mailroute: via: smtp host: smtp.example.com And that's all. The real work is done in Subscription::Bloglines and Publish::Gmail, but those are already written. Late Wednesday afternoon was taken up with the Perl Lightning Talks (16 talks in 90 minutes) and then I went to the author signing event (being an author) and signed books. Then I held a BOF session. At night was the annual party held for members of the Perl development mailing list and anyone else who shows up. I went with Iris, so had limited opportunities to talk to anyone else. On Thursday I attended Richard Hipp's session on "How Databases Work," which was disappointing; he didn't say anything I didn't already know. After the break I went to Guido van Rossum's talk on Python 3000. Never go to Guido's talks; he is a master of saying nothing in forty-five minutes. Summary: Python 3000 is a fancy name for the Python 3.0 series. Python 3.0 will not be significantly different from Python 2.x. Guido dislikes minor version numbers greater than 9, so he is incrementing the major version number instead. There will be some trivial language changes. Many but not all Python programs will run unchanged in the new version. (He ridiculed the Perl 6 project for abandoning compatibility, while making essentially the same compatibility promises that the Perl 6 project has.) As usual, he spoke at length about the proposals that he had rejected. After lunch, I gave my own talk ("Perl Program Repair Shop and Red Flags") which was generally well-received. I then went to "Live Perl Testing" with Michael Schwern and Josh Heuman. They took the oldest, rottenest Perl code they could find, from the infamous "Matt's Script Archive", and refitted it for testing, answering audience questions as they went. Matt's Script Archive is a model of decency compared with some of the junkpiles we have to maintain here, but I took away a number of useful ideas anyway. When you are trying to change a very old, crappy program, you have a vicious circle: you don't want to change the code with out tests, but the nonmodular structure of the program makes it difficult to produce tests at all. Schwern suggested that to take the first step to breaking the vicious circle, you can just capture the complete output of the program, and write a test that runs the program and checks to see if the output is identical. There are, of course, complications: what if the output contains the time of day? What if the output is forced to the terminal? Schwern suggested some testing tools that could be used to work around this: one replaces the Perl built-in time() function with one that is under control of the tests; another siezes control of the terminal. I bagged the Powell's technical bookstore open house that evening to go to a barbecue with some folks from a company called Socialtext that makes enterprise wiki software. There I met Marvin Humphrey, the author of Kinosearch, which is a searching utility that is making a big splash lately. Kinosearch is a database engine that is designed to be good for one thing only, and that one thing is text search. You put documents into it, and it compiles an index, and then it can be queried for search terms. It's essentially a port of Apache "lucene" to Perl, but it's still very fast, and much faster than similar engines written in Perl. Maybe we could use it for something. On Friday morning I was going to go to David Wheeler's talk on how to embed an object-oriented database into a relational database, but I ended up loitering in the hallway with Nat Torkington (conference program chair for the conference). I caught the tail end of a talk about "Perl Hacks You Never Knew Existed". Unfortunately, all the hacks I saw I either already knew existed or else were too hacky to actually use. For example, one of the hacks was to use the B::Deparse module inside your Perl code to transform the compiled Perl bytecode back into source code, edit the source code on the fly, then recompile it and install the modified version back into the program. Yeah, that's a great idea. The speaker was really pleased that he could modify the syntax of a Perl program on the fly "without using a source filter!" It reminds me of those late-night TV adds about "see without glasses", and instead of "glasses", you have to wear their patented gizmo over your eyes. I usually try to skip the keynote addresses, but I went to Eben Moglen's. Eben Moglen is a professor of Law at Columbia University, and a legal advisor to the Free Software Foundation. His speech was tremendous; he is a brilliant speaker. Here is a summary I found on someone's blog: > Do licenses still matter? Quite a lot. This is the summer that Gates > retired and Stallman didn't. The idea of sharing has triumphed. The > future of information technology is software created by a community. > > Is this the moment for the desktop to arrive? It doesn't matter, as > the desktop is only one place where humans use computers and the > future will fit within a few cubic cm in a human's pocket. Moglen said that the most important commercial and industrial battle of the next fifteen years is being fought over the space in the pocket. It is not enough, he said, for the device in the pocket to play music; it must play videos. It is not enough for it to play music and videos; it must also be a telephone. It is not enough for it to be a telephone that plays music and videos; it must also be a personal organizer. It is not enough for the software to be a personal organizer and telephone that plays music and videos; it needs to do anything, run on any hardware, and "just work" every time, and it must cost zero dollars and zero cents per unit. Then he said that we (the people in the room) were the only ones who could deliver the software that would be required to win the battle for the pocket, the most important commercial and industrial battle of the next fifteen years. > > Sharing is something that everyone needs. The collection of rules > known as IP (Intellectual Property) follows a belief that not-sharing > is the only way to innovate, ignoring the reasons behind patent and > content laws which were laid down in the US constitution. > > Current immigration policy restricts innovation. Current politics > implies that creativity requires exclusive ownership. Licenses replace > the formal laws in the books which don't address the hope for the 21st > century. Licenses are the only documents which currently reflect what > is happening in software. > > The critical question is "do users have rights?" including the rights > to creativity. His clients are afraid that patents are going to > destroy their work. The 20 year exclusive ownership of an idea is an > abomination. Speak loudly with licenses. We have to protect the right > to share. > > Don't disengage from licensing issues. If you don't own the keys to > the technology, who does, and what will they do with them? We will > win, but it's not over yet and there is much more work to do. Moglen said that although today a house is a piece of real estate containing some appliances, in fifteen years it will be a combination of machines and software for living, with real estate attached. Who will hold the keys to your house in fifteen years? Will it be the video rental store and the pizza delivery man? Or will it be you? Eben Moglen got a standing ovation. I stood up too. It was a great speech. Afterward, the geeks filed out of the auditorium and lined up for free cheese. I went off to lunch with Audrey Tang (leader of the Perl 6 parser implementation project) and Jesse Vincent (makes RT, a major bug-tracking system) and some other people. Then I came home. Talk I missed but wished afterwards I had seen: http://conferences.oreillynet.com/cs/os2006/view/e_sess/8694 . Final trivium: People from SixApart gave at least three different talks that all had "sucks" in the title. Anil Dash had "Trying to Suck Less: Making Web 2.0 Mean Something". Miyagawa had "Plagger: RSS/Atom Aggregator that sucks less". Ben Trott (their king) had "A relational object driver that doesn't suck". It worries me. It's like a used car dealer called Honest Joe.