 All right, so I have to admit I was a little bit scared putting together this sort of talk and I'm going to try the best I can to answer this question But really what I'd hope to do is provide you with a way to answer it for yourself Hopefully this won't turn into a religious talk I'm not going to tell you that there's one true right way and I hope that you agree with me that Ruby is Diverse enough where we don't need one true right way This also won't be a super scientific talk So if you're looking for hard numbers on various different aspects of things you might be Getting something different than what you expected Really it's a talk about choices both choices that I've made and choices that we as developers will need to make moving forward Working in Ruby. I'm definitely not a fortune teller So please do not come to me a year from now and tell me that was wrong about some of these things I know I will be I'm also not a language implementer and up until maybe a couple months ago I didn't really know anything about language design. So please don't fight with me over who has the fastest Fidunachi sequence It's not really that sort of talk instead what I'd like to focus on is a Few stories about things that I've actually had to deal with in projects of mine now The most well-known project of mine is prawn how many people have heard of or used that Okay, great. So prawn is interesting as a case study of Ruby the language because We decided from the get-go that we were going to develop it on Ruby one nine and this was before Ruby one nine one had come out and We decided we wanted to make sure to keep Ruby one eight support at you know At all times we didn't want it to break. It would be considered a bug if it did So there's some interesting things there to talk about Another interesting thing was the decisions I needed to make when writing this book It'll be out in a few weeks. I think O'Reilly may have given you all free rough cuts to access or something like that So you might want to check that out, but if you think about it a year ago Deciding whether you're going to talk about Ruby one eight or Ruby one nine was a non-trivial question to answer I'll also talk a tiny bit about stuff that I've been doing in my commercial work Because even though I tend to do a ton of open source stuff it actually turns out that I just work for a really understanding company and That makes me run into some interesting problems for sure So a lot of this is going to be about forks in the road Where you have to decide where to go and your decision is going to really affect the way that things go forward in your projects So I'd like to start with prawn now With prawn we were trying to build a PDF library that would be faster by a lot than PDF writer that would support Multilingualization so that people can use internationalized text in their documents and That would also allow people to be very expressive about the way that they built up their documents You know, we wanted to make something that was pretty to look at for sure so at the time the promises of Ruby one nine seemed obvious after all it is made out of cheetahs that speak every language and They are blessed by a magical wizard with magical features, but at the same time I Was writing prawn because I needed to replace PDF generation in existing software that I had and a hundred percent of that software was running on MRI on Ruby one eight six so that means that despite the fact that Ruby one eight is slow But it's a little out of date It's still sort of like that old pickup truck that is just a workhorse You know it it may have a little rust It may be a little bit dated, but it's done a lot of good work for us and we can't just get rid of it as it turned out you're looking at about 80 or 90 percent of the work that it took to take prawn which was written on Ruby one nine and bring it back to Ruby one eight Now this is a little bit of smoke and mirrors because we planned this you know in the first place We intentionally use things that made it so that it ran on both systems but I'd like to talk a little bit about how this sort of thing works and how you can do this in your own projects if you Wanted to support across versions So one thing that's great is that if you have a green field project You know something you're just starting off from scratch is that actually getting it to run on Ruby one nine isn't that hard But it's also not something that's going to be automatic For example not only will this not work correctly on Ruby one nine just to try to print out some unicode text as Seen exactly here. It won't even parse you'll get a message saying that you know there's an invalid multi-byte character or something like that and the fix for this is easy, which is that Every file every source file that you write needs to have a magic comment saying what encoding that file is in Now this may seem like sort of tedious, you know beam counting, but it actually gives some benefits that we can look at Of course, this is entirely to support the m718n framework So if you look at the situation on Ruby one eight Strings are essentially sequences of bytes and nothing more. It's possible to do character-based access and manipulation But you need to work around it But on Ruby one nine It's the opposite You're working with characters and if you want to work with bytes you need to be especially aware of that Now the interesting consequence of this is that Even if you firmly believe that your application need only be written in and speak American If you're doing any sort of binary manipulation You need to be aware of this. This could be a simple something as loading in a image file and playing around with it so when you're dealing with any strings or IO objects that are Binary data you need to be explicit about it so that Ruby doesn't look at the default External encoding for your files based on the actually is based on the locale on your file system unless you explicitly said it So it doesn't look at that and apply that to your binary data I Was having all sorts of weird bugs and primaries. I didn't realize about this situation existed but it was because it was trying to interpret some of the Files that we were working with as if it were utf-8 and because Ruby one nine is smart about these things and knows how to validate and Codings which means that if you have a binary string that doesn't Contains invalid Unicode characters in it, you know, it's interpreting it as unicode. It will cause problems when you try to run your code so If you look here the idea is fairly simple if you want your code to work the same everywhere You have to be explicit about the encoding that the file is in so for text files That means setting the character encoding for binary files. It means either using bin read or when you open the file Using the beef lag now I know that this is something that people used to think unless my software needs to run on Windows It doesn't matter, but this is actually two issues in one. It's not just the line feed issue It's now an issue of how Ruby one nine will interpret that code So everyone needs to be aware of the fact that you need to pay attention to when you're dealing with binary files on Ruby one nine The interesting side effect is that if you mostly develop on some sort of Unix It'll be easier to catch bugs related to this Before you release your code and this will make Windows people happier. So the multi-lingualization is really the thing that's going to get in your face when you start working with Ruby one nine and Sort of as a consequence of this among other things You no longer can treat a string as an enumerable So you no longer can just map across lines or do things like that. You have to be more explicit so that means either using some of the enumerators that are available or some of the iterators are available and This just means telling Ruby what you want to work with either lines or bytes or characters and Once you get in that habit of doing this. It's not really that hard to You know do at all So these are the things that when I first set out to start working on one nine with no previous experience at all Except for you know blog posts telling me about all the cool features That would be in one nine. These are the things that really impeded me from developing I could not continue to develop run until I learned about the existence of these features Now It depends on whether you're trying to build something just for one nine or if you need backwards compatibility But what you should be aware of is that certain things are new syntax features in Ruby one nine and if you decide to use these Backporting becomes more complicated because you can't simply Isolate these things depending on what version they are you would need to isolate them on a file level and make sure that they don't get Loaded so that you don't get parsed on Ruby one eight. Otherwise your code won't run so now What I'd like to do is take this general idea of how you can get started with Ruby one nine and I really think that this is enough just to get your code to run there And then you can start playing around with new features and things like that I think this is enough for you to get something running on Ruby one nine today if you wanted to But the question is what if you don't have a greenfield project? What if you have a side project that you'd like to see how it works on one night? Well, you can use the same ideas that I just talked about But you need to approach it in a little bit of a different way So right now I'm going to go through a very rough process of how you take Ruby one eight code and go to one nine This is actually what we did in Highline, which is a command line interface library First of all, you need to make sure that your coverage is decent You can use a tool like our cove to do this which works on one eight It doesn't work on one nine But the important point is before you start to migrate your code you have to make sure that you have tests for it Otherwise, it's going to get really ugly when you're starting to make these sort of you know Implementation level changes and things and this is sort of common sense, but it's also Something that is easy to forget and it's going to create problems when you don't know whether it's because you introduce the bug Or because you're doing something wrong on one nine So if you want to bring something up to speed get your test up to speed first now in prawn especially because prawn is something that's a little bit difficult to test because we're dealing with Very complex output that generates these PDFs and we have a great library PDF reader that can help us analyze that stuff But I mean I'll be honest. We don't test every single feature that we write because If PDF reader doesn't have support for it, then that means we have the right parsers for these things So what we did is you probably can't see this code, but it's not that important. Just look at the example on the right We made a bunch of examples a whole bunch of them And then we made a rake test to automate these examples And we made it so that it would make sure that when the errors happen It would catch those things and tell us what was breaking and things like that So if you're taking code from one eight and going to one nine I feel like this is invaluable to have if it's a rails app. This might be as simple as Setting up some sort of you know fitness testing of some sort But if you've got a library or a script Just write up some use cases and then make sure you hammer through them as you're working and working on this stuff It'll really help you catch subtle errors that your test might not So once you have these two things in place you sort of have a support framework for Beginning to experiment my suggestion at this point is that you know, whatever revision control system You're using create a branch dedicated to Ruby one nine stuff and then just hammer on it until the test pass And at this point don't use new syntax Don't worry too much about new features But don't worry too much about making the stuff work on Ruby one nine and one eight at the same time Just get the test to pass and the examples to work on one nine Then ask yourself whether you plan to support one eight in the future Now if you have an open source project, this might be a more sensitive subject But if these are scripts that you have running on your computer or you know Something that you have for a client and you've pretty much got a complete project Done and you have everything you need you may not need to continue support for one eight Believe me as a developer that's maintaining parallel, you know implementations across versions Even when it's not that bad. It's still a major burden to think about Supporting my software across different versions and the reason for this is that once you do that you're heavily constrained on what you can do You can't take advantage of new features because if you do then there's more code that you need to isolate So think about it long and hard once you get your stuff working on one nine whether you care about one eight Of course Like me some of you may really want to keep that workhorse around for some of your projects And now the process is pretty straightforward You get your test to run on one eight without breaking on one nine now with a case of prawn We were very specific about the versions that we support We only work with Ruby one eight six and Ruby one nine one and Other versions may work, but we don't support them So for us it was just a matter of running rake and rake one nine on our tests whenever we do these things But you should also look at Zen test for the multi-loop Ruby Utility this is really cool. It allows you to basically have as many Ruby versions as you want running concurrently against your tests So that's a really cool way of doing this because it'll tell you right away when something breaks Even if you're not using those in your day-to-day work You know, these will be installed in a sandbox that you don't need to worry about So it's a really cool tool and it's pretty easy to use So if you want to have parallel version support and you want to do more than what we did in terms of Supporting different versions. That's probably the way to go so what I suggest is Rather than Trying to come up with ugly hacks to make something work on one nine and one eight Maybe if the features are easy to backport selectively You might as well just do that because then At some point or another if you want to end your support for an earlier version of Ruby You don't need to break down different versions of the software. It's already written to meet a certain specification Now you'll notice here that whenever it's possible, we try to do this in a safe way You know, we check to see if the things already exist so that it doesn't conflict on different Implementations or different versions and things like that and I wouldn't suggest doing this for anything super fancy But if your needs are really simple like this go for it now another thing that you might want to do is if you are using Checking the actual version numbers you might want to create a utility that helps you selectively run blocks of code based on what version you're working with Now this just helps clean things up a whole lot And it makes it so that if you want to change the way that these things work internally the levels of versions You support and things like that you could do that in one place instead of every single place you do this within your application The underlying idea here is that if you're back porting a 1-9 library to 1-8 try to isolate those changes that you made so that they can more easily be seen by other people who are using your software or by you and so that those changes are in one place so if something breaks it's easy to fix and hopefully if you do these things you'll be back to greener pastures again and This is sort of the experience that I got out of prom and what I'm hoping that you can take away from it Is the first set of things tell you okay? If you do these things you can start just hacking on little scripts and things like that whatever you want on 1-9 try it out I did I specifically didn't talk about what new features they are I didn't talk about how fast it's going to be because most of that stuff is going to really depend on what you're doing in the case of prom if You're doing a bunch of image embedding Yard is super super fast for that because it's just a bunch of number crunching and You know basically doing pack and unpack But if you're doing a bunch of text and you need to transcode from different encodings It's slower than MRI So just keep this in mind that moving to Ruby 1-9 is not going to be a magic bullet but that it may well work really good and In other situations, I've seen It's clear advantages, and I think that the best way for you to find that out is to do it yourself so That basically wraps up what I'd like to say about just the idea of moving to 1-9 and trying it out Please do try it out I mean play with it for a few minutes and see if you like it if it seems promising Spend a day on it make it one of your side projects It's important for you to at least know what's out there instead of relying on what other people are telling you you should do So now I'd like to talk about the idea of writing a book a year ago about What versions of Ruby you should be using you know By choosing to make Ruby best practices 1-9 only that's a vote of confidence in Ruby 1-9 as the way forward but The interesting thing is that this didn't come from my book. I did some technical editing for David's books David's here, so He was the one that actually brought up an issue to me that I didn't really consider before And this issue was if you're gonna talk about Ruby 1-8 at this point. What does that mean now? It's pretty easy to draw a clear line in the sand between Ruby 1-8 6 Which is our workhorse our old Software that does a great job of running all of our legacy software I mean who has written code on MRI for Ruby 1-8 6 in here. It should be a hundred percent of you, right? Okay, so Obviously we know what that is to a certain extent We have a feeling of what Ruby 1-9 is supposed to be it's supposed to be this magical future car That brings us to a Ruby awesomeness right so but the question remains If that's the case what the hell is Ruby 1-8 7? Okay, so I'll do my best to answer this quoting directly from the sources So the core changes from 1-8 6 to 1-8 7 in which a method signature either had an addition to it Or it was a new method entirely look something like this Okay, those are the core changes. Did you get all of that? Okay, so the standard library was a little bit more conservative Okay, so there's a reason for this does anyone know what all of that stuff is Yeah, it's code, but I mean where did these functions come from? Right the Ruby 1-9 back ports which in theory seems sort of cool because you know I just spent the first 15 minutes of this talk telling you about how you're going to need to have a baseline understanding of internationalization to use Ruby 1-9 and I can imagine people saying damn it that sucks but the Problem with this is that Ruby 1-8 7 is basically sort of a platypus You know, it's it's a combination of two interesting things that is neither of those things and of themselves now these back ports are useful, but just The fact that they exist doesn't mean that if you write code on Ruby 1-9 it will work on Ruby 1-8 7 So it doesn't really accomplish that goal and one thing is for sure if you care about Ruby 1-8 6 support How many people use Ruby Enterprise Edition for something? Okay, some of you or J Ruby You know if you care about 1-8 6 support and you use even one feature that's new in Ruby 1-8 7 your old reliable truck explodes and and This is an interesting problem for project maintainers For sure, I mean what it means for me And I try really hard to review every single patch that comes into any single Any project of mine and I give people feedback whether or not I think I'm going to accept the patch but what it means for me is before I even Try this stuff I need to visually scan this to see if it includes any of these new features that might break my 1-8 6 support Now this has happened several times before so I'm not just you know speaking about hypotheticals but a more interesting problem is for Packagers on different operating system distributions How do you decide? What to use right now? Are you going to ship with Ruby 1-8 7 or 1-8 6? Most Distributors are using 1-8 7 moving forward. I heard completely I've nothing to back this up, but I think snow leopard may have 1-8 7 so that means that You will be working in a 1-8 7 environment if you use the default system. That's In your environment now If you wanted to use 1-8 6 right now, I'm sure that people know who are running it You need to go and look for it in the old versions of stuff You can't just pull it right off the front page of you know Ruby Lang and this means that 1-8 6 we are resisting change when we use it and There may be a reason for that or may not, but we are resisting change when we choose to do that so when we have a community doing this and we see the real problems to it what should authors be doing I Really don't know the answer to this question I mean at this point at the time that I was starting to write this book and the time David was writing his book This is during the time that Ruby 1-8 6 was having all of these crazy problems because of the security patches So it was too unstable. It was too unreliable, and you really hate telling someone in a book Okay, now go ahead and go to this FTP site and go to this particular version and download this exact patch level Because it just sounds terrible. I mean what kind of message is that to someone who is not familiar with our language? But something like Ruby 1-8 7 which you know for its purposes may have been useful in the sense of being a transitional release If you cover that what are you really giving someone? I mean if you talk about that and then you talk about Ruby 1-9 They're still going to be differences. So the only reasonable choice that we had I guess there is no choice is to treat Ruby 1-9 as the way forward and Hopefully that actually materializes because it's a big risk to write books in this way so You know this I believe that Ruby 1-8 7 was about giving you a choice to saying you can enjoy some of these new features But you can take your time and decide when you want to move to 1-9 if at all But it really puts a lot of people between a rock and a hard place So I really feel at this point that the only choice for us was to you know take the jump and Just say Ruby 1-9 is where it's going to be and for our legacy apps We're gonna have Ruby 1-8 6 but that's sort of like a special you know separate entity now because they're not cleanly connected together Now I wanted to make sure that I checked my time and I'm good on it this issue before I go any farther on this talk I wanted to get at least a little bit of feedback from the audience about your experiences So anyone who has experience with this sort of decision whether you're a maintainer or someone who's looking at the language And hasn't really done much yet. Whether you're an author. I'd like to hear from you So let me just take two or three minutes of responses if you guys would like to share So I'm Eric Ogle if you don't know me I've maintained Ruby Jam's and a lot of the stuff and I think I'm going to start moving away from 1-8 6 support because they're just too many versions for me to handle But this is gonna be like take me more than a year to do so not moving fast Eric you mean moving away from 1-8 entirely or Lots of people still use 1-8 7 1-8 6 stuff and It seems like they've been continuing to back for some stuff from 1-8 7 to 1-8 6 even so stuff may still work on 1-8 6 I just won't care that it breaks I Back and Ruby Jen and some things like that break on 1-8 6 correct Last two things that I would drop 1-8 6 support for Are you targeting 1-8 7 or 1-8 7 and 1-9 Okay If you were to write in a syntax 1-8 6 and run it all ones 1-8 7 or 1-9 it's still gonna work So you can still code specifically for 1-8 6 without really coding Which functions are in 1-8 6 So as long as your references for 1-8 6 then you're good That's not correct, right there is 1-8 6 code that will break if you look forward to 1-9 Those issues have been resolved it, but that was a very serious issue at first I mean that broke rails and lots of other things a lot of those incompatible issues have either been resolved or have reasonable work around I just know that you know basically there was this huge huge fight about I Guess I started this fight, but So there's this huge fight about that particular issue and everyone in Ruby core was saying show us code that isn't compatible Show us code that isn't compatible and at the point that that actually happened people couldn't come up with anything that made sense So I mean that's again That was even true with 1-8 7 and I think that's what that thread was about It seems like that issue which scared a lot of people I mean the problem right now in my eyes is not necessarily that anything that is bad But who do you trust in the Ruby world right now in terms of versions? That is not a question that we can answer right now I think there's a couple of problems that arose partly because of the version numbering I mean like for instance people point out correctly that there's code in say 1-8 5 or whatever That won't run in 1-8 6 or code in you know 1-1 6 3 that won't run in 1-6 5 In other words the up the tiny number Upgrades have always not necessarily run the previous version part of the problem is that since they decided not to have a 1.10 a new There was kind of this you know the people on the course said this that there was a kind of redefinition of what the changing the third digit map So going from 1-8 6 1-8 7 just in terms of sheer quantity as you've shown is you know much More significant than any other third digit changes ever been in the history of Ruby and really there are those of us who feel that You know 1-8 7 should have been 1.9 and 1.9 should be 2.0 Or something like that and so a lot of that I think people have been thrown by the fact that Going you know one minor digit is this really major kind of change So yeah a lot of 1-8 6 code will run 1-8 7 But as you said before it it it's a less it's just a bigger jump And so it makes it harder if you've got a development environment where you know you upgrade your operating system And it's 1-8 7 and it's just a bigger kind of gap Also just one other thing that the fact that 1-9-0 Was really not kind of production ready and not stable I think also that has you know still has kind of ripple effect of making people skittish about 1.9 in general Was you know less of a smooth Transition and then would have been ideal obviously. There's a lot of reasons and so on for it, but I think 1-9-1 In that sense is you know, it's really important About the 1-9-0 issue how many people tried Ruby 1-9-0, you know a while ago had some problems and said oh wow This isn't ready. I'm gonna come back to this way later You know the thing is that if you were in those shoes You may be thinking that 1-9-1 is just a small difference between that now in my experience writing a book 1-9-1 except for the absence of you know the library support is Definitely ready in the sense that it is much better than it was a year ago It's something that we can start playing with that the the more progressive members of this community can push it forward and Library maintainers can push it forward and it could be a good thing But I mean that issue is definitely a good point now I'd like to stop this here because I think we could probably go on forever with it, but There'll be if I have more time for questions at the end. I'd be happy to keep talking about it So here's another sort of oddity that came up in the projects that I'm working on now in my company That I've worked for we mostly Deal with Unix which if you're working with Ruby is great because you know Ruby has really good support across most of the Different, you know POSIX anything distros, you know, so you don't need to worry about much But occasionally we need to do stuff on Windows, which is a totally different story Now this is just something that I find either hilarious or sad, but I want to share this story so We're building this API on top of a truck routing software that runs only on Windows and has a See API only on Windows and we need to be able to interface with basically a DLL and Then we're going to wrap this in a service interface. All of that stuff's not that important now One thing that is amazingly awesome right now is that we have a solution that's much better than see extensions We have FFI FFI allows you to wrap Libraries see libraries using pure Ruby and you don't need to compile anything and this is supported All over the place now. This is like my full Sort of presentation application But if you isolate it down to just the stuff that has to do with the actual functions We were wrapping now. We actually ended up wrapping like 60 functions but this is a simple example of just opening a connection closing opening a connection Getting a distance between two points and then closing the connection now if you look at the C Specifications for this and then the code that we wrote to wrap these functions so that they're directly callable from Ruby That's the whole thing That's it pure Ruby. You didn't have to think about anything now This library is really cool. I just have a random syntax proposal for it. I would like the Signatures to match and I'd like to do less of this boilerplating So I've talked to the guys that maintain FFI and you may be able to do something like this in the future Which is literally point me at a library. This is not just on Windows by the way to see library anywhere in fact, you know it's mostly not meant for Windows, but it works fine and You can just wrap an API just by Defining its signature. I mean that's awesome This works cross-platform on pretty much any operating system that you could imagine and it works across implementation Now this is interesting because it means that if you're using JRuby or Rubinius and I think Mac Ruby is working on this You can use it. It works on MRI and it works on YARV now That fixes a big problem these right now if you think about MRI versus YARV if you have a C extension it doesn't just work when you try to use it on one that and You know on these other things that on these other libraries the C extensions don't work either So if you write a MRI C extension, that's going to run on MRI and MRI only unless you do a lot of hoops that I don't understand So can anyone guess? What we chose to use on Windows as an implementation I know that the Ruby community has some animosity towards Java But the funniest and saddest thing in the world is that the easiest way to wrap a C library on Windows is with JRuby Now it is theoretically possible to build FFI for you know The masses Ruby interpreter on Windows, but it's not supportive and it's not done But to use it with JRuby. I installed the JDK and FFI comes with it I wrote that script that I just showed and I typed JRuby and then the file name and it worked That was the whole set up and this is sort of amazing to me and you know Seriously, what the fuck So I'm now going to segue into implementation stuff Yeah, I understand that but if you're using software like in our case In fact, we do absolutely no Windows stuff unless we have to but a client has a requirement for software that they use that Only runs on Windows. What are you going to do? We're going to write our own truck running software. I Mean, it's just it's a reality You know, it's a reality that you need to be able to work in Windows sometimes if you're working You know something that isn't just perfectly your own project But right now I promise that I talk about implementations and I have to be honest It's really hard to summarize this stuff and it's really hard in the course of a few weeks to give you any sense of What you should be doing with implementations so I focus more on the stuff that we've talked about so far and then what I've done in the end here is compiled a list of a list of The different implementations that I tried out what was interesting about it What was sort of scary about it and what my experiences were? So of course there's standard Ruby 1.8 and every definition that I make here will be an oversimplification So I labeled it as such. This is the Ruby that most of us know and love It's able to run most third-party libraries and legacy code bases and this is why most of us use it The exciting thing about this is that everyone in this room is using it. That means that we have a high community base It's well supported infrastructure wise. It's pretty easy to find a host that has Ruby It's pretty easy to get Ruby and in turn in the form of MRI pretty much anywhere that you need it And it's pretty cool that you know when we talked about this one nine one one eight seven one eight six fiasco That engine yard is taking up support for one eight six Which means that at least for the foreseeable future that that will be in good hands so that our old code still runs So what's concerning well the direction of one eight seven is controversial and I think that we've already proved that by the dialogue here so far and actually the ubiquity of Ruby one eight six MRI Maybe slowing down other and possibly better implementations of Ruby one eight at this point Jay Ruby is really damn good and I have embarrassed to say that just because I said it was Java gross That I didn't even remotely start looking at it until a couple months ago And it's probably been good for a while and it's working for the projects that we're using it for and that's pretty interesting to me Another issue with MRI is that it likely never be M17 and capable it would require too many changes to do the sort of tricks that they're doing in you know YARV and The things that are planned for the other implementations So those are sort of my thoughts about Ruby one eight on MRI so standard Ruby one nine is YARV and The oversimplification here is that it's fast and that it provides the only complete way to have this Multilingualization support for Ruby now most of us don't really care about that too much But there's definitely a demographic which this is important to and it becomes very obvious Why this is there when you consider who the core team is and what sort of problems they face in their work? And if you learn how multilingualization works on Ruby one nine, it's pretty inspiring. It's pretty interesting Exciting thing about this is that it's the Ruby of the future And it's significantly faster than MRI for a lot of things and it's also a much more solid foundation For standard Ruby moving forward to build on top of this is a much better implementation than what Matt's built Matt's is a wonderful designer, but he said of himself that you know Koichi is a better implementer The concerning thing right now is that the roadmap for Ruby one nine is whatever is checked in at any given point Which makes it very hard for other implementers to Know what is changing? Ruby community seems to be divided on whether or not they can put their faith in your how many of you can say? Absolutely that you believe that your is the way forward Okay, so we're still crossing a language barrier between the core contributors in the Ruby community Which is an issue that I really have no solution for but it's something that's still there and this is causing some issues because Ruby one nine might be more well-defined if more people were talking between the Japanese and English communities Okay, so I'm going to blow through these really really fast Ruby Enterprise Edition the over-selectification here is that improves memory and performance and It's aimed towards passenger based servers for Ruby one eight six Exciting thing about this is that I deploy to it regularly and I never need to think about it I don't I the first time I ever installed it on my you know laptop was a few days ago because every time I deploy the code I never need to think about it, which is great It's extremely easy to work with as well and get set up The concerning thing to me about this is that you know we've actually sharded this and made it a separate implementation even though it's really just a branch of standard Ruby and of course the Windows situation for those Unfortunate trend because it doesn't run on Windows though I mean, I would say fairly that if you're running Windows server side. There's probably a problem One thing that's super cool, and I've not seen this in anything else is how friendly this damn installer is for installing Ruby Enterprise Edition It's sort of like clippy, but not in an annoying way So it's really cool. So if you go and install this and saying don't worry We're not going to screw up your standard Ruby that you have on your computer Answer these questions and then it even tells you what gems you might need to get things up and running. It's really really cool Okay, so Jay Ruby I've already said a lot about it in this talk and it's clear that even though a few weeks ago I might have told you. Oh, I don't really care about that. It's really interesting The concerning thing is that in order to use C extensions You do need to rewrite them for ffi to allow Jay Ruby to access them Which means a great deal of Ruby libraries that depend on C libraries currently aren't working And it's also still new to us because we haven't looked at it and that leaves some dark spots uncovered But this is super cool. It's using a Java library Just directly calling out to it as if it were Ruby to take HTML and translate it into PDF like this There's no Ruby wrappers on this. It's just straight calling the Java stuff. That's really cool Rubius Rubinius for now Is dealing with Ruby 186 and it's following the path of small talk by implementing Ruby in mostly Ruby and This is really exciting to me and it has a lot of benefits I really need to get to a certain point Which is that these guys came up with a lot of the cool stuff the ffi stuff that you saw came originally from Rubinius The Ruby spec project comes from Rubinius. Do people know what that is? I Okay, so that's an attempt to specify all of Ruby using tests and these tests will Document implementation specific things version specific things. It's really quite amazing And if you go and look at this stuff, it's really easy to work with Now Mac Ruby, I think will be really cool, but to be honest I'll go through this I can put my slides up later and you guys can see my opinions doesn't really matter But there's there's too much type too early here, and I've had a lot of trouble getting this stuff up and running I got to this sort of hello world example of making a little button show up on the screen But that was pretty much as far as I got with it, but I really like the idea Now I did do some cool stuff, which I'm not going to show which is basically I ran the test the examples and gave my bias judgment on how well something works on prawn and You know basically all of the official stuff worked fine, but j ruby was really impressive to me because I didn't consider at all Now I just want to end with this which is a teaser the ruby spec project is so important Bees it allows us to communicate across Implementations and versions through code and it tells you what ruby really is by those specs And what I would like to do is I'd like to make a web interface so that all of you guys can know exactly where every Version on every implementation stands So that you can just type in a method name and see if it works and what the specs were on every Implementation and I plan to do this and you'll hear more about it for me soon So please contact me if you're interested in that idea Thank you Okay, I could take a couple of questions Ruby 1.9 co-existing on a machine 1.8 because I know that as recently as a couple of weeks ago the Snapshots for 1.9 had their own version number Install that you flat it all over on your own libraries for 1.8.6 So how do you set that up? Well the way that I set it up Okay, so asked about how you can have Ruby 1.8 and Ruby 1.9 Coexisting peacefully on a machine the way that I set it up and it's ridiculous because I do this not just for Ruby But for everything is that I just keep everything out of my path and only add it when I want it to and I put it in different places You know and it's tedious. It's annoying you can set up scripts to help with that and it's just the most surefire way to just know exactly what you're running and Actually when I did these prawn tests I was about to report that Rubinius was running as fast as MRI on the prawn examples Which is obviously completely ridiculous because of a mistake like that, you know where I was running the wrong thing, but Generally speaking if I'm working with explicitly setting paths that works well for me. I don't rely on prefixes and things like that What's that in 1.9? I tend not to rely on the suffix because I prefer it just to be completely in a separate space So that they don't touch each other and I set up I set up a alias that does Ruby 1.9 but I do it through path stuff basically Python some stack with some some not all running on the same machine So check out sandbox, okay, so I really would like to continue this discussion. So, you know, hit me up on Twitter I'm see creature there for obvious reasons and Or not at all obvious reasons