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.
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
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?
In preparation for my talk at RubyConf Australia this
month, I've been working on a way to make it easy for anyone to run
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 is an article about the process that I followed and how you can use it in your own
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
skunk, a gem to calculate the StinkScore
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
Here is a description of the problem and solution.
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 Stink Score Calculator!
I'll explain why we need it, how it works, and the roadmap for this new tool.
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
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
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
I recently wrote a spec for
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.
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
After years upgrading Rails applications,
we learned that the best way to isolate our client projects' environments is
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
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.
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.
RailsConf 2019 is right around the corner. That means
Rails 6.0 is right
around the corner! Rails 6.0's beta has been available since January 18, 2019. Rails 6.0.0.rc1
was released today! 🎉
In this article I will explain how you can dual boot your application in your
local environment and your CI server. I hope that this will help you get ready
for the next stable release of Rails.
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
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
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 Ombu Labs 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.
where instead of
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.