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

by Forrest Chang

In the video titled "6 Reasons Jubilee Could be a Rubyist's New Best Friend," speaker Forrest Chang discusses the value of using Jubilee, a web framework built on Vert.x, specifically for Ruby developers. The main theme revolves around enhancing Ruby development with the benefits of concurrency, speed, and the ability to utilize the JVM ecosystem without abandoning Ruby's inherent joy. Chang highlights the importance of happiness in programming as a motivation for selecting technologies.

Key points discussed include:
- Joy-Driven Development: Emphasizing coding as a joyful process and how Ruby enhances this experience.
- Ruby’s Advantages: The clarity and expressiveness of Ruby code compared to other languages like Java and JavaScript.
- Limitations of Ruby: Addressing scenarios where Ruby falls short, such as image processing and lack of concurrency support, pushing developers towards Node.js for specific use cases.
- Introduction to Vert.x: Compared to Node.js, Vert.x is presented as a more robust alternative for building modern applications, particularly in conjunction with Ruby. Its support for polyglot programming and architecture catering to concurrency and scalability are emphasized.
- Features of Jubilee: As a framework based on Vert.x, Jubilee allows Rubyists to leverage existing Ruby knowledge and gems while improving performance through the Vert.x ecosystem. The tool provides ease of use with features like WebSocket support and shared memory structures.
- A Real-world Example: Chang illustrates the capabilities of Jubilee by discussing his game project, Rock-Paper-Scissors Mayhem. He explains how the game employed real-time interactions and efficient backend state management through the event bus architecture of Vert.x.

In conclusion, the primary takeaway is that Jubilee enables Ruby developers to maintain their workflow and productivity while tapping into more powerful concurrent and scaling capabilities provided by Vert.x, leading to happier programming experiences.

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!