A Rubyist at a Europython Conference. Day 4.

The EuroPython 2014 conference (@europython) took place late July at the BCC Berlin (Alexanderstraße 11). Find my highlights of day 4 below.

Table of Contents

• Thursday July 24
  • Writing Awesome Command-Line Programs in Python
  • Lessons learned from building Elasticsearch client
  • Farewell and Welcome Home: Python in Two Genders

Thursday July 24

Writing Awesome Command-Line Programs in Python

Mark Smith works for FanDuel and based his EuroPython talk on David Bryant Copeland’s book Build Awesome Command Line Applications in Ruby.

As his talk was the only one on the topic, Mark concludes writing CLI apps might just be a minor concern. Yet, in many cases, they are the best application for the job. Seen as inferior without all the buttons and fancy interfaces, CLI programs are actually more powerful.

Talking toolery, Mark mentioned cli libraries getopt, optparse and discussed argparse in a little more detail. From the third party domain he mentioned docopt, clint and compago specifically. For colorful output Mark recommends using third party library colorama. Using colors makes your program’s output look a whole lot more interesting and long running programs more useable. For adding a progress bar to help making the decision proces around killing a progress or not easier, Mark tips progressbar2.

Mark mentioned INI, Env var, JSON, csv, XML and Apple Plist as configuration options ‘in the box’. Useful third libraries are YAML and Java Properties, in his opinion.

Lessons learned from building Elasticsearch client

Honza Král (@honzakral) is a Python dev for Elasticsearch and shared some of the lessons learned building a client for ‘a fully distributed system and trying to minimize context-switching pains when using multiple languages’ with the EuroPython audience. “The problem with Elasticsearch clients is manyfold. Fragmentation, consistency, completeness, reliability and the many diverse environments… We decided to create our own client instead.”

Elasticsearch is distributed, talks over a REST API, has to perform in different deployment environments and has 96 API endpoints and 672 parameters. Making one client ‘to rule them all’ is therefor impossible. Honza and his team, all experts in their programming language of choosing, created multiple clients to serve the different languages. And: no opinions. Which meant low-level, 1-to-1 mapping to the REST API. Through spike prototype implementation and reference implementation they make sure everyone’s on the same page.

Furthermore, the project mantra was ‘don’t send a man to do a machine’s job’. “Consistency and repetative tasks are not fit for a human. With almost a 100 API endpoints and all those parameters – you don’t want to waste a decent Python engineer on that.” What about documentation? Documentation is written for people by people and usually requires tremendous manual labor. “Which is tedious.” Taking the API definitions as the specs however, the Elasticsearch team managed to create machine parseable (cause JSON) and human readable (again, cause JSON) documentation, pre-generated from Java.

Making the REST API spec part of the Elasticsearch repository, it’s now used in the main test suite, serves as a reference for the developers and functions as a script to generate clients. The unified test suite is running as a part of the Java test suite and all language’s clients have an interperter for these tests. With this process in place it took their JavaScript developer mere weeks to write an interpreter for the test suite and a parser for the client. Cool Stuff.

Farewell and Welcome Home: Python in Two Genders

Naomi Ceder (@naomiceder) transitioned from male to female ‘after half a lifetime’ while staying involved in the Python community and lived to share her side of the diversity story at EuroPython. And it’s an impressive story indeed, as Naomi knows the difference a change to one variable can make.

Before the transition, she was very involved in the Python community, and would be teaching and speaking at conferences. Life was good but she knew she was still transgender and a transition was her only chance of … having a life really. Unfortunately that traditionally means giving up everything. Organizing Pycon and all.

The business case for diversity is that diverse groups solve problems better, we’ve all read the studies. In the Open Source (Python) community the same should hold, Naomi reasons. Yet, she’s (almost always) the only (openly) transgender person in the room. She is not “real”. Once an acknowledged part of the community she has become ‘a thing, a curiosity, a joke’. People are sometimes embarrassed to be seen with her. She doesn’t have rights and a higher risk of violence and death. More-over, she lost friends, family and a career.

Over the years, Naomi has come to know many other women in tech – ‘scary smart women’. “Women who aren’t always recognized, who don’t always feel welcome. Women who don’t always feel safe. I am a newcomer in a world I thought I knew. I am now often the only woman in the room. I can no longer assume personal security. I am now ‘invisible’ as a professional, yet always judged by my appearance.”

If you are marginalized, your needs are ‘special’ and ‘extra’, Naomi said. You’re never quite sure you’re welcome. Objecting (or even just reporting) something is: ‘angry’, ‘hurting your own cause’, ‘bullying’, a ‘witch hunt’ or ‘asking for it’. “So what do ‘we’ want/need?” It’s very simple really. Understand that everyone’s different, listen. Codes of Conduct matter, so do outreach, allies and safe spaces.