Create a blog in 30 mins with Django 1.3 (Screencast) | Hacker News Reader

Create a blog in 30 mins with Django 1.3 (Screencast)

arunrocks.com

47 pointsarocks11 comments

I always like presentations like this. I think most languages really just need screencasts where people show you, "here is how you start using this language." One of my favorites was Ryan Dahl's introduction to Node.js, which had the same general form:

    https://www.youtube.com/watch?v=jo_B4LTHi3I

So thanks for that.

I still don't like Django so much, precisely because of the fact that you're sitting here navigating through these massive config files -- and you even need Django's bundled applications to make those files in the first place. Libraries seem much cleaner to me. I guess what I'm dreaming of is a version of django where this whole talk becomes a little simpler, a sort of cookie-cutter formalism where you just start writing:

    #!/usr/bin/python
    import django
    
    serve = django.server(port=8080, db=('sqlite3', 'mysite.db'))
    serve.url('/admin/.*', django.admin_site())
    
    blog = serve.app(model={
        "some json model": "I don't know exactly how it works"
    })
    serve.url('/blog/.*', blog)

...to accomplish the same thing that you're doing in this talk. I mean, it's okay that applications often get their own folder, but shouldn't they grow into that with import statements?

An open question to HN: are there libraries which do this sort of thing which I should know about?

> sitting here navigating through these massive config files -- and you even need Django's bundled applications to make those files in the first place.

what do you mean??

Just about the second thing he does in that video is to start editing settings.py, where he edits line 14, line 15, line 119, and deletes lines 118, 120, and 121. He then jumps over to urls.py and deletes lines 12, 13, 14, and 15 while uncommenting lines 4, 5, and 16. He makes the observation that he's just going to ignore all of the other crap in settings.py.

That workflow is very particular to a Unix config file. It's, for example, what you have to do if you want to use Tor: you browse slowly through a torrc file that sets every setting with comments explaining what it does, and you uncomment or change these lines depending on what you want to happen.

That's not a bad workflow, but when I'm in a programming language I have a better option: I don't need to think about the world as "here is this monolithic application which I have to configure," but instead I can think, "oh, here are some methods which I might like to use -- methods which make servers listening on sockets with various protocols, and so forth."

The thing about config files is that if you don't embrace the Unix philosophy of "small tool which does one small job well", then the config language can come close to being Turing-complete. But if your config files are Python applications, that's already Turing complete. You don't need to build a new language on top of Python. Why should I be trying to describe in a data structure what my database is? Why make me write a data structure containing 'sqlite3' rather than mydb = django.dbs.sqlite3("filename") ? (There are a couple of reasons, actually -- one of the biggest is that they want to have a 'syncdb' command -- but I'm still not convinced that this is the best way to implement that.)

Django is not a 'monolithic application which I have to configure', but settings are, well, settings - stuff you have to set. Urls.py is routing, you'd have to config it somehow anyway. There is a lot of room of improvement how the settings could be handled in Django to make them more flexible and get rid of that overhead in settings.py and afaik the core team is planning to work on that, but for the moment you take it as it is. Django has a nice learning curve, you get to know how it basically works while writing your first apps, but maybe it's not for you - if you're looking for something raw and lightweight, you can try Flask. If you want a mature framework which solves most use cases for synchronous web programming and you can build powerful stuff on top of that, it's Django.

Try Flask (python web "microframework"), the library approach is pretty close to what you're describing, although not so high level.

The reason you have to start looking in settings.py and urls.py is because you used "django-admin.py startproject". Why would you do that? Probably because it provides a nice and common layout with some sensible default configuration.

But you don't have to use "startproject". Here's an example: http://olifante.blogs.com/covil/2010/04/minimal-django.html

No, I don't recommend you to do that. Use Flask, Bottle or any other lightweight framework/library you want to use. Just don't get hung up on how the Django docs suggests you structure your project. It's all still Python.

You do the configuration once in your life. Then you can just copy your basic template between projects that suits yours style.

I am saddened that this video is not punctuated by the narrator yelling "Whups!" every fifteen seconds.

Didn't the rails "make a blog" video do it in 15 minutes?

Instead of a blog a better example to showcase a web framework would be a wiki, forum or even HN.

Not bashing the OP but tutorials and screencasts like this fail at the first step by teaching the beginner a blog should be dynamically generated.

Tutorials and screencasts like this are a great resource for beginners as an introduction to a new framework. And the "blog" has been the de facto standard web app to showcase the framework. But as developers we should know that web apps like blogs should be statically generated and saying otherwise is setting a bad example to beginning programmers.

Blogs are like the "Hello World" of dynamic web apps. No one is implying that this is where web dev ends at.

Reply on news.ycombinator.com