Plone is fifteen years old this year. What does the future hold?

Plone 5.0 has been really positively received. Plone 5.1 is where we apologize for what we did in 5.0. Some stuff:

• Meta bundles generation, so you don't get so many javascript and css files.
• Getting rid of the quick installer, so you don't have two competing ways of installing stuff. We have an @@installer view now that only uses GenericSetup. We will warn when there is no uninstall profile. The default profile is now really the default profile, instead of the quick installer taking the first one alphabetically.
• Configure portal actions through the Plone UI.
• Retina image scaling. Set scaling ratios for higher resolution images. Pretty seamless.

That is definitely going in. Probably several or all of the following as well:

• Conditionally import registry records.
• Merge Products.RedirectionTool into the core, with new control panel.
• Add/edit/delete registry records in the UI.
• Get rid of old resource registries (portal_css, portal_javascript)
• Merge collective.emailconfirmationregistration into core.
• Merge collective.indexing into core, giving queued indexing, which gives performance improvement.
• Some javascript improvements.
• Mosaic, not yet 'plipped' (proposed) for 5.1. This is content layout using tiles, giving you a lot of flexibility over how a page looks. We started similar projects years ago when browsers were not ready for it yet. Let's see a demo. The layout is saved as simple html that you can manually edit if needed.

With Mosaic and Rapido you have very powerful through-the-web development. We were pushing people away from this, to safe them from themselves. But with these two, you can export it to the file system, which makes it much more viable and safe.

For Google Summer of Code:

• Vikas Parashar created several themes.
• Prakhar Joshi worked on collective.easyform, which is dexterity form creation. It now has an upgrade path from PloneFormGen.

Plone 2020 discussion: where do we want to go as community and as software project?

• APIs to hide complexity. plone.api. plone.restapi.
• Improve TTW customisation.
• Improve training and documentation. You can follow a training at http://training.plone.org or use this to give a training yourself. It gives you a jump start to development.
• Cleaner codebase: simplify structure, remove unused functionality and code.
• Update dependencies to latest versions, ztk, Zope 2/4, ZODB3. Most are already Python 3 compatible. That is the step needed for Plone before we can focus on Python 3 ourselves.

CMS traditionally has three layers: content storage, management and presentation. Headless CMS removes the presentation layer. If you have that, you can write your own fronts for it: traditional UI, phone app, other front-end framework. What we are currently building with plone.rest and plone.restapi is more a decoupled CMS, because the original front-end is still always there. In a sprint in Barcelona we worked on several parts of this:

• REST api
• front-end: working with plone.server or plone 5 + restapi, server side rendering via Angular Universal
• back-end: plone.server, aiohttp-based server.

There will be several talks about these today.

So we have two parallel paths to the future:

• server/client with rest api
• back-end Zope and other dependency cleanup

What have we ripped out in the past? Kupu, Archetypes, classic theme, portal_interfaces, plonetestcase, xdv, portal_Css, DTML, NuPlone, etc. The Hello Kitty Theme. And Plone still works. So we can do this.

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

I am from the CWI, Center for Mathematics and Informatics, at Amsterdam, where Python was born, and where I worked on ABC, the basis for Python. I wrote parts of gcc. I ended up chairing the w3c html working group.

I will talk about Moore's switch and the future of programming.

We were developing ABC in the beginning of the eighties, when computers were really slow. However, we knew about Moore's law, that computers would become faster.

In the fifties, computers were really expensive. You could hire an hour of computer time for the amount of money you pay a developer in a year. What I call Moore's switch: this has gone the other way around. Earlier programming languages were geared towards making it the computer easier, not the programmer.

Moore's law: computing power doubles every 18 months. In 1977 was the first time I heard say that Moore's law was soon over. In 1988 my laptop had a power of 500, now it has doubled fifteen times.

By the 1970's, computers had become cheaper, but programmers not: software crisis. Ninety percent of the cost was in debugging. Fred Brookes wrote about this in The Mythical Man Month. The larger the program, the more expensive it becomes.

An order of magnitude improvement would help a lot. What takes one week, would take a morning instead.

A declarative approach is much shorter, and therefor faster to write. Can this help? What does declarative programming mean? I wrote a declarative clock program in the beginning of the 1990s of twelve lines, instead of 1000 for a procedural clock program.

Declarative: you specify what needs to be and remain true. This also means there can be no while loops.

Look at XForms for a declarative language. A certain company went from five years and thirty people to finish a project to one year and ten people, by using XForms. It shows that declarative programming is feasible, usable, for real world projects.

I believe that eventually everyone will switch to declarative programming.

Questions.

"Some programmers move from Python to lower level languages to get more performance out of computers." They may not have done the numbers. Programmers need to learn a new technique, which may make them not want to do this. Countries have held back the use of the Arab numerals that we now all use.

In ABC we saw that people were mostly busy with sorting and searching. So we made this very fast.

"Do big companies use this?" Yes, various, like Yahoo, IBM. Usually in small groups, not company wide.

"What will then happen with Python?" What happened to Pascal?

"Where should I start?" Look at Xforms. That is the only standardised version that I know of that does this stuff.

Strictly speaking, spreadsheets are declarative.

"What books do you recommend?" There are no books on XForms yet.

"Do you consider Prolog a declarative language?" Not really, though I see what you mean.

[For more information, see the XForms article on wikipedia, Maurits.]

Twitter: @stevenpemberton

Python and web developer since 1998. I did Zope, and for a little while it was as popular as Python itself.

What is this about? Implementation details, concepts, creativity, software development.

Morepath is a web microframework. The planet Zope exploded and Morepath came out. It has a unique approach to routing and link generation with Traject. Easy and powerful generic code with Reg. Extensible and overridable with Dectate.

In the early nineties you had simple file system traversal to publish a file on the web. Zope 2, in 1998, had traversal through an object tree, conceptually similar to filesystem traversal. Drawback: all objects need to have code to support web-stuff. Creativity: filesystem traversal is translated to an object tree. Similar: javascript client frameworks that mimick what used to be done on the server.

Zope 3 got traversal with components: adapt an object to an interface that knows how to publish to html, or to json. So the base object can be web agnostic again.

Pyramid simplified traversal, with __getitem__. So the object needs to be web aware again. Might not be an issue.

Routing: map a route to a view function. As developer you need to handle a 404 yourself, instead of letting the framework do this.

You can fight about this as frameworks. But morepath has it all. It is a synthesis.

I experimented with a nicer developer API than Zope was offering to get a view for traversal. So I created experimental packages like iface and crom. I threw them together in Reg. It was just a rewrite of the Zope Component Architecture with a simpler API.

Class dispatch: foo.bar() has self as first argument. Reg uses functools.singledispatch and builds multiple dispatch. But then I generalised it even more to predicate dispatch, as Pyramid had.

Don't be afraid to break stuff when you refactor things.

Dectate is a meta framework for code configuration. Old history involving Zope, Grok, martian, venusian, but now Dectate. With this you can extend or override configuration in your app, for example when you need to change something for one website.

Detours are good for learning.

Splitting things off into a library helps for focus, testing, documentation.

Morepath uses all these superpowers to form a micro framework.

Twitter: @faassen

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