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.
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:
Now let’s examine the advantages of Atom in comparison with RubyMine:
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’.)
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.
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 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.