How we brought the latest version of Python to App Engine and Cloud Functions

At Cloud Next 2018, we added Python 3.7 support to Cloud Functions and now we’ve announced Python 3.7 support for the App Engine standard environment. These new runtimes allow you to write Python functions and apps using the latest version of Python and the rich ecosystem of packages available on Python Packaging Index (PyPI).

This new runtime marks a significant update to App Engine and was enabled by new open source software that we recently released: gVisor and FTL.

Python, straight from the source

Running Python 3.7 on App Engine and Cloud Functions required us to fundamentally rethink our infrastructure. Traditionally, meeting Google Cloud’s security requirements meant that we had to run a modified version of the Python interpreter. However, using a modified interpreter constrained some language features and only allowed us to support a limited set of whitelisted Python libraries.

Thanks to gVisor, a container sandbox that provides improved security and process isolation, we can now run the unmodified Python 3.7.0 interpreter. We’ve done extensive testing to make sure Python 3.7 is compatible with gVisor. As part of our compatibility testing, we run Python’s full suite of language tests, and tests for Python packages that are popular on PyPI. We’re committed to ensuring that everything you’ve come to know and love about Python is supported on our platform.

Seamless deployments

Most importantly, this change in our infrastructure makes it easier to take advantage of Python’s vast ecosystem. As a developer, you just add project dependencies to a requirements.txt file and deploy.

During deployment, FTL, a tool for building containers, fetches dependencies listed in your requirements.txt file and installs them alongside your app or function. FTL also includes a short-lived dependency cache, which speeds up repeated deployments if no changes are detected in your requirements.txt file. This is particularly useful if you find just need to re-deploy because you found a typo.

Keeping up with the Pythonistas

In making these changes, we also decided to expand the list of system packages that are included with each runtime’s Ubuntu 18.04 distribution. We think that will make life just a little bit easier for developers working with the latest release of Python.

Looking forward, we’re excited about how these changes will allow us to keep up with the Python community’s progress as they release new versions and libraries. Please let us know what you think and if you run into any challenges.

You can learn more about how to get started with it on App Engine and Cloud Functions in our documentation. We can’t wait to see what you build with Python 3.7.

By Stewart Reichling, Product Manager

An update on container support on Google Cloud Platform

Cross posted from the Google Cloud Platform Blog

Everything at Google, from Search to Gmail, is packaged and run in a Linux container. Each week we launch more than 2 billion container instances across our global data centers, and the power of containers has enabled both more reliable services and higher, more-efficient scalability. Now we’re taking another step toward making those capabilities available to developers everywhere.

Support for Docker images in Google App Engine
Last month we released improved Docker image support in Compute Engine. Today, we’re building on that work and adding a set of extensions that allow App Engine developers to build and deploy Docker images in Managed VMs. Developers can use these extensions to easily access the large and growing library of Docker images, and the Docker community can easily deploy containers into a completely managed environment with access to services such as Cloud Datastore. If you want to try it, sign up via this form.

