By David Bush

Tools for a Modern Ruby Development Setup

By David Bush

The initial publication of this article was attributed to the wrong author. This has been fixed and those responsible have been sacked. Sorry David!


Web Development has evolved tremendously in the last 20 years. A modern development environment would be unrecognizable to to someone developing Coldfusion in the late ’90s for example. The greater focus on best practices and developer productivity have certainly made software more maintainable, but this comes at the cost of added complexity. To navigate this complexity, a modern development environment is required; this article will outline some of my personal favorite tools.


Tmux is a terminal multiplexer (think screen), which means you can have several terminals in the same shell session. It allows you to split panes and move them around and reconnect to a tmux session from a different machine. This particularly shines when it is deployed on a server, as you can start a long-running task, disconnect, and your tmux session will keep running.

The real strength in Tmux for development lies in knowing in which window each of your different tools is running because with some quick window changing shortcuts, you can move so quickly that flow becomes instinctual. To aid this, tmuxinator sets up profiles (protip: bind these to Tmux shortcuts to facilitate easy opening of different types of projects like Rails, Sinatra, etc), which complements Tmux nicely.

Additionally, Tmux is extendable through its plugin ecosystem. Take a look, but I would recommend the Tmux Plugin Manager, tmux-battery, and tmux sensible.

If you are looking for a simple start with Tmux, check out this article.


Bash is fine and all, but it hasn’t aged very well and better terminal alternatives are available. ZSH is an excellent choice, but I personally lack the motivation to invest time in learning how to configure yet another piece of software. To this end, I would recommend Fish. It has excellent command completion, is fully scriptable, and looks much nicer than Bash. Best of all, it just works out of the box (although there are a couple of minor idiosyncrasies you’ll run into. Also, your Bash aliases won’t work, but translating is straightforward and these are comparatively low setup costs). I particularly enjoy interfacing with Git this way, but I recently discovered the excellent Gitsome, which offers excellent Github integration and unparalleled autocomplete, so I am currently vacillating between the two.


Vim is the cornerstone of my environment. Heavily customized to speed development, it bears more of a resemblance to a fully fledged (albeit lightweight!) IDE. Let’s walk through some generally useful plugins, and then get to some Ruby-specific ones. You can download my vim dotfiles here.

Navigating a project can be cumbersome. Fortunately, Vim’s rich ecosystem really comes into its own here. For browsing a project, I recommend the excellent Nerdtree. This will give you a browsable tree structure, affording you a neat high-level overview of the current directory and its children. Pressing m while in this view will allow you the ability to delete, create, and rename nodes without ever leaving vim. Sublime stalwarts will enjoy ctrlp; an excellent fuzzy matcher which particularly shines when you have similarly named files, like in a Rails project for example. Finally, I frequently want to access files I have used recently; MRU does exactly this.

While those are some of my favorites, here are some other vim plugins that deserve special mention:
* Fugitive: Git integration directly in Vim
* Supertab: Code completion
* Airline: Pleasant looking status bar
* TComment: Quick comment/uncomment functionality
* Surround: Wrap the usual vim boundary selections in parenthesis or quotes
* Autoclose: Automatically close brackets or quotes
* Gundo: Interface to Vim’s well hidden tree structure storing document changes, which frequently proves much more useful than the linear ‘undo’ functionality

Ruby Specific Plugins

First up, you need to ensure your version of Vim is compiled with Ruby:

vim --version | grep ruby

The above command should include a +ruby. If it doesn’t, you need to either recompile Vim with ruby support (relatively trivial) or install a version of Vim with Ruby support, like MacVim. While a lot of the plugins will work without it, you’ll miss out on useful features like autocompletion.

vim-ruby is the first port of call. It adds syntax highlighting, IntelliSense-like autocompletion, and even compiler plugins. This should get you a lot of basic IDE functionality out of the box. It even has erb syntax highlighting!

Tim Pope is the man who has given us several excellent Ruby (and other) plugins. You could do worse than to check out his projects and integrate them into your workflow. If you’re going to get one plugin to aid your Rails development, it should be vim-rails. This plugin brings all the command line functionality directly into Vim, which is tremendously useful when you marry it up with Vim shortcuts. Let’s delve into some useful commands here:

