Intuitive

Your API should not surprise your users.

Hard coded variables are bad. Keep runtime variables in one central place, so users can find them. Make it so that you do not need to juggle with git to avoid accidentally committing a password. Search github for 'removed password' and you find over 300,000 commits with that commit message... Good: create a Config class, and DevelopmentConfig, and ProductionConfig and handle the differences there.

Use object relational mappers (ORM), instead of writing SQL, as you constantly worry about SQL injections.

How to standardise database migrations? A tool like alembic helps, to create a way to upgrade and downgrade. But please change the alembic file template to start with a date instead of a random hash.

Have a standard database seed, that users can use to get a database with standard content.

Use a requirements.txt file with all the requirements that you need. You can get packages from a git repository too. And you can install packages from the local file system, which is especially handy if you develop two packages at the same time, so you don't need to push changes all the time for package A when you yet know if they actually work with package B.

Is the setup code in your README working? If you can replace this by a single command, that would be better.

Create unit tests. You may hear:

• "But it wastes time." No, you still have to verify your code before you deploy it to production. And you do not just need to verify the new code, also the older code, as it may be affected by your change.
• "But writing it is boring." Manually clicking to verify that it works, is even more boring.

Database flush versus commit. A flush reserves a placeholder spot in the database. A commit saves records in the database. If you explicitly commit, and later something goes wrong, your commit is still in the database; usually you do not want this: either all changes should be written, or none at all. Also: use flush instead of commit when you need to get an auto increment id back: what is the id of the row that will be committed to the database.

Flexible

Create an app factory, so there is one way to instantiate your app. This may also help for avoiding circular imports, like when your API depends on your database code, and the other way around.

Create blueprints. For example create one decorator for registering an admin view, and another for anonymous views. That makes it very clear which view is for what kind of user.

Reliable

How to maximize uptime? Prevent downtime by not shipping bugs: have automated testing, have staging servers

Versioning: have a way to know what the used version is. Keep backwards compatibility. Communicate when you will drop a feature.

Get some analytics about API usage. If one of your front end developers is still calling a deprecated part of the API, detect this and send them an email.

First rule of endpoint design is: be consistent.

Document your API, or it does not exist.

A tool like Postman can be used to show the end points, and is helpful for debugging: paste the exact payload that gave an error on production.

Use Python profiling: what lines of your code take the most time?

Caching: store common responses in memory for quick retrieval.

Find me on Twitter: @devonwbernard.

Timo

Pastanaga UI was created by Albert Casada. Pastanaga means carrot, and the logo is a stylised carrot. Albert worked on this in his free time, creating hundreds of icons, etc. I was impressed before I even saw it. Main ideas:

• Simplify. Do not show what the user does not need to see.
• Adaptive user interface. More people are viewing web sites on mobile devices than on desk tops now. You UI should work good on all kinds of devices.
• Focus. I was writing a blog post in my code editor. [Note from Maurits: me too.] We want users to do that in Plone. Most current CMSes use TinyMCE or a similar editor, like Plone does, and we no longer stand out. The most time of our users is probably spent in TinyMCE, so we should make this better again.

Pastanaga is a carrot. Albert said he wanted a carrot on a stick, to entice people into using Plone again.

Another story. Ramon did all the stuff on plone.rest, I saw he wast smart, so I just nodded and created a few tests. I did not have much time to work on it afterwards. Others came and made it work with Archetypes, which we did not initially want, but they improved our initial code to make it flexible, so why not. Then Eric Bréhault came along for plone.restapi. Then people worked on an angular client. So: we told a story, did some work, and others jumped in.

It is hard to maintain stuff on our own. We must become consumers of libraries that are already there, especially javascript libraries. Do not reinvent, but reuse.

For us developers, it is cool to create a version of Plone that works on Zope 4, or Python 3, but clients mostly do not care. They need something else, like the Pastanaga UI.

Make Plone outstanding again.

Eric

It's time for new stories. Start writing them. Thank you.

Python at Google

Google loves Python. :) It is widely used internally and externally. We are sponsoring conferences. We have open source libraries, like a Google Data Python Client Library, libraries for youtube, app engine, etcetera. We use it for build systems, report generation, log analysis, etc.

How can you use Google Cloud Platform for your app or website? You can deploy at scale. You can embed intelligence empowered by machine learning, we provide multiple pre trained models. You can use serverless data processing and analytics.

Machine learning

Let me explain it in a simple way. You want to teach something to a kid: what is a car, what is a bike? You point at a car or bike and explain what it is called. With machines we shoot in lots of data and they start to see patterns.

• Artificial intelligence: process of building smarter computers
• Machine learning: process of making a computer learn

Machine learning is much easier.

Our CEO: "We no longer build mobile-first applications, but AI-first."

We have a lot of data, better models, and more computing power. That is why machine learning is happening a lot now.

Google created the open source Tensorflow Python framework for machine learning. And we have hardware to match. We have ready to use models for vision, speech, jobs, translation, natural language, video intelligence.

• Vision API: object recognition (landmarks), sentiment on faces, extract text, detect inappropriate content. Disney game: search with your phone for a chair, and we show a dragon on the chair. Point your camera at a house, and you see a price tag.
• Speech API: speech recognition (write out the transcript, support for 80 languages).
• Natural language API: really understand the text that is written, recognise nouns and verbs and sentiment.
• Translation API: realtime sub titles, automatic language translation using more context than earlier versions.
• Beta video intelligence: label detection, enable video search (in which frame did the dog first appear).

Demo

Go to the Google Cloud console and create a free account to play with. You need to enable the APIs that you want to use. Install the command line tools if you want to run it on your local machine. And pip install google-cloud.

We use machine learning for example in GMail to show you a possible answer to send for an email you receive.

Walkthrough of machine learning and TensorFlow

Google Cloud Dataflow. Dataflow is a unified programming model for batch or stream data processing. MapReduce-like operations. Parallel workloads. It is open sourced as Apache Beam, and you can run it on Google Cloud Platform.

You put files in Cloud Storage. Process this in batches, with Python and Dataflow. This uses pre-trained machine learning models. Then store results in BigQuery, and visualize the insights in Data Studio.