Dougma (dŭg·mə) n.

  1. An authoritative principle, belief, or statement of ideas or opinion, especially one considered to be absolutely true by Doug; who is often wrong.
  2. A specific tenet or dougtrine authoritatively laid down, as by Doug.
  3. A system of principles or tenets, for Doug.
June 16th, 2008

Any Pythonistas in Missoula Montana?

I will be in Montana again in early July. This year I will have a rental car and thus more freedom than in the past. Are there any pythonistas in the Missoula/Lolo area? Or coding in general? Security?

It has become tradition that I start getting my personal game plan for PyCon together. I am hoping to do less coding and more organizational work. It would be nice to talk to anyone who has been to a recent conferences (technical or not, professional or not, python or not, does not matter).

May 26th, 2008

Sarah’s first Camping

Well no bears this time, and no pictures yet either. We had a fun time at our annual first camping of the year, and Sarah had a blast. The weather was perfect. Everything went great. Josh was a great big brother showing Sarah the ropes and introducing her to everyone. One of the highlights was playing tag with Josh, his friend Quit and my friends Matt and Deidra.

But for some reason I just did not relax. I didn’t get to spend as much time with friends or just vegging on the beach as I wanted, and I really have no one to blame but myself. Part of the problem is that I just could not shut my brain off. Last year I got a notebook, and it ended up being my ‘PyCon’ notebook. This year, I just didn’t seem to have time, oddly enough. Code freeze at work was Friday and that, I am sure, didn’t help. The official fork will most likely be this upcoming Friday.

I have had no time to work on any of my python projects, and it is driving me crazy. There are so many fantastic things happening with django-survey, and Pinax is picking up steam, I need to put the old PyCon ‘08 stuff into archival mode, and start up ‘09. There is some very very interesting stuff going on with the DFW Python group that I want to help out on as well. There are so many fantastic things being worked on right now by incredible people, and I feel a down right claustrophobic not being able to do anything myself. I only been able to attend one Boston Python Meetup so far this year!

It looks like I will be in Montanna the first week of July this year (my anual pre-PyCon-Tech kickoff-kickoff). Barring any project ‘issues‘ I hope to get my act together then (with respect to PyCon software for 2009). If there are any pythonistas in the Missoula area, please send me an e-mail! For now I guess I should get back to unpacking the car.

May 13th, 2008

The Hague Decloration

Andy Updegrove has just posted about The Hague Decloration. I received a phone call about it this morning, and I believe it is one of the most important declarations on human rights to come along in quite some time. Please go read up on this. It may at first appear that technology and the standards those technologies are based on are a very meta-level aspect to human rights as apposed to the men in the night. Recent issues with Google, Yahoo, and Cuba, and South Africa have shown us otherwise. Please read Andy’s post en toto.

When one thinks of international human rights, one thinks of The Hague - home of the International Court of Justice and the International Criminal Court, and the situs of an increasing number of Tribunals chartered to redress the assaults on human dignity that inexcusably continue to plague this planet.  It is therefore appropriate that The Hague has been chosen to witness yet another pronouncement in defense of human rights.  That pronouncement has been titled The Hague Declaration by the new international group, called the Digital Standards Organization (”Digistan,” for short), that crafted it.  In this blog entry, I’ll talk about what the Declaration is all about, and what it is intended to achieve.

The basic premise is that as more and more of our basic freedoms (speech, assembly, interaction with government, and so on) move from the real to the virtual world, care must be taken to ensure that our ability to exercise these freedoms is not inadvertently eroded or lost.  And on the opportunity side, the Internet and the Web provide incredible and unique ways to bring the benefits heretofore enjoyed only in developed countries to those struggling for equality of opportunity in emerging countries.

– Andy Updegrove (Consortium Info Blog) ‘Introducing The Hague Declaration

April 30th, 2008

A picture is worth 1000 words!

Steve Ballmers Laptop.

April 24th, 2008

Generosity of the Python Community

