Developing Ruby on Rails applications in large teams can be frustrating when team members use different operative systems, languages, timezones, etc.
Docker is a great tool in these situations because it synchronises your team with the same setup for everyone collaborating on your project. That's fantastic!
Active record makes it easy to write simple queries anywhere in your application. The key phrase here is anywhere in your application: When database queries are scattered throughout your application, simple database changes may require modifications to your controllers, your views, helpers, mailers, etc.
ActiveRecord provides you with
scopewhich allows you to hide the details of your schema so that database changes don't affect the entire application.
Stripe has a great API to manage subscription payments. Here we take advantage of it to implement recurring subscriptions in Rails 5.
Using the Stripe API means we do not have to store sensitive customer information like (credit card number or CVC), and the APIs are already set up to handle complex cases such as update plans, manage subscriptions, trigger refunds, and more.
Here are a few small hacks I have discovered over the years to streamline your Ruby projects.
Many projects require a method that takes a date as a parameter and returns the date if it is valid and false if it is not. This method should also not raise an exception.
As your audience grows, it is important to ensure that your website or application can be used by everyone - specifically people with permanent or temporary disabilities. This is often referred to as accessibility (or A11y as an abbreviation), and is a requirement for all modern websites or applications.
Today I will share with you how I approach reverse geocoding using the Geocoder gem.
As you may know, the Ruby gem Geocoder allows you to do reverse geocoding "automatically" in the model by doing
reverse_geocoded_by :latitude, :longitude. That is cool, but I found a better way...
When working in the Rails console, I tend to build up commands over time that I run often. These might be for resetting data, fetching something from an API, generating tokens, etc. Multiple times a day, I find myself holding down the up arrow on the keyboard until I find the last time I ran it, so I can run it again. Usually, there will be multiple commands that need to be run in sequence, which get concatenated together with semi-colons so they can all be run in one go. I don't know for sure, but I imagine every developer does this.
As an example, right now I'm working on a project that calls a large number of API endpoints on various different microservices. These all require authentication via a JWT token. We use Her (an ORM for making requests to REST APIs and representing their responses with Ruby classes and objects). We have some Faraday middleware that adds the JWT token (stored in RequestLocals) to the Authorization header to authenticate the requests with the microservices. This means that when I am testing these API calls in the Rails console, I need to fetch a JWT and store it in RequestLocals.
Are you struggling to choose between ActiveAdmin and Rails Admin? Just to confuse you further, there is now a third option:
So, apart from an admin interface, what is Wallaby? The core design is that:
Action Cable is an awesome feature that uses Web Sockets to realise a real time application in Rails, and includes both the back-end and the front-end. In this article, we will use only the server side of Action Cable in Rails and client-side in AngularJS 1.x. This is not a step-by-step tutorial, but it is intended to help you to understand the purpose of each step.
The first thing we need to do is enable Action Cable in our back-end app. The simplest way is to mount action cable in the
Recently, our founder and CEO, Mikel Lindsaar spoke at the Ruby Developer Summit on Standard Development. He discussed the role of testing in project work, and talked about when you should follow the textbook approach and when it might be better to relax those rules. You can watch his talk on our youtube channel.
This blog post details my thoughts on how to approach writing tests. To illustrate, I'll be using a Ruby/Rails example as Rails is a framework that embraces the culture of testing. However, I believe these concepts can be adapted to any language.