Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Practical Django Projects

Posted by samzenpus on Wed Jul 23, 2008 01:30 PM
from the read-all-about-it dept.
Chromodromic writes "Apress's newest Django offering, Practical Django Projects by James Bennett, weighs in lightly at 224 pages of actual tutorial content, but trust me, they're dense pages. Filled with pragmatic examples which directly address the kinds of development issues you will encounter when first starting out with Django, this book makes an important addition to the aspiring Django developer's reference shelf. In particular, the book's emphasis on demonstrating best practices while building complete projects does an excellent job of accelerating an understanding of Django's most powerful features — in a realistic, pragmatic setting — and which a developer will be able to leverage in very short order." Read below for the rest of Greg's review.
This book serves an important function by providing progressive, useful examples of Django's role in the development of realistic projects. During the course of the tutorial you build three basic apps: A simple brochureware-oriented CMS, a complete blogging system (with Akismet spam protection and RSS feeds, among other features), and a social code-sharing site similar to that found at djangosnippets.org (with account signups, syntax highlighting via pygments, and bookmarking features — the whole enchilada). You may or may not find these projects immediately relevant to your work or goals, but the projects themselves are really just platforms for delving into Django's nooks and general philosophy. It's an important point to make about the book especially, because though Django itself provides potent facilities for creating reusable code while preserving a high degree of flexibility, "magic" is kept to a minimum compared to some other popular frameworks. It follows that maximizing your knowledge of Django's inner workings through familiar paradigms is critical to making the framework perform to your best advantage. The book excels at accomplishing this goal.

Along these lines, a lot of territory is covered in a short span. You're introduced to a couple of Django's contrib apps — code which comes with a normal Django installation and which cleanly plugs into your own application while remaining extremely customizable. After being ushered through a straightforward installation and database configuration, your first exposure to development is through the contrib app most frequently lauded in the Djangoverse, Django's deservedly well known admin system. But immediately, emphasis is shifted from the basic features of the system to the ways it can be customized. This approach of introducing a feature and then modifying or extending it is repeated immediately with Django's Flatpages contrib app, a very basic CMS which, again, comes with Django and installs with a single line of code and one command.

By the time you've finished the third chapter, you've built the foundation of a typical brochureware site, complete with a working search system and a completely functional customized admin with which you may modify your content using a javascript-based HTML editor (TinyMCE). Pretty impressive for 41 fast-moving pages.

The strongest feature of the book, though, is not the speed or facility with which features are presented, but rather the way these features are always demonstrated with a mind to Django's strongest argument: how easy it is to create reusable code, once you understand the framework's approach. As you move through the next four chapters of building the blogging system, the establish-modify-extend technique of presentation does a good job of working you through various standard Django features — generic views (a very important concept which is illuminated nicely), code organization, ORM techniques, template inheritance, and so forth — and you're smoothly shown the ways by which you will be able to incorporate much of the code you write into your future work. As you begin your last project, the code-sharing app, you've gotten an overview of both coding and workflow techniques which work best with Django. The final chapters reinforce everything you've learned while still introducing new material on library integration, form handling and the newforms library, and code distribution.

The overall approach is very effective, though I found I had to trust the tutorial a little at first in order to get the most out of it. The projects initially seemed somewhat vanilla, so it wasn't until I really focused on the organization of the material that I discovered the book's strengths. Now I wish I'd had this book years ago.

Issues? I had only one, really. The material presents itself as a tutorial suitable for those who are just starting out with Python. For example, near the beginning of the material the def keywork is pointed out as the way Python functions are declared, and similar kinds of notes and comments pepper the tutorial, somewhat unevenly, as well. While I appreciate the impulse to make the material as accessible as possible, I'm skeptical of the book's role as truly introductory at that level, although I could see some experienced developers, especially those coming from other languages, benefiting from these quick notes. But my feeling in general would be that if you're so new to Python that the def keyword is a revelation, you might be better off starting elsewhere before you dive into Django.

This is a minor point, though, and if you're willing to give the material the time, you'll appreciate what Django has to offer more and more with every page. The book maintains a brisk pace which I truly appreciated. And if you've struggled with Django in the past, or you've wanted to learn more about what to do beyond getting the admin running, "Practical Django Projects" is an excellent foundation for your Django education. I absolutely recommend this as the Django book I've found to be, by far, the most useful.

