RubyConf 2015

Desarrollando código Ruby extremadamente defensivo

Sam Phippen  · 




Extracto de la transcripción automática del vídeo realizada por YouTube.

- Extremely defensive coding. To introduce myself, my name is Sam Phippen. - [Audience member] Hi, Sam. - Hi, Alfie, hi people. I'm samphippen on Twitter, samphippen on GitHub. You can take a look at my profiles there if you're interested in finding out more about me.

If you do take a look at my GitHub profile, you'll find that I spend most of my time on GitHub committing as a member of the RSpec Core team. That's one of the reasons why I'm here, today. I think it's really important that RSpec is well represented in community events, like this, and people who use the framework everyday get the opportunity to talk someone who works on the framework full-time.

So, if you have any questions or feedback about RSpec, if you're loving it, if you're hating it, please do, let me know because, like, person-to-person feedback is one of the ways we influence the future of the framework. We, actually, just dropped a new release of RSpec, 3.

4, this week, and it contains a couple of really powerful new features. So, that might be worth checking out. I work for a company called Fun and Plausible Solutions. We're a consultancy based in the U. K. We tend to work on helping our clients with their Rails applications, do performance optimizations, data base analysis and stuff like that.

If that's of any interest to you, I love coming over here, to do work, as well, so, maybe, we can find a way to work, together. Before I get too far into the talk, I wanted to just, sort of, take a sample of the conference. Who's enjoying themselves, so far? (audience cheering) Everyone having a great time? Great, so, I have a, slightly, more pertinant question than just getting you all to clap, cheer and applaud.

Which is, who is here for their first time? Who hasn't been to a RubyConf or a RailsConf, before? So, that's like the vast majority of you, and given that you're all having fun and you're all enjoying the conference, I thought, that I'd just give a shout out to the Scholarship and Guiding program.

Which is something I've participated in, now, for RailsConf, this year, and this conference, as well. I think the Scholarship and Guiding program is an excellent feature of these conferences. It encourages new people, like the vast majority of people in this room, to come into our community, to be greeted and have a really, really great time.

So, if you're enjoying yourself, and you've enjoyed this conference, a lot, when it comes time for RailsConf and you're attending, or if you're planning on attending RubyConf, next year, I would thoroughly suggest that you volunteer to become a guide, and help the program get bigger.

It's something that our community is applauded by other communities, for having. I've seen people from a very, very wide range different language and technology communities, say our Scholarship program is great. So, I would encourage you all, to take part in that.

So, with all of that, sort of, front matter out of the way, let's get in to talking about coding, and stuff. So, I wanted to start this talk with a story. And, the story, actually, comes from one of the question and answer sessions from another one of my talks.

My talk was about deep, internal architecture of how RSpec Mocks, actually works. How the pieces all fit together, and stuff like that. And, as the close of the explanation of the talk, I said that most of the code was there to enable us to deal with complicated user objects that override default methods provided on Kernel or object.

And as I was beginning to answer the questions from the developers, more senior and deep technical questions, got out of the way, I was asked a question by a junior developer that, absolutely, floored me. That I wasn't, actually, able to give a reasonable and complete answer to.

And this is one thing I absolutely love about working with less experienced developers, because they don't have all of this base-line, built-up, implicit knowledge, you're forced to explain things in a great level of detail and clarify your own understanding of what those things are.

The question that I was asked is, "When is it okay to override the methods on object?" And I'd said that sometimes it's okay and sometimes it's not, but, I hadn't really given a clear explanation for when that was the case. So, I sort of, um'd and ah'd, I gave half explanations.

I really wasn't able to fully clarify my thoughts. And, this is so often the way, when you get asked a basic question that you think you totally understand. You, actually, can't explicitly put the knowledge into words and say it, and this is, again, one of the things I love working with newer developers.

So, eventually, I came to an answer to do with consistency. When overriding methods on object is sometimes a good idea, and sometimes it isn't. And the answer to do with consistency was well, do it when it makes your object more consistent with the things that already exist in Ruby, not less.

I could give lots of examples of this, I could talk for hours and hours and hours about this subject, but, that is not the focus of the talk. So instead, I'm gonna give a quick example and move on. So, for example, let's imagine you have some collection object that you've implemented, that might be a bit like a hash or a string or a set, or something like that.

Well, if you don't override the equals equals method on that object, then it's going to just perform object identity comparison But, that's not very Ruby like. Object identity comparison is fine, in some cases, but when you have a clearly defined collection of things, what most of the Ruby standard library does is ask all of the things inside it if they match all of the other things inside of the other collection.

And so, doing and override on this equals equals, there, is totally reasonable and this is a way that you make your object more consistent, not less. So, I'm gonna go through the rest of this talk and it would be great if you could hold on to that story as we're walking through it and we'll visit it back at the end of the talk.

So, I want to posit the question, "What makes a gem good?" Now, this is a hotly debated topic in our community, and, I certainly can't provide you with a universal panacea, but, I can provide you with I think makes a gem good. And, you can decide to agree or disagree with me, as you want to.

[ ... ]

Nota: se han omitido las otras 3.117 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.