jRuby for Web People

Personal Learnings about using jRuby, why you should too. If you choose not to, spending some time to learn about it is worthwhile.

Transcript

1. The Asset Pipeline Or Turbolinks
2. I thought this was about jRuby! It is.
3. 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.
4. jRuby • It runs your Ruby code, but using the JVM instead of MRI. • Read the wiki
5. Thanks!
6. 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.
7. 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.
8. It's not so bad though, really? This is where you all nod.
9. 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!
10. 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.
11. 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?
12. 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.
13. 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...
14. 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.
15. jBoss? WHAT? You already are building your own jBoss. Just go with Torquebox. Get everything in the same process.
16. 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?
17. 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.
18. 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.
19. 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.
20. Thanks!