Skip to content. | Skip to navigation

Personal tools
Log in
Sections
You are here: Home

Latest Plone Posts

Stellungnahme der Antidiskriminierungsstelle des Bundes zur Beförderung von großen Personen bei Airlines

From Planet Plone. Published on Jul 29, 2016.

In einer formlosen Anfrage an die Antidiskriminierungsstelle des Bundes habe ich gefragt, ob es das Zusammenpferchen von großen Personen wie mich (203cm) in der Economy Klasse der meisten Airlines auf dem Platz einer Legehenne rechtlich vereinbar ist und ob sich aus der Körpergrösse ein Anrecht auf eine menschenwürdige Beförderung ableiten lässt. Die Antidiskriminierungsstelle antwortet mit einer interessanten Rechtseinschätzung....

Cross-browser hyphenation support for Plone 5

From Planet Plone. Published on Jul 27, 2016.

Most browsers lack hyphenation support (except Firefox). This Plone 5 add-on brings customizable hyphenation support to Plone 5 e.g. for better readability of the Plone 5 toolbar in German language.

5 Reasons Your Website Needs an Update

From Planet Plone. Published on Jul 26, 2016.

Our countdown of 5 ways to know if your website needs an upgrade.

Plone 5 and XML-Director 2.0 with Dropbox integration

From Planet Plone. Published on Jul 21, 2016.

After many months of pain with Plone 5.0, XML-Director 2.0 will be finally available for production soon. This screencast shows you how to integrated Plone via XML-Director with Dropbox (or other databases or (cloud) storages).

Morepath 0.15 released!

By Martijn Faassen from Planet Plone. Published on Jul 18, 2016.

Today the Morepath developers released Morepath 0.15 (CHANGES).

What is Morepath? Morepath is a Python web framework that is small, easy to learn, extensively documented, and insanely powerful.

This release is a smaller release without big visible changes, or big hood changes. Instead it polishes a lot of stuff. It also continues the trend with contributions from multiple core developers.

This release prepares the way for the next Morepath release. To this end we've deprecated a number of APIs. We are preparing a big change to the underlying Reg predicate dispatch library APIs that should make it less implicit, less magic, and make it perform slightly better. Stay tuned!

collective.recipe.sphinxbuilder buildout recipe works on python 3 now

By Reinout van Rees from Planet Plone. Published on Jul 11, 2016.

I wanted to do a few small tweaks on collective.recipe.sphinxbuilder because it failed to install on python 3. I ended up as maintainer :-) It is now at https://github.com/reinout/collective.recipe.sphinxbuilder .

The only change needed was to tweak the way the readme was read in the setup.py and do a new release. Since then Thomas Khyn added windows support.

The documentation is now on readthedocs: http://collectiverecipesphinxbuilder.readthedocs.io/ . And the package is also tested on travis-ci.org.

Python Meeting Düsseldorf - 2016-07-06

From Planet Plone. Published on Jul 04, 2016.

The following text is in German, since we're announcing a regional user group meeting in Düsseldorf, Germany.

Ankündigung

Das nächste Python Meeting Düsseldorf findet an folgendem Termin statt:

06.07.2016, 18:15 Uhr
Raum 1, 2.OG im Bürgerhaus Stadtteilzentrum Bilk
Düsseldorfer Arcaden, Bachstr. 145, 40217 Düsseldorf


Neuigkeiten

Bereits angemeldete Vorträge

Stefan Richthofer
        "JyNI – Native CPython-Extensions in Jython"

Marc-Andre Lemburg
        "Stand-Alone Applikationen mit eGenix PyRun"

Charlie Clark
        "Eine kurze Einführung in SQLAlchemy: Was es ist und wie man es benutzen kann"

Jens Diemer
        "PyLucid – ein Open Source CMS auf Django Basis"

Weitere Vorträge können gerne noch angemeldet werden. Bei Interesse, bitte unter info@pyddf.de melden.

Startzeit und Ort

Wir treffen uns um 18:15 Uhr im Bürgerhaus in den Düsseldorfer Arcaden.

Das Bürgerhaus teilt sich den Eingang mit dem Schwimmbad und befindet sich an der Seite der Tiefgarageneinfahrt der Düsseldorfer Arcaden.

