Effective Ruby LiveLessons by Sam Phippen is a series of video lectures explaining best practices used by expert Rubyists targeting all levels of Ruby programmers. The series is based on Effective Ruby, the book written by Peter Jones for the Effective Software Development Series.
The video lessons contain hands-on demonstrations to help the viewer understand how each item is put into action. InfoQ spoke with the author about the lessons learned from the book and Ruby on Rails best practices.
InfoQ: Nil is used a lot by Ruby programmers to check on return values from methods. What is your opinion in raising exceptions vs using nil checking for method return values?
I’ve actually given a talk on this subject before; the slide deck is available here. The core problem with using nil in this space is that nil doesn’t have most of the operations on it that other objects have. This makes returning it from a method problematic. You’re forcing the caller to be aware that your method returns objects that don’t conform to the same interface. This is hugely problematic.
With raising exceptions, I’m also not convinced that’s a good solution. It really depends on the context. To me, the dichotomy presented by this question isn’t actually accurate. Where you’re presented with implementing an unreliable method, I think there are much better alternate choices to be made. I’d look for something that sensibly means “empty container” or “default value” of that type. If that’s not possible then I’d like to see something like an option type implemented instead.
InfoQ: What is your recommendation regarding method chaining and obeying the law of Demeter?
The law of Demeter, it’s the law. But, a word of caution: the law of demeter is often misunderstood. In my LiveLessons, I specifically point out that the definition allows you to dot chain within the same type. As I come to understand Demeter more, what it really means to me is: don’t pass information across architectural boundaries. That’s a way more hand-wavy concept than “don’t dot chain”. For example, I’m totally fine with method chaining to build an active record scope. In that case, not only are you not crossing an architectural boundary, but you’re actually just modifying state on an individual object.
So I guess, yes, follow the law of Demeter, but learn what it means before you get too religious about it.
InfoQ: RoR is used in great part in the web space. How much do you think that this has influenced the exception related best practices in Ruby vs other more strictly typed languages?
Ruby on Rails uses a variety of techniques to handle exceptional cases. I’m not sure I agree that Ruby uses exceptions as best practises. I will say, type systems give us lots of safety ahead of run time that Ruby can’t provide us, and in those places, exceptions can be pretty handy.
InfoQ: Should a Ruby developer rely more on unit or behavioral testing when testing their code?
When it comes to writing tests, it’s important to focus on building a test structure that works for you and your team. Really, modern testing practise is a facet of Agile. The best thing Agile can give us is a set of tools to modify how our teams work over time. This means our testing practise should change over time, too. That is to say, I think the individual application and team are going to influence what makes the best testing, not some community dictate.
InfoQ: Can you give advice for profile resource usage monitoring in Ruby on Rails apps?
Use New Relic. New Relic is the secret sauce that makes me a good consultant. Being able to pop open those graphs and get huge amounts of insight is really helpful.
InfoQ: What is your opinion about testing in Ruby and Rails? Should aspiring programmers stick with the default testing tools provided by Ruby and Rails or reach out to other testing frameworks?
I’m on the RSpec core team, so obviously my answer here is very biased. My typical response to “Which test framework should I use?” is: “Well, it depends”. Minitest has a very focused and limited set of capabilities, but that forces certain constraints on your application that aren’t there with RSpec. Maybe you’ll find those constraints useful, and as such should use minitest. RSpec is a big powerful monster of a test framework. I like to say that if you can imagine a test, you can write it in RSpec. To that end, RSpec lets you write and test any code you want. The problem there might be that your design is weaker for it. RSpec also excels at testing legacy code, so if you’ve got a legacy application that can be good. Again, caveats and trade-offs. Pick what works for you.
InfoQ: Can you provide more information about lambda and procs in Ruby and why one should prefer one over the other?
If I have to actually create one myself, I’ll always use a lambda. This is to do with how lambdas get stack frames VS procs. When you create a block in ruby you’re always going to allocate a proc, so that’s where you’re going to use them day to day.
InfoQ: Dealing with dates in programming is one of the most difficult problems in every language. What is your recommendation for aspiring Ruby programmers regarding datetime libraries and best practices?
I gave a recommendation in my LiveLessons, but the real answer is a little more complicated. It depends on your application, database and a bunch of other factors. More importantly, the best practise is going to change over time. As such, I’d recommend looking up the current best practise and implementing that.
InfoQ: Memoization - this and other design patterns in Ruby are of great interest to aspiring programmers. What would you recommend to a novice to intermediate level Ruby developer who is looking to improve his coding skills apart from your LiveLessons series?
Read "Practical Object-Oriented Design in Ruby: An Agile Primer" by Sandi Metz. Then read it again. Sandi absolutely nailed it when it comes to working with objects. That book will change how you write Ruby permanently and for the better.
InfoQ: What are the bad habits from other languages that you see bugging RoR programmers most of the time?
Being overly imperative. I think this causes people to think they can’t extract objects and leads to poor system design. Whenever I work with beginners/people new to Ruby, I make them extract objects way more often than I otherwise would. This is just to ensure that they know that it’s ok to do that and that it results in a better system.
InfoQ: Can you discuss how the hidden inheritance hierarchy works in Ruby and how does it compare with inheritance in other languages like Java?
In a nutshell, every object gets a singleton class which is invisible and immediate in the inheritance chain. This can be used to add methods to a single object without modifying every other object of that type. Java doesn’t have this, I guess, because you don’t typically dynamically modify classes in Java? A more complete explanation would take about a thousand words and would cover most of the metaprogramming architecture in Ruby. There might be a book in my future that would include this explanation.
InfoQ: Can you talk about the generational garbage collector in Ruby and any factors that developers need to consider when configuring it?
I literally never configure the garbage collector. To be honest, from what I’ve seen, the Ruby core team is continuously working to optimise it for common (read Rails) workloads. As such, I don’t know that much about the internals. But that’s the great thing about Ruby. I don’t need to know the internals of the GC in order to be able to write the language!
About the Author
Sam Phippen is a swashbuckling hacker from London, UK. He fixes every size of data problem at Fun and Plausible Solutions. He helps fight for the forces of justice as a member of the RSpec core team. He's sad that he can't hug every cat.