Reinout van Rees talks about improving your django admin: big gains with little effort, at PyGrunn.

See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.

The admin interface is Django's wrapper around the database. It has lots of possibilities that usually just take a few lines of code for a big improvement.

Three parts: you have the main admin page, a list of objects, and an object edit page.

What I tell you is all in the documentation of the Django admin.

Main admin page:

• In admin.py register all your models so they end up here.
• Give a verbose_name and verbose_name_plural in models.py in the Meta.

List of objects. I usually change these five items:

• Add a __unicode__ method on your model. Otherwise you see Token object as name. Don't make it too long, needing to access five database models for your name.
• Sort order. In your model Meta add something like: ordering = ('name',). Same in your admin model if you need a different order there.
• Columns. In the admin model specify fields to show: list_display = ['name', 'url']. These can also be method names defined in your model.
• Search. Please add a search box in admin: search_fields = ['name', 'url']. For this half minute of work I got lots of praise from colleagues.
• Filters. In the admin add a filter: list_filter = ['portals', 'organisations'].

All these are just one line. If you take over a project, this is a nice way of improving it and at the same time getting to know the database.

Object edit page:

• Order of fields. Default is just the order in which fields are specified in your model. So in your model put them in the right order. In admin you can add fieldsets to group fields, though this is not really one line.
• Specify verbose_name, help_text on the model: looks much nicer in the admin interface.
• readonly_fields in admin.
• Easier selection. You may have a dropdown of four hundred items, hard to select. But you can use a nicer widget: filter_horizantal with list of fields in admin.
• Faster selection. Tens of thousands of related model objects in a dropdown can make it very slow to display. Solution: row_id_fields in admin.
• Inline objects. Edit an object and on this edit page add a different model inline. In the admin define one model as TabularInline and add inlines on the parent admin model.

Others:

• Queryset filtering, to see only items that you have for example edit permission for.
• Are you missing the option to add a model? Then you are missing an admin model.
• You can define actions.

So: you can do various really easy things to make the django admin much nicer.

If you want to give users access to the admin, you can give him staff status and give permissions to view, add, or edit.

Documentation: https://docs.djangoproject.com/en/1.9/ref/contrib/admin/

Twitter: @reinoutvanrees

See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.

For more information about this topic, you can read an article by Oleg titled Factory injection, combining pytest with factory_boy. [I steal code from there, that page is way better if you want the full story.]

What's wrong with testing? It is annoying. You have to setup everything to make it work. Hard to reuse. The tests are written as an afterthought and are usually not very good.

With Behavior Driven Development (BDD) style of tests, it can be this:

Scenario: Dark Helmet vs Lone Star v1

    Given I am your father's brother's nephew's cousin's former roommate

    When So what does that make us?

    Then Absolutely nothing

This is an example of a hard setup, especially the first step is hard to setup. You can split this up into multiple steps.

Gherkin's just-enough specification: specify only the facts that you need to observe.

Dependency injection can be statically declared in the code when you use pytest:

@pytest.fixture
def you(your_father):
        """You can't be created without your father."""
        ...

Parametrization works like this:

@pytest.mark.parametrize("book__price", [Amount("EUR", "15.20")])
@pytest.mark.parametrize(
        ("author__fee_percent", "expected_author_fee"),
        (
                (27, Amount("EUR", "4.104")),
                (12.5, Amount("EUR", "1.9")),
        ),
)
def test_unicode(book, expected_author_fee):
        """Test author fee calculation."""
        assert book.author_fee == expected_author_fee

Factory pattern. Declarative. Factories create objects. factory_boy does this for pytest.

How can you combine factories with dependency injection? Create the minimum number of objects needed in the hierarchy.

The right way to implement fixtures: don't. Let them be generated automatically. Otherwise you need to write more code and you know:

E = m c squared
Errors = more code squared

So: write factories to simplify your tests. Make this so you only need to specify what you are interested in testing. Stop writing test setup code.

Future:

• auto-generated base factories for ORM models (alchemyboy)
• standard BDD Given steps (Given model attr is X)

Documentation: http://pytest-factoryboy.readthedocs.io/

At PayLogic I started porting tests to this. It really saves a lot of code. My colleagues are using it too. Some like it. :-)

Make the factories easy for most of the cases, not necessarily for corner cases.

pytest can run unittest test cases and also nose test cases, it is quite universal.

