Reflecting on Ruby Conf AU 2016

February 18th, 2016

A few weeks ago, James Healy, my colleague at The Conversation, alerted the team to the following tweet from Kent Beck.

Fast forward to the present and I find myself reflecting on Ruby Conf AU, held on the Gold Coast recently.

My gut feeling is that the conference would score fairly well if evaluated against Kent’s criteria. But us programmers are analytic beings, so let me reflect on the talks and see how well they stack up.

The Talks

Whilst there were many excellent talks amongst the 24 that were included, I’m going to pick some of them that resonated with me and place them each in one of Kent’s categories.

Working in Small Increments

Gradual refactoring, as illustrated by Katrina Owen in her One Undo talk, is a vital aspect of working in small increments. Katrina showed us an example of how to initially place some poorly optimised code under test and then progressively improve it by teasing out the abstractions. To me, it was a brilliant example of how to “remove duplication and improve names in small cycles”, as Joe Rainsberger would say.

To work in small increments, refactoring as you go, requires effective testing strategies. To this end, Tom Ridge gave a thoughtful talk which focussed on the readability of RSpec code. In Explicit Tests Tell a Better Tale, he challenged us to consider how our choices in our RSpec usage affect our cognitive load.

Being Kind

I could have categorised the talk by Elle Meredith as honest, which undoubtedly it was. However, my first inclination about Elle’s talk entitled Feedback Matters was that it was foremost about being kind. As Elle’s talk emphasised, giving and receiving feedback in the right spirit with careful attention to how it affects people is of utmost importance to software development teams.

Ernie Miller struck a chord with his Humane Development – Empathy talk. I’m looking forward to seeing his slides and watching the video to see what else I can glean from what Ernie had to say. But I do recall that I found myself thinking, how good is it to hear someone talking about empathy in the context of software development!

Adam Cuppy may have posed the question, What If Shakespeare Wrote Ruby? and arguably provoked thoughts about abstract commonalities between Shakespearian and Ruby patterns. However, to me there were overriding factors that lead me to unquestionably consider his talk as kind. For one thing, this professionally trained actor provided the opportunity for the organisers to schedule his talk as the second last in the conference. A masterstroke! Secondly, Adam describes himself as a Master of Smile Generation. I rest my case.

Being Honest

Jeff Casimir opened the conference with a talk that unquestionably fitted the “honest” bill. Sharing his experiences in the context of 10 Years and 10 Mistakes set a nice tone for the conference. I found it to be a refreshing approach. We all learn from our mistakes but it takes a certain degree of intestinal fortitude to get up on stage and honestly talk about all the ways you have goofed up.

Debugging Diversity, presented by Dan Draper and Catherine Jones was without a doubt an honest appraisal of the challenges that face the Australian tech community with respect to increasing the opportunities for people who don’t fall into the “white male” stereotype that is predominant.

Given the seriousness of the diversity challenge in tech, it was pleasing to also listen to Jess Rudder give her perspective on the topic. Her presentation, Diversity in Tech – It’s About More than Just the Hiring Process, hit home, focussing on a critically important aspect. The fact that so many women choose to leave the IT industry points to a problem that the community needs to address.

We were privileged to hear Senator Scott Ludlam present the closing keynote of the conference. Honesty is a word that leaps out when I reflect on Scott’s talk, How the government broke the internet. The importance of an honest approach to the Internet and democracy, that is. As Scott illustrated, we certainly cannot assume government honesty when it comes to privacy for individuals and transparency of governments.

Details

I guess it’s fair to say that Paulo Perrotta presented about “details”. After all, his talk delved into Refinements, a Ruby 2 feature. However, when you consider that Paulo’s talk was entitled Refinements – the Worst Feature You Ever Loved, you get an idea that this Italian has a devious sense of humour. And so it proved. To me, this was a great example of the importance of presenting a technical talk as an entertaining story.

When I reflected on what AndrĂ© Arko had to say, I admit that I hesitated about where to place his talk, or talks. His official talk was entitled Security Is Hard, But We Can’t Go Shopping, in which he shared with the audience the importance of handling security vulnerabilities. I guess it’s fair to say that’s an explanation of details. However, that wasn’t the end of his message. AndrĂ© went on to talk about Ruby Together, which to me sits squarely in the honesty category.

The Social Activities

Of course, the talks were only part of the conference. I love the way RubyConf AU has evolved to feature plenty of social activities. My impression is that our international guests particularly appreciate these, especially those on the Saturday morning. Kudos to the conference organisers, Jo Cranford, Rob Jacoby and Trish Jacoby, together with the volunteers for their thoughtfulness and kindness.


Richie Khoo, one of the Ruby Australia founders, enjoys a refreshing swim in Springbrook National Park