You can purchase Practical Django Projects from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by Illbay (700081) on Wednesday July 23 2008, @01:33PM (#24308653) Journal
    Here's a BUNCH of 'em! [djangobooks.com]
  • by SnarfQuest (469614) on Wednesday July 23 2008, @01:40PM (#24308753)

    What's django? Hardware? Software? Language? The fine article doesn't really clue me in.

    Should I imagine a beowulf cluster of these? Praise our new django masters? Profit? Or pour hot grits into my pants?

    • Re:Stupid question (Score:5, Informative)

      by StonedRat (837378) on Wednesday July 23 2008, @01:45PM (#24308849) Homepage Journal

      A web framework written in Python. And it's better than Rails.

      • Re:Stupid question (Score:5, Informative)

        by morgan_greywolf (835522) * <morgan_greywolf@ ... m ['rr.' in gap]> on Wednesday July 23 2008, @01:58PM (#24309067) Homepage Journal
        And why is Django [djangoproject.com] better than Rails? Well, for one it uses Python (obviously). But, in addition, it has:
        • An object-relational mapper so you don't have to write SQL. But you can still use SQL if needed;
        • Automatic admin interfaces. You never need to write another stinkin' admin interface again.
        • It's own template language. Althouh, you can use any other template language you want.
        • Support for memcached caches is built-in.
        • Built in support for i18n and l10n.

        Oh, yeah. And building Django apps is FAST.

        • Everytime a new framework or web development system gets hyped I can't but wonder why people get so excited about having reinvented the wheel, and a wonky one at that.

          Everything you mentioned in your post has been solved for many, many years already. Just use Perl and the Template Toolkit. Or one of the mature frameworks (Catalyst, Mason) if you hang that way.

          It is fast, stable and mature and gets the job done with little development time. Sure, it isn't the latest hype. But do you care? Should you care? If

          • by Anonymous Coward on Wednesday July 23 2008, @02:48PM (#24309775)

            I have some experience using mod_perl & Django in mod_python. Django provides much that perl does not, and I love writing perl for backend utilities and CGI.

            Django templates do not allow the scriptlet mentality of others like JSP & mod_perl. They have a short list of commands, a loop, an IF-statement, and some text filters. This forces users to separate computation (in perl/python code) from display (in the template). The template takes a dictionary of named (keyed ) objects and prints the fields.

            Django has an Object-Relational Model built-in to the system. Programmers write a models.py module full of ORM classes. Then, the Django utilities build SQL database tables to match the models. The Django Object-Relational Model has no equal so far as I've seen.

            Django enforces the MVC web application. Most other web frameworks let the bad habits creep in.

              • by ubernostrum (219442) on Thursday July 24 2008, @12:11AM (#24314987) Homepage

                All of the features that you list seem to be about limiting the options of the programmers rather than extending the capabilities of the base language.

                Devoid of context, yes, I can see that.

                In context, however, not so much. Consider Django's built-in template system (which you don't have to use, btw; most people do because it leads to easier interoperability with arbitrary applications, but you're free to drop in whatever you like -- it's just Python code on the backend); most people instinctively get upset when they find out that it isn't just the host programming language embedded into HTML (a la PHP, ERB, "classic" ASP, etc.). But I've found that it's extremely rare for me to have a need for such a thing, and when I do the template system is extensible from the Python side, so I can implement what I need and get on with life. A good example I ran into the other night while helping someone debug: he was doing a product-review site where each product had a government-issued safety rating, from one to five stars. What he wanted was basically a way to say something like:

                {% if product.safety_rating > 3 %}This product has a high safety rating.{% endif %}

                (the curly-brace constructs are how Django's template language delimits certain constructs, such as conditionals, loop expressions, etc.)

                Now, you can't actually do this: arbitrary Python expressions like product.safety_rating > 3 aren't supported by the language. What he ended up doing was moving this logic into a method on the object representing products, so it became if product.has_high_safety_rating instead. For most cases in most applications, this is a better option (it's more reusable, and leads to easier maintenance since you don't have magic numbers hard-coded everywhere). And for times when you need it, you can dip down to the Python level and extend whatever syntax you need into the template system (one night I sat down and implemented a bunch of comparison expressions; it took about five minutes).

                The parent comment you're responding to is also slightly incorrect on a few points; for example, Django doesn't "enforce" MVC in any particular way and actually deviates from it in some ways that made sense for the Web (e.g., the concept of the controller really has no place in most web applications, since there's only a single channel for interaction with the app: HTTP). All Django cares about is that for each URL you want to handle, you provide a callable object which accepts an HTTP request as its first argument and returns an HTTP response. Beyond that, the sky's the limit. Django also doesn't force you to use its ORM; several of the bundled applications in django.contrib make use of it (since, if you've got Django installed, they can rely on the ORM being available), but nobody says you have to use it in your apps.

          • Re: (Score:3, Informative)

            It's generally fascinating to watch people not grasp the fundamentally different world-view of a relational database with an object-oriented system.
            It's the difference between a warehouse and retail floor, yeah, you can blur things somewhat with a Costco or Sam's Club, but the ideas of how things are managed between a warehouse full of boxed bicycles and a bikeshed full of them is substantially different.
            The joy of watching someone take an .xsd and map it directly to a set of tables, with foreign keys to
      • Re: (Score:3, Interesting)

        "And it's better than Rails."

        Then where are the Django killer apps? No seriously, where are they? I can't find more than a hand full of Django apps. And when I asked this question on #django and #python, multiple times, nobody - not even a single person - could tell me even one killer app written in Django. If Django is so great then where are the apps?

        • Re:Stupid question (Score:4, Insightful)

          by Teilo (91279) on Wednesday July 23 2008, @06:42PM (#24312711) Homepage

          I will add to my above post, that in Django, it is very easy to extend / override almost any part of the framework. Within a week of using it, I was writing my own custom HTML widgets, compound data fields, and even custom added support for custom DB column types. Now, I know that ActiveRecord allows you to do some of these things, but it's not at all easy or intuitive.

          But, hey, if you love Ruby, use Rails.

          The thing everyone has to remember about Django vs. Rails, is that this is really more a Python vs. Ruby debate. The nature of the languages has affected the design of the corresponding framework in dramatic ways.

          That said, I think that, if Rails were done all over again, it could learn a lot from Django.

          Check out Snakes and Rubies [djangoproject.com]. (Google video version [google.com].) It was a pair of presentations on Django and Rails. Good stuff. This was in December of 2005. Yeah, Django's been around for a while, despite the comments about it being a "young" framework.

    • Re:Stupid question (Score:5, Informative)

      by discord5 (798235) on Wednesday July 23 2008, @01:47PM (#24308875)

      What's django?

      I'm sure this'll upset someone, but it's rails for python. Django Project Homepage [djangoproject.com]

      It's pretty neat and in a couple of evenings reading and experimenting you'll have figured most of it out (even if you're new to python).

      I've used it for a few personal projects, but not at work yet so I don't have any experience with it on larger projects. Still, it's pretty neat to get something done quickly.

    • by Kingrames (858416) on Wednesday July 23 2008, @01:52PM (#24308967)

      Boba Fett's dad.

    • Only a day ago I would have been asking the same question. I have been a long time Java Developer and decided to trying deploying an application to the Google App Engine. Unfortunately, for me at least, only Python is supported so I have been forced to take a deeper look into Python.

      The Google App Engine already has the Django libraries available. It's seems like a pretty useful template system, however I really wish they had chosen to use xml tags instead of parenthesis tags so that native xml tools, ev
      • Re: (Score:3, Informative)

        pylint [logilab.org]. It has some annoying style checks that I often disable, but is good at finding unused and undeclared variables and that sort of stuff.

      • Re: (Score:3, Informative)

        by imbaczek (690596)
        there are tools like pychecker [sourceforge.net], they help quite a bit. junit is right there in the standard library of python, see docs for the unittest module; there's also the doctest module for simple cases.
      • by Vornzog (409419) on Wednesday July 23 2008, @03:02PM (#24309977)

        The Google App Engine already has the Django libraries available.

        Have a little care, there. The GAE caused quite a stir in the Django community, because it is only a partial implementation of the database interface that Django normally uses. It is backed by BigTable, which is blazing fast, but not a full blown relational database. If that works for you, go for it - it looks like a sweet platform for certain kinds of projects.

        As for your question about Java->Python, I'm a former C++ convert myself, but I can help a little here. For some 'compile time' checking, look at PyLint [logilab.org] It may check too much for you, but you can turn off the stuff you don't want.

        As for unit testing, PyUnit [sourceforge.net] is a pretty straight port of JUnit, so that should look familiar. However, I actually find nose [somethingaboutorange.com] to be a little better. It has many of the same capabilities, but with less boilerplate needed, and it integrates well with any existing PyUnit or DocTest [python.org] tests.

        • Just wanted to say thanks for the links and information. I'll be sure to read the Python documentation more, but it's always helpful to get some advice. Cheers.
    • Re: (Score:3, Funny)

      That django ate your baby.
  • I must be getting old. Never heard of this before, so the article was confusion at first. For info: http://en.wikipedia.org/wiki/Django_(web_framework) [wikipedia.org]
  • by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Wednesday July 23 2008, @01:48PM (#24308891) Homepage Journal

    I'm getting ready to port a fairly large web app from Zope to either Django or Turbogears (easier development, more scalable for us, etc.). From what I've heard, Django is kind of the Ruby On Rails of the Python world, and while outstanding for writing small mostly-read apps, it's not the greatest for large interactive applications. Conversely, Turbogears seems to have the reputation for a higher initial learning curve and startup cost, but better interactivity.

    Any thoughts on the matter? I've used Django for some small projects and my experience kind of mirrored what I'd read: it's brilliant when you want to work with it, and a complete PITA when you're trying to do something unexpected. I haven't written anything with Turbogears yet so I can't personally compare them.

    No, I'm not going to make my decision solely on the opinions of Slashdot. Consider this the start of my research, not the end. :-)

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      Why not keep the application in Zope? You'll have the ability to better fine tune the application from Zope if the application is truly large. if the issue is it's written in Zope 2, you might as well fix it for Zope 3. Django/TG more scalable than Zope? No. In fact you've more limitations with Django, but only because of how restrictive the ORM can be in certain situations.

      • by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Wednesday July 23 2008, @02:04PM (#24309167) Homepage Journal

        My company is moving toward using a unified codebase for our applications. Whether you're viewing an invoice in a desktop app or on the web, it's calling the same function (written in Python, using SQLAlchemy). Every time I've looked at using code in the filesystem from Zope, it's been overly complicated and problematic. Right now we use External Methods to make specific functions available inside Zope, but the side effect of that is that we have to restart the Zope process every time we want to run new code.

        Another problem is that a lot of our pages take a long time to generate - think reports that take a minute or so. Because Zope is so minimally threaded, that means that other page views are delayed until those reports are finished. We use a pool of 8 Zope instances connecting to a Zeo server, with Apache sending queries to random instances to balance the load a bit. It's still too common for a use trying to view the front page to accidentally get queued up behind another using running "Financials 2004" and cursing at a blank screen until that report is done.

        Add those together and you get an environment where most development is done over Webdav and is consequently a lot harder to manage with version control, 8 giant server processes are splitting the load, and changing a line of code can require a complete restart of the whole mess.

        Yeah, we're ready to migrate.

        • Why not just run the heavy reports in a separate instance or on a separate machine? That way reporting won't cause standard transactional traffic to be queued up behind it, but without any more than a day of time investment.

          And, if I may add my two cents, might it not be easier to code a wrapper around External Methods that abstracts the complicated elements of loading code from the file system, and that is able to dynamically load new methods from the file system (or check for changes)? And even if yo
          • Well, by the time I was done with all that, I'd basically be reimplementing a different framework. With Django or Turbogears, I can let Apache spawn off as many child processes as it needs and not worry if a few of them are running slowly.

            Sometimes we make quite a few changes during the day, or more specifically, we'd like to make more changes but can't easily because of the architecture we're up against.

            Here's how I explained it to my boss:

            Zope is an excellent product and it was absolutely the right choic

      • by dedazo (737510)

        In my experience, Zope is overkill in most situations. And I (personally) have never liked ZODB at all.

    • by VGPowerlord (621254) on Wednesday July 23 2008, @02:21PM (#24309401) Homepage

      The biggest problem I have with Django is that it was created with newspapers in mind and that sometimes causes problems, particularly in the model.

      For example, the FileField isn't friendly for organizing things by users... the upload directory is fixed in the model, and it only takes strftime arguments if you want dynamic subdirectories... and for whatever reason, there is no move method in the FileField model. I have no use for files sorted by time, as this system is user-driven.

      Which means you need to manually move the file and update the FileField's value in the model, in addition to doing checks to make sure you don't try to move one file over another. (Note: I haven't tried this, I just assume it works, as the FileField is just a varchar(100) / CharField(max_length=100).)

      Oh, and I don't know how Django internally handles <input type="file">, or I'd say to just use a CharField.

      • That's exactly the kind of stuff that had me wringing my hands. Our site involves a lot of data entry, like allowing customers to enter complex invoice information. I've heard that Turbogears is a lot better about that stuff because it doesn't make as many assumptions on your behalf, which conversely means that you have to make them yourself.

      • Why do you need the files in specific directories? Can't the app figure out which file belongs to which user?
        • And I really cannot see why the implementation of the FileField is in anyway newspaper related???

          Because news stories are usually sorted by date, so it makes sense that files and images (ImageField inherits from FileField) are sorted by date as well.

  • by gorbachev (512743) on Wednesday July 23 2008, @01:53PM (#24308991) Homepage

    I just got a newsletter about a sale at Bookpool.com for APress books. APress books are 45% off until 8/31.

    This particular book is $5 cheaper at Bookpool.com than Amazon right now.

  • by Eberlin (570874) on Wednesday July 23 2008, @01:59PM (#24309087) Homepage
    SPOILER ALERT!!!

    Storm Dtroopers were imperfect clones of Django.

    Dboba is a perfect clone of Django.

    If you want to stop the Django process, you have to su to Windu and kill -9 Django

    If you're looking for Dboba, try this command: cat \dev\sarlac | grep Mandalorian

  • Django n00b (Score:5, Informative)

    by spaceyhackerlady (462530) on Wednesday July 23 2008, @02:05PM (#24309179)

    I recently had a look at web application frameworks for some new development and ended up doing it with Django.

    I find it handy. It's logically put together, the Python back end is fast, and, once you figure out a few basic concepts, you can put web apps together very quickly. The template system is particularly clever. I find that I like to set up my database tables first, then let Django create the model classes. Not the other way around. I also like to do table joins as views in the database, rather than gluing things together in Django. YMMV.

    My last experience with web application development was with Tomcat. I still have nightmares. :-(

    ...laura

  • I'm just finishing up a project with django. It is a lot of fun, quick, and useful. It is very well designed. One issue, however, is that it is still changing rather quickly. Things in version .95 or .96 can be substantially different than the current development version. This isn't unusual for such a young project, and since the documentation is quite clear and useful it's not a problem, but is something you may want to consider before you plunk down your hard-earned cash on a printed book.
    • by ubernostrum (219442) on Wednesday July 23 2008, @02:18PM (#24309351) Homepage

      One issue, however, is that it is still changing rather quickly. Things in version .95 or .96 can be substantially different than the current development version.

      Hi, I'm James and I wrote Practical Django Projects, and I have a confession to make: I cheated while writing the book. You see, I'm also Django's release manager, which meant I had a good idea of what would land in trunk and what would change by the time we went to press. Except for activating/hacking on the admin interface (the admin refactor just landed over the weekend), everything in the book should be up-to-date and usable on the Django 1.0 alpha we released Monday.

      • Cool!

        Thanks for the update.

      • That actually is good to know. The api changes are the main reason I'd be hesitant to buy any book related to django at the moment. I might actually pick this one up now.
  • by LS (57954) on Wednesday July 23 2008, @02:26PM (#24309483) Homepage

    Books about programming, especially internet programming, seem a bit archaic at this point. Or at least physical books. I find that especially with open source languages and tools, and even more so those related to the web, there is a wealth of information online, both in serial book format, tutorials, and searchable references. I haven't used a book to learn a language since Learning Perl back in about 2000. I bought a copy but I ended up using a pirated digital copy anyway because it was more useful...

    LS

    • Re: (Score:3, Interesting)

      by bloobloo (957543)

      I find books invaluable. Perhaps it would be different if I had 2 screens and I could put an editor on one screen and the tutorials on another, but as it stands I find it easier to flip pages to find what I am looking for.

      Unless you're copying code fragments, I don't get the benefit (other than portability) of a soft copy over a hard one.

      • The big advantage of a soft copy of book is being able to do searches for keywords which is invaluable when you don't know which set of terminology the author is using and the index doesn't cover the word or phrase you require.

        Note this is particularly invaluable in API references - particularly with php when you have no clue which daft name php uses for a function, but you are sure that php has function for that job.

  • by bedonnant (958404) on Wednesday July 23 2008, @02:26PM (#24309491) Homepage
    in a flabbergasting coincidence that will leave you all wondering about Fate, i just received my copy of this book today, and was at this very minute beginning to read it. my life has just been slashdotted.
  • Django Jobs (Score:3, Interesting)

    by daeg (828071) on Wednesday July 23 2008, @02:32PM (#24309565)

    We're running Django for basically our entire business systems. It's great. The only downside to Python is that there is a general lack of local developers (Tampa, Florida). Trying to find additional developers when you can't get relocation benefits approved is a royal PITA. (Anyone looking for a job in Tampa? =))

    We're very, very happy with Django.

  • 1.0 Real Soon Now (Score:5, Informative)

    by the_rev_matt (239420) <slashbot@re v m a t t.com> on Wednesday July 23 2008, @02:33PM (#24309577) Homepage

    Note that Django 1.0 is due this fall and it looks to be actually on track. I used Zope for personal and freelance projects for about 9 years and professionally for about 2. I migrated my site and the majority of the content over in about a week, and that included the process of learning django.

    I will note that one of the things I liked about Zope was the admin interface, which was clunky and minimal but a far sight better than what most other app servers had at the time (late 90's/early 00's). Django's is immensely better.

    I've also Read The Fine Book reviewed here and concur with the reviewer. This book is a great introduction to a useful tool.

  • I'm about to start a mid-sized project that I'd like to use a framework for. I'm planning on using the Zend Framework, since I know PHP very well. I do not know Python, but it's very high on my list of languages I'd like to learn (like, number 1).

    Would it be worth my time to learn Python and then do the project in Django? I'm experienced enough in OO and various languages that I don't think Python would take me too long to pick up, but is the learning curve between knowing Python and using Django steep
    • Depends on the project, as usual, but IMHO yes, Django is worth a try. I haven't used Zend though, so YMMV (particularly, I don't know what features you may expect from a framework.)
    • by Balinares (316703) on Wednesday July 23 2008, @03:36PM (#24310501)

      Firstly:

      > I'm planning on using the Zend Framework

      I understand the Zend Framework is not so much a framework as a tight collection of helper tools. If you want a framework, as in, framework, you'll probably want to look into CakePHP. Symfony is more powerful, but also kind of more complicated. (And declaring my models in XML makes my skin crawl -- but it's just me.)

      Secondly:

      > Would it be worth my time to learn Python and then do the project in Django?

      Short answer: If you know PHP really well and it works for you, it'll be less work (and less risk) to just keep using PHP.

      Long answer: If you're a fast learner, and intend to keep using Django afterwards so the overhead of learning it is worth it, then I'd say, absolutely. If I were in your shoes, I believe I would probably create a small functional site in Django in my spare time -- it doesn't take very long at all to get a blog with comments up and running, for instance -- and see how it flies with me. I understand learning Python and Django hand in hand works very fine, although I can't personally comment on that, having been into Python for many years.

      If you go the Django road, you'll probably find these resources handy:

      The Django community aggregator is at http://www.djangoproject.com/community/ [djangoproject.com] and has many good posts with great insight on how to get the best out of your new Django toy.

      The Django Snippets site at http://www.djangosnippets.org/ [djangosnippets.org] is a great catalog of small, useful bits of code. I read it in my RSS aggregator, personally.

      And of course, there's the #django IRC channel, and the various mailing-lists.

      Enjoy exploring Django! I've been following it for a few months already and still don't hate it, and for an old bitter bastard like me, that's the biggest praise.

  • In related news (Score:3, Informative)

    by dedazo (737510) on Wednesday July 23 2008, @02:52PM (#24309843) Journal

    After a loooong time, 1.0 Alpha was just released [djangoproject.com].