Über dem Eingang steht ein großes "Schwimm’ in Bilk" Logo. Hinter der Tür direkt links zu den zwei Aufzügen, dann in den 2. Stock hochfahren. Der Eingang zum Raum 1 liegt direkt links, wenn man aus dem Aufzug kommt.

>>> Eingang in Google Street View

Einleitung

Das Python Meeting Düsseldorf ist eine regelmäßige Veranstaltung in Düsseldorf, die sich an Python Begeisterte aus der Region wendet.

Einen guten Überblick über die Vorträge bietet unser PyDDF YouTube-Kanal, auf dem wir Videos der Vorträge nach den Meetings veröffentlichen.

Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld, in Zusammenarbeit mit Clark Consulting & Research, Düsseldorf:

Programm

Das Python Meeting Düsseldorf nutzt eine Mischung aus Open Space und Lightning Talks, wobei die Gewitter bei uns auch schon mal 20 Minuten dauern können :-)

Lightning Talks können vorher angemeldet werden, oder auch spontan während des Treffens eingebracht werden. Ein Beamer mit XGA Auflösung steht zur Verfügung.

Lightning Talk Anmeldung bitte formlos per EMail an info@pyddf.de

Kostenbeteiligung

Das Python Meeting Düsseldorf wird von Python Nutzern für Python Nutzer veranstaltet.

Da Tagungsraum, Beamer, Internet und Getränke Kosten produzieren, bitten wir die Teilnehmer um einen Beitrag in Höhe von EUR 10,00 inkl. 19% Mwst. Schüler und Studenten zahlen EUR 5,00 inkl. 19% Mwst.

Wir möchten alle Teilnehmer bitten, den Betrag in bar mitzubringen.

Anmeldung

Da wir nur für ca. 20 Personen Sitzplätze haben, möchten wir bitten, sich per EMail anzumelden. Damit wird keine Verpflichtung eingegangen. Es erleichtert uns allerdings die Planung.

Meeting Anmeldung bitte formlos per EMail an info@pyddf.de

Weitere Informationen

Weitere Informationen finden Sie auf der Webseite des Meetings:

              http://pyddf.de/

Viel Spaß !

Marc-Andre Lemburg, eGenix.com

The world's simplest Python template engine

From Planet Plone. Published on Jun 30, 2016.

Let's have fun with Python format()

Paypal tracking with Rapido

From Planet Plone. Published on Jun 30, 2016.

A very simple approach for Paypal on Plone

Djangorecipe: easy test coverage reports

By Reinout van Rees from Planet Plone. Published on Jun 30, 2016.

Code coverage reports help you see which parts of your code are still untested. Yes, it doesn't say anything about the quality of your tests, but at the least it tells you which parts of your code have absolute the worst kind of tests: those that are absent :-)

Ned Batchelder's coverage.py is the number one tool in python.

Note: I use buildout instead of pip to set up my projects. Reason: I can integrate extra automation that way. One of those extra automation steps is "djangorecipe": a recipe is a buildout plugin. It installs django, amongst others.

My previous setup

I use nose as a test runner. Easier test discovery was the reason at the time. Python's unittest2 is better at that, so it might be time to re-visit my choice. Especially as I just read that nose isn't really being maintained anymore.

A nice thing about nose is that you can have plugins. coverage.py is a standard plugin. And with django-nose you can easily use nose as a test runner instead of the standard django one. So once I put a few nose-related settings in my setup.cfg, coverage was run automatically every time I ran my tests. Including a quick coverage report.

The setup.cfg:

[nosetests]
cover-package = my_program
with-coverage = 1
cover-erase = 1
cover-html = 1
cover-html-dir = htmlcov

Running it:

$ bin/test
......................................
Name                       Stmts   Miss  Cover   Missing
--------------------------------------------------------
djangorecipe                   0      0   100%
djangorecipe.binscripts       42     16    62%   25, 37-57
djangorecipe.boilerplate       1      0   100%
djangorecipe.recipe          115      0   100%
--------------------------------------------------------
TOTAL                        158     16    90%
----------------------------------------------------------------------
Ran 38 tests in 1.308s

