Published at 26.07.2014
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
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.
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…
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.
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:
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.
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.
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.
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.
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.
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!