Extracto de la transcripción automática del vídeo realizada por YouTube.
- Before we get too far, I just want to take the opportunity to set the expectation because, if you've been to one of my talks before, they tend to be quite interactive. This is not going to be as interactive. I had sent out a tweet, if you want to have a chance to read through it real fast, but basically, it's a primer of what to expect from this talk.
I know there's a bunch of other talks that are happening, not that I don't think this is a wonderful talk. This is, basically, a walkthrough of how to extract small libraries, put them into Ruby gems, encapsulate them, and publish them. If you feel like it's still suited for you, if you've done a lot of gem publishing before, this is probably gonna be a little bit too cursory for you, but if this is something you really wanna learn and so forth, then it's gonna be perfect and ideal.
I just wanna say that I'm not gonna be offended at all if you're like, yeah maybe, yeah, thank you, first candidates. Yeah, I'm not gonna be offended whatsoever, 'cause I totally understand all this is gonna be recorded anyway. Oh, I'm going, okay, so, (chuckles) my name is Adam Cuppy, I am a principal at this consultancy, we're a web and mobile consultancy called Zeal, we're actually based in Oregon, so, on the other side of the planet, in a very smallish town.
We specialize in a lot of the stuff I'm talking about, we do work for hire, so if you have any companies that would really like some training, or just some development of some kind, we would love to work with you. But if not, totally cool, my Twitter profile's on here as well, please feel free to tweet at me.
I absolutely love working with people, especially helping educate and fill in the gaps. The next thing I'm gonna ask is that, we are really spread out, I'm gonna ask that you actually come forward. There's a ton of chairs, so come forward. There's a lot of space right here, there's space over there, don't be shy.
We are all friends, hopefully, but come on forward. Wonderous, the other thing I'm gonna say is, and I say this a lot during the talks too, is, everything you see is gonna be published online, so, don't feel like you have to take copious notes, in fact, it's much easier for a presenter, just so you know, when we see eyeballs instead of Apple logos.
Just keep that in mind, that 100% of what you see is gonna be available online, of course this talk is gonna be recorded so you can always reference back to it later. Please, feel free to engage, if you have questions during the talk, just keep a mental note of it, because I'm more than happy to answer those.
Like I said, you can find me on the interwebs, I'm on Github at acuppy. All of this stuff, all of the code you're about to see, has been published either under my name, or under Coding Zeal so you'll find it all there, and then my Twitter profile, I just spell my whole name out there, but, anyway, by all means, feel free to tweet like crazy.
Like I also said, this is gonna be available on Speaker Deck, I'm gonna publish it here within the next half hour or so after this talk is completed, once I figure out what areas of the talk didn't work, and I will remove them. Here's what this talk is, it is affectionately titled Pluck It, which is about extracting micro-libraries and building Ruby gems.
This track is about less code, and so this is done in conjunction with that, that more specifically, throughout our time as a consultancy and my time as a Ruby engineer, we've found that there's a lot of really awesome opportunities to pull out gems that are less than 100 lines of code.
They don't need to be big at all. It's really beneficial for a multitude of reasons that I'll get into later. This talk is focusing around those two things. Here's what we're gonna do, is we're gonna start with a basic Rails app. Now, I know this is RubyConf, so please forgive me, you can throw food at me later.
The reality is that even though I'm utilizing a Rails app, I wanna point out the fact that this can actually be a Sinatra app, Lotus, now, which is a cool framework that's, I think there's a talk on that this RubyConf, Volt, any framework or any Ruby library that you're utilizing that can tap into RubyGems, which is basically all of them, can take advantage of this, just in this example, I'm gonna use a Rails app.
So, like most Rails apps, we have a models directory, and inside the models directory we have a couple of models. This is generally where we're gonna find source material for extracting micro-libraries. Often times, micro-libraries center around services of some kind, it might be some sort of factory or builder code library that you might utilize.
This is really where we're gonna find a lot of this stuff. Another place that you're gonna find it often, we're not gonna refer to that here, is inside your controllers, especially inside of controller code where you're handling interactions, you're gonna have a ton, it's very likely that you're gonna have a lot of duplication.
There's a huge opportunity to extract micro-libraries out of that, too. If we take a closer look at, let's say, an example User model, we have this basic functionality that's baked into here, you're gonna notice that it just handles the, there's an attribute on the User model that is to pull a Gravitar URL.
So, just to walk through the code very briefly, we've got this constant that specifies effectively like a URL template, this is the Gravitar URL from their documentation. We're got this built in at the very end of that string, you see that there's the ability to put in a hash value that represents the user's token.
We've got a Gravitar URL public method on the object that we can use, and then we're gonna, if you just see, we're gonna build out that URL and return that back, right, it's really pretty basic. Then we have this privatized method, that is baked into the User object, that hashes, that creates a hash hex value of that hashed email address for the User.
It's really pretty small, but here's the thing, how many, raise your hand if you're familiar with the single responsibility principle? Excellent, so basically, that's what we're talking about as being problematic here, and so this is a big no. We're effectively taking some functionality that seems trivial, yet, we're placing it inside the responsibility of an object that doesn't really care about how that URL is built, it just needs to know that it can be.
So, this is a little problematic. A common pattern is that we're gonna then start to extract this, and maybe put this into its own class, and what we might do to do that is, we might open up the lib directory, and create a new class in the lib directory, it's maybe called gravitar, and then we're gonna move what is affectionately the code from the User object right into this new class.
Very basic, really kind of small. Maybe we wanna build this out, maybe add some features with some more different sized Gravitars, and so forth. That's effectively what we could do very easily with this code. Then, if we look back at our User model, we start to re-utilize this, and it can be really helpful.
So we require in, we inject that requirement for the gravitar, and we simply replace the functionality that we have inside of that attribute reader to call to the gravitar library that we made. This is a good and simple fix for that. This is very common, we'll see this a lot of times, especially in Rails applications, we do this a fair amount.
Whenever you have a library of code or functionality that's essentially agnostic to the application itself, or the domain, it is often a really good idea to extract that out so that you can control that a little bit more, and you can build in some testing around it that does not interact with the user model.
If you're familiar, or if you've done a lot of testing, especially with Active Record and testing Active Record objects, this is really a problem real fast, because we can easily in our test suite start to test things that aren't necessary, and then we slow down this gravitar functionality, and our test suite as a whole.
Then, we open up to this question, and this is the convening question of, ultimately, this talk, and it's this. How many times, and I'll throw this out as actually a question, how many times have you written the same small bits of code over and over and thought, you know, if this was only big enough to create a gem with it.
[ ... ]
Nota: se han omitido las otras 4.224 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.