The Asset Pipeline Or Turbolinks 

I thought this was about jRuby! It is. 

This Talk • Is aimed towards people doing web work. • Although jRuby opens a lot of awesome things on the desktop, for apps, gaming, etc., and on mobile with Ruboto, that’s a different talk. 

jRuby • It runs your Ruby code, but using the JVM instead of MRI. • Read the wiki 

Thanks! 

MongoDB Scale Backlash: The Asset Pipeline • Take a trip back... • My designers can't work this way! • "Nothing works now, my CSS is hosed and my JavaScript fails. • What did we learn? • The asset pipeline uncovered that people were doing bad things. 

Over 9000 Hadoop Clusters of Bad: Turbolinks • Oh my god this is the worst ever. • Things run 8 times or not at all! I can't delete things! • My 12 analytics js snippets don't work! • "The first thing I do it rip it out of projects" - Mike Danko • What did we learn? • People were also depending on bad decision making. 

It's not so bad though, really? This is where you all nod. 

Obamacare Scale Tragedy: jRuby • OMURGHURD gems! Gem dependencies! Won't anyone think of the children? • 2GB of RAM for my app? Ain't nobody got time for that. • X app/gem dep is not thread safe. Like this one called Rails. • git push heroku master of puppets is pulling your STRRRRRIIIINGS. Twisting your mind and smashing your dreams. • I've got all this C code I absolutely require! 

Why the Comparison to the Pipeline? • What I took away from those things: babies and bath water. Or get off my lawn. • Doing things the “right” way helped me learn the tools I use a bit better. • Being open to new ideas is always a benefit for your users, so jRuby. 

The Reality: It's Awesome • Most of your gems will work. Some of them will work better. • If you're not using 2GB of RAM you have a small app and little concurrency, or you haven’t optimized your JVM. • Threadsafety/concurrency is not really complicated anymore. • I don't Heroku for anything of importance. • C? There is FFI. But why when you have all of Java? 

Is it all sunshine and giggles? No. • You have to know your JVM and choose it wisely. • Behavior of the JVM itself changes per platform even with the same build. • 1.7.5, the current release, is broken for a lot of people. (OpenSSL issues, invokedynamic issues) • Your dev and deploy platforms may be wildly different. • But how long did it take you to setup homebrew and everything else? Quick? You go through a lot of startups. 

Why jRuby? • Kick ass garbage collection “Oh, let me reboot our mongrels after 24 hours...” • Threading. See “Why jRuby” talk by Charlie Nutter • Profiling tools are amazing. • Performance. jRuby compiles to Ruby to JVM bytecode. JVM compiles bytecode to native. As soon as invokedynamic doesn’t implode on the JVM... 

So Why jRuby? (for the web folks...) • A whole new set of tools open up to you, and ones you’ve already used may take advantage of the platform in awesome ways. • Highly concurrent web servers like Puma, Trinidad (Tomcat), Torquebox (JBoss), Mizuno (Jetty), and Vert.x. • Deployment into the “enterprise” with .war files. • Distribute a .jar file that contains your entire app. 

jBoss? WHAT? You already are building your own jBoss. Just go with Torquebox. Get everything in the same process. 

Why jRuby? • Thinking freshly about problems you’ve solved in the past might open up better ways of doing things. • Can’t have ImageScience? Try Joyent’s Manta. • Some library has concurrency issues? Try a native Java library for the same thing. • You probably didn’t need those extra 50 gems anyway, you have no idea what’s under the hood, why not simplify? 

Making the switch • Most of the time it “just works”. • When it doesn’t, check lousy gems. Stack traces aren’t always helpful. Most aren’t concurrency issues, but loading issues. • Something else not running? Make sure you’re eager loading, not autoloading everything you need to be available at runtime. 

Now that you’re running... • Optimize your JVM. See the jRuby Wiki. • Startup slow? See the wiki. • Consider compiling libraries ahead of time. • Avoid spawning subprocesses, launching another JVM, and making things REALLY slow. Must do this? Try Nailgun. Think image processing and the like. • Just try Nailgun. 

Growing from there • You really have to start “Thinking jRuby/JVM” • Look to the Java world for architecture and design (but don’t look too long, your poor eyes). • Don’t fear using Java. • Read the entire jRuby wiki - it’s worth your time even if you choose not to use jRuby. 

Thanks!