While I was thinking about security I decided to double check that I’m practicing what I preach.

When building a Rails app I don’t want to roll my own security (too easy to miss things) but I want something that’s simpler and lighter weight than Devise. There are lots of good options in this space but I usually reach for Clearance… I respect the Thoughtbot team’s approach to development, they actively maintain Clearance for use in their own projects and they were responsive when I flagged an issue using Clearance with the upcoming Rails 6 release.

Anyway, I kind of knew that Clearance used BCrypt and salting, but when I looked in my database schema I couldn’t find a column for storing the random salt. After doing a little digging, I discovered that bcrypt-ruby, quite cleverly, securely generates the salt for you and then appends it to the end of the now salted and hashed password. All you need to do is store the result in a single field.

Not only does this prevent well-meaning but clueless developers (i.e. me) from doing silly things with the salt (in a mis-guided attempt at “making it more secure”), but it also simplifies the interface of the library.

On a related note, bcrypt-ruby cleverly overrides the == method to let you compare a plaintext password (e.g. that someone just provided at log in) with the stored hash/salt combo to see if it’s a match. Jesus Castello has written a helpful article that just happens to explain this exact mechanism.

All in all, it’s an excellent example of making it easy for the user (in this case application developers) to do the right thing.

Today I learned that Ruby modules are actually implemented as classes under the hood.

When you include a module (which is kind of a class in disguise), it actually gets dynamically inserted into the inheritance tree.

---

Consider the example of a school. We might have a Person class to model every person in the school with some common attributes:

class Person
  attr_accessor :given_name
  attr_accessor :surname
end

Then we might have subclasses for students, staff and parents to model attributes specific to each group. Focusing on the student, our program might look like this:

class Person
  attr_accessor :given_name
  attr_accessor :surname
end

class Student < Person
  attr_accessor :year_level
end

To add attributes to staff and students that don’t apply to parents we could define a module and mix it in. Let’s say we want to be able to add students (e.g. Harry and Ron) and staff (e.g. Minerva McGonagall) to a house (e.g. Gryffindor). Our program now looks more like this:

class Person
  attr_accessor :given_name
  attr_accessor :surname
end

module House
  attr_accessor :name
  attr_accessor :colour
end

class Student < Person
  include House
  attr_accessor :year_level
end

Previously Student inherited directly from Person but now the House module (or, more accurately, a copy of it) gets inserted as the new parent class of Student. Under the hood the inheritance hierarchy now looks more like Student < House < Person.

---

That’s all well and good but Ruby doesn’t support multiple inheritance; each class can only have one parent. So how does including multiple modules work? It turns out, they each get dynamically inserted into the inheritance tree, one after another.

Stretching our example a little further, if we had some attributes common to parents and students, we might use another module. Perhaps we want to record the household so we can model that Ron, Ginny and Mr & Mrs Weasley are all part of the “Weasley” household (I’m stretching this example quite far, hopefully it doesn’t snap and take out an eye). Our student class might now look like this:

class Person
  attr_accessor :given_name
  attr_accessor :surname
end

module House
  attr_accessor :house_name
  attr_accessor :house_colour
end

module Household
  attr_accessor :household_name
  attr_accessor :address
end

class Student < Person
  include House
  include Household
  attr_accessor :year_level
end

Under the hood, Ruby first inserts House as the new parent (superclass) of Student but then on the very next line it inserts Household as the parent of Student. The inheritance chain is now Student < Household < House < Person.

Episode 40 of Remote Ruby was so thought-provoking I added it back to my podcast queue.

After listening to it again my previous thoughts on Graphiti (at the end of that post) still stand. But something else jumped out at me this time…

Lee speaks passionately about Graphiti and Vandal enabling product owners or “business people” (I cringe at the label “non-technical”) to essentially explore the schema and see the relationships between data, much like they already do in Excel (or Business Intelligence tools).

It brings to mind what I wrote last night about the many levels of abstraction between one line in my Rails app and the hundreds of thousands of CPU operations that result.

There’s a huge productivity benefit to me not having to know much about CPU instructions, assembly language, C, virtual machines or abstract syntax trees just to query a database from a Rails app.

Similarly, I think there could be a huge productivity benefit if business people could examine existing queries to understand how their app works or point out logic flaws to the developers… or modify an existing query to extract some data without having to wait for a new API endpoint or report to be developed… or write a new query to demonstrate a product requirement or a feature they would like added.

Just like good developers work hard to understand the business they are supporting, I wonder if Graphiti and Vandal could be the lever that helps good business people better understand the app the developers are building.