From Ivan Krstic’s keynote on the One Laptop Per Child project:

• Python is the language of the One Laptop Per Child (OLPC). Everything that can, will be done in Python… and there’s a “view source” button on the keyboard (view layout) so you can view (and edit) the source of your current running application.
• The filesystem (which supports versioning) is called Yellow, and will be released withing a week or so. The GUI is called Sugar, and is available on http://dev.laptop.org/ to play with. You can download the full image (or build the environment on Linux.)
• The OLPC supports 802.11s mesh networking.
• The hand crank was removed for case durability. The OLPC’s are designed to last five years, but the torque from the hand-crank would have stressed the plastic case too much for it to last that long.
• The first OLPC’s will start shipping in August of this year!
• The OLPC hardware was getting ~1100 pystones before optimization. They are now up to ~2300 pystones (on a 366 Mhz AMD Geode processor.) (Note: This means they have better Python performance then Python for S60 is seeing on current S60 phones.)

From the Web Frameworks panel:

• James Tauber, “Reinventing the wheel is great if your goal is to learn more about the wheel.”
• Jonathan Ellis, “When you control the whole stack you can innovate faster.”

From Adele Goldberg’s keynote:

Public school education is so bad that real eLearning solutions can’t go to the schools — they need to be outside of schools so that you don’t have the traditional censorship that comes with public schools — and you don’t have the associates with the bad experiences kids have while at “school”.

From Jacob Kaplan-Moss’talk, “Becoming an open-source developer: Lessons from the Django project”:

1. Use good tools. “Open source is better because it’s better.”
2. Avoid dogma. Don’t get stuck on what language something is implemented in.
3. Work with (and hire) smart people. The model in open source is that if you’re smart, people listen to you. That’s rough if you’re not smart… But also means that it’s worthwhile to mention when you’re an expert on a topic.
4. “Methodologies” suck. Ex., MVC is cool, but Django abuses it because it doesn’t fit so well with the web.
5. DRY — Don’t Repeat Yourself. The one methodology to use.
6. The business case for open source. You have to make one (to your company.)
   • Money. You’ll get recognized and sell services because of it. (Ex., Ellignton wouldn’t be as successful without Django.)
   • Free labor. (Sad to think of this way, but true when you have an interesting project.)
   • Self-improvement. Knowing that peers will review your code makes you much more careful about the code you submit. This makes the code a lot better.
   • Geek cred — gaining credibility within the geek community makes it easier to hire great people.
   • Moral Argument — If you built a business on open source — it’s time to give something back.
   • Figure out where to draw the line — Django gave away the tools, but not all the apps.
7. Selling open source to other companies. Microsoft’s FUD had been quite successful in some areas. Counter the “communist” argument with a “freedom” argument. Focus on the freedom of data — your data belongs to you; there is no vendor lock-in. Open vs. Lock-in is a better argument then Open vs. Closed.
8. Create a community. This doesn’t just happen because you setup a mailing list. (Gave example of thanking people who post anti-Django blog posts and asking what they didn’t like.) Don’t say anything that would get you kicked out of a bar.
   • Avoid monsters (trolls, vampires, etc.) Detect them early, and ignore them.
   • Spam can’t be an afterthought. Collaborative tools require spam filtering from Day 1. You’ll get spam. Lots of it. Google Groups is pretty good about cutting out spam.
9. listen to the community. But smartly. Sometimes the vocal majority doesn’t represent the wishes of the whole community. Django’s magic-removal was a big risk, driven by the community. You also have to be willing to ask for help. Sometimes you don’t feel comfortable delegating tasks that you think suck — but not everyone has the same definition of “what sucks” — sometimes there’s someone who actually WANTS to do this task!
10. Handling community contributions. You need a defined method for how you take contributions. It helped the Django project when they adopted a system for differentiating between patches that are controversial, and those that aren’t. (ie., simple bug fixes vs. design decisions.) A ticket reviewer makes this decision.
11. Learn to be comfortable saying ‘no’— there are plenty of Python web frameworks, and maybe someone’s needs are better handled by another framework. “If everyone can check in features, you have PHP.”

From “The absolute minimum an open source developer must know about intellectual property”:

• It’s a lawyer’s job to figure out what will go wrong with your plan. They are professional pessimists.
• Only the “claims” in a patent are covered, not the stuff in the “specification.”
• A header file is a “purely functional” expression, thus NOT-copyrightable.
• If you don’t protect your Trademark, you lose it. This is why companies have to send cease and desist. The “get a first life” situation was important because Lindon explicitly granted them a license to use the Second Life trademark in the parody, thus they were able to demonstrate that they were protecting their mark.
• If you tell someone how to do the work (ie., “work for hire”), then you own it.
• An independent contractor owns their work unless the contract specifically assigns the rights to the company.
• The person who made a patch owns the patch. By giving it to you, you get an applied license to use it, but because it’s implied, it’s fuzzy as to what you can do with it.

From Robert M. Lefkowitz’s keynote:

• Only 2% of the population can read source code. (And free software doesn’t matter if no one can read it!)
• Proprietary software values function. Free software people value the building of the “community of learning” around the software, even if it has fewer features.
• The traditional view is that computer literacy is about one’s ability to use applications, rather then to program. If this is right, then what’s the point? Computers might as well be printing presses.
• In literature, you read the greats (ex., Shakespeare), then try to write like them. So in computer literacy, who are the greats? If we were going to make every high school students memorize a program, what would it be?
• Great programmers break the rules elegantly. Bad programmers break the rules without realizing it.

Just a quick reminder for those near Austin this weekend, BarCampTexas starts Friday night!