OK

An important point here is that laziness is key. Just running bin/test (or an equivalent command) should run your tests and print out a quick coverage summary.

Note: bin/test is the normal test script if you set up a project with buildout, but it is effectively the same as python manage.py test.

New situation

"New" is relative here. Starting in django 1.7, you cannot use a custom test runner (like django-nose) anymore to automatically run your tests with coverage enabled. The new app initialization mechanism already loads your models.py, for instance, before the test runner gets called. So your models.py shows up as largely untested.

There's a bug report for this for django-nose.

There are basically two solutions. Either you run coverage separately:

$ coverage run python manage.py test
$ coverage report
$ coverage html_report

Ok. Right. You can guess what the prototypical programmer will do instead:

$ python manage.py test

That's easier. But you don't get coverage data.

The second alternative is to use the coverage API and modify your manage.py as shown in one of the answers. This is what I now build into buildout's djangorecipe (version 2.2.1).

bin/test now starts coverage recording before django gets called. It also prints out a report and export xml results (for recording test results in Jenkins, for instance) and html results. The only thing you need to do is to add coverage = true to your buildout config.

The details plus setup examples are in the 2.2.1 documentation.

(An advantage: I can now more easily move from nose to another test runner, if needed).

Not using buildout?

Most people use pip. Those using buildout for django will, I think, really appreciate this new functionality.

Using pip? Well, the basic idea still stands. You can use the call-coverage-API-in-manage.py approach just fine in your manage.py manually. Make it easy for yourself and your colleagues to get automatic coverage summaries!

Eerste Nederlandse Wagtail CMS Sprint

By Coen van der kamp from Planet Plone. Published on Jun 24, 2016.

Wagtail is een Content Management Systeem gebaseerd op Django Framework. Op 16 en 17 juni vond de eerste Nederlandse Wagtail CMS Sprint plaats.

Do You Lose Sleep at Night? Part 1: Why Security Matters

From Planet Plone. Published on Jun 22, 2016.

Slides from Nathan Van Gheem's talk at the Penn State Elements Web Conference, on June 6, 2016

A high availability Django setup on the cheap - Roland van Laar

By Reinout van Rees from Planet Plone. Published on Jun 22, 2016.

(One of the talks at the 22 June 2016 Amsterdam Python meetup)

Roland build an educational website that needed to be high available on a tight budget. He demoed the website. A site for the teacher on his own laptop and a separate page for on the digiboard for the class. The teacher steers the digiboard from his laptop (or an ipad or phone).

As it is used in classrooms, it needs to be really really available. As a teacher, you don't want to have to change your lesson plan at 8:30. The customer hat three goals:

  • Not expensive.
  • Always up.
  • Reliable.

He had some technical goals of his own:

  • Buildable.
  • Functional.
  • Maintainable.

Always up? Django? You have the following challenges, apart from having a bunch of webservers.

  • Media files. Files uploaded on one server need to be visible on others.
  • Websockets.
  • Database.
  • Sessions.

The setup he chose:

  • Front end (html, javascript, images): cloudflare as CDN, content delivery network. The front end is a single page jquery app. It chooses a random API host for ajax requests.

    It changes API hosts when the API is not responding. But.... when is an API not responding? Some schools have really bad internet, so 10 seconds for a request might be "normal".

    Don't make a "ping pong" application that retries all the time. Try every server and then fail.

  • Some Django API servers. The actual django project was easy. Simple models, a bit of djangorestframework. As an extra he used some new postgres features.

  • Two SQL servers in BDR, bi-directional replication, mode. "Postgres async multi master". It is awesome! It just works! Even sessions are replicated faultlessly.

    Things to watch out for: create a separate replication user on both ends. Also watch out with sequences (auto-increment fields). For django it was easy to get working by configuring the database with "USING BDR" when using such IDs. This takes a little bit longer to create such objects. Alternatively you can UUIDs.

    Backups: oopsie. When postgres goes down, you normally restart it and it rebuilds itself. But in a BDR setup, the sequences don't work right then. The standard tools don't work, he had to write a custom script.

    Another drawback. For updating your tables, you need a lock on all database nodes. This means you have downtime. No problem, he'll just do it early on in the morning in a weekend.

  • He uses csync2 for syncing uploaded files between the hosts. Simply a cronjob on all servers. This is good enough as the updates only really happen in the summer; during the school year nothing changes.

  • Websockets. He uses Tornado plus javascript code for reconnecting websockets. Initial connection for the teacher to connect his laptop with the digiboad is via a short 6-digit number. Internally, a UUID is generated. The UUID is stored in local storage, so reloading the page or restarting a laptop Just Works.

