Entries Tagged 'python' ↓

Adrian Holovaty is the co-creator of Django, author of the Django book and is currently the BDFL of Django along with Jacob Kaplan-Moss. He studied journalism at University of Missouri–Columbia and has worked with many news sites including Lawrence Journal World and Washington Post. He currently works at EveryBlock, a startup he founded.

Shabda: Would you tell a little about yourself? You majored in Journalism, how did you move to Programming?

Adrian: Sure! I have a dual background in journalism and computer science. I intended to get a degree in journalism and a minor in computer science, but things got a little off track. I heard from a professional colleague that a certain Web site would probably hire me if I graduated a semester early, so I hurriedly dropped my CS minor and got special permission to graduate early — but once the time came to ask for that job, the company was in the middle of a hiring freeze and didn’t have a position for me. So, in hindsight, I should’ve stuck with the minor, but things ended up working out OK.

Because journalism and computer science don’t normally go together, I’ve had some success in this silly little niche of employing Web development in news organizations — “journalism via computer programming.” Professionally, I’ve always worked as a Web developer at news organizations, up until my current gig, which is to run EveryBlock. But in its own way, it’s a news organization as well.

Aside from all of that, I’m quite into music, particularly gypsy jazz, which is the music of Django Reinhardt (hence the name of the Web framework). I just recently attended a week-long gypsy jazz guitar camp in Massachusetts and had a tremendous time staying up until early hours of the morning jamming with great musicians from various parts of the world. If money were no object, I would love to play music full time. In the meantime, I’ll settle for posting YouTube videos of my guitar playing, for an audience that seems to be comprised mostly of 16-year-old boys who constantly pester me for transcriptions of my arrangements.

I live with my wife in the beautiful city of Chicago.

Shabda: What are your current roles and responsibilities at Django?

Adrian: Well, I co-created Django back in 2003 with my friend Simon Willison while we were working together. Now, along with Jacob Kaplan-Moss, I’m Benevolent Dictator For Life of the project — a title we shamelessly ripped off from Guido/Python. This means that I have a hand in all sorts of things, from high-level API design to checking in patches and fixing bugs. I’ve touched probably every bit of the framework over the years, including implementing the initial ORM (back when it was a code generator!), pair-programming the original Django template system and URLconf/view framework with Simon and building the original admin application with design help from Wilson Miner.

One of the things I enjoy the most is writing documentation — both because I like technical writing and because I cannot stand bad open-source documentation.

Shabda: Can you describe the philosophy behind Django. What are its overarching goals?

Adrian: A couple of years ago, I wrote the “Design philosophies” document, which sums up the main points nicely.

Generally, the goal is to make Web development fast, fun and easy for the developer, while keeping performance as fast as possible and code as easy to understand as possible.

Shabda: How did the move at WorldOnline from PHP to Python happen? Why did you start from scratch (which finally lead to creation of Django), instead of using something like Zope?

Adrian: Simon and I had been big fans of Mark Pilgrim (and still are!), and we’d read his online book “Dive Into Python.” This was around the same time that the PHP “infrastructure” I’d developed had begun to feel really, really crufty, so…one day we just decided to start using Python! It’s quite nice working at a small organization with a very loose management structure; our boss, Rob Curley, was cool enough to let the developers themselves decide which technologies to use, as long as the work got done. “I don’t care how the sausage is made,” he always used to say.

We looked at the existing Python Web frameworks/libraries, but none of them felt 100% right to us. Simon and I are both quite into best practices, such as clean URLs, proper use of GET vs. POST, etc., so we were very picky in our analysis of those existing tools.

Shabda: Can you tell us about Everyblock? Why did you choose to create your own mapping engine instead of using something like Google Maps? How hard has it been creating a new mapping engine?

Adrian: EveryBlock is the project I lead for my day job. It’s funded by a two-year grant from the Knight Foundation, and the goal is to experiment with block-specific news — that is, the site lets you enter an address (currently only in Chicago, New York City and San Francisco) and view recent news within a very tight radius of that address. I’m pretty confident it’s the most granular attempt at local news ever attempted on the Web. Nobody else is crazy enough to do it, I guess!