Steve Holden is participating in the 5K Race for Hope. He is looking for people to sponsor his run. Lets show the other groups the generosity of the Python Community! (Sorry Team Hopkins, Steve got to me first ;-) )

If Steve is willing to go the full 5K distance, we should be able to support him with some cash. With the exception of this past year, it has been his fund raising efforts which have kept PyCon so cheap. Lets put some of those saved pennies towards a great cause!

April 24th, 2008

Limit Exceeded

Hmm…. I know I should be more concerned about what this says about my internet useage:

You have exceeded your 1027.63 gigabyte download limit
You have downloaded a total of 1027.67 gigabytes.

April 18th, 2008

Ray Ozzie, Microsoft and Open Source

I was going to write a reaction to Ray Ozzie’s comments on Microsoft and Open Source. First off this is a blog post which just quotes some of his comments. One must be careful when that happens, and I would prefer to read an entire transcript. Still there is enough context there to work with. I have been waiting for over a year to hear from this titan. It saddens me to read these excerpts.

I never write a post all in one go, and while doing other things I saw another blog post about this subject. It is much better than anything I could have ever written and sums up every point I wanted to make; then continues on to a level I am incapable of. So go read that.

April 16th, 2008

GitS: The Coming Abomination (in 3-D!)

I was having a decent enough day until this came across my rss reader:

DreamWorks Acquires Rights for Ghost in the Shell

And another of my favorite franchises gets mutated, warped and ruined. “But it’s DreamWorks and Spielburg“, you say. Exactly. Not only do I get to see something I love destroyed, I get to watch DreamWorks produce a turkey. To be honest I do hope they can pull it off, but I really do not expect it to happen. Even the franchise creator Masamune Shirow botched it (GitS2: Innocence was utter crap). They plan on making ‘it’ a 3-D live action movie (I think I just threw up a little in my mouth), but are very vague on what exactly ‘it’ is. The origional film from 1995 was revolutionary. It brought cyberpunk to a new level which has not been matched sense; not even by the rest of the franchise.

When I first hear that a TV series, GitS: Standalone Complex, was going to be produced I was concerned; just having been betrayed by Innocence. I was dismayed when I saw the opening sequence. You see in anime, the opening and ending sequences say a lot about the show in an indirect manner. The opening is usually orders of magnitude better than the actual show. The GitS:SC opening, rendered on a Playstation2, was so bad that I wrote it off (don’t get me wrong the music is top notch). That is until I heard from friends what I was missing. It turned out to be a good solid anime, shot through with moments of brilliance. Then came the follow up 2nd season, appropriatly named GitS:SC 2nd Gig. The entire season was phenomenal. The opening actually lived up to the series (without surpassing the actual content of the show). The sub plots were all tied together superbly. There were a total of 2 ‘filler’ episodes and even those managed to move the other plots along (which again were part of a seamless whole). GitS:SC Solid State Society actually made up for Innocence wrapping up the story and ending the franchise on a high note.

And therein lies the problem. The story is done. The only way to do anything more with it is to take it to a different country where the majority of people know nothing about it and re-do it in some botched way (ala ‘The Ring’, ‘The Visitors’, ‘Dark Water’, I could go on for pages…) Go see the originals of those films, especially ‘Dark Water‘. No comparison.That movie gave me nightmares; I turned off the US remake because I was laughing.

What really scares me is that another Masamune Shirow’s works (and another of my favorite manga+anime’s) AppleSeed was recently redone in ‘live action based 3-D‘, and… well… I could not watch more than 15min of it. I wish I had never seen those 15min as they have laid a taint on my memory.  It was bad. I mean really really BAD. It’s Phantom Menace all over again (or at least Bubblegum Crisis 2040… why? The series was done… no need to ruin it!) [Yes I have the Priss Hurricane Video in origional japanese and Live Concert on import PAL VHS]

Postscript: What did we do before wikipedia and youtube!?!!?!?!?

April 13th, 2008

Google App Engine: The good, the bad, and the ugly?