Twitter: @olegpidsadnyi

See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.

I went from Python to Clojure and back.

I am a Pythonista since 2006 and went away for a few years. This is not a very technical talk. I will talk about how I used Python, how I got disillusioned, how I switched to Clojure, and how I understood that Python still has good points and I went back to it.

I came from a C++ background, and started with Python 2.3. I was missing decorators, decimal, generator expressions. You could do crazy things like this:

None = False
assert bool() == False
with = 42

Meanwhile Python 3 (called 3000 at the time) was being developed and separated the community at the time. The libraries were not yet there, unicode in wrong places giving problems with file system access, breaking changes in the C API. At the company I worked for, we decided to stick with Python 2 at that point.

I went searching for something else. Looking for ease of deployment, better concurrency abstractions. I was not smart enough for Haskell. You can't get people to write Erlang. Then I saw a talk by Rick Hickey, the author of Clojure, about how to make things easier for ourselves as programmers. [See for example this video, Maurits]

It is a Lisp, but with a twist. Some (killer) features.

• Immutability is the default. You have persistent data structures, you get rid of data races, don't need to use locking, or worry about changing data in place.
• The core language is almost all in macros.
• There is Java interoperability and it is good. So you can use any library from Java.
• ClojureScript: write Clojure and compile it to Javascript. Many persons use it to integrate with ReactJS.
• Easy deployment. Python at the time was just starting to use virtualenv, wheels for packaging were not there yet. With Clojure you build your dependencies in a single JAR.
• Good REPL, Read-Eval-Print Loop
• Recently asynchronous support in the core.

Some sadder parts:

• There was not a debugger for long, current one is fairly new and not very powerful.
• Standard library is very stripped down, basically just string manipulation and regexes.
• Complicated compile routine, build systems are not part of the language (where Python has distutils), bad ideas stick around: the core folks experiment a lot and this stays in core without warnings.

After three years with Clojure I really liked the language, but I missed several things from Python, so it was time to go back. Rediscovering Python:

• Python 3 is the Python nowadays.
• IPython notebooks have come a long way, to share snippets of code about machine learning.
• Standard library keeps growing.
• Asynchronous programming: asyncio, async and await. It is good to have this in core, though it is good to have alternatives like gevent.
• New type hinting, which I think is a good beginning, though others hate it.

Things I wish Python had:

• Atoms, refs and optimistic concurrency. In Python it is still too primitive.
• PythonScript, so you can write Python and compile it to Javascript.
• JAR, though wheel is getting there, I like the direction.

Summary: don't be afraid to look around for other languages, Clojure is worth taking a look at, even if only for stealing ideas.

Questions

What about macros? Macros are nice, but they would be hard to do in Python, because the syntax is harder. There is rust. I don't quite miss it. [Audience: there is NEM which you could try.]

Did you miss the Global Interpreter Lock? No, but I don't miss the absence of it either. You just have to live with it.

What did you first use Clojure for? For a startup I needed a good network layer for an OpenStreetmap project. Another project that needed to handle tens of thousands of requests per seconds and analyze them.

Twitter: @mishok13

Op de Plone conferentie in Boekarest heb ik al twee presentaties gehouden, die kan je bekijken:

• The state of Plone Intranet
• Plone Intranet under the hood

Plone Intranet kan je nu al in productie gebruiken en dat gebeurt ook.

In 2012 ben ik hieraan begonnen, sommige stukken code zijn nog ouder. De ontwikkeling heeft al invloed gehad op Plone 5, vooral de manier waarop javascript wordt ontwikkeld.

Wij werken met 'design first.' Zomaar iets bouwen levert wat mij betreft te weinig gebruiksvriendelijkheid op. Maak dus eerst het ontwerp en ga daarna pas de code bouwen. Een van de uitdagingen was om de ontwikkelaars in deze gedachtengang mee te krijgen.

Sprints deden we eerst een dag per week, later twee dagen per twee weken en nu liefst een week per maand, om meer focus te krijgen. We hebben online en onsite sprints en regelmatig overleg met de board.

Synergie: technologische en sociale veranderingen versterken elkaar. Je koopt geen intranet omdat je een brok technologie wil hebben, maar omdat je mensen met elkaar wil laten samenwerken. Cultuur in een organisatie: onze wereld. Dus voor elke organisatie anders. Welke organisatievorm het beste is, hangt af van de omgeving. De omgeving wordt steeds complexer en dynamischer, dus efficiënte maar logge organisaties zijn daar minder geschikt.

