00:00:18.800
All right. I want to start with an apology. I've been experiencing a lot of slide envy and presentation envy. So, I’ve used the time-honored method of getting someone with a British accent to make my talk sound more sophisticated in certain parts. It also works well for imagining what the ancient Romans might have sounded like, because apparently, that's what you do in the movies.
00:00:38.079
After seeing some talks here, like Miller's talk, I realized what people are concerned about. So, I have two alternate subtitles for my talk. One is "We Own Rails While Still Using Rails," and the other is "Rails Can't Do All the Stuff I Want Anymore, and Fill in the Tech Makes Me Want to Cry." There you go.
00:00:56.280
So, the prelude to this presentation is a question: Why have you come here for Ruby? Now, arguably, the answer is that you like Ruby. This brings up another question: Why do you like Ruby? Arguably, it's because it makes you happy.
00:01:22.200
For me, the purpose of life is partly to have joy. Programmers often find joy when they can concentrate on the creative side of programming. Ruby is designed to make programmers happy. So, you could say that happiness is the Ruby way. The objective of this talk is to ensure that you, the Rubyist, stay happy.
00:01:47.560
Happiness is a recurring theme at RubyConf, and I've realized that it’s the same theme I use in all my presentations, where I seem to choose technology based on what makes me happy. I call it JDD: Joy-Driven Development. Basically, it's about coding and loving it.
00:02:17.720
Now, let's talk about what we like about Ruby. The language itself is pretty wonderful; I think most of you guys know that. An entire talk can be done on that, but I will point you to an example I came across. Recently, while editing some device configurations, I found a one-line config: "password length is 8-128." What I really like about this in Ruby is that the intent is so clear; there's nothing extraneous, just the essence of what you want.
00:02:43.800
In contrast, a typical Java or JavaScript approach might look something like "new Timer(8, 128)." That's just a lot of noise to wade through. Ruby makes me happy.
00:03:05.920
Another thing you might like about Ruby is all the gems and frameworks available. There are lots of gems, and almost anything you could need is out there. Among those gems, there are choices; sometimes, there’s more than one gem for the job. One might be more suited to you than the others. Gem authors tend to emulate Max, as they want to produce software that makes you happy, too.
00:03:37.159
Now, if we're going to talk about Ruby gems, the 800-pound gorilla is really Ruby on Rails. So, show of hands: Who codes in Rails? That's a pretty high percentage. Who came to Ruby from Rails? About a third—I'm actually surprised. For another question: Who was coding Ruby before Rails? That does not add up to 100. And finally, who loves Rails? I do love Rails. While there are reasons not to love Rails, there are certainly reasons to appreciate it. Lastly, who has a job because of Rails? Clearly, that's the majority.
00:04:29.199
Rails has been good to us. Why do we love Rails? An entire talk can be done on this, but I'll summarize it: productivity. We're all very productive in Rails. You know, Matt talks about Omo, and his take on it makes him happy, and it tends to make most of us happy when Rails does what we want. So, Rails can make you quite happy.
00:05:02.080
But the problem is, Ruby is not a panacea; it doesn't solve everything for you, nor should it. There are times you might not use Ruby purely for speed; for instance, when doing image processing or video encoding, Ruby isn't the best fit. Scaling is another challenge; Ruby doesn’t scale well for resource-heavy or computation-heavy tasks.
00:05:35.800
Sometimes, the functionality you want isn't even in Ruby; for example, if you are interested in scientific programming, Python support is better. It would be silly to rewrite that in Ruby unless you really have to. These are all legitimate reasons not to use Ruby.
00:06:02.680
Now, the problem is that some non-Ruby technologies can be less happy-making. We've already established that being happy is important here. A common alternative is Node. Node.js is good for some things, primarily quick, non-blocking I/O and concurrency. These are typically the things people talk about.
00:06:45.640
For example, chat applications are frequently used to demonstrate the strengths of Node. A chat app involves high concurrency, many people communicating with each other, and quick transactions with low CPU usage. However, Node isn't good at everything. It's also not particularly good at vertical scaling, as it is single-threaded.
00:07:22.240
If you start to perform CPU-intensive operations or manage slow-running tasks, you lose all the advantages that Node provides. So, if you need to do CPU-intensive work, Node isn't the way to go.
00:07:59.040
Language bias may also come into play. At RubyConf, there's a tendency to feel that too much JavaScript is no good, and thus, the phrase "Sad Panda is sad" resonates here. The question then becomes: how do we bridge this gap?
00:08:36.799
One way is Vert.x. So, who's heard of Vert.x? About five people. This is an oversimplified view, but you could consider Vert.x to be like Node for the JVM. That's not a perfect analogy, but it's effective in conveying the idea.
00:09:06.800
To give a better overview, let’s go to their website. They mention that Vert.x is designed for modern applications. I want to highlight some features: it's polyglot, supporting a variety of languages, but at RubyConf, we really care about Ruby through JRuby. I have to clarify that you do have to use JRuby with Vert.x.
00:09:45.760
It's not just simple; it's simple but not simplistic. Vert.x has a well-designed API, and it does many useful things, including achieving scalability and concurrency. Key features include event bus architecture, allowing you to connect your system's components seamlessly.
00:10:20.720
They have websocket support for server push, a major component contributing to its power. Their module system essentially serves as the Vert.x equivalent of gems. You can register modules, and an intriguing aspect of the Vert.x module system is that you don't need to install a module beforehand; you can give it a fully qualified path name, and it will go to the repository, fetch it, and run it. This is a fascinating approach.
00:10:55.599
Just like Node, it handles concurrency using a reactor pattern, which is utilized by many event-based systems. It’s efficient with non-blocking I/O, and it's fast in several ways—superior to Node. Since we're on the JVM, it can handle multi-threading effectively. Ruby's JRuby is the fastest Ruby implementation available, leveraging the optimizations of the JVM.
00:11:36.959
When it comes to slow-running items, the JVM knows how to manage threads. Node is not useful in this aspect. Vert.x introduces a concept called worker verticles. These are designed for tasks that might take longer to process.
00:12:05.120
By default, verticles are set up for asynchronous behavior; however, there are worker verticles that utilize thread pools intended for long-running processes that communicate through the event bus.
00:12:45.200
Additionally, Vert.x allows for horizontal scaling and high availability. You can easily run a verticle per CPU, which is managed effectively due to Java’s underlying capabilities.
00:13:23.200
It’s also designed as a system of systems. I could point out many features such as availability, clustering, subsystem communication, and the event bus which allows seamless interaction among components.
00:13:47.360
You can build virtually anything you want, and you have the foresight to connect all the components together. Now I'm going to take a sidetrack into duct tape. This image is called "duct tape moving," which whimsically suggests that you can duct tape anything together.
00:14:11.720
I think many of us have experienced this in open-source systems, as we often come up with creative ways to integrate various tools and technologies. For instance, Perl was once considered the duct tape of the Internet. While Ruby is a better tool, it also picks up some of that slack. Gems can formalize this duct taping experience.
00:14:51.480
In contrast, Vert.x is designed for integrated systems. Again, we have the concept of asynchronous and worker verticles, which accommodate different processing needs. In-process communication becomes vital, and the event bus supports publish-subscribe messaging and direct messaging.
00:15:40.160
It extends to the browser, allowing browsers to sit on the same bus as your server-side components, which is incredibly useful. They also support shared data structures, which you can utilize similarly to using Redis or other storage solutions.
00:16:23.040
One of the features of Vert.x is high availability. This allows you to invoke paths for clustering appropriately. I could delve into this aspect further, but I want to point you towards two excellent overview videos.
00:17:02.080
The first one is Tim Fox introducing Vert.x, and he's the founder who provides a great overview of the various features. He showcases live demos, illustrating high availability and clustering. It’s an insightful talk illustrating how Vert.x is superior to Node in numerous ways.
00:17:45.440
However, as with every emerging technology, there's always more to learn. This creates a feeling of 'Sad Panda'—because we have limited time to absorb it all. But what if I told you you could keep coding in Ruby and extend it as needed in Ruby?
00:18:30.080
And the answer is: what if I told you about Jubilee? This is probably the best web framework for Vert.x available. Originally, it started as a rack server with Vert.x built in, but it has now transitioned into a Vert.x module that runs rack.
00:19:03.280
In essence, this technical shift improves performance and interaction with the rest of the Vertex ecosystem. The summary is that you get all the power of Vert.x while continuing to handle your Rails projects as you always have.
00:19:41.920
Now, let us explore six reasons why Vert.x could be your new best friend as a Rubyist: concurrency, speed, expanded ecosystem, built-in upgrade path, easy WebSocket support, and the significant capability of reusing all the knowledge you have.
00:20:33.440
For concurrency, Vert.x utilizes the same reactive pattern as Node. You can use it for tasks like web servers where each verticle is single-threaded, with a straightforward concurrency model. You scale up by running a verticle per CPU.
00:21:20.760
In terms of speed, the JVM always gets faster, allowing for the effective use of CPUs and threads when necessary. Benchmarks can be misleading; however, one comparison between Vert.x and Node from 2012 reveals that Ruby is slower than Vert.x.
00:22:05.400
When it comes to Ruby web servers, Jubilee ranks as the second fastest Ruby server. I’m sure many of you have seen the Ruby web benchmark report published a few months back. It evaluated how fast various Ruby servers could perform.
00:22:52.160
TorqueBox was reported as the fastest Ruby server with about 10,159 requests per second, while Jubilee was clocked in at a robust 9,500. This puts Jubilee in the same ballpark as the best of them.
00:23:48.640
As for the ecosystem, by being able to run Rack and access Ruby gems alongside the capabilities of the Vert.x modules, you can take advantage of a vast set of libraries. At the time of writing, there were roughly 200 gems available, but this number is likely on the rise.
00:24:41.760
The pathway for upgrading is exceptionally clear, designed to build systems of systems through verticals. These include async verticals and worker verticals to handle complex requirements.
00:25:23.279
Make sure you utilize the event bus effectively for communication, as it is the main component connecting all sub-systems. The event bus supports shared data and clustering for high availability, thereby enabling a well-integrated architecture.
00:26:15.440
Ultimately, Vert.x and Jubilee are designed to work seamlessly together—which is far better than trying to duct tape various disparate pieces of technology.
00:27:02.160
To illustrate this, let's examine my game's chat application, Rock-Paper-Scissors Mayhem. Here's the URL, rock-paper-scissors-mayhem.bitly for everyone to visit. Please sign in using Twitter and interact with each other!
00:27:39.120
I designed this game to run on a free dyno, keeping in mind the small size of the audience. This means it should handle ten players without difficulty. However, many applications require connection access to avoid connectivity issues.
00:28:15.440
The game is interactive; you can sign in via Twitter, choose opponents, play, and leverage the chat features. As you engage, the game allows real-time communication for an immersive experience.
00:29:03.160
I've run typical tests where users can join and interact with each other, enjoying the active feedback loop from the game. Each player can see live updates of actions taken among participants.
00:29:56.960
From the starting page, you enter into a layout that indicates active players and allows challenges to be issued. If a challenge goes unanswered after a timeout, the server shuts it down and communicates that with both players.
00:30:35.760
Since the event bus connects the game thoroughly, the player experience is fluid. The backend uses the event bus to handle state management and business logic, enabling streamlined interactions.
00:31:22.639
This design effectively utilizes the advantages of the technologies being used, positioning Jubilee and Vert.x not as duct tape solutions but as integrated, modern frameworks.
00:31:42.639
For instance, I integrated Rails for the user interface and Twitter authentication. While using Jubilee, I manage event streaming and communication very intuitively. The system operates efficiently as everything communicates back to the event bus.
00:32:40.760
In terms of game logic, each player operates individually by their unique identifier. This not only streamlines communication but ensures that state data remains consistent across all sessions.
00:33:33.679
The separation of game functionality is emphasized, with distinct modules ensuring clarity and manageability across the system. While using Opal, I can ensure that the application remains in Ruby, further reducing context switches.
00:34:27.439
In conclusion, you can see that adopting Jubilee means more opportunities for happiness in Ruby development. While challenges remain—such as compatibility issues with gems or debugging across async setups—many advantages lead to improved productivity, deep integration, and a reaffirmation of our love for the Ruby language.
00:35:20.880
After implementing a Ruby-based game in the browser, the results reaffirm that it’s possible to create engaging applications without switching paradigms or jumping into JavaScript. If you're interested in my entire code repository, there is a link available!
00:36:07.600
My last words are a reminder: you can be happy in Ruby development, functioning effectively within the framework you know and love. This is a high opportunity time to leverage what you have while elevating the technology you work with.
00:36:57.160
Thank you for your attention, and thanks to everyone in the Ruby community who has helped make these technologies accessible to us. Let's keep expanding, improving, and enjoying Ruby together!
