02:18 - Ben Browning Introduction

02:46 - TorqueBox 

04:05 - Use Cases and Benchmarks

06:32 - The Genesis of TorqueBox

07:49 - JBoss

09:15 - The Name “TorqueBox”

10:12 - Adoption

12:05 - Documentation

13:18 - When should/could you use TorqueBox?

17:25 - Monolith vs Microservice

21:36 - JAR Files and WAR Files

25:31 - Server Setup & Deployment Process

27:16 - Packaging Static Assets in JAR and WAR Files

28:27 - Contribution and Community Involvement

32:55 - Startup Cost

35:53 - Getting Started with TorqueBox

37:33 - Immutant

40:17 - The Rack Spec and TorqueBox

42:11 - Useful Features

44:26 - Building Useful Features

45:53 - Growth

Picks

[Khan Academy] Pixar in a Box: Introduction to Animation Curves (Saron)
Tony Stark in Salt and Pepper (Saron)
ElixirConf (Jessica)
Nick Shrock: GraphQL Introduction (Jessica)
Troll - Shane Koyczan (Coraline)
funtools (Coraline)
Ruby Remote Conf Talks (Chuck)
Angular Remote Conf (Chuck)
Bob McWhirter: qcon-keynote (Ben)
Coders For Sanders (Ben)

Extras

Special Guest: Ben Browning.

 

Hey everybody and welcome to episode 225 of the Ruby Rogues Podcast. This week on our panel we have Jessica Kerr.

Good morning.

Saron Yitbarek

Hey, everybody.

Coraline Ada Ehmke.

Hello.

I'm Charles Max Wood from DevChat.TV. This week, we have a special guest and that's Ben Browning.

Good morning.

So Ben, do you want to introduce yourself?

Sure. So, I work at Red Hat. I lead a project called TorqueBox which you'll hear more about in a minute. I'm an active JRuby contributor as well. And I've been at Red Hat for five years now being paid to do professional open source development. Before that I worked in more traditional companies where it's closed source software, Java, Ruby, .NET. But open source is where I am now and where I love it.

Awesome. Do you want to give us a quick overview of what TorqueBox is? I've used it before. I don't know how many of the rest of the panelists have or our audience has, so I'd like to just give them an idea of what it is.