I have been holding off on writing this post as I prefer to fully form an opinion.

At the writing of this there are almost 600 blog posts about the new google hosted application. Most seem to me to be flailing around the actual core of what this new little beastie is. Some are comparing it to Amazon offerings, some as a threat to commodity hosting, and some as the dawn of a new computing revolution. A few highly respected people see this as brining application development to the people the way that html/aol/myspace brought web development to the people. Many see this as a validation that python is an enterprise level platform. While I believe python is just that, I do not yet see this as a validation. The validation comes with Google App Engine’s success. Not that the language needs this added validation. As for the revolution, time will tell.

Google is toting this as making the web a platform. A platform for development, essentially replacing the desktop as where applications get developed and deployed. They do all the busy work of setting up the hardware, configuring systems for monitoring traffic, setting up the database, setting up the source control system, bug tracking, and all the rest, and let you focus on writing the application. Also you get the power of Googles massive data centers with literal warehouses of machines and disks and their custom database.  They bill this as being a platform for building your web based applications, a user base, business, and revenue stream. Of course one revenue stream will be ad-sense further promoting the Google advertising juggernaut. This is all fantastic, but there are limitations (as there must be). I put the limitations at the end.

What is Google really up to?

Google is not releasing the App Engine in a void. There are many other services that google has been rolling out over time (and many quite recently) which need to be looked at in order to get a proper view of what is happening. First lets step back a bit and look at Google’s past. In the past when google released a feature with an API, people would rush out and start building mashups. Mashups which combined parts of Google, and parts of other systems. Systems google often had little or no control over. Early on Google revoked some keys when things got out of hand. Very early on there was some bad PR. Some mashups went away, some came back, some just died out. There was a wealth of data, information, and potential revenue behind those mashups, but it was out of Googles hands by and large.

In the mean time Facebook came along and changed what it meant to write a web app. No longer were applications monolithic disconnected things. They were widgets which plugged into a page. They were cool integrated, socially networked, and shared. They were things people paid real money for. They were things people were using to generate adwords revenue! Google created their own apps. They created them for all the other social sites and the desktop. they did not care who was the hot new trend, as long as they had a share. But they have to play by other peoples rules and API’s.

So google has their search, mail, maps, and documents, online bookmarks, and calendar. They have an rss reader. Others are making mashups, and now many of those are occurring on FaceBook as 3rd party apps. Google releases some extensions for form filling on the docs, and integrating charts. They release a data API. They release OpenSocial as an attempt to standardize all these social networks and the core of what their apps provide; the social connections. They release custom site hosting (without announcing it except in a blog posting). They now have all these great applications and pieces of applications. They have a means of creating, editing, and hosting static html and data. What they lack is a framework to integrate everything. Something where they host the mashups. Something that they can do the deep data mining on. At least that was the case until App Engine came along.

Google claims in the very opening of their announcement that the App Engine is all about the developers. It is all about the people out there who develop neat and interesting things and the feedback loop that creates. The creative creativity of the masses. That has always been the key to Googles overall success. They provide the tools, and others create all those great mashups, sites, and apps. This is not about you creating your cool new app. This is about you creating your cool new Google mashup app utilizing all the other google API’s. They are not all there yet, but they will be. The crucial one, the user backend, is already there. All the other offerings do not require their python API. All the other offerings already have javascript and IFrame, and other means of integrating which were developed for integrating with your blog or MySpace or FaceBook. But make no mistake, they are coming to GAE.

In short this is about taking all those Google pieces parts and creating the ‘next big thing’ and using the developers out on the internet to do it, as they are the ones who will do it anyway and now they can do it for Google.  Google gets their precious data, their add revenue, and at some point people get to pay for the privilege of developing apps for them (either via adds or real money for removing those quotas).

Now comes the really cool part. The SDK includes everything you need for running locally. They have the Google Gears framework for making your apps work both online and offline on your desktop. Integrate all that fully and there really is no difference between your online web based apps and your desktop apps. There is still a long row to hoe before it gets to that point, but the pieces are falling onto place.

