Latest Shows:

 VoV 096: Cordova and Vue with Daniel Purcell —

 RR 447: All About Kafka and Oracle with Bob Quillin and Karthik Gaekwad —

 RRU 096: React Round Up at RxJS Live —

 RNR 151: JavaScript Language Features —

 MRS 102: Elia Schito —

 MJS 133: Jonathan Martin —

 MAS 107: Zama Khan Mohammed —

 JSJ 417: Serverless with Microsoft Azure with Burke Holland —

 iPS 281: Our Builds —

 TFS 350: Course Creation with Christian Lüdemann —

 EMx 086: Teaching Your Team Elixir with Mike Binns —

 .NET 018: Fun and Development with Unit Testing, GraphQL and Firebase Auth —

 DevOps 020: Kui with The IBM Cloud Research Team —

 AiA 273: A Real Look at an Enterprise Application with Juan Stoppa —

 RRU 095: Designing Your Life —

Subscribe
  1. Home
  2. Ruby Rogues
  3. 169 RR Version Managers with Michal Papis, Mislav Maronić and Postmodern Mod III

169 RR Version Managers with Michal Papis, Mislav Maronić and Postmodern Mod III

  • Aug 13th 2014
00:00 6650
Download MP3

00:00 - Introductions

Book Club

Refactoring: Ruby Edition: Ruby Edition (Addison-Wesley Professional Ruby Series) by Jay Fields, Shane Harvie, Martin Fowler, and Kent Beck

Refactoring in Ruby by William C. Wake and Kevin Rutherford

Next Week

Padrino with Dario Cravero and Nathan Esquenazi

Transcript