We do a TON of work collecting local information, normalizing it and pulling it together for people in one place. A large part of what we publish is government data such as crime reports, restaurant inspections, building permits, business licenses…and even local movie filmings. Much of this stuff either is buried in “deep Web” government databases or has never before been available online. A second part of what we do is detecting addresses and locations in news articles and blog entries. Plus, we pull in various other geographic Web stuff like Flickr photos and Yelp reviews.

All in all, our goal is to show you recent, geographically relevant stuff that you might not have heard about. Say the local newspaper wrote something about your neighborhood on page B-23 — would you really have noticed that article? Say there was an aggravated assault on your block — would you really have remembered to check your police department’s crime-reports Web site on a daily basis? That’s the basic philosophy.

Regarding our custom mapping engine…Let’s face it: Google Maps is so passe. As one of the original Google Maps mashup guys (I developed chicagocrime.org by reverse-engineering Google’s JavaScript, before the API was released), I have all the respect in the world for what Google has done to invigorate the world of Web maps. But it’s time to take the next step. The Google Maps API doesn’t give you any control over the colors of the map tiles, or change the fonts in street labels, or disable building footprints, or hide one-way street markers or subway stations or bus stops or any of the other stuff that’s essentially hard-coded in the map. So, at EveryBlock, we rolled our own maps so we could have much, much more fine-grained control over all of these things. Not to mention it’s a great way to differentiate ourselves from the 2.5 million boring, same-old-yellow-blue-orange Google Maps mashups out there.

Paul Smith from the EveryBlock team has written an article at A List Apart with more of the technical specifics.

Shabda: As per the Knight grant rules, you would be releasing the code for Everyblock next year. Would you not be giving away your secret sauce? How do you plan to maintain competitive advantage once that code is freely avaliable under a permissive license?

Adrian: Our competitive advantage is that we’re an incredible team, and I’m sure we’ll come up with a way to feed our families.

Shabda: What problems would you like Django to tackle after 1.0? What big features would you be most interested in having in Django, after it hits 1.0?

Adrian: Generally I’d like to add higher and higher levels of abstraction to the framework. The Django admin application is a good example of that – it’s not just an abstraction of an HTTP request; it’s an abstraction of an entire Web application! We should do more of those.

Shabda: What is one thing about Django which you absolutely love, and one thing which you think Django should do differently?

Adrian: I love the way URLconfs work — like a table of contents for your Web app. I also love template inheritance. I don’t love the fact that we’re generally slow in keeping up with tickets and feature requests.

Shabda: A lot of people these days have to evaluate between Django and ROR. How can they make this decision? When should Adrian Holovaty use ROR? When should DHH use Django?

Adrian: My answer is simple: Try out both frameworks and see which one you like better.

Shabda: Does Django need to market itself differently? What can Django community do for this?

Adrian: I’m comfortable with the amount of attention (or lack thereof, depending on your perspective) that our project gets. I’m comfortable with the size of the community. I’m comfortable with the fact that the right people have found out about it through word of mouth, books, blogs, Google App Engine or wherever else. If things continue at their current rate, we’ll continue to do just fine, as a healthy open-source project.

The one thing I’d ask the community to do is to continue staying civil, polite and approachable.

Shabda: What does the phrase ‘journalism via computer programming’ mean? How can these two divergent fields be tied together?

Adrian: “Journalism via computer programming,” in my opinion, is when a journalist writes code to tell a story. Instead of talking on the phone with sources to gather facts, this could involve screen-scraping Web sites to gather raw data. Instead of writing a newspaper article, this could involve building a database-driven Web site.

Journalism has several subdisciplines — photography, information graphics, video. I advocate that computer programming should be another one of those subdisciplines. Just as a newspaper employs photographers and graphic artists, it should employ programmers who help gather information and tell stories with it.

Shabda: How can traditional journalists do more ‘journalism via computer programming’? How can programmers do more ‘journalism via computer programming’? Is it easier for Programmers to move to this field, or for Journalists?

Adrian: I believe it’s easier for programmers to become journalists than it is for journalists to become programmers, but both sides need to gain an appreciation for the other in order for this sort of thing to happen more often. Fortunately, some news organizations are starting to hire developers with this in mind, and some geeks are realizing journalism is a great, (mostly) pure field that lets you improve the world through information.

