I semi-regularly do a braindump of my ideas for running inclusive conferences, and I realised it would be useful to have it all written up in one place. Last week, I had a meeting with Lauren Couch, the head of Diversity and Inclusion at Wellcome, and she was kind enough to lend me the notes she wrote – this is the tidied-up version.
For better or for worse, conferences can be really important for career development. Sharing ideas, having conversations, meeting new people – if you can’t attend conferences, you miss out on a lot of these ooportunities. It’s important to open these events to as wide a range of people as possible, and make them feel welcome when they attend. It addresses a serious unfairness, and everyone benefits from having a wider diversity of people and ideas.
This is mostly based on my experience with small, community conferences in the European tech industry. Underrepresented groups in tech include women, people with disabilities, people on low income, people who don’t have European or US citizenship – and the suggestions reflect that. It definitely isn’t a complete list.
If you’re an event organiser, you can take these ideas to make your events more inclusive and accessible.
If you attend, speak at, or sponsor an event, you have power – you can ask for these accommodations where they don’t already exist. Be picky about where you choose to participate, and walk away from events that don’t meet your standards.
For a while, I’ve been whinging on Twitter about Scala compile times – mostly driven by the ever-increasing length of the Travis builds at work.
Somebody made a comment on Friday about how we don’t really track our build times, just our gut feeling. “They seem to be getting slower.” Since the Travis API provides a whole heap of information about builds, I decided to dig into the data to find a pattern.
This post contains the code I used, in case it’s useful to somebody else.
Here’s a screen I encounter while driving in Apple Maps, with worrying regularity:
I’m driving along, using turn-by-turn directions, and suddenly this route picker pops up instead.
This is a pretty dangerous distraction.
There’s lots of information on the screen, which means I have to look away from the road to read and understand it. Ideally I’d pull over (which is how I got this screenshot), but that isn’t always possible. The text is small – less than 2mm high on my iPhone SE – which makes it slower to read. And it’s taken away my instructions, and distracted me from actually driving.
When you’re driving, even a momentary lapse in concentration can be dangerous, even fatal. I’d love to see this screen go away in iOS 12.
(My phone is a few years old, and I think it gets confused about when I’m moving. I wonder if the screen is only meant to appear when you’re stationary, and my phone makes bad guesses about when I’ve stopped.)
I’m a heavy user of Travis CI. If you don’t know it, Travis is a service for automatically building and testing your code. You tell it how to run your tests, and when you commit to GitHub, it runs your tests and tells you the result. I use Travis to run tests at work, test and release several open source projects I work on, and it even builds this blog!
A sudo enabled, full virtual machine per build, that runs Linux, either Ubuntu Precise 12.04 or Ubuntu Trusty 14.04.
A fast boot time environment in which sudo commands are not available. Running Linux Ubuntu Trusty 14.04.
The container-based builds are usually much faster, and I prefer using them when I can. The main distinction for me is “do I need Docker” – I use Docker in a lot of my projects, and that’s only available in the sudo-enabled builds.
In your Travis build, you can have multiple “jobs” – processes that run on different build machines. For example, you might test your Python library with three versions of Python in three separate jobs.
Until recently, I thought sudo-vs-containers was all or nothing. If any of my jobs needed sudo, I had to add sudo: required at the top of my Travis config, and every job would get the slower VMs – even if they could run in a container instead.
Thanks to Anthony Sottile, I know that’s no longer the case! Anthony opened a pull request for Hypothesis adding Python 3.7 support to the build, which requires a sudo-enabled Travis build machine. This is the relevant snippet from the build config:
Adding sudo: required to the individual job runs the py37 job in a sudo-enabled environment, but the py35 and py36 jobs still run in containers.
I’ve changed a number of my builds this way to run more jobs on containers, and it’s made a nice improvement in build times. It also makes it easier to add sudo-based jobs to builds in future, because I don’t have to take a penalty for switching the other tasks to VMs.
I used to manage my calendar with iCloud. I have basic needs, and it seemed like a good fit – until I discovered the following unexpected restriction:
iCloud Calendars keep information from the last six months, and up to three years in the future.
The practical upshot is that iCloud has been deleting my old events – it doesn’t have anything from before January this year.
Silently deleting old user data is dubious, because a lot of people won’t realise it’s missing until it’s too late to make another copy. (See also: the horror stories about iMessage deleting threads on your phone to free up space.)
I like having my historical calendar – it’s a nice companion to my written journal – and so I decided to switch away from iCloud.
Since I already use FastMail for email, I looked at their calendar service. It fits my needs, and their support team confirmed they don’t have any time limits or auto-deletion policies. I followed their migration instructions, and now I’m using FastMail and CalDAV instead of iCloud.
It wasn’t hard, but it was annoying, and I wish Apple were more upfront about this “feature”. (Or heck, retain events forever!)
A coworker was reviewing one of my pull requests yesterday, when she pointed at the screen and asked, “Is that meant to be there?” Somehow, an SSH private key had appeared in the diff!
The key in question gave push access to our main repository (it was configured as a deploy key with write access). It was only for that repository, and we’d be able to restore everything from local clones; it would just be a massive faff.
I rushed back to my desk to revoke the key and work out what had happened, and I was pleasantly surprised by an email from GitHub (emphasis mine):
We noticed that a valid SSH private key of yours was committed to a public GitHub repository. This key is configured as a deploy key for the wellcometrust/platform repository. Publicly disclosing a valid SSH private key would allow other people to interact with this repository, potentially altering data.
As a precautionary measure, we have unverified the SSH key. You should should generate a new SSH key and add it to the repository.
Comparing timestamps, this email was sent almost as soon as the commit landed. Attempting to push to the repo using the leaked SSH key would fail. Even if we’d missed the diff, we were still protected against malicious commits.
I’ve heard stories of Amazon scanning public GitHub repos for leaked AWS credentials, and proactively revoking them, but I never thought something like that would happen to me.
Thanks for protecting us, GitHub!
How did this happen?
So how did an SSH private key end up in the commit history?
Nobody had checked it in, accidentally or on purpose. None of us even had a local copy!
No, our SSH key was leaked by one of our build jobs in Travis CI.
To keep our code tidy, we run a number of autoformatters against our repository (scalafmt, terraform fmt and autoflake). On pull requests, we have a Travis job that runs the autoformatting, puts the changes in a new commit, and pushes the changes to your PR.
To allow Travis to push changes, we give it an SSH private key in an encrypted zip file. The corresponding public key is configured as a deploy key on our repository. Travis unencrypts and unzips the file at runtime, and loads the private key into its Git config.
I’d been tweaking our GitHub deploy keys to manage them with Terraform. Previously the encrypted zip was unpacked into a dedicated (and gitignored) directory; now the files are unpacked into the repo root. Which is fine… until the autoformat script comes along, and tries to add every change to a new commit. It saw the private key as a new, untracked file, and included it in the commit.
How do I stop this happening again?
Aside from rotating out the compromised key, I’ll be making some changes to avoid a repeat of this exact scenario:
Add the private key file to .gitignore. I should have done this already, I was just lazy.
Use git add --update instead of git add --all in our autoformat script. That should stop the script adding random files it finds lying around the repo (which can also include AWS credentials).
The autoformat script gets a list of changed files before it decides whether to commit – if the list is empty, nothing has changed and it can exit early. It knows what sort of files should have changed (e.g. only files ending in .py for the Python formatter), so I’ll change it to error if it spots an unrecognised file.
This isn’t the first time I’ve made a daft security mistake, and it won’t be the last – and the next one will probably be something completely different. Best I can hope is that I’ll be similarly lucky, and whatever it is won’t be an expensive mistake.
I moved house recently, and this evening I was setting up my iMac. My particular machine is nearly five years old, and like every iMac of the last decade, all the USB ports are on the back of the machine.
It’s awkward to plug stuff into those rear ports, because I can’t see them. I fumble to get something in the right place, and only then do I find out if I even guessed the correct rotation. (For all having to buy dongles for USB-C is annoying, the symmetric connector is a really nice change.)
Sometime since my last move, I bought a USB extension cable and plugged it into one of those ports – and ran the other end round the front of the computer. Suddenly I can see the port, get the rotation right on the first try, and I’m not leaning over my desk to plug stuff in. If you’re an iMac owner who ever uses the USB ports, I really recommend it. They’re fairly cheap on Amazon (example, affiliate link).
In an ideal world, the next iMac design will feature easily accessible ports – until then, this is a good workaround.
When I’m writing scripts, I often have some tabular data that I need to present. This data might show the number of website hits per day, or which pages had the most errors. Here’s an example of the sort of tabular data I mean:
I want to print it in a way that’s easy for me to read, and makes the trends stand out. It’s hard to get a sense of the overall picture without reading the individual numbers – I’d much rather have a bar chart.
If I was being fancy, I could use matplotlib and draw a graphical chart – but if I’m running a shell script in the terminal, it’s not always convenient to display images. I’d rather print something I can view in my terminal – an ASCII bar chart.
There are probably libraries that can do this for you, but I found it simpler to write my own snippet to draw bar charts.
Last week was Google I/O, and there was a lot of discussion around one of their keynote demos: Google Duplex. This is a service that acts like a human, and makes phone calls on your behalf. You can watch the demos on YouTube – one has Duplex booking a haircut, another trying to book a table at a restaurant.
From a technical perspective, I think it’s very impressive. I still have memories of primitive speech-to-text voices, so the vocal quality of that demo and the understanding of the other person and the near-instant responses feels very futuristic.
But I’ve heard people dismissing it as a toy for rich lazy people, and that feels a bit ableist to me.
Lots of people have trouble with phone calls, for a variety of reasons. Maybe hearing is difficult. Perhaps they can’t speak, or they have speech difficulties or an accent that make it hard to be understood. Or they have anxiety talking to strangers on the phone, or waiting on hold uses energy they don’t have.
Giving those people a way to use phone trees/voice-only interfaces? That could be a great step forward for accessibility.
Calling it “lazy” is like shaming somebody for not using the stairs, or for buying pre-cut fruit and veg. You might not need it, but maybe they do.
I’m not somebody who needs this, but I feel icky seeing people so quick to pass judgement.