List of videos

Naomi Ceder - PSF Meeting [EuroPython 2016] [20 July 2016] [Bilbao, Euskadi, Spain] (https://ep2016.europython.eu//conference/talks/psf-meeting-2016) EuroPython Meeting of the Python Software Foundation Members and non-members are invited to this EuroPython meeting of the PSF! Please join us for some updates from the PSF board.

Andrew Svetlov - Introduction to aiohttp [EuroPython 2016] [20 July 2016] [Bilbao, Euskadi, Spain] (https://ep2016.europython.eu//conference/talks/introduction-to-aiohttp) aiohttp is asynchronous HTTP client and server library built on top of asyncio. The intro describes basic programming patterns for both client and server API as well as more advanced techniques. The main target of the talk is displaying an alternative to people who want to avoid classic WSGI frameworks (Django/Flask/Pyramid etc) limitations but found Twisted and Tornado too cumbersome. ----- aiohttp is asynchronous HTTP client and server library built on top of asyncio. The library allows to write user friendly code which looks like well-known linear one (requests library for client and Django/Flask/Pyramid for server) but utilizes the power of non-blocking sockets and supports websockets natively. The intro describes basic programming patterns for both client and server API as well as more advanced techniques. Tips and tricks for writing asyncio-based code are included as well. The main target of the talk is displaying an alternative to people who want to avoid classic WSGI frameworks (Django/Flask/Pyramid etc) limitations but found Twisted and Tornado too cumbersome. Dive into aiohttp usage with the library author.

Sebastian Neubauer - Infrastructure as Code: "pip install" your environment [EuroPython 2016] [20 July 2016] [Bilbao, Euskadi, Spain] (https://ep2016.europython.eu//conference/talks/infrastructure-as-code-pip-install-your-environment) In this talk I will show how to build your own infrastructure- as-a-service on the example of "Postgraas", an open source postgres- as-a-service I wrote in python just for fun. With a simple curl request you can get your very own database, just like RDS on AWS. You will learn how easy it is to create such a remarkably useful service with hardly three hundred lines of flask, docker and some glue-code, a project for a rainy Sunday. ----- Continuous Delivery, DevOps, Lean - all those movements have one thing in common: extending the process of software development along the whole value stream, ultimately to the customer. This simple requirement causes surprising serious difficulties on traditional operations workflows. All of a sudden, a single manual ticket to the operations team is a critical blocker in the delivery process. Therefore all parts of the infrastructure, storage, databases, identities, compute resources must be provided as a self service for the developers in order to be able to achieve this goal. What one may call "the cloud" (including self hosted ones like open stack) is such a successful model not least because they offer exactly this "ticket- less" self-service. But why should we wait for "the cloud" to offer what we really need? We are python developers, we are hackers! In this talk I will show how to build your own infrastructure- as-a-service on the example of "Postgraas", an open source postgres- as-a-service I wrote in python just for fun. With a simple curl request you can get your very own database, just like RDS on AWS. You will learn how easy it is to create such a remarkably useful service with hardly three hundred lines of flask, docker and some glue-code, a project for a rainy Sunday. After the talk you will know how to amaze your colleagues by eliminating an annoying ticket or manual workflow with a simple flask app and some creativity.

Miguel Cabrera - Things I wish I knew before starting using Python for Data Processing [EuroPython 2016] [20 July 2016] [Bilbao, Euskadi, Spain] (https://ep2016.europython.eu//conference/talks/things-i-wish-i-knew-before-starting-using-python-for-data-processing) In recent years one of the ways people get introduced into Python is through its scientific stack. Although this is not bad, it may lead to learn solely one aspect of the language, while overlooking other idioms and functionality included in Python as well as some basic software development good practices. I will share some useful tricks, tools and techniques and software design and development principles that I find beneficial when working on a data processing / science project. ----- In recent years of the ways people get introduced into Python is through its scientific stack. Most people that learned Python this way are not trained software developers and many times it is the first contact with a programming language. Although this is not bad, it may lead to learn solely one aspect of the language while overlooking other idioms, standard and common libraries included in Python as well as some basic software development good practices. This may become a problem when a data science project is moved from an experimentation phase to an integration with technical environment. In this talk I share some useful tricks, tools and techniques and as well as some software design and development principles that I find beneficial when working on a data processing / science project. The talk is divided into two parts, one is Python centered, where I will talk about some powerful Python construct that are useful in data processing tasks. This include some parts collections module, generators and iterators among others. The other I will describe some general software development concepts including SOLID, DRY, and KISS that are important to understand the rationale behind software design decisions.

Kali Kaneko - Against the silos: usable encrypted email & the quest for privacy-aware services [EuroPython 2016] [20 July 2016] [Bilbao, Euskadi, Spain] (https://ep2016.europython.eu//conference/talks/against-the-silos-usable-encrypted-email-the-quest-for-privacy-aware-services) At the LEAP Encryption Access Project we aim to make secure communications both easy to use and easy to provide. We bring some tales (and some, hopefully, tools) from the quest for user-friendly crypto software. How to make people love the email experience in the 21st century, without risking their privacy. How to encrypt data locally, sync it to servers that you can lose, and still be sexy. ----- Technologies that allow for privacy in the communications, allowing the escape from the pervasive massive surveillance, have been there for some years now, but yet its use by the general public is far from widespread. The challenge, in our view, can be defined by one of making usable crypto. Usable for the end user, usable for the sysadmin and for the fellow application developer. In the quest for massive adoption of encryption technologies, we've been forging several python packages to solve different problems, always standing in the shoulders of giants. We bring some tales from the trenches to share, from our humble experience trying to deploy clients and servers to provide Secured Encrypted Internet Tunnels and Encrypted Email. This includes interesting challenges dealing with key management, automatic and secure software updates, and processing of email while using stock cloud providers, while still being resistant to hostile environments. We'll show a webmail email user agent based on this architecture, a promising future for decentralization and privacy. We'll also talk about how to store locally encrypted data, and will present Soledad (Synchronization of Locally Encrypted Data Across Devices). Soledad is a library with server and client components that allows the development of different applications based on client-side, end-to-end and cloud-syncable encryption of private data. We'll play with some toy apps to showcase its features and potential.

Erik Näslund - Building a reasonably popular web application for the first time. [EuroPython 2016] [20 July 2016] [Bilbao, Euskadi, Spain] (https://ep2016.europython.eu//conference/talks/building-a-reasonably-popular-web-application-for-the-first-time) These are the lessons learned when scaling a SaaS web application which grew much faster than any one us could have ever expected. - Log and monitor from day one. - Things will fail, be sure you know when they do. - Choose components which allow language interoperability. - Horizontally scalable everything. - Plan for database downtime. - Have a way to share settings between backend and frontend. - Have a way to enter maintenance mode. - And more... ----- My name is Erik Näslund - I’m the co-founder and Head of Engineering at Hotjar. I'd love to share the lessons learned when scaling a SaaS web application which grew much faster than any one us could have ever expected. Words like “big” and “popular” carry very little meaning, so let me define how big Hotjar is right now using some numbers. We onboard about 500 new users on a daily basis. We process around 250 000 API requests every minute. Our CDN delivers about 10 TB of data per day. We have roughly 3 TB of data in our primary data store (PostgreSQL), another 1 TB in our Elasticsearch cluster, and a LOT more on Amazon S3. These are the key things we wish we knew when we started. They would have made our life so much easier! - Log and monitor from day one. - Have a way to profile your API calls. - Things will fail, be sure you know when they do. - Have a way to keep secrets. - Everything needs a limit (even if it's really big). - Be wary of hitting data type limits. - Don't get too attached to a framework. - Choose components which allow language interoperability. - Horizontally scalable everything. - Plan for database downtime. - Features are a great way to test things out before launching them to the public. - Have a way to share settings between back end and front end. - Have a way to enter maintenance mode. - Require different quality of code for different parts of your application.

Anders Hammarquist - Metaclasses for fun and profit: Making a declarative GUI implementation [EuroPython 2016] [20 July 2016] [Bilbao, Euskadi, Spain] (https://ep2016.europython.eu//conference/talks/metaclasses-for-fun-and-profit-making-a-declarative-gui-implementation) When standard Python syntax doesn't cut it, apply metaclasses to make it do what you want. Here I present our metaclass-based implementation of a declarative GUI layout syntax to inspire ideas for what to do when your goals don't fit the Python syntax. ----- When overhauling the user interface of Autolabel's labeling printers, we wanted a clean way to describe the layout of the settings widgets. The structure we came up with was a declarative class layout that leverages Python's metaclass concept to build the underlying GTK widget structure. I will present the implementation to hopefully inspire you to apply metaclass techniques to problems that standard Python syntax can't quite solve. If that fails, you will at least have a way to declaratively construct GTK GUIs. A short, non-exaustive, summary of concepts I will mention includes metaclasses (obviously), class hierarchies, method resolution order, super(), and anecdotes of dealing with GTK. You may find some similarities with my talk on Python as a domain specific language at Europython 2006 http://indico.cern.ch/event/44/session/41/contribution/35 Slides are available at https://www2.openend.se/~iko/ep2016 Example code on Bitbucket https://bitbucket.org/iko/ep2016-declarative-gui/

Larry Hastings - The Gilectomy [EuroPython 2016] [20 July 2016] [Bilbao, Euskadi, Spain] (https://ep2016.europython.eu//conference/talks/the-gilectomy) CPython's GIL means your Python code can only run on one CPU core at a time. Can we remove it? Yes, we can... in fact we already have! But is it worth the cost? ----- CPython's "Global Interpreter Lock", or "GIL", was added in 1992. It was an excellent design decision. But 24 years is a long time--today it prevents Python from capitalizing on multiple CPUs. Many people want us to remove the GIL. It turns out, removing the GIL isn't actually that hard. In fact, I already removed it, in my experimental "gilectomy" branch. But the GIL is one reason CPython is so fast! The "gilectomy" makes CPython shockingly slow. This talk will discuss the history of the GIL, how the GIL helps make CPython fast, how the "gilectomy" removed the GIL, and some ways we might be able to make the "gilectomy" version fast enough to be useful.

Victor Stinner/Larry Hastings/Christian Heimes/Yury Selivanov - Core Developers' Panel [EuroPython 2016] [20 July 2016] [Bilbao, Euskadi, Spain] Q&A session with Python core developers