One concrete thing programmers can do is to look for jobs at news organizations, which desperately need technical talent. Developers, you will be loved, you will be treated like geniuses, and your non-techie coworkers will be very easily impressed!

Another route programmers can take is to get training in journalism – in fact, Northwestern University’s journalism school is giving out full-tuition scholarships for programmers who want to learn journalism.

Shabda: Thanks Adrian.

This was Adrian’s interview, the last in django-interviews series. But we have a lot of interesting things coming up, so stay tuned.

Jacob Kaplan-Moss is the co-creator of Django along with Adrian Holovaty, as well as the author of the Django Book. He has been involved with Django since before it was called Django. He is currently employed at Whiskey Media where his job is hacking at Django. He blogs on Jacobian.org. He graciously agreed to be interviewed at the 42topics blog.

Shabda: Would you tell a little about yourself? How did you get started with Django? What other software/applications have you worked with. (Both OSS and otherwise)?

Jacob: So a bit about me: I grew up in Silicon Valley, so like many other geeks I got started with computers really early; I was programming professionally before I graduated high school. I didn’t start out doing web development; in college I worked on video surveillance systems for airports, harbors, marinas, and highways. That’s where I found Python: I rewrote a Java-based camera controller in Python and haven’t looked back since. I started doing web development pretty seriously when I moved to New York and took a job for a design firm there. The job was pretty terrible, and the technologies were worse: the good sites were PHP, and there was a bunch of WebLogic crap that was absolute hell to maintain.
So in 2004 I saw the job opening that Simon and Adrian posted on their blogs — and jumped on it. Web development in Python seemed like a dream job, and it really was. So that’s how I ended up in Kansas working for the local paper. At that point I suppose I was using Django, though we didn’t have a name for it yet: we just called it “The CMS”.
I’d been getting more into Open Source all along, though I’d barely contributed (I think I got a single line into Python at one point years ago — that was my largest contribution).

Shabda: What areas of Django have you worked most in? What are you current areas of focus?

Jacob: Well, at this point I’ve touched pretty much every part of Django at some point weather in the form of improvements, refactoring, or just small patches and bug fixes. I’m far from an expert in any particular area, though, so I’d say my main role is more holistic: I’m most concerned with making sure that Django “feels” correct and that APIs and conventions match across the framework.
Right now my current focus is documentation: I’ve been working on improving the structure and organization of the documentation so that it’s easier to find what you’re looking for. We’ve got something like 40,000 lines of documentation so organization and metadata is critical.
Now that I’m lucky enough to get to work on Django at work, I’ll probably be able to take on some more big tasks like that in the future.

Shabda: One of the most loved things about Django is its comprehensive documentation. What is the motivation behind refactoring this? What is going to be the new organization? How is this progressing?

Jacob: Thanks — I’ve always thought that Django’s documentation set us apart from most Open Source projects, and I’ve been really proud of what we’ve done there. However, over the past year or so as the size of the documentation (and Django itself) grew I think we’ve slipped from “outstanding” to merely “above average.” To us (the core maintainers and I) that’s not acceptable.
The best place to read up on the project and goals is in a post I made to Django-dev a couple of months ago. In a nutshell, I’m breaking up the documentation into smaller, more manageable chunks — the current DB API is almost sixty printed pages! I’m also separating more high-level how-to’s and topical guides from the detailed API references that get in the way when you’re just learning.
There’s some tool improvements going on under the hood that’ll make the documentation easier to write, edit, maintain, and contribute to; hopefully that’ll help decrease the number of undocumented features.
The work’s pretty close to done, actually. I was trying to finish before I went on vacation a month ago, but didn’t quite get there. So that means I need to roll in a month’s worth of documentation improvements that happened to the current docs while I was gone, but that shouldn’t take much time. You can expect to see the new docs rolled out online very soon.

Shabda: What does Whiskey Media, the startup you are currently associated with do? Is your role there developing Django, or are you associated with other day to day activities as well?

Jacob: I think I’ll have to be a bit coy and not say very much about Whiskey Media; we’d rather let our actions speak for themselves than try to build some sort of artificial hype. I’ll just say that we’re trying to solve some of the big problems in web publishing; you can probably see why Django’s the best technical bet for a company trying to be the on the cutting edge of content publishing.
Most of my time at Whiskey is devoted to working on Django — coding, but also community management, evangelism, and organization. I also have some internal responsibilities, of course, but those are more nebulous: mostly I just help out wherever I’m needed.

