Index ¦ Archives ¦ Atom

PyConUK 2016

PyConUK 2016 was in Cardiff this year, from Thursday the 15th of September through to Monday the 19th. I was very much looking forward to attending: I've been a few times before and it is always friendly, diverse, and full of interesting topics and people and my brain was deeply in need of some variation in input.

I travelled up from Cornwall by train. My initial plan was to drive but my car failed its MOT a couple days before departure and there wasn't time to resolve the problem (it's better now). This meant I, like many others, had to deal with train routes to Wales being disrupted by work in the Severn tunnel. This turned out to be mostly painless.

Videos from the conference can be found on YouTube.

Day 0

The train did however mean that I arrived later in the day than I planned on the first day, an open day held in a university hall. I only had time to attend Natural Language Processing in 10 Lines of Code and go to dinner with other delegates at The Clink (a very worthwhile charity and a great meal). Before then I learned from reception at my hotel that for the entire weekend surprise Roald Dahl celebrations would be happening throughout the city.


The NLP presentation demonstrated techniques for corpus analysis using a library over a pre-trained language model (spaCy). This reminded me of a previous life of using singular value decomposition to drive latent semantic analysis. After the session one of the presenters and I chatted. The primary difference between the techniques I had used and the modern word-embedding techniques more frequently used today is that the modern techniques use neural nets trained on a vast corpus of diverse documents to establish similarity whereas the old techniques were usually dynamic for whatever documents were available in the context being studied. The upshot of this difference is that the semantics in the modern techniques are usually more meaningful and less ... latent.

Day 2

My hotel was positioned such that it was possible to walk through a park on the way to the regular venue, the lovely Cardiff City Hall. In the park I spied some giant chairs. Probably a Roald Dahl something.

Python and the Glories of the UNIX Tradition

The opening keynote was given by Brandon Rhodes. He presented on the ties between UNIX traditions going back more than 40 years and the things we know and love about Python. They can be boiled down to:

  • Interaction and immediate feedback is important. This is why we have shells in UNIX and repls in Python.
  • Recursive data structures are great.
  • It is to the system's benefit to be willing to take a few performance hits to make things simpler. The /etc/passwd file is a great example of this. It's just text. Sometimes it feels like we forget this lesson.
  • Having a unified conceptual model is useful: In UNIX everything is a file, in Python everything is an object.
  • Reference counting (on a file or object) is a nice simple way to keep track of stuff.
  • Sharing code is the fundamental building block of community.

At some point in the morning we were informed of the existence of a quiet room:

quiet room

This place was great. Thanks for making it happen.

Django REST framework: Schemas, Hypermedia & Client libraries

An overview of some of the features of the Django REST framework. There was a good deal of discussion about the difference between using retrievable schemas to describe APIs and manage interaction prior to interaction versus hypermedia as a way of describing potential interaction at a point in time.

There was also some discussion of the difference between what was described as "true" hypermedia, wherein an entire application is encapsulated in the available resources, and "lite" hypermedia where link relationships in responses drive interaction.

The clear, and disappointing, piece of advice was that it is critical in these days to have excellent (and complex) tooling in order to effectively interact with either API schemas or hypermedia applications. This is entirely contrary to how I want HTTP APIs to work. What I want is for there to be a small number of documented resources, and we GET, PUT, POST, and DELETE with abandon with relatively simple HTTP clients.

I guess I'm a grape in the path of the steamroller of progress.


At this point I tried to go to some talks in a smaller room and it was simply too crowded to squeeze in comfortably. I escaped to the aforementioned quiet room. It was blissfully quiet, as advertised.

Properties based testing

After that break I was ready to brave the rooms again. A talk planned for another day was moved to this day. An introduction to property-based testing and Hypothesis demonstrated how to use hypothesis to drive property-based tests. I had seen Hypothesis demonstrated by the author at an earlier PyConUK, but this was a good reminder that it a very interesting and potentially very useful tool. Where it is most obviously useful is in tests where a series of hand-rolled examples (or scenarios) are provided to check the sanity of a method. Why should these be hand-rolled? That's error prone. Let hypothesis take care of it for you.

Taking control of your Bluetooth devices

At dinner the night before our tables were decorated with what initially appeared to be candles but proved to be small LED lamps. Being good little geeks we couldn't help ourselves and started playing with them. At first they were flickering a bit like candle flames. When we played with them they started cycling through a variety of colors. We couldn't figure out how to get them back to candlelight-style.

So it was quite exciting that the next day we were instructed on how to use tools available on the Linux command line to control bluetooth devices using a little LED lamp as the target device.

The trick is to somehow manage to sniff or log the bluetooth network activity, identify the relevant device and replay bluetooth commands against it using the tools.

The demo ended by using some Python to create a little mini disco with the lamp.

Scripting across hosts with Chopsticks

