When you think of refactoring, you imagine it in the context of TDD. Before working on a feature, you first write a failing test. Then you make it pass by writing code that implements that feature. Finally, you refactor the working code to make it more readable, clean, and beautiful.

In our industry, it’s known as red-green-refactor. You start with red (failing test), and move to green (working code) code, ending with refactored code with a better design. However, there are some other times when refactoring code can be very useful. This post explores a few.

Learning the Linux command line, like becoming an accomplished pianist, is not something that we pick up in an afternoon. It takes years of practice.

The Linux Command Line, William E. Shotts

Since I switched to Ruby on Rails from .NET, I find myself increasingly using the terminal every day. One thing I’ve realized as a Rails developer is that you need to have some basic competence with the terminal, as you will use it all the time. So I spent some time getting familiar with some basic Linux commands, and this post tries to summarize the essentials.

This is not a comprehensive list, but I will try to keep adding to this list as I learn more. If you want a detailed overview of Linux operating system, I highly recommend The Linux Command Line, 2nd Edition by William E. Shotts.

Here’s how you can to compress and archive files on a Linux server or on your Mac.

gzip file compresses the file. To keep the original file, pass the -k flag.

gunzip uncompresses a .gz file.

However, gzip doesn’t create archives of files, i.e. it doesn’t pack multiple files and dirs into a single file. For that, use the tar command.

tar command creates an archive.

tar cfv archive.tar file1 file2

The c option requires creating the archive, the v option requests the verbose operation, and the f option takes an argument that sets the name of the archive to operate upon.

The following command instructs tar to store all files from the directory /etc into the archive file etc.tar, verbosely listing the files being archived:

tar cfv etc.tar /etc

To unpack a .tar file, use the x flag, which operates tar in extract mode.

tar xvf archive.tar

To unpack a compressed archive, first uncompress the file and then unpack.

gunzip file.tar.gz
tar xvf file.tar

Or, use the shortcut with the z option that does the same.

tar zxvf file.tar.gz

Hope this helps.

In Rails, if you want to run a specific test without the others in the file, you can pass the method’s name to the --name flag.

def test_controller_name
  # assert ...
end

>  ruby -I test test/controller/renderer_test.rb --name test_controller_name

But, Rails also provides a test method that takes a test name and a block.

test "creating from a controller" do
  # assert ...
end

How do you run this test that allows you to pass a string containing spaces?

If you’ve been working with Ruby on Rails for a while, you’ve come across Rake. Written by the late Jim Weirich, Rake is to Ruby what Make is to C. It’s very easy to create custom Rake tasks to simplify your development workflows. Rails even provides a generator (rails g task) to create them for you.

However, one question that many new Rails developers (including myself) have when learning Rails is how to access the Rails environment in a Rake task, which is very useful for accessing the ActiveRecord models or performing database queries. This article shows how to do it.

Let’s say you have a Product object with properties @name = "Table" & @price = 10. What’s the best way in Rails to convert this object to the Hash { name: "Table", price: 10 }?

In Ruby, if you want to access hash values like methods on an object, use ActiveSupport::OrderedOptions. This class inherits from Hash and provides dynamic accessor methods.

Although Ruby on Rails provides great defaults out-of-the-box, you can easily extend Rails using Ruby gems. Here are eight gems that I find myself using every time I start a new Rails project.

Gerald Weinberg, one of my favorite technical authors, wrote a book titled The Psychology of Computer Programing decades ago, in 1971. This book is timeless because it explains computer programming as a human activity.

I read this book a few years ago. Recently, when I was browsing through my kindle, I stumbled across and reread a few chapters that teach the importance of reading programs and explain what makes a good program. This post is a short, condensed version of those chapters. The language, of course, is a bit dated, but the lessons are timeless.

Enjoy reading!

In the last post in the Turbo Internals series, we saw how to set up the Turbo source code for debugging and development. In this post, let’s dive into the codebase and try to understand the sequence of events that take place when you click a Turbo link.