In Closing

I think my selection of talks bears out my contention that the success of Ruby Conf AU 2016 coincides with the fact that many of the talks fitted in with Kent’s idea that a good conference focusses on small increments, kindness and honesty.

Tags: conferences | Comments (0)

Digging deeper into Rails scopes

October 8th, 2015

Background

Recently I wrote a post about Rails scopes and lambdas in an attempt to clarify why it is so common to see the use of lambdas with Rails scopes. I now realise that I could have gone a bit further in my explanation.

A question that is sometimes asked is:

Why are lambdas used with Rails scopes? Why not procs or blocks?

To answer that question it is useful to first look at the implementation of the Rails scope method in ActiveRecord::Scoping::Named::ClassMethods.

Implementation Details

The implementation is as follows:

def scope(name, body, &block)
  unless body.respond_to?(:call)
    raise ArgumentError, 'The scope body needs to be callable.'
  end

  if dangerous_class_method?(name)
    raise ArgumentError, "You tried to define a scope named \"#{name}\" " \
      "on the model \"#{self.name}\", but Active Record already defined " \
      "a class method with the same name."
  end

  extension = Module.new(&block) if block

  singleton_class.send(:define_method, name) do |*args|
    scope = all.scoping { body.call(*args) }
    scope = scope.extending(extension) if extension

    scope || all
  end
end

Now let’s consider this implementation in conjunction with the following scope:

class Article < ActiveRecord::Base
  scope :created_before, ->(time) { where("created_at < ?", time) }
end

In this example, :created_before is interpreted as name and ->(time) { where("created_at < ?", time) } as body.

Block, Proc or Lambda?

Notice that body must be callable. So that rules out a block, which is simply a syntactic structure. However, it does still allow body to be a lambda or a proc.

Whilst it is technically possible for a proc to be used in conjunction with a Rails scope, a lambda is more useful because of the constraint that it must, unlike a proc, have a specific arity. For example, in the example above, Article.created_before must be called with one argument.

Summing up

Hopefully, that explains why lambdas are used with Rails scopes.

Of course, you’ll notice that the implementation of the scope method uses metaprogramming via :define_method to create a class method that could have been programmed directly.

Tags: rails ruby scopes lambdas | Comments (0)

Rails scopes and lambdas

October 6th, 2015

Recently I was asked a searching question that left me pondering. The questioner mentioned that he had been following The Rails Way and was puzzled by it’s emphasis on the use of lambdas in conjunction with Rails scopes.

At the time I could only offer a vague answer along the lines of it being a common idiom. I was not satisfied with my reply so committed to following up with a more definitive response.

Background

Ruby Lambdas

Firstly, let’s recap and clarify exactly what a Ruby lambda is.

The lambda method belongs to the Kernel module. Since Ruby 1.9 introduced an alternative syntax, a lambda can also be identified with the characters ->. So, the following two code blocks are equivalent:

succ = ->(x) { x + 1 }
succ = lambda { |x| x + 1 }

Another thing to note about lambdas is their arity, or how many arguments are required when they are called. Every lambda has a precise arity, which can be tested using the arity method as follows:

->(x) { x + 1 }.arity # => 1

There is much more that can be said about lambdas but I’ll leave that to others. For example, Chapter 6, Methods, Procs, Lambdas, and Closures within The Ruby Programming Language by David Flanagan and Yukihiro Matsumoto gives a thorough treatment despite the age of the book.

As a taste, let me quote:

Blocks are syntactic structures in Ruby; they are not objects, and cannot be manipulated as objects. It is possible, however, to create an object that represents a block. Depending on how the object is created, it is called a proc or a lambda. Procs have block-like behavior and lambdas have method-like behavior. Both, however, are instances of class Proc.

Rails Scopes

At the time of writing, the latest Rails version is 4.2.4. On the subject of Rails scopes it is worth reading what is said about them in the Rails guides.

It is also worth keeping in mind that Rails has undergone many changes in it’s history. Currently the Rails guides illustrate that this:

class Article < ActiveRecord::Base
  scope :published, -> { where(published: true) }
end

is exactly the same as:

class Article < ActiveRecord::Base
  def self.published
    where(published: true)
  end
end

Furthermore, the Rails Guides section about passing in arguments advises:

Using a class method is the preferred way to accept arguments for scopes.

In other words, this:

class Article < ActiveRecord::Base
  def self.created_before(time)
    where("created_at < ?", time)
  end
end

is preferable to:

class Article < ActiveRecord::Base
  scope :created_before, ->(time) { where("created_at < ?", time) }
end

If you look carefully and test the two styles, you will realise that the important part of the code is the where clause. So long as the scope or class method returns an object that is an ActiveRecord::Relation, it can be chained together with other scopes or class methods.

