Setting Up Your Development Environment

The day-to-day business of writing Rails programs is pretty straightforward. Everyone works differently, but here’s how we work.

The command line

We do a lot of work at the command line. Although an increasing number of GUI tools help generate and manage a Rails application, we find the command line is still the most powerful place to be. It’s worth spending a little while getting familiar with the command line on the operating system. Find out how to use it to edit commands that are being typed, how to search for and edit previous commands, and how to complete the names of files and commands as they’re typed.

Tab completion is standard on Unix shells such as Bash and Zsh. It allows you to type the first few characters of a filename, hit Tab, and have the shell look for and complete the name based on matching files.

Version control

We keep all our work in a version control system (currently Git). We make a point of checking a new Rails project into Git when we create it and committing changes once we’ve passed the tests. We normally commit to the repository several times an hour.

If Git isn’t familiar, don’t worry. This course gives an introduction to the few commands that are needed to follow along with the application being developed. If needed, extensive documentation is available online.

Note: If you’re working on a Rails project with other people, consider setting up a continuous integration (CI) system. When anyone checks in changes, the CI system will check out a fresh copy of the application and run all the tests. It’s a common way to ensure that accidental breakages get immediate attention. You can also set up your CI system so that your customers can use it to play with the bleeding-edge version of your application. This kind of transparency is a great way to ensure that your project isn’t going off track.

Editors

We write our Rails programs using a programmer’s editor. We’ve found over the years that different editors work best with different languages and environments. For example, a customer originally wrote this chapter using Emacs because they think that its Filladapt mode is unsurpassed when it comes to neatly format XML as they type. The other customer updated the chapter using Vim. Many think that neither Emacs or Vim are ideal for Rails development. Although the choice of editor is a personal one, here are some suggestions for features to look for in a Rails editor:

• Support for syntax highlighting of Ruby and HTML, ideally, support for .erb files (a Rails file format that embeds Ruby snippets within HTML)

• Support for automatic indentation and reindentation of Ruby source. This is more than an aesthetic feature. Having an editor indent your program as you type is the best way to spot bad nesting in your code. Being able to reindent is important when you refactor your code and move stuff. TextMate’s ability to reindent when it pastes code from the clipboard is particularly convenient

• Support for insertion of common Ruby and Rails constructs. You’ll be writing lots of short methods. If the IDE creates method skeletons with a keystroke or two, you can concentrate on the interesting stuff inside

• Good file navigation. As you’ll see, Rails applications are spread across many files. For example, a newly created Rails application enters the world containing forty-six files spread across thirty-four directories. That’s before you’ve written a thing.

  You need an environment that helps navigate quickly among these. You’ll add a line to a controller to load a value, switch to the view to add a line to display it, and then switch to the test to verify you did it all right. Something like Notepad, where you traverse a File Open dialog box to select each file to edit, won’t cut it. We prefer a combination of a tree view of files in a sidebar, a small set of keystrokes that help us find a file (or files) in a directory tree by name, and some built-in smarts that know how to navigate between, say, a controller action and the corresponding view.

• Name completion. Names in Rails tend to belong. A nice editor will let you type the first few characters and then suggest possible completions to you at the touch of a key.

To help you get started with something other than Notepad, here are some suggestions:

• Atom is a modern, full-featured, highly customizable cross-platform text editor.

• TextMate is the favorite of many programmers who prefer to do their development on macOS, including David Heinemeier Hansson.

• Sublime Text is a cross-platform alternative that some see as the de facto successor to TextMate.

• jEdit is a fully featured editor with support for Ruby.18 It has extensive plugin support.

• Komodo is ActiveState’s IDE for dynamic languages, including Ruby.

• RubyMine is a commercial IDE for Ruby and is available for free to qualified educational and open source projects. It runs on Windows, macOS, and Linux.

• NetBeans Ruby and Rails plugin is an open-source plugin for the popular NetBeans IDE.

Ask experienced developers who use your kind of operating system which editor they use. Spend a week or so trying alternatives before settling in.

The desktop

We’re not going to give instructions on how to organize the desktop while working with Rails, but we’ll describe what we do.

Most of the time, we’re writing code, running tests, and poking at an application in a browser. As such, our main development desktop has an editor window and a browser window permanently open. We also want to keep an eye on the logging that’s generated by the application, so we keep a terminal window open. In it, we use tail -f to scroll the contents of the log file as it’s updated. We normally run this window with a small font so it takes up less space. If we see something interesting flash by, we increase the font size to investigate.

We also need access to the Rails API documentation, which we view in a browser. In the Introduction, we talked about using the gem server command to run a local webserver containing the Rails documentation. This is convenient, but it unfortunately splits the Rails documentation across a number of separate documentation trees. If you’re online, you can see a consolidated view of all the Rails documentation in one place.