Chopsticks is a new tool, similar to Ansible or Fabric, but more purely Python which is able to boot itself onto remote hosts and run arbitrary Python which is here over on that machine there. The author contends that it will be better (once it is fully working) than alternatives because:

  • Fabric requires code to be over there already.
  • Ansible's syntax is three different DSLs in one (the presenter really does not like Ansible).

Lightning Talks

And then it was time for lightning talks. Often these are the best part of a conference because they expose the most new and most weird ideas. Sadly these were the only lightning talks I managed to attend. Crowding and other exhaustion related issues had me running for the park by the time the evening rolled around on other days.

There was lots of fun and/or cool stuff, but by far the most awesome was a 14 year old kid who earlier that day had acquired their own microbit, borrowed their dad's, and managed to create a simple interactive calculator that took input on one microbit and displayed it on another. There was rapturous applause.

Earlier in the day about 300 microbits were made available on a first come first serve basis to people willing to stand in a line during the morning break.

Day 2

A club nearby was making pounding pounding beats until late in the night. I slept in.

An Introduction to Deep Learning with TensorFlow

Peter Goldsborough, a student from Munich, gave an extremely dense overview of TensorFlow, describing the difference between standard, deep and convolutional neural networks.

This was interesting, but it was confusing for me. I wanted less on how (the mechanics of what's going on) a neural network works and more on why it results in good results. We can describe that input goes in one side and probabilities come out the other. Great, why?

(I used to know this (from around the same time as the SVD and LSA above) but I've forgotten.)

Recommended learning place:

The room was so hot and crowded I had to leave immediately after this talk and skip the next one.

Python Library Development

In the afternoon I was the session chair for the talks in one room. This involved introducing the speakers, fielding the mic for questions, and shutting the speakers down if they went over time.

The first talk for the afternoon explored Python Library Development This was description of the process for managing the creation of a new library from the point of creating a new repo, structuring directories, managing tests and test tools, how to set up coverage and lint tests, how to manage CI systems (like travis) all the way through to how to do a release to pypi.

The speaker pointed out appveyor which is apparently CI/CD running on Windows. Many Python libraries ignore this side of things and should not.

So you "want" to maintain a Python legacy code base?

Advice on how to approach a legacy code base:

  • before you touch anything, understand (on many dimensions). Why does this thing exist? Why does it have the shape it has. Make diagrams.
  • read the code and explain it to grandma or rubber duck
  • read docs, or if they don't exist, write them
  • find scale limits
  • build a safety net
  • tests
  • canonical build (they use jenkins, and protect master)
  • monitoring of the deploy
  • visualization tools to discern patterns and see outliers
  • automate automate automate (such as deployment)
  • only once the safety net is in place, work on improvements
  • the code:
    • pep8, flake8, radon
    • pylint is good but needs tricky configuration, otherwise false-positives
  • the people:
    • tdd
    • code review

The rest of the day

At this point I got more involved in helping out with the presentations than taking notes. I was there for:

Day 3

Cleaner unit testing with the Arrange Act Assert pattern

My favorite talk of the conference was about using the arrange act assert pattern to create better tests.

The basic concept is that a unit test should be limited to three small sections that are separated by vertical whitespace:

# Arrange

# Act

# Assert

If possible the Act section should be just one line and should take the form:

result = format

If you find yourself in a situation where existing tests do not follow this form then one strategy is to write tests for the existing tests and then start decomposing the previously existing tests into a better form.

The reason I like this so much is that though the pattern is considered by some to be obvious or self-evident, giving it a name allows the pattern to be wielded in conversation with authority independent of the speaker. It has its own strength instead of being a bit of personal religion. This is very useful in a situation where change is desired but there is quite a lot of contention.

Form Follows Functions

An exploration of architecture to see if historical developments there can help establish ways of discussing current issues in technology.

When new technologies come, there are no pre-existing design patterns, so you have to think about what to do and how to do it. Models from other contexts may help.

The other main advice here was to always follow the five whys trick. I keep hearing that and hope that I can see it more in my daily life. Asking why isn't a criticism. It's a way of being hopeful and progressing.

Ancient Greek Philosophy, Medieval Mental Models and 21st Century Technology

An overview of the history of philosophy as a way of exploring ideas for how to model information to allow unlimited reuse. I was excited to see what this was about. The historical overview was very interesting, starting from Aristotle to the establishment of the logical paradigm.

However, the technology ended up being a desire for tuple-based ontology. Very hierarchical and very class oriented. Made me think RDF and get flashbacks.


Overall a great conference with a good injection of new ideas and perspectives for my OpenStack-exhausted brain. The venue was very good, despite some issues with room size. Everything was orchestrated very well. Thank you very much to the organisers, the presenters and everyone else.

Here's a peach, but no James:


If you found any typos please let me know, I'm my own worst editor.

© Chris Dent. Built using Pelican. Theme by Giulio Fidente on github.