Shabda: As you said “we’d rather let our actions speak for themselves than try to build some sort of artificial hype”. Do you see Django taking a potential hit in marketing due to similar belief of Django community? Does Django need to market itself differently than it has been doing till now? What can Django community do for this?

Jacob: Huh, that’s a tricky one. Well, let me break down the question a bit and look at a few different angles.
So first, I’ve always been a bit uncomfortable with the idea — pervasive in Open Source — that this is some sort of popularity contest. People are always comparing traffic figures, or numbers of job postings, or numbers of Google results, or whatever. I think the idea’s supposed to be that if Project Foo has more users than Project Bar that Foo somehow “wins”. But I don’t see it that way at all.
I mean, I moved from New York City to Lawrence, KS. New York City has a population of, what, 8 million or so? Lawrence has a population of around 80,000. Does that mean New York City is “better”? To most of those 8 million, sure… but to me? Hell no.
As in most areas, there’s no accounting for taste: one of my good friends here in Lawrence is a die-hard Perl fan, and though it makes him a bit twisted it doesn’t mean that I’m somehow “better” than him — we just have different needs and different ways of thinking.
All that said, though, there is undeniably a value in popularity.
Only a tiny number of people who use a given piece of Open Source software become involved in the community, and only a tiny fraction of those contribute back to the project, and only a tiny fraction of those contributors become long-term committers. So more users translates directly to more contributors, and more contributors brings more “value” to the project.
(By “value” I’m referring to code, good ideas, etc.)
So as you can probably tell this is something we struggle with. On one hand I think Django’s great, and it’s in the project’s best interest to persuade others to give it a shot. But on the other hand there’s a huge amount of bullshitting that goes on where software is concerned, and I try my best to not add to the pile.
It’s hard to tell when you’ve crossed the line from evangelism to hype, and hype can be toxic. Witness the recent backlash against Ruby on Rails: do you think they’d get such violent vitriol if they’d been more modest in their promotion?

Shabda: Talking of ROR, a lot of people these days have to evaluate between Django and ROR. What questions should they ask themselves to answer this question? (Well apart from “do you know Python better or Ruby better?”). To make this more interesting when would YOU choose ROR over Django, if you knew both Ruby and Python equally well?

Jacob: So first let me back up a step — I’ll answer directly in a moment — and make a quick point about web development in general. The past couple-three years have seen a radical improvement in the quality of tools available to web developers. It really wasn’t that long ago that CGI represented the state-of-the-art in web development.
Today, though, there’s really some fantastic tools available. Rails, Django, Symfony, Pylons, TurboGears, Seaside… any of these tools represent a major improvement over the CGI/PHP model of web development. If you’re still writing web sites the way you did five years ago, you’re missing out.
When it comes to which of these tools to choose, of course, we’re back to that question of taste. Each tool comes from a different world, and has a different “attitude” towards web development. The cool part, though, is that most new web development tools emphasize a quick start as a key feature: you could probably evaluate a dozen web development frameworks in just a couple of days. So my best advice is to to try a few and see what “clicks”.
It’s probably important to also pay attention to the language that the framework uses. One of the real pleasures of writing Django apps is that you get to take advantage of the awesome Python community. I’ve got a set of libraries in Python that I can’t imagine developing web apps without; many of those libraries don’t have analogues in any other environment.
So if I knew Python and Ruby equally well — I don’t — I’d still probably lean towards Python, and towards Django. However, there’s one place I can think of where Rails is far superior: Rails runs on the JVM. This is a big deal: there’s any number of large corporate environments where the JVM is the only game in town. And obviously if I had to choose between Java and Ruby I’d choose Ruby!
I’ll mention, though, that Jython (Python on the JVM) is improving by leaps and bounds, and that getting Django working perfectly on the JVM is one of the Google Summer of Code projects the Jython team is sponsoring.

