Wednesday lightning talks

Tags: django, djangocon, zestreleaser

Jan Lehnhardt: mustache

Mustache is a template language that works in almost every programming language. The programming work is done in the programming language: there’s a clear separation of concerns.

Some examples:



Jan Lehnhardt: CouchDB

You can use CouchDB directly from your browser without a web server! CouchDB uses the REST protocol, so you could put your html in the database and call it directly from the browser.

CouchDB has replication... So you could do a distributed flickr or facebook this way... FAST response times!

Russel Keith-Magee: django is a server side framework

Django is a server side framework, so we don’t do ajax ourselves. But we do have forms and thus widgets. And we don’t really provide good examples on how to use it.

Lots of questions on django-users are “how do I plug in this or that calender widget?”. There are all sorts of snippets lying around ready for using. But it isn’t really pluggable.

Html5 is great and it is going to change the landscape. But we’re not going to support it directly.

What he wants to get going: “Ray’s widget exchange”. It is designed to be a set of applications that explicitly makes client-side decisions. It will include ajax.

There’s already an empty repository. Do what you can. Help out! Code skills, graphical skills, javascript skills.

Ville Säävuori: patches welcome

We’re all contributors to Django, just by being here.

You can contribute in loads of ways. Triage tickets. Answer questions on the mailing list. Write tutorials or documents. It is not just about the code. Arrange local meetups.

Btw: there’s trying to arrange pycon Finland later this year:

Remco Wendt: demoserver management command

A new management command: demoserver. They wanted a simple command for showing a quick demo.

It runs runserver, but beforehand it loads all fixtures called demo_*. And it starts a special middleware which automatically logs you in.

Soon to be released.

Btw: next Dutch django meetup is on 9 June.

Horst Gutmann: Localized documentation

A German documentation translation project started before 1.0 was out. People ask for it. Other languages do it, too.

Problem: translating the whole documentation takes too much time. contributing.txt has 1200 lines of text, that is about a week of work. Combined with all the other documentation it can take a year or so.

  • Do we need everything? “No” Tutorials, howtos and contributing.txt is probably enough. We don’t need the references and detailed release notes.
  • Who maintains it after translating?

Are there alternatives for the documentation? Yes, smaller focused articles. Django advent worked really well.

Lukasz Dobrzanski: Continuous performance testing

See his slides.

You want to see how well your code performs over time. Did a certain commit improve or worsen the performance? We need a simple tool for that. Integrate it with your continuous integration tools and show graphs.

The tool: performatic. Example:

Jacob Kaplan-Moss, Eric Holscher, Idan Gazit: Hidden hires

Hiring in the open source community is different than in most circumstances. A commit count is more important than everything else on a resume for many people. Reputation. tries to connect the best django companies to the best django developers. Some informal reputation-based system. Filter out the best people and companies. It ought to work much better than regular recruiters and regular stacks of resumes.

Konrad Delong: Mockity mock mock, a little love for the mock library

Most people test, some people use a mocking framework.

There are two approaches to mocking. The first: prepare an object that expects a certain behaviour. The other is to have a generic object that remembers everything and then afterwards you ask what happened and check that. is of the second kind.

(He gave a quick demo).

It also contains mocks for stdin! (Note to self: test it!)

Reinout van Rees: zest.releaser

I myself showed zest.releaser, a handy tool for getting rid of all the manual work in releasing a package:

  • Removing the ‘dev’ marker from the version string in your
  • Recording the release date in your changelog.
  • Committing those changes.
  • Tagging the release (svn, hg, git, bzr).
  • Incrementing the version number and adding a ‘dev’ marker (so from 1.0 to 1.1dev).
  • Adding a new header in the changelog.

All that’s done automatically (well, it asks for your permission after showing the changes) by zest.releaser. Many people in the zope/grok/plone community use it, so it ought to work just fine in the Django community too :-)

Oh, and it has 95%+ code coverage.

Jonas Obrist: a quick look at django-cms

People said they missed the high-level overview after the earlier talk about django-cms.

So Jonas gave a demo of :-)

Benny Daon: django gov

Benny started a google group for discussing open government projects and apps.

blog comments powered by Disqus logo

About me

My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.

Weblog feeds

Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):