JAMES:  David will be chasing the cat all over the house.[This episode is sponsored by Rackspace. Are you looking for a place to host your latest creation? Want terrific support, high performance all backed by the largest open source cloud? What if you could try it for free? Try out Rackspace at RubyRogues.com/Rackspace and get a $300 credit over six months. That’s $50 per month at RubyRogues.com/Rackspace.]**[This episode is sponsored by Codeship.io. Don’t you wish you could simply deploy your code every time your tests pass? Wouldn’t it be nice if it were tied into a nice continuous integration system? That’s Codeship. They run your code. If all your tests pass, they deploy your code automatically. For fuss-free continuous delivery, check them out at Codeship.io, continuous delivery made simple.]**[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco, New York, and L.A. bid on Ruby developers, providing them with salary and equity upfront. The average Ruby developer gets an average of 5 to 15 introductory offers and an average salary offer of $130,000 a year. Users can either accept an offer and go right into interviewing with the company or deny them without any continuing obligations. It’s totally free for users. And when you’re hired, they also give you a $2,000 signing bonus as a thank you for using them. But if you use the Ruby Rogues link, you’ll get a $4,000 bonus instead. Finally, if you’re not looking for a job and know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept a job. Go sign up at Hired.com/RubyRoguesPodcast.]**[Snap is a hosted CI and continuous delivery services that is simple and intuitive. Snap’s deployment pipelines deliver fast feedback and can push healthy builds to multiple environments automatically or on demand. Snap integrates deeply with GitHub and has great support for different languages, data stores, and testing frameworks. Snap deploys your application to cloud services like Heroku, Digital Ocean, AWS, and many more. Try Snap for free. Sign up at SnapCI.com/RubyRogues.] **CHUCK:  Hey everybody and welcome to episode 169 of the Ruby Rogues Podcast. This week on our panel, we have David Brady. DAVID:  Who has mute button problems. CHUCK:  James Edward Gray. JAMES:  Does episode 169 mean that we have 169 guests today? CHUCK:  Just about. Avdi Grimm. AVDI:  Hello from Pennsylvania. CHUCK:  Saron Yitbarek. SARON:  Hey, everybody. CHUCK:  I’m Charles Max Wood from DevChat.TV. And we have a few special guests this week. We have Postmodern. POSTMODERN:  I have not seen the movie ‘The Room’ nor will I probably in the near future. But I can quote 50% of it, mostly from YouTube channel videos and memes. CHUCK:  We have Mislav Marohnić. MISLAV:  Hello from B.C., Canada. CHUCK:  And we have Michal Papis. MICHAL:  Hello from Poland. CHUCK:  So, we’re talking about the… JAMES:  Wait, I want to hear Postmodern quote 50% of the movie ‘The Broom’. I’m waiting. POSTMODERN:  I mean, it’s ‘The Room’. JAMES:  Oh, room, sorry. POSTMODERN:  See there’s, “Lisa, you’re tearing me apart.” AVDI:  Oh, hi… POSTMODERN:  “Oh hey, Mike.” [Laughter] AVDI:  Oh hey, Postmodern. [Laughter] POSTMODERN:  Nice doggy. AVDI:  [Laughs] JAMES:  Awesome. Okay, sorry. You may continue. CHUCK:  [Laughs] Thanks. Glad I got permission. JAMES:  [Chuckles] CHUCK:  So, we brought on all these guests because there are different options for managing your Ruby versions. There’s RVM, chruby, and I should have done my homework, because I don’t remember the other one that we’re representing. JAMES:  rbenv. DAVID:  Rbenv. CHUCK:  Rbenv. That’s right. DAVID:  So, we know which guest now feels like he’s further down on the totem pole. [Laughter] DAVID:  I kind of feel like we need to show some extra courtesy here. [Laughs] CHUCK:  Yeah. JAMES:  There’s also compiling by hand. CHUCK:  That’s true. DAVID:  And that guest was not invited today. [Laughter] POSTMODERN:  There is actually a person in the Ruby IRC channel on freenode who always advocates compiling by hands. CHUCK: Oh, really? DAVID:  That’s not Roger Pack, is it? POSTMODERN:  It’s Chevy. I believe that’s his handle. CHUCK:  And then Ford jumps all over him. [Chuckles] AVDI:  I always advocate running the compiler individually on each file rather than the… DAVID:  Makefile stuff. AVDI:  Makefile. JAMES:  Safer that way. AVDI:  Your industrialized making. POSTMODERN:  Who knows what they’re really doing? CHUCK:  Yeah, no kidding. AVDI:  Yeah. I try to grass-feed my files. POSTMODERN:  Yeah, that’s after you compile Linux from scratch. JAMES:  Right. DAVID:  [Chuckles] CHUCK:  Yeah. DAVID:  Well, obviously. [Chuckles] CHUCK:  Then you compile your compiler. POSTMODERN:  Well, [inaudible] bootstrap it. DAVID:  So, welcome to today’s episode on how to mismanage your Ruby. [Laughter] CHUCK:  So, one thing I think is interesting is that when I got started in Ruby, eons and eons ago, it seemed like everybody was basically on version 1.8.6 or 1.8.7 and you just upgraded and it wasn’t a big deal. It really didn’t become an issue until we started getting different distributions like, boy now I can’t even think of those. We have JRuby and we have Rubinius. MICHAL:  Rubinius, MagLev, MacRuby, Topaz, a few of them. CHUCK:  And then on top of that, we got into the different versions: 1.9.1, 1.9.2, 1.9.3, 2.0. AVDI:  And also patches like Enterprise Ruby, whatever it’s called. MISLAV:  And also, [inaudible] the Falcon patches, the performance patches. AVDI:  Yeah. CHUCK:  And REE, Ruby Enterprise Edition. And I remember the first foray into this was RVM. And Wayne Seguin wrote it and basically supported it on his own. I thought he was kind of crazy, [chuckles] all the time he was putting in on it. And it’s interesting how this has all evolved into this ecosystem now. Do you guys want to briefly introduce the solution that you’re here to talk about and why its approach is different or what scenarios it best fits? AVDI: Well, can we back up? CHUCK:  Yeah. AVDI: Before we do that, can we just, can somebody talk really briefly about what is the broad problem these tools solve? JAMES:  That’s a great idea. POSTMODERN:  I just want to mention something that wasn’t mentioned historically, is that the other reason for these tools is we’ve historically had problems with our environments. And these tools have met the needs of, for instance, installing additional libraries, working around weird platform-specific bugs. RVM is, that was one of the main things that Wayne originally mentioned, was he needed to install some bleeding edge version at the time on CentOS, which is really kind of impossible. CHUCK:  That’s true, especially if you were consulting or switching from one project to another where the requirements were just a little different. POSTMODERN:  Right. DAVID:  Oh, yeah. Yeah, freelancing. AVDI:  Is it fair to say that these tools all basically address a developer problem? If I wanted to just distribute a command line application to a bunch if machines to non-developers, I would probably just write it to the Ruby 1.9.2 API and that’s what you can find on Ubuntu and that’s what you can find on Macs and I wouldn’t worry about any of this. DAVID:  Or even just package Ruby itself. AVDI:  Right. DAVID:  And make a giant binary package. AVDI:  Is it fair to say this about the problem of being a developer in Ruby and needing to switch back and forth between different versions for different applications or even try on application on many versions? MICHAL:  We have a few problems. There is the one problem of switching, which [every of these] solves. And the other problem is you need to get a version and Ruby is moving quite fast, and none of the distributions are able to catch up with Ruby. So, every time you want to install Ruby and you think of the package manager, you get a very old version. CHUCK:  That’s very true. JAMES:  That’s a good point. MICHAL:  Maybe not old, buy yeah, not very, but it’s old. JAMES:  So, talking about something like apt-get on Debian, I assume, we say that whatever version you grab there may be a little bit behind the curve. And OS X has traditionally been quite behind the curve in its distributions, although Mavericks did pretty good catching up. AVDI:  What does it ship with? JAMES:  Good question. I’ll check. AVDI:  [Chuckles] CHUCK:  So, one thing that’s interesting about that is that a lot of these versions of Linux, they start working on them a year or two in advance. And so, they just lock in whatever the current version is then. And so, by the time they release, that’s why they’re out of date. They’ve built the packages way back in the day. POSTMODERN:  Also, it’s because you’re probably using a long-term supported version, the LTS version of Ubuntu on EC2. And so, that’s the version of Linux that people know most. And that’s just, oh, they’re always behind. But of course if you’re using something like Fedora, Gentoo, Arch, any of the other distros that are always trying to keep up to date, or OpenSUSE I think is another one, they do a pretty decent job at least staying up to date with the most stable version. So, you’re not going to get the latest version that was released yesterday, but you’re going to get one that was released probably within the year. And so, it’s guaranteed to work. CHUCK:  That’s true. JAMES:  Mavericks ships with 2.0.0 patch 451. It is obviously two minor versions behind now. But I believe it was actually current when Mavericks shipped or really close to it. AVDI:  And it’s also worth considering that the packagers for a given Linux distribution, they face a very different problem than we do as developers because they have packages that depend on those Ruby packages. They have Ruby applications that are packaged that then depend on those Ruby VMs. And so, they have to ensure that they don’t break those dependencies that they’re also shipping. So, it’s a different kind of problem entirely. JAMES:  Right. Thus the big split when 1.9 hit and was pretty drastically different in a lot of ways. A lot of package managers split that into a separate version. AVDI:  Right. MISLAV:  On systems like Ubuntu, if you install the Ruby package, that would be not even close to having a working development environment for developing something with Rails. You would have to install at least five or six optional packages. I remember that from the times I was working on Ubuntu as well. AVDI:  Right. MISLAV:  So, using a version manager to install Ruby would ensure that you have actually a complete development environment, rather than having something that’s only good for maybe running command line scripts but not being able to parse YAML or make an HTTPS request, things like that. AVDI:  It’s similar to installing Java. You can install a JRE or you can install a JDK if you’re a developer. POSTMODERN:  There is the Ruby-full package, which I think install most everything. But that’s because Debian has this history of splitting everything into little teeny packages. They were doing micro-packages before it was cool. JAMES:  There have been a lot of debates on the value of that, and we probably don’t need to get into it here. But it’s weird, because then you can’t rely on parts of the standard library, which is a little strange. AVDI:  So, I guess the point is as developers, we need more recent versions, we need multiple versions, we need to be able to switch back and forth easily, and we need to be able to install them easily and have them coexist. POSTMODERN:  Right. But there’s also the other aspect where people use tools like RVM or Rbenv in production, because they feel that they need the most recent version in production and their system package manager doesn’t provide it or they don’t have packages available. And so, the developer mindset bleeds into production, as we see them as similar environments. AVDI: It’s always nice to be developing on the same thing that’s in production. CHUCK:  Yeah, I have to admit, I generally just compile Ruby on my server and then just target whatever version I compiled on there. And then I just update it periodically when I feel like I need to. DAVID:  I’ve seen the reverse as well, where a sys admin will use RVM to lock Ruby to a known good version and just let it get older and older, even if the system Ruby updates. So, it’s just another use case though, of production wants to control their version as well. MICHAL:  There is another problem of control to migrations. When you install just one version in the user directory, then you have no option to go back if you upgrade. JAMES:  That’s it. Excellent point. MICHAL:  You have to install the new Ruby. And as much as it’s easy, if you use one server, that’s problematic. You should use a separate directory to be sure you can get back to your working version. POSTMODERN:  Yeah, you can’t downgrade packages. But yeah, technically, most of the distros, what they do is they separate them into version families. And so, you have these awkwardly suffixed Ruby executables based on the version family. Yeah, you can install multiple directories and there are ways about doing that. We can, I’m guessing later in the podcast we’ll talk about Unix file system hierarchy. MISLAV:  I would generally not recommend using any of the RVM and rbenv in production, because eventually every mature production environment ends up being managed by scripts like Puppet or Chef, and having a compiled version of Ruby with patches for performance and garbage collection. So, this convenience of easy install and switching, while it’s great for development, it’s not a convenience I think sys admins need for setting up production environments. But the convenience they need is to be able to compile and log down a project to a single version of Ruby that’s optimized for running this application. And that might not be the canonical version of Ruby. DAVID:  Yeah. MISLAV:  Or the one that is just straight up installed by saying ‘rbenv install this’ or ‘rbenv install that’. But a lot of people don’t really mind having these managers in production. So, I see a lot of people managing their production environments with either RVM or rbenv. And this is going to be [chuckles], one thing this is going to be hard to talk about on the podcast is RVM and rbenv are really similar to pronounce. I don’t usually talk about this stuff out loud. So, right now that I do in this podcast, it’s really interesting that… DAVID:  [Chuckles] MISLAV:  To hear that there’s basically no difference. But what I was saying about production environments, yeah. We get a lot of requests, support requests with people who are trying to set up their production environment, that they’re really struggling with rbenv and setting up path. And I usually tell them, if you don’t know how to set it up, maybe you shouldn’t be setting it up, because if it’s too complex for your environment, then better not do it. Because if you end up with an environment that you don’t understand how it works, that is not a very good place to deploy your production code onto. POSTMODERN:  Right, because all these tools, they all depend on being configured and having certain environments. And in production a lot of the time, the shells are not going to load up these configurations. They’re going to run under different users, or run under empty environments. And these tools add that extra layer that your scripts have to be cognizant of to make sure to load or whatever, or run under the correct shell if it’s an interactive login shell, something like that. And it really is unnecessary for production because I feel like a lot of people have gotten sucked into using these tools over the years. And they forgot that, well yes, you have a development environment, but production environment requires a certain level of administration and a certain amount of systems engineering where you actually craft the environments. And sometimes that might require compiling source code and making a package, configuring files. And we got sucked into using all these automated tools. And to use RVM or rbenv or chruby with these tools, it requires more modules and more plugins and such. AVDI:  It’s worth noting too, that packaged versions of more recent Rubies or patched Rubies have started showing up. You can find Ubuntu PPAs for very recent versions of Ruby. Brightbox has a PPA for that, that you can just have your server source from there. POSTMODERN:  Right. And that’s definitely, I think, the way forward, creating specific packages and making sure that they’re trusted. CHUCK:  Yeah. JAMES:  Okay. CHUCK:  So, I do want to get into the nitty-gritty of running my development environment. And just to set the stage, I’ve been using RVM for a long time and I really haven’t felt enough pain to switch. Does that make sense? So, I’m curious as to what the advantages or disadvantages are of these systems and why I should pick on over the other depending on how I work. JAMES:  Maybe we could just go around the horn and each maintainer could mention what they think is the main focus of the given system. AVDI:  Yeah, what’s your philosophy? JAMES:  Yeah. MICHAL:  RVM was started on servers. So, it wasn’t, too, for developers at the start. And it has a lot of stuff that helps you work with your server. Like when you have a problem with setting a queue environment for cron, for iced services. And for every Ruby you install, you get an environment file which automatically loads proper configuration for that Ruby. And it also generates wrappers. This way, you can say in cron, use this wrapper, the direct path, and it will automatically load your Ruby and the proper configuration for Ruby, and the proper application you want to run, the gem you are running. As for development, just for development, RVM, it’s not really a feature that was from the beginning, but RVM has this autolibs feature that automatically, depending on your system, on your versions, configuration, detects your dependencies and installs only what is needed. Like, you have GCC, some version of GCC installed in OS X, then you don’t need to install another version. So, it’s not hard coded, install the newest version. If there is some older version, it’s used. So, there is a lot of code that detects what’s already available. And if it’s possible, don’t install anything else. So, I guess that’s one of the biggest things for RVM. RVM has also, sometimes, issues. And because RVM is really, really big and used by many users, the Ruby people that have problems, as long as the problem is not reported, it could go unseen, because I didn’t have the problem maybe. And the other contributor didn’t have the problem. And some people might say, “Okay, there’s a problem. I will stop using it.” It’s just, I think, it’s a question of reporting it. MISLAV:  Rbenv, [chuckles] as opposed to RVM, was imagined in a way that it will be following the Unix philosophy, relying on executables that were in your path and lets [inaudible] hooking into a person’s shell to intercept calls to commands like ruby, rake, or bundler, or others. And to do that, rbenv operates in a way that it creates shim executables on a special directory that’s added to the path that intercept these calls to any of these commands that you might have, that you might be using in development. And from there on, it figures out what the current version of the Ruby should be for this directory, primarily looking at that ruby-version file, like other Ruby managers do as well. And it dynamically switches the call to this specified Ruby version. So, I guess it sounds a little bit complicated when I’m talking about it. So, I would just summarize what the most important differences are, and what the tradeoffs are. The tradeoff is that rbenv will be slower and will require set up of your path in your environment in different tools that you use. So, in that interactive shell, you need to change path. But if you’re working with Ruby from other programs, you will need to edit path in those as well, like desktop applications. So for instance, TextMate or editors like that. And the tradeoff is that it’s less dependent on an interactive shell, meaning that it can run in an environment where there’s no interactive shell without any problems. But on the other hand, it resolves the current Ruby version on each call to each Ruby executable, which means that on everything that you start on the command line, there’s overhead of picking the Ruby version and switching to that. So then, it’s a tad slower. People don’t seem to mind this. So, it’s not a huge obstacle for people who are picking Ruby version managers. And for me, it was more appealing before I was made maintainer, to use rbenv because I found it simpler and I found it more reassuring that I could just use Bash executables and not having any shell integration that I would have to debug while figuring out why the correct Ruby version wasn’t used, because shell scripts, shell integration in an interactive shell, are usually a little bit tricky to debug because there’s not a lot of tools. At least, I didn’t know enough to debug my current environment and what’s happening in all these shell scripts that will be sourced by other programs and other Ruby version managers. So yeah, following the Unix philosophy and also different from RVM, something that I think we didn’t mention yet, well comparing these three projects, what a fundamental difference between them are, is that neither rbenv or chruby, they don’t handle actual installing of Ruby versions by themselves. So, by themselves, they’re only switchers. And the actual installing is done by means of separate projects. For rbenv, this project called ruby-build. And for chruby, it’s called, ruby-… POSTMODERN:  Oh, ruby-install. MISLAV:  Ruby-install, right? POSTMODERN:  Yeah. MISLAV:  So, typically users of rbenv, they also install ruby-build and typically users of chruby as I think, they typically install the ruby-install project. So, these projects go in tandem. But they’re developed separately. They’re released separately. And this is both a positive and a negative thing. Positive is that they can be released separately. They track each other’s issues. They solve separate problems, so there is this separation of concerns and responsibility. And as developers, we like this. Users though, they often get confused. Where is the boundary between these projects? So, especially for rbenv, they report bugs about compilation of Ruby in the rbenv project because they think they’re just using one project. And that’s completely understandable. I would think so as well. When using software, you’re not aware of its internals. But on the other hand, as a maintainer, I appreciated these concerns are separate. And I also appreciate that I can choose to not use ruby-build, or I can use any alternative project, or even Chef scripts, even in my development environment to install Ruby. So, I can use a combination of Ruby version switcher with another style of installing the Ruby versions, another style of compiling Ruby versions on my system. And that will be the short overview of rbenv. POSTMODERN:  Alright. So, I think I’ll go next here. So, chruby or yeah, that’s what I’d like to call it pretty much. You can pronounce it however. But yeah, it’s patterned after the concept of creating very small and very simple Unix utilities. And it’s a path-based switcher. So, it modifies the path environment variable primarily to provide access to the bin directory of your Ruby. And it also adds some additional paths to the path variable. For instance, for RubyGems, so you have access to all the Ruby gems of that Ruby. Let’s see, and going through the features… AVDI:  And by that do you mean the binary directory? POSTMODERN:  Yes. AVDI:  Well not binary, but the directory of Ruby gems executables? POSTMODERN:  Yes. AVDI:  Okay. POSTMODERN:  And I’ll go more into that. But anyway, chruby, its philosophy is it’s minimalist. A lot of people throw around the words simplicity and complexity. I think minimalism, from the art term, makes a lot of sense here. It’s minimalist in functionality and also size. The [inaudible] two files. So, you can choose to load one of the two files. Oh, I should also point out that a lot of these, for instance RVM and some of the other switchers and managers, they use this weird trick and I think also rbenv does it as well, where the actual majority logic is in another Bash script and they load in a minimal amount of shell script that basically just calls out to that Bash script for certain needs and that evals the output of the script into the shell. And I felt that that was a little bit too much misdirection. And so, chruby literally just stores it into your shell configuration. So, it loads directly in and can modify environment variables as it pleases, because it’s basically just shell functions. But the main file, chruby.sh is 99 lines of code. And then the other file, auto.sh which handles auto loading so you can choose not to load that if you don’t want it, for instance in a server environment, is 31 lines of code. It runs on Bash and Zsh. It supports those. It’s heavily unit-tested. That was one of the main things that a lot of people typically choose not to do when they’re getting into Bash because they think, they feel, “Oh, it’s just so simple. You don’t need to write tests. What could go wrong?” But yeah, so it modifies a couple of environment variables, primarily path. It also detects the correct gem directories and adds those as well to path, the bin directories of the Ruby gems. Of course RubyGems since, was it 1.9.1 or 1.9.0, has been embedded into Ruby, so there are actually two technical gem directories: the one that’s actually built into Ruby that ships with certain default gems, and then there’s the user directory in your home directory, .gem. And it also sets GEM_HOME and GEM_PATH, which are used to look up gem directories. And it sets GEM_HOME for regular users to your gem directory, because a lot of people prefer to install gems without sudo and it also compartmentalizes it for a version. So, you can have your 1.8 gems separate from 1.9 gems and so on, and also your JRuby gems separate from your MRI gems. Let’s see. It also detects the Ruby engine, the Ruby version, and some other environment variables and it exports those. It’s very simple. And it also supports fuzzy matching. It also doesn’t care where your Rubies are installed. You can basically just add the paths to the RUBIES environment variable and it will use that. It defaults to using the system Ruby because I feel that it should be the de facto go-to Ruby. If it’s broken, you should probably file a bug with your distro or OS vendor and get it fixed or get it updated. Yeah, it also supports auto-switching like I’ve mentioned, which auto-detects .ruby-version files, which I think we now, most all switchers have standardized on, which basically just contains a string. And that is dependent on how the switcher wants to handle that. Again, chruby supports fuzzy matching, so you can literally just put 1.9 in there, or 2.0, or JRuby, or whatever, and it’ll just attempt to match it against the names of the Rubies that it knows. And auto-switching is actually pretty fast. We were worried initially that there would be some sort of performance degradations, because we had to resort to some clever tricks, because as it turns out, not all shells are so nice. On Zsh, it uses preexec functions, which is a set of hooks you can add that will run before every command. And we basically just have a simple command that scans the directories for any .ruby-version file. And if it detects it, it’ll set some environment variables. So, it doesn’t have to redetect it every time you run a command. And it can detect that, “Oh, we’re already using that version file. We’ve already switched that Ruby. We don’t need to do it again.” Bash uses trap debug, which is another kind of hook for running before every command. Yeah, so that works out pretty well. That was one of the main things that were requested by people. They really wanted that auto-switching that they’ve grown used to from RVM. So, we eventually hashed out the behavior and how it should work. I was actually very hesitant to add it. The philosophy, keeping with the minimalist philosophy is, do we really need these features or have we just grown used to using them? For instance, using a Ruby manager or switcher in production, that’s the kind of thing I feel we don’t really need this. Another thing we have actually been really hesitant on adding is gemsets. I actually am working on a separate script that you load in that would provide lots of functionality and features for managing and manipulating your GEM_PATH, which I think is a lot better solution than having these gemsets that are rooted in your .gem file in your home directory. CHUCK:  I’d like to talk about some of these features. JAMES:  Yeah, I would too. Especially, how about gemsets since they were just brought up? I'll explain what I know about them, and feel free to correct me. So, I believe the feature came from RVM, Ruby Version Manager, where… POSTMODERN:  Rivim. JAMES:  Rivim, yeah obviously. [Chuckles] JAMES:  I think that it had the initial feature of gemsets. And the idea there was you can use all of these to switch Ruby. So, you can say, I want to use Ruby 1.9 or I want to use Ruby 2.0 or whatever. But in RVM, you can say, I want to use Ruby 2.0 with gemset my-crazy-project. And the idea then is you get basically a clean set of gems that only has the gems from that particular project. And so, when this came out, it was almost needed, because… CHUCK:  It was a lifesaver. JAMES:  Yeah, because at the time, resolving dependencies in Ruby was unbelievable. It was horrible. You’d pull down some Rails application and then spend a day trying to get it to run because it needed this exact set of certain gems. And if you had another one in there that was of a newer version of whatever, it would grab that one instead, which then would miss some dependency of some other thing and chaos ensued. But you get these compartmentalized gem repositories, kind of, that just apply to specific projects or specific use cases, or whatever. The downside of something like that is then you end up with lots of duplication. You may have a specific gem installed multiple times, I assume. Maybe I don’t have that right, but we’ll see. And then in my opinion, when we got Bundler, and particularly when Bundler became pretty usable and universal, Bundler solves that problem in that when Bundler loads, it will resolve the dependencies and make sure that it locks to the right gems, no matter what gems are installed on the system. So, even though there may be a newer one, it will make sure that gem does not get loaded and you get the version that you need to satisfy all the dependencies. So, my opinion is that with Bundler, I don’t feel that need for gemsets anymore. So now, I find that they annoy me, that they provide that other layer of managing something that I don’t want to be there anymore, because Bundler is taking care of that and I don’t have to worry about that anymore. CHUCK:  Can I pile on that just real quick? JAMES:  Sure. CHUCK:  Because the only thing that’s worse than having a gemset set up for a project anymore, in my opinion, is having it automatically set in your ruby-version or rvmrc or whatever. Because then it totally switches you to a completely different context. And with most of these tools, when you auto, you go into a directory and it changes, automatically your Ruby version for you, it doesn’t change it back when you leave. And so, I’ve been in a situation where I temporarily moved over to another part of a project that had its own gemset and then moved back to another project that didn’t have that set. And it totally messed things up. And I wound up installing gems into the gemset that I didn’t need because I was in a different project and had it all act weird. And so yeah, relying on Bundler actually saves me pain as opposed to using gemsets. MICHAL:  Don’t forget the fast CPUs, because the problem we needed gemsets for was many years ago. And our processors were four or even eight times slower. I don’t know, maybe 16. We can get the number. But right at the beginning, it would talk a lot of time to resolve the gem dependencies. And right now, we have really fast CPUs that can do that resolving a lot faster. AVDI:  I think that’s been optimized a bit as well. POSTMODERN:  Yeah. Yeah, the RubyGems developers have done a good job of optimizing the version picking strategy. It was a major pain point in the past where I was developing on really large projects and trying to run some sort of executable from them and installed my main set of gems. It was like, “Wow, why is it taking forever, literally at least a minute to load?” And it turns out if you have lots of versions installed, or if low-level gems that pretty much every other gem depends on for instance RSpec or Rake, that will actually slow down the version picking strategy because it has to map out this whole version tree. And they actually did a pretty good job of optimizing that. And you can actually speed it up by going through and running ‘gem clean’ or ‘gem prune’, I forget. But you can basically uninstall all the older versions that built up after running gem update multiple times. It actually does speed things up. But also, I really dislike about gemsets, and this is a good example of how these features get started and really, no one questions them. For instance, how all these projects are always naming their configuration files something-file. And originally, that was because Rake named rakefiles after makefiles. They were kind of copying make, tongue-in-cheek thing. But then now we have gemfiles and… DAVID:  Guardfiles. POSTMODERN:  Guardfiles, procfiles. JAMES:  Procfile. POSTMODERN:  And no one really stops them. Why are we naming a file, file? JAMES:  All in the root directory, with no extensions. POSTMODERN:  Right. JAMES:  Your text editor loves is. POSTMODERN:  Right, exactly. AVDI:  If Josh Susser is listening to this, he’s punching the air right now. [Laughter] POSTMODERN:  But yeah, and one of the things that’s always struck me about gemsets, because usually when I need some sort of functionality of isolating gems, it’s usually to isolate them to a specific directory so they don’t pollute my main gem source, is let’s say… Because we’re so obsessed about test-driven development, I find something that annoys me in a really big project, let’s say Padrino, and I have to pull down all these repos. And then I have to run bundle-install and I have to make sure. I have to use bundle-install, either tell it to stuff everything in vendor gems and then you use bundle-exec or I have to somehow isolate the gems. But really, why do the gemsets have to be in your home .gem and then have a name? Why not just put the gems in that project directory? Because then when you’re done with the project, you just ‘rm rf’ it, and boom, it’s done. It’s cleaned up. And so, that was the one thing that annoyed me about the serve assumption, that this is how gemsets have to be implemented. DAVID:  Yeah. So, I’ll be that guy. Can I be that guy? [Laughs] CHUCK:  I was going to say, is anyone going to speak up for gemsets? DAVID:  Not only am I going to speak up for gemsets, but I’m going to speak up for Bundler and gemsets together. They’re two great tastes that do not taste bad when mixed together. James actually challenged me to give up my gemsets. And he and I worked on a project for a while where there were 50 different projects. And having gemsets for each one literally meant that checking out the projects, if you’re using gemsets, that’s going to take 1500 hours to build everything and duplicate everything. And I totally got it. I could totally see it. But when you do a bundle-exec any gems that you have that you like that you use for your development but do not necessarily go in the project, and they exist if we’re developers and we’re writing our own tools and we’re crafting our own IRB customizers like I do, I have quite a few of these. And if you do a bundle-exec, those gems are gone. They are inaccessible to you. I love being able to put gems in my global RVM gemset. And then they don’t get pushed up to the project as part of the gemfile. And I can still get to them from IRB when I’m debugging and when I’m developing. I do totally agree with all the issues that have been raised about Bundler and gemsets, like when you change out of a directory and the gemset follows you like a lost puppy. That’s a bad thing. The thing that I do like about the difference between Bundler and gemsets, or specifically between bundle-exec and gemsets is that it seems to me like Bundler is a dynamic way of loading your gems and deferring the version managing to the last possible moment, where gemsets is like statically caching them. And I think it was Postmodern that just mentioned a minute ago about why not just bundle the gems into the project yourself? And with the exception of size constraints, I think that might actually be an agreeable workaround solution. POSTMODERN:  Yeah, especially if you’re just only working, if you’re only trying to do a one-line change to a project and then run tests and do a pull request. Also, allow be to blow your mind. CHUCK:  [Laughs] POSTMODERN:  So, gemsets all they’re doing is changing GEM_HOME and also appending something to GEM_PATH, which GEM_PATH is like path except it’s for directories to look up gems within. So, you can actually have multiple, you can stack the directories up in GEM_PATH. And so, I was actually starting just a thought experiment. I was running a small script that would allow you to basically push and pop directories onto GEM_PATH and then set GEM_HOME accordingly. And it’s still a work in progress, but it’s called gem_path. And I feel like that would be maybe a tool that people might want to use or that would be a philosophy instead of having locked into this rigid way of thinking about gemsets, where they have to exist in this directory, they have to be used in this sort of way. We could just expose these variables and have something that would allow us to manipulate however we want, whether it’s wanting to put a directory on the front of GEM_PATH so it takes precedence over everything, or put it on the end so it basically just, what’s the word I’m looking for, unions the gems into the existing gem hierarchy. MICHAL:  There is one problem with it, because RubyGems stores the gems by version, not by the GEM_PATH order. So, in Python, in Java, everywhere else, libraries are sorted by the path you give to the language. And in Ruby, we are exceptional. We have sorting by version. And you cannot say, take gems of my project directory to the front. You cannot say this because the gem with the newest version will be up front. CHUCK:  One other little trick for the executables is if you install with Bundler and you use the bin stubs option, and then you modify your path so that it looks in ./bin first, you can get around some of this. Now, it only then works if you’re in the root of your project directory. But most of the time, I am when I’m trying to run those executables. DAVID:  Yeah, and every sys admin right now is listening to this advice to put . or ./bin in the path. CHUCK:  Yeah, and they’re crying. DAVID:  And they are vomiting up their chmod 5. POSTMODERN:  Yeah. Do not do that. DAVID:  Yeah. They’re setting -x on everything you own right now. [Chuckles] JAMES:  It doesn’t have to be an all or nothing thing. I write shell functions for things I commonly do, like rls to start a Rails server. And I have that function do a couple of things like see if there’s a bin directory in the current directory. If there is and there’s Rails in there, let’s do bin/rails. Or if there’s not, let’s do whatever and work our way down. So, that’s a lot safer than just modifying your path or something. CHUCK:  Yeah. And I just want to put a caveat on the ./bin thing. I have it on my development machine. I don’t put it on the server because that’s crazy. And I really do like the approach of being able to just run rake in the root of my project and not… POSTMODERN:  Here’s another interesting question. Why are we locking down the versions of basically development claw utilities? Because that’s one of the things I started thinking about was why are we specifying a specific version that always is going to differ from the current version that’s installed globally? Why not just put ‘gem rake’ in the gemfile and it will always use whatever the latest version is? DAVID:  Going back to my point about putting, about having things that I didn’t want pushed up into the project, I have probably five to ten different little fiddly gems that I use on IRB that are like, do you remember Hirb and Wirble, things that would colorize stuff and make text tables… JAMES:  Yeah. DAVID:  And that sort of stuff? I’ve got awesome_print. I think everybody’s got awesome_print. But I’ve got a little thing that I wrote called Vertable. And it’s just a gem that I wrote that makes vertical tables. That’s all it does. It makes text tables, but it sorts them vertically. And nobody else uses this. I’m the only user of this gem. I wrote it, it works for me, and I’m done. And I really needed it to debug a project. I finally ended up switching to the Looksee gem which is awesome. If you’re not using Looksee, you should be. But Vertable and Looksee work a little bit differently. And I was comfortable pushing Looksee up into the development group of the gemfile. But I was really uncomfortable pushing Vertable up because it’s my own private hack gem. And any maintainer taking on the project later has got to get the Vertable gem and go, “What the hell is this? Why is this in my project?” JAMES:  So, I feel compelled to point something out about RVM, since we’ve been kind of harsh on gemsets. You do not have to use gemsets with RVM. I think they’re on by default. DAVID:  Right. JAMES:  But there is an option to totally shut them off, just ignore them. So, I’ll link to that in the show notes and you can just turn them off if you don’t want to use them. So, I think that’s cool. That makes me happy. So, can I bring up another difference that I’ve run into lately between the systems? DAVID:  Sure. CHUCK:  Yeah. JAMES:  I used RVM for a long time and then more recently I’ve used chruby, which I think I usually called chruby, because that’s just how I say it. One of the differences I’ve noticed is how they go about installing. And I guess I should be specific here, chruby does not do installing. I use ruby-install, which is the companion project Mislav talked about earlier. And the differences in the way they install can be significant. It’s my opinion that RVM goes to great lengths to try to install whatever you say, doing however it should do it for your system. So, it has a recipe in its head for how it should install Ruby 2.1.2 on a Mavericks OS X system. And it goes through these steps and it makes it happen, including the correct little fiddly bit gotchas that you’re bound to run into when you’re compiling it by hand and you end up googling the error message and find out, “Oh, in Mavericks they do this, so you have to do this,” kind of thing. Whereas chruby is more minimalist, like Postmodern said. Therefore, it’s just, hey, it downloads it and compiles it for you. That’s what it does. So, one of the things that I ran into recently as I was using chruby on a very recent Ubuntu, I think, Ubuntu 14 before the core team got Ruby set for a difference readline that was the default on, in libreadline, that was the default on that distro. And so, I tried to compile Ruby with chruby and it just died with a crazy error. And I had to do some searching around, just like I would have if I was compiling it by hand. What’s this error message mean? Oh, there’s a problem with the libreadline version you have. It’s already fixed in ruby-trunk. So, I had to go find that commit, or commits really, and get the patch. And chruby will let you patch Ruby as it’s built. Or ruby-install, I should be more specific. Ruby-install will let you patch Ruby as it’s built. It has a switch where you can give the patch and then have that patch put in and it will do it. But I had to do that myself. I had to find that patch. I had to get it there, and I had that switch to get it to do that, and then it would build Ruby. And they did fix Ruby very soon after this problem. But I was compiling just right on the edge of the curve and I ran into that bug. I think those kinds of problems are pretty rare in RVM because somebody runs into them, then they fix RVM to patch it for you and do whatever it needs to do. And when it runs into that system, it just knows what to do to install it and it does it. So, I don’t remember having those problems. POSTMODERN:  And I think I should also bring up the important point that pretty much all of us agree with. It’s important that we fix these problems upstream. And a lot of the times, Ruby core will drag their feet because they have this complex release engineering process when they push out a new version. And in between that time, we have to then handle all these bug reports coming in like, “Ugh, the Ruby’s not compiling. It must be your tool that’s broken.” And we have to constantly forward people to the upstream bug report. And it would be just nicer if we had a more streamlined process where we can actually fix these problems at the root cause. I’m trying to think of also, what is it, issues with compiling against older open SSL, which that was I think before Mavericks came out, that Apple was shipping this extremely old version and MRI started requiring a newer one. And so, I feel like that, if we were able to actually get Apple to upgrade that quicker, it would reduce a lot of the complexity and a lot of the need for these tools to manage these things for you. MICHAL:  The problem is asking MRI or any distribution to upgrade something. It takes time. They have this long-time support idea for systems, like OS X or Ubuntu LTS. And they cannot just put something in the system. You probably have to use either patch, because you are using a too new compilation system, or you would have to get a head version of Ruby, which is in both ways complicated. JAMES:  Yeah. I think I agree that obviously the ideal thing is for the fix to happen upstream, because we don’t want people to run into it again ever, and that would be great. But the speed that developers move is exponentially faster than the speed that MRI moves, which is exponentially faster than the speed that Apple moves, I think. CHUCK:  Well, I think a lot of that comes down to the number of use cases you’re dealing with. I as a developer run into a specific number of use cases. Ruby has to handle everybody in the Ruby community’s use cases. Apple has to handle all of the stuff that’s going to run on their platform. And so, yeah there’s a lot to know. MISLAV:  I think that this is an interesting topic for me, especially lately. The patches and the ability to install Rubies on different systems, especially newer versions of systems with newer versions of dependencies such as OpenSSL, libreadline, and others, we had a lot of bug reports in ruby-build about Rubies not being able to compile. And especially not in most recent versions, patched recents of Ruby but the previous ones like 2.1.1 or versions like that. And people report to us bugs which are almost always bugs with Ruby’s incompatibility with system dependencies, and that is fixed upstream. And ruby-build had this philosophy of no patches, so different from RVM. We had the philosophy of we are not going to apply any patches for you. And that gives you the security of this Ruby version will be unchanged, un-tweaked, and you are in control completely, the Ruby version and what happens to it. We will just run the compile process for you and that’s it. But lately, I’ve been starting to think that we should be back-porting some patches like RVM does, because our users have a pretty bad experience lately on a variety of systems. On FreeBSD there are some problems unique to it, on Fedora there are some problems unique to it, on newer versions of Ubuntu, and then on newer versions of Mac OS. So, because these bugs are user-facing bugs, they are a problem of Ruby. But since people do need to install sometimes older versions of Ruby, and I’m not even speaking 1.8.7 or anything like that, I’m speaking about 1.9.3 or 2.1.1, I would really like to include some patches in ruby-build in the next iteration of the project, because just to reduce the number of bug reports and just to improve people’s experience. So, in this way, I wanted to propose to Sam Stephenson [inaudible] I’m waiting for his reply, that we quit this philosophy of patch-free just because our users are not having a great time lately installing Ruby, installing older versions of Rubies, because of these cross-platform differences. And I think I find that that’s okay because priorities change and perspectives change. When ruby-build started out it wanted to be different and it wanted to just handle something in a simple way. But as it grew older and more mature and more adopted and adopted in a more variety of systems, we just realized that user-friendliness and the easiness of install is more important than philosophical correctness, than following a certain principle. So, I’m really hoping that we can iron out some of these issues in the next release. And I’m not sure if ruby-install applies any patches. Postmodern, do you have any insight with that? POSTMODERN:  The buck stops here. DAVID:  [Chuckles] POSTMODERN:  We do not apply any patches. You can apply patches yourself if need be. But no, in the past we actually did apply one specific patch to get around a weird issue with how one of these scripts generates some C code for I believe the dl library for the 1.8 series: 1.8.8, 1.8.7. And we eventually then dropped that patch to streamline things, because we were applying this third-party patch and we’re not really sure if it’s going to continue working in the future. There are issues with various Ruby versions requiring specific version ranges of GCC. And so, basically we just dropped support for the patch. And I incorrectly stated that we dropped support for 1.8.7. We’re really just removing these hacks to make it easier. And so, we’re pretty much moving that kind of responsibility onto the user where if you really want to compile a known broken version of Ruby that needs a specific version of OpenSSL, a specific version of GCC, if you really, you have to go back, going against the flow of development and use this older version specifically and compile it from scratch, you have to set up environment yourself and specify the CC environment variable for which compiler do you use and what additional patches to apply. Because yeah, I’m just a little bit, it’s a little bit nerve-wracking to think like, “Well, we are applying this patch to make it easier and to make sure it compiles. But what if it breaks?” Whose responsibility is it? Suddenly, it’s my responsibility, because I’m breaking people’s Rubies, or if it introduces some sort of bizarre regression. Yeah, and also I think we do tend as developers, I notice in the Ruby community, we get stuck on versions where if something’s already fixed in a previous version, why not upgrade? Check the change log. Probably it’s not that significant an upgrade. No new features were introduced. MICHAL:  Mislav, I have a question for Mislav. I was thinking about extracting patches to a separate repository. Mislav, we probably should talk about it because RVM already has a lot of dispatches. And maybe we could use one repository so we don’t duplicate the effort to get something working. And yeah, I think that could be a great idea. MISLAV:  Yeah. That is an interesting idea. I was always looking at the patch sets of RVM, the patch sets I mean, just the whole bunch of patches, that they’re embedded in the project, that are vendored in the project. So, I was always a little bit intimidated because I didn’t know what most of these were. But I guess some of the patches in the project are of different importance. Some are performance leaks, right, and some are patches that are really needed to compile on a certain system. But I definitely think, I don’t want to be reinventing the wheel and figuring out everything from scratch if it’s already been figured out. So definitely, there are all of the ready patches from the RVM project. And I know that some people are pulling patches from the RVM project to apply to ruby-build, because it has the option the same as ruby-install. It has the option of applying patches on the command line. Some people are pulling from the RVM repository. So, they either do it from Ruby’s version manager, SVN tracker. Well, not SVN, bug tracker. But some of them are pulling them from RVM. So, because they’re already doing this, I don’t see why not. It’s just that one reason I would like to have them embedded in our project would just be the technical simplicity of when you pull down, when you get the clone, that you would have [inaudible]. MICHAL:  Yeah, of course, of course. I was thinking about the same for RVM. MISLAV:  Yeah. MICHAL:  Yeah. MISLAV:  But we should definitely talk about it, because I… MICHAL:  Yeah, we can use the same repository and just clone it to inside the project. So, it’s duplicated but we can exchange, put new patches in one code that we can synchronize. POSTMODERN:  Can I only request that you compile the patches together per version? Because that’ll make it easier to apply a bundle of patches, instead of individually incrementally applying the patch. MICHAL:  We can add a tool for that. POSTMODERN:  Because that would be kind of nice. It’s one of the main things I’ve run into when people are trying to, for instance apply all of the RVM patches, because they’re just all this individual patches. And it’d be nice if you just had one contiguous compile patch for that version. DAVID:  I feel like we just brokered a peace treaty here. [Laughter] JAMES:  I know, right? DAVID:  This is awesome. JAMES:  Can I ask one more difference… DAVID:  Ruby Rogues diplomacy. JAMES:  One more difference about this, the two different install types. I believe I understand this, but please correct me if I’m wrong. One of the downsides to the RVM approach I think is that basically if I’m using RVM and I want to get the newly minted Ruby, I need to first update RVM so that it knows the new magic formula for the Ruby installing and then do that. Whereas with ruby-install, I don’t update it because it has no idea one version of Ruby from the other. MICHAL:  Actually, RVM does check your version. And if it’s older than the available online version, it will give you a warning and you can set a flag to automatically update. JAMES:  Oh, interesting. So then, it would try to build it just having no special recipe, right? MICHAL:  Yeah. JAMES:  Just using the default strategy. MICHAL:  Yeah. Knowing there is something newer, RVM automatically updates and gets the newer patches. JAMES:  Interesting. POSTMODERN:  I should also point out that, Mislav would probably also mention this, but ruby-build actually has individual recipes per version. And so, this allows ruby-build to respond to per version issues, which is nice. But at the same time, most of these versions are basically the exact same recipe. You just have to copy it over, do a commit, and then you can update the ruby-build plugin that’s usually, I guess, installed directly by cloning Git, or installed from Homebrew, which it’s pretty easy to push a new version out to the Homebrew people. Ruby-build is a little bit different in the fact that it will take arbitrary versions and just attempt to download the file. So, when JRuby 9000 comes out, you can literally type in ruby-install jruby 9000. It will do that. The downside though is, well, currently it does not update the MD5 checksums for all the Rubies. So, you’re going to have to specify that yourself, which isn’t such a big deal because usually when a new version comes out you learn about that by reading the blog posts, which has usually the MD5 checksum right there. And you just copy and paste that to the command line. CHUCK:  So, I wanted to ask another question. Does the dependency and patching conversation change when the dependencies change? So for example, with MRI you’re using GCC because it’s C. Rubinius, it’s probably G++ because it’s C++. If you’re JRuby, you’re talking about JVM and maybe specific versions of the JVM. MagLev requires Gemstone. Topaz requires Python. Do you have to go through different gymnastics for those or is it more or less the same process? MICHAL:  It depends on the tool. [Chuckles] In RVM there is, the actual implementation is for this match in Ruby, for every name, we do something different. It’s not what was planned for autolibs, but it was the only thing that’s quite easy to implement in the shell. And it’s not like you can resolve the dependencies in the shell. You just have access [maximally] to arrays. Hash arrays are quite limited. So, in RVM you have possibility just of in the case of every Ruby, do something else, and for every system, a lot of options. Mislav how is it in ruby-build? MISLAV:  Well, it’s not as complicated as he thinks. For instance, if we’re talking about JRuby, what I wanted to say, it doesn’t have to be as complicated. JRuby for example, to install it, to download and install it you don’t really need to have a Java development environment or anything like that because you’re actually downloading a binary. So, the installation process by itself, it’s usually simple. But it’s the responsibility of the developer for using non-standard, well not standard but non-MRI Ruby implementations, it’s the responsibility of the developer to actually set up their runtime environment for this kind of Ruby implementation. So, the Ruby installation process will just handle fetching of this Ruby implementation. But you’re still in charge of setting up anything else. Because obviously, we’re not going to touch Java on your computer or anything like that for JRuby. So, you’ll have to handle that yourself. And I’m not, apart from Rubinius, I’m not a big user of alternative Ruby implementations. So, I don’t have much experience or much to say about the experience with developing with those. But it seems that whoever are the people who are using those, they seem to be content, because we don’t get a lot of bug reports or complaints that something is not working. So, I think I’m confident that we are for now, we are solving this problem of obtaining the Ruby versions, the Ruby implementations, very well. And we’re leaving it up to the developer to handle the rest of their development environment. And for now, it’s working alright. POSTMODERN:  Yeah, so for ruby-install, we basically, our “recipes” for each kind of implementation, it’s separated into a script that specifies the individual steps to install that Ruby. So, you have a configure step, you have a clean step, you have a compile, you have an install step, and pretty much those are eventually, there’s a call we make with some log messages thrown in there. So, it pretty much depends on the actual build process and script of that Ruby. So, if there’s a problem there, it’s going to crash. You’re going to have to report it upstream. But as far as dependencies go, we basically have dependencies sorted out per package manager. So, we have all the dependencies for instance for Rubinius, and we have them for APT, Yum, Ports, Backports, Brew, and Pacman which is the Arch Linux’s package manager. And so, we just list out all the build and runtime dependencies that are necessary. I am concerned splitting those apart so you can basically only install the runtime as opposed to the build. And for instance, one of the gotchas for JRuby, we do install a JDK. But that is only for APT, Yum, and Pacman. Homebrew, they actually don’t for copyright reasons, they don’t include that. So basically, we just print a message saying, “Go to this URL and download it.” We have had some issues where people wanted very configured and customized environments. For instance, they wanted JRuby but they didn’t want to have X11 installed on their server. They wanted a headless JRuby environment. That meant they couldn’t use all the GUI toolkits that are included with the JDK. So, that was an issue. We also had issues for instance, people complained about, because Rubinius’s build system is implemented in Ruby, this gives them a lot of power and flexibility in detecting things on the system. And they can do a lot more than using autoconf and libtool and automake and a bunch of Bash scripts. But the downside is that it makes MRI a build dependency of Rubinius. And so, some people vehemently wanted to build Rubinius but they didn’t want the Ruby package from the package manager installed in their system, which they could have gone afterwards and just uninstalled. So, I had to draw the line there and basically say, well it’s a build dependency of Rubinius. If you have specific needs, you can always build it by hand. There are compilation instructions on the website. You can literally just copy and paste. And yeah, that generates some hurt feelings. Some people got really angry about that. But that’s the philosophy of ruby-install, is that you run it on an actual system and you don’t have to do anything else. It handles the dependencies. It downloads the files. It does all that. There’s no user interaction unless there are bugs and stuff like that, of course. MICHAL:  Or password. POSTMODERN:  Yeah, yeah. You at least enter and run it under sudo or something like that if you want to install it globally as root. Or you run the package managers to install packages. The other gotcha is because Homebrew installs everything into user local and it symlinks libraries back into the Homebrew, I think they’re called kegs or something, I forget what they’re called, in the cellar. I think that’s what they call it. The autoconf configure scripts do not check user local by default. And so, we actually have to add all this code that specifically passes in all the paths from Homebrew, just for Homebrew. So, we have specific logic just for them, and also MacPorts, to pass in the directory to check for all the libraries. And so, when you install Ruby with ruby-install, it will actually compile against the Homebrew libraries as opposed to your system libraries. MICHAL:  There are some edge cases like on Raspberry Pi, the clock gets time shifted. You get it off after getting it to sleep or shutting it down. So, RVM automatically installs NTP for you and sets it up, because after unpacking Ruby, the time is in the future so you cannot build and there are problems with the build. Or when you work on OS X and the OpenSSL is not [inaudible] package from Apple, so your security certificate for [inaudible], anything from the internet, are either old or not existent. So, RVM automatically syncs them from the Apple certificate store. So, there is always something more to do. And I think that the problem is finding the line. Where is it good to do it all? And sometimes you don’t have to do everything, but if you miss this step, you leave your users vulnerable because most of them don’t know about the lack of certificates in OS X for OpenSSL. POSTMODERN:  Right, and that’s another OS X related issue. And so, we probably need to work better on fixing that at the root cause. MICHAL:  I think Apple is at the verge of dropping OpenSSL at all. I’m not sure if they shipped it in the last three of their systems. But they don’t want to have it. POSTMODERN:  Maybe they’ll switch to Libra SSL. Trololololol. [Laughter] POSTMODERN:  I actually want to throw in a question here. So, what do you guys think about this kind of ongoing push? The thing we’ve been trying to do is get more Ruby implementations to publish actual packages so people don’t have to deal with compiling things with Clang or GCC or the past troubles, you have to install Xcode and all that stuff. Where we can just download a precompiled, trusted binary and install that. I believe Rubinius is moving towards creating a bunch of precompiled binaries and packages, so you can basically just add some sort of repository, install some sort of rpm or deb or just extract a tar.gz. And the last man standing who doesn’t basically provide binary packages is MRI and Ruby core. MICHAL:  I have a ticket for them for it. POSTMODERN:  Yeah, we’ve been trying to convince them. But it seems like a human resource problem where they’re hesitant to take on the challenge and the responsibility of distributing precompiled binaries. And what if they break? But even though there’s the, what is it, the RVM build scripts that automatically will spit out precompiled binaries, there is also recently, I saw a person, we’ll have to add the URL in the show notes later, but who’s basically set up a build process for creating precompiled binaries for rbenv that install into basically, you extract them, they’re like tar.gz’s, into your .rbenv versions directory, if I remember correctly. MICHAL:  [Inaudible] number of binaries for different versions, but only for the Ubuntu version they use. POSTMODERN:  Yeah. MISLAV:  I like the concept of precompiled binaries. I don’t think that the Ruby core team needs to maintain those. I don’t even think that any Ruby implementers, unless they really want to, alternative Ruby implementations, they can maintain the binaries. But if they don’t want to, I think it should be community responsibility to make those precompiled binaries, just as it’s community responsibility to make packages for these different Linux distributions. I like that now precompiled binaries for Ruby are possible trivially. So, we’ve been looking lately, there are open pull requests and issues on ruby-builds issue tracker that we do the support for downloaded precompiled binaries if they’re available. If not, compile it for your current system. So, I guess we’re following in the track of what RVM supports right now. And since I would say 80% of Ruby developers use just a tiny subset of systems, I think that with only a handful of precompiled binaries, we can really go a long way to improving user experience with installing all these Ruby versions and with the stability of the installation process and with the speed. I think the greatest benefit will be speed. So, that’s something we’re looking into right now. POSTMODERN:  Yes. I’ll also mention that a lot of people use the FPM Ruby gem which can generate a variety of different packages, debs, rpm’s, you name it. Actually, you can spit out EXC’s even. I’m not sure, or I might be thinking of another one. But yeah, so it is possible to actually roll your own packages to basically use ruby-build or ruby-install, install into an arbitrary directory, and then package that up. And you now, boom, have a precompiled package you can drop onto servers. I just want to be, wave my finger as someone who works in security. If you are producing binary packages, we definitely want to be able to verify that malware hasn’t been injected into them, or I’m going to install Ruby and all of a sudden I’m going to start spamming out Viagra ads when I run IRB. And so, there’s a whole… CHUCK:  [Laughs] I could totally see that. [Laughs] POSTMODERN:  Right? I know. CHUCK:  IRB. DAVID:  That gives me an idea for a new gem. [Laughter] POSTMODERN:  Yeah. So, there’s a whole thing called deterministic builds. And the Tor project I think was the first one to start touting this as something that was necessary, where you actually have a build process that you can reproduce the binary and prove that byte for byte, nothing was changed. And so, there’s actually a tool for this called Gitian. It’s Git-ian, G-I-T-I-A-N. And it actually uses, it’s distributed as a Ruby gem, which is interesting. But it allows you to basically create a deterministic build script and then you can verify that. And they have an example for building Bitcoin as a deterministic build. And so, that’s an interesting thing. Hopefully, maybe we could explore this. Maybe more people could try using it or at least submit feedback on it. MISLAV:  Isn’t that a bit over-engineered though? Isn’t it enough to verify that a download has been tampered with by just checking the checksum like MD5 or as ruby-build recently switched to SHA checksums? POSTMODERN:  But how do we know that your system isn’t compromised? Or your compiler isn’t compromised? So, you basically need a completely other system that’s independent to verify. CHUCK:  I’d really love to see a blog post or something on this, because I love the idea of binaries. Just pull down a binary that works instead of making me wait until it compiles or whatever. JAMES:  So, it was mentioned, the Raspberry Pi earlier, and I think compiling Ruby on my Raspberry Pi takes around three hours and change. It’s pretty close to four hours, I think. So yeah, a binary’s a big deal then, right? MISLAV:  [Inaudible] reminded that every time your gem installs a gem that you don’t know anything about, you’re executing somebody else’s code on your system. MICHAL:  But in the case of gems, you can go and see the code. You can even fetch the gem and manually install it from the binary you fetch. But in the case of Ruby, you get an executable that’s compiled code. You’d have to be able to read the machine code for your system. POSTMODERN:  And plus, binaries are usually stripped and also optimized so it’s a lot difficult to actually audit them, at least for a laymen like us. MISLAV:  I know this great story about Heroku getting hacked. This was years ago. I guess three years ago, or four years ago. The way that their whole infrastructure got compromised is that somebody wrote a gem and published it on RubyGems that, as a part of its installation process, it opens an SSH tunnel back to the attacker’s machine. So, the gem install will hold indefinitely and it will last a really long while. And during this time, the attacker had SSH access, unlimited SSH access to Heroku’s infrastructure. And they broke out of just one isolated environment and got access to other environments as well. And it was pretty nasty and they were really quick to patch it up. And I don’t know how much of this was published, or if they were official post mortem. But I was talking to some Heroku engineers and I just thought that was a genius way to hack into somebody’s infrastructure, by making a gem like that. So, I’m always amazed by the resourcefulness of hackers and the way they can think outside of the box. JAMES:  That’s a sobering story. CHUCK:  Yeah, no kidding, right? JAMES:  It makes me appreciate how hard what the three of you are all working on really is. So many different environments, so many different combinations, so many different versions of Ruby and implementations. I think one of the things we should probably do is just thank you all for your effort, because you make… DAVID:  Yes. JAMES:  All of our lives considerably easier every day and we don’t have to read the messages reporting all the problems that you do. [Chuckles] I’m sure it’s amazing. POSTMODERN:  Oh yeah. I’ll also like to add on to that, I think I speak for everyone at the round table here that Bash and shell scripting is the worst programming paradigm ever. JAMES:  [Laughs] MICHAL:  Yes. Yes, it’s really bad. POSTMODERN:  The worst. MICHAL:  I’m not sure if it’s the worst, but it’s really bad. AVDI:  It’s pretty bad. [Laughter] POSTMODERN:  It’s all the caveats and edge cases, that’s what really gets you. JAMES:  Avdi, you were… MISLAV:  You have to debug something in shell. JAMES:  Avdi, you write web apps in Bash now, right? AVDI:  Yes, I do. JAMES:  Yeah, cool. POSTMODERN:  Is that the new thing? AVDI:  [Laughs] POSTMODERN:  Are we already moving off Go? [Chuckles] CHUCK:  Bash on Bails? I don’t know. [Laughter] JAMES:  No, please. AVDI:  So, there’s actually something very similar to that that’s a real thing. [Chuckles] JAMES:  That’s amazing. AVDI:  Yeah. It has a slightly rude name. DAVID:  So, the COBOL ON COGS website is still up. JAMES:  [Laughs] POSTMODERN:  I’m more of a fan of Fortran on Fails. CHUCK:  Ah, there you go. So, have we more or less wound down? Is there anything else we need to know that we just didn’t think or know to ask? MISLAV:  I have a question for all of us, and we can take turns answering it. I would ask what’s next for each of these projects. So, what’s next on the roadmap for RVM? I can answer what’s next on the roadmap for rbenv. And I guess chruby is the way it is right now, minimalist. I don’t see it undergoing radical changes. But that might not be true, so I’m interested in each of these maintainers telling their story. So, I would like to start with RVM. MICHAL:  Oh. [Chuckles] Yeah, so RVM has this big plan for RVM 2 which, because I hate shell, will be written in Ruby. And I’ve started working on it. I have moved parts of RVM 1 to Ruby already. And there are a few gems. Some are even used in other Ruby switchers like, what was it, rubygems-bundler, which automatically does bundle-exec for you, because I really had problems with users, “Hey, my erase doesn’t work,” and the error is you are using some wrong version of the gem. So, I wrote this rubygems-bundler which is called in Ruby, which is a gem, which will note proper, will set up bundle-setup for you instead of asking you to run bundle-exec. So, it might be a bit slower in some occasions, but I got, I don’t know, three or four people that were really wanting, that did want to use it. Otherwise, I’m really happy I wrote it because now I don’t have to answer all these questions where these versions don’t match. Everything just works. And I’m moving parts of RVM code that does work after. So, I’m moving code to gems now. Everything that runs after Ruby is installed, because RVM depends on the shell. We don’t have Ruby dependency. I cannot move everything at once to Ruby. But everything that’s run after Ruby is installed, I’m moving to gems. And there are already a few gems in GitHub /rvm. And after I move everything, what’s possible for RVM 1 to gems, I will be moving all the codebase to Ruby with changing the scope a bit. And changing is not enough to say. I will extend the scope so it will be no more just installing Ruby, because Ruby has dependencies like Java for JRuby. And I was having the talk with JRuby maintainers, Tom and Charlie, this [inaudible]. And they want to install JRuby 9000 with RVM. But you need some special sort of Java which implements, I don’t remember the new feature, but there is a new feature which is right now in beta release. So, you need to install this version of Java to make this new JRuby work. And this is quite problematic to make sure everything is properly installed. So, RVM 2 will no more be just for Ruby. It will install everything. And as for version switching, I’m thinking about borrowing parts of the ideas of chruby, because yeah, that’s the small, the minimalistic switcher that’s really… l like this idea. But maybe I will go maybe somewhere between rbenv and chruby where you will get a really small switcher but with some possibilities of extending. I’m still thinking about the ideas for making it really work. But yeah, that’s the plan, to separate everything, to have lots of gems so you can get a gemfile in which you can specify, “I want to install Rubies, Java, and whatever,” and it will be automatically done. The rest will be automatically done for you. MISLAV:  Alright, thank you. I’ll go on, continue on saying about the projects I’m maintaining. So, rbenv I have a plan for it. I already did some code to speed it up a lot, since compared to other projects on the runtime it’s typically slower because of the overhead that could be 50 milliseconds to 100 milliseconds, which most people don’t notice. But people who are really fast typists and who optimize their environment really well to run really quickly, they do notice this kind of overhead and lag on every invocation of Ruby executables. So, I definitely want to speed this up. And generally user-friendliness like rehashing of the shim executables after you install gems without any plugin needed, things like that. So, generally just making it more snappy, more user friendly. But no big changes in functionality because the functionality’s already there and the project already does what it needs to do. As for ruby-build, both plans that I have is doing the patches so that people have a better user experience of installing on different environments, and the binaries as well, which we talked to length about. And that’s the short roadmap for these projects. Generally, I would keep them the way they are right now, stable. I just want for people to have a better experience using them. They start to feel more secure in the way that they can just continue on doing their work. And things will just, their Ruby environment will just work for them, and they wouldn’t have to google for error messages and things like that, because that’s one of the worst things about setting up your Ruby development environment. All the complex, it doesn’t need to be anymore complex. POSTMODERN:  Yeah, so even though chruby is pretty minimal and small, there are a couple of remaining things we’ve been meaning to do. Development goes pretty slowly on it. One of which is adding natural version sorting of the actual Rubies array. And so, we can actually, one of the problems, because Bash naturally, not naturally but Bash automatically sorts things lexicographically, and so for instance, if you have a path that ends in 1.2.10, that’s going to come before 1.2.1. And so, we need to actually sort these by versions. And one of the developers who also work on chruby, Havenwood, he wrote this, perfected this massive giant Bash string that basically sorts the actual paths by version. And so, we actually… he did a bunch of cross-platform testing and we just basically need to do some benchmarking. And that will probably go in the next 0.4.0 release. And let’s see. There are a couple of other things we wanted to add to it, adding extra functions. There’s also a split-off project that basically wraps around chruby. And it provides a fish wrapper, so you can use it in the fish shell, because the fish shell is not POSIX-compliant. So, all your Bash scripts and Zsh scripts will not work. And so, they have to either port them directly across, or write wrappers. And so, he wrote a wrapper that basically just runs Bash underneath and then gets the appropriate information back and then loads that to the Fish shell. Let’s see, what else? As for ruby-install, one of the things that I’ve been thinking about but hesitant because it’s going to lock me in, is automatically update the known stable version families and also updating MD5 checksum lists. So, when a new version comes out, you can just run the update script and pull down the new files for those. And so you’ll automatically… DAVID:  How do you mean it will lock you in? POSTMODERN:  Well it locks me into a format. I have to support a format and a URL, so I can’t move them. I have to symlink them. DAVID:  Ah. POSTMODERN:  And yeah, so I’ve been wanting to change the format, for instance how we list stable versions. And instead of actually having them group by version family, just do fuzzy sorting, fuzzy matching on them. So, it will just pick the largest or highest version of 1.9 if you select to install 1.9. Yeah, and see, there’s also we have support for binary builds in there. We just haven’t released it because there’s uneven support. Everyone has their own binaries. And that’s kind of a weird thing. And we have to sort that all out. Also, when I have some actual free time to actually work on code, I want to wrap up this gem_path helper and release that, because I had another utility called chgems that I did. We’re chroot for Ruby gems. But there are issues with chruby, because tmux users required that we did more aggressive automatic version switching. And that broke some of the features when you use it conjunction with chgems. So, I want to move to the gem_path utility, which will just be loaded in your shell and will not spawn a subshell. So, that’s pretty much it. It’s pretty stable. And I think also, I’m watching how things are evolving. There’s a huge push in the Linux community to move towards Linux containers and Docker. Even this new roadmap for the Fedora Linux distribution, they have this big castle in the sky plan called Fedora Workstation and it’s pretty much going to be applications will be distributed as Docker images that will run in self-contained environments and then communicate with the system through Unix pipes or dbus, something like that. Or no, I think they’re actually using kdbus, which is integrated in the kernel. Yeah, it’s something else. So, that’s I think it for me. CHUCK:  Awesome. If people want to find out more about these different options, what are the best ways to do that? POSTMODERN:  Probably just say read the wiki pages, the READMEs. All the READMEs for these projects are incredibly detailed. There’ll be URLs in the show notes, I’m pretty sure. CHUCK:  Just on GitHub. POSTMODERN:  RVM also has a nice wiki. Yeah, they’re all on GitHub. CHUCK:  Alright. Yeah, we’ll put links to all that in the show notes then. DAVID:  I think there’s an interesting correlation, just real quick. You guys can rebut me if I’m wrong, but I think there’s a good correlation with Hick’s Law and with Leaver’s Law. Hick’s Law basically talks about the complexity of a thing versus the efficiency of it. And Leaver’s Law is a law that I made up and named after my friend, Don Leaver, who once said, “Everything the system does for you, the system also does to you.” And I notice that people who like chruby also like mini-test. And they also like small, sharp things. And people who like RVM tend to like RSpec and tend to like Cucumber and they tend to like, “I want the system to do everything for me.” And I think it’s really interesting that there’s that commonality. And I find if fascinating when I find somebody who loves one complicated luxurious tool and also loves one small sharp fast deadly tool. POSTMODERN:  That’s a nice little hypothesis there. It’d be a shame if someone would provide a counterexample. DAVID:  [Laughs] JAMES:  I don’t think [inaudible]. POSTMODERN:  Yeah. Actually… DAVID:  Okay. POSTMODERN:  I love RSpec. And I’m actually in the process of converting. I settled on these sets of tools. And so, I’ve been using RSpec forever. DAVID:  Hang on, I’m tweeting something. [Laughter] CHUCK:  Alright. I’m going to push us into the picks. James, do you want to go first? JAMES:  Sure. I’ll just do two really quick. This first one I noticed just before we got on the call. And it’s basically an analysis of the most popular Ruby standard libraries by usage. And it was pretty interesting. First of all, the list of 30 they give are probably something you should be familiar with. I’m pretty sure I’ve used all of them, save maybe one. And you probably should know these. But also, they explain their process of how they came up with these numbers and what they thought about that. And it was pretty interesting. So, it’s a fun read if you’re into this kind of stuff. And my second pick is this, since we’ve been talking a lot about system administration stuff, and I’m kind of a system administration dummy, there’s this system administration screencast that covers lots of cool utilities and made me think of some of the stuff we talked about with Julia Evans recently about understanding how things are working at the lower level. And I found that interesting. So, if you would like to see some cool system administration stuff, you might enjoy these sets of screencasts. That’s it for me. CHUCK:  Okay. Avdi, what are your picks? AVDI:  As I’ve mentioned several times on the show, I recently went to the Midwest.io conference in Kansas City, which is a very cool multidisciplinary, multilingual conference. And the opening keynote was really cool, really worth watching, very inspiring. Dr. Jeff Norris talked about mission critical innovation and talked about his experiences running Mars missions, or running the team that writes software for Mars missions. Fun fact about writing software for Mars missions, they keep writing the software basically right up until the point that the lander lands on Mars, because they can keep sending software updates to it. But he also had some very interesting presentation software, which I’m not even going to try to describe. But anyway, the video is up on YouTube and totally worth watching. I’ll put a link in the show notes. On a less technical note, got myself some new glasses recently. And after a tip from a friend of mine, I went to Warby Parker which is an online store, or mostly online store, that basically they just sell really high quality designer glasses that they’ve designed for a relatively reasonable price. They’re $95, which if you look at the full price on the glasses at your local glasses store, is probably a pretty good deal. And you just send them your prescription, and they send you glasses. Or I think you can also do a thing where they send you a bunch of different frames without glasses in them so you can try them on and then figure out which one you like. I’ve been wearing them for a while now and they worked out really well. One more pick. I cannot believe I haven’t picked this before. But I was looking through the picks and I can’t find it. So, I will pick the show Pingu. If you have Netflix and you have kids and you are not watching Pingu with them already, well okay, young kids, you totally should be. It is the most adorable kids’ show ever. It is Claymation. It stars a bunch of Claymation penguins that speak in a made up gibberish language. And it’s precious and inoffensive to adult sensibilities, I’ll say. It’s one of those shows that I can sit around and watch with the kids and not just get mad because it’s so lame and badly done. So yeah, really cool show. And I think that’ll be it for now. CHUCK:  Alright. I’ll jump in with a couple of picks. I’m going to pick three books. They’re all really short. On Audible, they’re an hour and a half or less and they are these self-help-ish. I hate using that term. But anyway, I found them really inspiring, so I’m going to share them. The first one is called ‘Rhinoceros Success’. And basically, it’s about focus. And so, it provides a metaphor, you are like a rhinoceros. So, you choose something to focus on and charge toward it until you run it down, basically. He does take the metaphor a little further than I thought was necessary. But I thought overall, the message was really good and it really did inspire me to get up and really focus on the one thing that I want to charge down. The next one is called ‘The Go-Getter’. And it is more of a parable story. It’s an example story and it demonstrates what a go-getter is and talks about what it really means to be a go-getter. And I really, again, found it inspiring. Both books are really short. The last one is called ‘QBQ! The Question Behind the Question’. And it’s a lot about personal responsibility. And the crux of the book is basically instead of asking, “Why is this happening to me?” or, “Why is this happening?” the question behind the question is what can I do about it? Because if you are asking whose fault it is or asking why something is happening, you’re not really getting to anything constructive because you’re not asking what can I do to fix it? And so, it trains you to ask the questions that are going to lead you to a solution, or at least lead you to a constructive way of dealing with it. So, instead of passing blame, you take personal responsibility. And if it’s not your fault, you still have some responsibility in the way that you react or respond. And so, instead of, “Why is this my fault?” it’s, “How can I make the situation better?” “How can I encourage some other to do something?” though that isn’t as constructive, because obviously it depends on somebody else. But anyway, it really, really helped me go, “Okay. So, even if it’s not my fault or even if I don’t want to accept that it’s my fault, I can still ask the question, how do I make this better? How do I keep it from happening again?” Anyway, great books. They’re all real short. I put links in Amazon and Audible, because I listen to them and they’re terrific. So, those are my picks. David, what are your picks? DAVID:  I’ve got three today. The first one, real quick, for Linux users there is a program called RSI break, which it’s not an elegant program. I’m going to throw out, I’m going to lead with the bad. It’s not a pretty program. But it’s Linux, what do you expect? And if you can get past the poor aesthetics, it’s a fantastic program for what it does. And that is, is that it just sits up in your little taskbar up in Gnome or in KDE and you tell it how long you need between rest intervals to stretch your wrists, or stretch your fingers, or get up and walk around or whatever, just get away from the computer for a few seconds, look away from the screen and look off and focus your eyes far away. And you can program it to just give you a little notification for ten seconds every five minutes. I actually tried setting it up to do pomodoros as well, to give me a five minute break every 25 minutes. And the cool thing about it is that it will lock your screen. It will lock your desktop if you tell it to. And so, you’re typing along and this little thing that says, “Please take a break for 500 seconds,” or whatever five minutes is, 300 seconds. 299, 298, 297… and then I’m still trying to finish this document right, so I’m typing, typing, typing. And so, it keeps resetting. Please take a break for 300 seconds. Type, type, type. Please take a break for 300 seconds. And then after about 15 seconds, and it gives you a button to say postpone. You can disarm the bomb. But after about 15 seconds, boom, your screen locks. And it just says, “Please take a break for 300 seconds.” And there’s a button that you can click to unlock it and make it go away. But if you let it drive you, if you say, “Yeah, you know what? I really do need to stand up and stretch my legs or stretch my wrists or whatever,” it’s exactly what you need to get yourself away from the keyboard and get yourself stretching and resting the way you need to. So, that’s my first pick. JAMES:  I want my computer screen to lock and tell me to go for a walk. CHUCK:  [Laughs] DAVID:  Yeah. Yeah, exactly. [Laughs] So, my second pick is, I’ve had this Bluetooth theme I guess. I guess not really a theme. I picked a Bluetooth thing last week, but the week before that I was griping endlessly in the preshow about Bluetooth. So, it doesn’t really count as a theme to listeners. But this is going to conclude my theme, which is I have finally found a Bluetooth headset that I love. And that is the JayBird BlueBuds X. They make just a Bluetooth headphones version that is a really premium, and I want to say about $150 for the headset and the headphones are about $100. They’re not cheap. But they deliver fantastic sound. They wrote their own codec for Bluetooth. It just has superb audio. They’ve got their own signal booster in the headset so that you can put them on and then no matter where you put your iPod, you can put them in your pants pocket, on the other side of your body, whatever, the signal connectivity is still good. You can get 20 feet away from the transmitter with these things and they still get really strong signal without skipping. They’re really, really good. And the reason I like them is that they are the first in-the-ear earbud that I can stand. And the reason I can stand them is they have this little silicone Spock ear sticking up off of the top of the earbud. So, you plug the thing into your ear like an earplug and then, I’m not sure what the scientific name for this is, but you tuck the little pointy-uppy thing into the, I think the technical term is the creasy foldy-overy part of the front of your ear, inside the shell. So, you tuck the pointy bit into the creasy foldy-overy bit of your ear. And it holds the earbuds in place without you having to hammer them into your ear canal and fracture your skull in the process. And so, these things are designed to stay in while you are playing soccer and playing rough sports where you get knocked down. And they do. They fit great and they feel fantastic. And they give really great audio. The headset works fantastic with my Android phone and I love it. My last pick is My Cat From Hell which is basically the Dog Whisperer, only for cats. We’ve all heard crazy cat stories. And basically, this is a semi-reality show about crazy cats and crazy cat people. And the bottom line is this guy comes out and basically, if you don’t like cats, you don’t understand them. And this guy comes out and he retrains people to understand how they’re treating their cat is what’s causing their behavior problems, everything from peeing in the sink to attacking you while you are asleep, running up into the bed and biting you. And he gets these cats to mellow out and calm down and not be crazy. And at the end of the show, everybody loves their cat and it’s wonderful. And it’s an amazing show because the cats start out completely bat-poop insane. And they end up cuddly, fuzzy, wonderful, snuggly kitties at the end. And it’s all about how the humans put energy into the cats and how the cats then respond to it. So, them’s my picks. CHUCK:  Alright. Michal, what are your picks? MICHAL:  My first pick will be OpenSUSE. It’s my Linux distribution I use. And I’m really happy with it. And for all the Rubyists out there, the management utility for OpenSUSE is written in Ruby. So, if you get any issues or ideas, you want to improve it, you can jump in and use your Ruby to work on it. My second pick will be JRuby. I used to be a Java developer for some time. And I hate Java. And because I hated Java, I had a really hard time in believing in JRuby in what they want to do and how it does. And I finally understand the difference between JVM and Java. And for everybody afraid of Java, you should not be afraid of JRuby. JVM is really fast in trying to run Ruby and you should try it. And my last pick is swimming. I love to swim in the lake. And I like it to the point where when my kids have issues with sleeping, I ask them to close their eyes and think of swimming, like imagine you’re swimming. And most of the time, it works. CHUCK:  Alright Mislav, what are your picks? MISLAV:   Well, it’s hard to pick anything after searching on the Ruby Rogues picks page, which is everything in the world has been picked already. [Chuckles] DAVID:  Oh, just pick Sandi Metz’s book then, and you’re golden. [Chuckles] MISLAV:  Well, I wanted to pick, I will re-pick Bash shell from three years ago. I think Chuck picked it first in the podcast three years ago. I will re-pick it now because it’s relevant. All programmed here in Bash and we all trash talked about it and are frustrated with it. But it’s really therapeutic to write all these tiny shell scripts for your development environment, at least if you’re working like most of us are in a Unix-y environment that can run executables. And Bash is pretty much guaranteed to run everywhere. It doesn’t have dependencies. And it is this horrible language which is hard to grok, but there are certain parts of it that I really like. It’s maybe like JavaScript. It’s this Stockholm syndrome that you’re working in this horrible language that is so basic that it doesn’t handle most of the things you need handled. But when you finally get through it and you make a working thing, you feel really proud of yourself. So, that’s I think what’s an appeal of Bash programmers and JavaScript programmers that we can share. And since rbenv is written entirely in Bash, by contributing to this project I had to teach myself Bash. And I’m very grateful for it, for this knowledge. So, you can go up on my dot files, Mislav/.files to see all the tiny little Bash executables that I created for my developing with Ruby and other things, and mostly Git, actually, my development environment. And Bash is the first pick. The second pick would be British Columbia, Canada in the summer. I’m currently backpacking around here. I won’t stay much longer. I’m going down to the US. But it’s a fascinating place to be traveling and I recommend everybody to at least take one summer and a few weeks or more to visit British Columbia, because it’s really great. And those are two of my picks. CHUCK:  Alright. Postmodern, what are your picks? POSTMODERN:  Adding on Mislav’s Bash thing, two resources I totally found that were invaluable to dealing with all the caveats and the edge cases and the gotchas of Bash programming is Woolege. So, Woolege is a Wikipedia page that has all of pretty much the Bash pro tips. And if you go into the Bash IRC channel on freenode, they’re basically just going to link to there and tell you to RTFM. The other thing is shunit2, xUnit testing framework. It’s pretty much available in your package manager already. It’s super easy. If you’re not testing your Bash script already, you need to do that now because there are just so many things that go wrong in a Bash script because it depends so heavily, coupled so heavily to environment variables, weird issues like that. As for audio, notice my amazing voice. [Chuckles] DAVID:  Oh, yeah. POSTMODERN:  What I’m using is the Blue Microphone Nessie. So, Blue Microphones have been picked twice in the past on Ruby Rogues. DAVID:  Nice. POSTMODERN:  But the Nessie is the latest one and it’s basically [inaudible] plug and play for amateur podcasters and musicians. There’s a weird switch in the back that automatically enables a whole bunch of filters, whether you’re recording voice or audio. And it literally was, it’s reasonably priced also. It’s not a high end microphone, but it sounds pretty high end. And it’s USB. You just plug it in, go. I didn’t have to do anything on Linux. It just worked. Then also for headphones, a lot of people get into this whole status symbol of their office equipment. They have the $1000 glass desk and the ergonomically designed chair. And especially, the super high end expensive Sony headphones or Sennheiser headphones. But there’s actually a headphone company you probably haven’t heard of unless you’re a weird audiophile who only streams their music over cables made of pure diamonds. But it’s actually a reasonably priced headphone company that is actually made in the US. Didn’t know that. It’s called Grado Labs. And even their lowest end headphone sounds amazing. I was using them for the longest time. I believe it was the SR20s or the SR30s. And the cord eventually broke because I was yanking on the cord too much and it frayed or the connection to the headphone, because I kept dropping them. And I had to go back to normal headphones and you could definitely tell the difference. It’s literally like going between FM and AM. There’s definitely a noise. You lose quality. And so, that definitely improved my audio listening enjoyments. It also helps that you haven’t blown out your eardrums from years of going to rock, heavy metal concerts and standing right next to the speakers. So, this was picked previously in the past, but I think it deserves reiterating because it’s changed a lot. So, in this age of all this gnashing our teeth about Rails and is Rails Omakase or whatever, or is TDD dead, I’ve had a whole bunch of enjoyment recently by building APIs and web services on top of Padrino. And Padrino has actually improved massively in the recent year. And one of the great things about it is just the fact that it’s familiar because it’s built on top of Sinatra and it pulls a lot of the Sinatra-isms in. But also the fact that when you submit feature requests to them, be like, “Hey, it’d be great if you could filter the requests coming in based on what parameters have been parsed and that way you can actually use it to kill mass injection vulnerabilities at the router level,” so before it even gets to a controller could just kill it. And they actually accept your feature request and they try to implement them. And they’re like, “Hey, that’s a great idea,” instead of, “No, go away.” And that’s been a whole lot of fun. So, try something else if Rails isn’t working for you. There are other options. And lastly, something that’s massively improved my productivity is using an alternative window manager, and so, the whole IDS or desktop environment, whatever you want to call it, on Unix and Linux systems we’ve had this whole abundance of all these various window managers. There’s zillions of tiling window managers where all the windows are just tiled congruently onto the screen, probably because they’re so easy to write. There are tons. But I use a normal, I think you call it mosaic, window manager. And so, I’m still on Fluxbox which is a really old one. But what the benefits are is it has amazing configuration and amazing key bindings. So, basically I have key bindings for switching between different types of windows. I have all the different types of windows. My terminals, text editors, chat windows, all of them are preconfigured to pop up in certain parts of the screen. And I have key binds that spawn new text editors or new browsers or terminals as well as switch in between them, key binds for moving between different work spaces. Pretty much, I barely use the mouse anymore. And also, there’s no animations which I also found made a huge cognitive performance boost because you aren’t sitting there mentally waiting for the animation to finish. It’s just you hit a key and boom, there it is. So, those are my tips. Or picks, sorry. CHUCK:  Awesome. Well, I have no time. I’ve got to run. So, we’ll wrap it up. Thanks for coming, guys. JAMES:  Thanks everybody. DAVID:  Awesome. Cheers, guys. POSTMODERN:  Yeah. CHUCK:  Yeah, we’ll catch you all next week. MISLAV:  Thanks. MICHAL:  Thank you.[A special thanks to Honeybadger.io for sponsoring Ruby Rogues. They do exception monitoring, uptime, and performance metrics and are an active part of the Ruby community.]**[Working and learning from designers at Amazon and Quora, developers at SoundCloud and Heroku, and entrepreneurs like Patrick Ambron from BrandYourself, you can level up your design, dev, and promotion skills at Level Up Con taking place October 8 **th and 9** th ** in downtown Saratoga Springs, New York. Only two hours by train from New York City, this is the perfect place to enjoy early fall and Oktoberfest while you mingle with industry pioneers in a resort town in upstate New York. Get your ticket today at LevelUpCon.com. Space is extremely limited for this premium conference experience. Don’t delay. Check out LevelUpCon.com now.]**[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] **[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]**[Would you like to join a conversation with the Rogues and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at RubyRogues.com/Parley.]**

