I’ve been refactoring quite a bit of legacy code recently. I love this kind
of work because you get to setup new patterns and code pathways for future developers to use. Right past mistakes and make the future of the application just a bit brighter. My most recent refactoring involved converting an Enum based architecture to utilize Rail’s Single Table Inheritance setup. So what does it take to move from one architecture to another? Keep reading to find out strategies that I use to help keep bugs to a minimum while ensuring that end-users experience zero downtime.
I’m by nature a kinesthetic learning or someone that learns by doing. One of the
ways I learn new Ruby codebases or techniques is to dive into them and see how
they work during every step of their processing. Pry is a great tool for allowing me to
dig directly into code. While, really useful for debugging and understanding, one
thing that has bothered me about using Pry is that it doesn’t work properly with classes
that inherit from SimpleDelegator. Instead it ends up in a method_missing block. Luckily,
I recently learned a great workaround for this issue which we’ll get into below.
The beginning steps to writing a new class usually involve writing a quick
def initialize method. The purpose of these type of methods is to
setup any dependencies or configurations necessary for the object to fulfill its
responsibility. With instance variables, a common paradigm is to use an attr_reader
or attr_writer to read/write values. However, these methods specifically work
off of instance variables.
SublimeLinter is an excellent tool for linting new code quickly and efficiently. Version managers like rvm, nvm, and asdf are also great tools for smoothly switching between projects with different version requirements. Getting both SublimeLinter and version manager to play nice can sometimes be challenging. I’m going to quickly talk about the simple steps I took to getting ESLint and asdf to work with SublimeLinter below.
When dropping a database table in a migration all data contained within the dropped table will be lost as well. This is to be expected since the table schema no longer exists. However, it is possible to make such a migration reversible so that at least the database structure is preserved.
Deploying a new blog with Github Pages is a breeze. All you need is a new repo named after your Github username and a jekyll site on your master branch.
Github also kindly provides several whitelisted plugins for ease-of-use which can be found here. Unfortunately, some of these are a bit outdated (I’m looking at you jekyll-paginate). More bad news is that because the plugins are whitelisted you can’t use any other plugins.
We’re developers though, like a whitelist will stop us…
Recently, I ran into an issue with migrating data from one table to another incorrectly set the sequence for the new table’s primary key. The issue stemmed from inserting all the data from one table into another.
If you’ve ever used Heroku’s low cost staging plan for Bonsai Elasticsearch you may have
ran into the following error: reached maximum index count for current plan.
Since in most cases your staging indices aren’t as critical as say production (don’t use
the fix below in production, please!), you can safely follow the procedure below for
removing and reindexing your search enabled models.
Find your Elasticsearch URL
First you’ll need to find your Elasticsearch url. If you are using the Bonsai
addon from Heroku you can do so in your terminal with:
If you don’t know what your environment variable is for BONSAI then you’ll need
to go into Heroku’s web UI and look at the config variables for it. It should
be in the format of BONSAI_PLANNAME_URL.
Delete all available indices
The next step is to remove all the available Elasticsearch indices.
WARNING DO NOT RUN THIS IN PRODUCTION! PLEASE, PLEASE, PLEASE DON’T DO THIS.
We offer a low cost staging plan for development and testing - Heroku
You can read more on this in Elasticsearch’s documentation.
This can be accomplished via cURL, which you’ll also need installed, from the following:
Reindex all search enabled models
Lastly, we need to reindex all of your available models. If you are using Searchkick you can accomplish this
by running the following command. This will run through all of your searchkick
models 1-by-1 and reindex them. Otherwise, you’ll need to reindex your content
based on whatever method you have configured.
That’s it! You now have removed all the current indices and reindexed with new ones. Start searching!
Having confidence in your application helps with the aid of great interation tests.
For Rails, that means utilizing the Capybara gem for testing features from end-to-end.
While Capybara is a great gem for accomplishing this goal, it can be at time difficult, frustrating, and
nuanced in its implementation. I’ve been keeping track of all the tricks I use reguarly and compiled a
list of the best ones. Hopefully, this helps give some clarity to a few best practices I use on a daily basis.
Have you ever needed to gather a large amount of data from your production server but didn't have the script available on the server? You could remote into the server and write the script in rails console but what if the volume of data was in the hundreds of thousands? And you needed it in CSV format? Well, recently I recently discovered a great little command for gathering remote data and saving it to a local file.