LRUG was my first Ruby Users Group since Belfast Ruby wrapped up, that was over a year ago. I was itching to hear me some Ruby!
Keen readers of this site will have seen my photo post of LRUG go up already, if not you can take 2 minutes to enjoy my crappy iPhone photography.
I want the talks!
If you are just here from a Google search because you want to view the talks, here you go.
Everyone else, do carry on!
It really is a great location with a great energy around it. The ideal spot for folk passionate about Ruby to meet up.
The format for the event was very casual, after signing in and stickering up (great during conversations later when you immediately forget the name you literally just heard) you could grab a quick coffee before settling into the spacious room.
Murray Steele got things underway with some house keeping and by offering up the floor to anyone who wanted to make an announcement. I thought this was a nice touch.
One of the announcements that stood out and that I wanted to draw attention to here was a non-profit called Codebar.
Let me quickly steal a mission statement from their website.
Our goal is to enable underrepresented groups to learn programming in a safe and collaborative environment and expand their career opportunities. To achieve this, we run free weekly workshops, regular events and try to create opportunities for our students making technology and coding more accessible.
I think this is a great project and I hope either I or the company I work for is able to work with Codebar at some point in the future.
Enough pre-amble, lets get into the talks. There was a nice range of topics covered on the night from a range of disciplines. Let me go through each one in turn.
Hack Like a Journalist
The first talk of the evening was by Scott Matthewman, he was going to share with us how to hack like a journalist. I wasn’t sure if this meant we were about to be given a step by step guide to using the Twillio API to compromise celebrity iPhones!
It wasn’t that, but it was still fascinating.
Scott argues that developers and journalists share many common factors between them, two examples being;
- Both are required to take complicated data from multiple sources and break it down.
- Both are required to tell stories, how code reasons about data is just as important as how a news story does.
I completely buy that there are many shared aspects to the jobs. The question becomes then, what can we developers learn from journalists.
Scott focused in on one thing that gets used when reporting hard news, it is a concept known as the inverted pyramid.
You start with a small amount of the most crucial information.
You move into more moderately important information.
Then onto less important information
Finally you end with background information, only the truly interested will need to get this far.
The pyramid is designed so that the reader can leave as soon as they have got the information they need. The idea that the story builds on what comes before also means that you can edit from the bottom up, knowing you aren’t going to take out any information that was required to understand previous statements.
I have to say as someone who likes to write, even if this wasn’t applicable to code it is still good stuff!
It does apply to programming, but how?
- Starting with the most important information focuses our thinking to reject what isn’t absolutely necessary in code.
- We spend more time reading code than we do writing it, so having well written code makes sense.
- Good code tells us what we need to know and no more, we can leave the codebase once we have read enough to understand at the abstraction that we need to.
If you think this advice sounds familiar it might be because you have read it before. Scott pointed out that in Bob Martin’s Clean Code book he references what is called the Step Down rule, which is exactly the same concept. You explain in code what is needed to be known at the current level of abstraction and no more.
I really loved this talk.
No Man’s Land
It was fitting that this was the middle talk of the evening since the subject matter was about finding a middle ground between Art and Tech.
It was given by two members of the same family, Kevin Monk and Simon Sharville.
After explaining the family’s chops in the creative and technical industries (including a blogger in her 90s!) Kevin explained that his passion lies in the uncomfortable intersections of art and technology.
The talk explained that the craftspeople and toolmakers in their industries spur each other on, each finding novel ways to build upon what the other has created.
It was quite interesting to hear their opinions on when design can help engineering and vice versa.
I was glad to hear someone from the audience during the questions suggest Design for Hackers, a book I love.
You can view the video for this talk here.
Immutability in Ruby
Last but by no means least was a talk about Immutability in Ruby given by Lorenzo Barasti.
After giving us the Wikipedia definition of immutability the talk started by making a case for immutability in general, with Testing, Code Predictability, and Debugging all being made easier.
He argued that parallelisation comes more naturally to immutable code. This makes a lot of sense when you consider that so long as everyone abides by the look but don’t change nature of immutable objects then you don’t have to worry about other threads or processes changing your data whilst it is still being read.
Having code I can better predict is enough of a win for me that I am interested.
We were shown how the concept of immutability can be applied to a list of data to show how not every node needs to be updated when data changes. Conceptually this is very neat and maybe it was because I had already read about this but I thought his explanation and diagrams made perfect sense.
Lorenzo presented some interesting sources for his talk at the end. One that I want to spend some time with is Hamster, which aims to bring “Efficient, Immutable, Thread-Safe Collection classes for Ruby”. This helps to address a point made that mutable and immutable data structures and concepts generally don’t play that well together.
As was mentioned in the talk, Rubyists can often feel left out of the loop when Functional Programming concepts are discussed – I think this is one of the reasons I really loved his talk. Ruby was designed to be fun and a joy to code in. It makes sense we would use our amazing language to play with new concepts!
I really liked Lorenzo’s attitude towards trying new things.
I loved the evening, heard some great talks, had some great conversations after and am looking forward to attending more.