 Okay, so Coby tells me we're a little behind time so I'll try to go right and get started. Hello, nice to see you. I am very, very, very sick today so I'm just doing a little bit of stuff and dancing around and any time I feel like I'm kind of going to fall over, I'm just going to make Aaron jump in for me, which is my way of keeping him in the reverse. So, thanks to you both for being cool. My name is Thelma, and this is my heterosexual life partner, Louise. Hello. We are a regionally known web architect and the text works. You may have heard of us. We work for ATT Interactive for Coby, who is awesome. And we live up in Seattle, which is raining and sometimes awesome. So, very good day to talk to you about a couple of different languages. The first one is JavaScript. And most of you probably know about JavaScript. It went through a bunch of different names. It was invented by one guy who was highly, highly stressed and hacked it up in a couple of weeks. And we've been living with these mistakes ever since. It actually started out as a much more skeiny kind of language than it did with the C-Syntax. And it got sort of the familiar look that we're used to seeing slack on top of it afterwards. It has prototypes like some languages. It has C bits like some languages, but it's not really like any of them. So, to give you a really, really quick refresher, JavaScript objects are simultaneously hashes and objects. You can get to them through the indexer just that we're used to getting to things. You can also get to them through something that looks remarkably like a method of us. JavaScript functions are totally free and first class. You can create them anywhere. You can set variables. You can call them through variables. But, unlike our lambas, except under certain special circumstances, you can also find them into an object so that they have it this. Also, JavaScript doesn't particularly have any classes. You can take a function, tell it to pretend to be a constructor, and create new copies of this function with its prototypes and stuff like that. But beyond that, it doesn't really have any of the sort of class, inheritance, semantics that we're looking for. So, really, really quick light interaction. Strangely, language that's way more popular than we might have expected it to be based on its origins. But it's very important because it is everywhere. It is absolutely everywhere. It has the widest penetration of any program from language as far as consumer devices are concerned. It's on your browser. It's on a lot of your phones. Probably most of your phones here. It is on the moon. A little unfactless. JavaScript on the moon. It is in most parents' recipes, which I'll call for some level of delicious JavaScript or whatever. I'm not that good at cook. I'm going to specify for the JavaScript. The other language that we want to talk about today is Ruby. I guess it's probably safe to assume that most of you know all the basic facts of Ruby, so I'm not really going to go over anything else like that. I'd much rather talk about why these two languages are important together. And you should care because we like the internets. Most of us probably work on the internets, too. Specifically, the two most confused. Specifically, most of us probably work on the worldwide web. And the interesting thing about the web, especially for those of us with our idea, is there's a great big cast of cares. We use a client-side behavior, and a lot of things are written in JavaScript on one side, and then we have tons of frameworks we're dealing with. Persistence with control flow and everything else on the other side in Ruby. And these two sides, we use them together all the time. Every day we switch our brains between coding for one and coding for another. Sometimes a couple of times a minute, but they're very, very different on the inside. And I'm going to high-five in the corner. High-five. For JavaScript, the browser is the runtime. And this is unfortunate to us because it causes a tight coupling. JavaScript is very bound to the browser. We can't bring it to the outside world, and that kind of sucks. But the good parts are that we get a sweet standard library when we work on JavaScript. We're able to modify dog queries sometimes. And that's what I did. Another awesome thing is, I don't know, how many of you guys use package management through JavaScript? This, that package management? Also, excellent, excellent command line test frameworks, such as that one. That was probably my favorite, this one. Continuous integration systems. I know we use those in Ruby, but you also have this one available in JavaScript. That's not my favorite. No, but this one is my favorite. But unfortunately for us, everything depends on the browser that comes to JavaScript. Up to free the runtime. We want browser-less testing, file system access, easy extensions, and easy experimentation. And this is where we're coming. Hi. Good to be here. So we worked on something called Johnson. Johnson is a way of embedding a JavaScript runtime in Ruby or a Ruby runtime in JavaScript. We're not really sure which one it does. But what it does is it bridges that huge divide between two languages. You can use JavaScript in your Ruby. You can write a little snippet of JavaScript that will return you an anonymous JavaScript function that will act like a land-based Ruby land, just like that. You can use Ruby in your JavaScript. You can go the other way and acquire something in Ruby, write a JavaScript function that talks to the IO, get something back, and does something with it's all in JavaScript. Yes. Have you ever written a rack out? I absolutely have written a rack out, Aaron. Oh, really? What language did you write your rack out? It's JavaScript for that rack out. Interesting. Yeah, you can do that. Anyway, if you guys need them all, we'll take them for a second here. High five. So the dynamic internets. We all use the dynamic internets when we're working with Rails. Everybody knows what this stands for. And another thing that we do a lot that deals with JavaScript is screen-scraping. It's not just for these facts. It's mostly for these facts. Ah, I see. Sometimes there are websites which just don't have APIs when we interact with them, so we use screen-scraping techniques to do that. The internets are full of JavaScript JavaScript. Everywhere. So what can we do to deal with this stuff? We have tools for scraping webpages such as Mechanize, but unfortunately, given some clients that are JavaScript, we can end up with failed results. It's incorrect. But if we integrate Johnson, we can actually get something for Rails, something we might expect. Thank you, Aaron. High five. So one of the things that we ship with Johnson is Michelle. It's basically just like IRB for O2 languages. So just give you a quick lightning tour of some of the stuff you can do with it. When you start, it gives you a JavaScript prompt, just as if you were having an IRB one. When you're in there, you can type in a JavaScript command, so you can get back results in the console just like you'd expect. You can also tell it by typing because it would be interpreted as part of the second process. In both directions, you have access to the other runtime. So here, for example, we're creating a little lambda that just puts whatever comes into it, and we're binding it to a global in the JavaScript runtime. Once we've done that, when we switch back to JavaScript, we can call it work just like it was a JavaScript method and add it to how to call Ruby and do its thing. And just like I showed you before, you can immediately hop between with stuff you can expect to be able to hop between with the pass-by reference or some of these functions or lambas in any of your directions. Everything that can be is pass-by reference, so if you move an object across the divider in the JavaScript, and you bring back into Ruby, we're not in Marshall, we're not doing the copies, we're actually doing the reference proxies. Yeah, it's doing the proxies. Ah, yes, the magic. How does this magic work? It works via Johnson Process. Now, in Ruby, everything is an object. And in JavaScript, everything is an object too, but unfortunately, the two objects speak different languages. They can't talk to each other. So, in Johnson, we've provided a plus-nine ACMI disguise kit. See, we've got objects over in the Ruby country and objects over in JavaScript country, and they need to be able to talk to each other. So, we use this disguise kit to enable them to speak to each other. We wrap our JavaScript objects with the disguise kit such that they can speak to each other when you're in Ruby country. They both speak the Ruby language. When you move over into the JavaScript runtime, we proxy the objects such that they can speak JavaScript to each other. And this is all done transparent. So, you can see here, we've created a new Ruby object, put the object into the JavaScript runtime, move over into the JavaScript runtime, call some methods on the object. The important thing to note is that this was all done, what am I looking for? With no interaction from the developer, it's completely transparent to the developer and also to the runtime. So, the JavaScript runtime does not know that a particular method was implemented in Ruby, and it doesn't know that the Ruby runtime doesn't know that a particular method was implemented in JavaScript. We also do fancy margining. Unfortunately, regular expressions happen differently in JavaScript than they do in Ruby. So, we try to be intelligent about that. For example, moving this regular expression into the JavaScript runtime, we actually move it into the native JavaScript regular expression. So, right here, we're assigning a JavaScript function or assigning a function to a Ruby object in JavaScript, moving back into the Ruby runtime and calling that JavaScript function in the Ruby runtime. And from the perspective of the runtime, it's just a single method in Ruby like we would define on any other question. Now, we can attach JavaScript functions everywhere. So, we can even get access to the strings prototype in Ruby. This code here is accessing the strings prototype in Ruby even though we don't have prototype-style programming in Ruby. So, we can define the Invigen method on every string and move it back into the Ruby runtime, and we've got the Invigen method in Ruby. And this works the same way in the other direction although we won't have a theory if you pull out a JavaScript constructor for our class or what we call it, and you mess with its prototype in Ruby and you treat it as a hash and assign a lambda to it. Then that lambda is available as an instance method for any of the other things in the same from that object in JavaScript. So, I think you should talk about some difficult things. So, as you can see, I'm laying here and doing the line share where I'm taking like two slides out of ten, which is great because I feel crappy. I want to talk about a few things that will be really, really hard and are awesome. Thing number one that's really hard to do this is garbage collection. This is two very, very independent run times with, you know, evolved separately and undercrundless things. We're certainly not, you know, hybrid type of projects or anything else like that. So, we have a GC in JavaScript and we have GC in Ruby. We have a disabled eye that we spent a whole bunch of time trying to keep them orchestrated, which was super fun because they don't use the same and they don't use anything else like that. So, this is one of my biggest stability difficulties that we're still dealing with here. So, garbage collection is huge and it was extremely difficult. It was probably the biggest problem in the whole thing. Yeah, I mean, if you think about a JavaScript project moving into the Ruby runtime, and you have a Ruby proxy to a JavaScript object, both of those things need to deal with Ruby's garbage collector and Spiderman's garbage collector. That's the kind of stuff where you create something in JavaScript, take it across the wire over to Ruby, assign it as a property in the Ruby object, and as it's going back in, it uses a proxy in JavaScript. It gets very messy. So, that's one of the hardest places when we're still working very hard. You have one of these thread models. Spiderman specifically uses green threads. We don't know how well Ruby would be in place with those. Ruby's very similar. Spiderman uses native threads and Ruby uses green threads. So, you can imagine the problems that occur if you do thread again in the JavaScript runtime while you're inside green threads in the Ruby runtime. It is mad news bears. Yeah, and this, even with the global interpreter block, is one of our biggest barriers to taking this out of Ruby 1.8. So, I know you all are saying that you're not convinced. You're saying that Jaws on Santa's way. Well, let me tell you. You're wrong. Case in point. Everybody recognizes this, right? Fibonacci sequence written in Ruby. Fibonacci sequence written in JavaScript in Ruby. Here's an object called tellA and it has two methods on it. One of them is the Fibonacci sequence written in Ruby. The other one is the Fibonacci sequence implemented in JavaScript. The client of this class can't tell which implementation is done in Ruby and which one is done in JavaScript. As you can see, if we test this, both functions return the same values. Which one is faster? You know, I'll be very surprised. I'll let you be the judge. Well, I'm happy with Jaws. You'd be amazed at places where if you were crazy enough to do significant spot opposition Ruby might embed in JavaScript interpreter. That sounds crazy. Almost as true. Would you like to continue? I will continue. High-five. High-five. We had a couple of little things just as far as JavaScript might be concerned. We had very little as far as anything else like that accessible from the global object by default. We do have a few little convenience things when you're running these two lines together. We provide Johnson.quire. What this does is it searches Ruby's load path, just like Ruby's require does, but it supports both rbn.js files. So from inside your JavaScript, you can do the Johnson.quire. You can, I don't know why you want to do this, but if your JavaScript is a gem, you can very easily do it and get to it this way. We also provide full, on-demand access to everything in the Ruby object graph. There's a Ruby.constant in JavaScript and you can get to anything in Ruby to that. You can see the Ruby.hash just like we have there. You can call up any of the kernel methods on it. You can get down into any of your classes. We translate Ruby.constants into JavaScript properties so we don't have to resolve. Anything in Ruby is available in Ruby. In that same configuration, in vain, JavaScript doesn't have any concept that easily equates to symbols. So we provide a few little extras to help you with that. There's a symbolized method on Johnson that will turn any string into something that runtime will recognize as a symbol when it crosses the language boundary. There's also a mix around string to symbolize anything. We originally did this. We actually just had it look anytime strings were coming across the language boundary. If it started with a colon, we turned it into a symbol. Which looked really cool, but it really didn't turn out very well in the long run. So it's more explicit now. And then we have one little extra that can be very useful when you're doing this sort of server-side JavaScript which is to give you under every file just like Ruby does. That's about the extent of the language integration we give you. It's a bunch of really tiny things but they add up to pretty much everything that we think you need to write support letters and Ruby and have them look like any amount of JavaScript. Write JavaScript in your rails or send off for half or way down. Send off for our waves. Raise your hands. Thank you. How many of you test that JavaScript? I don't know. Really? Do you execute that JavaScript? In browsers, you don't have a command line test. Interesting. What if I told you you could execute your tests in Ruby? Unpaid for this tool. How much would you pay for this? I released a new demo last night called Taka. What it is is a document object model implementation in Ruby. What this lets us do is this lets us take HTML that looks like this accessing the document object model and because of our transparent proxy between Ruby and JavaScript we can actually execute this execute this JavaScript and have it affect the DOM. You don't need to understand what this code does because we've got a slide right here that shows it. All it does is it populates a select list in a form dropped down with a bunch of options. This is showing what the DOM tree looks like after the JavaScript is executed. Before execution there are no often tags inside that select tag after execution there are. Taka, what I was able to do is create a new Johnson runtime, parse the HTML set the document inside the Johnson runtime evaluate everything inside of the strict tags and then execute the onload function inside of the body tag. This actually modified the DOM in Ruby and we ended up with an HTML tree that looks like this. We're actually able to assert that that JavaScript made its manipulations to the DOM tree. This is obviously a long way from giving you all the stuff that the browser does set time out or execute requests which are actually the two biggest most complicated things you want to implement in a browser with a column. But we feel like all the tools are there to do that and what we'd really like to do is get the same sort of insanely rapid response time with our JavaScript tests through auto tests or whatever else that we can or anything else. With this I can get sub-second response times instead of giving you more than that. So yes, pop has released too many music it is extremely helpless software. Oh, okay. Anyway, we are also unhelpful. I want to go over a few things that you probably don't need but I just think are neat. Stupid Ruby JavaScript tricks. Yes, stupid tricks you can do with JavaScript with Ruby. You can get database access. So, for example, in this I'm inside of a Rails project I run the Johnson shell I can actually evaluate my Rails environment and then require a user model for example. I can switch over into my JavaScript runtime and using symbolize there's an iterate over those all purely by JavaScript. So, we have given JavaScript database access. That slide is strange. Imagine a world where the code was lined up properly. So, with Johnson we are able to write our views in JavaScript. So, notice that this view is actually written in JavaScript inside of the ER E, JS, CAD So, we have no idea why you would want to do this. Yeah, you would want to do this because awesome, that's why you want to do this. Actually, the reason you would want to do this is to get locked into using Johnson so that you can submit patches to it. Actually, when we had this together we really didn't have a point. So, it was really highly dynamic. I used a lot of little independent partials and we really didn't want to in a lot of cases have to duplicate, bring the updates on both the server and the client. So, we actually ended up experimenting with writing a bunch of smaller partials in JavaScript so that we could render them on an initial page load and then send them across the wire to the browser so that we could re-render things in JavaScript on the browser. And not have to worry about doing complex DOM updates or anything else like that. We just bind new data into it and render them, which we didn't take it far enough to do any significant live stuff with it, but it actually turned out to clean up a lot of stuff as RSS has. Next up, break points. We can set break points in our top sprint with Johnson. The other thing that was great was Patrick Swayze. He was also awesome and great. Oh, you're great. Yeah, that's a good point. Patrick Swayze was actually a lot better than he was. Yeah, I mean it wasn't even a good mouse or anything. No. Exactly, he was awesome. Great question. Go on. So, back to Johnson. We can compile our JavaScript, give the JavaScript a name, and then we can actually set break points inside that JavaScript. And this example shows setting a break point on line 3 of this function which is where x gets incremented by 2. Then what happens is every time that line hits, the Ruby block is executed. So we can muck with the runtime inside that block too, so we can examine the values y and the values of the x at that particular point. So this is nothing that you can't do with something like fire button, but if you're starting to run browserless tests for your JavaScript property, which we do now for certain pieces of JavaScript that don't have a huge dom dependency, it's really nice to be able to actually set the break points in your tests when you're working on a JavaScript instead of having to actually learn the whole stack. So the output from this would look like this. We're actually looking at the i value and the x value inside the JavaScript runtime. Another neat thing is hotruby.js. I don't know if any of you guys have heard of this, but it is a Ruby 1.9 bytecode interpreter written in JavaScript. So, for example, these Ruby codes will we can run those through Ruby 1.9 and pull the bytecode out for those and we get this yaki-looking bytecode. But in Johnson, we can require how Ruby instantiate a new hot Ruby instance to activate that Ruby 1.9 bytecode. And this gives us the unique ability to be able to execute Ruby on JavaScript, on Ruby, on Rails. Okay, so we are just about out of time. We pushed out 1.1 to Ruby Forge. It's the first release on Ruby Forge. It's the only thing really seen a lot of use on 1.8.6, on macOS 10 and a bit on a couple other instances on Intel. Stability is something we're continuing to work on because GC is really hard, so you should break stuff and it almost makes it better. Did we mention that Johnson is hard? I think we got that. That was real subtle. So, good job. Definitely want to thank a few folks that have worked with us on a few different parts of that, especially for genreizing, because of our jobs for support. And I definitely want to thank Aaron for helping me because I'm really sick, so thank you very much. So, please check it out. Help us out. We think that there's huge advantages to being able to do this sort of integration. As much as the release stuff that we can do with it, there's some really, really tremendous productivity that we can do. So, we really enjoyed it. Thank you. Take a question. Question. We have three minutes. Yes. Well, the answer is kind of. It doesn't really be a job of interpreting the 1.9 byte code. We actually have Ruby 1.9 parson that ended the byte code for you. We can't just take Ruby source files and do them in the browser. It's also implemented about that much of the standard libraries. So, you're not going to get any standard libraries. You're not going to get any standards or anything like that. You just get the basic flow. It's just enough to say stupid things like Ruby on JavaScript and Ruby on Rails. And that's about all that's useful for right now. Yes. I have two questions. First one is, have you guys ever played Ruby on Rails? Have we done anything with Steve Yeti's rewrite of Rails in JavaScript? No. No, you're talking about running on Rails, right? Yeah, I haven't even looked at this code. I'm sorry. How much of it is making use of Rhino's JDM and Java runtime integration? So they're probably pretty significant in that point. We're actually pretty significantly going beyond feature parity as far as language integration is concerned with Rhino. So that shouldn't be a big deal. As far as multiple languages, JavaScript is the only one we're really interested in just because it had such an impact on what we're doing every day. One thing we would like to do is let you run simultaneous JavaScript runtimes. So we've been looking at embed V8 and potentially trace monkeying as well which I think would be really nice. We've also looked at a bit at squirrelfish or whatever they're coming in now. The basic architecture lets you have a bunch of different kinds and implementations but we haven't really looked at seriously embedding anything that Spiderman can get. So I'm considering integrating this somehow with QComper. I'm considering integrating this with QComper and it would be nice to be able to test any JAX calls. And the answer is no. I released talk the last night and it's very, very, very helpful. So we do want to do that. We originally wanted this so that we could write better integration tests so more or less at the same time. That's really beyond the fun of coding or whatever we want out of this in the long run. That is the future but we haven't done yet. All right. I think we're up. One more. See Spiderman can embed it with inside Ruby. The slides about the proxies are very similar to what we actually do. We have two proxies written in C. One that proxies inside of the Ruby runtime and one that proxies inside of the JAX so we intercept coding calls within either one of those run times and send them over to the other. And as far as the build-in, Spiderman stacked the compiler into the extension and the extension is a few thousand lines of C. So if you want to know more about it, you can hit us afterwards and we'll be around the day over so we're going to stop. All right. Thank you.