I am from Jamaica and am enjoying the weather here!

We are going to talk about the pain, the background, and the goal of developer onboarding.

Being approachable is a good thing. Plone can be hard to approach. For end-users it is fine, but programming it can be tough. It's more like learning to operate a helicopter than like learning to ride a bike.

Can we make getting started with Plone easier for new developers? If we do this, it is going to add a lot of value for a lot of persons. To be fair, the barrier is getting lower.

I had someone who knew how to theme Wordpress sites. She needed to learn how to theme Plone. The documentation was lacking. I started thinking about what she needed, and started creating documentation.

Funny experience: I searched for 'Plone newbie' and the top results were from my own website.

MIT has an onboarding program for new employees, all kinds of things for the first day, first week, first month. This is very different to sink-or-swim. It requires understanding to some extend, looking at your blind spots.

So what is developer onboarding? Turning an outsider into an insider. Preparing developers to be effective with the stack by equipping them with an understanding of our culture, tools, skills and processes. Are you an insider or an outsider? Even after a few years you can be hesitant to say you are an insider.

There is a gang of four people who do research on developer onboarding: Fagerholm, Sanchez Guinea, Borenstein, Münch. They researched at Facebook. Some findings:

• Mentors are less productive during mentoring.
• Mentored employees became productive much quicker than employees who were not mentored.
• Recommended: get core developers to mentor. They can communicate the model of development, give overview.

What can you do?

• provide checklists, for example steps in a readme
• simplify the setup, automate things
• have lists of ready-made blocks of code, snippets, conventions

Make the development cycle clear:

• setup development environment
• customize/code/test
• deploy to production

People don't want to work or think more than they have to. If a hello-world exercise takes three hours, you don't get motivated. Have good examples instead of descriptions. Progressive disclosure: tell new users only what they need to know, and tell more later, so they don't get overloaded in the beginning.

My newbie-friendly picks:

• Plock, for quickly getting a Plone Site up and running
• mr.bob for creating an add-on skeleton
• training.plone.org for quick-start tutorials
• Gloss as layer on top of Diazo
• Diazo snippets library

What is the least amount of vocabulary for newbies to get things done? Do they really need to know what buildout is, and Diazo, or can they be productive without it.

Getting the model wrong can cost a lot of time. Let's help newbies.

Rapido can help for newbies too, fairly maintainable, I like that.

This is a story about an early adoption of Plone 5.0. We are from the Blue Dynamics Alliance.

Plone 5 helped us to meet the requirements of a big project. But we ran into problems, which we fixed upstream in Plone core. At the pure CMS level the first Plone 5.0 release was okay, but lots of bugs were left, although there were no blockers.

The new theme was a big advantage for our projects, responsive, much easier to begin development with.

For Porsche Informatik Salzburg we did mostly training, though also a few minor core fixes, consulting. The internal developers knew Zope 2 already, so they could use some of their previous knowledge. We used Mosaic, which meant they only needed to create tiles, not viewlets and portlets.

Project for Architecturstiftung Österreich. We used Lineage, to handle eleven sub sites. Very image centric site. Mobile friendliness was important. We updated several add-ons to support Plone 5.

For Swiss Bankers association we did a project together with Peter Holzer. It had to be secure, modern, responsive, and since it was Switzerland multilingual support was very important. We had to find a way to let collections show German documents and as fallback show the English document. We created collective.linguatags for multilingual tags: tag in one language which gets translated to other languages.

Free software is part of our business model. We try to give back to the core, instead of stacking things on top. Plone is open source driven by the community, not a single company. That is better for the companies, although it makes it more difficult to make money with it.

We made around 200 core pull requests for these three projects. Here are some of them, most are merged, some not:

• Add review state as a class in content items in the portal tabs.
• Improve the new resource registry. Simpler generation of gruntfile, compile resources. Make this generator more verbose. Better formatting of generated file. Fix compile errors. Fix plone-legacy RequireJS errors in development mode.
• Prettified the toolbar. Added a less variable for the width of the secondary toolbar column.
• Reworked the related items widget in mockup. You can search and browse, instead of only one of the two. Still, linking to three or four items works fine, but for more it gets difficult.
• The structure pattern: design for alerts, better action items.
• Use official TinyMCE bower dependency. Documented in core TinyMCE how this is built, so we can use this well in Plone. You can include multiple styles now.
• Mosaic fixes. The editor needs work, though it got better during the Leipzig sprint. Take permissions of visibility of tiles into account. Adapterize the layout (ILayoutAware). This gives a base to remove the main template if you want to. Fixed a MemoryError due to sub requests. This also makes Diazo faster.

Did various code cleanup, pep8, sort imports, etcetera. Makes it easier for newbies to get in.

Fixes for Lineage. Fixes with path setting of widgets, like related items widget, also important for multilingual. Subject vocabularies are now aware of navigation root (sub site).

Enabled unload protection in various packages. Various pattern fixes. Fixed MemoryError during scaling. Added events in the transform chain.

Lessons learned:

• Don't underestimate dot zero releases. It was an experience.
• Better fix things upstream instead of patching.
• Avoid forking repositories, better create a branch on the original repo.

Want to help?

• Please report and/or fix issues. Improve documentation, edit or add it. Dare to ask on http://community.plone.org. Enhance the add-ons, help them to Plone 5.
• PLIP: PLone Improvement Proposals. This is the process for getting bigger features into Plone.
• Enhance the ecosystem around Plone. Help to get Plone on Python 3. Code cleanup.

I am from the University of Utah Department of Pediatrics, http://upiq.org. I will be giving practical tips for using component architectures. This is my pragmatic perspective on components, my opinion. We will explore idioms and ideas.

Plone has been using the ZCA (Zope Component Architecture) for most of the past fifteen years. It is an old hat, but it fits great, we don't want another.

In Plone we push to make things simpler. An API helps here. But you should still strive to understand the underlying component architecture, otherwise lots of things won't make sense. We have complexity, which may be hard to debug, but it makes great things possible.

I encountered the ZCA for the first time in a discussion on OSCON in 2002 with Jim Fulton. Zope 2 at that time had lots of difficult code, look at all the mixin classes in for example the OFS package. We still have that today. But the ZCA allows a different approach. Instead of one big package, there are more packages, which is a trade-off.

Holy trinity of components:

• adapters: single context. Or views with multiple contexts (object and request). Or subscribers.
• resources: content, utilities, request/response
• schemas

Objects can be in two categories, those that you lookup and those that you don't. Lookup by path, component registry or both. Others are created on the fly, like site global state.

Indirection. If you want to override a widget with a custom widget and the override is not working, then it can be tricky to see why this is. It can be a scary departure from imperative programming, where things may be clearer at first, but the override may not even be possible in such a system.

Interfaces are contracts. Multiple implementations can provide this interface.

Make components that look like native data structures. Programmers are used to it, so let them make use of their experience, don't work against it. We use a resource-centric development, driven by state, not by action. We do object publishing, so keep the object central. A procedural API, like plone.api, will often try to hide the ZCA: just ask the site for something, which then makes the single site central. You don't notice that under the hood plone.api is using the ZCA. But this abstraction leaks through.

I can and do use plone.api. But I also wrote my own, more state-driven api. I can mix these.

My point: don't think that an API needs to hide the ZCA, that the ZCA is only for ninjas. Food analogy: sure, use a kitchen appliance, but please still remember how to use a knife, without cutting yourself.

Components are "objects connected by interfaces." (Jim Fulton) Resources are easier to work with when they are smaller and pluggable.

Use interfaces as schemas. For content items, you only want to add fields in this interface, and not methods: content should be simple. Then create adapters for adding functionality.

For debugging adapter lookup: temporarily move _zope_interface_coptimizations.so out of the zope.interface distributions. Restarts, take coffee, and debug. But this is not often needed.

Views. Other frameworks see views as endpoints for urls. We see views as all about content, using a multiadapter on the content and the request for it, which is terrific.

Some vocabularies may be static, but others need to be specific for a context, so we use the ZCA for that. Very useful.

For site-global utilities there are four ways:

• persistent component (utility). So this stores state in the ZODB. Uninstalling can be a nightmare, so watch out.
• adapter of a site. Needs to be cheap to construct, because you will construct this every time code needs it. You may still need to store state somewhere, like in an annotation or the configuration registry.
• plone.api in certain cases
• CMF tools (deprecated).

Related:

• Reg, from Martijn Faassen, inspired by zope.interface and zope.component
• Python's ABC, abstract base classes. But they are not really interfaces.

I really like Python. I always miss its elegancy when I write Javascript. But Javascript is a reality. It runs on all browsers. If you are a web developer, you need to know Javascript and its frameworks. Things are moving fast.

Plone development happens slow in comparison. Also we have Plone 5, but some universities are still at Plone 3. [My site is Plone 2.5, Maurits.]

plone.restapi is our bridge between Plone and the Javascript framework world. It is not opinionated: you can use Angular or React or tomorrow's framework.

You can login using the REST api and get a token back that you can use in subsequent requests. You can create/get/edit/delete content information, navigation, breadcrumbs, get or set registry settings, handle users. A unified search api will be tricky: making it usable for both default catalog, solr and elasticsearch is basically impossible.

plone.rest is stable. plone.restapi is still in the alpha phase, but a lot of companies are already using it. We are really open to contributions.

• https://pypi.python.org/pypi/plone.restapi
• https://pypi.python.org/pypi/plone.rest

Questions? Doesn't the front-end need access to some configuration information that we currently consider private? Yes, that is a problem we run into and are thinking about.

plone.server is just a project, it is not approved by the framework team, this is not in Plone core yet.

Philip Bauer in Brazil Plone conference 2013 was pushing people to think about the future of Plone. Where are we going. Plone has a really good component architecture, thanks to Martin Aspeli and others. After lots of discussions about the future in Bristol Plone conference 2014 Timo Stollenwerk started working on the Plone REST api. Asko Soukka worked on Mosaic. Nathan Vangheem worked on elasticsearch. Eric Brehault worked on front end with Angular 2. We took lots of these people and gathered them in Barcelona earlier this year. Fifteen developers on back-end, api and front-end. Experiment: could we do it? Yes, we had really great results. We have reached an experimental version of the whole stack. We will present this today in three talks.

In this talk: the back-end.

We split the various parts of Plone in three: front-end, basic core (dexterity, zodb), extra Plone stuff (link integrity, discussion). The division between the parts is bridged with a REST api and the framework api (plone.api).

Possible future is that plone.restapi will be included in Plone 6, and separate front-end is possible in a later version.

For plone.server we used as base ZODB 5, ZEO asyncio, and the ZTK (Zope ToolKit). It is an asynchronous app server that offers a traversable REST api with a ZODB.

It is a headless CMS: it does not include the view/presentation part.

Content type: there is no CMF, it is based on zope.container and dexterity. One content type: an item that is a container. Content types are specified declaratively, defined in Python code and zcml, not stored in the database, no option to create content types through the web at this point. A simple base.

plone.jsonserializer. Used on plone.app.mosaic. We need to merge this with plone.restapi. We did fixes yesterday night.

plone.registry is the main or really the only configuration place. All persistent info is in one place. For example portal actions should be in the registry.

API definition. Traversal is hard to define in an api, we used json. We use the websocket api. All is built on plone.restapi.

Mount databases or sites using json configuration. /DB/SITE/FOLDER/OBJECT.

In traversal we do a lot:

• Get the resource
• abstract the user
• language negotiation
• check access permission
• etc

Read calls (mostly GET) by definition do not write anything to the database. Any changes are rolled back.

On the request we make available several things like the site components, the main object, configuration registry, etc. Some helper methods. Upload/download is done with external blobstorage with async.

There is no ZCatalog, but there are ways to hook up what you want yourself. No GenericSetup, no acquisition, no z3c.form, no attribute traversal. No Zope roles, only Plone roles or permissions. The base Plone server does not need many packages outside of the ZTK.

It is Gunicorn compatible (WSGI). It is only for Python 3.5 and higher.

Extra packages: pserver.oauth, pserver.elasticsearch, pserver.gcouldstorage, pserver.cms.

You can try a demo with the repository at https://github.com/pyrenees/pserver.demo

We are a community! We can have fun! We should be proud!