Kubernetes—an open source container manager
Based on our experience running Linux containers within Google, we know how important it is to be able to efficiently schedule containers at Internet scale. We use Omega within Google, but many developers have more modest needs. To that end, we’re announcing Kubernetes, a lean yet powerful open-source container manager that deploys containers into a fleet of machines, provides health management and replication capabilities, and makes it easy for containers to connect to one another and the outside world. (For the curious, Kubernetes (koo-ber-nay'-tace) is Greek for “helmsman” of a ship.) Kubernetes was developed from the outset to be an extensible, community-supported project. Take a look at the source and documentation on GitHub and let us know what you think via our mailing list. We’ll continue to build out the feature set, while collaborating with the Docker community to incorporate the best ideas from Kubernetes into Docker.

Container stack improvements
We’ve released an open-source tool called cAdvisor that enables fine-grain statistics on resource usage for containers. It tracks both instantaneous and historical stats for a wide variety of resources, handles nested containers, and supports both LMCTFY and Docker’s libcontainer. It’s written in Go with the hope that we can move some of these tools into libcontainer directly if people find them useful (as we have).

A commitment to open container standards
Finally, I'm happy that I've been nominated to Docker's Governance Committee to continue working with the Docker community toward better open container standards. Containers have been a great building block for Google and by working together we can make them the key building block for “cloud native” applications.

-Posted by Eric Brewer, VP of Infrastructure

Babbage: easily encode or decode data with a click

Engineers at Google deal with encoded data on a daily basis. It’s very common to handle files encoded in a variety of different formats. For example, email attachments are Base64 encoded and web requests are URL encoded. Custom encodings bring another level of complication especially when different codings are chained together. Over time this constant need to encode / decode data left me with a large, unmanageable collection of scripts. This collection was simply not scaling, so I set off to create a better solution. We needed something easy to use and extensible enough to serve our future needs.

Today, I’m happy to introduce Babbage, an open source tool for manipulating data in many different formats. With Babbage you can easily decode or encode data with just a click. Paste in “SGVsbG8h”, select base 64 decode and you get “Hello!”. You can paste in text to process with plugins (which are an easy way to transform data). Babbage comes with a basic set of plugins to cover simple encodings and obfuscation techniques such as Base64, URL encoding, XOR and others. If you have something a bit more complicated, you can chain multiple plugins together. Babbage is open source and written so that anyone can create their own collection of plugins with libraries already in use.

Babbage was written in Python and JavaScript with Google Closure on top of Google App Engine. The full source code is available on GitHub. Develop something cool and share it with the world! We are always looking for new contributions — feel free to contact us on our developers discussion group.

By Tom Fitzgerald, Google Engineering

Find sample code and more for Google Cloud Platform, now on GitHub

Today, we’re announcing that you can now find Google Cloud Platform on GitHub! The GitHub organization for the Google Cloud Platform is your destination for samples and tools relating to App Engine, BigQuery, Compute Engine, Cloud SQL, and Cloud Storage. Most Google Cloud Platform existing open source tools will be migrated to the organization over time. You can quickly get your app running by forking any of our repositories and diving into the code.

Currently, the GitHub organization for the Google Cloud Platform has 36 public repositories, some of which are currently undergoing their initial code reviews, which you can follow on the repo. The Google Cloud Platform Developer Relations Team will be using GitHub to maintain our starter projects, which show how to get started with our APIs using different stacks. We will continue to add repositories that illustrate solutions, such as the classic guest book app on Google App Engine. For good measure, you will also see some tools that will make your life easier, such as an OAuth 2.0 helper.

From getting started with Python on Google Cloud Storage to monitoring your Google Compute Engine instances with App Engine, our GitHub organization is home to it all.

Trick of the trade: to find samples relating to a specific platform, try filtering on the name in the “Find a Repository” text field.

We set up this organization not only to give you an easy way to find and follow our samples, but also to give you a way to get involved and start hacking alongside us. We’ll be monitoring our repositories for any reported issues as well as for pull requests. If you’re interested in seeing what a code review looks like for Google’s open source code, you can follow along with the discussion happening right on the commits.

Let us know about your suggestions for samples. We look forward to seeing what you create!

By Julia Ferraioli, Developer Advocate, Google Compute Engine

Google Ideas develops citizen engagement pilot project for Somalia

When a country is unable to hold regular elections, how do people make their voices heard? That’s the challenge today in Somalia, which hasn’t had a permanent government since 1991. Somalia is in the middle of drafting a new provisional constitution which will be ratified later this summer, and with this process has come new opportunities to increase citizen engagement.

As the draft constitution has undergone revisions in recent months, Google Ideas developed a pilot project with the Somali service, Africa Division of Voice of America (VOA) to help Somalis register their opinions. Using Google App Engine, Google Voice, and Google Docs, we built an internal site for VOA to conduct public opinion polling:

Starting in April, with just a few clicks, VOA pollsters could call and survey Somalis for their thoughts on a new constitution, asking questions such as: Should there be a strong central government? Should Sharia law be the basis of the constitution? And should there be a requirement that women be included as elected officials? Over three rounds of polling, VOA used the internal site to collect the survey results. The last round concluded last week, and VOA published the aggregate results across the country on its new radio program, “Constitution Square.”

We’re pleased to make this small contribution in helping Somalis participate as they draft a new constitution, and hope that others might benefit from this as well. This open source project can be modified for use in any country or context, and anyone interested in downloading the source code can click here.

By Brendan Ballou and Yasmin Dolatabadi, Google Ideas

Open Monitor: Building a World Wide Internet Connectivity Monitor through Google Summer of Code 2011

Despite all the magnificent improvements to both technology and the internet these days, we lack a free and open source real time internet connectivity monitor from which anyone can tell what the connectivity conditions are in any part of the world. Solving this problem is a huge undertaking, but at Umit Project, we saw a chance to start developing such a solution through the Google Summer of Code when we were chosen as a mentoring organization for the 2011 program.
   
We chose a hybrid P2P approach that would consist of hybrid peers and a centralized server that we call the aggregator. The hybrid peers would be able to communicate with each other and pass along reports even if direct connection to the aggregator is blocked, acting as both a server and client and promoting themselves to super peers as needed. The aggregator would be responsible for gathering all the connectivity reports from the peers and showing them in real time in a Google App Engine based site using the Google Maps API.

We also thought of having three different kinds of peers: desktop peer, desktop super peer and mobile peer. The desktop peer runs on top of the same code base but promotion to super peer status is based on the peer's availability. The desktop version is very portable (runs on Mac, Linux and Windows) and is written in Python, while the mobile peer is Android based, can not turn into a super peer and is focused on getting us a view from inside mobile ISPs.

We were given three talented students for the three month long Google Summer of Code, and each of them tackled the different pieces of the system. Despite the overwhelming amount of work and the short time frame they were working with, the students managed to get these systems to form a network, communicate, run connectivity tests and share reports.

The Umit Project team has been working very hard since Google Summer of Code ended in August to deliver our first version of Open Monitor and we're very close to releasing an alpha in the next few weeks for selected trusted testers.

If you're interested in knowing more about the project, its motivation, and more technical details about it, we have released a video on YouTube of a presentation given about the project at the Creativity World Forum 2011 and another talk given at the Chicago Python User Group Meeting. Slides of the CWF11 presentation are also available to view.

Special thanks to Google for their amazing Google Summer of Code program!

By Adriano Marques, Director of Umit Project and Google Summer of Code mentor

Cauliflower Vest: end-to-end OS X FileVault 2 recovery key escrow solution

We are thrilled to announce the open source release of Cauliflower Vest, a solution that we’ve developed to automate enabling FileVault 2 and escrowing recovery tokens.

FileVault 2 is a major, welcome addition to Mac OS X starting with Lion, as full disk encryption is an important part of securing your computer and its data. While the new FileVault 2 offering is very well suited to consumers, some enterprises may require additional features that are not provided out of the box. For example, FileVault 2 encryption is initiated voluntarily by users, lacks enforcement, and, by default, escrows recovery keys to Apple’s central server. It also relies on individual Apple IDs, which cannot be managed as a group.

Cauliflower Vest bridges these feature gaps by allowing enterprise Mac admins to:

• Forcibly enable FileVault 2 encryption.
• Automatically escrow recovery keys to a secure Google App Engine server.
• Securely access recovery keys so that volumes may be unlocked or reverted.

This release includes a GUI client to easily enable encryption, an escrow service, and a web UI for management. Also provided is a standalone CLI tool to automatically initiate encryption and generate a recovery key without requiring any user actions.

Employees at Google self-enable FileVault 2 using Cauliflower Vest - it’s tested and ready to help you make FileVault 2 part of your enterprise.

We are releasing this source code today as part of our commitment to share Google's unique IT approach with the world, including future releases of Simian and more.

For more information, please visit the Cauliflower Vest project page and join the discussion list.

Several Googlers made Cauliflower Vest possible: Anthony Lieuallen, Avi Drissman, Edward Marczak, Felix Gröbert, Greg Castle, John Randolph, Justin McWilliams, and Mark Mentovai.

By Edward Marczak, John Randolph and Justin McWilliams, Google Corporate Platforms Engineering Team

Unleash the QualityBots

Are you a website developer that wants to know if Chrome updates will break your website before they reach the stable release channel? Have you ever wished there was an easy way to compare how your website appears in all channels of Chrome? Now you can!

QualityBots is a new open source tool for web developers created by the Web Testing team at Google. It’s a comparison tool that examines web pages across different Chrome channels using pixel-based DOM analysis. As new versions of Chrome are pushed, QualityBots serves as an early warning system for breakages. Additionally, it helps developers quickly and easily understand how their pages appear across Chrome channels.

QualityBots is built on top of Google AppEngine for the frontend and Amazon EC2 for the backend workers that crawl the web pages. Using QualityBots requires an Amazon EC2 account to run the virtual machines that will crawl public web pages with different versions of Chrome. The tool provides a web frontend where users can log on and request URLs that they want to crawl, see the results from the latest run on a dashboard, and drill down to get detailed information about what elements on the page are causing the trouble.

Developers and testers can use these results to identify sites that need attention due to a high amount of change and to highlight the pages that can be safely ignored when they render identically across Chrome channels. This saves time and the need for tedious compatibility testing of sites when nothing has changed.



We hope that interested website developers will take a deeper look and even join the project at the QualityBots project page. Feedback is more than welcome at [email protected].

By Richard Bustamante, Google QualityBots Team

Introducing Solar Permit AppEngine Examples

It was a milestone that took over 50 years, and at last solar panel manufacturers can produce their modules for less than $1/Watt. Now, the renewable energy community is faced with the dilemma that the permitting and interconnection costs, i.e. the paperwork, is a significant fraction of the cost of a rooftop installation. To deploy gigaWatts of solar energy in the United States these costs need to drop. In response, the Department of Energy has made permitting part of its Sun Shot Initiative and SolarTech has launched its Solar Permitting Challenge. And now Google is pleased to announce Solar Permitting Code Examples to make it faster for software developers to be productive using AppEngine.

A small team of Googlers (Alex Martelli, Arjun Satyapal, Clay Murphy, Luke Stone, Ross Koningstein and Dave Fork) pooled their 20% time to help out. We tried to make the task of building a web based permitting application easier by providing examples of essential tasks in AppEngine including login, creating new permit requests, uploading files, and gathering statistics. Two different versions, one in Python and one in Java, were created.

We were inspired to create this code example by the work that SolarTech has done to promote faster permitting through its Solar Permitting Challenge, and by the Solar ABCs efforts to produce a simple, uniform process for solar permitting. The user login screen for the Python code example appears below.

Navigant consulting estimates that there are 700 gigaWatts of solar power generation resource on rooftops in the United States. Overall, we believe that efforts to streamline the workflow connected with rooftop solar installations could reduce the costs of installations by 50 cents/Watt. Please help us help the industry make this a reality.

By Dave Fork, Solar Permitting Team Member

See you at PyCon 2011

As many of you may know, Python is one of the official languages here at Google. Guido van Rossum, the creator of Python, is a Googler too—so naturally we’re thrilled to be supporting PyCon 2011 USA, the largest annual gathering for the community using and developing the open-source Python programming language. The PyCon conference days will be March 11th to the 13th, preceded by two tutorial days, March 9th and 10th. For those of you with coding in mind, the Sprints run afterwards from March 14th-17th. All-in-all that’s nine days of Python nirvana!!

In addition to having many Googlers in attendance, some of us will be presenting as well.

• On Wednesday, March 9th at 2 PM, I will be leading a Google App Engine tutorial with fellow teammate Ikai Lan. Tutorials have gotten so popular at PyCon, they’ve now been expanded into a two-day affair!

• On Friday the 11th, the very first day of sessions, App Engine engineer Brett Slatkin will kick things off with his talk, “Creating Complex Data Pipelines in the Cloud” using the new App Engine Pipeline API at 10:25 AM.

• After lunch on Friday, I’ll take my Google hat off momentarily to discuss Python 3 in my talk subtitled “The Next Generation is Here Already” at 1:35 PM. It is mostly a repeat of the well-received talk I gave last year but with updates. The main point is to introduce folks to the next version of the language and discuss how its backwards-incompatibility will affect users, when users should port their apps to Python 3, what the differences from Python 2 are, etc. My job is to calm and soothe, dispelling any FUD (fear, uncertainty, doubt) about Python 3.

• On Saturday morning at 9:25 AM, Python creator, BDFL, and App Engine engineer Guido van Rossum will do his annual Q&A session for all conference attendees in a fireside chat session.

• Later Saturday morning at 11:05 AM, I’m looking forward to speaking about “Running Django Apps on Google App Engine.” This is exciting for me, not only because it’s a relatively new topic, but it represents a major change for Django developers: being able to write Django apps that run on NoSQL or non-relational databases -- it’s been only RDBMSs all this time. Furthermore, with Django-nonrel, you can move Django projects/apps between traditional hosting and App Engine, helping to break that “vendor lock-in” issue that many have had concerns about when hosting apps in the cloud. A good part of my talk does focus on porting apps from App Engine to Django however.

• Right after my talk, at 11:45 AM comes another famous Googler, author of Python in a Nutshell, co-editor of the Python Cookbook, and a long-time member of the Python community, Alex Martelli. Alex’s invited talk on “API Design anti-patterns” will be insightful and cerebral, sure to cause many future hallway discussions.

• Late Saturday afternoon at 4:15 PM, Google engineer Augie Fackler will deliver his talk entitled, “HTTP in Python: which library for what task?” There are many libraries that do HTTP. Which ones should you use and when? What are the benefits and tradeoffs?

• Finally, several members of the Google App Engine team, App Engine forum gurus, and experienced App Engine users are attending PyCon this year. I’m hoping to establish an OpenSpace session one of the conference evenings where we can meet other users, chat about best practices, and do some informal Q&A letting people ask anything they want (except “When will you support newer versions of Python?”). :-)

You can find the entire PyCon schedule online. It’s interactive if you log-in, allowing you to bookmark sessions you’re interested in attending. This will be PyCon’s biggest year yet, so hopefully you can join us in Atlanta next week! Keep an eye out on the PyCon blog to get the latest news, and be sure to follow the Twitter hashtag (#pycon).

We invite you to join Google team members at all our talks, plus stop by our booth to meet our technical staff as they demo select developer tools and APIs. We’ll have handouts there and also encourage you to try a short coding puzzle for a prize!

By Wesley Chun (@wescpy), Google Developer Relations team

Simian: Mac OS X package deployment via App Engine

Administration of software packages on the Mac platform can often be daunting. Google’s Mac Operations and Security teams evaluated several solutions for OS X package deployment, but unfortunately none of them met all of our required features. We decided to build our own solution to do the following:

• Deploy new or updated software by targeting a single Mac or tens of thousands.
• Push security patches, whether the Mac is on an internal network/VPN or not.
• Force mandatory installation of some packages, while allowing others to be optional.
• Tightly manage Apple-provided updates.
• Scale without deploying and maintaining additional server infrastructure.
• Obtain reports on all of this and the fleet overall.

Today we are open-sourcing Simian, our solution to enterprise-class Mac OS X package deployment. Simian uses App Engine-based hosting to scale with the needs of your growing enterprise, and a Munki-based client which will continue to evolve through the outstanding work of Greg Neagle and the Munki community. We hope this to be the first of many announcements in sharing Google's unique IT approach with the larger community.

For more information, please visit our Simian project page, join the discussion list, and download the code. For more information about Munki, please visit its project page.

By John Randolph and Justin McWilliams, Google Corporate Platforms Engineering Team

Open sourcing Thoughtsite - A discussion forum designed for Google App Engine

Google App Engine is a powerful system, designed to take all the pain of infrastructure management and performance scaling out of web application programming. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow.

While there are a lot of open source projects available to learn how to use App Engine, there have been few open sourced, comprehensive web applications built on App Engine to help you learn how best to use the advanced features that App Engine provides.

Enter... Thoughtsite!
Thoughtsite is a discussions/forum web app designed for Google App Engine. The main features of the app are:

• a flexible system that could be used for any kind of discussion forum.
• voting, tagging, comments and a reputation point system for users.
• full text search on App Engine with Apache Lucene.
• search for threads by tags or by keywords. Threads can also be linked to from user profiles.
• users gain reputation points based on community votes for their contributions.
• full-fledged user profiles with info, points, contributions, user's personal tag cloud, etc.
• basic duplication detection filters to detect similar threads so posters can avoid creating a new thread if one already exists.
• basic spam and gaming filters (self-voting, cross-voting, etc.).
• comprehensive admin section that allows moderation of individual posts and users. Users can flag objectionable content or trolls.

Best of all, Thoughtsite is completely open source using an Apache 2 license and the code is available for download.

We hope you download the source, take it apart and play with it. Thoughtsite will work as a complete app if you want to use it to host a discussion forum on your own domain, but its real value is in taking it apart to understand how it uses App Engine under the hood.

By Swapneel Kshetramade, Developer Relations Team

CSS Selector Shell Released

By Lindsey Simon, Google User Experience Team

Most web developers have felt the pain of discovering or remembering ways in which different browsers interpret and/or render their Cascading Style Sheets (CSS). Our newly released CSS Selector Shell is a simple Javascript tool for testing how a given browser parses CSS text by inserting a style element into the document and then reading the cssText back programmatically. You can already check out the CSS Selector Shell code base in action on Google AppEngine.

So far this tool has proven quite useful by showing what happens when developers try to make use of CSS selector syntax that may not be supported in a particular browser. Specifically, it can show how and perhaps why a particular CSS hack works in some browsers and how it is ignored in others. It can also demonstrate the potential for harm when using unsupported CSS syntax in some browsers. For instance, when testing a combined selector ".class1.class2" in Internet Explorer 6, it becomes active as ".class2", which may not at all be the goal of the CSS author. Another detail the CSS Selector Shell demonstrates is that shorthand property/values sometimes expand much further than you may have suspected. On the test page itself, there are two visible test elements that you can use to target and experiment. The code itself makes use of the Dojo Tooklit as well as the Django framework.

We hope this tool will be useful to you in diagnosing problems or understanding the differences between browsers when interacting with your Cascading Style Sheets. We always welcome your feedback, so check out the code and let us know what you think in our discussion group.

Google Blog Converters 1.0 Released

By J.J. Lueck, Data Liberation Front

Blog authors around the world, Google would like to remind you that it's your blog, your data. Now that Blogger allows users the ability to export all contents of their blog, the Data Liberation team would like to announce the Google Blog Converters project. This new Open Source project provides the ability to easily move blog posts and comments from service to service. This initial release provides Python libraries and runnable scripts that convert between the export formats of Blogger, LiveJournal, MovableType, and WordPress.

In addition, the source code includes templates for hosting these conversions on Google App Engine. Future additions to the project will include support for BlogML and synchronization tools between various services that do not provide a import/export feature but do provide APIs for accessing and modifying blog contents.

We're excited to provide this level of control for your personal blog data. Contributions to the project are always welcomed and encouraged, so check out our source code (download, 2.7 MB zipped) and let us know what you think. We look forward to your feedback in our discussion group.

Gerrit and Repo, the Android Source Management Tools

By Jeff Bailey, Open Source Team

A couple weeks ago, we announced the Android open source release. Beside it, we silently released the tools that we wrote in order to make handling a large multi-repository project manageable in git. If you had a chance to look through the Android open source website, you'll notice references to a tool called repo. Why did we write this? With approximately 8.5 million lines of code (not including things like the Linux Kernel!), keeping this all in one git tree would've been problematic for a few reasons:

* We want to delineate access control based on location in the tree.
* We want to be able to make some components replaceable at a later date.
* We needed trivial overlays for OEMs and other projects who either aren't ready or aren't able to embrace open source.
* We don't want our most technical people to spend their time as patch monkeys.

The repo tool uses an XML-based manifest file describing where the upstream repositories are, and how to merge them into a single working checkout. repo will recurse across all the git subtrees and handle uploads, pulls, and other needed items. repo has built-in knowledge of topic branches and makes working with them an essential part of the workflow.

The gerrit code review tool is based off of rietveld. Gerrit is itself split into two components: Half that runs on Google App Engine to provide front-end web service, and half that runs on a machine to handle attempted merges into the "upstream" branch, and the various code review branches. When we integrate the auto-builders into the system, that will also be handled by Gerrit.

We have a workflow diagram that shows how code gets into the system for Android. If you're looking to switch to git, but don't want to lose the ability for multiple people to commit into an upstream tree, this is one solution for you to consider. Interested? Find us at [email protected]

Highlights from DjangoCon 2008

By Leslie Hawthorn, Open Source Team

Google's Open Source Team recently hosted DjangoCon 2008, the first ever international conference for developers and users of this popular web framework. While we're always pleased to host Open Source events at the Googleplex, we were particularly excited to welcome the Django folks once again. We love Django, making use of it extensively in products like Google App Engine, so it was a pleasure and privilege to give back to this community. More than 250 attendees in Mountain View, California, USA enjoyed two days of technical sessions and celebrated the recent release of Django 1.0, and thanks to the efforts of one of our stalwart Site Reliability Engineers, Rodolpho Eckhardt, we were able to welcome more than 50 additional guests via videoconference with Sao Paulo, Brazil. Better still, attendees raised several hundred dollars for the Django Software Foundation through a charity auction, their donations netting them swag like conference tees signed by Keynote speaker Guido van Rossum and notebooks (the legacy interface variety - paper only) signed by the Django Core Developer Team.

Many thanks to Conference Chair Robert Lofthouse for making DjangoCon 2008 a reality in just a few short months, our attendees for joining us and the entire Django community for both their amazing spirit and great code.

Wish you could have made it? We've got you covered; the conference sessions are now available on YouTube for your perusal.

Ed. Note: Due to technical difficulties, Jacob Kaplan-Moss' Saturday Keynote, The State of Django, was not recorded. Fortunately we've heard from Jacob that he'll be back in the San Francisco Bay Area later this year and will be happy to reprise his talk then. We'll post to this blog when that talk happens and the video is make available.

Geeks Find an Alternative Way to Spend a Summer Evening

By J-P Stacey, Oxford Geek

What with the football and the tennis, and the Glastonbury Festival and Reboot 10, we had no idea how many people might turn up at the Jericho Tavern for our latest Oxford Geek Night. So it was with relief that we finally counted around a hundred geeks through the door, thanks to our master-stroke of handing out Moo cards to all-comers, to be exchanged for the Google Open Source Team's kind hospitality at the bar.


Keynote speakers are generally industry experts, standard bearers, or just well-respected enthusiasts in their field. This time our keynote was delivered by Tom Taylor from Headshift, talking about not so much his day job as the “beautiful pointlessness” of mashups and automations he had built in his spare time (turning automatic webservices into Twitter feeds, such as @lowflyingrocks), and how other people’s similar work had inspired his own. This was followed up by a brief announcement from the Oxfordshire branch of the British Computer Society and a short break.


Our usual mini-presentations, a.k.a. microslots, then came in thick and fast, in two batches of three. First up was Andrew Godwin, whose music graphing software LastGraph reduces CPU cycles to smoking rubble; Drew McLellan followed him, accompanied by 1970s British TV characters The Clangers in an explanation of the advantages of microformats; then Matthew Westcott took us into the break with the lowdown on the new AJAX “push” technology Comet, and provided us with a soon-to-be legendary description of long and short polling in relation to a tedious car journey with your dad.


After much poking and prodding while everyone else relaxed, Matthew began the second set of microslots with his live demo of Comet, and from this we moved on to a walkthrough of Google App Engine by Tom Dyson; Simon Whitaker imagined in lurid detail and deadpan enterprise jargon how one might use the OSX address book; and Duncan Parkes finished by taking us behind the scenes of PlanningAlerts, yet another focussed, simple, successful, society-changing application from the mySociety stable. The night was rounded off by a book raffle, back after a brief hiatus for OGN6 thanks to Friends of Ed.

You can check out videos for any of these talks, all of which are linked from the Oxford Geek Night #7 page.