Sometimes you will be caught between a rock and a hard place. For example: You
really need to upgrade your Rails application because Heroku is discontinuing
your stack in two weeks so you don't have the time to write an entire test
suite.
Sometimes the situation will be that your boss really needs you to upgrade Ruby
or Rails to use a version that gets security updates and they won't allow you
to write tests beforehand.
This article will explain how to ship a Rails upgrade project without a test
suite. If your application has no tests, you will learn how to upgrade without
having to write tests first.
Read more
When inheriting a project or starting an upgrade, it is useful to understand how big and complex the
application really is. So, what is a good way to understand whether a Rails
application is tiny, medium, or huge?
The good news is that there are a couple of gems that make this easy for us.
In this article I will explain how you can use these gems to begin to understand
the size and complexity of a Rails application.
Read more
At FastRuby.io we are constantly looking at code coverage metrics for Ruby on
Rails applications. It's a key indicator for us. We even use that information
to decide whether we work on a Rails upgrade project or not.
So, I was interested in seeing code coverage metrics for the Ruby on Rails framework.
I couldn't find any information about this online, so I decided to generate a
few reports for each component.
This is an article about my process and my findings.
Read more
Churn vs. Complexity analysis is a great way to find insights about the
maintainability of a project. Two of my favorite authors have written great
articles about the Churn vs. Complexity graph:
This two-dimensional graph can be very useful in finding the files that are the
hardest to maintain in your application. In this article I will explain:
- How you can calculate these metrics and use them in your legacy project
- How code coverage metrics can guide your technical debt's collection efforts
Read more
There are some really great guides for starting a new open source projects,
yet when it comes to dealing with a possibly abandoned, unmaintained project,
there is no definitive guide for users, contributors, or maintainers.
I hope that this can be a useful guide for our community.
Problem
When do you declare that an open source project has been abandoned? How many
days have to go by until you start maintaining your own fork? What's the
standard for communicating with maintainers, contributors, and users? How do
you avoid n
competing OSS forks of popular projects? How do you avoid
duplicated work by people who want to maintain popular, but unmaintained OSS
projects? What's the best way to find that one fork everybody is using?
Read more
Right before my talk at RubyConf Australia,
I worked on a way to make it easy for anyone to run skunk
in their Ruby projects. In order to do that I decided to use GitHub Actions.
It's a powerful service by GitHub and it's quite easy to set up.
This article is about the process that I followed and how you can use it in your own
application.
Read more
This year I had the honor to speak at RubyConf in Nashville.
It was my second time attending the conference and first time as a speaker. I
talked about skunk
, a gem to calculate the SkunkScore
of a module or set of modules.
Since its inception, skunk
has changed quite a bit based on real usage in
our productized service for Rails upgrades. As a matter
of fact, the night before my talk I realized there was a BIG error in our
formula.
Here is a description of the problem and solution.
Read more
Two weeks ago I had the opportunity to speak at Solidus Conf 2019.
I presented Escaping the Tar Pit
for the first time and I got to talk about a few metrics that we can use to
quickly assess code quality
in any Ruby project.
In this article I'd like to talk about Skunk: A SkunkScore Calculator!
I'll explain why we need it, how it works, and the roadmap for this new tool.
Read more
Every time we evaluate a new project we follow a well-defined process to decide
whether we take it or not. We analyze its dependencies; its code coverage; and
its code quality to determine the amount of tech debt in a project. We have been
using CodeClimate to assess code quality
and SimpleCov to assess code coverage.
In my previous article I wrote about free and open source Ruby gems we can use to assess code quality for any Ruby or
Rails project. After writing that article, I found that RubyCritic
was really interesting and its community quite active, so I thought it was a good
idea to add SimpleCov
support to it: https://github.com/whitesmith/rubycritic/pull/319
Read more
As part of our Rails upgrade business we get to evaluate
a lot of codebases every month. We usually need a quick way to assess the quality
of the code we get. For this we like to use CodeClimate
and SimpleCov.
CodeClimate is free for open source projects and paid for private projects. I
know that not everybody can pay for their service, so I thought it was a good
idea to share some free, open source alternatives.
Here is a list of 3 tools that can help you assess the quality of your next
codebase.
Read more
I recently wrote a spec for metric_fu
which
accidentally introduced a non-deterministic spec
(a flaky spec!). I had no idea why it was randomly failing. This is an
article to explain the process I followed to debug this issue.
Read more
Every time we start a new Rails upgrade project,
we need to setup a whole new environment in our local machines. Sometimes that
leads us down the rabbit hole which ends up breaking our environment for other
client projects.
After years upgrading Rails applications,
we learned that the best way to isolate our client projects' environments is
using Docker.
That's why we decided to use Docker and docker-compose
for all of our client projects. This year I had the opportunity to share our
process in a series of workshops:
Upgrade Rails 101: The Roadmap to Smooth Upgrades
Read more
This year's RailsConf was a special conference for me.
It was my third time attending and my first time speaking at the conference. I
conducted a 2-hour workshop for anyone interested in upgrading their Rails
application: Upgrade Rails 101: The Roadmap to Smooth Upgrades
Here are a few lessons learned from running such an ambitious workshop.
Read more
This is a short post to show the compatibility between Ruby on Rails
and Ruby across different versions. In the
process of upgrading really old applications to more modern versions of Ruby and
Rails we have ran into a lot of these combinations.
Read more
In this article I will explain how you can dual boot your application in your
local environment and your continuous integration (CI) service. I hope that this
will help you get ready for the next stable release of Rails.
Read more
I had to come up with a clever title because this article is about legacy
Rails applications and I know that you might fall
asleep by the third paragraph. Boooooring... You probably want to read about
that new JavaScript framework that came out (I love that this sentence will
always be true, it doesn't matter when you read this)
If you have been working with Rails for a few years, you have seen your
fair share of shiny new applications, well-maintained and poorly-maintained
legacy applications. This post is about Legacy Rails applications
Read more
This article is part of our Upgrade Rails series. To see more of them, click here.
This article will cover the most important aspects that you need to know to get
your Ruby on Rails application from version 5.1 to 5.2.
Read more
This article is part of our Upgrade Rails series. To see more of them, click here.
This article will cover the most important aspects that you need to know to get
your Ruby on Rails application from version 5.0 to 5.1.
Read more
This article is part of our Upgrade Rails series. To see more of them, click here.
This article will cover the most important aspects that you need to know to get
your Ruby on Rails application from version 4.2 to 5.0.
Read more
Rails is a powerful framework. You can write a lot of features in a short period of time. In the process you can easily write code that performs poorly.
At OmbuLabs we like to maintain Ruby on Rails
applications. In the process
of maintaining them, adding features and fixing bugs, we like to improve
the code and its performance (because we are good boy scouts!)
Here are some tips based on our experience.
Prefer where
instead of select
When you are performing a lot of calculations, you should load as little as
possible into memory. Always prefer a SQL query vs. an object's method call.
Read more