Sure. We call TorqueBox a Ruby application server. What it basically is, is we tried to take the idea of Java application servers. Rubyists are always [aren't] in love with Java. They want to be Rubyists. A lot of Rubyists are ex-Java people but they have a lot of problems that they have solved in Java with application servers. We basically are trying to take that and bring it to Ruby in a way that is familiar and comfortable for Rubyists without having to reinvent the wheel to solve the same problems that have already been solved in some of the Java spaces.

It's a JRuby project. It only runs on JRuby because we do sit on the JVM to take advantage of Java. But we allow you to run Rack, Rails apps on top of TorqueBox. There are also libraries for other things. If you want to do scheduled jobs or messaging, we have a lot of these different components that we bring to the table outside of just web. And a lot of our users use us because of the other components. Some of our users just use us for the web bits. Some people are in a position where they do Java at work but they can use TorqueBox and it runs on a Java server but it's still Ruby, like a [Warbler] if you will.

It seems like there are two or three use cases that I see with people using it. And one is that they work in a Java shop and like you said they just take advantage of the stuff that's there. It all runs on top of JBoss so their ops people and everybody else are familiar with it. So, they can take advantage of some of the momentum that they already have in the company and then they just put this stack on top of it. The other use case I see is that people look at TorqueBox. They like some of the performance characteristics of JRuby and they also see that because TorqueBox provides all of these different pieces that they can plug into, they get a lot of their stack more or less for free. And then they just take advantage of the APIs that are provided by TorqueBox. And then the last group like you said is just the group that's using it for a web server. And then occasionally they might dabble over into something else.

Right, exactly. And the last group is actually a growing group, we've seen. Because we do have such good web performance, being on JRuby having real threads, sitting on top of… it's not a new pure Ruby implementation of a web server we've written. We're just adapting to existing highperforming web implementations. So, we've actually had a lot of success with our web performance compared to some of the other Ruby servers. And so, part of where we're going in the future is to make sure the people that just want the web bits of TorqueBox can get that without having to bring in all the other bits that they might not want or need at the moment.

Are there benchmarks for that? I'm really curious.

There are. We did a pretty exhaustive benchmarking test. It's a couple of years back now. So, it's pretty out of date. The latest benchmarks I've seen, and I'll have to get you a link, is… TechEmpower is a third-party. They're not affiliated with Red Hat at all. They're not affiliated with Ruby at all. They benchmark lots of languages and frameworks. And they have a benchmark and we a while back transitioned all of their JRuby benchmarks to run on top of TorqueBox 4, which is still in beta. It's not actually completely released yet. But when we did that, we've gotten TorqueBox performance for some of the basic Rack apps on par with some languages that you would expect… like Go and other things. I'll get you a link for that to show that.

So, our web performance has been doing really well. The TorqueBox 3, which is our current stable version, is not as fast as TorqueBox 4 but it's still very fast. People tend to try us out and we perform favorably compared to a lot of MRI-based servers.

I'm curious. What was the genesis of the project?

That's a great question. So, I lead TorqueBox project. I've led it for about three years. But I did not start TorqueBox. I did not create TorqueBox. TorqueBox was created by Bob McWhirter who is my boss. Bob also was instrumental in the creation of Groovy and Drools, if you ever heard of the Drools Java business rules project. And so, he started TorqueBox. I don't know the exact reason he started TorqueBox. I can speculate that he worked for JBoss at the time. I actually think he may have been on a sabbatical even at the time.

But the idea of the JBoss application server in Java solves a lot of these problems in other languages like in Ruby. Or in Rails specifically we're seeing a reinventing of the wheel. And it takes years and years to get to a mature solution for something that, it's already done in another language and it's mature. It's just that it's another language and it has baggage associated with that. So, the idea was can we utilize what's already there from another language without the baggage of having to let users deal with XML files and that kind of stuff that usually comes in the Java world? And so, it used to be called JBoss Rails I believe. And then about six years ago they renamed to TorqueBox and became an official project of Red Hat.

And JBoss is also a Red Hat project, right?

That's right. Red Hat bought JBoss. When we say JBoss used to be its own company and they had a flagship product called the JBoss Application Server. And Red Hat acquired them several years, many years back. It's before my time. So, when you hear JBoss usually people are referring to the JBoss Application Server which is definitely a Red Hat project. Nowadays that's actually called WildFly, W-I-L-D-F-L-Y, WildFly. They renamed to WildFly for the community version. And as we do at Red Hat we also have a supported version that they call JBoss Enterprise Application Server. And TorqueBox builds on top of those bits. We build on top of the community bits since TorqueBox is a community project, to ship our code.

Yeah, that makes sense. Back before I started programming professionally I worked in IT at Brigham Young University and they were a big Red Hat Linux and JBoss shop for all of their assets.

Yes. A lot our customers are pretty big shops. It's the challenge of TorqueBox and Ruby, is that a lot of Ruby shops are not the giant corporate shops, although that's changing. And we've seen that changing the last several years. So, it's an interesting balance to walk between corporate developers and attracting the startups in Ruby that want to write code. And I think JRuby's probably helped a lot here getting Ruby into the enterprise and the corporate environment.

Why is it called TorqueBox?

I actually don't know if I know the genesis of the name. [Chuckles] I think 'box' has to do with everything's kind of all in the tin. The idea is everything you should need to write a moderately complex application, not just the demo but actually when you need cron jobs and messaging and all that kind of stuff. So, I think the 'box' is everything's in the tin. I don't know exactly where the 'torque' came from, whether it denotes power or whether it was just a fun word [chuckles].

Yeah. It seems to me that the word 'torque' implies leverage. You think of applying torque as increasing your speed of rotation, in physics sense.

That's a great explanation. Yes. I will have to use that from now on.

Increase your speed of development. Apply leverage to your development process with TorqueBox.

That's pretty catchy.

To make it turn faster.

I'd just get dizzy.

So then, I'm curious. Do you see most of the adoption being Ruby shops that want to take advantage of JRuby or do you see an equal amount of adoption by Java shops who are interested in getting started with Ruby projects?

We have a mix of both. We have quite a few Ruby shops that were small and they were hitting scaling problems with Ruby. They were on MRI or they were on JRuby but they were using another web server, whether it was using Warbler and Tomcat or whether it was Puma or something else. And most of our customers seem to be, or not customers, most of our users seem to be people that have scaling issues with Ruby and they want something to help solve that. And so, it's an even blend.

And that's another point to the fine line we have to walk, is how TorqueBox appeals to the Java developer wanting to try Ruby is a lot different than how TorqueBox should appeal to the Ruby developer that's used to MRI. Java developers are used to application servers and containers. Ruby developers are used to just 'gem install' and 'rails server' and that's it. And I think we're swinging more towards the Ruby side now where with TorqueBox 4, I can talk more about that in a little bit, but it's a major change for us in direction.

And we're really trying to focus more on the embedded use case. The Ruby developer that wants a

familiar development feel to how they get with Puma or Thin or Passenger to some extent or Unicorn where it's just install some gems, and go. So, I think that's where we're moving towards. But we have had a lot of interest from the Java shops in the past. And I actually think, we're probably… Java people wanting to learn Ruby probably don't try this first. They probably try Warbler first, will be my guess, just because then they can directly run that on Tomcat or GlassFish or JBoss Application Server, whatever they're already running. And that's probably the path of least resistance for those Java shops.

That's interesting that you have multiple audiences that you're trying to help: the Java to Ruby and the Ruby to JRuby performance levels. Do you find that that affects how you write your documentation?

It does. So, it has been a tough balance and we're not sure we even have the balance right yet. But previously our documentation was all written in DocBook XML format which makes a giant manual basically. And then we've since moved to writing documentation basically as markdown and mainly as actual documentation on our methods in our Ruby API itself, and actually just using Yardoc to generate a lot of our documentation now. So, it is hard, because Java users expect one thing and Ruby users expect another thing.

And like I said, I think we're mainly trying to focus now on the Ruby users because Java users that want to use TorqueBox have to learn Ruby anyway. And so, I think if they want to come to TorqueBox and it's familiar from a Ruby standpoint, then that helps them also learn the Ruby culture versus trying to make everything look and feel Java-ish that A, alienates our Ruby users, and B, that doesn't do a whole lot to help immerse people transitioning from Java to actually immerse themselves in the Ruby culture and development.

I'm a little curious. If somebody has an existing Rails app, what are the red flags or smells or problems that they're going to see that they may want to explore TorqueBox to solve?

Just from a pure performance standpoint, if you're making lots and lots of Ruby processes, and this will go really from a generic MRI to JRuby, if you find yourself using lots and lots of Ruby processes you probably have a lot of memory overhead. And I've seen that you can save a lot of memory by moving to JRuby because we can use threads. We can use a single JRuby runtime and let a thousand threads go in there and work. And there are some caveats around… well you have to make sure that the code that you've written in your Ruby app is thread-safe. That's not always a

concern for Ruby developers. You have to make sure your gems are thread-safe, which is pretty common now for most gems to be thread-safe. But you still run into issues sometimes. So, that's just from a pure web performance standpoint. Sometimes on the server you can save gigs of memory if you're running lots of Ruby processes versus moving to the JVM and running a single process.

Not only that, but once you start having a lot of pieces cobbled together. Our typical example is you've got Resque or delayed_job or some other external, maybe Sidekiq, some other external processing your jobs. You've got your web processes, whether that's on Puma or Unicorn or whatever that's on. And you've got cron daemon set up where you've got some external scheduler process. And then you've got, like God or Monit to handle some other long-running Ruby process that runs in the background. And once you start having a lot of those pieces, that's really where from a standpoint of using all the features of TorqueBox, we can help reduce the complexity by getting it, everything in one JVM, one process.

And we can run your scheduled jobs for you. We can do messaging for you. And we have not only messaging in a traditional sense but there's also a background job abstraction to make it a little simpler. [Inaudible] actually send and receive messages. You can just background work and we'd do that transparently for you underneath. And then long-running services.

And we even have built-in things you can't get from Ruby. Like you can't get, I don't know of any Ruby server at least that does clustered sessions where you don't have to set up an external database. You don't have to set up an external Memcached. The actual process, the TorqueBox processes themselves talk to each other. And we can cluster web sessions back and forth. And that's some of the Java technology we can use. We have some smart load-balancing integrations where if you were willing to use a Java-based, well an Apache module called mod_proxy it talks to the Java-based agent in TorqueBox. And it does some smart things for knowing when a server goes down or if you just [inaudible] one app but leave another app running in the server and that kind of stuff.

you're in production and you start running into these scaling headaches where you want clustering or you want failover or you're having a hard time managing all these different processes.

Right. And all of that stuff is handled by the Java ecosystem with JBoss and some of the other things like you talked about.

Right. And it does come at a cost. When you start talking about all these different things, it's not free. You do have to learn about, there's a lot more knobs you could tweak on the Java side of things because Java developers and especially Java operations people seem to love to tweak knobs. So, there is a nice thing, a simplicity of keeping everything separate where everything's just this tiny little package that in and of itself is simple. But sometimes when you add too many simple things together, the entire suite becomes a little more complex.

And so, then that's usually where I'd say if you're reaching a complexity with your stack where all these individual pieces, it's hard to keep them coordinated and working together, that's a time where it's good to take a look back and say, “Maybe I should look at an integrated solution.” Then everything's in one process. Everything's configured the same way. I've now got to learn, instead of learning how to configure Resque I've now got to learn how to configure HornetQ which is the Java library that underlies our messaging. So, you've got to be willing to learn some of these [Java things]. No matter how hard we try, at the end of the day somebody in production has to know how to tune the Java pieces of the stack.

You said something interesting there as you were talking about taking a bunch of small pieces and putting them into one thing, like you're moving away from the buzzword of microservices, of small things that are in themselves simple, toward a monolith of moving everything into one. But yet, this particular monolith has clustering and failover and all of those things that we always talk about with microservices built-in. So, you're actually making it more safe [when it's] together.

[Chuckles] Right. We [inaudible] a lot. And there is the application server in Java, which is considered a monolith, right? It's got all these things in there. But what you're seeing in the Java world is if you take a project with WildFly Swarm which is also created by my boss, Bob McWhirter, that takes a Java application server container and breaks it down into a microservice-friendly thing where you can just create executable jars that just do one piece. So, it's still the application server. And it's still all integrated well together. But you can choose to just use bits and pieces of it. And that's kind of what we've done with TorqueBox 4, which is not finished yet. Development always takes longer than I guess you think when you do a big rewrite.

But the idea that we still have all the pieces we provide that now you can pick and choose and you don't have to run them all at once, but they're still all an integrated piece that work well together. So, you can have just one process running if you want to that just does messaging. Or you can just use web over here. But they still know how to talk to each other. You don't have to learn five different systems. You can just learn the TorqueBox API and use it across the board. So, we offer you either way. Up until TorqueBox 4 we were pretty much a monolith. But with TorqueBox 4 we give you the option to have your monolith or to do your microservices. But either way, you can use the same API for the app.

Nice. I think this illustrates that the big monolithic Rails app, the problem isn't inherent in its one process. It's one big unit. Because in TorqueBox you've got, yeah you can run it all in one big unit. But that unit is built for scalability. And it's built for reliability. And it's built for modularity even, especially in TorqueBox 4.

Yes. And we've had some users ask us if TorqueBox 4 is vaporware, like Half-Life 3 or something maybe. But TorqueBox 4 has been in development for a while now. And it's a big change. For those that aren't familiar, TorqueBox 1, 2 and 3 was entirely dependent upon the application server. And we bundled the application server, JBoss Application Server, and we bundled JRuby and all of our bits, all in a giant 170 meg zip file you downloaded. And it had scripts in there to run it. And that's more of the Java end of the spectrum. Java people didn't really mind doing that. But Rubyists are like, “What do I do with this? Where's my Ruby gem?” So, with TorqueBox 3 we slimmed that down to be 60 meg, but it was still the same installation process. With TorqueBox 4 everything is a Ruby gem. That's it. You just 'gem install' whatever, TorqueBox.

And then what we do is if you want to run inside an application server then you can download WildFly application server. And we'll create a WAR file and you could drop it in your server. Or if you want to, you install your own JRuby, whatever JRuby version you want. So, we don't have to ship a new toolbox every time there's a new JRuby release. You can use JRuby 9 or JRuby 1.7. So, that's a nice change of pace.

And the other thing we do is you can create an executable JAR file, too So, we can run completely outside of your container, just executable JAR. And what we do is we take the components that make up the container, the Java container, we take the components that provide the web and the caching and the messaging, and we just embed those Java libraries directly into our JAR file without bringing the entire container infrastructure.

So, we give you a whole continuum. You can run your app as a WAR file in a container. And maybe it's a WAR file in other containers. That's something that we're evaluating. And I think there might be desire from the communities to, “Take my TorqueBox app, make a WAR file, and not only run it in WildFly but let me run it in Tomcat. Let me run it in GlassFish.” So, we're looking into what that would mean.

For the Rubyists who are maybe frightened by, “Oh my gosh. Listen to all those Java words.” [Laughter]

Right, right.

Can you define JAR and WAR?

Sure, sure. No, I take it for granted because I live in JRuby all day. A JAR file is a Java application archive I think, or Java archive. And it's like the Java version of a gem, of a Ruby gem, if you will. It's just a bundle of Java code and properties files and code and data. A WAR file is a web application archive. It's basically the same thing, except with a little bit different format. And it's designed to run in Java application servers.

So, with TorqueBox 4 you can create these Java JAR files and WAR files. And the advantage there, the reason why you would want to do that… if you just give somebody your Ruby app that runs on TorqueBox, they can run it without having any JAR files or WAR files, any of these Java stuff. But what they'll have to do is they'll have to, you know, the typical Ruby setup. They'll 'bundle install' and then 'rails server' right? And they can fire up TorqueBox and run their app just like a Rubyist is used to.

The reason we provide the other options is that you can create this JAR file and give it to somebody and all they need is a JVM. And then they can just execute. They can run the JAR file. They don't have to have Ruby installed. They don't have to have gems installed. They don't have to deal with any of that. They just run the JAR file through the JVM and it'll run your app. So, it's a neat way to distribute apps written in Ruby to someone that doesn't have to know it's written in Ruby. They just need the JVM and they can run your app

Is there a build process to get the JAR file?

There is. We have a command in one of our gems. It's called 'torquebox jar'. And all it does is it takes your app, packages it up into a JAR file. It takes your JRuby installation, packages that up into the JAR file as well because we have to have a JRuby to run everything. And so, you end up with this JAR file that may be 20 meg or 50 meg or however big depending on how big your app is. And that has everything it needs to run just with a JVM, without having to have JRuby installed, without having to have gems installed separately.

JAR files can be a little confusing because there are multiple different kinds. A JAR could contain a library. It could be just a bunch of classes that you can then import to use in your app. Or it could contain all of its dependencies as well. And it could contain configuration to say, “Here's the main method. And then it can be executable as an application on its own.”

Right, correct.

And then the WAR file, I believe that just adds some metadata for the application container?

That's correct. It basically adds an XML file [chuckles]. It doesn't have to be an XML file. But the WAR file just adds metadata. It's typically in the form of an XML file or some other thing. There are a couple other layout conventions in the WAR file as far as where you place the classes. But our users don't have to worry about that. But all it means is it creates a file that is a standard that Java application containers can read and run as a web application. So, most containers, you put this WAR file in a certain directory and now it deploys your application for you. Our WAR files only work with WildFly right now, which is the success of the JBoss application server. But I guess that we've had some interest.

And we technically know how to do it so we may spend some time trying to get them working other places in an effort to encourage adoption from people that for some reason don't want to run WildFly. We have a lot of users that, “I'm stuck on Tomcat. But I'd like to use it.” And currently we can't run our stuff on top of Tomcat, which is another popular Java application server. So, we want to make sure that the Java users can run this on whichever server they really need to. For Ruby users, none of this really matters. You can just treat us like I said, you can just add some dependencies to your gem file, 'rails server' and it'll run TorqueBox. And you don't have to worry about any of this.

So, if I'm setting things up then to deploy this, you said that the WAR files will only run on WildFly?

Is that what it is?

That's correct, yes.

So, I have to have a server set up somewhere not just with the JVM installed but actually with WildFly on it and then the deployment process is just copy the WAR file up and tell it that it's there?

If you're using the WAR file, I would only suggest to use these WAR files if you already are using WildFly. That's the difference. You don't have to have WildFly to run TorqueBox applications. But if you have WildFly which a lot of people do, we make it so that you can bundle up your Ruby app as a WAR file and just, you put it in a certain directory in WildFly or you use their administrative tools to deploy that WAR file and it'll deploy the application for you.

But if you don't already have WildFly and you don't have a reason to want WildFly, then we also allow you to just, either you make it into an executable JAR file and that means that all you need is a JVM, or if you're only deploying, your only audience are Rubyists then it's easy enough to just distribute the app as you would any other Ruby app. Whether it's just the source tree basically, on disk, and you tell your users to 'bundle install' and then 'bundle exec rails server' and off you go without having to deal with any Java side of things at all.

Oh, gotcha. So, you can actually set this up with Passenger or run TorqueBox on a JRuby instance and it'll just do its thing?

Right. I haven't tried it with Passenger. But TorqueBox definitely can just run. You need JRuby installed and then you can just run TorqueBox without having to deal with any of the Java…

Right.

Application servers.

Now, if you are using the JAR file or WAR file does that include or does that package up all of your static assets as well? So, you compile your SCSS or Sass into CSS. You compile your CoffeeScript or whatever else you're using into regular JavaScript. You have your image files and it just packages all that into the JAR file or WAR file as well?

We have some options when you create the JAR and WAR file as far as what to include and not include. And I'm actually not sure at the moment if we do the asset compilation. Obviously, we should. But like I said, TorqueBox 4 is still in beta and we have a ways to go. I'll have to look and see. But things like that are where we… the reason we're still in beta. We've got to fix these kinds of things for actual production usage. And none of this talk with WAR file or JAR files applies to the previous stable releases of TorqueBox. It was all a giant zip file you download and run. And it does for sure have tasks for precompiling assets.

With TorqueBox 4 it's basically I'd love to get some volunteers from the community helping us do these things so that… I don't work full-time on TorqueBox. I do get paid to write open source software but I'm not paid to full-time work on TorqueBox. So, it'd be great to have some community volunteers. If you want to add to our asset compilation step and stuff like that, it'd be appreciated.

If someone wanted to help out with TorqueBox, how much background would they need in both Java and Ruby? What should people do that's approachable?

Sure. A lot of TorqueBox is written in Ruby and a lot of it's written in Java. There's a clear delineation. So in the case, the example of asset compilation, tasks like that, things that happen when you're building the JAR file, all of that happens in Ruby. Other than the actual final step of writing out the JAR file itself. But everything as far as which files should we include in the JAR file, what command line flags do we have for this command, all that kind. So, all of our command line tools are all written in Ruby and use the Ruby option parser, optparse, to parse options. So, it's all very approachable Ruby code. If you want to get into the guts of the actual running server itself, there's going to be at least some Java involved.

So, the easiest thing if you just want to help out and only know Ruby is to help with these command line tools, adding extra options for JAR creation, stuff like that. If you're willing to learn Java or you already know Java, then there's a lot that you can do to help out with simple things. Like we have some features that exist in TorqueBox 3 that don't yet exist in TorqueBox 4 just for lack of time at the moment. And so, it'd be great to have anybody that knows Java that can help port features over. If you don't know programming at all and want to help, our documentation could always use help. Migration guides, that kind of stuff. I think we have a task that probably anybody with any skill level could do. And if you know Ruby and/or Java then obviously that's a bonus.

And some things, there are some tasks that you really are going to have to know the guts of the underlying technologies that build up the WildFly application server. And so, for some of those, some tasks are going to require a lot of in-depth knowledge that not everybody would have. But if you have a basic understanding of Java or Ruby, you could help out with most things.

What kind of involvement do you see from the open source community?

We have had a lot of involvement lately. So, how TorqueBox started is it was basically a Red Hat driven project. We had a team of four or five engineers paid by Red Hat. We evolved TorqueBox and he had a lot of users. And we still have a lot of users. But over time, the number of people paid to work on TorqueBox full-time has diminished. And so now, we're trying to reach out more to the community. And I think part of it is we had a lot of community pull requests with simple things. Other than one or two, we never had very many non-Red Hat actual contributors to the code, actual people involved in the day-to-day [writing] of the code.

And it could be that maybe all of us being Red Hat employees maybe gave the impression that it was like a sacred cow or something that maybe outside people couldn't touch. But that's not at all the case. So, we've had some discussion on the mailing list about opening things up, getting people more involved with TorqueBox itself. We have a lot of users still. And we always have a lot of users looking for support as well.

So, there's plenty of opportunity here as well for some people to learn TorqueBox and offer support services to some of our users. It's something that I at Red Hat don't provide at the moment. And it would be a great benefit to the community as well. If somebody doesn't even want to write code but they are great at helping find and fix problems, then there's always that avenue as well.

When you think about the future of TorqueBox, do you see it becoming more of an open source community-led project or do you think it'll always take the lead and be home at Red Hat?

Well Red Hat, I'm sure would always be willing to provide us resources as far as CI and websites and all that kind of stuff. But I would love for, similar to, if you look at JRuby [it's tough]. Red Hat employs some of the JRuby developers. But there are a lot of people that contribute to JRuby that work for other companies that work outside of Red Hat. And I'd love for TorqueBox to be the same way from a pure standpoint of looking to get more done faster, looking to get TorqueBox 4 out the door and better.

And also, I see a big need in the JRuby community to have a high-performing well-maintained server. There's kind of a gap there right now. There are a lot of servers that work with JRuby but some of the more popular ones don't have the best performance in JRuby and it's mainly because it's a lot of work maintaining a high-performance server on the Java side. Especially you've got to make sure you're staying up to date with the latest Java web server technology where everybody doing NIO, non-blocking I/O now and years ago everything was thread-based. So, it'd be great to get a lot of people outside of Red Hat working on it. And you know, I'd love to continue leading it but I'd love to have people volunteer and help. And really, the door is open to anybody at this point that has a passion for open source. If they want to help with open source development, this is a great way to do it.

I have another question related to TorqueBox and JRuby. I mentioned that I have used TorqueBox in the past. I wasn't super involved with the deployment part of it which is why I was asking questions about that. But one thing that I did notice is when I was doing development the startup time, and I think this was more JRuby's fault that TorqueBox's fault but there was a significant startup cost for each process.

So, I'd run a Rake task and I have to start up the JVM and get everything squared away there and then it could do the work. So, for long-running stuff it was fine because you pay that cost when you start up and then it performs great after that. But for running Rake tasks and stuff it didn't make a ton of sense because it took forever for it to start up. I know that the story with that on JRuby has gotten better. But do you see that as an impediment to people adopting TorqueBox in development?

I'm sure it is for some people. Like you said, it's not really a TorqueBox-specific impediment, more a JRuby impediment. And the JRuby people know that. And probably more so [inaudible] just about anybody else, if they could find a magic way to just make startup instant, they'd be all over it. And I know that the JRuby 9, and they have a new intermediate representation in how they're representing Ruby code, I know they have some hopes there to be able to persist some of that, write it out to disk, and then load it back up and maybe do things faster on startup.

So, there is a lot of work. They even have… they've done some work in making some new flags on the command line that… I think there's a '--dev' flag now for JRuby that will tweak some, there's some options you can tweak to make it start up faster at the expense of max throughput. So, for things like Rake tasks, a lot of times you'd be willing to make that trade off, that, “Yes, start faster here. I don't care if it doesn't run at maximum throughput [inaudible] running for 10 minutes. I just want it to start fast and exit quickly.” So, they've been working on extra flags on the command line. And then I think they have a lot of homes for a new intermediate representation.

And then I think the JVM itself, I think the Java teams that work on the JVM itself are aware of it. That is kind of a stigma and there's been a lot of interesting things coming out of the Java team at Oracle, some of their research labs. So hopefully one day, that will be a non-issue. But for now, yes, the startup is still higher. And so, if running a Rake task in half a second, if it can't boot up and run your Rake task and exit in half a second, then you may have to run that Rake task under MRI or look at some of the other JRuby options. There's some options to keep a hot process running in the background so that you have less of that startup cost at the expense of this always-running Java process in the background that you can get it to run your code very quickly. So, there are some hacks like that.

But I think that's one of their main goals with JRuby 9 is to try and, if there's any way to solve this outside of the Java people themselves solving it, solve it. And I don't know. Maybe once everybody has solid state drives if they don't already and high-speed computers, maybe the problem will go away. But in the meantime, it's always that stigma. And you just get used to it. I get used to, okay it takes a second for a Rake task to run instead of one quarter of a second or however quick MRI can start up and shut down.

The other question I have is if people have the running app that they want to try and at least try out in development just to see how it does on TorqueBox, they just install the TorqueBox gem, the TorqueBox server gem, and then 'bundle install' under JRuby and then just 'rails server' just to see what it does? Is that the best way to try it out?

The easiest way if you want to try out TorqueBox 4 in this case, probably the best thing for somebody that's new to TorqueBox to try it out, it still is in beta so you've got to add the TorqueBox gem to your Gemfile. You've got to make sure you but a version qualifier on there, otherwise Bundler will skip any, what's it called, pre-release gems or versions. But yeah, add it to your

Gemfile, 'bundle install'. If you're moving from MRI to JRuby you may have to delete your Gemfile.lock first and then 'bundle install' again. Sometimes you have problems with that. If you're moving from MRI to JRuby generally you've got to do some other things too, like make sure you don't have gems with C extensions or you find a suitable replacement. So, there are some caveats there.

If you're already on JRuby and you just want to try out TorqueBox, it's quite straightforward. Just add us to your Gemfile, 'bundle install' and then I think you have to do 'rails s torquebox'. I think you can just do 'rails server'. It'll probably boot up the built in server. But if you do 'rails s torquebox' it'll boot up TorqueBox for you.

Yeah. I can just say that most of the time when I've switched over to JRuby most of the gems I use just work. So, you can just try it out and then if it barfs on one of the gems then you know you have to replace it.

Right, exactly. And that's the easiest way in my opinion to find out if your gems work or not. Because a lot of gems with C extensions also have Java extensions on the JRuby side. So, just because a C extension under MRI doesn't mean it won't work in JRuby because there might be a Java-specific extension or maybe a fallback to plain old Ruby on the Java side that would work.

The TorqueBox GitHub repo says that TorqueBox runs on top of Wonderboss. What is Wonderboss?

Wonderboss was never meant to be a public project. It's just a codename that we came up with. So, TorqueBox has a sister project. I haven't mentioned it until now. Our sister project is Immutant, I-M-M-U-T-A-N-T. And everything that TorqueBox does, it's the same thing but for Clojure and Clojure apps, instead of Ruby. And so, Immutant and TorqueBox sit on top of this common core that's mostly Java that we codenamed Wonderboss. And Wonderboss is basically the layer that allows us to run inside a Java application server or run directly outside of a Java application server in what we call embedded mode. It's the thing that lets us, lets TorqueBox and Immutant appear to Ruby and Clojure users as they would expect instead of always having to take their app and deploy it to an app server.

So, it's basically just a shim and a helper for common APIs and to help translate APIs from what our users expect into what the Java world expects for the application server model. And basically, it also aggregates the actual components of the application server itself. It has them as dependencies and lets us bundle them in. And we can transparently, to our Ruby and Clojure code, use the right library whether you're running inside or outside of the application server. It's a little complex there to get all the class loaders right. If you're not from Java, you won't know what class loaders are. And you don't want to find out, if you're not from Java.

[Chuckles] But if you are from the Java world you know what they are.

[Chuckles] So true.

[Chuckles] Yes. If you know Java, class loaders can be frustrating, especially in application servers. And so, it has a lot of code there that is the underlying bits. And the goal being that you could come along and make a new TorqueBox but say, for Scala or for any other JVM-based language really. And a lot of the underlying work would be done for you. It's just now you have to put the languagespecific facade on top of it all. That’s the idea of Wonderboss. And that's the grand vision, is that one day maybe instead of just Clojure and Ruby, maybe there would be other JVM… maybe we'd have a Scala and a Groovy and a Ceylon or whatever language we have could have the same capability that we provide.

Cool.

But Wonderboss doesn't have its own website or anything. So [chuckles] I'm impressed you found that out. Maybe we need to remove that from the footer of that page until we decide to make it its own project.

Yeah, the GitHub repo for it looked pretty sparse.

Right, yeah. So it's not… it's developer-facing but it's not really user-facing. But if anybody is interested in taking the features we provide in TorqueBox and doing that for another language, they can get in touch with us because Wonderboss would make that much easier than it otherwise would be.

And just to be clear, TorqueBox works for any Rack-based Ruby framework?

Yes. We have integration tests with quite a few. There's a lot that we haven't tested with, but we do follow the Rack spec. Everything that's mandatory in the Rack spec we follow. We have a partial Rack hijack implementation for WebSockets. And when I say partial, we actually implement it mostly. But a lot of Rack.hijack consumers, if you know what the Rack.hijack API is, it's usually used for, well most commonly people seem to use it for WebSockets on top of Rack, or any other kind of low-level communication that the Rack spec didn't really handle well. It's kind of like a bandaid onto Rack to make it work for some more streaming use cases, WebSockets, that kind of thing. And we do implement that.

We have tested the Tubesock gem against TorqueBox 4 which is a WebSocket, Ruby WebSocket library. And it works fine. But any EventMachine-based WebSocket library doesn't work. What we found is in the Java world, some of these Ruby gems on JRuby have Java extensions that expect… they make an assumption about the exact implementing class that is your socket connection or your I/O stream. And in our case, that's not the right class. Maybe it is when you run under a different server, but not under our server. So, some things don't work. Anything EventMachinebased using WebSockets doesn't seem to work because it expects a certain class. But the Tubesock gem works find.

And we also provide our own SockJS implementation, which SockJS is maybe not as popular as it used to be in the Node world but it was a solution for doing WebSocket push with fallback to other transport protocols if WebSockets weren't supported. And we do provide that as well. So, we try and make sure we support the Rack spec, but also the things that you need to build a modern web app that maybe Rack doesn't handle that well. And hopefully, as work happens on a newer Rack spec we can have some input there and make sure that it works out well for JRuby-based servers.

Are there any features in TorqueBox that people generally don't know are there that are useful?

You know, we've [called] the feature list over the year, the ones that don't seem to get used, we have stopped supporting because just to save headaches from things that people don't actually use and trying to keep it working. We do have some features that are useful but that very few people use. We support distributed transactions. And if you're not from the Java world, you might not even know what those are. But it's where like I can have a single transaction between my database and my messaging system so that if this message fails to get handled or published on the queue, then this database write gets rolled back kind of a thing. It's transactions…

Oh, wow.

Among more than one resource. Not just transactions in my database layer but transactions between my distributed cache, my messaging layer, my database. And we've supported that for a while. But it doesn't seem to get used a lot. So, that's one of the things that are maybe in danger of being ripped out if people don't use it. It's very powerful. But it just is not something that Rubyists seem to really take advantage of. So, that's definitely one of those that's next on the list to reconsider, “Do we want to continue?”

We like distributed transactions and the idea and we think they're useful. But if people aren't going to use it then it's a lot of work to support them, especially given that in the Rails world, like Active Record didn't really… you have to monkey-patch Active Record to get distributed transaction support. There's no Ruby ORM that natively supports it. And we didn't want to have to tell our users well, you've got to use Hibernate from the Java world or any other Java… Java has a lot of these ORMs that support distributed transactions but Ruby just doesn't. So, it's a lot of work to maintain the monkey-patches there and to get it all working. But that's one of our probably least used features that are actually pretty cool. But if you use it, you need to speak up because otherwise, [inaudible] rip it out before too long.

It sounds like a handy feature to me.

It is. But I just… in the Ruby world it's not something that really exists…

Yeah.

Outside of TorqueBox. So, I guess I see why it's not used. It can be more than handy. It can save your data in some cases. And of course, you can get by without them. But you have to be a lot more careful about making sure you're doing idempotent operations and that kind of stuff or you've got to have some other way to make sure you're not leaving things in a hanging state if a server crashes in the middle of something going on.

Yeah, that's a good point actually. Because I assume you build features based on problems and issues you're having or feedback from the community. But once a feature is built and released, how do you decide, or how do you know if it's working or solving that problem? And when would you decide to retire it?

Our first line of defense is: are people asking questions about that feature? Are they filing bugs about that feature on the mailing list or on our GitHub Issues or JIRA Issue Tracker? And that's a good indication of, are people using it? Because in almost all cases, even if by some miracle there aren't any bugs in a feature, there are still going to be people asking questions about it. And then we also are proactive sometimes to say, “Hey,” on the mailing list, “Who's using this?” Who's using this in production? Who's not?

And the other flip-side to it is, sometimes we develop a feature because we want to see, can we do it? I think the transaction's more, can we do that from Ruby? We wanted to push the boundaries of, what can you do in Ruby? So, we got distributed transactions working across Active Record and a distributed cache and messaging. And it was awesome. But in that case, that wasn't born out of a need for us to have it. It was more, can we do it? We think it would be useful. And we did do it and we still think it's useful. But users don't seem to ask a whole lot of questions about it or anything. So, maybe it's useful but not right for the Ruby community at this point in time, maybe, kind of a thing.

TorqueBox is an application server and it's also got all these other pieces built in. Do you see it as, this is something that if you build your application here or want to put your application inside TorqueBox and use the TorqueBox API, you're at a really good place for growth.

That was our hope. I think it is that a lot. Our hope with TorqueBox, especially TorqueBox 4 where we made it where you could choose just the web bit or just the messaging bit. It was to get users to move into our web pieces because it's very high-performance, low overhead web server, right? And at that point, okay you're just using web bits, but then if you need to add the things that almost every application at some point when it grows enough needs to add, some kind of a job scheduler, some kind of a messaging system, some kind of a clustering or scaling or load balancing, the goal is that we're here for you. We have an API for that. We don't have an API for everything, obviously. We never will. But at least for the most common task that we think we have a good solution for, we're here for you and provide and API for that when you need it. And if you don't need it, that's fine. But you probably will at some point, was the thinking and so we're here when you do.

So, I think it is a great path for growth if you get started on it. And at the same time, if you never have anything but web then you haven't lost anything by choosing us to use your web bits because now you get a high-performance web server. And it's not like there's a downside to just using us for your web bits either. But if you need more, we're there. And the other thing worth mentioning too is, if you decide you don't like our messaging, you can just use somebody… there's no restriction. You can just use somebody else's. So, you don't have to use the APIs we provide just because we provide them. You can pick and choose which pieces you want to use. And if for some reason you want to use Sidekiq for your background job processing instead of what we have, that's fine. You're not going to hurt our feelings. We provide something. We think it will work well. But feel free to choose something else if you have a need to. So, it's not an exclusive choice. You don't have to stick to only TorqueBox features on TorqueBox. You can use other things as well.

Cool. It sounds like TorqueBox provides a ramp both in terms of scale and performance and also in terms of all the extra components you might need to add.

Yes, hopefully so. And the other thing that we provide that the JRuby guys love is we have a heck of an integration test suite. It takes forever to run, so CI runs it. But every time there's a JRuby release, we run our full integration test suite. We make sure it's green before they release. And just another great thing that comes from working close with the JRuby guys, I guess, that is really helpful.

The first time I saw TorqueBox I was like, “Okay. They just need to bolt in the kitchen sink.” But it really does have a lot of features that are really handy. And it does a lot for you, I guess is what I'm trying to say. It's everything and the kitchen sink. Anyway, let's go ahead and do picks. Before we get to the picks, I just want to acknowledge our silver sponsor.

Saron, do you have some picks for us?

Yup. I have two picks. So, the first is from Khan Academy. So, I don't know if you guys knew this but I didn't know that Khan Academy had partner content. And I was looking through it and it's kind of interesting. They have partnerships with NASA and NOVA Labs and also LeBron James which I thought was kind of random. But one of them that I wanted to talk about was Pixar in a Box. And so, it talks about all these animation-related classes that they do and courses online which are really interesting. And there's one that feels very beginner friendly called 'Introduction to Animation Curves'. And it talks about coding but also math. And it makes it just incredibly friendly and just really approachable. So, I encourage everyone to check that out.

My second one is… have I done the Tony Stark salt and pepper artwork yet?

No.

I don't think so. Okay. This thing is awesome. Okay. So, there is this artwork done of Tony Stark but entirely in salt and pepper. And it's just mind-blowing. The way they did the gradients and the shadows, I cannot believe that it's just salt and pepper. It's awesome. So, I think everyone should check that out. Those are my two picks.

Nice. Jessica, what are your picks?

Okay. My first pick is ElixirConf because if you want to learn Elixir or if you are doing Elixir and want to learn more, ElixirConf is October 1 through 3 in Austin this year. There's a training day and two days of conference. And I'm speaking. And it's going to be cool.

Woo! Go you.

Yay.

Nice.

Yeah, I know. Yet another conference for a language that I don't yet know.

Elixir's cool.

Oh, very, very.

I got to play with Elixir and really enjoyed it a lot. So, I agree.

Yeah. And the actor model is important. Elixir and the actor model will stretch your mind as it takes you farther into object-oriented programming that any other object-oriented language really goes.

Wow.

Yeah.

I have one more pick and that is from last week I was at the React Really conference in Salt Lake City which was very interesting. And the most interesting thing was two people from Facebook talked about GraphQL. And it's really interesting how it takes all of the data needs from the different [inaudible] in the client and passes them to the server in one request. And then the server assembles the data in the format requested by the client, instead of the client making REST calls and then the next level and then the next level and the next level for a lot of network traffic. I think that's going to be really important in future architecture between UI and backend. So, I'm going to pick GraphQL and I'll put a link in the show notes. It's pretty cool. That's it.

Nice. If you want more information about GraphQL and some of the other React stuff, we did an episode with Nick Schrock and Joe Savona on GraphQL and Relay on JavaScript Jabber. So, you can check that out, too. Coraline, do you have some picks for us?

I do. I have a couple of picks. The first is a short film by Shane Koyczan and I might be massacring that last name. It's called 'Troll'. It's from the album and graphic novel 'Silence is a Song I Know all the Words To'. It's a beautiful animation, five minute song. It looks like it's drawn on cloth. And it provides a perspective on the modern phenomenon of hostile trolling in the online world, something that I've experienced and probably a lot of other people have experienced. It's a take on what happens to the mythological troll as it transformed into the information age. So, it's really great, really beautiful, and really poignant. And that's my first pick.

My second pick is a library called Funtools. So, it was created by my friend Tina Wuest. It's a collection of tools to help Rubyists write Ruby in a more functional style. The recursion tool for example provides helper methods to assist in writing code that's recursive in nature while avoiding issues with Ruby's poor support for tail-call optimization. There are additional tools for patternmatching, type checking, composition, and immutable data structures. It's a pretty cool project and can really change the way you think about how to do Ruby. If you're looking to [inaudible] experimenting with functional principles, it can be a good introduction to those as well. So, that's my second pick.

Very nice. I'm going to put a couple of picks out there. First off, we did Ruby Remote Conf a few months ago. Great talks, great stuff. I'm actually going to be making those videos public. So, you can go check them out. I'll put a link to the playlist in the show notes. And then related to that, I also have the remote conf's RSS feed. It's currently putting out the JS Remote Conf talks. I know that there's some interest with our listenership here in JavaScript. And then after that I will be putting the Ruby Remote Conf talks out there. Coraline gave a talk at that. And it was awesome. And then we had a whole bunch of others including related to what Jessica picked. There was a talk by Dave Thomas which is what got me interested in Elixir in the first place. And I think he really makes some terrific points about where programming as an industry is going. And some of the things that have been mentioned about Elixir with the actor model and pattern-matching and things like that, that change the way you really think about problems and solve things in a much nicer and cleaner way in many cases. Yeah, so I'm just going to pick the Ruby Remote Conf talks and things like that.

And then just remind you that we are doing an Angular Remote Conf so you can go check that out. That's AngularRemoteConf.com. And I'll put a coupon code up, ROGUES. And that'll get you 20% off. So, those are my picks. Ben, what are your picks?

Alright, so I mentioned earlier I work from home. Maybe I didn't mention that. I work from home on a distributed team. And I love working that way. And my boss just gave a presentation at QCon Rio about what it's like to work on a distributed team. And so, one of my picks is that presentation. It was one of the keynotes at QCon Rio. It will be on the official QCon Rio website at some point but it's not yet. And it's a great read. If you've never worked on a distributed team or if you've been a remote worker working from home while everybody else was an the office, it's a great intro into what a distributed team is and why at least we value that more so than just being that one guy or one girl that works from home while everybody else is in an office without you, which is not a good team dynamic.

My other pick is actually a website and a group called Coders for Sanders. If you've ever heard of Bernie Sanders who's running for president, there's a group of volunteers that are being active in their democracy. And no matter who or whatever you are advocating for your democracy, I encourage all of us software developers or graphic designers, anybody to become active and get involved with that in a direct way if possible. So, there's a group of volunteers that put together websites and apps, mobile apps, and all kinds of other stuff to help try and get him elected president.

Alright. Well, I don't think there's anything else so let's go ahead and wrap this up. If people want to follow you or the TorqueBox project, where do they go?

Twitter.com/bbrowning is me, B-B-R-O-W-N-I-N-G. Or Twitter.com/torquebox, T-O-R-Q-U-E-B-O-X. And our website is TorqueBox.org. We hang out on IRC. We're on the mailing list. You can find links from the website. And we're always happy to answer questions.

Alright. Well, thanks again, Ben.

Yeah, thank you so much.

Sure. Thanks for having me.