 My god, hello. Happy Saturday. My name is Aaron Patterson, also known as Tenderlove. I'm Tenderlove on Twitter, GitHub, etc. You can Google Tenderlove, but the search results might not be safe for work, so be careful. I work for AT&T Interactive, and I have to say thanks to them because I am currently employed full-time to do open source work. So I work on open source all day. So thank you. And because I work for AT&T, that means I must be an enterprise developer, which I am. You can go to this address and you'll see that I am in fact an enterprise developer. I'm a Ruby core committer and not a Rails core committer. I'm just a Rails committer. So first I want to talk about my failures, and the first failure is I am not a Rails core committer. And I wonder to myself why I work on Rails full-time and I'm not one yet. And if you wonder the same thing, I encourage you to ask DHH. What? What? Sorry. Okay. Continuing on with my failures, I am presenting last. I like Ryan Davis. My slides suck. I'm sorry, Shane. I use Minitest. I enjoy reading RFC 2119 for fun. Read this. You'll understand why I don't like RSpec. I don't have parents on method definitions, so my code looks like this. Most people here say that they use Ruby and JavaScript, but really I code more C than I do JavaScript, so I'm sorry. But really I want to talk about my failures as a presenter. So I really like to have fun and give a talk. I want to have fun giving talks and entertain people. But at the same time, one of the reasons I really enjoy going to conferences is so that I can learn something practical. One of the best things about going to conferences is learning something and being able to go home and use that new thing that I learned. I love doing that, but the truth is I'm a nerd and I enjoy boring things. I really enjoy boring things. One of my biggest failures as a presenter is I don't know how to combine the two. I don't yet know how to make boring things interesting yet. So tonight I'm going to do two presentations, a practical presentation, and I'm going to give a fun presentation. And I hope this fits under 35. So I like to eat dessert first, so we're going to start with the fun. How many of you were at GoGurupil last year? Okay, yeah, alright. I was not at GoGurupil last year. I probably shouldn't have listed that as a failure, but I was not. I heard last year that there was a presentation that was very popular. I want my presentation to be popular too, so I decided to write a guide about making popular presentations. And Ryan was reviewing my slides and he told me that I didn't know much about the talk, and he said it wasn't really popular so much as it was notable, so this is actually your guide to presentation notoriety. And as far as I can tell, three bullet points, sorry Shane, you need a provocative title, risque photos, and possibly ruby code. So first step is we'll come up with a provocative title. Use ruby 1.9 like an engineer. Not provocative, sorry. So the way to fix this is we will fix it like this, use ruby 1.9 like a sexy engineer, right? Easy, no problem. So next up is risque photos. Everyone, this is totally important, and so what I like to do is take a lot of photos and make sure that I have, you know, come up with these risque photos, and one of my favorite TV shows is America's Next Top Model. So what I did at home for inspiration was I did America's Next Top Engineer. And if anybody here watches that show, you'll know that basically what happens is you have a guy at a camera shouting out a bunch of words, and then somebody in front of the camera trying to act out what those words mean. So what I'm going to show you next is the words in combination with me acting out the words. So these, you know, just some ideas for you guys to come up with risque photos for your slides. So our first one is confidence. We have elegant, sultry, sexy, thoughtful, fierce, thank you Tyra, playful, powerful, and finally provocative. Thank you, thank you. And finally, the last thing to having a notable presentation is obviously ruby code. So I went online, I found some ruby codes, and too long generated, don't care, don't need them. So that's it for my first presentation. This is the first presentation where we're going to go move on to the practical presentation now. So I have a really bad sense of humor. The title of this talk is The Hidden Gems with Ruby 1.9, and really this is a Ruby 1.9 PSA. This talk is a public service announcement for Ruby 1.9. Please upgrade to Ruby 1.9. Ruby 1.9.2 is awesome, you should use it. So back to the terrible joke. The reason it's titled this is because I'm not going to talk about gems at all. Everything I'm going to talk about is from the standard library, so please run now. Anyway, the first thing I want to talk about is mini-test. So this is our normal testing, you know, normal test. It looks like our normal test unit stuff. I'm going to highlight some of the differences here between a mini-test test and a normal test unit test test. The first thing is instead of requiring test unit, we require mini-test auto-run. The next notable difference is we inherit from mini-test unit test case rather than test unit test case. So a base test might look like this. The next difference is we don't have assert knots in mini-test. We have refute underscore. So this makes all of the asserts and refutes line up nicely, so an assert knot would translate to something like this, refute equal food. Food is not equal bar. We have a new method called skip, and what skip does is let us skip a test. So let's say we have some test that doesn't really work on, or it doesn't make sense to run on Windows or is something that we're not ready to implement yet. We can just use the skip method, and when we run our tests, we'll see output like this. So you see there's a new statistic down at the bottom and we have assertions, failures, and then skips. Next up is randomization. Mini-test randomizes the order in which your tests are executed. So you'll see that this test case modifies global values when it's running, and sometimes it'll fail and sometimes it won't. The execution of one test affects the execution of the other, and that's a bad thing for a test. We see sometimes we get all of our tests passed and everything is fine, but sometimes we get an error. You'll see at the bottom there's a new option here. It says these test run options dash dash seed. What that seed is is the random number seed that was used to determine the order in which the test should run. So we can grab that command line option dash dash seed, also tap on a dash seed for verbose, run the test like this, and then we'll be able to see what tests were run and in what order so that we can debug the problems in our test models. Another interesting thing is test performance. If we use mini-test, we have a test like this, like let's say one of our tests is slow, obviously you would probably not write as best as leaves, but let's say we have tests that are slow like this guy. When we run the test with dash verbose we can actually see what the test times are, so you can see up there that tests slow to 10 seconds. So if you have slow tests, you can figure out where those slow tests are. If you're running with rake, then you should use this test ops, the test ops environment variables, you can tap on a dash seed and then you'll see it. Next up, man, 13 minutes. It's already been 13 minutes, I'm not halfway done yet. R-spec, yes. So does everybody know that we're doing 90 shifts with R-spec? No. No. You did not. Look at this test. It looks like R-spec, doesn't it? Right? Right? Right? Actually it's not. That is mini-test-spec. Mini-test has an R-spec like notation. I encourage you to check it out. You just do require mini-test-spec, require mini-test auto run, you too can write tests that look like R-spec. Okay, apparently you do not need that require. Thank you, Ryan. I made a mistake. All right, next up is object space. How many of you know about object space? Yes, everybody, I'm sure you've seen code that looks like this, object space. Object space. Yeah, I do that all the time. Debugging stuff, I don't know what's in the whole virtual machine. What's going on? Okay, I mentioned that I code C a lot, so there's going to be C in these slides. I'm sorry, another failure. In Ruby 1.9 we have object space. These are extensions to object space, which can give us interesting statistics about the current state of the virtual machine. There's four new methods. There's four new methods. Count object size, mem size of, count nodes, count key data objects. We're going to take a look at each of these. Count object size returns to us a hash that is the keys are the types of objects that currently exist, and the values are the total number of bytes that that particular object is taking in memory when you call this method. So you get a return value that looks like this. So we can see that, for example, we have two sum number, I can't count, I was nervous, T class. There's some number of bytes. So it's interesting, interesting for debugging so we can figure out how much memory any particular object is taking up total. Mem size of, Mem size of will tell us how much memory a particular instance is taking so we can give, we pass an instance of an object to mem size of and mem size of will return the number of bytes that that object is using. So this object returns 232 so it's using up 232 bytes of memory. But with mem size of, there's a caveat. We have to implement our own memory allocation or we have to implement our own function to determine how much memory is being used. Alright, sorry, C codes. There's a new pointer on RB data type struct. It is this D size pointer where we give Ruby a function pointer that returns a size T value and Ruby will call, when you call mem size of Ruby will call that function and use whatever the return value of that function is to give back the size value. So here is a very stupid implementation where we just return 10 from my mem size so whenever somebody inspects this particular object it'll always return 10 and say that it's claimed that it's taking 10 bytes of memory. The other caveat with this is that it's only implemented on native objects so things that are any type of Ruby object are only implemented in C. So most normal Ruby objects will return zero because this function is meant to count the amount of memory that the backing C struct is supposed to take. So next up is count nodes and this actually counts the number of parse nodes that Ruby found. So we'll see that it returns a hash with the nodes and the count. And we can actually tickle this, tickle these particular stats by running code that looks like this. Loop over, count, print out the number of if statements that Ruby has parsed and we'll see that if we loop over this we'll actually increase the number of we'll see the number of if statements parsed increases. Count T data objects. This counts native objects so anything that's implemented in C we can get the keys for some reason this is inconsistent with the other methods but the keys are actually classes rather than symbols and the values are the number of times it found that. So on this particular run we had 64 instances of instruction sequence, etc. We can also tickle this by allocating any type of C backed Ruby object. So this allocates a bunch of fiddle closure objects and then prints out the number of closures that are currently instantiated. So when we run this we'll see the number increase this. All right. Object space is finished. Fiddle. Does anyone know about this? Sweet. All right. Fiddle is a LiveAppify wrapper that is in Ruby 1.9. Ruby 1.9.2 now depends on LiveAppify. How many people have heard of RubyAppify? Okay. Excellent. The RubyAppify also wraps LiveAppify so these are two separate libraries but Ruby is now dependent on LiveAppify so we can use LiveAppify from Ruby standard library but fiddle only wraps function calls and closure allocations. LiveAppify provides two utilities. One is to call native methods and the other is to allocate native closures and that is the only thing that fiddle handles. Fiddle can call native functions and fiddle can allocate closures but it can't do things that DL does for example open shared libraries or do any type of memory management. So I want to look at how DL and fiddle interact and we're going to do that by looking at calling functions using DL and fiddle and we have to do four steps to do that open a dynamic library locate the function pointer wrap the function pointer and call the function. So this is our end result code. This line opens LiveM so we're going to wrap the sign function that's provided by LiveM. We have to open the dynamic library then locate the function pointer here we're locating the sign function out of LiveM then we allocate a new fiddle function we have to provide the parameter types as well as the return values. So we tell fiddle about those and then finally we can call the function and determine the value of pi over 180. So creating closures let's say we want to create a function that looks like this similar to sign returns a double takes a double it's very easy with fiddle we just subclass fiddle closure this is different from RubyFFI RubyFFI asks for lambdas if I remember correctly but here we subclass fiddle closure we implement the call method and then inside the call method we return whatever value we want now we allocate this function during this object and tell it the return value and the parameter values just like we did with the functions previously and then we can call it but the important thing here is that when we call function.call we're not actually exercising LiveFFI at all when you call this call method it's actually only exercising your Ruby code so the contract is that you have to assume that LiveFFI will call your call method so this is powerful and the reason I think it's powerful is that it lets you test your closures so you can test your closures in pure Ruby without ever having to open up some particular C library and passing your closure to that C library you can make sure that your closure does the right thing without ever having to hit native code so to use our we can actually use our closure and eat our own dog food the function returned in our LiveSign instance responds to 2i and 2i returns the memory location where that closure sits so we can actually wrap that function with a fiddle function and then call it so we're creating a function wrapping the function and then calling the function down here the only change we have is down here where we allocate a new fiddle function then we call it yes I asked everyone who was familiar with RubyFFI this is RubyFFI code this will run as RubyFFI is wrapping which is a library for cleaning up your HTML code and this will run as RubyFFI today but we can implement this in terms of fiddle and the code to implement it in terms of fiddle looks like this don't read it I just want to show you it's short we can implement it in pure Ruby so now this code which was RubyFFI code they are exactly the same so Psyche Psyche is a YAML parser it is in Ruby192 and up it wraps the YAML or replaces Psyche and it is opt in in order to opt in you need to set the Psyche YAML so normally when you do require YAML YAML will use Psyche you have to do something specific if you want to use Psyche or you just do require Psyche and that's what we're going to do for the rest of this talk so everyone knows how to dump and load YAML it looks like this we all know about this but I want to talk about new features JSON is a subset of YAML in it is a full subset of YAML in YAML 1.2 but not YAML 1.1 as far as I know the only thing that YAML doesn't support in YAML 1.1 is YAML 532 but I'm not sure I really don't know I can't find that information so Psyche will load and dump JSON it's magic okay I already gave you the JSON disclaimer but the new stuff I want to talk about is eventive parsing Psyche supports eventive parsing for your YAML and what I mean by this is rather than buffering up the YAML and doing some data structure back we can actually get real-time notifications of events when our YAML is parsing if you're familiar with XML SAC style parsing this will be familiar so we can write a handler that looks like this and whenever we see a start sequence and end sequence or a scalar value our object will get notified and we use it like this instantiate a new parser pass in our handler so when we run this code we'll see how it looks like this if you're going to straightforward but what I want to talk about is that we actually can give it an IO or a string object and I think that this is a very powerful feature we can provide YAML with a socket for example or an open file handle and we'll get this eventive system going on it also supports eventive meeting so the hard way is like this we can create a new emitter and then just call methods on the emitter over and over and emit YAML but this is hard I don't like it, the output looks like this and if you want to see all the different events read the order doc for this class it's got everything you want to know but streamed-emitting is another thing that SAC supports and I like to think that this is the easy way for eventive meeting what this does is it emits YAML documents but it emits them immediately, there's no buffering it serializes the Ruby data structures to YAML immediately for you there's no buffering and I believe that this interface is much easier than the previous one so important thing here too is that we're emitting multiple documents which emits the YAML document so here we emit two YAML documents the output of it will look like this but there is a problem I don't know if any of you notice what that problem is how many of you use streaming YAML for APIs nobody that's what I thought but as I mentioned earlier JSON is a subset of YAML so we can stream JSON too and all we have to do to stream JSON is change our code from this to this the only difference is this and we get a streaming JSON parser for free so what this is is JSON that's delimited by three dashes and three dots so uses can anyone think of uses better Java protocol yeah so Twitter uses streaming Twitter uses streaming JSON for its APIs you can write something similar I was going to put a slide in here for more info but I didn't so you should do over that and wow I actually did it I can't believe it I am 130 minutes so no questions I actually have more slides so if there are no questions I can do more Evie she is coming over here who are you wearing who am I wearing come on just get closer to it oh no apparently it's all I will repeat the question I can hear you products go ahead you cite do you meet people who make libraries like the twitter library please don't require psych makes it impossible to use your library in a jruby app or a ruminous app or something that doesn't have this library so sweet because I completely disagree with you the plea was don't use psych because you can't use it on jruby if you are a library writer do not use psych because you can't use it on jruby that is true today but we will not feature in the future one of the reasons one of the things that was important to me important to me about rapping live gamel is that it is something that everybody uses us rubies are not the only ones that use live gamel it is also used by python I believe it was actually factored out of pythons and rubies but the important thing is that it is very well known in the community and there is actually a java implementation so I am working on this but my c skills are much better than my java skills there will be a java version for jruby so while it is true today it will not be true tomorrow more questions I really like that what else do I have hold on a minute I need to see what else I have in my I guess coverage man I look like I look really buff in this picture look at those guns dang coverage is another new thing in standard library I blogged about this recently but there are two methods very simple start and result can't get easier than that you probably can't read it but I will tell you what it does it iterates over a line 10 times there are some comments in there there is also an his statement where part of that his statement does not get executed that is all you need to know so these parts never get executed inbox, comments this line is executed 10 times this line is executed never and when we run this file some stuff happens it is super amazing but the way we do coverage is we actually have to require so the interface of the coverage is kind of strange we have to measure the coverage for the file like this we start coverage with coverage.start and then we require the file we print out the results so this is where we actually execute our RB file and the results will look like this and it looks kind of weird but what it is is a hash where the keys are the files that were required and the value is the coverage information for that file a nil means a nil value means that the line will never be executed a number means the number of times the outline was executed and you will get zeros for lines that could have been executed but weren't so with this information we are able to learn the lines executed the number of times the line was executed and the lines that can't be executed and from this information we can deduce coverage information and we can deduce hot spots from our code so somebody ran with this and actually made a coverage tool you should check it out I have made a work with my personal non-rails projects yet but supposedly it works with rails and you can read more about the coverage tool here I have written an article that is in-depth and you can find it at the CRNL and actually I actually have no more slides now but I should mention be careful with the stuff that I have presented because the point about live animal not being available on JRuby is absolutely an important point I feel less important and it is why I am concerned about implementing live animal implementing site for JRuby but not all of this stuff is available for say Rubinius and other Ruby implementations so please be careful though I think using the animal parser is safer than say oh the object space thank you thank you very much