OmbuLabs Blog

In a recent project for OmbuLabs, we were looking for a payment solution that allows users of our platform to easily start accepting online payments while at the same time allowing us to collect a fee from each transaction they receive. That’s where Stripe Connect came into place.

In this series of code refactoring posts we are discussing how design patterns can be used to make our Ruby code beautiful, maintainable and clean.

Today I want to talk about a pattern that can be very useful when we need to control the flow of a set of events of our objects: The State Pattern a.k.a Finite State Machine.

As a developer it is common to see objects changing their state. At the beginning managing the state of an object can be as simple as having some boolean attributes where you can check if the object is in state A or B. But when the complexity increases you can end up with a number of states that are difficult to manage without breaking the SOLID principles. That is where we can implement the elegant solution provided by the State Pattern.

At OmbuLabs, we are big fans of Ruby on Rails and design patterns, especially convention over configuration! The beauty of Rails is that you can inherit a legacy project and easily find the different layers of code in different directories.

When it comes to database migrations the policy of Rails is very clear. It’s all about altering the database structure with gradual migration files: “Migrations are a convenient way to alter your database schema over time in a consistent and easy way.” (source)

But, what about data migrations? What’s the best way to write, maintain, and run migrations that alter the data in your production database?

In this article I will talk about three different patterns for writing and maintaining your data migrations:

1. Data migrations in db/migrate
2. Data migrations with a set of Rake tasks
3. Data migrations with data_migrate

At OmbuLabs, we like to split our time between working on our own products, open source and client projects.

Our own products include everything from OmbuShop, an e-commerce platform, to FastRuby.io, a Ruby on Rails upgrade service. In terms of open source, we recently created Audit Tool and are constantly searching for more projects to contribute to. We also work on a variety of interesting client projects, and with our current team size, like to take on two to three of them at a time.

As an Account Manager, it can get hectic trying to manage all of this. Google Calendar can be a serious help.

If you’ve been a web developer for any length of time at all these days, you’ve no doubt used at least a few web based APIs here and there. It’s possible that you’ve even written one (or more!) yourself. API design is a rich topic with a lot of deep roots, but some cursory research will show a number of best practices that public facing APIs should implement. Understanding these practices will give you a firm basis for judging the quality of APIs as a user and consumer, and allow you to design more useful APIs when it’s your turn.

If you’re looking for services that handle the delivery of your emails and SMSs in your app, SendGrid and Twilio are some of the most complete options out there.

In this article we are going to focus on a common scenario when using those services: How can we have a real time status of the emails and text messages that we send from our Rails app.

At OmbuLabs, we have a number of tools that help us to keep organized, write better code and communicate more effectively with our clients.

If you are interested in Ruby and Rails performance, you have definitely read articles by Nate Berkopec from Speedshop. At Ombu Labs we are big fans of his work, his Complete Guide to Rails Performance book and Slack community.

When Nate announced a series of public workshops I didn’t hesitate and signed up as quickly as possible. Here are my notes from my experience at the workshop on October 17th.

When starting a new software development project with a client, it is important to get started on the right foot. The way you communicate with a client at the beginning of a project can set the tone for how communication will be throughout the project.

Therefore, at OmbuLabs, we believe it is crucial to start off every new project with a Kickoff Call, where we can take time to get to know the client’s team and speak in depth about their goals and priorities for the project. We like to discuss the following list of topics with clients during our calls:

The internet is a wonderful place, but there will always be people that don’t have good intentions when they visit our websites. That’s why you need to be aware of the vulnerabilities that your application can have and how to avoid them. In this article I’ll cover two common security problems in Rails applications (I’ll probably make a second part since this is a very extensive topic).

In our last article of the refactoring series we saw how design patterns can be used to make our Ruby code beautiful and clean. Design patterns are a powerful tool for any developer and a familiarity with them will lead to better code by forcing a consideration of SOLID principles.

Now let’s talk about other pattern that when properly used can be very helpful: The Template Method.

At OmbuLabs we believe that if we are not learning from our mistakes we are doing it wrong. It is simple: The only unforgivable mistake is to not learn from our mistakes.

That is why we try to incorporate feedback into everything we do. We embrace peer reviews and pair programming as a way to get constant feedback on a daily basis. Even this article had reviews from 3 different people! (https://github.com/ombulabs/blog/pull/154)

Another step that we incorporate into every client relationship is an exit call. This call gives us an opportunity to assess how well we performed.

If we performed well: Great! What can we do more of? If we performed poorly: What can we improve? What can we do to make it better for our next project?

We like to use GitHub to its full potential at OmbuLabs, so any tool we add to the toolset needs to integrate nicely with it. As a growing agency working in larger and increasingly more complex projects, we need a project management tool that allows us to keep track of our work and plan accordingly. For this, we use Pivotal Tracker.

There are many things that are easier with Pivotal Tracker, as long as you are using it the right way. Some of its features are very useful for agile teams like ours. This is how we like to use it to ship value with every sprint and keep track of our team velocity.

Transcript:

Hello and welcome to the first OmbuCast by OmbuLabs. In this screencast we’ll be taking a look at the derailed_benchmarks gem, and how you can use it to benchmark your Rails application and find, and hopefully fix bottlenecks in your code.

Code refactoring can be defined as “the process of introducing small and incremental changes to leave the code in a better state than it was.”. When refactoring your code you have to consider two things: no new functionality should be added and the external behavior should not be affected.

One of the biggest challenges as a Ruby on Rails Developer is to keep your code clean, simple and easy to maintain and that is why we are always refactoring our code.

There are several techniques that a developer can follow to improve their code by code refactoring, such as extract method, move method, move field, switch statements, etc. If you are not familiarized with them, please visit the Refactoring Guru site.

Another technique developers try to follow is to apply good design patterns to their code. In this post we’ll try to go over some of the documented design patterns and how you can apply them to your Ruby code.