On a brighter note, in one of those “it’s a small world” moments, I happened to hear that Matt Biddulph (http://www.hackdiary.com) was speaking at the Helsinki Institute for Information Technology, and fortunately I was able to stop by. Matt gave a nice talk about “the Open Data Movement” — the idea that opening free access to data will be just as important in shaping the future internet as the open source software / free information movements have been.

Matt in action (and a little bit of Jukka’s ear, for you hardcore PyS60 stalker types ;-):

While I’m sharing pictures… Here’s a few more images I snapped with my N90 while walking about town:

A quick shot in front of the main train station:

A crowded tube stop:

Ghosts in the street:

What’s that? In Japan, phone has answer

“If you stand on a street corner in Tokyo today, you can point a specialized cellphone at a hotel, a restaurant or a historical monument, and with the press of a button the phone will display information from the Internet describing the object you are looking at.”

The technology is a combination of GPS + compass + internet connectivity. With the GPS chip on-board, the phone knows where it is, and with the compass it can tell which direction you are facing. Using that information, the phone can perform a very accurate location-based search.

It would be interesting to combine this technology with what the ZoneTag folks are doing on location-based image recognition. It’s pretty easy to imagine mobile devices that can tell exactly what you are looking at, translate signs, give directions, and pull in community feedback to help navigate and explore the world. Anyone who’s experienced the joy of wandering foreign cities can appreciate the value in having your mobile keep an eye out for restaurants and activities nearby that you won’t want to miss!

Hope to see you there!

Hotel rates were much better in the summer. We stayed at the Pan Pacific Mountainside, which is *right* next to the Whistler lifts. It was small room with a Murphy bed and a kitchen, but it was quite nice and it offered secured bike storage.

To get to the mountain we used Perimeter‘s shuttle services, which cost about $50 each way. Besides being much less expensive then a rental car, taking a shuttle van is a good way to meet people and share travel stories. It also lets you enjoy the view instead of fumbling around with some rental car’s traction control buttons.

Once at the mountain, Whister has a few free trails heading to some of the nearby lakes, and of course, the bike park, which you’ll need lift tickets for. Riding DOWN the mountain was what I came for, and it was a blast! We don’t have such hills in central Texas, so it was quite a treat. It also gave for some nice stories, like the time I came around a corner to find a black bear cub about four or five feet away from me. Thankfully I startled him, and he jumped into the trees.

One lesson learned from the trip that I have to mention is that American Airlines charges a hefty fee for shipping bike cases internationally. If it had been a domestic trip I probably could have gotten by, but brining a bike across the Canadian border costs $80 each way! It apparently had nothing to do with the size or weight of the case — the fact that it contained a bike made it cost money. That said, you should certainly evaluate your needs when planning a similar trip. A decent mountain bike could be rented at the mountain for around $30 a day, and a killer downhill bike was around $80 a day.

Since I had never taken a mountain bike up a lift before, I had no idea how it would work. Turns out it’s pretty simple. You could take your bike into the gondola’s, or stick it on one of these racks. (Some of the lift chairs also had hooks attached that could be used to hang a bike from.)

The bike park featured trails, skills areas, and jump parks (this one was near the bottom of the mountain, visible from the village):

This lake was actually near the top of Whistler. We took the gondola up, then hiked a couple kilometers to the lake:

Google’s use of Python is mostly in their build- and server-management tools, but they do have a few web toys (like http://code.google.com/ ) that are built with it. He said that Google uses Python because it’s “highly adaptable,” meaning that software requirements and computing environments can change without drastically hurting the development process.

In describing the time it takes for programmers to learn Python, he said something to the effect of, “[you can] read it in 2 hours, program in 2 days, [and] contribute to the company in 2 weeks.” Fabulous.

For the web projects using Python, the meat of the work is still done in C , which is the most common programming language at Google. However, when the C code is built, the build system automatically uses SWIG to generate Python bindings for prototyping.

After the Google session, Jukka and I got ready for our presentation on Python for Series 60. After talking to people at the conference for a couple days, we decided that we should actually start the presentation by describing what Series 60 actually is. In hind-sight, we probably should have titled the presentation “Python on your phone.” I was a little disappointed that we didn’t have enough time to cover everything we wanted, but fortunately we had a lot of really good conversations in the hallways after the presentation.

After lunch I headed back to the Lightning Talks, and once again, there were some great projects presented. My personal favorite this time was the demo of rlcompleter2. Amazing!

To wrap up the day I went to Ted Leung’s presentation on PyBlosxom. I’ve been thinking more lately about moving my blog over to PyBlosxom, and thankfully, the session answered a few questions I’d had.

After the session I had to run to the airport, but amazingly enough, I’m actually on a plane (right now), and we’re on schedule. A delay out of D.C. made me almost miss my connection, but I made it right as they were closing the gate. So I’m 1-in-4 now for getting home on time this month… we’ll see how next week goes.

The conference keynotes take place first thing in the morning in a mid-size auditorium. But surprisingly for the tech conference, you can’t bring your coffee (or any drinks) into the room — so it’s an early morning, sleepy crowd. This is also the one room that lacks wi-fi and power outlets, which is good or bad depending on how you look at it.

The keynote this morning was Guido’s “State of Python” address. He briefly talked about the ‘decorator’decision process (mentioning that “Perl isn’t all bad”), then went on to discuss the formation of new Python Security Response Team in reaction to the first official Python vulnerability alert that happened recently (for SimpleXMLRPCServer.)

Guido then moved on to the more controversial topics of Python 3.0 being incompatible with Python 2.x (for example, old-style objects won’t be supported anymore, which is a good thing), the addition of the any() and all() standard methods, the likely removal of map(), filter(), and reduce(), and the potential demise of lambda. He then talked about potential changes to how divide-by-zero can be reported, and the very heated topic of static typing.

After the early sessions, we held an informal Python for Series 60 BoF, where we got some good dialog about networking on Symbian, but not too many people were there to hear it. That’s the nature of holding BoF sessions though, so hopefully we’ll have a larger crowd at the real session tomorrow morning. We were luck enough to get the main auditorium for the presentation (I say ‘we’because Jukka‘s joining me for the more meaty, technical bits), but unfortunately, the sessions are rather quick (20 minutes) and we’ve had to drop a lot of things we were hoping to unveil.

After lunch I went to the Lightning Talks, which I think wins my vote for the most interesting session. The format was a quick, 5-minute soap-box window for presentations about random projects, ideas, and questions. It was long enough to get the gist of what people were up to and jot down some terms to google later, but not so long that as to get boring. It’s hard to pick a favorite, but I really enjoyed Ka-Ping Yee‘s demonstration of his new scrape module.

I’ve once again gathered the URL’s I wrote down during the day, but if you’re just looking for more detail on the sessions, Matt‘s been doing a much better job then I at posting regularly.

Now for the links:
- http://www.elementalsecurity.com/
- http://www.infoworld.com/article/04/09/24/39FErrdev_1.html
- http://unicon.org/
- http://www.cs.luc.edu/~anh/gallery
- http://www.scipy.org/
- http://numeric.scipy.org/PEP.txt
- http://svn.webdav.org/repos/projects/ezt/trunk/
- http://codespeak.net/svn/user/argigo/hack/misc/
- http://codespeak.net/svn/shpy/trunk/dist/
- http://www.ludumdare.com
- http://pygame.org/

The flight in was uneventful, but the descent path to Reagan Airport brought the plane right passed some of the more recognizable memorials. Having a left-side window seat gave a nice view of it all.

Unfortunately, the weather is crap today — slight rain and a tad bit chilly make it exactly what you don’t call walking weather; Fortunately the conference is all indoors. PyCon is taking place at the Cafritz Conference Center at George Washington University. The conference area itself is rather small, but there are only 400 or so people attending, so it works out alright.

The opening sessions of the day started with a quick look at the work the Python Software Foundation (PSF) has been doing to revamp the Python Web Site. The new site (and logo) isn’t live yet, but they will be changing the branding and feel of the site to be a bit more “business friendly.”

The backend system for generating the site is being updated as well. The new site uses YAML and reStructuredText for content storage. The thinking is that this format will make content authoring easier and more accessible.

Next up was Jim Hugunin (Microsoft) from the IronPython project. Jim started the presentation by asking (by a show of hands) how many people in the crowd were developing on Windows, and then, how many were deploying on Windows. It turned out, surprisingly few. I sit in the OS X / Linux camp as well (I guess I deploy on Series 60 too), but I wasn’t expecting that from this crowd.

Even though I don’t use Windows, Jim’s demos were quite compelling. With access to the .NET framework, he was able to interact with native applications and libraries from an interactive Python session. And according to pystone, Python actually runs faster on the CLI then it does through CPython! The performance gains apparently come from the CLI’s JIT compiler, which converts the IL bytecode to native x86 instructions.

One question from the crowd left Jim without an answer though. The issue was whether Microsoft will be patenting parts of IronPython that could eventually come to harm the Python community. The concern is that innovations coming to Python from Microsoft might be restricted to the platform (which obviously isn’t good.) Jim couldn’t comment on the issue; However, the IronPython work is at least being released under a BSD-like license.

After lunch I hit the Mac scripting sessions. The first covered appscript; the second and third were on PyObjC. I’ve looked at appscript before and found it a bit convoluted, so the first presentation was helpful in explaining “why” doing AppleEvents from Python seems so awkward. Apparently much of it is due to how the OSA environment works.

After appscript, Bob Ippolito gave an “Introduction to PyObjC” and “PyObjC Hacking” session. Both were interesting, but the latter was most inspiring. Bob gave a demo of doing PyObjC code injection into running processes. He focused on the Preview.app application, first inserting a class browser to explore private methods, and secondly to insert an actual Python console into the running application to open it up for exploration. The implications of this are pretty severe. It fundamentally explained a procedure for hijacking a running application and modifying it’s environment at runtime. The most abusive application I can think of would be to hijack an application like iTunes that does DRM encoding, and re-write the DRM methods in real-time to bypass the content signing mechanisms. Wickedly cool. Bob’s presentations can be found here.

After the lunch break I heard Michelle Levesque’s session on PyWebOff — a project to document Python web application frameworks in a hope to identify the best and encourage the Python community to focus on improving and adopting a small set of web frameworks. The motivation for the project comes from two sides; first being the actual problem Python has doing web development (it’s a little cumbersome), and second, the press attention the Ruby on Rails project has gotten.

After Michelle I heard Ian Bicking’s presentation about WSGI Middleware and WSGIKit, then Donavan Preston’s presentation on “Responsive GUI Web Applications” using Nevow. Donavan’s presentation focused on the LivePage functionality of Nevow that implements an XmlHttpRequest framework for Python. While the capabilities for this aren’t new, the success of GMail and Google Maps has brought it some new attention lately.

Since it’s actually pretty late here I’ll call it quits for now, but I’ll end with a listing of links I jotted down today:

- http://workspaces.gotdotnet.com/ironpython/
- http://toys.jacobian.org/presentations/2005/appscript/
- http://www.crummy.com/software/BeautifulSoup/
- http://developer.apple.com/
- http://pyobjc.sourceforge.net/
- http://bob.pythonmac.org/
- http://pythonmac.org/wiki/
- http://cocoadev.com/
- http://pyre.third-bit.com/pyweb/
- http://ianbicking.org/docs/pycon2005/
- http://nevow.com/

A stewardesses on the flight was complaining about the situation to some of the passengers. She’d been with the airline for almost 15 years and thought that they were really going down-hill. She claimed the reason it would take a while for them to resolve the mechanical issue is that they didn’t have enough ground staff. According to her, the budget-airlines were undercutting American so much that American couldn’t afford to operate. The ground staff that hadn’t been laid off were being employed under multi-year, minimum-wage contracts with no benefits. “Is this really how we want to treat people?” she asked. Sure, airline ticket prices are a bit lower, but at what cost?

Given my recent track record, I’m now expecting a long-haul heading home from PyCon.