 Hi, hi everybody. Isn't this exciting or as I like to call it terrifying. I'm Charlie. This is Tom. We're gonna give you kind of the JRuby State of the Union to start the day off. First off, you know, huge thanks to Engine Yard for making this happen. It happened in a very short time. I think we started discussing this around the beginning of September and then within weeks we had it up to go. And the funny story, yeah, big thanks to Engine Yard for this. You know, the funny thing is when we opened up the registrations I was terrified that no one was gonna want to come to JRuby.com and then they sold out like that. So that was a really exciting day for us. You know, a couple words on Engine Yard. It's really been an amazing reception for us here. Looking at getting JRuby development support, cloud offerings out there. Anybody who is interested in looking at the cloud stuff or has tried some of the beta support out you definitely should talk to Kirk Haynes. Where are you? Right over here. And let them know what you've seen, what works for you or, you know, if you're looking to do JRuby stuff on the cloud in the future, what is it that you need out of that? JRuby.com obviously is a huge thing and lots and lots of support. It's been really a great experience for us coming to Engine Yard. Of course, when I thank all of our sponsors, I was also worried nobody's gonna want to sponsor this thing. It's just JRuby.com, right? But, you know, we got, we obviously got a lot of sponsors. A lot of people that are interested in this. And, you know, these are all friends of JRuby and we're really happy that you guys are able to help out with the conference. So thank you very much. So who are we? Of course, I'm Charlie and this is Tom. Hello. We also have Nick here somewhere. Raise your hand, Nick. And Ola is here. There are other JRuby committers and of course, lots of folks in the community, but we're the ones that are here at the moment. So the first thing I wanted to find out is who are all of you? So how many people here have never tried JRuby? Okay, there's a few folks at school. Maybe we can pull. That's great. We'll bring you into the fold here. How many of you have tried JRuby and maybe reported bugs, JRuby bugs? Okay, so you're the ones. All right, all right. About 30%. Yeah, now we know. Now we know how many contributed patches to JRuby. It's smaller, it's a small amount. And that's an interesting problem, isn't it? That we have that many with bugs and fewer with patches. How many people are actually using JRuby in production for applications right now? Oh, awesome. Awesome. How many of those are Rails applications? So not actually slightly less than that. That's interesting. That's interesting. All right, cool. All right, so we'll continue on. So we're going to do a little looking back a little history of JRuby. Not a lot of people know JRuby was not actually started by any of the current committers, started as kind of a pet project, toy project by this guy, Jan Arna Peterson in about 2001. So it's actually a fairly old project. Since then, we've basically replaced almost all of the original code. But, you know, Jan is out there somewhere. We've never met this guy, never talked to him in person. Is he here? Are you here now? We've never met him. But there's some mythology behind this. We're not sure if this is true that someone noticed that the C implementation of Ruby used a .wifile. And then someone said, well, I bet you can go and make that .wifile work in Java. And then I think it was Stefan Matthias Haust of all people who cranked it out like a day later. And I think that was the motivation for starting. Right. But it's mythology because we don't know. We still have not met any of those original guys. So someday we're gonna have to travel to, you know, wherever those guys are and find them. About 2002, Tom came on to the project. I joined in 2004 immediately after RubyConf 2004, because I was so excited about Ruby at that point. 2006, Ola and Nick came in. And then since then we've added lots of new folks. We've had lots of community folks come in. And we're at around nine active committers right now. The most recent ads would be Yoko Harada, who did all of the JRuby embedding APIs in the new one for really awesome work. And Sabu Sastri, who's our compiler guy working on the new JRuby compiler. And we'll talk a little bit about that later. So big milestones. 2006 was was the beginning, really, of where JRuby started to actually be useful. In winter 2006, we thought, hey, maybe we can actually make JRuby run stuff that regular Ruby use Rubyists are using before that time it could run Ruby code sort of. But the compatibility just wasn't there to run things that people are used to. So we started out with IRB. That's kind of the first thing that you want to get going because it has a lot of weird behaviors and requires a lot of core libraries. Got that working, you know, took a couple of weeks worth of work, but it got got it functional. And then rake and Ruby gems. And then, you know, towards spring, we start thinking, hey, we've got these basic pieces working. We've got most of the core libraries functional. What if we can actually get rails to run on JRuby on the JVM. And lots of people thought, no, this is impossible. It's never going to actually run with JRuby. But I guess Tim kind of Tim Bray kind of lit a fire under us and said, hey, you know, if you guys get rails working in time for Java one, there might be some surprises for you. And of course, the surprises meant that we spent all of Java one doing press and other nonsense. So that wasn't quite the surprise we were hoping for. But in the fall, we finally managed to work with son and come on full time. And we got a lot of help over the years from Sunday to really make JRuby go. So I would like a quick round of applause for everything that son has done for us. So we should probably tell at least one story. So it was less than one week, I think like three days before Java one, we got accepted for a talk and we did a few pretty late runs to try to get a spike to get rails working. And then we were really excited. It was like three days before and rails was running. But we'd go and like try to load a simple view and it would take like a half a second or three quarters of a second for one page view to come back. And we're like, well, this is really impressive to us because we know how much work it takes to get rails working. But the Java people are going to look at it and go, oh, wow, when can I start using rails? But we don't know anything about rails development. We certainly know more now, but we're not rails developers. And then we're at a coffee shop and then Charlie's like, well, why don't I go and look to see how you tune rails apps? He's like, hey, we can set it in a production mode. Who'da thunk it? And what an amazing discovery. All of a sudden it ran fast enough to demo. It was like a like a switch flip. All of a sudden, hey, maybe this actually will be useful for some people. So that was pretty fun. And then, you know, proceeding on 2007, you know, it was roughly seven or seven, eight months or so after we came to Sun, managed to get JRuby 1.0 out. And that was, that was a really exciting time. We had it running well enough that we thought people could put real apps up on it. And to our surprise, a few people did. Thoughtworks in Oracle being among some of the earliest adopters that actually started building stuff off JRuby 1.0. We look back now and we think, God, you guys were nuts. That thing was nowhere near ready for production. But it worked. And they managed to get it to go. In 2007, summer, we started working on the JRuby compiler, which led up to the 1.1 release in the winter of 2008, which was really the first JRuby release that actually ran Ruby code faster than the C implementation, which we really was, we really knew we could get there, but we weren't sure when it would happen. So it's pretty nice to have that in JRuby 1.1. And then, you know, continuing on, the fact that JRuby has always had native threads that actually run concurrently. In 2008, the Rails thread safety work started, leading up to the Rails 2.2 release, the 2.2 release that was, that had thread safe support. And now there's a lot of folks running with JRuby in thread safe mode and getting some, some amazing performance out of that. You know, in the fall of 2008, we started doing some more Java integration rework, trying to clean things up. And that brings us to 2009, which is obviously a huge year for JRuby. We've had three major releases. I ran some of the numbers last night and we've had over 1,300 issues resolved in the past year. I don't know what that, that works out to four or five issues a day, something like that. Thousands of commits, thousands of commits. I think we have more, more commits in 2009 than in the entire rest of history of JRuby. And of course, the move to Engine Yard and JRuby comp. So it's been, it's been a great year. Over these years, we've gathered lots of friends, of course, son, oracle, dot works, Collaborative Software Initiative has been a real big fan for their trisano product. LinkedIn's polls was running on the last time I checked. Relevance has a whole bunch of JRuby stuff. And of course, there's lots and lots more. I mean, there's too many people to list that have been our friends over the year and helped us go, helped us get to where we are now. So we've come a long way from, from being the, the joke at Ruby, RubyConf 2005, where people went out of their way to put jokes in slides after my talk about how goofy JRuby was to now actually people are running stuff in production with JRuby and people are really, really excited about it. And that's, that's great. We've really, we managed to get a long way. So, so where are we now? JRuby 1.4 is the most recent release just at the beginning of this month. Again, massive amount of work, 300 plus bug fixes since our 1.3 release in the summer. 1.8 support is now up to 1.8.7. So we finally made the move to 1.8.7. Seems like it was the right time to do it. The 1.9 support in JRuby 1.4 is improved. It's not quite complete yet, but it is, it is a lot better. And we've got a bunch of contributors that are helping us get 1.9 really working solid. And the, the basic apps do work in 1.9 right now. You can generate a simple Rails app. You can run Ruby gems, rake, IRB. Right. Exactly. So it does, it does work, but there's a lot of edges that you'll hit if you start running it. So there's more work to do, but we're really glad with how much we've gotten done. An installer and a native executable for Windows. We'll talk a little bit more about really trying to prioritize Windows support a little bit better. But this was a huge help for anybody that's running on Windows. Lots of Java integration improvements. The new embedding API I mentioned from Yoko, which has made it far, far easier to embed JRuby into existing Java applications. We have a bug for bug port of the Psyc YAML parser, SIC YAML parser. Thanks to OLA. I think this is number four now. Number four YAML parser for OLA. But it means that we actually have no open YAML bugs in the tracker anymore, which is, well, I have a couple that I filed. And there's a few others, but no, no user reported ones, I think. So OLA has almost done as many YAML implementations as there are YAML implementations. So yes, if you want to know about, if you want OLA to implement a YAML parser for you, you can go right to him. Never say never. All right, lots more memory reductions. We did a little bit of work in one three additional work in one four, updated all of the libraries we ship with and then, you know, a little performant focus performance fixes. So it was a really big release, at least as big as one two, which was probably the other gigantic release that we did in 2009. Again, a note on compatibility. We mentioned this in our JRuby talk at RubyConf. JRuby actually runs more tests than any other Ruby implementation. We run all of the Ruby spec, up to 37,000 of them passing, which is, you know, high 90%, 98 something like. We also run a whole set of other suites of tests. There's some overlap, of course. We don't know exactly where the overlap is, but we're terrified to pull out any of those other test suites in case they're not being covered by Ruby spec. So we run tons and tons of tests. Continuous integration, we have the machine in my box that's keeping my basement warm, is actually running Java 5, Java 6, and Java 7 versions of four different vendors of JVMs on every commit. And that's Ruby spec and all of the other tests. And then every night we run on one of those, one of those Java implementations with all of the different JRuby settings and configuration options, which is about a about a 30 minute test run. So we've got a lot of testing going on. I think that machine runs continuously. And we're also running unit tests for Ruby on Rails. Yep. And we've also got Rails stuff running on there. And we're just going to start pulling in some specific gems, some important gems, so that they run on continuous integration as well. Incompatibilities, there are a few things that we still need to work on or may never be able to support, like fork. You're not going to be able to fork a JVM anytime in the near future. Strangely, we do have an option to turn it on. Yes. Yeah, you can play with that if you really want to. And fork is there, but I don't recommend it. Don't use it. No continuations, at least until the JVM has continuation support. Startup is always a challenge for us and it's probably one of the main things that drives people away from JRuby. So we constantly are trying to improve that, trying to solve startup issues and make it make it a little bit faster each release. And I think I saw that Vladimir is working on that a little bit now too. And of course, the C extension thing, which we'll talk a little bit more about later and try and find ways that we can work around that problem. So a little bit about the JRuby community, which is a lot of you folks and a lot of folks that weren't able to make it here, nine active committers, as I mentioned, we've had dozens of external contributors, probably hundreds of external contributors over the years, but dozens that are active right now submitting patches. We have no idea how many users there are. Every time we go to a conference, we hear from another dozen people that we didn't even know about before. So there's lots and lots of folks out there that are using JRuby. And it feels like we're kind of at a tipping point. There's more and more people that are actually starting to use it. We've gotten to compatibility point where people can just take their apps and run them. And that's great. And we're really happy that things work so well. So if we can ask one thing, if you've actually deployed a production JRuby application and you're allowed to talk about it, please tweet it or blog it or let us know. We want to know. Join our mailing list and say it because it's really nice to actually see that people are using JRuby. Yes, yes, definitely, definitely. A lot of shy people in the world. Yes, yes. Well, and I think a lot of the Java world is kind of, you know, will keep everything behind the firewall and never really talk about it. I didn't subscribe to Struts lists when I was doing Struts development. So I can appreciate that. But we really would love to hear from you guys. OK, so we got talks at just about every Ruby conference more than we can cover. And so there are other people that are picking up some of the slack for us. We'll talk a little bit about that later too. And we feel like JRuby really is part of Ruby. It's part of the Ruby community now. And that makes us really happy that we've kind of been accepted into the Ruby world. JRuby is everywhere. People are doing stuff with JRuby all over the place. Everything from cloud applications to JRuby in your pocket. There's all sorts of stuff that's going on. We're trying to support all of these different layers. If you're interested in any one of these, please let us know. We'd really like to know who's doing desktop and games and mobile and whatever else. Because there's so many opportunities. Since Java is everywhere, JRuby can really bring Ruby to all these different domains. And that's what we really want to make possible. And we've gotten even more friends over the past year or two. Guiltgroup, we heard, is doing a whole bunch of JRuby stuff. It sounds like a huge amount of traffic going through their JRuby servers. Oslo's airport now running the JRuby point of sale terminal for refueling airplanes, which is a little scary for us. But it's a lot scary for us. It's a lot scary. It's almost like running Twitter. Oh, not quite that bad. Not quite that bad. The Alan Telescope Array up at UC Berkeley is using JRuby as kind of the glue to script together all the different components and all the different drive systems and everything. And the great quote we got from those guys is, if we find intelligent life out there, JRuby will have helped to find it. So that's pretty cool, too. Pons.eu is a very large European dictionary site. They switched to JRuby because they needed to basically have the entire dictionary in memory, multiple gigs of data. And the only way they could do that was to run on JRuby, and it runs great for them. Detect Wireless has some stuff going with JRuby. And of course, Edgecase is doing JRuby stuff. So, again, more people than we can list that are actually using JRuby in production and are really happy about what they're getting out of it. And so if you're not shy, your name could be here next year. That's right, that's right. All right, so I'll hand it off to Tom a little bit to talk about some of the future of where JRuby's going. So these are some near-term goals that we have, at least near-term issues that we recognize that we have. So the first one is Windows. And this is actually quite funny because what the hell are we thinking? We don't like Windows and working on Windows. So we didn't really give it a lot of attention because we have MacBook Pros and whatnot, but how many Java developers are on Windows? So, how many people use Windows here? Wow. Less than people supplying patches to JRuby. Yeah. Yeah. But be that as it may, a vast majority of people who do Java are on Windows and we think we need to go after Java folks more. Right. Well, an interesting story about this, we put the Windows installer out there and suddenly we had a whole bunch of new users coming and porting issues with our Windows support, which is actually why we ended up doing an RC2 and an RC3. All these Windows users realized that there were things that just didn't work and until we had the nice installer, we didn't even know these people were out there. It's probably one of the biggest upticks in traffic was when we got nice Windows support. So those people are out there and we really do need to support them well. It was literally bad enough that we realized that our .bat script sucked so bad that we had to make a native launcher. So, hey, it's great, we're gonna keep doing this and see how many more Windows users we can get. And JRuby may be the cleanest and most compatible way to run Ruby on Windows right now because we have put in a lot of work. And we have a few problems that we've had forever and we know we've had them forever. Our JRuby launcher on Unix is a shell script and there's some libraries that'll actually in the she bang line at the top of scripts put options to JRuby. Well, you can't pass that to a shell script and have it see that. So we have a large motivation to actually make native launchers for all the Unixes. Right, hopefully in 1.5 we'll have native launchers for all the different platforms so we can get around the bash script stuff. And then we also have this problem where we'll submit a issue for Mac ports to say hey, 1.4 is out now, you need to put it in there. Four or five months later it shows up and by that point we're already on the next version. So we wanna have native installers so that people can just download it off her site. Right, so have a package installer or a shell script installer, something like that that actually puts it in place for you. Horizontal Java integration. We wanna just kind of fill out the rest of the spaces that we know haven't been implemented yet. We wanna make Ruby to Java, really generate a .class file for any particular feature of Java like annotations. Right. We have tons of little corner cases that most people don't run into when they actually consume Java classes but they're there and so we wanna fix those. Right, we know about those. And really this is about trying to get across all libraries, across all use cases, all the little Java features in JRuby working really well. And vertical Java integration. This is similar to the whole Windows problem that Java people actually use Java in their own Java projects. Surprisingly. Yeah, unbelievable. But if you want people to use JRuby and use Ruby on Rails, you wanna integrate into their environment. So we'd like to be able to easily consume hybrid aid objects from Ruby on Rails. And if there's any experts out there, I think we'll reiterate this call for experts like two or three more times. Or we wanna make sure that their testing environment, it's very easy to plug in to JRuby and their build, just their environment in general. And also there's been a lot of interest lately in people actually calling across to different languages on the JVM. So there was, what was it, Scallop? What was the? Scooby. Scooby is the Scallop JRuby wrapper. And I know there's, I saw there's a lightning talk proposed for JRuby with closure. And we wanna make that all as easy as possible and make it fit really well. It's really a benefit of being on the JVM that you can use these other languages for the purposes they're really good at. Startup time, as Charlie mentioned earlier, is an issue that we're working on. If you learn nothing else today, learn that stat is the root of all evil. Yes. It's almost always your performance problem for some strange reason. So we actually have a statistic up here. A medium-sized Rails app, we measured the number of stats that happened. And it's stated about 113,000 times to load 3,000 files. It's a lot of file system access and a lot of memory access. A whole lot of nothing going on. And I think we're doing like four times as many stats as the C implementation of Ruby, so. Right, and this was really a big, this really is a big impact on slower file systems, like if you're running on Google App Engine, stats are extremely slow. And file system access is extremely slow. And those guys, there's almost unusable to get it to start up. And this is a large reason why. So we're gonna look to try and fix this as much as possible. And there's a bunch of things that we're doing that aren't being used. Someone recently brought up to our attention that Set Accessible is getting called like 5,000 times when Rails starts up. And this is to do things like set protected methods so that we can call them even though we're not in the same Java package. But we probably only call these methods like once or twice. So we're doing 4,998 too many Set Accessible calls. Exactly. And we also have this thing called Nailgun, which is a separate process that gets spawned in the background and it starts up the JVM. It loads JRuby up. And then if you invoke command line invocations of JRuby, it'll actually forward that response there. Yeah, it just sort of tosses it over to that running instance. Now things like Autotest will execute extremely fast because it doesn't have to wait for everything to start up next time. There's still some issues trying to get Rails to boot fast even on that remote system, but it's helped. We're getting there. And the reason is stat. Yeah, it probably is. Here's that. C extensions. Similar to not reporting that you've deployed production apps, we also don't know which gems aren't working for people. So every time you run into a gem that doesn't work, or because it's a native extension or there's just a bug in it, please report it to our issue tracking system. Or at least know that it doesn't work. Right, don't assume that it's the gems fault either. We're willing to do a little footwork ourselves to see if it's JRuby. If it turns out it is the gem that's got a problem, we'll toss it back to the gem authors or try and help them. But we just want to know what works and what doesn't. Right, there is also visitjruby.com, which you can start to use to report things. And hopefully we'll get some metadata like that included in rubyforge.org stuff. Or yeah, rubygems.org. And we've been pushing foreign function interface as a way of solving native C extensions. If you go and do the work and provide that to the gem maintainer, they're probably fairly likely to accept it. But of course, you can write Java native extensions if you want, and then that's a little more friendly for Google App Engine and solutions like that. Right, there are a lot of environments that simply, even with FFI, are not going to be able to load native libraries. So there is always a push to get a pure Java version of anything that's native for regular ruby. And of course if anyone has any ideas on how to fix this disparity between C extensions and Java extensions, come up and talk to us. It's likely we didn't think of something. Active record JDBC, these are sort of some hip ironic statements. MySQL adapter is not yet perfect. What this means is for the last three years, we've never had a green run of MySQL unit tests on Active record. And the other adapters are in various states of district pair. They generally work for common stuff, but we know that we have to work on this. And I think Nick's gonna spend a little bit of time on this in his talk. And if anyone's having performance issues with Active record JDBC, come and talk to us. We did some optimizations for queries like eight or nine months ago and got the performance pretty good, but... There certainly is a chance that it's Active record as well. But if it's something specific to us and we're significantly slower than running on regular Ruby, we definitely want to know about that. Geeking out. Okay, so we'll talk about some cool stuff that's coming up for JRuby, a little bit more, kind of a more positive spin on some interesting things coming for JRuby in the future. Java 7 will be coming out someday. Someday, yes. I think it was pushed back again, so... It's up to milestone five, so they're moving along. I think October. October 2010? October, wow. All is always the source for the latest up-to-the-minute Java reporting. He told us three days ago that closures were gonna be in some. Yeah, so. So InvokeDynamic is a way of informing the JVM how we want to do method dispatch as opposed to how Java actually does method dispatch. And the benefit of this is that it'll do a whole bunch of optimizations. We'll get to get rid of a whole bunch of special code we do to get good performance out of Java 6 and Java 7. Basically allows us to inform the JVM of the best way to do a dynamic call for Ruby so that it can optimize our dynamic calls the same way that it optimizes all the other Java calls. And I think they're talking about the JVM guys are pretty convinced that they can make this at least as fast as running with like an interface call in regular Java, which should be pretty exciting. And we're looking forward to all the optimization coming from that. Sun recently started having these JVM language summit conferences. And it's been really great because we've had direct interaction with JVM engineers. Well, of course we did when we were working at Sun, but they started to realize that some of the ergonomics they have for tuning garbage collection and these various internal settings are pretty good for Java, but they're not so good for languages like Ruby where you create a lot more objects than there's different needs. Yes, yes. There should be some better ergonomics for supporting different languages on the JVM. And escape analysis is listed at the bottom, but there's always a collection of new optimizations that are coming in each version of Java. And whenever we upgrade Java, we're always pleasantly surprised to see our benchmarks speed up by 15 or 20% and we're not doing anything other than upgrading. Yes, nice to get free performance upgrade just by going to a newer JVM. We're working on a new internal representation instead of our older AST. And there's a next generation compiler in fact, we have this compiler guy. He's his nickname, Sabu. I can't pronounce his name. Sabermanian. All right, good, very good. He got his PhD in writing an optimized Java compiler and now he's trying his hand at making an optimizing Ruby compiler. And the interesting part of this versus our old compiler is that these are higher level Ruby optimizations. So we'll do Ruby method inlining. So in the old compiler, we would still generate the byte code for doing a method dispatch and then hope that hotspot would go and optimize it away. And actually hotspot does a really good job but there's still a certain level of irreducibility that we couldn't get past. Right, we hope that we're gonna try and give hotspot a little bit more information about how to optimize Ruby code. Maybe do a little bit more upfront so that it doesn't have to work quite so hard and then we'll get a better performance as a result. And so there's some other cool stuff like maybe type propagation. We might not actually create a Ruby fix num at all. We'll just use a Java primitive to go and loop over something or Ruby block inlining. I don't know how many people know this but invoking a block is quite a bit slower than invoking a Ruby method. If we can get that to inline all the way back to the place you call each or map or whatever, we can probably just reduce it down again to a loop. So, Duby is one other thing I've been playing with. I did a talk, my second talk ever on Duby at RubyConf. It's something else that we're looking at as kind of an experimental thing for future JRuby contributors can possibly use this to help write JRuby. If you need to write one-off Java code and you don't wanna write Java, you can use something like Duby to generate that code. And learning different ways that we can use this to improve JRuby and bring some of this back. If you wanna know more about Duby, I know that my talk from RubyConf is gonna be online. I did another talk at Strange Loop. And hopefully this will help bring more Ruby folks that really don't know Java or Java syntax so that they can help JRuby move forward a little bit. So, library optimizations. Realize, recently we realized that one of the most common innumerable types or innumerable consuming types was Ruby array. And we realized we could make a fast path through there. And by doing that, we ended up getting a 20 to 30% speed jump over what we had, which already was pretty good performance. And for very common types, we're gonna start doing some profiling with Rails and figure out what things are getting hit and try to do more optimizations like this. Right, getting things to run is only the first 10% of doing Ruby. Then you have to go back and figure out all the core classes and all the bottlenecks and make sure everything's running fast. And that's an endless process, but we're coming back around to some of those now. There's a lot of interesting side effects like these optimizations also produce less garbage, which has less GC pressure, one of our favorite terms now. Yes, yeah. And actually there are paces where we're doing very well. Some of the numbers reported in RubyConf were that JRuby's hash operations are probably the fastest of any of the Ruby implementations at this point. If we can spend that kind of effort on other core classes, things will be that much better. The array can be that fast, will be in great shape. Okay, taking a little inspiration from Yagui. Yagui in her talk at RubyConf was, had the word help written in like 96 point font. And this is a common thing that all open source projects have is they have a need for help. They always want more people to help contribute. One of the things that Yagui wanted was for people to go and try to take maintainership of certain aspects of the Ruby Standard Library. And that's also helpful for JRuby. So if you're interested in doing that, she's in like the fifth row right now, so get her. Definitely help out Ruby Core or JRuby or whatever. Contributors are what keep these projects going. But from this point on I'm gonna talk about how you can just help the JRuby project. So here's a graph of our issue tracking system. And this is pretty illustrative of how development works on the JRuby project. So when you see green, that means we're fixing more issues than are coming in. When you see red, well, we're hemorrhaging issues. We're falling behind. Yeah, so when you get close to a release like JRuby 1.4. That's that line in the middle there is the JRuby 1.4 release. We start to get much more anxious and nervous about fixing issues. We're spending a lot more time triaging. We're begging people to go and submit patches and we make a dent. And then we release a new version of JRuby and then people try it and then. Then it goes the other direction. It goes the other way. It's kind of hard to read on here, but this 30 day summary shows that in the past month we've had 110 issues reported and that works out. And that's about right. We've worked out to three or four issues per day every day for the past three years. So the fact that we've managed to only fall behind by a couple hundred issues is amazing, but it's a constant stream of things and a constant amount of work that's required to keep up with it. Okay, but before we talk about new people joining the project, we should probably acknowledge a few people who have already been helping. We had a committer of Latimer. He took like a one year hiatus or maybe health leave, I don't know, but he's a phenomenal developer. If you look at issues created in the last two weeks, like 75% were actually created by him. And thankfully he actually fixes more bugs than he reports. Yes, he's carbon negative, I think. And then there's people like Hero Asari who is in the front row. And David Calavera, they're sort of tag teaming to address failing Ruby specs and they do a lot of great patches and triaging of the problems. And there's just so many other people in the project like we had people raise their hands earlier and it was like 15% here. It's very impressive. And again, your name could be here. We'd love to have you help out and contribute in any possible way. And we're willing to hold your hand the entire time and try and make it easy for you. Help. Okay. Evangelism, we made a recent realization that Charlie can only do so many presentations a day. So, we need people in different parts of the country or the world to be able to do regional Ruby conferences, regional Java conferences. Java conferences especially, if there's a lot more than we can even cover. And that's the huge, huge area for JRuby to grow and to grow the Ruby world. And user groups and the truth is people that actually use JRuby on a day-to-day basis can do a better job of selling it than we can because people will always think that we have an ulterior motive because our jobs are developing JRuby. Right, right, especially people that are running this stuff in production and know that it works great. Get out there and spread the word and let people know how well this stuff actually works. It was mentioned before, but we don't know Ruby on Rails. Nick does, but we need people that are willing to go to particularly Java conferences and do JRuby on Rails tutorials. How many screencasts do we have? I think it's still zero. Zero, yeah, so. If anyone likes doing screencasts, that would be great, people love screencasts. We're willing to walk you through it and provide scripts and all the details that you need to build it. We just have no idea how to do screencasts ourselves. Blog, tweet, generate interest, have fun. Documentation, this is always the saddest plea because no one likes writing documentation and we're not writing documentation, so why are we asking this? Yoko Harada recently got her new embedding framework merged into the JRuby project and one of the reasons why she was able to do this so easily is that she wrote awesome documentation. She set up a wiki and we have nice like little cut and paste snippets that we can go and paste in and compile. It was very easy for us to review and figure out how well it fit the bill and. We've had an overwhelming response from folks that are doing embedding of JRuby with this API. It's an incredible amount of work on the documentation and it shows how much that really can help when you have a good set of examples and some good walkthroughs. We just wish we had this for everything in JRuby. So has anyone used Redbridge yet since it came out? Used the JRuby embed container stuff? I think two people. Okay, okay. All right, so again, a call for feedback. Try to test gems that you use, try to run the unit tests or specs for that gem and if there's problems report them. It could be a problem in holler testing which you'd be helping that project and if it's not, then we'll fix the problem. Yep, yep. Multi-threading is kind of a bigger order to ask of you but if you're running your Ruby on Rails app in multi-threaded mode, just doing a simple code audit looking for like lazy initialization of class variables or things that obviously couldn't work in a multi-threaded environment. Globals are not something that you should probably be using in multi-threaded environments. If they're not putting locks around these things and they're obviously wrong, so. And then definitely we wanna know if there's performance. So specific gems have performance issues and really if any piece of Ruby code has performance issues, we have a performance category in our bug tracker and we wanna know about those so we can figure out why it's not running as fast as it should be. In Ruby specs, an amazing project. It helps us to find what Ruby is and more specs gives us more confidence that we really are Ruby. Yagui's and her talk brought up the fact that we have this language divide between Japanese and English and but we all speak Ruby and Ruby spec gives us a really unambiguous way of talking about what Ruby is. Right, it's our chance to really show that Ruby is a great language and help define what it means for the rest of the world. This is what's going to ensure that all Ruby implementations can run Ruby and are reliable in the future. So we all need to try and contribute to it. Everybody should submit a pass to Ruby spec at some point. That's right and it's very easy to get a commit bit. Yes. Ruby 1.9 support is something that we all wanna make sure is a great first production release. So if you can in particular work on Ruby 1.9 specs that would be even better. That's a perfect example. We can't really do want Ruby 1.9 support and know that it runs well until we know what Ruby 1.9 is supposed to do and although the MRI tests are great and they do cover quite a bit, we need to have full-on spec support and have all of the Ruby 1.9 features in there. And of course hacking. I suspect most of the people here actually write code on a day-to-day basis. So this is probably the easiest slide to help with. Help us fix any of the pain points that we listed before, obviously, but try to scratch your own itch because odds are if you're having a problem someone else is having the same problem. In vertical integration, again, if you know Hibernate well. Hibernate, JPA, Spring Persistence, other libraries. We'd love to have people wrap some of that stuff. And actually that's one of the biggest ways that we've drawn people into using JRuby. They wanna use Lucene or one of these other libraries but they hate using the Java API. Someone comes along, writes a nice Ruby wrapper for it. Really easy to do if you know the API and then everybody's able to use that library from within Ruby applications. And if you're in a mixed mode environment where you have Java application, framework stuff, and Ruby and Rails stuff running side by side, you should talk to us and help identify what the pain points are because we wanna improve that picture. Absolutely. So in general, the future looks really bright. Everything is running really well. Performance continues to improve, release on release. We continue getting Java integration all solidified and fixing all the remaining issues and we're really excited. We're really glad that you're all here and we wanna keep making JRuby the best possible tool for you. Oh, and we have one more thing, one more little announcement which is exciting. Yes, we finally will be getting a JRuby book out. We have several chapters done already. It's the core JRuby folks and our friend Ian who's been an amazing lead author for us. Raise your hand Ian. Yes, great, big thanks to Ian for this. We're not sure when we're gonna have a beta or when we're gonna have a final book, but it is moving along and it's looking great. We got a lot of good content in there. Hopefully we'll be able to accelerate a little bit after the conference season kind of calms down now. And so that's it. Enjoy the show everybody. I would love to talk to each and every one of you about your JRuby uses. I'm not sure we're going to get to that, but if you have something specific, come and grab us in between and at lunch, in the hallway, whatever, and have fun. We got a lot of good talks and a lot of other JRubyists here. So make sure you talk to other people and meet other folks. Thanks a lot. Schedule, I think this was supposed to go to 1050 and we're...