The rewrite of the RRs (resource registries) started in 2013 or 2014 and landed in Plone 5.0. I would recommend using Plone 5.1, as various things have been improved there.

With the RR you register and deploy JS and CSS. You can organise dependencies, and optimise resources and number of requests. The resources are grouped into bundles, they are concatenated and minified. Add-ons can easily register their resources. Cache headers are set automatically.

In Plone 4 there were no formally defined dependencies, so that made it hard to manage. You just had a list, and that order was used.

In Plone 5, the RRs are based on plone.registry, RequireJS, LESS and the command line interface of gulp. Instead of LESS, a lot of projects have switched to using SASS now. RequireJS is also less popular. So there is still room for advancement.

The Plone 5 way solves dependency management, but it is complexer and harder to debug. I have had my problems with it, but usually it works quite well, and is a huge improvement over Plone 4.

The js/config.js file in mockup contains configuration on how the javascript in Plone should be built. In Products/CMFPlone/static/plone.js you can see how the plone bundle is defined, and what it requires.

You can still define legacy resources, which work like they did in Plone 4. They are wrapped by some code that temporarily undefines the define and require definitions, otherwise you get errors.

In Products/CMFPlone/static/plone.less all the needed LESS definitions are imported or defined, used for creating our CSS. LESS is very handy for defining for example a text color once and use it in lots of places. [In Plone 4 we did this by using DTML files.]

You can customise and override the plone and plone-loggedin bundles in your code, if you maybe do not need everything that Plone offers by default.

collective.lazysizes has a good example of defining resources and bundles. In its registry.xml it uses condition="have plone-5" to only apply this part on install when the site is Plone 5.

With ./bin/plone-compile-resources -b plone you compile the plone bundle resources. This is also possible TTW, but I recommend the command line tool.

Get a normalised state for your json data. Think about how to structure your data so you don't duplicate data, and you have quick retrieval. For example use the normalizr library.

Use Redux development tools to give you hints or boiler plate for a new test.

Use components. When you use them, make sure they don't block other components: if four other components are not getting shown until a fifth one is ready, that is not a good idea. Give the user the information that is already there. Already show a skeleton on the page of how the component is going to look, so you only need to fill in some extra stuff and the user can already see how the component will look like.

Watch the component life cycle: which part is taking the most time?

Check if repainting is really needed before you do it: maybe a data value gets set but it is the same as the old value. Catch this and save on rendering. Use the Chrome Render Tools.

Use local, non-committed environment files to make differences between local development and production. .env may contain the default values for everyone, committed, and .env.local has your local tweaks, and you let git ignore that.

Use route wrappers to for example ease checking for anonymous or authenticated users, and do some calculations in there, so you don't need to do that in all kinds of places.

Offline first: have some javascript that runs in the background for hijacking netword requests. If you are offline, this should queue the network requests for later. IndexedDB could be more useful here than localstorage.

Use the ESLint command line utility to check the quality of your code, including your fellow developers.

Find me on Twitter: @devonwbernard.

This is about the Python 3 core asyncio library. "This module provides infrastructure for writing single-threaded concurrent code using coroutines, multiplexing I/O access over sockets and other resources, running network clients and servers, and other related primitives."

The first time I read that I was like: what?

Asynchronous programming using async and await syntax. Any network activity should not block other code, that is the main idea. This is useful because web applications use TCP sockets. It is a way to improve performance and scale web applications. Also think of microservices.

The optimised event loop allows you to handle a larger number of requests per second. You can have long running requests with very little performance impact. With standard Plone that is impossible.

Requirements: Python 3.4.

How are typical web servers designed like Flask, and Django? Each request is tied to a thread, so you are limited to handling number of threads and processes you run. Threads are expensive (GIL, context switching, CPU). If no threads are available, further requests are blocked, waiting for an open thread. Threads are blocked by network traffic, for example to a database server.

With asyncio, requests can be tied to tasks. You can have lots of tasks per thread, and if a task needs to wait for network traffic, it does not hurt you. But be careful: if anywhere in your code you use the requests library instead of asyncio, that will block your network traffic.

