Python Users Netherlands

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.

Erik Romijn, Solidlinks: Making awesome apps with Open Data

Apps for Amsterdam, Apps for Noord-Holland. Last week I won the third prize in Apps for the Netherlands with an app.

What is open data? Our goverments have tons of data. Sometimes they just publish that data for free, without restrictions (as long as it is not private info of course). Data can be eighty videos about cars travelling over ice, or places where you can hook the line of your boat, or numbers about gas or electricity meters, water levels, data sets about where you can charge your electric car, Nijmegen has a register on valuable trees.

Data is available at http://data.overheid.nl/ Launched September last year.

Why should you work with open data? It is like crude oil, money just sitting on the ground waiting for someone to pick it up. You can enrich your existing apps with knowledge about the surrondings. What if your TomTom could say: "You are speeding. The intersection you are nearing saw ten deadly accidents last year." Or as Mr. T. would say: "You are a fool!"

How do you make an awesome open data app? Create awesome visualizations. Do innovative things with it. Make it exciting. Be socially relevant: e.g. show significance of solar panels. http://10000scholen.nl shows you information about schools, helping you find a good school for your children.

There is a contest. Build an awesome app, submit it for free, you may win a prize and win a seat at the main contest. On average one in three apps win.

Challenges with using open data. I do not want to scare you away, but have you be a bit more prepared. Some data needs a high level of domain knowledge. Data may be in different formats: csv, json, xml, shapefile. You may need to access it with SOAP, HTTP, FTP. Most of it is live, so it has an API. Locations: 'rijksdriehoekscoördinaten' in the Netherlands is based on a spot in a farmfield in France, or on a church tower in Amersfoort, so that may not be what you expect. The data is all in Dutch and there are no plans to change this.

After the contest, you should make your app durable. Talk to data owners about how you use it; they like that and are usually impressed. Yes, it is the government, so gettings things done may happen slowly.

How do you earn money with your apps? There was 40,000 euro in prizes awarded in apps for Amsterdam, Northern-Holland and The Netherlands. Open data usually makes no restrictions on money that you make on it. Usually the government is just happy that someone is using the data and they don't have to create an app themselves. You are free to use any business model that you like. You keep all rights. Also, it is free publicity.

If we making more awesome apps, we make it more attractive for the government to add more data.

The United Kingdom is further here. Usually the data format is different. So building the same app for similar data from two countries is hard.