In essence, with Rails 4.2 there is no reason to use scopes together with lambdas in preference to class methods. It is a matter of personal preference.

So, why the emphasis on using scopes with lambdas?

To answer this we need to consider the history of Rails. It was around the time of version 2 that named scopes were introduced. They allowed the convenience of chaining scope calls together. Later, if my memory serves me correctly, in version 3, Arel was introduced. This reduced the importance of named scopes when it came to specifying a variety of conditions to return a collection of model objects.

Fast forward to today and, as the Rails Guides state, there is no need to use scopes with lambdas instead of their equivalent class methods, which are arguably easier to read. However, given that Rails has been around for over ten years now, there are lots of legacy Rails codebases, many of which contain a plethora of scopes. Also, there are plenty of seasoned Rails programmers who have formed the habit of using Rails scopes.

In Summary

Hopefully this post has done a better job of clarifying the use of lambdas in Rails scopes than my original fumbling reply during a conversation at last week’s Melbourne Ruby meetup.

Tags: rails ruby scopes lambdas | Comments (0)

Effective Collaboration using GitHub PRs

September 19th, 2015

Background

In her excellent talk about Prefactoring at RubyConf Australia 2015, Coraline Ada Ehmke emphasised her preference for collaboration over code reviews:

I don’t like pull requests. By the time code comes up in a pull request, a thousand micro-decisions have been made about how it’s going to look and how it’s going to function. If you have an alternate idea, maybe even a better idea or a different idea, or questions about why something was designed the way it was or suggestions about how to make it better, by the time it comes up to a pull request, you may be reluctant to share that kind of feedback because somebody has put a lot of work into that already. You don’t want them to feel bad about the work that they’ve done. You don’t want them to feel defensive about the code that they’ve written. So we end up accepting code that is technically sufficient instead of excellent, code that doesn’t necessarily live up to our architectural vision or our standards of quality, and thus begins a slide into entropy.

In my own talk about Loving Legacy Code I touched briefly upon GitHub pull requests, recommending them wholeheartedly, especially when compared with the “structured walkthroughs” that were in vogue in earlier decades. I prompted the audience to ponder whether they were using GitHub PRs to their full potential.

Am I at odds with Coraline on this topic? Not necessarily.

Whilst I agree with Coraline’s sentiments, I believe that, with a thoughtful approach, GitHub pull requests can be used advantageously without falling into the traps she speaks of.

Thoughtful Collaboration using Pull Requests

Early feedback about design

For all non-trivial programming tasks, it definitely makes sense to check your intended approach with one or more colleagues before getting too deeply into coding. How this is effectively done depends on aspects such as the proximity of your colleague. You may be remote but in the same time zone. Or you may be in a very different time zone. The important thing is to make good use of the many different types of tools that now facilitate collaboration.

For co-located collaborators, design discussions around a white board are often effective.

For remote collaborators, in days gone by, your choices may have been limited to the telephone and email. However tools such as Slack, Trello and Skype now provide plenty of scope for collaborating about design approaches.

Once thoughts are closer to code, collaboration via a GitHub pull request can be beneficial. Obviously the creation of a pull request requires a difference in the code. However, that can simply be a TODO comment, for example. From that point on, a valuable discussion can be had via comments that can include code snippets, attached diagrams and all sorts of artifacts.

Early feedback about code

Coraline is right to highlight the risks of creating pull requests only once the programmer believes their change is finished.

By contrast, the creation of a PR early in the development process allows more visibility to colleagues and should, in my view, go hand in hand with a culture that encourages early feedback.

The earlier a PR is created the better. Certainly, as soon as thought about a change can be conveyed by code, it makes sense to create a PR to promote discussion with your peers. Even if you’re not ready to commit code changes, GitHub Flavored Markdown offers an ideal way of sharing thoughts in code in comments within a PR. Resulting comments from your peers can steer you towards a good solution.

One practice I would encourage is to use the prefix [WIP] in the title of the PR to indicate that it is a work in progress rather than one ready for final review.

For all but trivial PRs, my ideal PR is one which is created early in the thought process, undergoes collaboration via comments with colleagues and eventually leads to a solution that the affected developers are all prepared to accept.

Avoiding over-protectiveness

Obviously, if a developer puts a lot of effort into a solution and, once they think it’s finished and ready to be shipped, they open a PR, they are likely to be protective of their efforts. It is human nature.

This is not the fault of pull requests but the choice of the developer to delay the decision to invite feedback via a PR until the last moment. So it’s important to acknowledge that a consequence of opening pull requests early in the development process is a reduced likelihood of over-protectiveness.