Shabda: Coming back to the marketing question.. For most of non hackers choosing the framework to use is a big question, and the decision they will make depend on various non-tech factors, such as availability of capable skilled people. You mentioned that you would choose Django over Rails due to the awesome Python libraries. For the long term survival and growth of Django, do you not think that an early capture of mindshare in developer community is important? For example I have pitched Django to a fair number of people, and I always have to start with “Django, what?” as compared to “Yeah, we are evaluating Rails for our requirements.”

Jacob: Sure, there’s definitely a value of having Django be familiar to your friendly local Pointy Haired Boss, so in that context a certain amount of advertising is important. There’s nothing worse than being forced by management to use the wrong tool for the job. Keep in mind, though, that this cuts both ways: I’d feel pretty unhappy if there was a team using Django because someone read about it in CTO Monthly. I’d agree that we could be doing more in terms of “brand awareness” or something, but all in all I’m pretty happy with the size and quality of Django’s community.

Shabda: There is not much information about the early days of Django, so a little about that. How did the move at WorldOnline from PHP to Python happen? Why did you create a new framework, instead of reusing something like Zope?

Jacob: I wasn’t yet at World Online when we moved from PHP to Python, but from what I understand it was a pretty typical change. Adrian and Simon got fed up with the pain and suffering wrought by PHP, and wanted something cleaner and — most importantly — something that would be easy to maintain. Python really shines here.
The main reason we ended up building our own framework was that we didn’t know we were building a framework. We just wanted to “build cool shit” and, over time, we built tools to help us do that. It wasn’t until we started showing it off that we realized we had something that could be used by other people.
This, by the way, is one of the reasons I think Django turned out so great. If you sit down one day and say, “I’m going to develop a framework!” you’re almost certainly going to become an Architecture Astronaut, and if you ever actually finish the thing’ll be so over designed nobody will want to use it. If, on the other hand, you simply try to solve real-world problems in a clean, obvious way, you’ll eventually end up with a great tool.
Look at Rails, TurboGears, even PHP; they all started as simple libraries written by frustrated programmers just trying to get the job done.

Shabda: What are the overarching goals of Django? Again to make this more interesting, Here is a quote from you. “My work as a core developer of Django focuses on giving anyone — even (especially) non-programmers — the tools to create dynamic, content-driven websites.” Should not that be the job of something like Wordpress, while Django should aim to give “programmers, but not non-programmers — the tools to create dynamic, content-driven websites.”

Jacob: Wordpress is great if you want to publish a blog, but what if you want a website to track a book collection, or sell tickets to concerts, or organize a local farmer’s market? There’s a great deal that Wordpress (and other single-purpose tools) can do, but the amazing thing about the web is just how wide-open the possibilities are. There’s a whole world of possibilities out there, and the end-goal is to help anyone self-publish anything they can dream up.
One of the most fascinating aspects of the history of communication is how intertwined literacy is with social controls. For most of the history of humankind, literacy was strictly available to the elite. The Web created the greatest democratization of publishing ability in history, and has almost immediately turned into a battleground between traditional, centralized publishing and decentralized democratic publishing.
As a programmer, we don’t personally play much of a role in this sea change, but I do see the lowering of the barrier to self-publishing as something we ought to continuously think about.

Shabda: If Django’s goal is “and the end-goal is to help anyone self-publish “, does not that mean Django is trying to fill the niche of an Extensible CMS like Drupal, as compared to filling the gap left by PHP? Are non programmers really using Django, or are they using apps built with Django?

Jacob: No, you’re right that Django’s lower-level than something like Drupal. Django’s not trying to be a CMS but to be a tool you could use to build your own CMS. It’s easier to design your own content models than to shoehorn your publishing into a CMS limited by the ideas of its developers.
There are indeed quite a few non-programmers using Django, though in the long run I think the interesting trend is that more and more computer users are learning a little bit of programming — enough to develop a site with Django, say.

Shabda: (Since I ask this to everyone!) What is one thing about Django which you absolutely love, and one thing which you think Django should do differently?

Jacob: I only get to choose one thing I love?
I think my favorite bit of Django is the URLconf system. I love that Django forces me to think about URL design as part of my application instead of some byproduct; I’ve always hated web tools that try to someone pretend that you’re writing a desktop app. I’ll admit to obsession over my URL design from time-to-time, but I really enjoy clean, semantic URLs.
As for something we should do differently: the assumption that you’ll only use a single database is a bad one, and needs to be fixed. Unfortunately, it’s an assumption that we made really early on, which means that fixing it is going to be tricky. There’s some smart people working on it right now so I’ve got high hopes, but I wish we’d not made that assumption to begin with.