We have Futures`.  ``asyncio.run_until_complete with ensure_future wraps your asynchronous call in a Future object.

You can have long running Tasks. Tasks, futures and coroutines are very similar, in the beginning you don't need to worry about that.

Gotcha: everything must be async. Async functions need to be run by the event loop. If you run it manually, it will not do anything. If you don't call an async function using await it will never be run either.

asyncio is single threaded: only one event loop can run in a thread at a time. Running multi threaded code in asyncio is unsafe. You can have multiple threads, each having their own event loop. You can get the feel of multiprocessing by using asyncio.gather

With an 'executor' you can make synchronous code asynchronous. Typically it is a thread executor. Try to avoid it, but it is a tool that you can use if needed. See concurrent.futures.

asyncio comes with an amazing subprocess module, so you can await the result of executing a command on the terminal.

The event loop is pluggable, for example tokio.

More and more libraries are popping up using asyncio:

• aiohttp: client and server library
• aioes for elastic search
• asyncpg for postgres
• aioredis
• aiobotocore
• aiosmtpd for smtp

[See https://github.com/aio-libs for more.]

Debugging is more difficult than regulare sequential programs, the pdb is tricky. aioconsole allows you to have a Python prompt with an asyncio loop already setup for you.

guillotina uses asyncio.

In Python 3.7 you have an execution context, which is going to be nice.

Questions and answers:

• You cannot do WSGI with asyncio. But Tornado uses asyncio.
• What was hardest? Wrapping your head around it all.
• Is this only for network calls? Or also useful for disk access? There is an add-on for that. I tried it and then it was kind of a hack.
• Do you have profiler tools, like seeing if code is blocking too long? See an earlier talk. There is `aiomonitor <https://github.com/aio-libs/aiomonitor>`_.

Twitter: @vangheezy

Existing code needs love too! Look at the truth behind open source apps on commitstrip. You can help open source projects by becoming a maintainer. I became maintainer of WebOb.

What I was told: don't mess it up. There was no existing maintainer at the time. It was handed over to the Pylons project for maintenance, but no single person was responsible for it. They all stepped back.

Side-track: imposter syndrome. See Denys Mishunov's talk yesterday. Usually you get extra responsibility gradually: for example first commit rights, then release rights. You may think you are not good enough for extra responsibility, but probably you are.

You have all these nice ideas and good intentions. You push out some alphas and betas, all seems okay. You make a full release. Then a bug report comes in because you removed something that you did not expect anyone to use.

Code grows over time. All kinds of code is there because it fixed an actual problem for an actual user. So you are faced with backwards compatibility. How much of it do you do? It depends on whether you are using a library or a tool. Libraries need to maintain more backwards compatibility. For a command line tool, the only API is the tool, not its internals.

Can you afford to lose your users? Someone can fork your code and maybe rename it and create an alternative tool.

Testing: if you have 100 percent test coverage, and you change something and a test breaks, then you can more easily see what is wrong. Does the test simply need to be rewritten for the new situation? Or is the test breakage a hint that something will break for a user, letting an old bug resurface?

You sometimes have to make a breaking change. Give a deprecation warning then.

Joel Spolsky: 'Single worst strategic mistake: rewrite the code from scratch.' This was about NetScape 6, and allowed Internet Explorer to catch up and take over. It is an option, but probably not the best.

So. You took over. You are now the gate keeper. You are a temporary guardian. Eventually someone else is going to take over. You should start looking at mentoring opportunities. Find ways to engage others, engage the community. Create pull requests instead of pushing to master.

Reach out to other communities, consumers of your code. Can you help them?

People may ask or tell you to just accept this pull request. Just push out a new version. Just is a bad word. Push back and insist on them following the standards of your project. If you require 100 percent test coverage, don't review the pull request.

I have received bad bug reports, so now I myself write better bug reports. I push myself to do better. Maybe even try to provide a fix for a bug upstream.

Be friendly when someone does crazy or seemingly stupid things in a pull request. A good question to get clarity is: 'What are you trying to accomplish?'

Twitter: @bertjwregeer.

[Sorry Mark, I came in late.]

SSR = server side rendering

Create an app.module.ts and an app.server.module.ts

• Static SSR is done at build time.
• Dynamic SSR is done at run time.

SSR gotchas:

• If you use window or document, the server does not know what to do: this only lives in the browser. If you must, create a WindowService and use dependency injection to provide different versions. Use isPlatformBrowser() as much as possible. Hide things from node. Not all parts need a server version.
• Be careful with timeouts, because they will let your server wait.

Conclusion:

• Universal makes SEO possible.
• Universal gives really fast initial painting of your app, and you keep the interactivity. Can be two to three times faster on mobile.
• Be mindful of browser-specific things you might be using in your code.
• Choose third party libraries carefully, as they need to be mindful of the pitfalls as well.
• It takes a bit of work, but it is worth it

Further reading:

• Code: https://github.com/angular/universal
• Twitter: @MarkPieszak, which will get a link to the slides soon.