List of videos

Angelo Failla - FBTFTP: Facebook's open source python3 framework for dynamic TFTP servers. [EuroPython 2016] [18 July 2016] [Bilbao, Euskadi, Spain] (https://ep2016.europython.eu//conference/talks/fbtftp-facebooks-python3-framework-for-tftp-servers) FBTFTP: facebook's opensource framework for creating dynamic TFTP servers in Python3. ----- TFTP was first standardized in '81 (same year I was born!) and one of its primary uses is in the early stage of network booting. TFTP is very simple to implement, and one of the reasons it is still in use is that its small footprint allows engineers to fit the code into very low resource, single board computers, system-on-a-chip implementations and mainboard chipsets, in the case of modern hardware. It is therefore a crucial protocol deployed in almost every data center environment. It is used, together with DHCP, to chain load Network Boot Programs (NBPs), like Grub2 and iPXE. They allow machines to bootstrap themselves and install operating systems off of the network, downloading kernels and initrds via HTTP and starting them up. At Facebook, we have been using the standard in.tftpd daemon for years, however, we started to reach its limitations. Limitations that were partially due to our scale and the way TFTP was deployed in our infrastructure, but also to the protocol specifications based on requirements from the 80's. To address those limitations we ended up writing our own framework for creating dynamic TFTP servers in Python3, and we decided to open source it. I will take you thru the framework and the features it offers. I'll discuss the specific problems that motivated us to create it. We will look at practical examples of how touse it, along with a little code, to build your own server that are tailored to your own infra needs.

