We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

6 Reasons Jubilee Could be a Rubyist's New Best Friend

00:00

Formal Metadata

Title
6 Reasons Jubilee Could be a Rubyist's New Best Friend
Title of Series
Number of Parts
65
Author
License
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language
Producer

Content Metadata

Subject Area
Genre
Abstract
Do you do web development in Ruby? Have you been forced to go to node or other technologies just for concurrency/websockets etc. Do miss your gems, and tire of functionality you have to implement from scratch? Do you hate javascript? Well no need to switch languages/platforms, Jubilee could be your new best friend. Jubilee, a rack server on top of Vert.x gives you Concurrency Speed Easy Websockets support Shared Memory Access to the JVM ecosystem Ability to reuse your existing Ruby knowledge and gems "Say Hello to your new friend" - Al Pacino
39
Slide ruleDirected setAreaProjective planeSlide ruleMultiplication signPower (physics)Traffic reportingPresentation of a group
WordGame controllerComputer animationMeeting/Interview
Moving averageArithmetic meanVideo gameRight angleComputer programmingArithmetic progressionProgrammer (hardware)Computer animation
Repeating decimalFormal languageSingle-precision floating-point formatCone penetration testSoftware developerPresentation of a groupFormal languageMultiplication signConfiguration spaceJava appletCodecNoise (electronics)Right angleLengthPasswordComa BerenicesComputer programmingProcess (computing)Line (geometry)
Software frameworkProgrammer (hardware)Right angleProcess (computing)Software frameworkMusical ensembleTheoryAxiom of choiceSoftwareAuthorizationDialectMaxima and minimaCellular automatonComputer animation
Codierung <Programmierung>CodeRight angleQuicksortMassRule of inferenceProcess (computing)Goodness of fitProduct (business)Computer animation
Image processingVideoconferencingScaling (geometry)Library (computing)Function (mathematics)Disk read-and-write headRight angleScaling (geometry)Image processingFitness functionVideoconferencingGoodness of fitFunctional (mathematics)Medical imagingNeuroinformatikMereologyComputer programmingComputer animationLecture/Conference
Concurrency (computer science)Vertex (graph theory)BefehlsprozessorDatabase transactionServer (computing)Exterior algebraConcurrency (computer science)Point (geometry)Database transactionServer (computing)BefehlsprozessorWeb applicationMobile appOnline chat
Scaling (geometry)DisintegrationSystem programmingFormal languageEntire functionSingle-precision floating-point formatGoodness of fitINTEGRALPoint (geometry)BefehlsprozessorPhysical systemProcess (computing)Descriptive statisticsFormal languageRight angleComputer animationLecture/Conference
AnalogyCartesian coordinate systemWebsiteVertex (graph theory)Computer animationLecture/ConferenceMeeting/Interview
PredictabilityMIDIConcurrency (computer science)ScalabilityBitEvent horizonGoodness of fitMereologyPhysical systemConnected spaceScaling (geometry)Formal languageConnectivity (graph theory)
Key (cryptography)SynchronizationServer (computing)Execution unitVirtual machineComputer wormSocket-SchnittstelleEquivalence relationModulare ProgrammierungMereologyServer (computing)Software repositoryPhysical systemConcurrency (computer science)Vertex (graph theory)Pattern languageRainforestEvent horizonEndliche Modelltheorie
Pattern languageConcurrency (computer science)BefehlsprozessorThread (computing)MereologyOperations researchPhysical systemJava appletBeta functionAlgebraic closureFormal languageComputing platformScripting languageEnterprise architectureWeb pagePattern languagePhysical systemNumberBlock (periodic table)Natural numberFront and back endsWeb applicationServer (computing)Java appletBus (computing)BefehlsprozessorFormal languageQuicksortEvent horizonVertex (graph theory)High availabilityComputing platformExecution unitThread (computing)Slide ruleBuildingVariable (mathematics)Default (computer science)TelecommunicationBeta functionScripting languageAlgebraic closureSequenceLecture/Conference
Sanitary sewerClient (computing)Core dumpTape driveEvent horizonTelecommunicationPhysical systemWebsiteOpen sourceClient (computing)Bus (computing)Server (computing)File systemWeb 2.0Formal grammarProgrammer (hardware)BuildingComputer programmingMultiplication signGroup actionInternetworkingComputer animation
Type theoryBefehlsprozessorProcess (computing)Physical systemTelecommunicationDirected setScaling (geometry)Web browserMultiplication signTerm (mathematics)Process (computing)Connectivity (graph theory)Message passingBitCovering spaceTelecommunicationWebsitePhysical lawDemo (music)Computer fileQuicksortGoodness of fitEvent horizonBus (computing)High availabilityServer (computing)Physical systemSimilarity (geometry)Interior (topology)Direction (geometry)Proxy serverCASE <Informatik>VideoconferencingGene clusterVertex (graph theory)Point (geometry)Java appletHash functionComputer animation
Extension (kinesiology)Multiplication signCausalityComputer animation
Vertex (graph theory)Software frameworkRankingScaling (geometry)Pattern languageConcurrency (computer science)BefehlsprozessorData modelMoment (mathematics)Thread (computing)Scaling (geometry)Concurrency (computer science)Row (database)Reading (process)Process (computing)Web applicationFrame problemPower (physics)ResultantInteractive televisionPairwise comparisonBenchmarkWeb pageSoftware frameworkServer (computing)Arithmetic meanModule (mathematics)Lie groupWeb 2.0WritingEndliche ModelltheorieVertex (graph theory)Product (business)Computer fontPattern languageBefehlsprozessorComputer animationLecture/Conference
BenchmarkConvex hullMobile appPairwise comparisonQuicksortBenchmarkComputer fileXML
Maxima and minimaBenchmarkWhiteboardServer (computing)BenchmarkMereologyNumberCuboidWhiteboardLimit (category theory)2 (number)WaveTraffic reportingWeb 2.0
Server (computing)Modul <Datentyp>Thermal expansionSystem callEvent horizonBus (computing)Scaling (geometry)Network socketWeb browserExistenceComputer programmingServer (computing)Theory of relativityBenchmarkNumberDialectCuboidEvent horizonDirection (geometry)Formal languagePhysical systemLibrary (computing)System callCore dumpVertex (graph theory)Web browserVapor barrierMobile appQuicksortEndliche ModelltheorieModule (mathematics)Bus (computing)CodeBuildingSocket-SchnittstelleDiagramWeb 2.0Moment (mathematics)FamilyHigh availabilityFront and back endsCASE <Informatik>TelecommunicationComputer programmingMedical imagingProxy server
Slide ruleMobile appComputer configurationMessage passingEvent horizonBlogDifferent (Kate Ryan album)Configuration spaceComputer fileVertex (graph theory)Variable (mathematics)FreewareComputing platformIntegrated development environmentBus (computing)WaveLine (geometry)Right angleDemo (music)Interactive televisionProduct (business)Wave packetPeer-to-peerComputer animation
Vertex (graph theory)Group actionExponential functionMaizeRight angleGoodness of fitSampling (statistics)Data storage deviceProcess (computing)MassEquivalence relationReliefCharacteristic polynomialPasswordBitSound effectConnected spaceGame theoryTwitterMobile appSlide ruleWritingComputer animation
PhysicsTwitterGame theoryBitLoginWeb pageMereologySign (mathematics)WordElectronic visual display
Menu (computing)Correlation and dependenceLemma (mathematics)Electronic visual displayLie groupOrder (biology)WindowGraphical user interfaceGoodness of fitComputer animationProgram flowchart
Computer wormMenu (computing)Gamma functionWindowBookmark (World Wide Web)Denial-of-service attackTerm (mathematics)Goodness of fitTwitterLoginGame theoryReal-time operating systemMathematicsMultiplication signArithmetic meanComputer animationXML
WindowRoundness (object)Multiplication signCausality
Chemical equationMoving averageInfinite conjugacy class propertyLemma (mathematics)Game theoryMobile appRoundness (object)Core dumpAsynchronous Transfer ModeXML
File formatView (database)Duality (mathematics)Process (computing)Right angleNormed vector spaceMobile appAsynchronous Transfer ModeMusical ensembleProcess (computing)Partial derivativeRight angleView (database)LoginDiagramVertex (graph theory)RobotRoboticsMultiplication signGame theoryEvent horizonDatabaseTouchscreenMobile appRow (database)Web pageConcurrency (computer science)Bus (computing)Streaming mediaProxy serverWebsiteTelecommunicationHuman migrationTwitterSign (mathematics)2 (number)AuthenticationVideo gameProgram flowchart
Web pageSign (mathematics)TwitterCurvatureGame theoryState of matterWeb pageTwitterAuthenticationException handlingStreaming mediaState of matterGame theoryMultiplication signMathematicsComputer animationXML
System callVertex (graph theory)Web pageRight angleFront and back endsMultiplication signServer (computing)Bus (computing)Dependent and independent variablesDebuggerMultilaterationEvent horizonCASE <Informatik>Connected spaceProxy serverGame theoryXMLUMLProgram flowchart
Game theoryRobotEvent horizonClient (computing)ArchitectureWeb browserGame theoryBus (computing)Event horizonRobotServer (computing)CodeTape driveHuman migrationNumberWeb 2.0Library (computing)Process (computing)Client (computing)WebsitePhysical systemTwitterGreatest elementProxy serverConcurrency (computer science)Computer animation
Tape driveClient (computing)Mobile appStatisticsCodeSanitary sewerEvent horizonExecution unitRobotGame theoryHydraulic jumpConvex hullHash functionLevel (video gaming)Server (computing)Vertex (graph theory)Task (computing)MultiplicationSystem programmingLie groupWeb browserCASE <Informatik>RobotGraphical user interfaceCodeClient (computing)Error messageMereology2 (number)Bus (computing)Multiplication signYouTubePoint (geometry)Multi-agent systemSingle-precision floating-point formatGame theoryPattern languageState of matterHash functionLine (geometry)Connected spaceTouchscreenFront and back endsSoftware testingBit rateWritingLatent heatEvent horizonGroup actionStatement (computer science)Game controllerServer (computing)Domain nameConfiguration spaceInheritance (object-oriented programming)Message passingReal numberVertex (graph theory)Physical systemMobile appQuicksortTape driveString (computer science)Functional (mathematics)Social classSet (mathematics)Link (knot theory)Entire functionLoginWeb browserLetterpress printingGoodness of fitStack (abstract data type)ConsistencyIntrusion detection systemPRINCE2Proxy serverRevision controlWebsiteSystem callMusical ensembleControl flowFlow separationSynchronizationScripting languageProcess (computing)GenderGoogolSoftware bugFigurate numberRight angleVideoconferencingGodHypermediaFamilyLie groupSpacetime
Scale (map)RoutingRight angleProcess (computing)Core dumpAxiom of choiceMultiplication signCellular automatonComputer animation
SoftwareEvent horizonVideoconferencingRight angleComputer animation
Transcript: English(auto-generated)
All right, I want to start with apologies.
I've been having a lot of slide envy and presentation envy. So I've used a time-honored method of getting someone with a British accent to make my talk sound more sophisticated in certain parts. It also works good for imagining what the ancient Romans might have sounded like, because apparently that's what you do in movies. But there you go.
So I did see in some talks here, I realized after seeing like, Dave Miller's talk here, what people are concerned about. So I have two alternate subtitles for my talk. We own rails while still using rails.
Or, rails can't be all the stuff I want anymore, and killing the tech makes me want to cry. There you go. So apparently to this question is a question. So why become bigger when you can't?
Now arguably, the answer for that is that you like Ruby. So that brings another question. Why do you like Ruby? Arguably again, because it makes you happy. So. For me, the purpose of life is partly to have joy.
Programmers often feel joy when they can concentrate on the creative side of programming. So Ruby is designed to make programmers happy. Yes. Ruby is designed to make programmers happy. So therefore you could say, happiness is the Ruby way, right? So the objective then of this talk is to ensure that you, the Rubyist, stays happy.
There's always memes or two that go on at RubyConf. So happiness is a recurring theme, but actually is the same theme I realize in all my presentations where I seem to pick technology based on what makes me happy. I call it JDD, joy-driven development. Basically it's about coding and loving it.
So if we talk about what do we like about Ruby? The language itself, it's pretty wonderful. I think most of you guys know that, right? An entire talk can be done on that one, so I really won't do one. But I will point you to an example I came across. So I was doing some device config editing recently, and I came across this one line, config.passwordlength is, you know, eight to 128.
And so what I really like about this in Ruby in general is that the intent, the intent is just so clear, right? There's nothing extraneous there, just the essence of what you want, right? A typical Java or JavaScript way might be something like new time or age eight, paren eight comma 128 close paren, right? Just less noise, it's beautiful.
All right, there's in theory, there's sound here. Okay, you missed that one, that was music. Oh, I can play back. Okay, so Ruby makes me happy, right? The other thing you might like about Ruby
is all the gems and frameworks, right? There's lots of gems, almost anything you could pick from. Even among those gems, there's choice. Sometimes there's more than one gem for the job, one is maybe more suited to you than the others. Gem authors tend to emulate Macs and that they wanna make software that makes you happy too. There's lots of really elegant DSLs, right?
And so if we're gonna talk about Ruby gems, the 800 pound gorilla of Ruby gems is really Ruby on Rails, right? So for Rails, show of hands, who codes in Rails? Pretty high percentage there. Who came to Ruby from Rails? About a third, I'm actually surprised.
So then the other question is, of course, who is coding Ruby before Rails? That does not add up to 100, I gotta say, 100%. And so who loves Rails? I do love Rails. I mean, there's reasons to not love Rails, but there's reasons to love Rails. And lastly, who has a job because of Rails? All right, it's clearly the majority, right?
So Rails has been good to us, why do we love Rails? Whole talk can be done on this, I won't do one. But in a nutshell, productivity, right? We're all very productive in Rails and, you know, Max talks about Omokase and his tailored to him, make me happy sort of thing. And it tends to make most of us happy
when it does what we want. So it's a good thing, right? So Rails can make you pretty happy. The problem now is Ruby's not a panacea, right? It's not a solve, it doesn't solve everything for you, nor should it. Some reasons you might not use Ruby are just pure speed.
So you're doing image processing, video encoding, stuff that does not a good fit for Ruby, right? Scaling, Ruby doesn't scale so well. Things that are resource heavy, computation heavy, not the best fit for Ruby for the most part. Sometimes the functionality you want is not in Ruby. So if you wanna do, say, scientific programming,
Python support is better. Be kind of silly to rewrite that unless you really have to. So these are all legit reasons not to use Ruby. The problem we get is some of these non-Ruby things are less happy making, right? And we already established that being happy is important here. So common alternative is, of course, Node, right?
Node, okay, it's not true, it's not good for anything. It is actually good for some things. Quick, non-blocking IO, concurrency, these are typically the things you talk about. So very often you use the chat app
to demonstrate the sweet spots of Node. What's in a chat app? It's high concurrency, lots of people talking. Quick, very low CPU transactions, that's chat. The server push thing that's so popular. It's what they call the modern web app. That being said, so Node is not good at everything. What's it not good at? Vertical scaling, they're trying to work on this, but it's single threaded,
they're trying to fork all kinds of stuff. Not particularly good at this. Once you do CPU intensive or slow running things, you lose the entire benefit of Node. So if you start blocking on these things then no point in using Node unless you like JavaScript. Integration with other systems, not particularly good, not necessarily worse than anything else, but not really designed for that.
Language, right? We're at RubyConf, so the Ruby bias is JavaScript's no good. So too much JavaScript and sad panda is sad. So the question is how do we bring back that love? One way is Vertex, right?
So who's heard of Vertex? About five people. Oversimplified, Vertex you could call Node for the JVM, that's not a great analogy, but it communicates a lot there. You might think more like Node plus plus and much more. So let's go to their website. They do mention in their little blurb
designed for modern applications, I'm just gonna highlight some things. It's polyglot, it supports a bunch of languages, but at RubyConf we really care about Ruby by way of JRuby, and I have to call this out because people have asked me during lunch. So do you have to use JRuby with that? Because yes, you do. Simple, not simplistic.
It's got a good API, it does good stuff. Scalability is, and we'll talk a little bit more about this, thought from from the beginning as well as concurrency. Some key features we're talking about are the event plus. So you can see what they wrote here. The nervous system, a Vertex, and connects your system side components. This is part of the connect everything together.
WebSockets, sockets.io, server push, this is a big thing. They thought about it. Their module system is basically the Vertex equivalent of gems, right? And so you can register these things. And a very interesting thing about the Vertex module system is you don't have to install it. You know how we do bundle, install, install, deploy. You can actually deploy a vertical,
give it a fully qualified path name. It'll go to the repo and actually, I guess, temporarily download it, run for it. So you don't actually have to pre, it's an interesting thing there. So, like Node, handles the concurrency, same reactor pattern that it and a ton of event-based systems use,
good with the non-blocking IO, it's fast. In a number of ways, it's better than Node. Node is not good for CPU intensive. We're on the JVM, you know, highly optimized for these things. And of course, of the Ruby's, JRuby is the fastest. You know, it's a JVM. So JVM's, if you need to do threads, it knows how to do threads, right? Blocking IO, slow running things.
So Node is not good for this. Vertex has the concept of a worker vertical. The vertical is sort of the unit of work in Vertex. And so by default, those verticals are set up for asynchronous, but they have the concept of worker verticals that use thread pools and intend for you to just sit there and do long things. And then again, communicate via the event bus.
Scaling, so they thought about it. Horizontally, you can cluster, they have high availability vertical. You easily run a vertical per CPU and Java stuff. So that's covered. Polyglot, so they have official idiomatic APIs for these languages, Java, JavaScript, Ruby, CoffeeScript, Ruby,
of course, by way of JRuby and Python. And of course, at this conference, the one we really care about is Ruby. In beta, they have close your skull. Those make sense. PHP, that's like, okay. If you wanna do that and run PHP on the JVM. So ultimately, any JVM language will work
or something that compiles the JVM. So any, those other things that compile the JavaScript, you could figure out a way to run here. There you go. It is actually a general applications platform. So while the modern web app with the server push and asynchronous is supported, it's got a lot of traditional backend support, again, by nature of the JVM.
And it's also designed to build systems of systems. So I got a bunch of slides that I repeat a lot, availability, clustering, subsystem communication, the event bus shared data. Core APIs that it has, TCP, SSL clients and servers, HTTP, web socket, SOCKS.js, file system APIs, event bus, which is a communication DNS, UDP,
pretty much, you can pretty much build everything you want. And you have like the foresight of being able to connect them together. So I'm gonna take a side segue into duct tape. So this picture is like called duct tape moving van. You can pretty much duct tape anything together, right?
Open source system typically are duct taped together. I think a lot of us know, oh, I got this and I put it together. We as open source programmers often figure out how to duct tape these together. Perl, once upon a time, was the duct tape of the internet. Ruby's a better Perl, so I guess it picked up some of that slack. You know, gems kind of formalize
that duct taping sometimes. You know, Node being relatively less mature, I think you do a lot more duct taping there. I know certainly in building apps, you end up rewriting stuff that you've long had gems for. On the contrary, Vertex is designed for integrated systems. Again, so we have the vertical for asynchronous
and we have the worker vertical non-asynchronous. So we kind of cover both cases there. Inner process communication. The big one here is the event bus. This sort of allows you to, it supports the publish, supports direct messaging, it supports direct reply to a direct message,
and it extends in the browser. So typically you think of the event bus sitting behind your server side components. You can actually have the browsers sit in the same bus. That's actually a very useful thing. Shared data, they have that one. They support the hash and the set. You know, a lot of times you use Redis or something like that to basically do a similar kind of thing. They've, you know, thought about scaling.
So clustering, the way you run a vertical with clustering is Vertex, name of the file. And again, I give an example as a Ruby file, it could be a Java file, Scala file, whatever, dash dash cluster. I'll talk a little bit more of this a little later. High availability again, how do you invoke that dash HA? So there's lots more, right?
There could be a whole talk be done on Vertex. There has been, I won't. But I'll point you to two good overview videos. So this first one is Tim Fox, introducing Vertex 2.0. Tim Fox is the guy who wrote Vertex. And so this is a really good talk about overview of all the various features it does.
He's got tons and tons of live demos where he's just kicking off processes. He shows high availability, he shows clustering. It's a really good worthwhile look. Vertex, this ain't your dad's node. This one's good at showing how Vertex is better than node in a lot of ways.
So Vertex is pretty awesome. But with every new tech, there's always more to learn. So sad panda thing comes guy cause we always have so much time to learn everything. Right, so question is, what if I could keep coding Ruby and extend it as I needed in Ruby? And the answer to that is,
what if I told you you could? He's my dramatic moment guy. Jubilee. There you go. So the original, actually, I probably shouldn't let you go. You should probably read this one too.
Hope you can read the tiny font. We need a web framework for Vertex, you said. But why not use Vertex in your Rails application? It's the most productive web framework ever created. Thank you. So this used to be this logo on the original readme page.
He's since taken it down, but it's something that spoke to me. It's like, why reinvent the wheel? We got this great framework. And of course, we need to write web apps. Well, there's one that works well. What if you could put them together? So Jubilee originally started as a Rack server with Vertex built in, but he's since converted to a Vertex module that runs Rack. So to us, it doesn't mean that much
cause it seems like it's essentially the same thing, but ultimately it's for improved performance in the interaction with the rest of the Vertex ecosystem. But the summary is you get all the power of Vertex and you can keep doing the Rails stuff that you're doing. So can't do that with Node. So this brings us to, of course, the title of the talk.
So the six reasons Vertex could be your new best friend as a Rubyist. Concurrency, speed, expanded ecosystem, built-in upgrade to scaling path, easy WebSocket support. And I think this is the biggest one. Reuse all this knowledge that you have. All right, so on concurrency, same reactor pattern as Node. So you use it for things like that one.
Each vertical itself is single threaded. They have a interesting, simple concurrency model. So there's no threading and some things that, again, I don't want to talk too much about, just realize that the threading model is very simple for them. And again, you can do your vertical scaling, run a vertical per CPU and other things like that. Speed wise, JVM, you know, always gets faster. We always leverage on that one.
You can use CPUs and threads as needed. And I'm gonna talk about benchmarks. So there's lies, damn lies, and benchmarks. That being said, here's a Vertex versus Node benchmark from 2012. We can see this is kind of basically a hello world app. So you can see Ruby sits here, relatively slow among Vertex, but then you compare where Node is by comparison.
And then here's Node with six processes. So, and I believe Vertex is running off of single because that sort of is at the top. So here's a static file serving again. Ruby is here. The slowest of the Vertex, but the best Node can do is here. So if we're to believe these benchmarks, it's faster than Node.
On the nation of Ruby servers in general, Jubilee is the second fastest Ruby server. Have you guys seen this benchmark? The Ruby web benchmark report came out a few months ago. It's a different one because instead of doing average stuff, he decided what's the fastest we could possibly do. It's not the benchmark you do, but it gives you like, what's the upper limit?
General conclusions, JRuby leads these across the board and I can wave to Charlie and Tom back there. Thank these guys for that. And the fastest is almost as fast as Go. That's kind of like, surprise the guy who did the benchmark. Surprise pretty much everyone who reads it.
So when we look at these server benchmarks here, so you can see TorqueBox is number one, 10,159 requests per second, TechTorqueBox four, that is coming up and Jubilee is number two at 9,500. And so for your relative benchmark, Go is 10,500. So you can see TorqueBox is almost as fast as Go
and Jubilee is definitely in the ballpark. So fast. Expand ecosystem. Being able to run Rack, you get your Ruby gems. Caveat have to be able to run into JRuby. You get access to the Vertex modules. Again, their idea of Ruby gems, right? At the moment of writing 200 there, obviously they're adding it.
And then you also, by way of JRuby, you get access to the rest of the JVM ecosystem, languages, libraries. You can call other JVM languages directly from JRuby if you want or you can write verticals in those languages and then it all hooks into Vertex. A built-in upgrading ceiling path. So as I keep talking, it was really designed
for system of systems, verticals. You know, async verticals, worker verticals for when you need non-async stuff. Intercommunication between all these things. You know, you have core APIs. If you can do the raw stuff, maybe you need direct web sockets. That's not a Vertex thing. You can support that one. Of course, the event bus is the big glue. Shared data is there when you wanna do stuff like that.
They support clustering, high availability. So again, Vertex is designed to build systems of systems. This is popular because of server push, soccer IO, socks.js is there. But again, I think in most cases, unless you have to talk to someone outside of Vertex, you'd use the event bus. Why? Because it's easy and I'll show you some code for that.
I realize I should warm up my app. Scott, could you? Okay, if you're on it. So it's super easy and more importantly, extends in the browser. So you can imagine, I'll have a diagram of stuff where you have all these server guys talking to the backend, but you can also push that in the browser and back. And that's, again, such a great simple model.
And so the most important thing is the ability to reuse your existing knowledge. I think that's what hurts. Oh, I've written this Rails app. Oh, I need concurrency. Oh God, I have to learn node. And I gotta remake it okay for me to look at JavaScript and stay healthy sort of things and all these things that just sort of bother you. You know, it's Rack. So you can use Ruby, you can use Rack programming,
which is usually Rails, but it could be Sinatra, Padrino, et cetera. You get your gems. It's, you know, very low barrier of entry to be able to leverage this. So jubilee can make you happy. Let's look at how we use it.
To install it, gem install jubilee. To use it, go into a JRuby compatible Rack app. If you want the jubilee options, and you probably do, just jubilee and you pass those options. If you don't need the options, you can do typical ways with different servers, rails sjubilee, rackup-sjubilee. If you're gonna run it the vertex style way,
vertex run config.ru, the one you have, and then various config options that you might have for it in the config.json. So I think many people love Heroku because it gives you a chance to deploy an app for free. And it's not, no difference here. I wrote a blog post on this one, but the summary is, here's your gem file. So you can see, I said, Ruby, you pick the version,
and what kind of JRuby engine there. The important one, of course, is the jubilee gem there. You don't have to do the platforms JRuby, but sometimes I'll run them under both. So I need that one. And that last gem you have to do to run a Rails app on Heroku. You get a proc file, this is where I call jubilee. I set the name of the event bus and typical stuff that you do in your proc file.
And if you need to set any JRuby or JVM options, you just do a Heroku environment variable and pass those through. And that's pretty much it. You do a git push Heroku and your app's running. So to get the message across, everyone has slides, of course. Most people do demos.
I wanted something with first-hand interaction, right? You can sit there and I can hand wave all this stuff, but if you can actually work with it, that's tough to beat. So I'm looking basically for an experience. Okay, so now it's sweet spot. Again, it's the chat, the sample app that everyone writes. This is kind of the equivalent of the pet store app
for J2EE where everyone wrote that app to prove that they know how to use it, right? Chat app's not exciting. How do I make something a little more interesting? So my thought was, I would do a game with chat characteristics. So we're looking at, you know, massive multiplayer online something. What could I write? Any ideas?
All right, the answer is rock, paper, scissors, right? And you look at me, yeah, yeah, yeah. No, really. Because I got four kids and demanding job. I'm not gonna write World of Warcraft or anything like that, so. And actually, that's excuse one. My slides are not as good as everyone else's too. So the experience is this one.
I want everyone to sign in. Okay, and so I did ask, know your Twitter password. I realize when I last gave the preview talk of this one, people don't know it. They put it in once and they never remember it. Know your Twitter password, play with each other, have some fun, and then we'll talk about it. So I'm running this on one, the free dyno intentionally
with the idea that actually, since I only have this many people, I think it should support that quite easily. But I haven't tested it past 10 people. So conference Wi-Fi will probably be the issue. And so if you're gonna hit it from your phone, hit the Wi-Fi, there's a little bit of connection issue there. So everyone connect your Wi-Fi. I stupidly put sound effects to make it sound cool,
which of course, like triple the size of my assets. All right, so the name of the game, Rock, Paper, Scissors, Mayhem. And to make it easy for you to figure out the URL, here it is. So it's Rock, Paper, Scissors, Mayhem on Bitly.
Okay, so this is what you do. Go, hit this page. And I am running one worker there. So go to this, do your Twitter thing, sign in with Twitter. If you're running your Android phone, press the little play sound button because HTML5 is weird and not consistent on mobile device
and you kinda need to do that to prime the sounds. And again, this is probably what would be the most challenging of the experiment. Pick opponents and play. And actually I'll step you through the thing for that one. And again, there's other parts of it are very chat-like you should observe. So if you get something that seems not to be working,
refresh the page, should rejoin you into the game. So play it. Now I'm going to try and jump into it and do my display mirroring so I can actually see what I'm doing. All right, where is my thing?
Oh, you guys are already playing it, that's cool. I have no idea where any of my Chrome windows are. Like you can hear them. So you're playing each of them. I'm looking for my window. I swear I had, I have the window
and I don't want to run too. But so I can hear you guys are playing each other and that's good. I kinda want to capture for the stuff. Okay. Be more impressed. Be more impressive with more people out there. And then of course you can't hear the sound.
So here's the game. I'm signing in with Twitter. Someone find me and challenge me when I come up. So you can see I'm getting lied feed down here. Anyone who's actually in combat is in combat and this changes over time. Oh, this is great. This is the most people I've had.
Here, these guys are currently playing. This changes in real time. Oh, someone's challenged me and I just swept away. So Jonathan Chay has challenged me. Round one. Yes, and now everyone can hear the awesome sound. So he picks and you have to pick first cause you can see what I'm picking. Round two, tie. Oh, tie. Round three.
All right, here's the last thing. I gotta wait for you. Then I will play when I see, so. Anytime. We're missing. So I don't know where Jonathan is in the audience, but. Oh, you gotta be picking. You lose. Okay, so I have however many people this is.
Oh, I got challenged again. Round one. Oh, okay. So we're bouncing around. I was hoping to hear this din of sound which I'm not hearing, but that was the idea. So that's the game. You can see people are engaging. They're coming out. I've got this many people. We're running on one dino, but like I said, looking at the sides of the room,
I didn't think there was gonna be a problem. So you can see stuff is going on. I'm kind of obnoxious on the things that are right over here, like turkey down, poor so-and-so. You crush the bot, blah, blah, blah, blah. So that's the app. And as long as I hear cool announcer guy, I know you guys are playing. All right, so that is the...
Actually, let me jump out of mirror mode and we'll pick up. Okay, so we played it, right?
So let's do a breakdown of the app now that we played it. So we started off with the very polyglot concept of Right Tool for the jobs. So I'm using Rails. What do I use it for? Login, I'm using OmniAuth and Devise that supports all that login stuff. I got views, I'm partial to Hamel myself, so I like that one. Easy database access, right?
Active record migrations, who doesn't love that, right? Jubilee vertex, what am I using that for? Event bus, this is the WebSocket supports, the concurrency, the subsystem communication, and I'll have a diagram of that one. Shared data, so I'm using this to make, I don't want a database for everyone because every time I persistently save the rounds in between. Vertex, I have a timer.
So if you challenge someone and someone doesn't answer, it's got like a 10-second timeout and it'll kick you out so you don't get locked in there. Any of you guys who played the robot there, the bot there is a vertical, a separate vertical. And I didn't do this yet, but I was gonna build a leaderboard. I was trying to figure out what can I do that takes time to use a worker vertical,
but I could deploy a worker vertical and asynchronously use that one. So the summary is I use Rails to get to the game and then I use Jubilee to play the game. All right, the divvy up of work. So let's look at screen by screen. So you hit the main page. I got this cool picture Kendra drew for me. You know, that's vanilla Rails. You go to the sign-in.
It's Twitter authentication. OmniAuth makes this so easy. I would hate to have to write it myself. Then we hit the game. And so what makes a chat lag? Well, here's you, here's this live stream. It's typically a chat stream. Here's presence, except that I changed the state of presence and this is where you challenge people. When you challenge someone, you can give up and it will tell you the side you give up. If you don't get an answer in time, it times out.
I use a, sorry, Jubilee, the vertex timer. I use a Jubilee vertex timer to say, hey, have you been accepted in threshold? And if not, I cancel on both sides. So if I put up two pages, you can see on the left, I've challenged the person I give up on the right. I could hit accept.
Again, the players and the server all connected by the event bus. So it's backend and frontend. In this case, I let it time out and then the server tells both time out, I cancel the thing. And you can see one side said he didn't respond. The other side said, you know, you missed something. Again, all event bus connected.
The game itself, you know, this various play. Again, we're connected to server and each other by the event bus. I'm using shared data to make the speed fast. The bot is its own vertical. It plays on the event bus like everyone else. All right, so here's my architecture. So I ran all this in one dyno. I got my rails app. I'm talking over the event bus.
You know, you might set up something like rabbit MQ or rescue or something like this, depending, you know, again, duct taping stuff together. The server, the server I wrote and we'll show you, look at the code. I wrote this event bus handler. Arguably again, for concurrency, you'd run that in another thing, a non-rails process. You know, shared data,
you might use Redis or Tokyo Cabin or something like that to do the same kind of thing, more duct taping. You know, and then web sockets, maybe you outsource it to pusher, you know, any number of libraries to do that one. That's how I talked to the client. Again, that's all event bus for me. Yeah, the bot's another vertical. Again, another thing, asynchronous, another process.
And then of course I'm using timers to enforce the timeout thing so that I don't have to do it. You might use delayed job or something like that. Again, another gem and, you know, migration and et cetera. So ultimately system using Jubilee Flash Vertex, it's designed to work together, right? As opposed to being duct taped together. And we don't want any more duct tape.
So stats, the client code for this is about, you know, 497 lines of code. It's done in Opal. I'm using Ruby on the browser because I like to be happy. This includes white space and comments. The breakdown is the actual game itself is 444 lines. And then I wrapped the event bus code in something that looks like the JRuby thing
so that I could of course be happy and consistent. So that's this one, that's those lines. The server code, the initializer that sets up all the connection stuff is 50 lines of code. Naturally I have like all the server game on the backend but that's not anything vertex specific but obviously I'm playing the game and whatnot.
So other code. So the real stuff, same stuff you always do. So you don't want to see that. And the client game code, it's not super advanced so you don't need to see a lot of that one but I'll probably show some. But the code you really want to see is a jubilee code. It's where I set up the event bus. This is the heart of the app. I deploy another vertical and you can see what's involved in that.
I'm using shared data, again for speed and I have a timer. So here's the setup on the rail side. So this is an initializer. You can see begin, I require vertex. I have a little convenience function. You don't even know so much about it. Down here is your register handlers on the event bus. So I have a channel called log out
and this is a string and you do, typically they'll do like domain qualified things to make you name things here. So I get the ID from the message. I kind of print something out. I have shared data. So I'm storing all the user IDs in this hash, this set because I don't want duplication there.
And so once I get this, I publish this out and this is how other people know people logged in. You get this little publish. Oh, Fred Thompson logged in. Register handle for logins. So when you log into the game, I'm sorry, I jumped ahead. Get the user ID, you get shared data. We saw that one because I'm going to stick me into the thing there. I'm sorry about the highlighting here.
Ultimately at some point I replied back to user. So here's a direct reply that you can do in the same place here. I have less highlights than I think I do. Okay, so last time. So I find the user and I publish this and again, the clients get this one. So next here.
So the bulk of the game is done here. So we have a handler here. I have come up with what I call the command hash pattern. This is how I multiplex stuff over single channels instead of having individual channels. So you can see I have a little command hash and just a case statement here to do. These are the various actions that you do in the game. So again, I just kind of send the things
to the various stuff in the thingy. Down here, this line, this is how I deploy a bot. Deploy vertical, really hard, right? I've got to learn a lot of things to be able to run this one. I deploy the bot there and he's running. We'll look at the bot a couple slides down. On the client side, and again, I'm using Opal, so it's just Ruby, I set up event bus.
So on the client side, we have an on open because you can't use the event bus before it's been opened. And so to keep you out of trying to write stuff that's not open, you have to do an on open event. So when I first open, I will log in and this is how everyone knows I'm there. I will register the handler.
What to do when an user comes because I want to be able to handle. I basically just parse the data comes to me and I draw him on the screen. The game is done through this handler. So the UID, I decided to pick the unique ID as the channel for each person because it's supposed to be unique. And again, the same command hash pattern and this is how we respond to all the various things that are involved in the game.
We do have an activity thing. So activity window, a lot of people can go to that one. That's a publish sort of thing. Player state, that whole in combat, not in combat is that one. And when the user logs out, I want to kind of pull them off of the state so you don't challenge him. So this is the bulk of the bot code.
I left out the actual part where he plays, but it's like I register the bot ID. You know, I have the command hash pattern. You can see that he has no GUI. So half the things are GUI command. So there's a no op thing, you know, down the third wind there. And so that's pretty much, so he just plays like everyone else, except I don't care to draw any GUI stuff there.
And then when you log out some cleanup stuff. So I have the timer code, like if there's an unanswered challenge, I cancel it on all ends there. So when I make the challenge, I set a timer 10,000 milliseconds. It should be 10 seconds to run this method. Down here, I will stuff that ID so that I can cancel it later.
And then when the timer fires off, I grab the timer's thing, I pull the ID, and then if it's there, I cancel it. And then this course, I think, cancel timer, delete challenge. Somewhere I have the code that goes and tells everyone on the event bus, hey, this challenge is over. So that's pretty much the heart of how that works with Jubilee.
There are some considerations when you're doing Jubilee in Rails. The way you have to set up event stuff is in the Rails initializer. You can't do it in controllers because those get instantiated for each request. You need to run it for the entire app. That's what it said there.
Because you run initializers all the time, and Vertex only runs in the server, you kind of have to wrap it so that your rate tests don't suddenly break. Oops, is that all I said? Is that all I put there? I thought I had more. Okay, so there are some drawbacks. First thing, it's, I don't know why this is the case,
but JRuby's still kind of second class. You know, there's gems that don't work, or gems that are supposed to work that don't, or this config is at least three Google searches away before you can figure out what it is. So you have that sometimes. Debugging asynchronous multi-agent systems is still always hard, no matter how little code you have to write.
If you need really fine control of stuff, so I've showed you the Jubilee Rails-friendly way. That's super easy. If you need more detail, you have to switch to the Vertex, a little more complicated way, but again, I was able to do this app in the easy way. And this happens, I think, in promise a lot of things. Your error messages can get swallowed
inside of some of these event bus things there. I had some problem debugging some things, because I didn't know where the error message went. This works for me sometimes. I auto-reload, and sometimes I have to restart the server, and I haven't figured out the pattern yet. And it's always nicer when it does the whole Rails thing and auto-reloads for you. So it works if you're put in the right place.
So one more thing. So of course, by now you know I'm using Opal, and so I basically have an all Ruby stack. And so that big thing the node guys say about, this is awesome, it really is awesome. I just have so much more fun. That's another talk that I will propose about how I write better code when I write Ruby in the browser, for any all kinds of reasons.
I'm so much happier, and I write better code. And if we have time, I'll show you all the code. It's like this big, and it looks good. Whereas JavaScript looks like this. So Opal could be its own talk. I already did one, so I would recommend you go look at this one.
I have a Vimeo link, so I spent a gazillion hours putting Star Wars music, and sounds, and pictures, and videos, and YouTube said, oh my God, copyright music, and it muted the entire Confreaks thing. And so Confreaks went and just blotted out the sound, which I thought was the best part of it. So this is the intro music, and I put a link to YouTube to pick up the rest of the talk.
So watch that if you don't know about Jubilee. You wanna learn about Jubilee? Oh, you're my best friend. So true, so true. All right, thanks. Thanks to Matz for writing Ruby. Thanks to DHH for giving us jobs. Thanks to Charlie and Tom there for their ever non-ceasing work on JRuby.
Tim Fox and his team wrote Vertex. Isaiah Peng wrote Jubilee. Adam, Alia, and Matz are the Opal core people there, and thanks for listening. So my final advice to Ruby-ist is you can stay happy. You can still do most of your stuff in Ruby via Jubilee. You can stay happy, and you can scale.
You can see now there's a lot of capability here, and you can stay in Ruby if that's what you wanna do. Don't worry, be happy. So this is a time where, you know, a lot of people feel we have no choice. We've gotta adopt, node, or die. I'm saying that's not true. Because I'm happy, I'm alone.
If you feel like a room is my own room. You can choose to be happy, and that's what I choose. So I love that one. All right.