Dutch Python Web Meetup 21 March 2013

Orne Brocaar - Job-Runner

Job-Runner is a product we built inside Spil. I am a freelance Python/Django web application developer. I am currently working for Spil Games, a gaming company in Hilversum, about 70 people working there, about 50 gaming portals worldwide.

I am working within the data warehouse team. We gather data from internal and external sources, like analytics data, game related data. We convert this into a Data Vault and Data Mart model, where we can analyze it so we can understand our users. We create reports to inform the business. The data is imported into the staging area (database), then the data warehouse, then we go to reporting, analysis, recommendations. These are all jobs that need to be performed in order.

Before Job-Runner this was all scheduled by cron. If one job failed, the follow-up jobs would fail too. There was no good overview of running, completed and failed jobs, hard to quickly see what (if anything) went wrong. Cron could start a new job if the previous long-running job was still running. Not good.

Job-Runner is a centralized dashboard, an admin interface, a broadcaster for jobs, a RESTful interface. Then there are decentralized workers (job-runner-worker), and a centralized WebSocket server (job-runner-ws-service). Those two communicate with Job-Runner.

The dashboard is HTTP, the queue broadcaster is ZeroMQ.

A project has a job template, for example a python snippet with some variables that are filled in. A job is created from this template. The job is executed in a worker pool. The job may run multiple times, for example once every day. You can also start it manually from the dashboard.

Job-Runner is a Django project, with TastyPie for the RESTful interface. There is a long running management command (the publisher), called broadcast_queue. The worker subscribes to this publisher. It publishes events to ZeroMQ. gevent handles the event queue. The WS Server is a simple proxy between ZeroMQ and the WebSocket server.

We started in December last year. We looked around for other solutions, but they did not fit our needs. The authentication system of Django worked nicely for us. You can setup notification e-mail addresses for a job or pool. Via the admin interface you can schedule jobs at a specific time. If a previous job run has not finished yet, the new job instance will not yet be started.

We have used this for hundreds or even tens of thousands of jobs. We only have one normal cronjob left.

The documentation is at http://job-runner.readthedocs.org

Personal website: http://www.brocaar.com

Jan-Jaap Driessen - Sentry

I work at Mind District. We set up Sentry in our web stack, because we don't want to hunt around for stuff in lots of logs on several servers.

Tip: use UDP for sending the logs to the central server.

We have used this in Python, but are now also using it in javascript, as simple as this:

MD.logging.warn('bar');

Inspired by Strophe. We have a few lines of code for that. Ask me. We also use log4javascript, which is 128 kB and that is minified. In development you want to use the console, but in deployment you want to use Sentry. The code uses Raven to capture the logged message and send the message to the Sentry server.

The WSGI integration is in Zope3, let me know if you are interested.

Diederik van der Boor - 10 things to take care of when Open Sourcing your package

For example django-fluent-pages, developed by me.

• License: do not use the GPL, but the BSD or the Apache license, otherwise you cut your project off from other Python community modules. [For the record: I do not agree with this. Maurits]
• Please provide a README with a reason for using your project. Maybe a screenshot.
• A changelog please. I don't want to look at github commits to check if my bug got fixed in a specific version.
• Documentation. For example on http://readthedocs.org. Look into sphinx.ext.autodoc for automatically generating documentation from your code. Also graphviz and intersphinx.
• Add tests. A runtests.py that is enough to run your tests without needing to setup anything is a good idea. Look into Travis for automatically running tests on a server. tox is good for running tests locally.
• Use the communication channels. Keep people updated. Have a website, with documentation.
• Please provide an example project, so people can easily see how it works.
• Create a good setup.py.

See my github account: https://github.com/edoburu

I count eight things, not ten, so I apparently missed two. Well, two points from the audience follow.

Audience:

• If you start losing interest in your project, look for someone who can take over, preferably someone who has already created some pull requests. Also give people commit access to your repository if they have made some good pull requests.
• Upload your distributions to PyPI, not your own small server. And leave all versions online, otherwise some people will be very annoyed as they are using it on their live site.

Eric - Two Scoops of Django

Daniel Greenfeld and Audrey Roy are writing a book on best practices for Django development. It is in beta, but you can already buy it. It is very good, so please do. The beta is 14 dollars and then you get the final version for free.

Get it at https://django.2scoops.org

Jan Murre - Webapp2

I am active with Python, Zope, Plone, Django, since 1999. I am currently working for a company in Utrecht and before that Pareto.

Webapp2 is a lightweight Python web application framework. It is compatible with webapp, its predecessor, which is the original Google App Engine framework. Webapp2 has several improvements, for example better URI routing and WebOb. See the webapp2_extras package for more stuff. Google has adopted it since GAE SDK 1.6.0.

It has WSGI integration. You can choose your templating language: Jinja2, Mako, etcetera. Forms: wtform, formish, etcetera. Persistence: for AppEngine there is BigTable. Stand-alone you can again use whatever you like: SQLAlchemy, some noSQL, etc. Use a WSGI container, like uWSGI, mod_wsgi, paste. So you pick and choose your own stuff on top of the micro framework.

Google App Engine is Platform As A Service (PAAS). You upload your application there. Comparable in that respect with Heroku. Easy to build, easy to maintain, scales and load-balances automatically, you pay for what you are using. There are several quotas and limits. For some applications we only have to pay the minimum of two dollars a week for the professional version. There is also a free version, with low limits for bandwidth, memory. Languages supported are Python, Java, Go (experimental). BigTable is a noSQL storage, with queries, sorting, transaction, caching built in. URL fetching. E-mailing. There are task queues (think: Celery). Scheduled tasks (think: cron).

You start the application with a simple, plain text yaml configuration. Of course I use Buildout to setup my local development environment, where you have some local storage. The recipe to use is rod.recipe.appengine.

There are other Python (micro) frameworks that you can look at, for example Flask, Pyramid. You can use those on the Google App Engine too, but it takes a bit more setup.

Conclusions for Webapp2: small, but nice. Quite some batteries included. Good routing engine. Plays nice with Google App Engine.

Together with someone else I created http://mijnvoetbaltrainer.nl that uses this, in combination with Amazon for hosting the video material.

More info on webapp2: http://webapp-improved.appspot.com

Pepijn Vos - Pygments, ctags

Pygments: code colorizer. Ctags: allows you to jump to a definition of some code. You can combine that. I did that in spelunking. You can use it to browse github repositories and click around in it. It downloads the repository and runs Pygments and ctags on it and makes it available.

Code: https://github.com/pepijndevos/spelunking

Demo server: http://raspi.pepijndevos.nl

Jan-Jaap Driessen - video conferencing

We have built some cool stuff for health care professionals who visit other people. It can be handy to do this via video communication. We did not base this on Skype, but on Google video conferencing. http://videmo.minddistrict.com There was a SOAP api that we had to interact with. If you have to do that, you should use suds. Using bosh, jabber, xmpp on the server. You can use it simply with an Android phone, no need to buy special hardware.