Python Users Netherlands

published Feb 16, 2012

PUN meeting 15 February 2012.

The Python Users Netherlands (PUN) meeting on Wednesday 15 February 2012 was organized by Maykin Media in Amsterdam.

Remko Wendt, Maykin Media: Logging with Logbook

(I missed the first part as I was buying books at the nearby American Book Center, related to the ABC Treehouse where this PUN meeting is hosted; they sponsor this location.)

Logbook is a handy alternative to the standard logging module.

It is easier to disable debug logging and make it hardly take any time, contrary to the standard debug logging.

You can define a MailHandler that mails you at most 3 times per 5 minutes for the same error.

FingersCrossedHandler: only output debug level info when there is a problem .

You can use Logbook in combination with Sentry. This gathers log messages from several applications in one place, with statistics. See http://www.getsentry.com

See the Logbook documentation.

Sylvain Viollon, Infrae: Good and bad code

[Hurray: Sylvain is wearing an Emacs shirt. :-)]

I do open source because I want to reuse existing code: code that works, that helps me build my project. For me good code is reliable code. Professionally I want a high quality application that works for my customer.

Bad code is code that I can't reuse, because it is broken or it doesn't do what it claims to do.

Writing good code is writing code that works and fits my needs. Publish your code on PyPI so I can use it. Test your code, verify that it works in real life, under real conditions. Do not write tests only to get 100 percent test coverage. Handle errors and test them. Write code that is easy to test.

Respect the standards that are applicable to your application, for example the WSGI standards. Be polite to other parts of the system that you interact with. Actually look at the standards, instead of just guessing what will be the correct way.

Don't write fantasy code, code for hypothetical use cases that are never actually used. Keep it simple. Refactor your code later if needed.

Write documentation. Write simple documentation to get started. For me, doctest is not good enough for simple documentation. Maintain a changelog that is easy to find.

Listen to your users, so they can use your code. Update your code to make it usable by them or delegate that role to someone who wants to do it. Or better: make your code extensible so your users can be independent of you and continue development without you needing to watch it or spend time on it. Use dictionaries instead of if-statements [not sure how that would look, Maurits]. Create setuptools entry points. Use the Zope Component Architecture (which in essence is a nested dictionary). Do not EVER hardcode anything.

Audience:

  • Remco: be iterative; start small and release it. Your package does not have to be perfect the first time around and contain everything. Do not let doubts about how good your code is hold you back.
  • Good code is code that does just one thing, instead of a package that does eight things out of which just one thing is relevant for me.
  • Use PEP8, please.
  • Make easy tasks easy and make hard tasks possible.
  • If I can choose between code hosted on Launchpad and code hosted on github, I choose github.
  • 100 percent test coverage is still better than 80 percent test coverage. Sylvain: sure, but your 100 percent may have tested that your code can correctly divide 2 by 2, but you may still miss the more important corner case of dividing by zero.
  • If you write documentation but do not keep it up to date, you should be shot.

Reinout van Rees, Nelen en Schuurmans: Laptop setup: explicit automation

Do not just fool around. Collect everything. It it is not version controlled, it does not exist. I have my stuff on github: https://github.com/reinout/tools

There is a directory with some tiny shell scripts that probably each save four of five seconds of work per time (e.g. editignores.sh: svn propedit svn:ignore .). Also python scripts.

Symlink your dotfiles (.bashrc, .pypirc, etc): pip install dotfiles. Separate: ~/.emacs.d: Google for the starter kit.

I have a lot of packages on github, bitbucket, pypi, etc. But my dotfiles? Maybe not. I use a private repository on an own Linux box, like ssh://vanrees.org/~/git/Dotfiles, ssh://vanrees.org/hg/preken. (Yes, I do need to have my ssh key somewhere.)

I counted: I have 31 git, 22 subversion and 9 mercurial checkouts. I use checkoutmanager so I do not have to do git pull, svn up, etc in each directory. Also, checkoutmanager out checks if I have changes that are committed but not yet pushed to the central server. It's on PyPI and bitbucket: http://pypi.python.org/pypi/checkoutmanager

Backups. You should automate this, too. I have mail that is coming in on an own server and is automatically copied to gmail. Use git/hg/svn. Use the Time Machine when you are on the Apple Mac. Synchronize with Ubuntu One. Backup your own server when you have it, for example with backupninja.

Write a blog entry on your setup, so you can Google it the next time you need it.

You can also put a gpg encrypted file with secrets (passwords) somewhere in a version control system.