PyTennesee 2015
I came, I saw, I spoke. A quick hit of the talk highlights.
Building Better API Clients
My own talk was on the topic of designing and writing API clients.
I gave a slightly different version of the talk a month later at the Richmond API Craft meetup.
Function decorators
One of my favorite talks was Bill Israel’s talk on function decorators, appropriately titled “Function Decorators: How Do You Even”.
I’m not sure I left this talk having learned much new about decorators - but this owes to the time I’ve spent working with decorators and not to any failure in the talk itself. That said, I enjoyed the talk just the same - it was fantastically well thought out, well prepared, and well delivered. It was, in short, the talk I had thought of giving on function decorators, but far better motivated and organized than the hypotethical one I’d thought about.
Testing requests
Ian Cordasco’s talk was somewhat related to the topic of my own talk, so I made sure to sit in. Testing an API client is an important part of shipping one, this talk, “Cutting Off the Internet: Testing Applications that Use Requests” covered that exactly.
The upshot is that when you’re writing any code that necessarily uses
an HTTP-based service, you should be mocking those requests. If you’re
using the Python library requests then you have a few options, and
Ian’s talk here focused on the vcr model, specifically betamax.
Unlike httpretty or responses - both of which he mentioned I
specifically called out in my own talk - the vcr style actually starts
with a full service call. The tool caches the response, however, in a
source controlled fixture file, so that subsequent calls can be mocked.
The primary difference with this style, implemented using vcy.py or
Ian’s own betamax, is that you don’t have to worry about crafting
fixtures or your own mocked responses. There’s still room and a need for
“regular” mocking of some sort or another, as certain types of responses
like server errors are pretty hard to arbitrarily get out of the
third-party service in question.
Yielding to better code
The thesis of James Powell’s talk, “Generators will free your mind” was that Python generators can greatly simplify a lot of code, making it easier to reason about, more extensible, and often perform better too.
This was another well organized presented talk and I left with a better understanding of how to make use of generators. There were a number of good points, but the one that sticks out in my mind is using generators to, er, free yourself from overspecified argument types. Function expects a list? Use a generator. Function expects a tuple? Can still use a generator. As long as your function is actually a generator, you’ll find yourself covered.
Brown fields and green architectures
Daniel Rocco’s talk, “Clean and Green: Pragmatic Architecture Patterns” went a great way to crystalize some things I’d been thinking about with regard to working with and refactoring “legacy” code.
The biggest takeaway was one probably familiar to functional programmers: keep I/O at the out layer of the application rather than embedded throughout. I’ve since found that explicitly applying this filter to existing code - where is I/O, and any mutation, at that - to be one of the most straightforward ways of identifying bottlenecks and problem code.
One of the lessons I walked away from this talk from was the importance of spending time with other languages (or technologies in general). When Daniel talked about pulling I/O out of your code to the surface I immediately thought of the advice from a Haskell guide on the importance of separating ‘pure’ and ‘impure’, I/O related functions. It’s I/O at the surface and pure functions the rest of the way down. The benefit even in a non-functional language is code that is easier to test, certainly, and usually easier to reason about, too.
Notes
Bill Israel’s decorators talk slides are available on Speaker Deck.
