I was lucky enough to attend Brighton Ruby 2019 as a speaker this year, but that didn’t stop me from enjoying the other great talks. Maybe this summary will be useful when your boss asks you what you learned, which conferences videos to look forward to or just as a helping hand to remember a great day in Brighton.
Intro & Admin
Every conference has some admin, thank yous etc. to get through & Brighton Ruby is no different. Two things made the Brighton Ruby intro stand out for me:
- Andy’s sponsorship routine, in which he wears a branded t-shirt/hoodie etc. from each of the sponsors & removes them one at a time in in what is probably the least erotic striptease since the previous Brighton Ruby. He has hinted at a future premium sponsorship package in which he strips down to a appropriately branded naked torso - take note big spenders of the Ruby world.
- The seriousness & earnestness with which he introduced the Code of Conduct. I hope everyone felt they could pick up the phone/text/DM him if required.
Setting Up To Fail
A great & accessible introduction to the difficulties of distributed systems (and also their widespreadness) by Vaidehi Joshi (@vaidehijoshi). I really hope Andy takes her up on her offer to come back next year to talk about some of the solutions to these problems!
Why Should you Care About Cultivating Trust
I really loved this talk by Gareth Marlow (@GarethMarlow). The core concept of person debt (basically organisational dysfunction due to people, as a parallel to technical debt) was really interesting as was his discussion around the results of Google’s project Aristotle. Beyond feeling safe, depedendability, structure, meaning & impact are all super important. He seemed visibly torn up by how Jocelyn Burnell was robbed of the recognition for her discovery of pulsars. Best line: “In 1953 Crick & Watson discovered Rosalind Franklin’s work”.
Lightning (10 minute talks)
From Developer to Technical Architect & Back Again
Matthew Jacobs (@matthewrudy) spoke about his year as a technical architect at the Ministry of Justice & what that actually meant. Architect is one of those words that gets thrown around & it was interesting to here what that concretely meant for him & how that overlapps with other developer-y roles. Also one to think about later - should some of your more senior developers be at least part architect?
Embracing Openness in Open Source
Amina Adewusi (@a_adewusi) gave a great talk about how to make projects welcoming to first time contributors. Much as junior developers are a sentinel species for a healthy technical organisation, open source projects ultimately rely on an influx of fresh blood. Some simple & actionable tips, from making sure it is clear first timers are welcome, to signposting how to get involved & flagging good first time issues.
Fixing Performance Problems with ruby-prof
I didn’t see this talk because I was too busy giving it. Despite being a barrelful of nerves apparently I seemed quite calm.
A Chat With Sarah Mei
I was interested to see how this would turn out. As it happened, Sarah Mei (@sarahmei) & Nadia Odunayo’s (@nodunayo) conversation was spontaneous, natural & thought provoking. Topics ranged from the nature of communities & open source (availability of source code is probably incidental compared to the collaboration this allows & it shows when communities place the former on a pedestal), career paths (the mostly inescapable dichotomy of individual contributor VS manager, even though they both eventually converge on similar things) & mentoring.
Better Coding Through Unit Tests
I thought this was a tall order from Valerie Woolard Srinivasan (@valeriecodes) - what more can you say about testing in 2019? - but she totally pulled it off. Some good tips on how to make tests work for you & a healthy reminder that tests are not your deliverable. Some interesting parallels with art too (her talk entirely on that topic from a while back is well worth looking up - I think I saw it at Bath Ruby 2018).
Perhaps my favourite quote was how (paraphrasing) good work results from a large body of average work from which you’ve excised the bad bits. I think a lot of developers starting out have an unrealistic expectation that they should be producing perfect code from scratch, that at some point you get to skip the writing bad code first bit. Of course no one ever gets there, but we don’t talk about that alot, so it’s easy to feel inadequate for doing something entirely normal.
The Life Changing Magic of Tidying Technical Debt
You might not think Marie Kondo has much to teach developers but Sroop Sunar (@sroopsunar) certainly proved me wrong. I’d be hard pressed to pick a favourite talk, but gun to my head I would probably pick this one. From the distinction between cleaning & tidying code to the joy of deleting code (which I heartily share) this was a knock-out talk.
Much as we get attached to possessions that have far outlived their usefulness we are often emotionally involved with the work we’ve created, yet we need to be able to cut loose what has outlived its usefulness. This also reminded me of a Sarah Mei talk from a few years back of codebases as spaces in which you live - you might aspire to that perfect magazine photoshoot living space but those aren’t real! As an aside this may be what tips me over the edge into watching the Netflix show.
Six Years of Ruby Performance: A History
As the end of Ruby 3x3 begins to come into sight, Noah Gibbs (@codefolio) reviewed how this impacted some of the benchmarks he gathers, from complex end-to-end discourse based RRB to simpler RSB & rack based tests. Although the headline 3x performance isn’t on show (and arguably can’t be in applications influenced by other pieces such as DB or Redis access) there are still some really healthy gains.
You may have encountered a bug in the Ruby interpreter
A really engaging bug hunt tale from Alyssa Ross (https://alyssa.is) on how she traced a Ruby VM crash running middleman to the exact commit in Ruby that caused it. As in the best thrillers there were twists and turns and seemingly smoking gun holding perps that turned out to be innocent bystanders. Some good practical tips too on how she narrowed down the problem, both in terms of breadth of the code causing the problem & then using git bisect on the Ruby codebase.
A massive take home from this should be that she did all this without understanding Ruby internals, which probably scares off a lot of people faced with this infamous message - spatial & temporal divide & conquer goes a long way; git bisect is awesome!
Ruby like it’s 1995
I know I already said that, gun to my head, Sroop’s talk was my favourite, but if I was having a really bad day and there was another gun to my head then this would also be a favourite. We often say that with the source code anything is possible, but as Matias Korhonen (@matiaskorhonen) discovered, it’s not necessarily simple.
Following Ruby’s 25th birthday Matias set out to build the first publicly released version of Ruby (0.95) & boy were there obstacles! This Ruby needed 32bit platform, used functionality removed from GCC 17 years ago, & of course new versions of gcc can’t build old versions of gcc, debian packages/mirrors from the later 1990s are no longer available etc. He did in the end succeed with some modification of the original sources, but I remain curious as to whether resurecting a toolchain capable of building the unmodified sources is possible.
On a more serious note, it seems very likely that important cultural artefacts are being lost this way - this seems to present a significant challenge to present & future digital curators.
Defragging Ruby
I’m having a bad day because yet another gun is pointed at my head & another talk is being knocked out of the park / Brighton Dome. Aaron Patterson (@tenderlove) was presenting some of his recent work on improving the Ruby garbage collector by allowing it to consolidate unused space with implications beyond what I had expected (eg CoW friendliness). As with most GC work in Ruby, C extensions are the bogeyman - the compacting GC needs to be able to move objects safely even though C extensions may hold references to then.
Luckily Aaron was able to use the way C extensions already tell the VM what references they hold as part of the mark phase to pin such objects. As long as C extensions are doing what they should already doing, it should all work without changes ( although extensions can be updated to play even nicer with compaction). It may bring to the fore some issues that people have been able to get away with until now (eg if you reference (& mark) object A and you reference (but don’t mark) B that is also referenced by A. The Ruby reference keep B from being collected which is why such code has worked until now but it won’t stop the object from being moved).
I was chatting to Aaron earlier in the afternoon and he mentioned that he still gets super nervous before talks - I’m not sure what the takeaway is here; is it “even the best get nerves” or “the nerves will never go away” but there you go.
Summary
I thought this was a truly exceptional day of talks - from the first version of Ruby to the next one and covering a wide range of topics in between. I got to see behind the curtain a little for the first time as a speaker here & Andy does an amazing job here too, from helping me improve my talk to a stress busting group hug 20 minutes before it. Brighton Ruby is a labour of love & it really shows. If you’re ever on the fence about whether you want to attend or speak at Brighton Ruby, jump now! As for future improvements, perhaps in the closing notes & thanks to sponsors he could put all of their shirts back on again, in reverse order. I think I would find the symmetry pleasing.
This post brought to you by 🍌.