Moving from RubyMine to Atom: Is It Worth the Effort?

RubyMine or Atom


It’s pretty hard to find a topic more popular and more frequently discussed among programmers than the process of choosing a text editor. I’m not here to participate in that discussion, because it always ends up with everyone defending their own interests. Instead, I’m here to explain how to make the process of moving from RubyMine to Atom as easy as possible for Ruby developers.
By way of background: I, for one, couldn’t imagine any alternatives to the integrated development environment (IDE) when I entered the world of Ruby from a C# environment. However, my Distillery colleagues frequently told me that there are some specific reasons why writing code in a text editor is much easier and faster. That was the moment I became interested in moving my working environment from RubyMine to Atom.
Before going any further, however, I want to explain that it’s pretty hard to separate IDEs and text editors. As it turns out, according to Wikipedia’s definition of an IDE, the process of setting up Atom is nothing but a transformation from a notepad on steroids into a real IDE.

Pros and Cons

First, let’s try to understand if we really need to change anything and make the move to Atom. Let’s start with the most obvious considerations — those which can be found in any earnest IDE, and which aren’t available in text editors:

RubyMine or Atom - pros and cons

  • Autocomplete. If I had to write such things as “BaseRemoteDataStorageWrapper” on my own, I would be a very sad developer indeed.

  • Test launching. In all IDEs I have seen, the process of test launching is an incredibly easy and enjoyable process. You just need to check that the cursor is inside the test, and click a couple of keys. That’s it! You are glorious, and the test is already running. When we leave the comfortable world of IDEs, an inadequately aware person would imagine something extremely pleasureless: switch to the terminal, enter the full path from the root folder to the test file (it’s worth noting that if we’re talking about a professional project, all tests are usually hidden in a very branchy directory structure), and use the ‘—name’ parameter to indicate the name of the test to be launched, because we don’t want to wait until all tests are carried out in case it turns out we need only one.

  • Debugging. What could be more beautiful and efficient than iterating through each and every stage of your code with the ability to see the current state of all variables at any given moment in time?

  • Automatic refactoring. We can’t expect that an IDE will write the code instead of us, but we can be sure that it can extract a couple of strings into a separate method or rename the class name throughout the code.

Now let’s examine the advantages of Atom in comparison with RubyMine:

RubyMine or Atom - pros and cons

  • Performance. It’s hard to say that Atom is fast, because it can be slow once in a while; however, the slowdown happens significantly more rarely.

  • More configuration options. A vast ecosystem of plugins has been created around Atom. All modern IDEs, including RubyMine, have plugins and extensions, but Atom easily outmatches all of them by a huge margin. It’s hard to explain why, but the fact remains. You will find a plugin for everything that comes to your mind. Do you want to edit the code automatically after getting a warning from the linter? You can easily do that! As you’re writing code, do you want the editor to shake and sparks to fly from every character you type? That too can be done!

  • Price. Atom is free and based on open source code, and $200 doesn’t grow on trees. If I were a student or a freelancer planning to learn Ruby, I would really like to save that amount of money.

Let’s Go!

I’m pretty sure I don’t need to explain complex things such as downloading and installation. I will note, however, that during the installation process, Atom installs the apm utility, which is used as a package manager for various plugins. You can also install plugins one by one using the settings tab, but that wouldn’t be as efficient. So, let’s look at what we really need for the process of Ruby development:

# Just ruby
apm install linter # Base for other linters
apm install linter-ruby
apm install linter-rubocop
apm install rubocop-auto-correct
apm install atom-rails

# Nicer code
apm install atom-beautify

# Testing
apm install ruby-test

# Dockerfile support
apm install language-docker
# Other
apm install platformio-ide-terminal # terminal inside your editor
apm install minimap # Sublime-like minimap
apm install Sublime-Style-Column-Selection
apm install toggle-quotes
apm install trailing-spaces
apm install git-blame

Now, let’s install a couple of gems that we need for our work:

gem ’rubocop’ # static code analyzer
gem ’m’ # test launcher

After launching the script and adding gems into the Gemfile, we have partially solved the first problem — the one focused on autocomplete. It requires some time to warm up, however, because the autocomplete feature is based on the information available in the file and on user input. Even though this solution is pretty minimalist, we can still use it in our work. Also, you can make the autocomplete feature more intelligent by using this package.
Now, let’s talk about the process of test launching. For our project we use only mini_test, and that’s why we’re going to use it as our example, but one can embed any other testing engine, such as RSpec or even Cucumber.
The discriminating reader has already noticed such important package as ‘ruby-test’ and ‘m’ gem. This package allows the launching of various tests right in the text editor — the terminal window will be shown at the bottom of the screen. (This feature is carried out by ‘platformio-ide-terminal’.)

Launch all available tests (Hotkey: Cmd+Y).

  • mini_test command: Run all tests — ’m’
  • I was really impressed with the ease of this command.

Launch the current file with tests (Hotkey: Cmd+T).

  • mini_test command: Run test file — ’m {relative_path}’

Launch the current test (Hotkey: Cmd+R).

  • mini_test command: Run current test — ’m {relative_path}:{line_number}’
  • It’s pretty easy to guess the meaning of {relative_path} and {line_number}, while the key combinations are given by default. You can easily change them at any time. (The weirdest idea I had in mind was to use a set of pedals for test launching.)

We have finally reached the debugging stage. I still think that there’s nothing better than executing the most important parts of the program (or the entire program) step by step, but do developers really need such mountains of data in their daily lives? Let’s think about what we really need during the debugging process.

If the unwavering gaze proves useless in finding the errors in the code, we need to know the value of specific variables in the most suspicious places of the code. That’s how we use the console for debugging when such variables are sent to the console, where we can check them more thoroughly. But it’s pretty hard to create a list of such variables right away, and it may take too much time to understand a huge piece of text in the console. We can, however, use the good old ‘pry’. To do that, we need to write ‘binding.pry’ in a specific place. When this line is executed, we will see an IRB console with the same context. There’s nothing really new here, because that’s how the debugging process is carried out in the majority of cases. When using IDE tools, however, we need to wait until the process reaches a breakpoint, write a couple of strings in the interactive console, and achieve an understanding of the important things that are going on.

Finally, let’s say a few words about the automatic refactoring. I couldn’t really get used to that feature, because every time the IDE or the plugin was doing something instead of me, I had to make an incredible number of changes on my own, thus killing the idea of saving precious time with this method. There are several packages available in Atom, and they offer a high level of JavaScript support. But I have to confess that the situation with Ruby is not really ideal, and I couldn’t set up anything reliable or interesting in my text editor for a couple of days.


I can’t say that I’ve experienced anything really impressive and new after a couple of days of setting up — and another couple of days working in — Atom. I won’t say that I’ll never return to RubyMine, but I will say that Atom is indeed very worthy. It’s really easy to work with, and you’ll forget about its inconveniences relatively quickly. It works significantly faster. And most importantly, knowing that I can set it up as I want — and not as the developers of RubyMine want — makes my soul smile.

Want to learn more about how Distillery’s developers stay up to date with the latest technologies? Let us know!

Andrey Oleynikov

About the Author

Andrey Oleynikov has built his entire career within Distillery’s walls, starting out as a junior developer and rising to become a head of Web Department. Over the years he has mastered both the .NET and Rails frameworks, along with the C# and Ruby programming languages. Andrey is a big fan of beer and DevOps, though not both at the same time.

previous next