LRUG (London Ruby User Group) writeup from July 2016's meetup

Tonight was LRUG night and the Rubyists were out in force to hear some great talks. Here is my humble writeup of the evening with my main takeaways.

Ruby Book Club - LIVE

I must confess I didn’t know Ruby Book Club existed, which is a shame because I love reading me some books! Luckily Nadia Odunayo was there to educate us in the ways of the Ruby Book Club.

This talk acted like a live version of the podcast she hosts, each week they read 1 hour’s worth of a Ruby book and discuss it. I really love the premise.

The current book is Avdi Grimm’s Confident Ruby – an excellent book which I now have a very real urge to re-read, so thanks Nadia.

I’ve just subscribed to the podcast and if you are a Rubyist I think you should too!

Documenting Ruby APIs

Next up we had a talk from Tom Kadwill on the subject of documenting Ruby APIs.

I took a load of notes off the back of this short presentation because I have only half been involved in projects to document APIs.

The Ruby tools discussed were;

• RAML
• Swagger
• API Blueprint
• Apipie

With pros and cons listed for all of them. There was no clear winner because each covered different cases (I wouldn’t be doing them justice to gloss over them in this article, maybe another time after I’ve played with them).

Tom did give us two things to consider when choosing an API documentation tool;

• Is there something already in place from another team? It is easier to keep to one tool
• What support does the tool have for your current tech stack? Is there Rails support baked in, for example

Tom also introduced us to DREDD, a Language-agnostic HTTP API Testing Framework which looks nice.

Tom ended by sharing a project he has been working on that generates API documentation from RSpec tests. I really like the idea behind this, especially as a first stab to help get something documented.

React at Deliveroo

Last but my no means least was a talk from Edd Sowden on how Deliveroo handled moving to React on a Rails backed project.

There were plenty of positive things Edd had to say about React;

• Server-side rendered views with progressive enhancement lead to some great speed gains
• Better separation of concerns; Ruby gets and presents data, React displays it
• Behaviour is described in templates which helps to keep things neat
• Testable server rendered views. Because the same props fed into the same template will produce the same output you can easily orchestrate basic Capybara tests.

Edd shared some notes on how they went about rolling out React in the project;

• Page by page, (some pages will never be turned into React views, like terms of service pages)
• They used Vanilla React, no state stores and no extensions
• Used the asset pipeline

After proving out that this worked and in order to get more from the React side of things they switched from using the react-rails gem to the react-on-rails gem, this allowed them to use Webpack and get more performance out of their pages.

To Sum Up

A great community providing an excellent set of talks. Roll on the next instalment!