The pleasure and learning process of contributing to Ruby on Rails
0 likes843 views
The document discusses the evolution of the ActiveRecord "where" method in Rails from version 3 to version 4. In Rails 3, negation conditions like "where.not" had to use SQL operators instead of a cleaner method chain. Various alternatives were proposed until the best solution of making "where" chainable and adding a ".not" method was implemented in Rails 4. The discussion highlights how contributing to open source can improve code through collaborative discussion of ideas and design tradeoffs.
![Commit.where.not(liked_by: ‘DHH’).reject!
A story about open source, ideas, smells and tastes
[github.com/claudiob]
I’m a Senior Software Engineer at GOOD and I’m going to to tell you a story about what I learned from contributing to Rails.](https://image.slidesharecdn.com/2012-12-laruby-recent-121214115409-phpapp02/85/The-pleasure-and-learning-process-of-contributing-to-Ruby-on-Rails-1-320.jpg)
The pleasure and learning process of contributing to Ruby on Rails
- 1. Commit.where.not(liked_by: ‘DHH’).reject! A story about open source, ideas, smells and tastes [github.com/claudiob] I’m a Senior Software Engineer at GOOD and I’m going to to tell you a story about what I learned from contributing to Rails.
- 2. TL;DR Rails 3 Commit.where(“liked_by <> ‘DHH’”) Rails 4 Commit.where.not(liked_by: ‘DHH’) So since this is a story, I’m going to spoil it and tell you how it ends. In Rails 3, ActiveRecord cannot specify negative conditions in a query, so you have to use SQL operators. In Rails 4, ‘where’ becomes a chainable method that can be followed by a new not operator to write a negation
- 3. Now that you know the end of the story, let’s rewind to its inception. Most people don’t listen when you say something is annoying, even more if you are a stranger. But programmers can be more heartful and kind than normal people. We actually listen to complaints, even when they come from strangers. We empathize!
- 4. Commit.where(:liked_by ^ ‘DHH’) Someone else had a similar feeling and created a gem to avoid SQL fragments. What’s cool about gems is that you decide if you want to use them or not.
- 5. But suggesting this syntax in Rails core… gets rejected: it doesn’t smell or taste right. DHH may sound harsh but he is telling the truth. He is inviting us to try harder, to make a better coding world for everyone. This is the main reason I love open source, because you can follow your instincts and feel human again!
- 6. Commit.where_not_like(sha: ‘2F%’) So a new option came up: introducing where_not. Well then, why not where_like, where_not_like, where_union etc? But this would pollute ActiveRecord, a lot!
- 7. Commit.where.not(liked_by: ‘DHH’) Commit.where.like(author: ‘cla%’) Finally, the best idea arrives: keept only one ‘where’ and make it chainable.
- 8. Rails 3 where(“author <> ‘DHH’”) @de75af7 where.not(author: ‘DHH’) where.not(‘author = “DHH”’) where.not(‘author = ?’, ‘DHH’) Rails 3 where(“author like ‘DH%’”) @de75af7 where.like(author: ‘DH%’) Rails 3 where(“author not like ‘DH%’”) @de75af7 where.not_like(author: ‘DH%’) Initially implemented by @amatsuda. Smells almost right…
- 9. Rails 3 where(“id <> 42”).order(:id) @de75af7 where.not(id: 42).order(:id) …but here’s a gotcha. Using mixins does not smell right. Mixins delegate the responsibility to another module instead of making sure the code does what we want. And you can write “smelly code” like the where.order(…).not(…) statement.
- 10. Rails 3 where(“id <> 42”).order(:id) @de75af7 where.not(id: 42).order(:id) where.order(:id).not(id: 42) …but here’s a gotcha. Using mixins does not smell right. Mixins delegate the responsibility to another module instead of making sure the code does what we want. And you can write “smelly code” like the where.order(…).not(…) statement.
- 11. So I made a pull request to use a builder class rather than a module.
- 12. Rails 3 where(“id <> 42”) @de75af7 where.not(id: 42) Rails 3 where(“id > 42”) ??? where.gt(id: 42) ??? where.greater_than(id: 42) Rails 3 where(“id <= 42”) ??? where.lte(id: 42) ??? where.less_than_or_equal(id: 42) Moreover, if we start adding inequalities, than why not adding ALL of them?
- 13. Sounds right, but it’s not powerful enough, because they only apply to numeric types, while not has more uses. Funny how a discussion started with “all SQL fragments are annoying” and took us to really understand their power one by one.
- 14. Rails 3 where(“author <> ‘DHH’”) @de75af7 where.not(author: ‘DHH’) where.not(‘author = “DHH”’) where.not(‘author = ?’, ‘DHH’) Rails 3 where(“author like ‘DH%’”) @de75af7 where.like(author: ‘DH%’) Rails 3 where(“author not like ‘DH%’”) @de75af7 where.not_like(author: ‘DH%’) Which brings us back to evaluate this commit: in this light, where.like and where.not_like look very similar to inequalities: only apply to strings, do not reduce the code.
- 15. Rails 3 where(“author <> ‘DHH’”) @de75af7 where.not(author: ‘DHH’) where.not(‘author = “DHH”’) where.not(‘author = ?’, ‘DHH’) Rails 3 where(“author like ‘DH%’”) @de75af7 where.like(author: ‘DH%’) Rails 3 where(“author not like ‘DH%’”) @de75af7 where.not_like(author: ‘DH%’) Which brings us back to evaluate this commit: in this light, where.like and where.not_like look very similar to inequalities: only apply to strings, do not reduce the code.
- 16. Therefore, not powerful enough to belong to the core!
- 17. TL;DR Rails 3 Commit.where(“liked_by <> ‘DHH’”) Rails 4 Commit.where.not(liked_by: ‘DHH’) In the end, Rails 4 will have where chainable only with .not. Contributing to Rails is fun, you learn a lot from the process, not only about source code, but about communities and the impact you can make following your instincts and listening to people who express feelings like “being annoyed”. So, join the movement and contribute to open source!