Shabda: Django started as a in house project and was later open sourced. At your current startup your major job is with Django itself. The Django book which you wrote was released under a permissive license. How difficult is it to convince people outside the hacker culture of the business value of open source? What are the best ways to do this? How difficult was doing this at World online?

Jacob: These days, thankfully, the business value of Open Source is pretty well-established. There really hasn’t been a lot of “convincing” necessary. For example, Apress didn’t just agree to release the Django Book under a permissive license: they actively encouraged it. You’d have to ask them if it was “worth it” in terms of sales, but I’m sure that being the first Google hit for “django book” didn’t hurt!
Releasing Django at World Online is actually an interesting story. We decided at the 2005 PyCon that we should Open Source some of our software, and started building a business case for doing so. We prepared a series of arguments — open source will increase our visibility and lead to easier sales and easier hiring, open source will improve the quality of our software, etc. — and took them to our management. All of those things turnned out to be true, by the way, but o our surprise, the argument that was the most effective was actually a “moral” one. We talked about how Open Source had helped our business (Apache, Linux, Python, etc.) and argued that it was time to “give back” to the community. The World Company has always been a company that’s tried to be a conscientious part of our local community here in Lawrence, and they really jumped at the chance to participate in the global Open Source community.
I like to tell this story, by the way, because it really makes me hopeful that this “hacker culture” is in fact compatible with business culture. Fact is that most businesses are in fact concerned with doing the “right thing” — they just often don’t know what that is when it comes to technology. Of course the business case for Open Source needs to be there, too — and it is — but I think there are a lot of companies that’ll jump on the chance to “give back.”

Shabda: Before we close would you like to share any tips with us? Jacob: If you don’t read the Django community aggregator you really should: there are some incredibly smart people blogging about Django and you’ll learn something new from all of them.

This was the interview of Jacob Kaplan-Moss. We have a few more Django interviews coming, before we close this series of Django interviews, so stay tuned.

The five things I hate about * meme seems have died down, and memes, should not be allowed to die.

Of course I love Django, and have bet very heavily on it. But we do not know a topic, until we know it warts, so here you go. The listing is in no particular order, so sorry no numbering.

Ajax with Django is hard:

Most of the Django Community has decided that bundling Javascript helpers with a python framework is bad idea. Though I can understand the reasoning, (argued here and rebuttal), that Javascript is so basic that you can not be expected to not know it, I can not agree with it. SQL is as basic as Javascript, and yet we have ORM for abstracting away the common and the tedious.

Of Course, with simplejson, and a good Javascript library, you can build Ajax apps fast and with only a minimal amout of fuss. And yet switching between Python and Javascript, twice every hour is a huge time drain. Eg. I put commas after the last element in Python arrays, with JS this would work in FF, but fail with weird errors in IE.

Lack of identity map:

If you get the same row from the DB twice using Model.objects.get, you will get two different objects. Apart from the performance problems of two DB queries, when only one should have done, when you update one of them, the other does not get updated, and you will have interesting things happening in your application. And if you update both of them, you might write two inconsistent changes to the DB.

Look at this code for example.

Whether Sessions are browser length/persistent are set sitewide:

You can set whether you want sessions to be browser length/persistent using SESSION_EXPIRE_AT_BROWSER_CLOSE in settings.py. But you can not set them per user, without mucking with django internal. This might seem a minor annoyance, yet this is something which you need to do for every app, as the remember me, function will not work without this.

Newforms is very limited:

Let us say you want the Form to contain a varible number of fields. How can you define the NewForms class to do your biddings.

This can only create a form with a fixed number of fields. While there are ways to generate forms with variable number of fields, (generate the Form class programatically), they are not easy or well documented. (Remind me to write such tutorial sometime.)

Bonus question: How can you generate a form with same form elements multiple (and variable number) times, ala what happens with edit_inline?

Settings mixes application configuration which should be public and passwords, which should be private:

