Now, while I think a netbook is great for someone like my mom, or my daughter, I cannot imagine myself doing any sort of serious programming work on one. Or can I?

So, first of all it looks like is a non-starter. That means I would likely have to use something like Mozilla Bespin as my editor. A quick Google search showed me that you can edit remote files using Bespin, so that is a good thing. But I would miss doing all the system-level things I’ve grown accustomed too. Would make it pretty much impossible to do command line testing of code.

And what about all my tools for managing databases? All the web-based database manipulation tools (like phpMyAdmin or phpPgAdmin can probably meet that need. But then I’m looking at some sort of web-based SSH client to be able to look at things like server configurations or slow query logs. Again, it’s probably doable but is it optimal?

Anyway, it’s an interesting thought. Perhaps I should spend some time trying to see if I could actually be productive using the tools I just mentioned above.

So I got to work creating a Django project, installed the django-admin application and got to work.

Have I mentioned how I *love* code generation these days? Can I get "hell yeah!" from the lazy programmers out there? Django comes with this awesome tool that you access via manage.py called inspectdb. What it does is introspect the database you configured for your Django application and generates the output for your models.py file. However, keep in mind the following:

• You *will* have to fiddle with the order your classes that represent the models appear in the generated code
• You *will* have to go in and alter any field definitions where inspectdb was not able to determine the proper field type and instead guessed.

So, after firing off inspectdb, I then issued a 'python manage.py syncdb' to create all the tables needed for django-admin, created a user for the admin site...and then it got hairy.

The documentation for customizing django-admin is good. And I was able to create just about everything I wanted by actually, you know, READING the documentation. But I found a problem that I was not able to solve. I even asked my favourite consultants for help but I could not get it to work the way I *wanted* it to work. When I told my buddy via IM that it would be easier to whip up this admin in PHP than slog through learning how to do it the Django way, he was not impressed. He stopped short of saying "you're dead to me now", but I got that vibe.

Here's the problem. I have these two models:

Now, if you look at the definition in there for the base_league field, you will notice that I gave up and called it an IntegerField. But in reality, it is pointing to another record in the same Permissions table. We have a concept in Sportso of a "shared league model" where you can base a league on another league and import all sorts of properties and data from it. I was hoping that I could do something like this:

Whenever I did that, I would actually crash Python on my MacBook. Not a good sign. If I tried swapping them, I would get an error complaining about violating permissions_pkey, which is the Postgres sequence that was created for the auto-incremented ID for the table. I did manage to take a look at the SQL it was trying to execute, and it keeps trying to update the 'id' field (which is the primary key) instead of the 'base_league" field. So I gave up and will continue building out the other parts of the admin. I just wish I could figure out WHY this self-referencing foreign key setup was not working.

If you know what's going on here, let me know via the comments.

• It will require manipulating exponentially more data than now
• It will require you to understand both parallel processing and concurrency (although to this simple programmer's brain they appear to be the same thing
• A stateless model of the web looks more and more like something that works against human nature

I have become fascinated with languages that talk about dealing with concurrency: Erlang, Python using Twisted, Clojure, and the newest kid on the block Google Go. I have no idea why these interest me so much. But I find them all fascinating, and I wonder how anything we do at work on the XML-feed-parsing side could benefit from concurrency (and that gets me into the topic of whether or not concurrency matters if you have to write data to a relational database and dealing with locks etc, god I sound like a programming nerd!).

Rich Hickey, the creator of Clojure, gave this awesome talk about current programming language paradigms and how well suited they are to the highly statefull, concurrent future that I feel we will be facing when building online applications. Go and watch it and you will find that you knew oh so very little about programming language concepts.

So not only are we dealing with concurrency, we also need to deal with state. PHP is stateless. "Share-nothing" was a revelation for it's time, and allowed you to build web applications that could horizontally scale quite well. But then we started requiring state. So we use things like sessions, and cookies: tricks that allow us to let data persist between requests. You could almost throw databases into that category.

Perhaps this is ignorant rambling. All these things make it harder and harder for a statefull environment like the web to act like it is actually retaining values between requests. Maybe something like Seaside is a model to look at it: it preserves state across requests using continuations, which is a programming concept that you just don't learn when you teach yourself PHP.

You could argue that we are on the verge of a major shift in programming language methodologies. The challenge of programatically handling concurrency and state in a way that programming trolls like me can understand is a huge one. Tim Bray has been covering this on his blog via his "so fascinating it makes me understands how stupid I really am" Concur.next series.

Will we ever have a statefull, concurrent language for building web apps. I'm sure we will. I just don't think it's been written yet.