 you're not using yet and there is a URL you can follow along with the slides. About me, my name is Craig Buchek. I've been using Ruby since late 2005. I started with Rails like most of us. I've had occasional forays into other languages, which just makes me appreciate Ruby more. I am an independent contractor, always looking for new work. I specialize in Rails rescue projects and agile tech needs. And I'm also a sometimes contributor to this agile life podcast. So first I want to talk about what is an idiom. So the dictionary gives us a couple definitions and most people when they're talking about programming languages, they kind of concentrate on this first definition, something that can't be understood from the meaning of the separate words, but has a separate meaning of its own. I prefer this definition. I think this is closer to what we mean when we talk about idioms in programming languages in idiomatic Ruby, which is a form of expression characteristic to a group of people. So that's going to be my working definition, a way in which we normally express ourselves in Ruby. So here's some examples of non-idiomatic Ruby. I can tell that these were written by someone not very familiar with Ruby. Maybe they're writing Java in Ruby. So the first one uses a for loop. Idiomatic Ruby uses a for loop so little I had to look up the documentation just to figure out how to get that syntax right. You'll notice that the indentation is not the standard two space indentation that we typically use in Ruby. The second one is longer than it needs to be, but not just that, it takes more effort for me to understand what it means. So we've got the I equals and we've got the initializer for the dates and then we go through a while loop and we add things and then we have an explicit return at the end. So that's pretty non-idiomatic Ruby. So the idiomatic versions of this, we use a five times or we could use an each there instead of a for loop. And let's see. I can tell that the person who wrote this probably is at least a little familiar with Ruby. And the second one with the expiration dates is a lot clearer. And I actually ran into something like that second one in the past couple days. It happened to be JavaScript, but it was very non-idiomatic. So one of the things I struggle with, what's the difference between an idiom and a pattern? And it seems like people disagree, but a pattern is just a template for a common solution to a common problem. And this doesn't just mean design patterns and architectural level. There can be different levels of patterns. A great book is Kentback's Small Talk Best Practice Patterns. It talks about patterns at the method level and very small low-level patterns. So in this presentation, I'm going to treat the two terms somewhat interchangeably. So why do we use idioms? They're tools that Ruby gives us. Not necessarily on purpose, but they still are given to us by Ruby. And they're tools that Rubyists can help you with. And often Ruby is optimized to make idiomatic versions work better than the non-idiomatic versions. So surprisingly, that for loop might actually work less than the five times loop. So the first one I'm going to start out with memoization. It's pretty simple. Hopefully most of us have used this pretty often. Let's see. If the instance variable is set to something that's not falsely, then the instance variable will be returned. So if we've already set the at yesterday, then we'll just return that. Otherwise, we'll actually perform that computation, date today minus one. And this won't... Well, if your calculation might return false or no. So that's one caveat when you don't want to use that. But you use it to cache expensive operations. If you're going to take a lot of CPU time or if it's going to take some IO, if you're going to have to hit the disk, then you might want to consider memoization. But don't just use it without thinking. Sometimes you really do need to recalculate every time. And the example on that previous slide, if your process might run more than a day, you're going to end up with a bug. It's going to be really hard to track down because yesterday is going to be three days ago instead of one day ago. So think before you use memoization. So there is a gem for memoization. But for the basic case, it's not really worth bothering. There are some more difficult cases, like when you do care about nil, and if you have parameters. It turns out most of the times in Ruby, that's not the case though. I think it's because we extract objects better. So each object is implemented by itself, self-contained enough that you can just memorize without parameters. The next one's pretty simple. This one comes from OptiGrim, from his blog and from his Ruby Tapas episodes. This works best for hashes and arrays and hash like objects. So in this case, we've got a hash like object to get environment variables. And the typical way we do this is with just the or, sort of similar to the memoization. We check to see if Ruby version environment variable is nil, if we don't have it set. And if it's not, we set it to 2.1.4. The problem comes when if Ruby version could be nil or it could be false, that's going to still return the 2.1.4 even though that may be a valid value. So the alternative is to use fetch instead of the square brackets. If you use that without any block argument, it will raise an index error if it's not found. And it's helpful to ensure that you don't pass nil around. So if you have a nil and you keep passing around, you get a no method error at a later time and you don't know where that came from exactly. You'd have to trace back to figure out where it got set. The second version is the one that Opti recommends as the default. So you don't have to think about it. If you don't want to have to think about, do I have to worry about nil, do I have to worry about false? Prefer that version to the first. And an even better version if you really need an explicit version specified is just raise an exception in that block. It's good for failing fast and being very explicit about how to fix the problem. Alternatively, if you're the one creating the hash, you can actually new it up with a different default. In this case, we knew up the hash to return not found as a symbol if the key doesn't exist in the hash. So that's an alternative to worrying about nil and false. Note that array doesn't have this option. And ENV doesn't either because we don't ever new it up ourselves. The next one I want to talk about is tag module. This one also comes from Abdi Gurum. It's from his book called exceptional Ruby that talks a lot about exceptions. So a tag module is a mix-in module whose sole purpose is to add types to an object. Now, that sounds kind of weird because we don't use types during much in Ruby. Although if you watch the previous presentation in this room, sometimes we do. About the only place we use it is actually to test for types in an exception handler. And here's the implementation. So the idea is here that I've got my own library and I create my own error type in my library. And I do something and I rescue an error, but then I extend that error with my own type and then I re-raise that same error. So what this does is allows the caller to rescue either my lib error so he can get any errors that come from my library, or he can also rescue on the original exception. Plus, he has all the information available from that original exception. So this next idiom, I actually ran across him when I was doing some Java work, but it works great for if you're using capybara and cucumber. So what we do for a page object is we use an object to represent a screen in our application. And this is mainly for full stack testing, acceptance testing. And within that object, we have methods that represent actions. And then we have different methods that represent things on the page that we might want to query. So this abstracts away those actions. You don't have to specify all the details. And that's one of the problems with Cucumber is all the steps end up being in these worlds, but there's just one big pile of methods that you can call. This gives some object orientation to your testing. So here's an example. So we create an instance variable called home page. We create a new login page object. That's our page object. And then we log in. We tell it to log in. And we just pass it username and password. In this case, I did something a little unusual. On the initialization, I actually visit the page. We may or may not do that depending on on your use cases. And then we've abstracted the details into this page object. So when I call login page dot login, I don't have to worry about all those details, like filling in the user if the username field ended up being called email instead of user, I could fix that in that login definition instead of every place I want to use it. And one of the advice that they give on using page objects is if you perform an action return another page object. So in this case, when I log in, I end up at the home page. And I create a new home page object based on that page and return it so I can later interact with that. So that's why I signed it to that as a very top to the home page instance variable. Another idiom that we use in tests, there's quite a few idioms we used in testing, especially if you're using RSpec. So one of my problems that I've always had is mocking. So mocking is where you set an expectation for what's going to happen before you actually run your code. And I'll show you an example here shortly. But the problem I've always had with it is it doesn't fit the pattern. So there's three ways of expressing the patterns that we normally use when writing a test. The X unit standard terminology is set up exercise verify teardown. The one I like to use is arrange act assert. And then the more modern version is given when and then. So in the first example, the down at the lower part invitation dot deliver is our act. And the expect invitation to receive deliver is actually making an assertion, but it's making it in the wrong place. And that makes it difficult to to move the the act part into a common section and it and the setup into a common section. So RSpec three and I believe 214 actually gives us a different way to do it. We can actually do expect invitation to have received. So we get to make that verification that assertion after we've actually done our actions. So the tricky part there is that we actually have to set up our test double up at the top. But we don't really have to set up that verification until the end. And this way we can move up the we can move that invitation delivered to a before block if we want. And the assertion only runs in one place in that case. So the next one I'll talk about is allow class or instance. So I came across this in one case. I don't know if it's generally applicable, but I did find one use for it. And I'll show you that now. So this is I was actually writing a date class for the crystal standard library. So crystal is kind of what Mott's talked about earlier today. It's a language that already exists and it is mostly Ruby. It is compiled and it does type inference. So it's a new language and I was creating a date class for it. And one of the tricky things about date classes is the U.S. changed its calendar in 1752. And we changed from the Julian calendar to the Gregorian calendar. So if you're on a unique system you type Cal 1752 space nine. It will actually print a calendar that is missing 11 days. And so if you want to get your date class right you have to make that work right. So in this case I wanted my default calendar to be a combination of the Julian calendar and the Gregorian calendar that changes on a specific date. So I've got a Julian class and I've got a Gregorian class. And then I've got a third class that basically combines those two. So the trick was when I'm creating new and up a date sometimes I don't want to provide what calendar I'm using. I just wanted to take the default. Sometimes I want to say this is the Julian calendar. Sometimes I want to say this is the Gregorian calendar. And sometimes I want to say well I'm not in the U.S. and in fact that those two calendars didn't change in 1752. Every state every country actually changed on a different date. So sometimes I need to be specific about when this calendar changed happened. And so the implementation actually ended up being pretty simple. Basically I say if the calendar is a class, new it up. Otherwise assume it's already been new it up and it's an instance. So there were some alternatives I considered here. I could have made Julian and Gregorian into constants instead of classes but then I'd have to give them singleton methods and that didn't seem like a good answer either. So this seemed like a sort of a new idiom that I hadn't come across yet before. The next one is configuration query and co-worker of mine came up with this. So normally when you're grabbing some configuration data, you'll ask the configuration file what it looks like. We decided to take that up a level instead of asking what does it look like. We want to ask more of the actual question we want it answered. And in this instance we were doing some extra logging and we want to say hey does this applicant get extra logging. So we just made the API that one level higher. So we got to use a couple other idioms in our implementation of this. One is defining a class method with self there on the second line self for applicant. And that's our main API. And in fact we probably would have made the rest of them private if you could make class methods private here. So we're using some memoization in that second method there. And the third method is loading a file in parsing. So that's something that's going to take some CPU time and some IO time. And one of the nice little tricks we were able to do with memoization is we actually used unmemoization in the reload. So when we got a signal we call this reload method. We set those memoized instance variables back to nil. And so the next time it comes through it actually refetches the data. So that was a nice little idiom that we came up with. So the next one is the one that sort of instigated this whole presentation. And for a long time when I started using Rails we come up with we've got these different orms or different libraries. And you've got you know your model class and you include the orm. And then you provide a separate line that configures that orm. And that always bothers me because I always thought well isn't table more like an option to that module being included? Couldn't we just put it up there? And so of course I tried you know let's see if we can write something like that. And I tried adding table colon people to the include. But that's not Valley Ruby. Include can take more than one argument but they all have to be modules. So for a long time I'd look for a solution and didn't come up with one and had assumed that there wasn't one. And then I was reading some source code for Vertis or actually just the documentation for Vertis and it told me how to use Vertis to create a model. And I found what I've been looking for for several years. And so the next thing was well how the heck is that working? What is that doing? So we've got Vertis.model and then parentheses so that's just doing a function call right? Or a method call. And it must be returning a module because that's all that a include statement will take. So what it's doing is it's using the factory pattern to create a module and it configures that module dynamically per the parameters that we pass it. So I've got an example here of a simple implementation of how this can work. And again we're using a few simpler Ruby idioms here. We're defining class method. We're modifying an object in line with tap there. That's pretty common in idiomatic Ruby. We're using the fetch with default value from obd there. And we're using an options hash which is pretty common to pass in arguments. And one of the tricks here is that we're actually accessing a private method there was send. So we're taking that module that we created with module new and we're passing that to tap and called it mod. We can't call it module because that's actually a keyword in Ruby. And so we're sending include to that module or to that module to add the model constructors. So we're creating a module that's getting other modules included to be included into our model. So we can do a lot of different things with this. We could actually take positional parameters. We could take a block. We could use the builder pattern. Anything that ends up creating a module can be used in that include statement. And as my friend Amos wants me to point out the vertus.model there doesn't have to be a lowercase. You can actually use an uppercase model there. You can have methods with uppercase names. Let's see. So this is kind of I'm kind of one of the first people to discover this at least in the wild. So I wasn't able to find a name for this pattern or idioms. So at first I call it parameterized module inclusion. But then I realized it's just a factory building module. So I decided to call it the module factory. The next pattern I'll talk about is circuit breaker. And this came to me by way of Martin Fowler who wrote patterns of enterprise application architecture. And he says you got it from Michael Nygaard from release it. And this comes from Martin Fowler's Blicky. And so this is trying to stop an avalanche of inaccessible resources. So sometimes when you've got a slow resource a slow server and its API isn't providing you any answers. It's timing out. It's down or whatever. Sometimes that will cause everything else to fail. The idea of the circuit breaker is hey let's stop the failure. Let's stop the bleeding right here at its source and respond to it in a better way. So that might be a slower or unresponsive network resource. You might have filled up a queue. You might have a thread pool or a connection pool that's been exhausted. And you need to somehow deal with that in a same way. This is a little harder to explain in a very short amount of code. I will point out that there is a circuit breaker gem that you might want to take a look into. It's by W. S. Argent on GitHub. And there's also an article on Martin Fowler's Blicky. So the idea here is when we're trying to do something before we do it we see if the circuit's already been broken. And if it's already been broken then we don't want to make that call. Or we might actually want to make that call maybe one times out of 10 and just see if it's up. But we don't want to make it every time for sure. And then if there's a problem we rescue that error. We break the circuit anytime there is that error whether that's a time out or some other not their error. And we probably want to re-raise that exception. And so the other code is just basically seeing if the circuit's already been broken and some simple code to break the circuit and a way to reset the circuit. Now in this case there's no automated way to reset the circuit and that may actually be your case. You may send some logging and alerting for someone to manually reset the circuit. Or you may find some way to to reset that circuit. And like I said you might want to when the circuit is broken might want to try one out of 10 times and if it comes up three times in a row then assume it's up and you reset that circuit. So the circuit breaker pattern has a lot of different options. What do you do when it's broken? Do you just drop the request? Do you raise an exception? Do you use some sort of promise to return a value later? Lots of different things you can do depending on what you're trying to accomplish. Also the conditions for deciding when to flip the breaker. Do you do it on the first error? Do you wait for five in a row? Do you wait for 50% over a given amount of time? What conditions would automatically reset that circuit? You definitely want logging and alerting. If you're going to trip a circuit you want to have a log of what as much as you can what went wrong and you want to let someone know as soon as possible. And the next idiom I want to talk about is blue-green deployment. This is a deployment pattern and I'd like to see more Rubyist adopting this as a lot of us have done continuous deployment, sort of this continuum of testing, continuous integration, continuous deployment. I think the next one on that line is blue-green deployment. And the idea here is to have two complete production environments that are equivalent except for the code running on them. One is live and the other one is either the previous code or the next code. And when you're deploying you deploy to the one that's not live. And the other one just keeps running as it was. And you smoke test what you just deployed to and then you just swap the live one with the next one. So that's usually your load balancer pointing to the green and then moving to the blue or moving from the blue to the green. This makes it very easy to switch back to the previous deployment. We ran into a problem a couple of weeks ago where we deployed the wrong version and it took almost eight hours to restore everything back to the way it was. Had we had had a blue and green deployment we probably would have been back in about five seconds. So the trickiest part about this though is database integrity. If you started using the new database with the new code, do you lose all that data and go back to the old database? That's the hardest part about studying all this up. Do you make the database? Do you sync the two databases? Do you break them when you break them when you sync them? That's the hardest part about that. So the takeaway here is we should learn the idioms because there are tools that can help us to write better code. They can help us write more readable code and even more importantly it turns out that idioms are not static. We might find new ones. We might be looking for them and not find them for years and then all of a sudden we find a new idiom. And these new idioms, sometimes they fit with our existing idioms and extend what we can do with Ruby. So I've got some ideas for further investigation. These are basically ones that I didn't have anything important to say or I didn't have time to research and find anything interesting to say. Config blocks is pretty one of the popular things that we use in a lot of areas in Ruby. DSL is something we use in Ruby probably more than any other language. I saw a mention of flip-flops the other day. I've only seen mention of that twice but every time I see it it blows my mind. I saw a case where sometimes a method will take a block or a value which is pretty handy. In fact I think the hash fetch probably is using that idiom. Enumerable is pretty awesome. If you've got a collection always try to implement the enumerable module. Enumerator is related to that and I've not looked into it very much but it's sort of sort of gives you a sort of a promise or a continuation on enumerable return values. We can always use more object-oriented programming and object-oriented design in our Ruby. We could always use more refactoring. Keyword arguments is new to Ruby I believe 2.0 but refined in 2.1 and 2.2 is going to be coming out soon. So there's probably some ways we can use keyword arguments that aren't immediately obvious. Apparently we're going to have to learn about soft typing and how to use that pretty soon. And so other languages a lot of times some of these things I found in other languages that I found more applicable to Ruby than their original language. So always be on the lookout for new ideas that we can use in our favorite language. So a couple of the resources I used to find some of these Confident Ruby by Abdi Grimm and Exceptional Ruby by Abdi Grimm are where I grabbed a couple of these and Anything by Abdi Grimm. In fact Anything by Kent Beck or Martin Fowler would be great to read. Martin Fowler's Small Talk Best Practice Patterns is a great book on patterns in the small probably more close to what most people think of as idioms. If you think it's a little weird to recommend a small talk book at a Ruby conference Avi Bryant had a great talk at RailsConf I think it was 2007 maybe 2006. He talked about small talk in Ruby and how they're basically brothers twins separated at birth. So most of the things in that book are applicable. And Martin Fowler's books in Blicky. His Blicky covers pretty much all the patterns that his books cover sometimes in more depth and sometimes in less. And here's where I got the ideas for most of these. A memoization was suggested to me by James or Edward Gray. If you're have a question for a you want to talk to one of the people that are high up high up in the Ruby chain, send him an email. James actually answered my email really quickly and unbelievably thoroughly. So the page object idea came from selenium developers. It happened to be actually more for root for Java but it worked really well for Ruby. The config query was Kyle Stephens and myself a coworker of mine. And the module factory like I said came from Vertis. And if you're interested in the slideshow software, it's a slideshow called remark. And it lets me have show notes that I can see, percenter notes that I can see that you can't. It has a timer. It's really easy to use. Basically, you just have a template and you throw in some markdown and it does everything for you. And I would appreciate any feedback. My Twitter is Craig Buchek. GitHub is Buch. And email is Buchek.com. Thanks. I appreciate your time.