Brighton Ruby 2016

Recently I spent a lovely Friday in Brighton hearing talks and chatting with some amazing Rubyists.

This was my first time attending Brighton Ruby and it won’t be the last, the mix of topics and formats was great – we were treated to a mixture of talks, lightening talks, and even a live version of Just a Minute.

Opening Remarks

Andy Croll kicked everything off with some opening remarks. I liked that a Code of Conduct was mentioned and I really liked the idea of the physical job board and thanks board.

These were physical places you could go to write a note down, in the case of the job board it was if you were hiring or looking for a job. In the case of the thanks board, it was to publicly thank members of our community. Lovely.

Security is Broken

Eileen Uchitelle was first to speak – she gave an excellent talk on the topic of security. She started to explain why security is broken. Here were my main takeaways;

• It is easy to become jaded when doing security
  • It is impossible to test all the vulnerabilities
  • Hackers are always one step ahead
  • Patching exposes new factors
• We failed to enforce web standards, the browser wars was won based on features, not solid security
• We don’t really know what “secure” looks like
• We rarely get ahead of the game, we are always reacting to security alerts
• In general, not enough developers understand the main vulnerabilities

Eileen then took us through CSRF, XSS, and XXE attack vectors, explaining what they were and how to deal with them in Rails applications.

Her examples were concise and the advice was immediately actionable.

I won’t share all my notes for each of the attack vectors, but I will share some excellent advice the talk closed with;

• Take time to understand the vulnerability before patching it
• Write tests to handle the security patches
• Use brakeman on all rails sites
• Don’t assume you are safe

The Point of Objects

John Cinnamond led us on a brief history of development, talking about the first computer to store programs in memory (The computer was nicknamed Baby).

Back then development used to be all about the machine and the languages reflected this, John posits that perhaps caring too much about the machines we were writing code for have stifled the computer revolution.

Nowadays languages care less about the machine and more about development (and developers) this allows us humans to be more productive.

Complete aside, John had a great line which cracked me up;

If Procedural Programming is so great, why don’t I marry it?

I really liked how John talked about Object Orientated design, he called it the art of deferred caring.

OO is not about technology, it is a technique for people to write better code by deferring thinking about the logic they will need later until later!

When coding it is good to stop and ask yourself – what do I want to achieve with this code, and does it help to care about the particular code I am writing right now.

What is Processor

Sam Phippen’s talk, titled “What is Processor” was an excellent follow on from the history of computing that we had received in the previous talk.

Sam wanted to show us how processors worked.

The mechanics (at a sane abstraction) of how processors do their thing are something I thought about during my degree for one module, and for my Computer Science A-Level. This talk was a perfect opportunity to refresh my memory (my internal registers which stored information about ALUs had long since been overridden).

I really liked Sam’s point that C was born to model the behaviour of the PDP-11 computer, it wasn’t a general purpose language.

I left this talk feeling refreshed and incredibly thankful that I was lucky enough to be in a school where I had to learn these things early on in my programming career.

The Function of Bias

Sara Simon gave an amazing talk on the function of bias. Bias fascinates me because even if you’re hyper-aware of it you still project your own biases on the world.

My core takeaways from this talk were;

Bias is heavily affected by your sources, so any bias present in the books you read, talks you attend or senior folk you look up to will inevitably have an affect you.

Our work grows upon and feeds other work, so it will inherit and give out particular vibes. Tech is so incredibly important but unfortunately it has been created by a largely homogeneous group of people, which is an issue.

Sara is at the cross section of Journalism and Tech (side note, she isn’t the first person I know who walks these lines. Scott Matthewman has delivered a talk called Hack like a Journalist before.) and she pointed out Journalism tries to fight back against bias by having a code of ethics. It is worth wondering why we as software developers don’t have a similar code.

Do it Yourself Testing

Emily Stolfo opened my eyes to a different way to consider writing tests for other people.

The problem Emily and her team faced was MongoDB has several drivers written in different languages, but all of them needed to be tested.

Relying on each driver to implement its own test suite meant each driver could act in subtly different ways but still pass its own test suite.

The solution was to write a language agnostic test harness.

This can be read from multiple languages and allows folk at MongoDB to specify what needs to happen, and then each language can implement the test in their chosen way.

This means features stay consistent between drivers, but the implementation can be geared to take advantage of the particular language the driver is being written in.

Just a Ruby Minute

This was such a fun interlude – If you aren’t aware of the gameshow Just a Minute it is a game where someone needs to speak on a subject without repeating a word, hesitating or veering off topic. You score points by being the person to finish of the minute talking, you also score points for correctly calling someone on breaking the rules.

The host was Andrew Faraday and the contestants were Andy Croll, Eileen Uchitelle, Sam Phippen, and Britni Alexander.

Well done to all involved, it was great fun!

Fast Talks

Next up we had 5 “fast talks” these were 5 minute long talks on a variety of subjects.

Phil Nash

First up we had Phil Nash doing a live demo of how you can add 2 factor authentication to your app really easily using Authy (which I learned are part of Twilio, I had no idea).

I’m already considering tightening up some admin areas I’ve built before.