Most Popular

Ruby Rogues

087 RR Book Club: Practical Object-Oriented Design in Ruby with Sandi Metz

Jan 9th 2013
Ruby Rogues

131 RR How to Learn

Nov 13th 2013
JavaScript Jabber

124 JSJ The Origin of Javascript with Brendan Eich

Sep 3rd 2014
JavaScript Jabber

146 JSJ React with Christopher Chedeau and Jordan Walke

Feb 11th 2015
The Dev Rev

Automate the Pain Away

Dec 19th 2018

Suggestion Box

Subscribe

On social

Current Sponsors

Views on Vue

VoV 096: Cordova and Vue with Daniel Purcell

Ruby Rogues

RR 447: All About Kafka and Oracle with Bob Quillin and Karthik Gaekwad

React Round Up

RRU 096: React Round Up at RxJS Live

React Native Radio

RNR 151: JavaScript Language Features

My Ruby Story

MRS 102: Elia Schito

Ruby Rogues

087 RR Book Club: Practical Object-Oriented Design in Ruby with Sandi Metz

Ruby Rogues

131 RR How to Learn

JavaScript Jabber

124 JSJ The Origin of Javascript with Brendan Eich

JavaScript Jabber

146 JSJ React with Christopher Chedeau and Jordan Walke

The Dev Rev

Automate the Pain Away

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.