Brighton Ruby in a Nutshell (Sort Of)

Sunday I embarked on a crazy travel to Brighton, to attend Brighton Ruby ( @brightonruby) the day after – only to board the plane that would bring me from London back to Berlin little after the forlast talk. Naturally I summarized everything for your enjoyment.

Table of Contents

• May the Ruby be with you
• Building fast, standardised JSON APIs in Ruby
• Better Security For Rails Apps
• Don’t Fear The Cuke
• Unpacking Technical Decisions
• RubyMotion: Ruby For Native Mobile Apps
• Take the pain out of your TDD

May the Ruby be with you

Terence Lee (@Hone02) and Zachary Scott (@_zzak) turned Brighton Ruby in Star Wars Conf with their jedi do’s. This was one of those talks you need to experience, but I will try to summarize it a bit. Zachary, as a member of the ‘Ruby Order’ (Ruby Core) – archiving and documenting Ruby standard libraries – told how he teaches younglings in order to give back to the force. Talking weaknesses (heartbleed, Rails Security issues) in the trade routes, Heroku – employing padawan Terence – was mentioned as a member of the Trade Federation calling the Ruby Order for help. After a Skype session via the Holonet with Grand Master Matsumoto, Terence joined the Republic. One of the goals of the Ruby Order is said to create less dependency on the order. Teaching younglings himself, Terence now tries to improve the relationship with alliances in the Trade Federation. And we can apparently all help here.

Building fast, standardised JSON APIs in Ruby

Ben Lovell works at the digital agency 1minus1. A regular contributor to open-source and agile fanboy, Ben harbours an almost unhealthy obsession for all things API. And he’s high on ‘cutting out unnecessary bikeshedding’. Composing a good API, it should be fast, standardized (a good http citizen) and intuitive (discoverability, documentation), much like the Json API that’s commuted to some sort of standard, which stops people from loosing their head. The Json API is also a good GitHub citizen.

A lesser API? Well, all Mailchimp’s API calls are with http post. Which is a bad idea. Trolling the Rails API (“which loads everything and the kitchen sink”), Ben recommends trying out Sinatra or Cuba. He calls jbuilder a whole bunch of noise. Using rails g serializer – which is less code than Basecamp wrote to do the same without leaving out functionality ;) – merrily, might cause you to serialize your database. YET using the Json API plus the Rails API and Active Model Serializer does not equal success, money and love either. Side loading is a problem. Trade-offs people…

Better Security For Rails Apps

Najaf Ali (@Alinajaf) starts on a friendly note: “we suck so hard at security that there’s a whole industry (infosec) whose sole purpose is to document all the ways in which we suck at security.” The only way to defend against an attack: understand them in as much technical depth as possible.

Najaf’s recommendations:

• Make a list of all software and libraries running in production.
  Sign up for the developer mailing list for that software. When a vulnerability is reported, asses the damage and patch NOW.
• Think hard about authorization.
  Libraries are there to help you but you’ll write most of the code yourself. Who are your users and what are their rights and rules? Najaf likes cancan for more complex apps.
• Make recovering from breaches easy. How long does it take from a database blackout to being back up again?

Don’t Fear The Cuke

Thomas Brand (@Tom_b025) joined Pivotal Labs in early 2014. Became a Cucumber dev team member in October 2013. Has seen some scary test suites in his days. With all of the room having used Cucumber, we were divided in lovers and haters. Thomas argued that Rspec made writing expressive tests easier and finds it extremely useful collecting programmer documentation. “Rspec Story Runner was the prequel to Cucumber to accurately and expressively document intended behavior for all stakeholders.”
Today BDD is often done wrong, too much focus on toolery instead of on collaboration. “Installing Cucumber doesn’t mean you are now doing BDD.” And: “BDD is more about analysis then testing.”

When writing Cucumber tests, Thomas goes about it as follows:

1. 1 Planning
2. 2 Implementation (running the scenarios and code repeatedly until a feature is complete)
3. 3 Review and refine

Thomas: “Acceptance tests should frame the problem rather than force the shape the solution should take.” Push the how out of the way, write declarative scenarios. Name problems. No solutions. And focus on what makes your app different. Write your Cucumber scenarios around that. Login works like login does, you don’t need a whole bunch of tests around that.

Unpacking Technical Decisions

Sarah Mei (@sarahmei) is a Ruby developer, rabid pair-programmer, RailsBridge founder and the Head of Propaganda at Ministry of Velocity. Furthermore she was/is involved in a number of Ruby and Rails conferences.

Whilst attending Fluent (an O’Reilly conference) Sarah talked to the frontend devs attending and they all seemed to have the same question: what JavaScript framework to use? With all the (excellent) frameworks out there, this seems like a good problem to have.

So, what is the thing for the thing? Truth is that the choice for a language or framework is one we make a whole lot less often than deciding what Gem to use. And repetition is notoriously the best way to learn… These decisions seem to be very feeling based. What do you evaluate? The README, number of (recent) commits, available tutorials, last release date, number of questions on StackOverflow, ask people we know, look at (open) issues (and the response of the maintainer), by using it and/or by looking at the tests. Different communities use different ways to get informed – the Python community for instance relies heavily on mailing lists.

Sarah divides the things we might look at evaluating a framework are based on activity and interface, popularity and accessibility. Talking about accessibility, that actually seems to make the difference between Backbone, AngularJS and Ember. What is your background, what feels better? It’s not always easy to untangle what makes something feel better. Is it Ember being more Rails-y? Angular – being build by Java developers – will feel more comfortable to… Java developers. Backbone as the grandpa of the three is more like the veneer on top of your app – not for standalone JavaScript apps. You pick by familiarity.

RubyMotion: Ruby For Native Mobile Apps

Laurent Sansonetti (@lrz) is the Founder/CEO of HipByte, who make RubyMotion. The former Apple employee, MacRuby author has good news for anyone who does not want to code C or Swift. RubyMotion is actually not a bridge, nor an interpreter, and its built-in classes are based on Ruby classes. tl;dr it’s worth checking out.

The whole RubyMotion team works remote. They bootstrapped from the beginning and never took investment. Bandcamp’s iOS app is written in RubyMotion. And so is FrontBack with over a million downloads. No small players. RubyMotion 3.0 is up for 2014. With real eval print loop plus ‘reload epic production loop’ and android as its new platform. Especially the latter was much requested after.

Take the pain out of your TDD

Andy Pike (@andypike) is the Technical Director of 1minus1. TDD gives Andy confidence. He likes the Red – (shameless) green – refactor cycle. He evangelizes it. But TDD used to cause him pain. His tests were brittle, he was trying to drive design with tests or he mocked too many things.

Now he knows that there’s only two types of tests. “Feature tests to prove your basics are working. They should be loosely coupled with UI (you don’t want to be testing JavaScript) and leave the details to unit tests.” Unit tests then test the details. Unit stands for unit of work rather than unit of code.

Add tests when needed, they are not mandatory, Andy says. To easier spot bugs – keep classes and methods small, use the stack trace. For a great (yet silly) FizzBuzz example, check out Andy’s slides. Andy recommends to avoid mocks unless you’re using an already tested API or when the setup is really complex. And don’t drive design through tests, rather use tests to highlight design smells. Refactor Driven Design, it’s a thing…

Unfortunately I had to miss Rosa Fox & Despo Pentara’s talk on Codebar and generally coaching and Aaron Patterson infamous closing notes, but Brighton Ruby was nevertheless a great conference.

On to EuroPython!