Why Python?

There are a number of theories about the real reasons for choosing python. Most believe it’s because python is one of Googles 4 primary languages. I do not believe that exactly. If this could have been done in Java, they would have done that. PHP is the only other ‘language’ that could approach what they want to do. As what they want is a platform for developing mashups with their existing technologies on a massively distributed scale by unknown random people, here is a short list of requirements:

  • Easy to develop in (who would develop in prolog?)
  • Sandboxable (including no ability to crash the server or corrupt ram)
  • No spawning of processes/threads (or other things to bypass cpu/process management)
  • No connections in or out of the app except those expressly controlled via an API
  • Easy means of administration (for the developers)
  • A language for which the Google API’s are already available
  • Low overhead for deployment on the servers [initial startup cant be too slow, later requests must be extremely fast]

I know of no other language which meets these requirements. PHP comes close, but would require a partial lobotomy (where python just has some modules removed or limited). Also PHP is not one of the languages that there are API clients for. I know that people are clamoring for other languages. All I can say is don’t hold your breath. I just do not see it happening any time soon.

[UPDATE: as a commenter points out, google is quite dedicated to python and has many core programmers on staff including the language creator. This is a great help for getting things done and adding validity to the project. Read the comments to hear my thoughts on Ruby.]

Growing Pains

App Engine is in its infancy. As with all their Beta projects there are problems. The main problem is how they are dealing with the problems. In short they are overwhelmed. People are asking for PHP, and their favorite python projects to be supported. They made the mistake of claiming that most python frameworks will run on it without putting up the proper CAUTION signs. It is possible to get Zope to run on it with some work. All that is missing is the hook to use the google database instead of the ZODB as the backend, a few minor tweaks, and use the WSGI adapter. Twisted is just out due to the signals, and the threads, and crucially, the tcp connections. One of the problems is that people expect that XYZ module should just work, and it’s the App Engine teams job to do that. The team seems to feel that they provide the framework and others should do the porting. There are also reports of bugs not being responded to in a timely manner. This is a bit laughable given the shear number of bugs currently reported and the 15 or so engineers they have dealing with all the App Engine deployment issues. I am sure that no one expected to have to deal with flamewars in the bug tracker. Or that thousands of people would post +1 comments in the bug tracker making it next to unusable (some people just can’t read instructions). I would not expect all the current bugs to be triaged until late next week or the week after.

Most of the complaints seem to be about the limitations put in place. I can understand that, but I can also understand why hell will freeze over before most of them are lifted. When it comes to an initial deployment it seems quite generous and unrestricted. Insanely so. If you think about what it takes to deploy something like this, at this level, things start to click into place. How would you do it? How would you manage the issues, security risks, vectors of abuse? It is great to say you want to create thread to accept a certified https connection, but if you are making that request, then you have no clue about the technical aspects behind that request or the technical aspects behind the App Engine.

Current Limitations

1. No long running processes

These are run once executions, and there is a time limit of a few seconds. Think of this the same way you would think about a PHP page.

2. No reliable state between runs

There is potential state from one run to the next, but you should not rely on it for large deployments. All state and persistent data should be stored in the database (or via some neat hacks). NOTE: this is more from my reading between the lines and knowledge of load balanced grid deployments. I.e. I do not trust their ‘cache‘ system as something that can be relied upon.Why? Because we are talking about nodes and sandboxes.

3. No incoming TCP connections

No binding to sockets, etc. These are Google’s servers. Even they do not know which node your http request which starts the app will be run on; no way of knowing which IP it really will be. Only apps are running on these nodes. This means no mixing of non-app and app requests. No twisted or zope admin instances. For google to provide a proper balanced network (with proper dispatching), it has to be that way (well at this phase in the game at least).

4. Limited connections out

Google has a url API for making http and https requests out to other servers, a connection to a database and a mail API. Those are the only outgoing network connections, and all are bound in API’s. If you were allowing anyone to run programs on your servers would you want them to be part of botnets?

