Saturday, August 20
Welcoming & Keynote by Raymond Hettinger
Raymond was a great speaker, he has a great sense of humor and was a wonderful story teller. He started his talk sharing of his adventures in the Open Source world – being lost in Shaghai and python (particularly Python Cookbook) gave him the ability to connect to someone who helped him. He shared Doctor Sue quotes and Hunger Game quotes. He was very fun. He followed up on Jessica Mckellar‘s call to action from the night before – ‘what you can do to make change.’ He shared how attendees, today, can contribute to the community and walked through 6 different tasks. He also shared his values of how to be a good neighbor (how to be a good contributor). My favorite one was “Don’t trample other people’s flower gardens (collections, random, itertools, enum).’ I really like this one because it shows that its a community and that we are all building towards a better community. Instead of changing other people garden(code), why not go to a patch of space and make something new. Of course it is still really important to go to other people’s garden to see how they structured their plot and how they arranged their flowers to optimized for sun/shade/water.
Python 103: Memory Model & Best Practices (Wesley Chun):
Wesley started with sharing that the best feature of Python isn’t its code, but its community. He then went into his best practices in 9 parts, some great take aways:
- Minimizing function/method calls
- You don’t need list comprehensions, just generator expressions
- Being aware of your refcount
- Wesley totally said ‘You must unlearn what you have learned’ in a yoda voice (that sounded a little bit more like Miss Piggy, teehee)
- 3 Models of Data Types: Storage, Update & Access
- Mutability is like the butler… they probability did it
A/B Testing: Harder than just a color change (Or Weizman):
Or works at Yelp and he shared an example of A/B testing that they had with yelp’s food ordering feature: which is best color and layout. So they did some testing. They started with generating a hypothesis, getting necessary data (the data for current clicks and secondary metics of users starting orders, adding items and completing orders. Since they wanted to test for several things, the implementation couldn’t just be that 50% under the control and the 50% getting a combination of color and layout. They decided to implement the idea of “swim lanes.” This means that the 50% that are being tested, 1/2 of those go into a one lane- which half of those see the different layout and the other does not – and the other 1/2 are divided into the 5 color possibilities.
By using swim lanes, the experiments can stager (have different start and end dates) and if the layout change was the best along with the color green, they can test the combination if future data is needed.
Exploring complex data with Elasticsearch and Python (Simon Willison):
Simon demoed the denormalized query engine design pattern where he uses relational database to keep data and a Document Index (in the demo he used Vesspa). The art is in choosing which data to denormalize for separate search index and suggested to keep the object ids(primary keys) in this data. That way, if data is stall, a cron job can be queued up to update that record using its primary key. He stressed that if you are providing the user their own data, to query directly to the database because the Document Index can take a bit to update. But doing this pattern you gain horizontal scalability, new types of query and aggregation, but you do loss few seconds for indexing delay. His demo was built to search Django Documentation – it was amazingly fast. Elastic search guesses the keys and you can use mapping to describe your index structure, giving you more control.
Simon used Sense and Kibana (Elastic Search interface is JSON over HTTP) to demo the queries.
Since the index document needs to reflect the relational database, indexing codes needs to track the most recently seen ‘last_touched’ data time. Simon suggested using Redis/Kafka (message brokers) to have cron jobs keeping the data updated and properly indexed.
Flask for Fun and Profit (Armin Ronacher):
Armin is the creator of Flask and it was amazing to learn how he uses Flask. He built it because he wanted to build software, he was inspired to build ‘trac’ and he wanted to put programmer into control of configurations. Flask has a limited box, but its fast, tests well and good with json, apis and http; it does lack in regards to high performance async IO.
His favorite was to structure create an app is through a function:
This allows the ability to make many apps with different configurations and its easier to test. He also showed an alternative way of containing the app in an object. This pattern is particularly useful when your app exposes an api that others are going to use.
He runs his app differently too! Instead of using app.run(debug=True), he runs it through the command line as flask run:
He does this because with app.run() is normally at the end of a file, so the file runs and the code is read and then needs to run again on the command app.run(). Also, $ flask run automatically reloads as well.
When he is validating, he likes to use voluptuous:
There are a lot of great extensions to flask and one of his favorites is SQlAlchemy(connects python object relational mappers to sql).
He improves security by using context, which can limit queries -that way users only see what they are suppose to see (you can query with an organization id and validate with a user id). There is also JSON escaping that protects you when you are using templating and htmlsafe_dumps.
Armin does testing with pytest by making an app client and uses assert:
This give you the value of the expressions so when the test fail you know have more data.
Did you know that the image on flask isn’t a chili pepper but a horn?
Building Tic-Tac_Toe 2 Player Game with Tornado over Web-sockets (Ramesh Sampath, slides):
var ws = new WebSocket(ws://<endpoint>)
To send message:
To receive message:
This gives a persistent connection, two way communication and is non-blocking. In order to keep several games going, he added ‘game state’ with an id – uses a GameManger class, he generates a game_id starting from 100 and increasing by 1. To push this onto the web, Ramesh uses only external library, tornado, which is a web framework which is single threaded.
The server only has two routes, the first one shows the html of the site and the other way is the web-socket that opens, send/receives messages and closes connection. He suggested having a load balancer that the client request so you can have many tornado processes and then using a cron job to maintain game state as a further task.
Then there was a job fair and drinks.