Madison+ Ruby 2014 expands Rubyists’ toolkits

Madison+ Ruby 2014 offered several technical talks to get developers’ mental juices flowing and their toolkits growing. Brian Shirai, Vipul A M, Prathamesh Sonpatki, Brian Liles, Lauren Voswinkel and André Arko shared their sweet, sweet Ruby knowledge for the betterment of the community.

Brian Shirai of Enova has worked on Rubinius for eight years. When he started, there were very few people who were paid to write Ruby, but that’s no longer the case.

Ruby is something we can use, he says, to tackle the world’s thorniest problems. “We live in a world that is struggling constantly—Gaza, Ferguson, the Middle East,” he says. “I can’t look at my daughter and not see these other things in the world. I want to do something to make things better.”

As such, he says, “I want to make Ruby better. But I can only influence people with Ruby if they actually use Ruby. A lot of people I’ve met are going to other programming languages. Either Ruby is a good tool or it’s not. I want to understand why people are leaving Ruby. I spent a lot of time thinking about what other languages have that Ruby doesn’t have.”

Shirai addressed several issues programmers have with the language, including speed, concurrency, memory, monkey patching and Ruby’s lack of static types. He showed how Rubinius addresses these issues and explained that in order to deal with problems that are complicated, complex, or chaotic—as most real-world problems are—those trying to fix them need to be able to experiment. They need to work with clay, not concrete. Ruby is the clay. “Ruby’s ability to be molded is what makes it a better solution than the other languages,” Shirai says.

By sharing tools on the Rubinius platform that expose the deeper structures in our code, Shirai helped attendees understand the behavior of their programs and close the gap between the code they write and the code that runs.

Next, Madison+ Ruby 2014 welcomed Vipul A M and Prathamesh Sonpatki from India to share their knowledge on how to build an ORM with ARel. The two developers, who both work for BigBinary LLC, traveled for over 48 hours to reach Madison in time for the conference.

The pair discussed how ActiveRecord handles generating complex SQL queries as well as Joins, Associations and Table Relations, and explained that most of its power comes from ARel. By describing Relational Algebra, Object and Collection modeling of ARel using a tiny ORM at its base, Vipul and Prathamesh gave everyone at Madison+ Ruby 2014 a better understanding of ARel and AR as an ORM.

Bryan Liles, who has spoken at every Madison+ Ruby conference since its inception, took the stage on Saturday with the goal of helping developers get rid of accidental successes. He encouraged everyone to canary their deploys. “Only open your releases to a very small set, and if those customers die…”

On a more serious note, Andre Arko of CloudCity Development in San Francisco addressed security issues in Ruby and talked through the concept of responsible disclosure. He says that security issues are accelerating. While one school of thought says if we just put more work into finding security issues and fix them, we will be done, Arko believes the evidence points more toward the idea that there are an infinite number of security bugs and we will keep finding them forever.

“Security is not a thing that Rubyists have traditionally thought about,” he explains. “But once people started using it in the wider world, this stopped working as a philosophy. One of the big things that changed in Rails 3 is that everything became a gem—17 gems, and then you added more. One of the downsides to that is each gem can have separate security problems.”

We should update our things when there are security fixes, Arko says. It can be hard to convince people to update things because updating is a pain. It can be hard to convince business-y people it is important to take the time. Updating blocks feature development time. But that doesn’t make it any less essential.

“Updating with security fixes is, effectively, insurance. You are mitigating a small risk before it turns into a business-ending problem. It’s a small cost to mitigate a risk. Without it, failures are catastrophic.”