Missed RDRC? You can view the presentation materials here: Red Dot Ruby Conference 2014

I had the pleasure of attending this year’s Red Dot Ruby Conference, a locally organized tech conference for Ruby developers.

RedDotRubyConf is the largest Ruby conference in South East Asia - a two day single-track event that brings together renowned international and local speakers.

I’ve learned tremendously from the speakers, most of which were prominent OSS (open source software) and core Ruby contributors such as Koichi Sasada (Ruby core team) and Aaron Patterson (Top Rails contributor.) Here, I will outline three of the lessons I’ve learned from the conference.

##Tending your Open Source Garden

Tending the open source garden is not easy, and it’s not for everyone.

From this talk by Brandon Keepers (Github), I learned many lessons in cultivating and maintaining open source projects. Open source is hard work, but it often leads to better software.

Like a garden, open source projects require cultivation, diligent maintenance, and pruning to sustainably produce a harvest. Without proper care, they become a burden that smothers your reputation, causes harm to your product, and kills your morale.

Trending Github repositories are open source role models. They have a clearly defined use case, good documentation, and active contributors.

These steps include:

• carefully picking a name for your open source project,
• writing proper documentation with setup instructions, API examples, and directions how others can contribute, to always be hospitable to contributors,
• only merging features you want to maintain,
• writing regression tests and having a Continuous Integration System to guard against erosion and give contributors confidence,
• semantic versioning,
• and how to deprecate features in minor/major versions.

How to handle deprecations. Using semantic versioning, we remove features only on major version releases. On minor releases, we warn developers of the feature deprecation.

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

I never considered myself as a “security engineer,” but this talk taught me the importance of defensive and secure engineering even as a “normal” software engineer. I learned of secure password storage, how to examine hacks, and how to mitigate threats.

Hashing passwords. Unlike encryption, hashing is irreversible. However, rainbow tables makes simple hashing obsolete. To solve this, we salt our passwords - we add a random string to our password before hashing occurs.

Using Harvest as a case study, the speaker outlines how they improved security within their application, especially with their data. We begin with hashing the sensitive data, but we face the threat of rainbow tables. We salt our passwords, but computers today are capable of trivially generating millions-row rainbow tables for every salt. The solution? Bcrypt, a deterministic hashing algorithm with a built-in salt based on Eksblowfish.

The Bcrypt encryption algorithm research paper. Paper Link

It was fascinating to see how the bcrypt encryption algorithm fights against the computational arms race by allowing consumers to manually set the difficulty level of the encryption. Besides incorporating a salt to protect against rainbow table attacks, bcrypt is an adaptive function: over time, the iteration count can be increased to make it slower, so it remains resistant to brute-force search attacks even with increasing computation power, which makes the system future-proof.

##Speed up Rails, Speed up your Code This talk opened my eyes on how I can use the knowledge I’ve learned from my data structures and algorithms courses (CS2020, CS3230) into more performant production code.

Aaron Patterson - The #1 Rails contributor with an astounding 4384 commits - outlined how he used Ruby benchmarking and profiling tools to refactor and optimize Rails’ ActiveRecord component. Using the information gathered using the ruby-prof profiler, by estimating the actual vs optimal order of growth, and by using a more optimal data structure, Aaron increased the ubiquitous .find() method by 100%. Walking through the whole process, I learned how to find potential areas of optimization using benchmarking tools as well as what it takes to contribute to a mature OSS project.

Using benchmarking tools and a more optimal data structure, Aaron’s ‘adequate’ fork achieved speedup of close to 2x.

I’ve learned about how you can manage technical debt in open source projects. In many open source software projects such as Rails, there’s often an attempt to make your API as inclusive as possible, with multiple syntax sugar for the same method call. For example, the .find() method has 7(!) valid parameter signatures most of which are unknown to Rails developers. Consequently, a complex boolean conditional is run each time this method is called just to identify which signature is passed in.

Rails .find() method. A complex boolean validation is run every time the method is called to facilitate syntax sugar that most developers are not even aware of.

Since .find() is one of the most frequently called methods in Rails, it makes sense to limit the API to the most commonly used to improve performance. As always, there are tradeoffs to be made. In this example, we sacrificed syntactic sugar in favor of performance. In other cases, we may trade memory for speed.

Summary

I really did learn a lot from the conference. Thank you to all the organizers who made this happen; and thank you Tinkerbox for sponsoring my ticket!