Dutch django meetup (feb 2016) summaries¶

Dutch django meetup revival - Erik Romijn¶

Sponsored by http://byte.nl, organized by the Dutch django association (django vereniging). The association was founded to organize the 2011 Django Europ conference. They’re also behind the “django under the hood” conferences.

They’re also supporting django girls workshops and even Python Namibia 2015.

If you want to become a member, mail bestuur@djangovereniging.nl

If you want to help with future meetups, contact him!

Migrating nu.nl to Django - Besma Mcharek-Boussif¶

Besma works for Sanoma, the company behind http://www.nu.nl/, a very big news site in the Netherlands. The real title of the talk is “nu.nl performance and our journey in the django realm”. She’s a django backend developer. She’s also a co-organizer of PyLadies meetings.

Nu.nl is the biggest Dutch news platform. 10^9 pageviews per day. They specialize on getting the news online fastest. Mobile and desktop web sites plus mobile apps (ios, android and windows) for tablets, phones and smart watches.

There’s now an ios team, an android team and a web/API and a CMS team. The API is also used by the mobile apps, btw.

Regarding development: they try to use a devops mind set. It is almost continuous integration. About 10 developers. You should be able to work on any part of the system. Development tools: jira, bamboo, hipchat. Monitoring is done with GA and New Relic.

The architecture is divided in layers. CMS, API, frontend. You of course always have to keep them in mind. Editors use the CMS (content management system) to enter content into the database. The database is used by the API (with a cache in front) to feed content to the mobile apps and the website. The website has its own cache.

The web/API team has three kinds of output:

• Serving static pages for the main website.

• Push notifications for big news.

• Serve the raw data for certain API users (for use by third parties to use in hospital news monitors, for instance).

Past/present/future: the whole stack used to be written in php. Development and maintenance was by an external party. Not a good idea, especially when the traffic became crazy.

Currently most of the stack is in django, developed and maintained by the their own team. Only the CMS (for the editors) is still made in PHP.

Future: trying to get all of the stack in django, especially the CMS part. Also to get also this part of the stack in-house.

The site is made using a block layout. Business and editors decide on the layout. Editors supply the blocks with content The resulting layout is served to the web front-end and to mobile.

There are still challenges in the current setup: scale, speed and API errors. “Scale” means “big news items so lots and lots and lots of people come to the site”. How do they deal with this?

• Django security.

• Django rest framework as data provider.

• Lots of cache servers (mostly Varnish).

• Rigorous testing (also manual). Especially the API is almost fully unit-tested. If there is a bug, she writes a test. Period. She doesn’t accept new functionality without tests.

Recently they had a performance sprint:

• Updated python to 2.7 (their hosting party sadly only supported 2.6, originally).

• Updated from apache to nginx.

• Disabled django.views.static.serve.

• Using “serpy” as the API’s serializer. They found it to be faster than Django Rest Framework’s default one.

One of the biggest future challenges is to add more personalisation. This means pages are no longer static, which means a performance problem. Also the API will have to be changed.

Djangocon Europe - Baptiste Mispelon¶

He’s the chair of the upcoming Budapest Djangocon Europe. The tickets are almost sold out, so if you want to go, be quick! They can also still use sponsors.

Django Girls Den Haag - Martin Matusiak¶

The python community is well-known for being friendly and cozy.

Sometimes when working on a shitty piece of software with lots of dirty legacy, you yearn for a nice codebase. The python community is that nice codebase. We’re in a good shape. We’re a nice, comfortable community to be around.

A django girls workshop is aimed to take non-programmers (especially woman as they’re under-represented) and existing developers (as mentors) and help the women to learn to program and learn to love to program.

Lots of people show up because they want to learn what their colleagues do. Others look for a career change.

“What comes out of a workshop” is programmers. Beginning programmers. And also mentors for them! Also for the more advanced programmers it is interesting as you can learn to mentor people. Being a coach is quite relaxing, btw.

The interest for the upcoming meeting in The Hague is overwhelming. 100 applications when there’s only room for 60!

They hope it’ll be organized in more cities. In the Netherlands it is regularly organized in Groningen and Amsterdam.

If you want to organize it: there is a ready-made organization manual!

(Note to self: my daughter wants to learn python programming with three of her classmates…)

Djavascript that doesn’t make you cry - Sergei Maertens¶

Sergei works at Maykin Media as a backend developer. (The presentation is online on github, btw).

The most used javascript version is ecmascript 5.1 from June 2011. Ecmascript 6 (“ES6”) came out in June 2015, but not everything supports it yet.

Some problems that make you cry in javascript (the 5.1 version):

• Global scope polution.

• Loading/bundlign files. django-compressor/django-pipeline help here. But it is another thing to set up maintain in your project.

• Unit testing.

• Most will do jquery development. Jquery isn’t javascript.

ES6 features that’ll make you happy:

• Proper modules. import $ from 'jquery';

• To make something available to other modules, you have to explicitly export it and import it in another. This solves the polution and file-loading issues.

• Native classes! Object oriented programming is now more within reach. It is mostly syntactic sugar around the existing prototypical inheritance, but ok.

• Async javascript. You can already use callbacks (the nodejs way, “callback hell”). Or promises (now finalized in ES6). And coroutines (very much like asyncio from Python).

  Promises will either return a response or an exception. There is no other possibility. You call something (which you call a promise) and then call “then” on it. When the promise-handler is finished, it’ll return and execute what’s in the .then().

  Remember to catch exceptions, as they’ll be eaten quietly and suppressed. Bah.

• Arrow functions. Basically something that looks like a python list comprehension.

• New let and const var-like keywords. let is more limited, it limits the scope of the variable to the current loop, for instance. const is meant not to be changed. Browsers don’t really support that yet, though.

• Template strings. Hello ${world.name}

• A useful full list of ES6 features: https://github.com/lukehoban/es6features

A recommended tool: JSPM/Systemjs, see http://jspm.io/ . (“Do we need a new javascript package manager? Yes!”) It handles transpiling ES6 to ES5. It handles bundling. It is customizable by overriding package.json. It loads ES6 modules, commonjs, AMD, all in one codebase: you can use three styles of imports in one codebase.

Now… how do we use it with django? With Sergei’s own django-systemjs, of course :-) It integrates with django’s template language. It handle both DEBUG = True mode and production setups. It has a python manage.py systemjs_bundle management command.

He showed something from ponyjs (https://github.com/ponyorm/pony). It is a model layer aimed at Django Rest Framework. It uses ES6 and its Promises.