RVM provides a convenient way for developers and sysadmins to install multiple Ruby interpreters and for them to be able to switch them out to manage them, to upgrade them and to manage their sets of gems independently of each other and also it helps with the development workflow. So, if it’s used properly, it helps you manage your entire environment on a per project basis, so that you do not need to know for each project what all of these environment settings were. You simply cd into the directory and your project automatically gets this environment bootstrapped for you, so even if you come back six months later, you just cd into the directory and your environment's set up for you. You can just start working around the project right away without having to try to remember how to bootstrap that environment, even if you have, say, a new machine. This makes bootstrapping your project environment very easy on that.
On that aspect it actually is just like new developers coming in on projects, getting them set up. As long as you are using your RVM or rvmrc correctly it makes it very speedy and efficient to get new developers up to speed, as well as if you are deploying to staging QA, production, you can use this to deploy as well and keep the environments identical between staging, QA, production and development. You are using the same Ruby interpreter, the same patch level, for each project.
The idea for doing it came from "I wanted it for myself, so I did it." However, I’m a guy that has trouble saying no to helping someone, so people started using my project and they were asking for different things and they ended up saying "Does it do this?" and I said "No. But give me a few minutes." And I would go and implement a quick thing and they would say "Yay! It works! Thanks!"
3. What was the first thing? What did it start with?
What it started with was at my old job we had a couple of projects. One was running on 1.8, one was being started on 1.9 and there was another one that had to be run on JRuby because we needed the JDBC to connect to an SQLServer instance at the time. Because of this we needed something we could quickly install all three Ruby interpreters and be able to switch between them for the projects quickly and easily. As time went on, it ended up evolving into a "Let’s make it manage the environment and stay out of the way" kind of thing and basically try to eat all the pain itself so that other people don’t have to.
4. Taking this concept of managing pain, I hear you have a new project called BDSM.
Yes, it’s the Bash Delectable Scripting Modules and what it is, it’s basically this three-part framework. There is a core, which is basically nothing more than a shim, the shim launches extensions and an extension is basically a namespaced set of scripts that shares common functionality - for example, Redis. Everyone loves Redis or nginx right? Redis has a packaging part to it, where you download, you extract, you make, you configure, you install - that kind of stuff - and it also has a service type thing where you want to be able to start, stop, restart and check the status of it and stuff like that. Those are two different things.
The start script, the stop script, the install script those things all for Redis end up going into the Redis extension, so their namespaced scripts that are specific to Redis and basically you say BDSM extend Redis, BDSM Redis install and it calls out the ./bin/install script for the Redis extension. Then you do the BDSM Redis start and then it calls the start script in that extension, after you’ve extended it. Now, where the third part comes in is the modules. The best equivalent for Ruby developers to get it is that modules are similar to the standard library for Ruby whereas there are lots of standard libraries for shell scripting. For example, you have a file system module that allows you instead of remembering shell scripting - "if[-de]….." - to do "If directory_exists blah", give it the path or "if array_is_nonempty" get the array variable name. It’s very clean and readable and I’ve added back-traces similar to the Ruby stack trace to do this shell scripting as well.
5. Is this a dramatically better way of writing?
Yes: system level scripting. The extensions can be equated to probably the closest thing is Ruby gems and you are going to be able to package them and release them similar to a Ruby gem type of thing.
7. It also sounds similar to the homebrew.
Yes and no. There is the file system module, array module, trace module, all these things and those are low-level modules. On top of those low-level modules, is like a package module and a service module which use these low-level modules to give this abstract concept. Package management is this abstract concept where it’s doing lots of different things and it has to account for tons of different things so the package module encapsulates that. If you want to install Redis, you say "modules package" and then you can actually for the install action of the Redis, if you open up, you’ll see the only thing in that script says "package_install".
It just reads all the defaults, like the version and where it was downloaded from and then it follows a default configure-make-install thing. You overwrite whatever you need to, but as long as it’s a standard like Unix type package where it’s extract-configure-make-install, then it just works.
8. Is there going to be a repository of modules?
Actually there is; it’s already out there. There are two things that are going to be: there is currently a master repository of extensions, there are probably 80 or more extensions right now and that’s at https://github.com/sm/ [Editors note: the BDSM project's repositories have moved to https://github.com/sm/ after the interview was recorded ] and that’s the initial step and what’s currently in there. Then, you can also do bdsm-ext-package and then extension name and then publish the extension name and you will be able to push it up just like you do with gem push kind of idea to release. There is an https://extensions.beginrescueend.com/ that I’ve started and you’ll be able to actually socially publish these extensions and share them with everybody else. We can hopefully take a lot of the pain out of the system management and it also helps with debugging. It would take me literally two hours to walk you through it, but you get the idea maybe.
If you install BDSM, make sure you use bdsmdocopen to open the documentation instead of googling. I’ll consider BDSM a success if it becomes the top hit on Google. I’m cleaning up Google! [Editor's note: see https://bdsm.beginrescueend.com/ for up to date resources and documentation of the mentioned commands].