Gain insights into Ruby development with 78 tasks tailored for beginners and experienced coders. Explore object-oriented concepts, debug programs, and advance your freelance coding career.

Ruby Is for Fun by Roman Pushkin_468 x 60 copy.png

Dockefile.tar.gz

ruby_emulator

ruby_slot_machine

ruby_roboWar

ruby_Robot-copy

ruby_load

ruby_load-copy

ruby_app

This self-study course written as a book is your first step towards making money by coding and programming from home, and having fun doing it. You will understand how the Ruby language works, and establish a foundation for being a successful freelance developer. This course gives you not only technical detail, but presents knowledge in a friendly format, understandable by all ages, providing a thorough explanation of modern concepts for absolute beginners.

In this course you will find 78 easy to follow tasks, so even people without any programming skill can solve them. Beginners will learn how to create, debug, and understand programs in Ruby. Those who are already familiar with the language will rediscover object-oriented concepts, memory organization, find career advice, and save the planet from a nuclear apocalypse.

Ready to dive into one of the most influential and demanding third generation programming languages? Let's tune in!

The Handbook for Ruby Developers

# Popularity of Rspec
According to [The Ruby Toolbox](https://www.ruby-toolbox.com/categories/testing_frameworks) website, Rspec is the most popular testing library for Ruby:


Some folks from the Ruby community don't like it, though:

> RSpec offends me aesthetically with no discernible benefit for its added complexity over test/unit says [DHH,the creator of Ruby on Rails, on Twitter](https://twitter.com/dhh/status/52807321499340800)

It’s a matter of preference; the question is quite controversial. To some degree, DHH is right. RSpec often emphasizes the smart, not-simple way of writing tests. 

The Rspec configuration can take up some time. The good news, though, is that Rspec has completed its maturing phase, and its configuration is rather simple. For almost every question, there is an answer we can find online.

In reality, the readability (and developer happiness) of tests solely depends on a team. A development tool is not the first factor here. There is no such tool that solves all problems, and any tool can be misused. This question is more about balance and producing readable and straightforward rather than smart tests.

Rspec is based on its domain-specific language (DSL). Read this as “language extensions.” Rspec introduces a few new keywords, like “describe,” “let,” “it,” “before,” “after,” and so on. We haven’t covered any DSL in this course before, so let’s assume it’s a new language syntax we need to be familiar with.

# Installation
We will install and configure Rspec from scratch. Let’s start with the latest Ruby. Type “`rvm list known`” to get the list of available Ruby versions for download. We need an “MRI” flavor (Matz’s Ruby Interpreter, a classic developed by Yukihiro Matsumoto). Once we get the version, we need to type the following command to install it:

```shell
$ rvm install 2.7.0
```  
Or, type any other version without the “-preview” suffix. Then, let’s create a directory and fix the Ruby version for this directory:

```shell
$ mkdir rspec_demo
$ cd rspec_demo
$ echo "2.7.0" > .ruby-version
```

We must ensure we have the version we expect:


```shell
$ ruby -v
ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-darwin16]
```
If the version is different, do the `cd` trick. Change the directory to one level up, then switch back. That’s how some Ruby version managers work: they hijack our `cd` command:

```shell
$ cd ..
$ cd rspec_demo
```
# `Gemfile`
In previous chapters, we used the `gem install…` command to download and use Ruby libraries. Once a library is downloaded, it is located somewhere on the disk, and programs can use it. However, it’s nice if we can keep a list of dependencies somewhere. This list can easily guide us through numerous complexities.

`Gemfile` is such a mechanism. It’s just a list of libraries with some features. For example, we can specify a source or stick to a particular version of a library. Imagine new versions get released, and API (the way we use the library) changes. We still want our old program to work, right? Let’s create a new `Gemfile`:

```shell
$ bundle init
```

Here is what default `Gemfile` looks like:

```shell
# frozen_string_literal: true

source "https://rubygems.org"

git_source(:github) {|repo_name| "https://github.com/#{repo_name}" }

# gem "rails"
```

It looks a bit scary but, at the moment, we need only one line that defines a place where to look for gems. We’ll keep the `source …` line and add `rspec`  dependency. So, here is what our `Gemfile` should look like:

```shell
source "https://rubygems.org"
gem "rspec"
```

Then, we can run the `bundle`. This command will execute `gem install …` for every gem located in `Gemfile`. We have only one at the moment:


```shell
$ bundle
Fetching gem metadata from https://rubygems.org/...
Resolving dependencies...
...
Fetching rspec 3.9.0
Installing rspec 3.9.0
Bundle complete! 1 Gemfile dependency, 7 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
```

If our `ls` is in the directory, we’ll see `Gemfile.lock` created automatically. We’re not supposed to modify this file with our code editor. It gets updated automatically by the `bundle` command if needed. Lock-file locks our application to a specific version of the library so that the app will work forever. Imagine a scenario 30 years from now, where we need to execute the same program. Our `Gemfile.lock` will come into play and help our program run effectively. Unless we explicitly update our dependencies, we’ll stick to the specific version of Rspec (or any other library).
 
We should have three files in our directory: `.ruby-version`, `Gemfile`, and `Gemfile.lock`. We can type `ls -a` to get the full list. We need to specify the `-a` (all) parameter, so the list hides the dotfiles as well, including `.ruby-version`.
 
If we type `gem which rspec`, we’ll see the exact path where Rspec has been downloaded. It’s outside our project, and it is understandable because we might want to use it in another project on the same computer.
 
`rspec --help` requires `rspec --init` to initialize the project:
We have two more files, `.rspec` and `spec_helper.rb`, and one `spec` directory. Simply put, “spec” is a specification, or “test.” Developers often use the words “spec” and “test” interchangeably.
 
`.spec_helper.rb` is quite lengthy, about one hundred lines, but is mostly made up of comments. It’s an auxiliary file that aims to provide a way to tune Rspec to our needs. We’ll skip doing any adjustments for now. Let’s look at the file structure of our newly created project:


```shell
$ rspec --init
  create   .rspec
  create   spec/spec_helper.rb 
```

We have two more files, `.rspec` and `spec_helper.rb`, and one `spec` directory. Simply put, “spec” is a specification, or “test.” Developers often use the words “spec” and “test” interchangeably.
 
`.spec_helper.rb` is quite lengthy, about one hundred lines, but is mostly made up of comments. It’s an auxiliary file that aims to provide a way to tune Rspec to our needs. We’ll skip doing any adjustments for now. Let’s look at the file structure of our newly created project:


Learn what Rspec is and how to use it to test Ruby programs.


Rspec Testing Framework

Learn what Rspec is and how to use it to test Ruby programs.

Before We Begin

First Steps

Fundamentals of Ruby

Conditional Statements

Operators and Methods

Arrays

Hash

Fun with Object Oriented Programming

Debugging in Ruby

Ruby Version Manager

Testing Ruby Programs

Wrap Up!

Appendix

Rspec Testing Framework

Popularity of Rspec