Before you say "there is no better programming language, each one has its purpose", I know it. That's why "the best" is in quotes in the title.
But in this text I want to show 3 situations in which Ruby was the best choice, even though I didn't want to use it in two. With Ruby, I did in hours what I couldn't do in days (2 to 3) in another language (Shell Script, in this case).
The three situations that I will talk about here are:
- Continuous compliance
- GitHub Automations
- CLI Test Automation (Command Line Tools)
But before getting into these topics,
Its creator, Yukihiro “Matz” Matsumoto, combined parts of his favorite languages (Perl, Smalltalk, Eiffel, Ada, and Lisp) to form a new language that balanced functional programming with imperative programming. He said, "I wanted a scripting language that was more powerful than Perl and more object-oriented than Python." (From https://www.ruby-lang.org/en/about/)
Ruby is highly portable: it is primarily developed on GNU/Linux, but works on many types of UNIX, macOS, Windows, DOS, BeOS, OS/2, etc. It comes by default on many Linux distributions and on macOS.
Ruby is not only completely free, but also free to use, copy, modify and distribute.
It is considered one of the best languages for test automation and one of the pioneers in some frameworks, such as RSpec and Cucumber. But unfortunately its popularity is decreasing.
Below, only 3 examples where Ruby is used:
Now let's get to the main subject, which is where I'm using Ruby even though it wasn't my first choice.
I didn't even know it existed until I watched TAU's Continuous Compliance course. This course opened my mind to a sea of possibilities for automating checks.
The course uses Chef Inspec, an open source Ruby DSL. I made a POC with this tool to automatically check repositories on GitHub, checks like if it contains a gitignore consistent with the language used, if node_modules is not present, etc.
The problem is that Chef Inspec must be installed every time a workflow runs, in addition to having to run a specific command, the repository being in a specific folder, having to look in the documentation for the command to perform a check, which is sometimes limited …
After reading the documentation and knowing the possibilities for use, I ended up abandoning the tool to use pure Ruby. If the tool made in Ruby does it, obviously pure Ruby will do it too, and much more, because there will be actions not implemented in the DSL (this is one of the reasons I'm a bit against DSLs, but that's for another text).
Probably everyone here has already created a repository on GitHub, but I'm sure if you don't use GitHub for work, you've never bothered to secure a branch, for example.
Some settings are essential when working with GitHub, such as protecting the develop and main branches with some rules:
- Do not accept direct push
- Merge with pull request only
- Require signed commits etc
These settings are a little boring to make. When creating a repository, it can take some time clicking on (checking) checkboxes. This time can be reduced by scripts for automating the creation of repositories through the GitHub API.
As I wanted these scripts to be able to run on both Linux and macOS (sorry Windows. Hi WSL), I started to develop them in Shell Script, since it is a native language of both systems.
But when it came time to do some checks before an action, Shell Script became extremely complicated. And what is the other language that comes with Linux and macOS? That's right, Ruby.
I used Ruby to do some checks like if the repository exists, list repositories and call existing sh files.
And to make it even more "system compatible", this is inside a VSCode devcontainer, with the Ruby Docker image, making everything configured with one click.
We were developing a command line application. I had never worked with this and had no idea how to automate CLI tests. Obviously I went to ask Google.
One of the results was how to test CLI developed in Rust, just what I needed! Unfortunately, for lower-level testing, the code would need to be refactored to be testable. And I don't have the knowledge in Rust for that.
Fortunately this and several other results told how to test, which is simply typing a command and checking what comes out in the terminal. So I would just do e2e for now.
The tool that was most indicated was Bats, made in Shell Script. But I couldn't make some simple things work like assigning variables to use them within the tests. The documentation itself said that it was a little complicated to split the tests into different files. Imagine the mess that would be as the tests grew.
Another tool I found was Aruba, written in Ruby, but the documentation is practically non-existent and it recommends using it with Cucumber. Even the examples inside are in a
features folder. I refuse to use Cucumber…
Then came the same thought from Chef Inspec: if it's done in Ruby, I can do it in Ruby. And it's working beautifully with Ruby, RSpec and the Open3 module for handling terminal commands.
Whenever I go looking for a way to automate something, if there isn't a widely used framework like Cypress, Robot Framework, Skuli etc, and there is some mention of a framework made in Ruby, I won't even look at the others. Ruby is the choice!
I learned from Codecademy and, of course, from Google too. I recommend Codecademy for any language. Online hands on and straight to the point! Basic courses are free.
RubyGuides also has a lot of material and helped me a lot. It also has a newsletter that you receive content about Ruby directly in your email. That's great for me!
In the language official documentation, there are other links to learn Ruby.