Rubyists in Ghent – A Recap of Arrrrcamp

Table of Contents

• A recap of Arrrrcamp 2014 – written by Floor Drees
  • How I Accidentally Wrote the Best Code of my Career
  • Weak References Strongly Held
  • Be a better developer (no code required)
  • 80,000 Plaintext Passwords: An Open Source Love Story in Three Acts
  • This is bigger than us: Building a future for Open Source

A recap of Arrrrcamp 2014 – written by Floor Drees

October 2nd and 3rd were all about arrrrcamp, an annual Ruby conference in Ghent, Belgium. I got to co-organize a hackathon improving the Rails Girls guides and website there. Of course I also summarized my favorite talks.

How I Accidentally Wrote the Best Code of my Career

Michael Ries
 has had his fair share of traumatic experiences with legacy PHP code (and an API with methods with 300+ lines) without any test coverage. In attempt to clear things up for his former employer, he thought up an all-new registration system. Yet, he did a poor job at describing it. At arrrrcamp he shared some of his pro-tips both shaping up his idea and getting support for it. Like: use a system metaphor, talk out loud (to different audiences), tell a story, use intentional abstraction and draw big (literally).

Like Sandi Metz, Michael now knows it is totally fine to ‘leave a mess’ and clean it up through iterative refinement. Michael encourages to sleep on things and plan plenty of time for design. Michael got lucky as the the concept he tried to convey matched the way the business talked about the problem they were solving. Still, he needed to specifically set time apart for the creative process that enabled him to generate ideas
. Studying design principles made him understand tradeoffs better. And ultimately Michael found that he thrives best in a team that embraces design.

Weak References Strongly Held

Piotr Szotkowski is an assistant professor at Warsaw University of Technology and Ruby developer at Rebased. He’s also very active in the Rails Girls community and known for his conference talks on tooling and the craziest shell commands. His arrrrcamp talk was no different. Amongst other things we learned everything about the Cowsay app and Ansible.


Pro tip: ANSIBLE_COW_SELECTION=random

What I learned? It’s important to sanitize the output of the shell as soon as you have users and you can use shellwords (or open3) to escape unwatend commands to be executed. Piotr also showed how using the ancient flip flop operator he could remove Perl operators from Cowsay and only output ASCII to even the most narrow consoles. Plus, he was pretty excited about Avdi Grimm ‘taking Cowsay to the web‘.

Be a better developer (no code required)

Katherine Wu (@kwugirl
) is a junior developer at New Relic and interested in building better relationships. In order to do so, Katherine found that it helps if you can get people to want to help you. How? Get to know people
, actually pay attention and make friends with the support team (they know more about the product than you do).
Katherine also recommends preparing some topics for small talk. And: show you did your homework
. When your question is answered, make sure to push out the answer and extend internal documentation (so you are equipped with a solution when a variation of the question pops up). Want to go out of your way to thank someone? Share your appreciation with their manager.

Another road to building better relationships is to make your team look good
. How? Give awesome demos
, push out meaningful status updates
and be a responsive, thorough and empathetic team member. It also helps to realise whether you’re operating in an ask vs guess culture. Which brought Katherine to the topic of better communication. If you want to make it easy for people to help,
articulate why you are confused and have the courage to say that you don’t know things. Then, ask ‘good questions
’ – Is there a reason we are doing it this way?
 Why are we doing this?
 – without pissing people off.  And give good feedback
 when people helped you, focused on with what you were most helped.

80,000 Plaintext Passwords: An Open Source Love Story in Three Acts

T.J. Schuck is a developer at Harvest and has a thing with passwords. “Fluffmuffin, peppercorn, gilligan — those are just a few of our users’ plaintext passwords. I have 80,000 more, and it only took me 87 seconds to gather them from our customer database in a white-hat attack.” Encryption is reversible, hashing is irreversible and deterministic (but not obvious), yet Google-able – T.J. sums up password protection in a nutshell. Adding a string of random letters and numbers to your password (salting) and then hashing it, would work as long as you don’t save it somewhere within your application. And then there’s bcrypt, a related hash function, that does one-way hashing, is pre-image resistant, deterministic and has buit-in per password salts. It even has a Ruby gem. And because of all his pull request action, T.J. is now a maintainer of the bcrypt-ruby project.

This is bigger than us: Building a future for Open Source

Lena Reinhard is a core team member of Hoodie, working on CouchDB. “The term culture evolved in the mid‑15th century and meant the tilling of land. The term culture today refers to a community or group that shares common experiences that shape the way its members understand the world.” Many very important technologies of our time rely heavily on Open Source, not to mention that Open Source actually generates business value. Yet the tech culture is broken and cripplingly exclusive. We need to realize that community is not just about building nice stuff and hanging around with nice people and chat rooms mailing lists or conferences. Every troll, sexist comment, or harassment toward one single community member will directly harm this person, the entire community, the product that you’re building, and finally Open Source in general.

Communications will have direct impact

One major deterministic of culture is language.  All communications in an Open Source project will have direct impact on the product, like the software that you’re building.  One change in an expression in the source code of an application can affect everything. And break everything. We have to stop silencing people when they speak out about threats, mobbing, sexism and other topics that show our broken culture.

Then there’s the topic of diversity. Various studies show that diversity enables us to solve complex problems better and faster, be more creative and stimulated through persistent exposure to minority perspective, make better decisions and generate more innovation. Good news: diversity is the default. Except for in artificial settings like Open Source communities.

According to a 2013 study 89 percent of contributors to Open Source are men. 11 percent are women. But Lena is not just talking about a binary gender system. Currently, there’s so little space for LGBT people in Open Source that they are not even numbers. To phrase it like Hartwig did recently on Twitter, when everyone is making technology, the technology they make will be for everybody. We have to stop the marginalizelization of people, and the worshiping of others. People in our Open Source communities experience not only good times, but also bad times, burnouts and mental health issues like depression. We as members of Open Source communities have to implement a culture where mental health issues are not stigmatized. There are already many initiatives and individuals in Open Source and tech that are working on improving all those topics. “Support them.”