Anthony Panozzo's Blog

This guide represents my current best understanding of how to get productive with an existing Ruby on Rails app. I currently work in a consulting / contracting role on various web development projects, and this general process would work with other frameworks similarly. I thought about the process that I go through (or would like to go through) when starting to work on an existing Ruby on Rails project, and wrote down those thoughts. Afterward, it seemed valuable enough to clean up a little and publish.

In this post I won’t cover getting a legacy project’s tests up to snuff. I also will not cover taking an existing Rails project and upgrading it to the latest version of Rails. There are existing resources that already cover this.

So what will I cover?

Let’s pretend you are starting to work on a Rails project today and this isn’t your first Rails rodeo. However, the project that you are starting on has been in development or on production for months or years. How do you quickly get up to speed to make a contribution, and how do you not break everything in the process?

This project could have been unmaintained for a little while. You could be joining up with an existing team. It could have been outsourced and in disrepair. It could have been insourced and in disrepair. :) It could be well-tested or have no test coverage. But someone, somewhere, cares about this project, or you wouldn’t be working on it. Where do you get started?

Overview

The first thing to do is to understand what the project does at a high level. This might seem obvious, but still important. Questions to answer include:

• What value does this project have to the business that owns it?
• What is the primary functionality of this project?
• Where does this fit in with the company’s other projects / products?
• Who uses this app on a daily basis?
• How many people use this app on a daily basis?
• What is the history of the project development?
• If the old developers are still available, can you contact them?

Once you have this information, you have a better understanding of the context of the project and those things most important to keep running.

Get Access

You can’t get very far without having access to anything important. You’ll eventually need access to:

• source control (Github)
• project management (Trello, Jira)
• team communication tools (Slack, Teams, Zoom)
• supplementary docs (Google Docs, Notion, wiki, Miro)
• deployment credentials (Heroku)
• error notifications (Airbrake, Exceptional, Honeybadger)
• storage credentials (AWS)
• end user message apps (Helpscout)
• performance monitoring (New Relic)
• continuous integration (GitHub Actions, Jenkins)

I would generally send out one email to whoever should have most of these and see if you can get credentials or get your account added. I would then make a document that has all of these services in one list, and then whenever you onboard a new developer you can add them more quickly the next time.

Reading the Fine Manual

After understanding the project, the next thing to do is to look at the clues previous developers have given you. Sometimes you get the dreaded Welcome to Rails documentation, but often your predecessors or teammates have left a breadcrumb trail of how to get up and running on the app.

I run the continuous integration server Jenkins on my local development machine to work as a better cron. I actually run the Jenkins LTS (long term support) version since it is designed to be more stable than the developer release line.

From the Jenkins LTS docs:

Jenkins produces a new release weekly to deliver bug fixes and new features rapidly to users and plugin developers who need them. But for more conservative users, it’s preferable to stick to a release line which changes less often and only for important bug fixes, even if such a release line lags behind in terms of features.

I’d rather have stability than blazing edge features for something that is just supporting infrastructure. Since I am using a Mac, it would be nice to install this using Homebrew. The homebrew-versions keg has a version of this, so you can install it from there with:

$ brew tap homebrew/versions
$ brew install jenkins-lts

Then you can run it with the commands listed at brew info jenkins-lts. By default, jenkins-lts will have a plist to control startup and teardown of the Jenkins process at ~/Library/LaunchAgents/homebrew.mxcl.jenkins-lts.plist:

This blog used to run on WordPress, but I was not entirely happy with it. I changed it to use Octopress (an extension of Jekyll) and I enjoy the writing workflow better now.

WordPress is a content management system, and as such, it does a whole lot of stuff. WordPress has a ton of built-in functionality and is well-tested. With plugins, you can add many things: from shopping carts to calendars to image slide shows. Other plugins can give you detailed permission models and auditing for posting or other complex functionality.

Advantages

I didn’t like WordPress for blogging for a few reasons (many of them very specific to my workflow.)

I prefer writing with Vim, and no WordPress functionality was going to easily replace this tool. This alone would probably be enough to get me to switch. Typically what I would do would be to compose a post in Vim, and then copy that into WordPress, do a little previewing to make sure everything looked good, then schedule the post for some future date.

Using a static site generator like Octopress or Jekyll enables me to use git. Git tracks detailed version changes across the entire blog (not just the posts). It also lets me work locally and then easily deploy when I am back online or finished. With WordPress I would have to connect to the server to be able to write. I can now even preview locally, something I could never do without an internet connection. Further, I can set it up so that preview updating happens whenever I save the file, so I can see how changes look in near-real time.

I’ve been doing a fair amount of flying in the last year, and Southwest is currently my favorite airline. In this post I will list reasons why Southwest is the best (in order of importance) and one thing I’d like to see improved.

Biggest Benefits

Liberal reschedule policy

Probably the biggest benefit to me has been Southwest’s liberal flight rescheduling or cancellation policy. On many other airlines, changing or cancelling your flight reservation (whether it is days or months away), will cost you hundreds of dollars. Have something come up at the last minute? Well, you’re out a hundred bucks to change your flight by an hour or two. You can pay much more for a refundable ticket as well.

Southwest does not have this restriction, so even if you pay a little more for your ticket, if you use this option one time, you are going to come out ahead. Worst case, if you cancel, you get a credit to apply to future Southwest flights.

I tried a new tool with Kyle Shipley recently, and it has proven to be interesting and useful.

Floobits is a recently-created remote pairing solution. Imagine wanting to pair with someone and they are across town or in another state.

I enjoy pairing remotely, as it lets multiple people work together even when they are not colocated. I think that pairing is a great way to share knowledge on a team and reduce defects by promoting accountability and quick feedback. Further, I think that remote worker morale increases when talking and working with teammates.

Kyle and I used Floobits to pair on a random coding project, and I found the entire experience compelling enough to get past the set up and some early wrinkles. With Floobits, you create a shared workspace that other people can view (public or invite-only). You install a plugin to your editor and maybe a custom build of the editor. Then when you make changes to the file, diffs of the code are sent up to a server, which then propagates to anyone connected.

Existing solutions

There are some solid existing solutions out there like sharing tmux or screen sessions.