At a talk we gave recently to Ruby Ireland, I was support to the main act (the Kobayashi to the Ruby Kyser, I suppose) on the topic of "Can Ruby Survive the Financial Turmoil". We tackled the question based on our recent experiences of building a proof-of-concept for a significant financial institution here in Dublin - the Client. I promised the room I'd publish my talk on our blog - finally, here it is...
Now, Máté did a great job talking about the technical challenges Ruby faced in the Client brief. Did it meet the challenge? Did it hell - crushed it! (How? Relax! He put it all in his Mary Poppins post). I then took up the baton to talk about the bigger challenge: cultural divide!
I wanted to tell the room that the barrier to Ruby (or any 'open source' language) succeeding in the corporate world was not technical - Máté had proven that - but cultural. To do that, I used an example: one of the questions that the client had asked us and our response to it. Then I broadened it to how this example shows us the bigger trend.
What did the Client ask?
"How do we know these gems are safe and can be controlled?
In our heads?
"Ehhh, like, because!"
But a split second later we were asking ourselves "Good question: How do we know the gems are safe??"
It was like my 6-year old god-son asking me "Why are plants green?"
On seeing his skepticism about my quick-fire "so caterpillars can hide on the leaves", I'd realise that I can't really remember why. So I'd have to take a google refresher and then the memory cells would fire: "Ah photosynthesis, we meet again... the chlorophyll in the chloroplasts... it's a light receptor... red and blue light is absorbed... 500-600 nm wavelengths are bounced back... hey, that's green light!"
It Starts with the Gem
First it was important to define Ruby and its gems (we couldn't assume any knowledge) in terms of language familiar to the Client team (i.e. "library").
Next: explaining the process of selecting a Gem.
Step 1: When to build and when to Gem
We explained why so many people go for gems - why not just build it yourself? This is a fundamental characteristic of the Ruby community. Ultimately: why build it yourself if somebody else has done the work and wrapped it up for you to use? Only the re-inventers in this world will build everything themselves. We came up with a flow chart as the simple tool to work out if you need to build it or get a gem.
Step 2: Search for what you need
How do we go about finding Gems?
Google search. Use plain-english search terms to find examples of what you’re after, e.g. “ruby gem that does histograms”
Stackoverflow.com. The biggest community site for developers. Search by tags and text, e.g. “[ruby] dashboards”
Rubygems.org. The official home of good gems. Search using keywords that describe your need, e.g. “charts”, “table grids”
Word-of-Mouth. Ask your colleagues, your buddies, your team. You'll be amazed by how many ideas come from this channel.
Step 3: Do your Due Diligence
Next step is to find out who built your Gem. We deliberately used the term "due diligence" - a term used commonly in finance. This was a conscious attempt to phrase things in the Client's language.
The overall goal is build your confidence in the gem, it’s abilities and it’s authors. Then it comes down to your judgement call on whether to use the gem or try something different (you trust yourself, right?).
✓ Homepages for gem projects will often include live examples of the functionality for you to click
✓ Search gem authors on LinkedIn, stackoverflow and google to see their professional affiliations and reputations.
✓ Download and try it out locally. Satisfy yourself of the quality of the install and usage instructions. A good gem will explain itself very well
Here are some other sources...
Due Diligence Source: Look it up on Rubygems.org.
Due Diligence Source: Look it up on Ruby-Toolbox.com.
Due Diligence Source: Look it up on github.com.
Step 5: Security
When the Client asked me how we know the open source gems don't contain malicious code, I paused to think for a moment before replying, "Well, how are you sure the pre-compiled and locked DLLs you're currently using don't contain anything bad? You can't see inside them. The code in the open-source gems is there for all to see. "
In general, the open-source nature of Ruby minimises risks of the insertion of malicious code. Think about it: everyone in the world can see the code, you can even suggest changes, but the official authors are the only people who can approve changes and release new versions, and there's a clear history of code changes as an audit trail. It's the ultimate peer review system! To think that in the near past we accepted packages of pre-compiled and hidden code as secure software seems, well, plain crazy to me now!
The new 'secure' looks something like:
✓ Complete the due diligence steps I mentioned above to learn about the gem before using and to gain confidence and trust in its code and its authors
✓ Always take gems from the official source: ruby-gems.org
✓ Always cross-check the SHA checksum of the file you download with the checksum advertised on ruby-gems.org
✓ Maintain good IT firewall and IP egress policies such that calls to unknown IPs are immediately detected and blocked
Step 6: Gem maintenance - Stick or Twist?
Once installed into your application, you have options for maintaining gems.
✓ Bundler is a well-known Ruby app installing gems and dependencies.
✓ You can use the Gemfile.lock in your Ruby project to tell Bundler to ‘stick’ to a particular version of a gem; Bundler will not update gems listed in this way.
✓ You can let Bundler automatically pick up latest gem versions by doing a regular rebuild of your application. It will ignore gems listed with specific version numbers in the Gemfile.lock.
Recommendation: once your app is built and tested and signed-off, lock in the gem versions. Then, only take gem updates when you and your team are ready and willing. This gives super stability.
What does all this mean for Ruby?
In concluding my talk, I attempted to spell out the future for the Ruby community:
We're going to see Ruby being used more and more in corporate environments. The big companies, while not fully understanding it, are very aware of Ruby. They're getting a sense of its buzz and power, and are attracted by its vibrant community and its apparent ability to deliver finished products fast.
Can Ruby handle it? From a technical perspective, yes, absolutely. The real challenge is the cultural one. And that, dear reader, is up to us, the people who work and thrive in the Ruby community.
What that will increasingly mean for us all?
- Finding appropriate language and analogies to describe Ruby and open-source concepts and features
- Working out how to integrate with legacy corporate IT authentication systems and exotic systems
- Informing ourselves on Information Security policies (ISO27001), it's 3 tenets and what they mean for our Ruby development:
- Leaving useful artifacts for the rest of us when you solve an integration of any kind:
- New gems
- Creating compatibility matrix readmes in repos so you can record the versions of systems you worked on
- Holding on to the behaviours that made the Ruby ecosystem so strong: publishing information back to the community, giving talks like ours on your experiences, publishing gems and/or tricks
NOTE: The original deck (PDF) is available for download here - permissions for re-use are hereby granted!