5. No https

This is not static IP hosting, no cert for you! There are some things that can be done, but there would be cert warnings, etc. Granted this does not stop you from integrating with PayPal, or Google Checkout, where the https checkout is handled by a different site (insanely weak). [UPDATE: yes I know static IP's are not required for certs, but they are required if you would rather people not to get the cert warning or have IE7 mark the site as 'insecure'. And google will not pay for a cert per app, nor will it get a single cert for all apps some of which they are not really sure of their authenticity (a phising app based on Adrian's dynamic html->template tool for instance.) I do expect them to support something in the future, but that is a ways off and will not be for free.]

6.  No spawning new processes (or signal overriding)

Well no big surprise here. Starting new processes could be very dangerous for all, and signal overriding… well that could make it hard for google to safely stop a rogue app (among other things).

7. No creating new threads!

Ok, this is a bit strange at first blush, but if you have ever dealt with grid deployments, or taught a 102 CS course (where you start covering semaphores and mutexes, and IPC) you have had the experience of a rogue multi-thread app taking down a  machine. Part of the problem is that creating a new thread is very much like starting a new process. One of the interesting things about starting a new process is that the operation does not adhere to the nice protocol. It gets the CPU to do that start no matter what, and at the kernel priority (which is not very nice). New threads behave the same way, and are a PITA to deal with when trying to take down a process which has gone rogue. I hated that lab. I have other theories behind why they do not allow this (but that is for another post)

8. No ‘real’ filesystem

Well there is no real access to the file system. Not the ‘real’ file system. As such certain things like tmpfile are not present (as there is no /tmp directory).

9. Crippled import/bytecode

Well that is an overstatement. Google has written their own import replacement, and modified the bytecode (I think) from standard python. I have some theories on why for a later post, but the deal is, forget about using marshal, imp, or even some of the package __import__ hooks, and cPickle is just pickle.  Part of the reason is because of the lack of a ‘real’ file system. The python path and import control is special as only packages from google, and those in your current app are available, and they are specially managed. This should not affect anyone unless you play funky package import tricks that you should not be doing anyway. Extending __path__ in packages does still work, but using __import__ directly to import a package using a computed abs path does not work (might be a bug).

10. Quotas and App shutdown

If your app gets too popular and goes over quotas, then it is disabled. Once it gets too popular,  you need to buy more computes, etc. None of the quotas are set in stone yet, and of course if you use google analytics and/or ad-sense, then the quotas are less restrictive or removed. The details are still in flux. For the beta period you can request a larger quote for free (but each request is reviewed for merit). You can also report app abuse if you find that someone’s app is not being nice.

[UPDATE: Here is the link to the current quota system.]

11. Only 3 Apps and no deleting.

For the beta period, each developer can have just 3 apps, and you can not delete an app.

12. Only pure python

No c extension modules. This is again because of the sandbox system, and all the other stuff above. You can’t prevent process or thread spawning in a c extension. You can not stop a c extension from corrupting things in very bad ways. You can’t stop it from attempting to connect out or bind a tcp port. And it would be a PITA to distribute the binaries to all the nodes like they do for the apps themselves (via custom import hooks + caching).

[UPDATE: fixing numbering and adding some other restrictions and errors people have pointed out]

13.  1MB per file upload limit and 500MB total storage limit.

The 500 MB limit is part of the current Quota system, but I was unaware of the 1MB file upload limit that a commenter pointed out.

14. 1000 files in an app limit

This is a huge problem for people trying to deploy pylons, TG, or Django trunk based applications. One potential solution (which is not currently supported) would be for google to allow for python zip imports and have things bundled.

15. The Google DataStore has limitations over a classic RDBMS

Ben Bangert has a great write up on this, so go read that. ;-)

April 11th, 2008

Randall Munroe Rules!

It’s like someone peered into my 3am brain and drew what they saw.

Randall: you forgot the farside chicken perched on the tree, but besides that, spot on! Spot On!!