Andy Pike

Next up we had a really fun rap from Andy Pike about the virtues of Elixir.

Elixir isn’t something I’ve spent a lot of time playing with, but I have to be honest I am going to be disappointed if I look at it again and the docs aren’t all written as verse and rhyme!

Dorothy Wingrove

My favourite fast talk was by Dorothy Wingrove it was 5 WTFs in 6 lines.

In it she led us through a really backwards implementation of the classic FizzBuzz programming problem.

As well as some laughs I felt I learned more about Flip-Flops in Ruby.

Jay Gooby

Jay Gooby wanted to spend his fast talk sharing what he has learned from Richard Sennett’s book, The Craftsman.

In the book various trades are discussed as is the concept of being a journeyman. Jay reminded us about the fun times you can have as a journeyman in software development.

The second concept he wanted to talk about was cathedrals and how when building work would start on a project really the only thing someone would know is the rough eventual size. There was a lot more time dedicated to planning than actually working on something. Perhaps something we could benefit from?

Neil Middleton

Niel Middleton took us on a quick tour of what Heroku Pipelines can do.

Heroku Pipelines uses some of the strengths of Heroku (being able to spin up instances quickly) with some of the flows we have learned from good development practices.

A pipeline is a group of Heroku apps that share the same codebase, they get grouped into “review”, “dev”, “staging”, and “prod” so you can better handle how your code is deployed.

Rails 5 Features You Haven’t Heard About

Sean Griffin dedicated his talk to sharing some Rails 5 features we may not have heard about.

Getting to see new features is always exciting, here is what I took away;

• ActiveRecord has added or (great news)
• Rails is pushing folk to use scopes for everything instead of chained queries (great news)
• accessed_fields returns fields that have been accessed in an object (great news)
• Canada has money with the Queen’s head on it, is less mental than post-Brexit Britain and has a cute Prime Minister (great but potentially cold news)

Hubs & Spokes & Stockmarkets

I really respect Patrick McKenzie as an engineer and I love reading pretty much anything he puts out. (side note: It was his inclusion in the lineup which made me buy a ticket this year).

His talk was on some of the engineering challenges that had to be faced when building a real time trading platform for StockFighter.

NSQ helped them solve a lot of problems, to quote from an article Patrick has written on the subject;

I have fallen in love with NSQ, an enterprise message bus for people who don’t ever want to have an enterprise message bus.

I’ve not had to write anything needing to be quite as real time as StockFighter, but I can certainly see the benefits of having a robust message bus like this in place.

Mary Richards & the Delicate Art of YOLO

The penultimate talk of the day was from Britni Alexander. It was a fantastic talk on how to get hired in a competitive environment.

Here were my main takeaways;

• Stop Negative self-talk
• Improve your personal brand
• Always frame things in a positive light
• Don’t wait until you have 100% of the skill set, (at one point Britni said “If I had 25% of the qualifications on the posting – I applied)
• By being everywhere, people couldn’t ignore her
• It is ok to show eagerness and excitement

How We Make Software

This amazing day of talks culminated in Sarah Mei discussing how we make software.

Wow, what a talk. I’ve spoken about this to about 5 people since hearing about it. I can’t wait for the video to come out so I can share it.

Sarah explained a lot of the problems in tech turn out to be human issues, not technical ones. As a result she defined the 4 hard problems in tech to be Hiring, Turnover, Growth, and Productivity.

With these in mind the framework in which we view development teams might need some tweaking.

Lots of people talk about development in terms of a factory, you “build” stuff to “ship” and then you perform “maintenance” on it.

This view is too product centred and the factory analogy doesn’t explain the 4 hard problems.

Other folk think of development more like a workshop of craftspeople. A small group of passionate people making bespoke items than they can be proud of.

This helps explain things like hiring (if you had one toxic person in a workshop, the entire mood would drop) but doesn’t explain things like growth, since twice as many people should be able to make twice as many items.

Sarah suggests we should maybe consider thinking about development in terms of a Stage Model. Saying it is more like a performance than a physical thing.

• The script is the goals of the project.
• The actors are the dev team.
• Rehearsals help cement everything, the more you do the harder it is to change something.
• The performance is the deadline, this is what everything is based on.

This explains the 4 hard human problems;

• Hiring – Actors require trust in each other (hard to work with divas)
• Turnover – Main actors leaving have large ramifications. Understudies will do things differently and other roles may need to be considered
• Growth – Double the actors can’t double the performance. The play would need to change to suit
• Productivity – Under this framework measuring productivity isn’t useful. The main output of the team is the team.

Sarah wraps up by saying each of these models can exist together to help frame various conversations.

Fantastic talk.

Final Thoughts

I thought this was an excellently ran conference. It included great speakers, engaging sponsors, and allowed a fantastic community to meet up – what else could you want!

I can’t wait for the videos to come online so I can experience it all again.

If you are in a position to attend next year you really should. (Update, I’ve got my ticket for next year!)

If you’re worried you don’t know enough Ruby, don’t be – the excellent line-up of speakers means concepts are explained in ways the majority of people will understand. And of course I have a tonne of Ruby articles you could read before hand!