Mircea Zetea - Managing technical debt [EuroPython 2016] [18 July 2016] [Bilbao, Euskadi, Spain] (https://ep2016.europython.eu//conference/talks/managing-technical-debt) Technical debt lives among us regardless if we are in the services business or building products. We discuss about it, we try to fix it or live with it, but can we actually prevent it? My reason for discussing this openly is because once it is there you do not only deal with the technical debt itself but also with the interest you must pay. What qualifies as debt? What qualifies as interest? How do we manage it? Is it really unavoidable? ----- Technical debt lives among us regardless if we are in the services business or building products. We discuss about it, we try to fix it or live with it, but can we actually prevent it? My reason for discussing this openly is because once it is there you do not only deal with the technical debt itself but also with the interest you must pay. My reason for discussing this openly is because once it is there you do not only deal with the technical debt itself but also with the interest you must pay. Comparing the two, probably the highest cost that we see is with the interest. As our code base grows and our deadlines get tougher we tend to forget about the cost our project will have to pay for every functionality that we implement in a hurry, for which we “forget” about tests or for which we write in a comment “this needs to be refactored” or “this is a temporary solution. refactor later”. What qualifies as debt? What qualifies as interest? How do we manage it? At what levels in our projects can we see the debt and the interest? Is it really unavoidable?

Andrés Cidel - Create secure production environment using Docker [EuroPython 2016] [18 July 2016] [Bilbao, Euskadi, Spain] (https://ep2016.europython.eu//conference/talks/create-secure-production-environment-using-docker) The purpose of this talk if pointing out that using Docker in production is perfectly valid, not just for develop and CI environments. ----- Docker is a relatively new technology platform that helps teams develop, deploy and scale applications with greater ease and speed. However, there are doubts about using Docker in production environments. One important reason is that containers don't provide the same security layer as hypervisors do. The purpose of this talk is pointing out that using Docker in production is perfectly valid, not just for develop and CI environments. We'll learn: - How Docker works. - Main risks. - How create and maintain secure images. - How defend containers. - How delimit security risks in containers. - Best practices for running containers.

Andrei Coman - Effectively test your webapp with Python and Selenium [EuroPython 2016] [18 July 2016] [Bilbao, Euskadi, Spain] (https://ep2016.europython.eu//conference/talks/effectively-test-your-webapp-with-python-and-selenium) We will explore the lessons learned on maintaining a Selenium test suite against a webapplication and how to leverage python tools to make this process easy and transparent. ----- How often do you run your Selenium test suite? How fast do you get a result from it? Would you like to answer with: "Whenever I feel like it" and "Well, about the time it takes me to finish a coffee" ? This talk will try to get you closer to these answers. We will have a look at the lessons learned and the challenges my team faced maintaining a Selenium test suite against a long-lived Django web application. We will go over the pros and cons of: - test design approaches - technologies we used (nose, py.test, LiveServerTestCase) - reporting tools

Domen Kožar - What Python can learn from Haskell packaging [EuroPython 2016] [18 July 2016] [Bilbao, Euskadi, Spain] (https://ep2016.europython.eu//conference/talks/what-python-can-learn-from-haskell-packaging) Haskell community has made lots of small important improvements to packaging in 2015. What can Python community learn from it and how are we different? ----- Haskell community has been living in "Cabal hell" for decades, but Stack tool and Nix language have been a great game changer for Haskell in 2015. Python packaging has evolved since they very beginning of distutils in 1999. We'll take a look what Haskell community has been doing in their playground and what they've done better or worse. The talk is inspired by Peter Simons talk given at Nix conference: [Peter Simons: Inside of the Nixpkgs Haskell Infrastructure][1] [1]: https://www.youtube.com/watch?v=TDnZsBxqeBM&list=PL_IxoDz1Nq2Y7mIxMZ28mVtjRbbnlVdmy&index=4 Outline: - Cabal (packaging) interesting features overview - Cabal file specification overview - Interesting Cabal features not seen in Python packaging - Lack of features (introduction into next section) - Cabal hell - Quick overview of Haskell community frustration over Cabal tooling - Stack tool overview - What problem Stack solves - How Stack works - Comparing Stack to pip requirements - Using Nix language to automate packaging - how packaging is automated for Haskell - how it could be done for Python

Dmitry Trofimov - Profiling the unprofilable [EuroPython 2016] [18 July 2016] [Bilbao, Euskadi, Spain] (https://ep2016.europython.eu//conference/talks/profiling-the-unprofilable) When a program is not fast enough, we call on the profiler to save us. But what happens when the program is hard to profile, like for instance the Python Debugger? In this talk we're going dive deep into Vmprof, a Python profiler, and see how it helps us find out why a debugger can be slow. Once we find the culprit, we'll use Cython to optimise things. ----- Profile is the main way to find slow parts of your application, and it's often the first approach to performance optimisation. While there are quite a few profilers, many of them have limitations. In this talk we're going to learn about the new statistical profiler for Python called Vmprof that is actively being developed by the PyPy team. We'll see how it is implemented and how to use it effectively. We will apply it to an open source project, the Pydev.Debugger, a popular debugger used in IDE's such as Pydev and PyCharm, and with the help of Cython which we'll also dig into, we'll work on optimising the issues we find. Whether it's a Python debugger, a Web Application or any other kind of Python development you're doing, you'll learn how to effectively profile and resolve many performance issues.

Miguel Sánchez de León Peque - Developing a real-time automated trading platform with Python [EuroPython 2016] [18 July 2016] [Bilbao, Euskadi, Spain] (https://ep2016.europython.eu//conference/talks/developing-a-real-time-automated-trading-platform-with-python) Nowadays Python is the perfect environment for developing a real-time automated trading tool. In this talk we will discuss the development of: a general-purpose multiagent-system module using Pyro and ZeroMQ; a platform, based on it, for developing automated trading strategies using Numpy, Numba, Theano, etc.; and a GUI for visualizing real-time market data using PyQtGraph and Qt. ----- In OpenSistemas we have developed a general-purpose multi-agent system which is written in pure Python: *osBrain*. Agents communicate with each other using ZeroMQ, allowing the user to define different communication patterns based on their needs. Based on this multi-agent system, we have also developed a broker- independent platform for real-time automated trading: *osMarkets*. This platform implements specialized agents: - **Feeder** is an agent which receives real-time data from the broker. - **Router** is an agent which receives data from feeders. It manages the historical data and distributes updates to all the subscribed agents in the network. - **Brain** is the most common agent. It receives data from router or from other brains and processes them, sending the results to other brains or sending orders to be executed. Brains can make use of many useful packages avilable in the Python ecosystem: NumPy, SciPy, Numba, Theano... - **Trader** is an agent which is designed to interact with the broker, just as the feeder, but to execute market orders.  While it is still in its earliest stages, we are developing a tool for real-time visualization of trading strategies using PyQtGraph. This tool acts as an agent in the multi-agent system. 

Adrian Dziubek - Python Descriptors for Better Data Structures [EuroPython 2016] [18 July 2016] [Bilbao, Euskadi, Spain] (https://ep2016.europython.eu//conference/talks/python-descriptors-for-better-data-structures) Have you ever wondered how Django models work? I'll present a story of data structure transformation. I will talk about ideas from Django models that I used and how I rediscovered descriptor API. I will talk about printing, serializing, comparing data structures and some other examples, where descriptors excel at making declarative code easier to write. ----- I worked as a developer of a testing framework for a C++ server. The framework tested binary protocol implemented by the server. Most of the work involved testers preparing test cases. The data format was primitive structures -- hard to read and easy to break. Field order and all the data had to be entered manually. At the time, I have already seen the better world -- the models from Django. Have you ever wondered how those work? Step by step, I used the ideas from there to make the structures more friendly and on my way I rediscovered descriptors. I'll show in incremental steps, how: - used keyword arguments to lower signal to noise ratio, - order of definition for sorting the fields, - realized that `__call__` is used instead of assignment, - used `__setattribute__` as first step to extend primitive fields, - discovered that I'm actually reimplementing descriptors, and how it lead me to: - implement printing in a way that is friendly to regression testing, - use diff library for less code and better results, - implement more readable validation. I want to show how descriptors work in Python and how they enable declarative style of programming. By the end of the talk I want you to understand what is at the core of the magic behind field types used by object relational mappers like Django.

Amber Brown - The Report Of Twisted’s Death [EuroPython 2016] [18 July 2016] [Bilbao, Euskadi, Spain] (https://ep2016.europython.eu//conference/talks/the-report-of-twisteds-death) This talk will teach you how Twisted or Tornado supplement asyncio, how asyncio can/is integrated with these frameworks, and makes a case for the continued development of new and existing selector-loop based frameworks. It will also paint a picture of the future direction of Twisted, why the original plan of asyncio as a standard API has not come to complete fruition, and what can be done about it. ----- Historically, there has been no “standard way” of doing asynchronous I/O in Python. A variety of solutions, from using threads (WSGI), processes (multiprocessing), green threads (gevent), or selector loops (Tornado, Twisted) have all been used to similar degrees, but apart from the (now deprecated) standard library asyncore/asynchat, Python itself did not have a blessed option. PEP 3156, or “the asyncio PEP”, introduced in Python 3.4, provides this blessed option, choosing a standard selector loop approach (or “reactor”, in Twisted parlance). The role of asyncio may seem muddled in the eyes of developers new to asynchronous programming, or those that may not understand the technical details of asyncio nor the political environment in which it was created. This talk will teach you how Twisted or Tornado supplement asyncio, how asyncio can/is integrated with these frameworks, and makes a case for the continued development of new and existing selector-loop based frameworks. It will also paint a picture of the future direction of Twisted, why the original plan of asyncio as a standard API has not come to complete fruition, and what can be done about it.