PyCon US 2017 (David and Mattias)
Written by Mattias Sluis and David van Buiten
Elements sent three fine developers on a plane to Portland in the US to attend PyCon 2017. David van Buiten, with help from Mattias, wrote his impressions and learnings from the conference down in a fresh blog post.
After a long trip I finally arrived at Portland PDX. It was a long flight from Amsterdam but I got through it watching, sleeping, standing and walking around in the airplane. Overall it was a very smooth flight no turbulence at all and the crew took good care of us. At the airport I took a taxi to my hotel, which was really close to the convention center it was just a five minute walk — great work booking, Stephanie! I registered myself at PyCon and went for a small walk through the city. However, at 4 o’clock the jet lag kicked in.
Day 1
Opening reception
The next day was all about wandering around downtown. At 6 I met up with my colleagues Mattias and Łukasz and we attended the opening reception of PyCon. A lot of off goodies were scored here. We selected a couple of talks that we found the most interesting of the conference, all talks can be watched on YouTube and we really recommend seeing them (or at least the ones you find interesting).
Constructive Code Review
The description of this talk held by Erik Rose immediately got my attention: “Your code is bad and you are bad. Have a bad day.”
It was a very fun talk about given people good criticism in a fun, polite and honest way. I believe that getting a code review should not suck the live out of you as a developer. Instead it should help you become a better developer and it is in no way criticism on your work. Do not hurt people’s feeling but ignite their spark so that they can learn and get enthusiastic about their job! Although this was a talk about “open source” this is something that applies to all of us working with pull/merge requests and code reviews.
So let’s all make this part off our daily routine when reviewing code! Think first before writing down your comments. Is this a new employee? Do I get my sarcasm across in a written review? Should we have a face-to-face discussion (always write down the results in the code review)? Am I nitpicking/proofing my point? Does this really need to hold back this merge? Etc.
Day 2
Keynote
The second day kicked off with a great keynote from Lisa Guo and Hui Ding from Instagram on how Instagram runs on Python/Django and how they recently migrated to Python 3. It was very interesting to see how they approached the challenge of upgrading a large and quickly evolving code base. They ended up slowly making there code base compatible in a way that would limit the impact on regular development. During this process there was no slowdown in the development and/or release of features, in fact, development speed of features actually increased. In the end the switch to Python 3 went without any downtime. Sometimes, at our clients we deal with large code bases and large migrations which made it really interesting to see how a large platform like Instagram deals with this and what motivated their choices.
How documentation works, and how to make it work for your project
This was a great talk by Daniele Procida. So we all agree that documentation needs to be included in our projects and that it needs to be good, right? All developers try hard to make documentation and although they put a lot of effort into it, it’s not always a success. Daniele’s talk is all about how to make better documentation without doing more work, so that sounded really interesting.
Documentation can be divided into 4 parts:
1. Tutorials
- Show how a user can setup your project to work
- Give them a great start using your project
2. How-to guides
- Show a user how to solve a problem using your code giving examples
- Make sure that this is working always
- Think of this as a to-do list to accomplish a certain goal (like how to cook dinner)
3. Reference (This is what most developers will think of when writing documentation)
- This should be more technical and information oriented
- Show a user how to use the different parts of your project
- Should always be up to date
4. Discussions/Explanation
- This will give a more in-depth view of how and why your project is what it is
- Hard to write
A developer usually only makes the reference documentation. And as we can see the four topics are all related. So let’s not forget what each topic is about. It is hard to keep the four parts apart because they have so much similarities, but when done right, it can really benefit your project.
When the abyss gazes back: staring down Python’s surprising internals
This talk given by David Woleverand one other talk (How to write a Python transpiler by Russell Keith-Magee) gained our interest and provided some insight into what is happening under the hood of Python, looking at the byte code of your Python programs and reading the C code of Python itself.
Although a greater understanding of Pythons internals doesn’t directly affect day to day development it is always good to have some knowledge of this and know how to navigate Pythons’ source code in case you want to understand how things work.
Day 3
Arriving on the last day already we got a trip down memory lane with some of the old generals of Python, including Python benevolent dictator for life, Guido van Rossum himself. We heard several stories of the early days of Python, the start of the community, the first PyCon (called SPAM back then) and how Python had to beat Perl.
After this panel discussion it was time for the job fair/poster session, a three-hour slot reserved for people to explore opportunities with some of the bigger and smaller tech companies (primarily located in the United States) and to have discussions on several projects that are mostly science, environmental or educational focused. After a quick round looking for more swag and interesting topics there was a great opening to see if the nearby mall would sell some nice souvenirs to bring home. And after lunch the time had come for the last three sessions.
Hacking Classic Nintendo Games with Python
In this talk by Sam Agnew, he created an SMS powered “Game Genie” live on stage. And before we knew it we where playing the original Legend of Zelda! He also explained a little bit about how to hack the game by altering the memory allocated by the game. So with a quick search on the internet we where able to give him all the rupees he needed, the master sword, infinite lives and finally crashing the game all the time :)
Closing keynote
The conference ended with a closing keynote from Google’s Kelsey Hightower who spoke on Kubernetes for Pythonistas. He pointed out that everywhere in the world people expect products to be delivered as a complete and ready-to-go package.
Like apps on our smartphones for example: we install the app and expect it to work. Software delivery/deployment for web developers (and in this case specifically Python developers) often gets messy. We tend to deliver products that rely on other components to be (pre)installed on systems, which often makes installing our products cumbersome (for instance, you need to compile some plugin or package).
Kelsey challenged us to deliver full packaged Docker images that are ready to run and easy to deploy to a platform like Kubernetes. He demonstrated to use some simple example applications that he than deployed, upgraded and scaled using voice commands of Google’s Assistant.
Thanks Elements for the opportunity to attend PyCon 2017!
Originally published at www.elements.nl on June 2, 2017.
