Ruby on Rails — Final tips (part 5)
Tips to facilitate working, deploying and maintaining your Rails project.
Hello again! After a pause for some well-deserved vacations 😎, we’re back with a few final tips for your daily Rails life. Hopefully, they’ll make you more productive and focused on delivering the best product your users can have.
If you haven’t followed our entire series check the previous posts to learn even more: 🤓
Part 1: Handling data on Rails
Part 2: Front-end Tools
Part 3: Advanced Tools
Part 4: Testing and code quality
In this wrap-up, we’ll be talking about some tools to facilitate working, deploying and maintaining your project. In the end, I’ll also share a few useful websites that get me going when I need to lookup libraries or better understand Rails’ intrinsics. Let’s dive in. 🌊
Environment variables 🔒
Sensitive information like passwords and other credentials should never be committed to your git repositories, I’m pretty sure you know that. Thus, frequently people fallback to load such values from environment variables. dotenv is a ruby gem that aims to make things smoother, providing you with a way to define env variables in files that you can make git ignore. This way no sensitive info is shared in your repo and you still have a nice way to work locally without setting up variables system-wide. You can have environment-specific files, override variables by following the precedence the gem loads those files with, and much more.
Figaro is focused on Rails apps and does pretty much the same thing as dotenv. It consists of a single YAML file where you can define your environment variables — you can also define environment-specific variables — and when you’re running your app it will look like they came from ENV. If you’re using Heroku, Figaro has a neat tool for setting up the environment variables in there for you, which might be a plus when comparing it with dotenv.
Finally, if you’re just starting a new Rails project or planning to update a current one, Rails 5.2 ships with a new feature to help you on this matter. Rails credentials allow you to keep all your sensitive data written in an encrypted file that you can safely commit into your repository. In order to do that, you need a master key file (or environment variable) set up, that is used to decrypt the credentials from the encrypted file when the app runs. You can structure the credentials YAML file as you wish (e.g., with environment namespaces) and use Rails.application.credentials to access your variables, instead of ENV. Our favorite way of keeping secrets from now on. 😋
Deployment automation 🚀
If you’re setting up your own production environment you probably figured already that you need a way to continuously update your app as you keep working. Capistrano will most likely be your best friend from now on. With very reasonable defaults, it will let you deploy a simple Rails application with almost no configuration other than your git repo URL and your web server address. On the other hand, it’s a really versatile tool, that lets you deploy your app into different hosts if you want to distribute your workload, supports multiple stages and keeps your downtime to a minimum when deploying. There are lots of plugins for Capistrano and if you need to attach some behavior to a deploy you can always write your own scripts and have them run before/after specific deployment steps.
Mina is another tool for deploying your app. Like Capistrano, it’s an SSH-based tool that will pull code from your git repo and run all the necessary steps to have your project running in a web server in production mode. The configuration file is very similar to Capistrano, so if you’re still deciding which one to use, you won’t spend much time moving from one to the other in case you need. Mina has a lot of users already, which means you’ll find a fair amount of 3rd party plugins for managing the more common tools you need around a Rails app. Personally, I’ve never tried Mina but I’m looking forward to giving it a try in a future project. 🤞
API-only app ⚙️
If you’re building a backend for mobile and/or web apps and you wished you could have a simpler version of Rails for that, wish no more. 😅 Rails ships with an API-only mode, in which you still get most of the perks without the overhead of having the view layer attached. You can easily convert an existing Rails app into an API-only app, just by changing a few configs if you want. You can remove middleware included by default, and also add middleware you might need in your controllers for your specific purposes. Definitely, something to try out if you’re creating a JSON API and you’re already familiar with Rails.
Other tools 🛠
When your project starts growing you will need a lot of different tools running in order to mimic your production environment. Let’s say you have a detached React app, that locally is provided by webpack-dev-server, you have some Sidekiq queues for background processing, and for those you also need Redis to be run. All of this plus your rails server, of course. I bet you have a lot of console tabs to look at right now. 🤓 Foreman is a tool that allows you to define multiple processes to run in a Procfile. When you run Foreman against a Procfile it will start all the commands you listed, and have them nicely outputting in the same console window with different colors. It’s a great way to have all the logging accessible in the same place.
When you’re integrating an external service it’s not unusual that you need to receive some callbacks. When developing locally you’ll have a hard time trying to do that. ngrok is a tool that provides you a way to route traffic from an HTTP(S) address to a specific port on your localhost server. This way, you can use that address when setting up your callback URL in the external service, and you’ll receive the callbacks right inside your Rails app. Cool, right?
On the other hand, if you’re focused in the frontend and you would like to have Rails info available from inside a Google Chrome instance, this is your lucky day! RailsPanel is an extension for Chrome that will add a new Rails tab to your developer tools panel. It provides detailed information about all the requests to your Rails app, like the incoming params, the database queries performed, rendering time and more. A must-have if you don’t want to leave the browser to discover what went wrong. 🤫
Last, if you need to write a long-running task and you’re thinking about a good way to display its progress, don’t bother. 🙈 Someone already did that for you, and it works really well. Ruby/ProgressBar is a handy way to provide that feedback, with lots of customization and formatting options. It can even display an estimate on the remaining time for you, based on the total you defined and the elapsed time. 👏
Wrap up
It has been quite an adventure to share the tools we use in our RoR projects with you, trying to find alternatives and other stuff worth mentioning. I hope you guys enjoyed the ride as much as we did! This work would not be possible without a few websites that are absolute go-to’s when it comes down to Rails, namely:
RoR Guides — the best place to learn everything there is to know about Rails. Really! The official guides are very rich in information and will provide you useful tips along the road, every time you need to clear something up.
RubyGems — the place where Ruby gems are hosted. Here you can quickly lookup gems, find out their latest stable version and even grab a ready to paste version locked snippet for your Gemfile. 👌
The Ruby Toolbox — a nice way to discover new gems either by searching and looking up alternatives or simply by browsing the many categories available. The details of each gem display the essential information you’ll need to make up your mind.
Aaaaand… that’s it, for now. 😄 If you have other great tools that improve your work, please let us know in the comments.
Deemaze Software is a digital agency developing products for web and mobile. We do a lot more than sharing awesome Rails tools, so stay up to date with our work on Twitter, Facebook and Instagram.
See you around! 🖖