Attitude is also important. Even if a pull request is created late in the development process, it is possible to avoid over-protectiveness with a good culture that encourages constructive criticism and teamwork. There should be an expectation that each pull request receives close scrutiny from peers. Equally, when feedback is provided, encouraging language should be used.

Who should merge the PR?

There are various practices that are followed when it comes to merging pull requests. In some teams, a convention is followed whereby receiving one or more shipit comments gives the right for the author to merge. An alternative practice dictates that the author can never merge. Only when their teammates have approved the PR does one of them merge it. Obviously the complexity of the change dictates how many people need to be involved in giving the +1 for a merge.

Whichever approach is followed, it is important that at least one other set of eyes sees the change and approves it before the merge is carried out.

Conclusion

So, there you have it. That’s my take on using pull requests to collaborate effectively. I think they offer a fantastic opportunity provided they are used intelligently within a culture of encouraging teamwork.

Tags: pull requests collaboration | Comments (0)

Rails and RSpec with Two Databases

June 18th, 2015

Maintaining Rails applications in the real world is not always straight-forward.

Recently I needed to enable a Rails 4.0.13 application which used a MySQL database as it’s default to also use a PostgreSQL database. Being a good TDD citizen, I also needed to ensure that the new tests would run in our CI environment.

Whilst I did find a helpful post, it didn’t tell me everything I needed to know. So I thought I’d share what I did.

Database Configuration

First of all, I configured environments for the PostgreSQL database within config/database.yml as follows:

# in addition to existing contents
postgres: &postgresql_defaults
  adapter: postgresql
  pool: 10
  timeout: 60000
  host: localhost
  template: template0

development_foo:
  database: foo_development
  <<: *postgresql_defaults

test_foo:
  database: foo_test
  <<: *postgresql_defaults

staging_foo:
  database: foo_staging
  <<: *postgresql_defaults

production_foo:
  database: foo_production
  <<: *postgresql_defaults

Establish Connection in Model Class

In my case, I only needed to use one model class backed by a table from the extra database. Let’s imaginatively call this class Bar. So the class would be defined like this:

class Bar < ActiveRecord::Base
  establish_connection "#{Rails.env}_foo"

# the rest of the class
end

Note that you probably want to introduce an abstract class which establishes the connection if you have more than one model class which needs it.

Augment rake db tasks

So far so good. The next step was to ensure that the CI script on Buildkite handled the extra database. As you would expect, the script prepares to run the tests by dropping, creating and loading the schema of the database. To do this it uses some code common to all our builds, which includes running bundle exec rake db:drop and bundle exec rake db:create db:schema:load.

I wanted to find a way for the setup of the extra database to piggy-back on these rake tasks and, in so doing, use the existing script unchanged. I discovered I could do so by using the Rake::Task#enhance method. This allowed the rake db tasks to be augmented as follows:

namespace :db do
  task drop_foo: :environment do
    ActiveRecord::Tasks::DatabaseTasks.drop(foo_db_config)
  end

  task create_foo: :environment do
    ActiveRecord::Tasks::DatabaseTasks.create(foo_db_config)
    reset_connection_to_mysql_db
  end

  namespace :structure do
    task load_foo: :environment do
      if File.exist?(foo_structure_filename)
        ActiveRecord::Tasks::DatabaseTasks.structure_load(foo_db_config, foo_structure_filename)
      end
    end
  end
end

def foo_structure_filename
  "#{Rails.root}/db/foo_structure.sql"
end

def foo_db_config
  ActiveRecord::Base.configurations["#{Rails.env}_foo"]
end

def default_db_config
  ActiveRecord::Base.configurations["#{Rails.env}"]
end

def reset_connection_to_mysql_db
  ActiveRecord::Base.establish_connection(default_db_config)
end

Rake::Task['db:drop'].enhance do
  Rake::Task['db:drop_foo'].invoke
end

Rake::Task['db:create'].enhance do
  Rake::Task['db:create_foo'].invoke
end

Rake::Task['db:schema:load'].enhance do
  Rake::Task['db:structure:load_foo'].invoke
end

There are a couple of things I should explain here.

Let’s assume FooApp is the name of application which has foo as it’s default database. FooApp uses SQL rather than Ruby to define it’s schema so I copied db/foo_structure.sql from db/structure.sql in FooApp.

Also worthy of close attention is the call to the reset_connection_to_mysql_db method after the create_foo task. Without this, rake db:schema:load will load the default MySQL schema into the PostgreSQL database!

Conclusion

So there you have it. How to add an extra database to your Rails application and not break CI in the process. Discovering how to use the Rake::Task#enhance method to facilitate this was my main motivation for sharing this.

I hope it helps someone else.

Tags: rspec rake databases rails | Comments (3)