Hoe vertaalt zich dit in Plone Intranet voor verschillende organisaties?

Voor strakke organisaties (blauw):

• Documenten kan je uploaden en dan krijg je een preview zodat je Word niet hoeft te openen op je mobieltje waar je dat niet hebt.
• Bibliotheek: diepe boomstructuur van documenten.

Voor actieve organisaties (oranje):

• Adaptief case management met fases waarin todo items passen. Typisch voor het opbouwen van een besluitvormingstraject.
• Documenten, evenementen.
• Dashboard met centraal de taken.

Voor professionele organisaties (groen):

• Sociaal dashboard, met conversatie centraal, Twitter- of Facebook-achtig, met de documenten weer geïntegreerd.
• Team spaces. Elk team heeft een beveiligde ruimte. Sharing tab gereduceerd tot drie eenvoudige sliders.
• Teamleden kan je beheren, en moderator of admin maken binnen de team space.

Voor inspirerende netwerkorganisaties (geel):

• @mentions, #tags, notificatiepaneel
• Faceted search van documenten. Of van mensen, zodat je experts binnen de organisatie kan vinden.
• Afbeeldingenbank.
• Sociale profielen met endorsements: zoals op LinkedIn zeggen mensen waar jij goed in bent. Mensen volgen.

Het is een emergent systeem. Als mensen veel sociale updates doen, dan wordt het een sociaal systeem. Als mensen veel gestructureerde informatie toevoegen, dan wordt het een bibliotheeksysteem.

Het is uitbreidbaar met apps.

Roadmap:

• Content updates, dus dat je een nieuw document in je stream ziet. Is al grotendeels af, maar we willen het helemaal goed hebben.
• Automatisch taggen.
• Organogram.
• Push naar mobiel.

Marketing is heel belangrijk is ons vak. Daar zijn we ons nu op aan het richten. Ons merk is nu: Quaive. Sociale intranet samenwerking.

Plone Intranet draait op het Plone framework. Het is niet zomaar een add-on, maar echt een afgewerkt product. Je moet niet allerlei add-ons erbij gooien. Ik wil niet dat er een los-zand-systeem ontstaat. Alles moet goed bij elkaar passen.

Ga je dit nog aanpassen voor de klant qua vormgeving? Logo: oké. Maar klanten gaan ook de vormgeving van Word niet aanpassen. Nieuwe functionaliteit kan in de apps sectie.

Je kan bestaande Plone content importeren of een site migreren. Maar je wil niet de oude chaos importeren, je wil de structuur aanpassen. Bijvoorbeeld: wat hoort in een naslagbibliotheek en wat hoort in een team space?

Hoe beïnvloedt dit Plone? Lekt functionaliteit van Quaive door naar Plone? Ja, we zijn vorig jaar al op Plone 5 gaan werken en een deel van de Plone 5 functionaliteit bestaat omdat het voor Quaive is gebouwd.

Jean-Paul heet ons welkom.

Sinds 2007 is er elk jaar een Nederlandse Plone gebruikersdag. Ditmaal georganiseerd door Zest Software.

Plone is nog steeds actief en komt graag bij elkaar om kennis te delen. Dit jaar in Boekarest. De jongens kwamen met veel meer energie terug dan andere conferenties.

Plone gaat zijn vijftiende jaar in. Is Plone nog steeds hetzelfde als vijftien jaar geleden? Nee, Plone 5 heeft flink wat wijzigingen, ook voor de gebruiker. Er is evolutie geweest in Plone vanaf dag 1. Er is lange termijn visie, bijvoorbeeld dat data meegemigreerd moet kunnen worden, wat met Sharepoint erg lastig is met veel extra kosten. Dus: Plone is niet 15 jaar oud, maar 15 jaar actief.

Deze dag is georganiseerd door Zest Software en gesponsord door Python United, Four Digits en Cosent.

Presentaties:

• Paul Roeland: Meer dan software: de weg naar Plone 5
• Jean-Paul Ladage: Plone 5 is uit. En nu?
• Kees Hink: Mosaic, flexibele pagina layouts voor Plone
• Guido Stevens: de status van Plone Intranet