This version of Vestibule is read only. It represents an archive of the community effort to produce content for Ruby Manor 4.

Sleeping with the enemy

This proposal by <a href="/users/georgebrock">George Brocklehurst</a> has been chosen by the community to be given at Ruby Manor 4.

updated over 7 years ago; latest suggestion over 7 years ago

In this talk we'll go off the Rails and take a look at what our Pythonista cousins are doing with Django. Why talk about Python at a Ruby conference? Seeing another way of doing things forces us to think about what we're doing, challenges or validates the assumptions we make about our work, and inspires us to try new things.

I'll start by showing the building blocks of a basic Django blog application to give a quick tour of how a Django app fits together. This won't involve any live coding, instead I'll use a carefully prepared Git repository to show how the app is built in two or three steps.

Once we have set the stage, I'll use the demo application to talk about some of the design decisions in Django and how they compare to Rails. I'll be focusing on the places I think Django has made better choices than Rails, because that's where we can learn the most. You'll see convention over configuration in places you didn't expect it, why Django doesn't need attr_accessible or strong parameters, how the template method pattern could change your life, and a lot of significant whitespace.

I'll point to a few examples of Rails gems that have Django-like properties, but the main aim of the talk is to see some unfamiliar ideas and think a little bit differently.


  • The proposal author responds over 7 years ago

    Thanks for all the feedback, I've updated the proposal:

    • The live coding is dead, I'll pull a Blue Peter instead and just say “here's one I made earlier”. There's not a lot of code, and with no typing it should be pretty quick to get through the concepts.
    • I've clarified my goals, and which areas I'll be focusing on.

    @jbsf: You're right that there's been a lot of cross pollination before. I considered rolling it into the talk, but given that I'm already trying to cover a lot I didn't want to add another section (even if it was a small one).

  • 6597b956887bfa6066bd08be263a08ca Joel Chippindale suggests over 7 years ago

    Another possible approach to demo'ing the code is to have a partner in crime making changes to code while you narrate, although as already mentioned this may only have an advantage over 'something I made earlier' if you plan to respond in some way to the audience with respect to the code you show

  • 3c9da486f4ab709c368fdde6596c480a jbsf suggests over 7 years ago

    Are you going to mention some of the cross-pollination that's already taken place between Rails and Python/Django? For example, EventMachine and Rack? There's a healthy history of sleeping with the enemy. A quick look back and a longer look forward could be interesting.

  • 11364e09c2ea04444314e94eead06e98 Roland Swingler suggests over 7 years ago

    Think this would be interesting, especially if you focus on the areas where you think django "beats" rails and so give us all ideas to go off and implement.

  • B68ce3695bb8dc29b9f9cb0dc0b721a5 Murray Steele suggests over 7 years ago

    I think the structure of the talk you outline sounds fine, I'm wondering about how you're going to end it. Is the plan to show us how Django is different and leave us to think about that ourselves, or to take some time to show us (perhaps only the beginnings of) ruby/rails implementations of how it does things?

    Regarding the live coding aspect, I think it sounds like a good way to introduce Django (although you might want to condense it as 15 minutes is about half the time you have available). Even with practice and the cheating you've described I think you could go one step further. DHH's "15 minute blog demo" is a video, there's no reason your Django version can't be one too. That way you can concentrate on the narration of what's going on, and why it's different rather than typing. I've left some suggestions on this other proposal that might help you out.

  • The proposal author responds over 7 years ago

    I definitely agree that live coding is risky, and I've updated the proposal with some of the ways I could cheat.

    The app demonstration is definitely important though: Rails and Django are sufficiently different that it's worth spending time on demonstrating Django, otherwise the feature comparisons will lack context. It's also easier to understand code in an unfamiliar language and framework if you see it built up in simple steps, rather than just being presented with the finished product.

  • 2f46d76f0e5db4dc318b03be07ebaac4 Tom Ward suggests over 7 years ago

    I'd love to know more about the choices made by Django vs rails. I think my concerns echo those of James Adam. I like seeing code but I've seen a lot of presentations get bogged down in confusing live-coding demonstrations where there has been too little rehearsal or preparation. Coding in front of an audience is much harder than one might imagine. Be prepared to both practise and cheat to make sure the liveness doesn't get in the way of the actual content.

  • Acd62030df551952268e84c8fff26a5b James Adam suggests over 7 years ago

    Do you think it will take 15 minutes to recreate the blog demo, or will it be faster in Django? Do you plan on live-coding it? One minor concern is that while live-coding can be fun, it often takes a bit more time than a more prepared/recorded demonstration. I think it would be worth maximising the time spent highlighting and exploring the different design decisions, if there's any tradeoff to be made.

    I think this is a really interesting idea though - I'd love to see this presentation.