If I am distributing an app MIDDLEWARE_CLASSES is something which I would assume users would not (generally) modify. Similarly, in most of the cases, INSTALLED_APPS, would also be something which users would not change, (unless you are distributing standalone_apps). This means, I want to source control settings.py. But settings.py also contain my DB setiings, and SECRET_KEY, which means, I cannot source control settings.py.

And while we are at it, can we refactor settings.py, so it works without

Bonus:

Two things which used to bug me but no more. 1. You cannot extend Models - Well now you can if you use queryset-refactor, or soon can if you are on trunc. 2. Url configuration using regexes. - Now they have two problems. joke notwithstanding, mapping URLs to views is one problem where regexes fit the problem beautifully. With less that 50 lines of code, you can manage a large number of views, and Url patterns.

Now stay tuned for Five things I love about Django

I wrote a new tutorial on building a search engine using Appengine, and Yahoo Search API here. This uses pure Appengine API, and not Django, and is a tutorial on how to use Appengine without Django.

With launch of Google Appengine, there has never been a better time to start a startup. Let not the lack of a business plan or a pitch hold you back. Go to our web 2.0 startup pitch generator, and get your own, custom, startup pitch. Hurry only 24192 available.

The original source for this was written by Nathan and was in Perl. Of course we needed a web2.0 logo for such a marvelous piece of code. This comes from web2.0 logo generator.

The source for this is available here

I have posted two Tutorials for Using Django with Appengine.

• For people who do not know Django
• For people who already know Django see what we build in this tutorial

And here a few good links about the topic.

• James Bennet tells exactly why Appengine and Django are not so good together.
• Ian Bicking has an interesting take on how Appengine can change the economics of Python hosting.
• The guys at Joyent reading my mind on why I or you can not deploy any production site on Appengine. (Hint. you mean I can never move away, without writing half my code?)

We are hard at work building 42topics.com, and are looking at the best places to deploy this. So when I heard about Appengine, with out of box Django support(gasp!) I was delighted. After using it for a day, and posting a tutorial, I am so disappointed.

Peeves in no particular order.

• Appengine is a very constrained environment, so out goes any chance to run background jobs.
• The ORM-API is very similar to Django, but yet the Django API is much better. modelobj.filter('attr =', value1).filter('attr2 =', value2) or modelobj.filter(attr = value1, attr2 = value2). Putting entity level operations on modelobj.manager is much cleaner that making them classmethods, as argued here.
• Very half baked documentation. Releasing without sufficient testing on windows. If you follow the Getting started guide, and are on windows, I hope you like debugging regexes
• NO JOINS? Ok so I can use obj.master to simlute this. Umm can I get GROUP BY? What about UNION? Admittedly Bigtable is not relational, but are you telling me Google built all their search without a way to simulate GROUP BY.
• PDB does not work on dev server. With Django’s dev server, I put breakpoints with PDB all the time, and it works perfectly. With Appengine devserver, pdb will give you BDBQuit exceptions. I hope you enjoy debugging by reading logfiles.
• Modules used by django are empty.
• You can not start a dbshell on the dev server. (And django-admin framework does not work). When I am coding, I write the data insertion views first, and then the other views. Whether the Insert views are working or not can be checked immediately, from the db shell, or from admin. Here until I write the other views, I can not check on my create view.

The other flaws I can live with, but a dbshell not working and pdb breakpoints raising exceptions make this unusable for me. I guess I will stick with Django on a normal web host, and look at EC2, when we really need to scale.

Google launched their EC2 competitor, Appengine yesterday, and all hell broke loose. And in about 24 hours, the 10,000 accounts were used up. Currently it is tied to only working with python, and Django 0.96.1 works out of the box.

The Good

• Python powered. Django works out of the box.
• No sysadmining chores.
• Promise of infinite scalability with no configuration. (Ah!)
• Free for now.

The Bad

• Python powered, if you want to use ruby/java/php, sorry you are out of luck.
• Your code is tied to Google. You might be able to reuse most of your code, but the DB/ORM sepcific code, ah you are out of luck. And if you are building database backed websites, well most of your most complex code talk to ORM.
• Too magical. Explicit is better than implicit. On the dev server I do not know where my data is stored. If I change the data model, the changed models are available immediately. But well, how do you do it?
• Free for now, and no way to pay for when your usage out grows the free quota limits.