The One Time We Were Down: they switched email providers one time because their original one got much more expensive. But the new provider wasn't as good and suddenly calls took more than 10 seconds and clients started to fail. It wasn't that critical as it happened after school time when only one teacher wanted to reset his password. So it was easy to fix.

What are distributed systems? - Quazi Nafiul Islam

By Reinout van Rees from Planet Plone. Published on Jun 22, 2016.

(One of the talks at the 22 June 2016 Amsterdam Python meetup)

Distributed systems?

  • Distributed computation (like hadoop, mapreduce).
  • Distributed storage (like cassandra, riak).
  • Distributed messaging (like kafka).

You need distributed systems if you want to do more than is regulary possible.

With many systems you need things like synchronisation (for instance NTP, network time protocol).

A distributed system is a bunch of computers working together. Such systems have challenges and limitations. Take for instance the CAP theorem for distributed storage systems. You can't have all three of the following three at the same time:

  • Consistency.
  • Availability.
  • Partition tolerance.

You can for instance value availability over consistency. You give the answer as soon as possible, even if you're not completely sure you have the full answer (as other nodes might have extra/newer information).

Python for OPS and platform teams - Pavel Chunyayev

By Reinout van Rees from Planet Plone. Published on Jun 22, 2016.

(One of the talks at the 22 June 2016 Amsterdam Python meetup)

The sub-title of his talk is supporting development teams in their journey to Continuous Delivery. Pavel's job description is continuous delivery architect. He loves biking so he just had to move to Amsterdam :-)

What is continuous delivery? Often you'll hear something like "safely, rapidly and predictably deliver new features to production". But that's a little bit restricted. He likes to start already in the inception and planning stage and only end in the actual operation stage. So the whole process. You don't want to continuously deliver bad features that won't be used. You want to include the inception/planning stage to make sure the right features are implemented.

A core idea is to keep the product releasable: build quality in. That is the core that we ought to remember. Quality is an integral part of the product, it is not something you can tack on later.

So... quality in the entire build/test/release cycle.

  • Build. All the checks you can do. Linting, static code analysis, unit tests.
  • Test. Contract tests, end-to-end testsuites, browser tests, scaling tests.
  • Release. Verify the deploy.

Especially in the "test" phase, you need specific clean test environments. Provision infrastructure, run the tests, dispose of the infrastructure. Repeatability is keys.

"Platform as a service": the real name of every operations team nowadays.

The number of jobs that include configuring servers manually is quickly declining. You need to be a programmer now! You need to enable self-service for the teams you work with.

So: python for system engineers. Python is the best language for this.

  • It is the most popular programming language for devops (apart from bash).
  • It is easy to learn (but hard to master).
  • It is more powerful than bash.
  • You can create and distribute real helper applications.
  • Devops means you're a developer now!

What you need to do: create a provisioning service. A self-service. The developer can just click a button and they have a server! Amazon's AWS was born this way. But these are generic servers. Your company needs custom setups. This is where you come up.

  • Services to manage environment lifecycle.
  • The same way for everyone.
  • Manipulation using API.
  • You can mix and match infrastructure providers.

They build something with python + flask + ansible. Flask recieves API calls, analyzes it and creates an ansible object and fires off ansible. Ready!

Also something to look at: Jenkins pipelines. All the jenkins tasks for one job inside one versionable file. You can apparently even write those in python nowadays (instead of the default "groovy" DSL).

Some further thoughts:

  • Open all the helper tools to the whole organization.
  • Distribute it as docker containers. Both the services and command line tools!
  • As sysadmin, act as a developer. Use the same tools!