gf – This is a context aware switch that will jump you right into a related file. You can leverage the appropriately named :A (alternate) and :R (related) to go from model to schema, template to helper, and controller to functional test.

Interface with rails on the command line with :Rails (also rake can be accessed via :Rake, if you’re pre-Rails 5.)

You can extract partials by visually selecting an area and leveraging :Rextract <filename>. This seems such a minor feature but is incredibly useful when refactoring a clumsy view.

There are a ton of other useful shortcuts and your time will be well invested in learning them.

vim-dispatch is another Tim Pope creation. This allows you to leverage Tmux to bring asynchronous functionality to Vim. Useful to kick off unit tests without blocking input or opening another pane.

vim-rspec is a lightweight RSpec runner for Vim. I enjoy the mappings if I’m not using Guard.

For further reading on this subject, check out this article which is much more in depth.

Honorable mentions:

  • vim-endwise: automatically appends an end when you input def <function_name>. Think snipmate but without having to invoke the shortcut.
  • vimbundler: wraps bundler, which makes interfacing with it slightly nicer.
  • vim-haml: Cutting edge Vim runtime files for Haml, Sass, and SCSS – unnecessary but nice.

This isn’t really a Vim plugin but I’ll include it here anyway: gem-browse is a Ruby Gem that opens a library’s source file in your editor, which saves time when you need to wade through the source of some obscure library to see why your code isn’t executing as expected.


Docker is comparatively new technology compared with the others, but no less important. It facilitates easy and platform agnostic deployment by running a ‘container’ within a single Linux instance, avoiding the overhead of starting and maintaining traditional Virtual Machines. Additionally, the isolation afforded by this approach affords an extra layer of protection.

Docker used to be a bit difficult to get started with, necessitating the excellent How to Use Docker on OS X: The Missing Guide, but things are better now. Head over to to get started.


I am a huge fan of Guard. While in large projects with huge batteries of tests, it doesn’t shine so much, any rapidly evolving project without this constraint benefits hugely from the instant feedback it provides to developers. By keeping the Spring preloader going, it can dramatically reduce time taken for tests to run, and I would wholeheartedly recommend pairing it with minitest-reporters for more informative test output.



Pry is a fantastic addition to your gemset. A powerful alternative to irb, it allows command shell integration (git, vim, etc), syntax highlighting and powerful history viewing and replay functionality. Used in tandem with the pry-doc gem, it includes some neat features like show-doc to bring up documentation and show-source to view source of Ruby builtins. It can work well as a debugger and as someone who favors REPL driven development, I find it a breath of fresh air to use compared with the default irb.


With the advent of ORMs, SQL is something I interface with less regularly, which means autocomplete is a real time saver when I can’t remember exactly how to do something. Pgcli (and its cousin Mycli if you’re stuck with mysql) offer this exact functionality and with syntax highlighting to boot. Highly recommended.


If you can suffer through what is arguably the most painful configuration process in modern software, Mutt is an excellent choice for command line email access. It uses Vim bindings and I definitely appreciate not having to leave my shell to handle email.


I find IRC an invaluable resource, but definitely something that works better in the shell. irssi is my client of choice (be sure to check out the extensions). I also hear good things about weechat.


We’ve covered a lot of ground here and, as always, there’s a ton more below the surface. Vim is where I spend most of my time, so I’ve spent proportionally much more time customizing it. Researching Tmux and your shell properly is definitely time well-spent. Naturally, this is all personal preference so you’re unlikely to develop using my exact setup, but you should hopefully have a better idea of what is out there and perhaps even integrate something new from here into your workflow.

  • gapipro

    Articles like this make me feel like some still live in 90’s where terminal was only thing existing.

    But no its 2016 and people should use and recommend a normal IDE like RubyMine or IntelliJ IDEA that have everything included (yes that also means you get a VISUAL DEBUGGER!!!).

    • Artemiy

      a normal IDE like RubyMine or IntelliJ IDEA

      That are also, ahem, not free. So yeah, I wouldn’t just go and recommend them off the mill.

      • gapipro

        If you are a good programmer price shouldn’t be a problem because you cover it in less then a day.

        • Artemiy

          Good point. I still think articles have all rights to focus on FOSS, but that is a good point.

    • ggsp

      So, Rubyists just don’t use IDEs, for the most part. Check out this article: where the VAST majority of Ruby devs (including Matz and DHH) don’t use IDEs. Also, see the comments here: One actually says “We don’t need IDEs”

      • gapipro

        Yea I have read that. And I think that so high percentage don’t use IDE because they never tried it before. When they do they come to same conclusion as that article did. The ones that started using it, never turn back because they see how much more productive they can be.

        • ggsp

          I think saying people like DHH and Matz aren’t on an IDE b/c “they haven’t tried it before” is a bit of a reach. Not only are these folks professionals, but they are well beyond the skill level of most programmers. If they could be more productive with an IDE, they would use it.

          I would say, however, that most devs that don’t use vim haven’t made the leap (and it is a sizable leap) to vim. It’s a big learning and habit curve, but well-worth it, IMO.

          • dbush

            I’d agree fully. I’ve tried both ways and I’d certainly never go back to an IDE. I would not imagine my experience to be atypical. I don’t want a visual debugger. And if I did, I’d get one (like gdb or something) and work it into my existing toolchain.

            The learning curve of Vim is among the steepest, but the payoff is huge. I imagine similar returns with Emacs, but I’m too locked in to modal editing at this point to comment!

    • Lord Alveric

      I’ve used RubyMine in the past, but it was simply not up to the demands I was putting on it. It was slow to load, and debugging was atrocious, and didn’t handle multiple threads well, to say nothing of simply crashing while trying to debug my neural evolution engine…

      And they wanted me to PAY for this????

      So I went back to Emacs, with the ECB plugin, and using Tmux with Tmuxinator. I use Pry for debugging. Just works, allows me to “cd” into Ruby objects and “ls” its contents, etc. Sweet.

      Also, RubyMine had a problem with my layout tastes. I like being able to look at 5 or more files at a time, so screen real-estate is important. RubyMine cluttered all of that. It was hard to look at more than 3 at once without going nuts, and then I had to contend with switching modes between writing the code and debugging, where the debugging tools were hogging the real-estate???

      The wheel has been around for centuries. Millennia. Guess what? The Wheel has never been more heavily used in all of human history than it is today. It Works.

      Same goes for command-line debugging, Emacs, Vim, etc. My personal opinion is that greenhorns get too caught up in whiz-bang IDEs, when they should be focusing on what matters — writing clean, concise code, and being able to debug the same with ease. Most IDEs today constrain you, and if you ever need to, say, set up CI/CD without them, you sometimes might be hamstrung for overdependence on them, as was the case on a recent project where IntelliJ was relied on too much to do Java development. It’s built-in “build” process mirrored doing it from command-line, but not exactly. It differed just enough to keep you dependent on the IDE. It took effort to divorce that dependency.

  • thereisnothingtoachieve

    I’m going to be pretty brutal here, maybe not Cannibal Corpse level brutal:
    1) title is completely misleading, it should rather be something along “My favourite software for dabbling with Ruby” and the write-up itself is more suitable for a personal blog than for general public that might be interested in finding out about some viable options in the field
    2) in connection with the first point, this write-up is completely biased and unreliable: although vim is available on various platforms, other pieces of software may not be, and most probably aren’t; judging by the title itself one might have expected a review of options that might be usable on other OSes, not just *nicksy stuff which most preferably should be a Mac (omission of say MSWin-available options and of the OS itself should by modern standards be considered at least unprofessional – long gone are the times when said OS was and could be an object of derision and a toy rather than a serious piece of software)
    3) in connection with the above points, I think this overview of say Mac or Linux specific options does nothing to counter the idea that those operating systems are and should be preferred for the so-called web development, which is a shame, but that’s the impression one gets when presented with only Linux or Mac specific options
    4) in connection with the above points, modern-day set-up for any serious development in ANY language should first and foremost stress the importance of using a fully fledged IDE, where one might get all the options (or at least a considerable number of them) mentioned in this write-up plus options allowing proper assurance of code quality, like visual debugging, code refactoring, testing and many others (the idea of professional environment presented in this write-up dates back to the 1980s at least where professionalness was considered to consist in and of using tools totally confusing to non-“professional” individuals – the arcane technology, the terminal and command line infatuation, wasting one’s life on trying to learn some overcomplicated tool in order to carry out tasks that are maybe much less daunting, … maybe it’s time to grow up and stop or at least try to insist on the cli and having to use a plethora of tools being a synonym of professional development, and that being possible only on a Linux distribution or a *nicksy system…, cli is useful and more handy than GUI in some contexts but where it is not necessary it shouldn’t be overused
    5) badly formed words in my response are used purposely

    • ggsp

      That wasn’t THAT brutal ;)

      1) Disagree. This is a Ruby channel where people come to learn about Ruby and how to develop with Ruby. Learning about tools people use to do that is well within our wheelhouse. If you don’t like the title, well, OK.
      2) Of course it’s biased. It’s this developer’s view of the world. Again, I feel like you’ve let the title fire you up. Also, I used to be a .NET dev, and I tried many, many times to have a viable Ruby dev env on Windows, and it is extremely difficult.
      3) As a seasoned Ruby dev, I would absolutely say that Mac/Linux is preferred for Ruby development. I think it stinks that Windows doesn’t have better options, but the fact is, it doesn’t.
      4) I couldn’t disagree more about the IDE opinion. I prefer vim. In fact, I avoid IDEs like the plague. They are resource-heavy, often expensive, and they don’t move as fast as the vim community. I can step-through debug, run tests, etc. from vim. While some IDEs may have prettier debuggers or one or two other small advantages, vim still blows them all away for speed, cost, and usability. IMO. Oh, and I am a professional developer and I use vim. Everyday. It isn’t arcane or “nicksy”. It’s productive. I don’t want a gui. Some folks do, but I don’t.

      Anyway, I appreciate the comment. I think discussion around dev tools is very valuable. I stand by David’s article, with the caveat that maybe the title could be better (which is on me, b/c I came up with it)

    • dbush

      Author here. Some good points. I think the salient issue here is operating system choice, but I haven’t used Windows in years and couldn’t comment on developing with it (Visual Studio is one of the best IDEs I’ve ever used though!). That said, Microsoft actually included a Bash emulator (Ubuntu user-mode binaries, I believe) in Windows 10 back in March, so you could theoretically use all the tools mentioned in this article if you were so inclined.

      Naturally I am biased, but I reject the notion that the command line is inherently inferior. I purposefully ensure that seldom have to take my fingers off the keyboard as the mouse slows me down and interrupts my flow, and with the various shortcuts and keybindings that are muscle-memorised, I have never found speed or complexity to be much of a problem. Of course, the plural of anecdote is not data.

      It’s irresponsible to place an emphasis on IDE use as important, when it isn’t. Solid understanding of fundamentals is important. Knowing your toolchain is important. Using one tool over another? Not important. Millions of developers write professional grade code every day without an IDE. There’s an argument that says the sheer volume of options and choices an IDE presents could easily be overwhelming to a newcomer; or to paraphrase your point – wasting time trying to learn some overcomplicated tool when more efficient options are available.

      I would agree fully that a CLI environment is not in any way a figurehead for professional development, and certainly shouldn’t be treated as such. People should use the tools that work for them.

      Thank you for stoking a lively discussion!

    • Fred@Bootstrap

      Hi there,
      allow me a brief riposte:

      1) although the article naturally describes the author’s favorite tools for dabbling with Ruby (it would be disingenuous if it didn’t), it still presents tools for modern Ruby development. And yes, it does give readers options for trying out theirselves. Whether a reader may like or dislike the tools presented or the style of the presentation, does nothing to invalidate the title or the value of the content.

      2) Whether we like it or not, the near totality of Ruby development takes place on Mac or *nix machines. It is therefore naturally expected of the author to present tools available on those platforms, while ignoring alternatives for hardly-ever-used platforms

      3) Anyone who’s ever tried Ruby development on Windows (myself included) will know exactly why Mac/*nix are the preferred platforms not just for Ruby but for also most non-MS-tied languages. Besides, the aim of this article was to present a toolset, *not* to evaluate OSs.

      4) You say: “in connection with the above points, modern-day set-up for any serious development in ANY language should first and foremost stress the importance of using a fully fledged IDE”

      No it shouldn’t! Any article respecting its readers should stress the importance of using the most productive and flexible tools for the domain. In the case of Ruby development, a fully fledged IDE is *not*, I repeat *not*, the most productive and flexible environment to use. I can understand why someone coming from a .Net/Java/etc background may find it incomprehensible developing without an IDE, but anyone with a sufficient enough grasp of Ruby must realise that a fully-fledged IDE is overkill. For the record, I’ve been developing on MS Visual Studio for 14 years before I started using Ruby. Part of the reason I moved to Linux was that I could much easier develop Ruby on Linux than on Windows. Also, I don’t use Vim (I’m a Sublime fan) but I can appreciate the productivity advantages Vim can give its users.

      Ultimately, the article does what it says on the tin: it presents a number of tools that many ‘modern’ Ruby devs use. It’s up to you to decide whether you’d like to explore some of them further. But criticizing the article because it doesn’t cover *your* favorite tools for your niche environment is unfair and unfounded.

  • ggsp

    Well, in regards to the OS, no one has said that Window is for noobs or that the GUI isn’t useful outside of dev. My point is that Ruby development on Windows is tedious to the point of not being worth it. I have tried it, it was painful, so I moved. I use a Mac precisely b/c the GUI bits are SO much better than the Linux alternatives. So, I see the value in a GUI, I just don’t need one for my development.

    As far as being a hypocrite for not paying for an IDE, I don’t see your point. I never said the reason I use vim is b/c it’s free. I said it’s _productive_. Show me an IDE where I can development in all the languages I use regularly (ruby, js, css, html, go, etc.) that performs as well as vim and makes me MORE productive, and I will pay for it. Right now, it doesn’t exist, AFAIK. I am not going to pay for something that I won’t use. I am not stealing from devs by using a free editor. I don’t insist on IDEs being free, I insist on being productive.

  • Javier Ojeda

    I know this may be out of date but…

    The reason why Windows is so bad for modern web development is because Microsoft itself seems to forget about there are other MANY languages out there than just VS, C#, etc… It is the fault of MS for this movement from MS to *nix for modern development.

    So, ok. You want that the dev community gives a more extensive use and recommend using MS for development just because it is not impossible, well… Say that to a profesional dev. It WONT happen.

    For the people who is learning to code exists other alternatives like codecademy, codeschool, pluralsight, etc, etc, etc… Even books. Some of these sities, doesn’t even mention any OS.

    About the IDEs is not worth for me to comment about more than this: If I can’t make Ruby run on Windows, why am I about to pay, download a 1gb IDE and install it? to use it with my barely working Ruby installation? (replace Ruby with any other language that are not part of the MS family).


  • Lord Alveric

    I am a little dismayed that Emacs was not also mentioned. I know there are religious tribes circling both camps, but really, Emacs is a force to be reckoned with. It now forms an integral part of nearly all development I do these days, regardless of language — Haskell, Ruby, Lisp, C++… tons of support for nearly all major languages, and OrgMode is a powerful way to document your project too, which GitHub also supports. If you do a lot with Markdown, you might want to take a serious look at using OrgMode. You just can’t beat it.

    With Tmux, an indispensable companion is Tmuxinator. You can create layouts you can reproduce at whim — as well as run any commands on startup in any of the tmux panes. The combination of the two has revolutionized my use of the command-line to a new level. I, for example, have a Tmux layout per project I am working on, and when I bring them up with Tmuxinator, it “cd”s all the panes to the proper location of the projects they belong too, and more.

    I have also tooled my Bash startup to automatically jump into tmux when I start a console. I can’t imagine not doing it this way anymore.

Get the latest in Ruby, once a week, for free.