Take your Rails development to the next level

New UI Features for Schema Tracking and Migration Management in ActualDbSchema

2025-02-28 14:28:19 +0400T00:00:00-00:00

Hello, Rails developers! We’re thrilled to announce the release of ActualDbSchema v0.8.3! 🎉 This update brings new tools to visualize schema changes directly in your browser, clean up broken migrations, and customize your workflow. Let’s explore what’s new!

View Schema with Migration Annotations in the UI

Ever wanted to inspect your schema and trace which migration introduced a specific change directly from the browser? Now you can!

Navigate to the migrations page (http://localhost:3000/rails/migrations) and click the View Schema button to see the schema diff rendered in the UI, annotated with the migrations that created each change. In case there is no pending changes, the UI shows the entire schema.

Key Features:

Diff Highlighting: See schema changes alongside their originating migrations.
Filtering: Search for specific tables using a built-in filter.
Migration Links: Click any annotation to jump to the corresponding migration details.

Schema Page on the UI

Schema Page with Filter

Clean Up Broken Migrations

Managing old migrations can be challenging, especially when migration files go missing. In this release, we’ve introduced a Broken Versions page and rake tasks to clean up these records.

What Are Broken Migrations?

A migration is considered broken if it exists in the database but the corresponding file is missing. This can happen if migrations were deleted manually after being applied.

How to Delete Broken Migrations?

1️⃣ Using the UI

Navigate to the following URL in your web browser to see all broken migrations:

http://localhost:3000/rails/broken_versions

You can delete them individually or use the Delete All button to clean up everything at once.

2️⃣ Using a Rake Task

Run the following command to remove all broken migrations:

rake actual_db_schema:delete_broken_versions

To delete specific migrations, specify their versions:

rake actual_db_schema:delete_broken_versions["20250224103352 20250224103358"]

For multi-database applications, you can also specify the database:

rake actual_db_schema:delete_broken_versions["20250224103352 20250224103358", "primary"]

Filter Migrations in the UI

Tired of scrolling through hundreds of migrations? We’ve added a search bar to the migrations page, making it easy to find migrations by name or content. Whether you’re tracking down a specific change or reviewing past updates, finding what you need is now faster and more intuitive.

Customize Your Migrated Folder Location

By default, ActualDbSchema stores migration records in tmp/migrated. Now you can customize this path to match your project structure:

1️⃣ Using Environment Variable

Set the environment variable ACTUAL_DB_SCHEMA_MIGRATED_FOLDER to your desired folder path:

export ACTUAL_DB_SCHEMA_MIGRATED_FOLDER="custom/migrated"

2️⃣ Using Initializer

Add the following line to your initializer file (config/initializers/actual_db_schema.rb):

config.migrated_folder = Rails.root.join("custom", "migrated")

Conclusion

With ActualDbSchema v0.8.3, managing your database schema is easier than ever. From visualizing schema changes to cleaning up broken migrations and filtering migrations more efficiently, this release provides new tools for your Rails projects.

We hope these enhancements improve your development workflow. Give them a try in your next project and let us know what you think!

Happy coding, and stay tuned for more updates! 🌟

New UI Features for Schema Tracking and Migration Management in ActualDbSchema was originally published by Andrei Kaleshka at Take your Rails development to the next level on February 28, 2025.

Trace Schema Changes & Run Migrations in Rails Console with ActualDbSchema

2025-02-06 12:37:00 +0400T00:00:00-00:00

Hello, everyone! We’re happy to announce the release of ActualDbSchema v0.8.2! 🎉 This release introduces two features that will make your Rails development experience even smoother. Let’s dive into the details!

Schema Diff with Migration Annotations

Ever stared at the schema.rb diff wondering “Which migration caused this?” Tracking down the origin of schema changes across multiple migrations can be time-consuming, especially in collaborative environments.

The new diff_schema_with_migrations Rake task generates a diff of the schema.rb file, annotated with the migrations responsible for each change. This makes it easier to identify which migration introduced a specific schema modification, helping you decide whether to resolve the diff on your own or discuss it with your teammates to determine the next steps.

Here’s an example of what the schema diff with migration annotations looks like in action:

By default, the task uses db/schema.rb and db/migrate as the schema and migrations paths. You can run it with the following command:

rake actual_db_schema:diff_schema_with_migrations

If your project uses custom paths for the schema or migrations, you can provide them as arguments:

rake actual_db_schema:diff_schema_with_migrations[path/to/custom_schema.rb, path/to/custom_migrations]

This task also checks for phantom migrations. If phantom migrations were not properly rolled back (due to failure or pending migration), the schema might contain related changes that are missing from the original migrations. These changes are properly detected and included in the schema diff, giving you a more complete and accurate picture of your database history.

Console Migrations

Sometimes, you need to make quick adjustments to your database schema without creating migration files - whether you’re fixing a corrupted schema, experimenting with indexes, or making quick changes in development. This feature allows you to run the same commands used in migrations directly in the Rails console.

By default, Console Migrations is disabled. You can enable it in two ways:

1. Using Environment Variable

Set the environment variable ACTUAL_DB_SCHEMA_CONSOLE_MIGRATIONS_ENABLED to true:

export ACTUAL_DB_SCHEMA_CONSOLE_MIGRATIONS_ENABLED=true

2. Using Initializer

Add the following line to your initializer file (config/initializers/actual_db_schema.rb):

config.console_migrations_enabled = true

Once enabled, you can run migration commands directly in the Rails console. Here are a few examples:

# Create a new table
create_table :posts do |t|
  t.string :title
end

# Add a column
add_column :users, :age, :integer

# Remove an index
remove_index :users, :email

# Rename a column
rename_column :users, :username, :handle

Conclusion

We hope these features help you keep your database schema clean, consistent, and easy to work with. We’re committed to making Rails development more efficient and enjoyable, and your feedback continues to drive these improvements. Give these new features a try and let us know what you think!

Stay tuned for more updates in the next release. Happy coding! 🚀

Trace Schema Changes & Run Migrations in Rails Console with ActualDbSchema was originally published by Andrei Kaleshka at Take your Rails development to the next level on February 06, 2025.

Multiple schemas support added to ActualDbSchema

2025-01-15 19:21:16 +0100T00:00:00-00:00

Good day, everyone! I’m excited to announce the release of actual_db_schema v0.8.1! 🎉 This milestone is particularly special as it focuses entirely on addressing feedback from our valued users. Check out the updates and improvements introduced in this release.

Rake task added to initialize the gem

Run the following command to generate the default initializer (an optional post-installation step):

rake actual_db_schema:install

This step is optional and only necessary if you wish to modify the default configuration. If you are already using the gem and have manually created the initializer, it is recommended to back up your config/initializers/actual_db_schema.rb file (if it exists) before proceeding.

DSL for configuring the gem

To make the gem configuration more flexible and reliable, we have introduced a DSL.

Use the following DSL to configure the gem. This will also be generated as a content of config/initializers/actual_db_schema.rb by the init command above.

ActualDbSchema.configure do |config|
  # Enable the gem.
  config.enabled = Rails.env.development?
  # Disable automatic rollback of phantom migrations.
  # config.auto_rollback_disabled = true
  config.auto_rollback_disabled = ENV["ACTUAL_DB_SCHEMA_AUTO_ROLLBACK_DISABLED"].present?
  # Enable the UI for managing migrations.
  config.ui_enabled = Rails.env.development? || ENV["ACTUAL_DB_SCHEMA_UI_ENABLED"].present?
  # Enable automatic phantom migration rollback on branch switch,
  # config.git_hooks_enabled = true
  config.git_hooks_enabled = ENV["ACTUAL_DB_SCHEMA_GIT_HOOKS_ENABLED"].present?
  # If your application leverages multiple schemas for multi-tenancy, define the active schemas.
  # config.multi_tenant_schemas = -> { ["public", "tenant1", "tenant2"] }
end

Support for multiple database schemas

From now on, the gem is compatible with multi-tenant applications that are using the apartment gem or similar solutions.

To add support for multiple schemas, define the active schemas in the configuration:

ActualDbSchema.configure do |config|
  config.multi_tenant_schemas = -> { ["public", "tenant1", "tenant2"] }
end

By multi-tenant schemas, we refer to schemas that are designated for different tenants within an application. For instance, in a SaaS application, each tenant is assigned its own schema. Although the set of migrations and schema structure remains consistent across all tenants, the data within each schema is isolated, ensuring tenant-specific separation. Check out the apartment gem for more details.

The link to Changelog fixed

The Rubygems.org page now correctly displays the changelog link, which was previously broken.

Run the git hook on switch branch only

The gem now runs the git hook only when switching branches, ensuring that the rollback process is triggered only when necessary.

This ensures that when you reset a file using git checkout in the current branch, the gem hook will no longer run as it previously would. This prevents unnecessary rollbacks and streamlines the development process, making it more efficient and convenient.

Conclusion

Thanks to the valuable feedback and suggestions from our users, we’ve made significant improvements to the gem. We believe these updates will enhance your experience with ActualDbSchema, making it an even more powerful tool for your Rails application development.

The next release is already in progress, so stay tuned for more exciting updates!

Multiple schemas support added to ActualDbSchema was originally published by Andrei Kaleshka at Take your Rails development to the next level on January 15, 2025.

The Importance of Understanding the What and Why in Software Development

2024-11-28 18:24:48 +0100T00:00:00-00:00

Understanding the “What” and “Why” in Software Development: A Mentorship Story

In software development, it’s crucial to understand not just what you’re doing, but also why you’re doing it. This simple but essential concept is often overlooked by junior developers, which can lead to incomplete or incorrect implementations. Let me share a story from my experience mentoring a junior developer, where this principle proved pivotal.

The Task: Implementing a Refund Operation

A junior developer I was mentoring had to implement a refund operation in Sage, an accounting software. The task seemed straightforward: reverse the related payment transaction when a refund is issued. However, instead of questioning the broader context, the developer simply reverted the payment transaction in the code.

What Went Wrong?

While the payment was reversed, the outcome didn’t align with the requirements. Specifically:

The invoice remained in a “paid” status, which was incorrect after a refund.
The payment wasn’t marked as refunded, leaving the system in an inconsistent state.

The developer was satisfied with the outcome, claiming that the job was complete. This led to a key realization: they had focused solely on the what—reverting the transaction—without understanding the why behind the operation.

Why It Happened

This issue stemmed from the developer’s failure to fully grasp the business logic behind the refund operation. In addition to reversing the payment, the invoice needed to reflect its refunded status, and the payment itself should be marked as refunded for accurate reporting.

The key to solving this problem wasn’t just about fixing the code; it was about understanding the purpose behind the refund operation. That meant clarifying the inputs (e.g., refund amount, invoice ID) and expected outputs (e.g., updated invoice and payment statuses).

The Lesson: Understanding What and Why

This situation highlighted the importance of understanding both the what and why when developing software. It’s not enough to implement a feature or operation based on surface-level requirements. Developers must dive deeper into:

What the operation actually does: Reversing a payment is only part of the solution.
Why it needs to be done this way: The operation impacts multiple entities (invoice, payment, accounting) and must maintain system consistency.

By emphasizing these two aspects, developers can ensure their work aligns with business goals, prevents errors, and creates more reliable software.

Mentoring Junior Developers

As a mentor, this was a perfect opportunity to reinforce the importance of understanding the business logic behind every operation. I walked the developer through the full process, from understanding the input/output flow to ensuring that all related statuses and records were updated correctly.

The lesson here was clear: developers should never assume that completing the technical task means the job is done. They need to take the time to understand the broader implications of their work.

Conclusion

In conclusion, understanding both the what and the why is fundamental to effective software development. This approach prevents incomplete implementations and ensures that code contributes to the broader goals of the system. By asking the right questions and considering the full scope of a task, developers can create more robust, efficient, and maintainable software.

The Importance of Understanding the What and Why in Software Development was originally published by Andrei Kaleshka at Take your Rails development to the next level on November 28, 2024.

Personal Gemfile for development

2024-03-26 16:04:28 +0100T00:00:00-00:00

I want to use actual_db_schema in my development process. My colleagues are against it. They say that solving the same problem this gem solves can be done by other means. But I don’t want to use their solution as it doesn’t improve my development process. I got used to actual_db_schema. It makes my workflow so comfortable that I don’t accept their solutions. I also don’t want to force them using actual_db_schema.

What should I do if installing this gem requires changes in the Gemfile? Is it a dead-end? It turned out that it’s not. Keep reading to learn how to overcome this obstacle.

Configure the gem not to run

If you persuaded your colleagues and they agreed to install the gem, then accept my congratulations! You can install the gem by modifying Gemfile and then configuring it so that it doesn’t run for anyone by default. But for you, it will run.

Here is how you can do it. Add the gem to Gemfile in development group and install it with bundle. Then add the following initializer:

# config/initializers/actual_db_schema.rb
ActualDbSchema.config[:enabled] = ENV['ACTUAL_DB_SCHEMA'] == 'true'

Now, if the environment variable ACTUAL_DB_SCHEMA is set to true the gem will do its job. By default it’s not defined for anyone. So the gem won’t work for them. But you can define this variable in your shell profile or in the .env file.

While the solution is related to only one gem, you can use it for any other gem. The only requirement for other gems is that they have similar facilities - a configuration option to enable/disable the gem.

While this solution is good, your colleagues may not like that the changes to Gemfile were committed. This is usually the case, and this is okay. Don’t worry! There is a solution for this scenario. Keep reading.

Local Gemfile

I turned out that you can have a local Gemfile. This file is not committed to the repository. It’s used only by you. You can use it to install gems that you want to use in your development process but you don’t want to force others to use them. This solution is possible because Bundler allows you to specify the path to the Gemfile.

Here is how you can do it. Create a file named Gemfile.local in the root of your project. Add the following content to it:

eval_gemfile 'Gemfile'

gem 'actual_db_schema'

Now, install the gem with the following command:

BUNDLE_GEMFILE=Gemfile.local bundle install

This command will install the gem only for you. The changes in the Gemfile are not committed. The gem is not installed for anyone else. You can use this approach for any other gem you want to use in your development process. Don’t forget to add the Gemfile.local and Gemfile.local.lock to the .gitignore file.

The solution is not limited to the actual_db_schema gem. You can use it for any other gem you want to use in your development process but you don’t want to force others to use them.

This is the full checklist of the steps you need to follow to install a gem for your development process without forcing others to use it:

Add these lines to .gitignore:

Gemfile.local
Gemfile.local.lock

Create the Gemfile.local file with the following content:

eval_gemfile 'Gemfile'

# add your local gems here

Define the environment variable in your shell profile or in the .env file:

export BUNDLE_GEMFILE=Gemfile.local

Install the gem with the following command:

bundle install

Enjoy the gem in your development process.
If you want to commit changes into the original Gemfile, you should unset the BUNDLE_GEMFILE environment variable or temprorary set it to the original Gemfile:

unset BUNDLE_GEMFILE

export BUNDLE_GEMFILE=Gemfile

or without modifying the shell profile:

BUNDLE_GEMFILE=Gemfile bundle install

Conclusion

Don’t be afraid to use the gems that improve your development process. You can use them without forcing others to use them. The solutions I described in this article will help you to achieve this goal. Use them and enjoy the gems that make your workflow more comfortable. Share this solution with others who may need it. They will appreciate it.

Personal Gemfile for development was originally published by Andrei Kaleshka at Take your Rails development to the next level on March 26, 2024.

Prevent account sharing with MFA

2024-03-14 15:57:54 +0100T00:00:00-00:00

TL;DR: MFA increased our app new signups by 30% daily. It can help you but measure the impact of the changes.

Preventing account sharing in your app is vital. Various methods tackle this. Recently, we’ve been focusing on the issue. We discovered a simple, low-risk solution. It protects revenue and boosts security. It assists in generating dynamic reports. This solution allows us track data. It helps to manage violation cases. Look how we have achieved this.

Sharing an account is one of the backdoors that leads to financial losses. Instead of having paid two users who are friends in your app, you have only one. They buy one account and share credentials, resulting in underpaying the business.

Another aspect of preventing sharing accounts is security. Someone might steal a user’s credentials. The thief will use the account, and nobody will know about it.

All of that is very important indeed. However, our primary goal was to boost app revenue.

Some services promise to solve the issue with account sharing in your product. That option might sound like a good choice. Relying on their implementation, you sign up. Then, you configure your app by following their instructions and enjoying it. Sounds easy and fantastic. Yet, some disadvantages can prevent you from following this path.

To start, consider how these services tackle the problem. They track user actions. These include clicks, mouse movements, IP addresses, device types, and locations. If the user’s behavior deviates from the norm, the service flags it as suspicious. While effective, there are limitations to this approach. It hinges on a vast amount of user data. The more data and users they have, the more accurate the service becomes. The law of large numbers must function. But you never know if they have enough data. They also need to know your app data and users. Hence, the conclusions about sharing an account might be wrong. In the end, remember that there will always be false positives. It’s essential to have a plan to address them.

This solution takes time to set up and integrate. Dealing with false positives is challenging. You need custom logic to link this service to your app. You lose control over valuable data to improve your product. Also, there’s a fee that may not suit long-term needs. Comparing it to your solution is necessary.

We aimed for user session control, limiting per-user sessions. Account sharing was still possible. The system permitted a fixed number of simultaneous sessions. A user accessing the app on various devices led us here. Working with a third-party service brought obstacles here. Thus, we chose to drop this method.

As the first step, many recommend using multi-factor authentication (MFA) and stopping there. Indeed, it’s an excellent option to consider. We definitely should implement it. Yet, how can we be sure it helps? How can we prevent user loss after enabling MFA? Each app community is different. Their expectations may vary. Enabling MFA for all for no reason could alienate many users. They may leave the app, hurting the business.

Hence, we need indicators to track the impact of our changes on user behavior. Yet, we must decide who gets MFA enabled and assess whether account-sharing prevention works. Thus, an imaginary “violations per user” is a crucial indicator to track. Ultimately, it aligns with login sessions per user—the fewer active login sessions a user has, the fewer violations. If all goes well, the “violations per user” indicator should drop after enabling MFA. Additionally, we expect more users to sign up. Some users using the shared account should eventually sign up for the app. Moreover, the number of active users should not drop. If all that happens, that would mean the feature works well and improves things rather than hurting the business.

We can easily track the number of new signups and the number of active users without changing the app. Having direct access to the database, we can do that with relatively easy SQL queries.

However, we do not have data for the “violations per user” indicator. Thus, we should implement a solution for that.

Thinking this way, we come up with the following initial ideas:

Analyze the user agent’s IP and device type in the web server logs. Create a report of suspicious user actions such as often IP change or device type.
Then, if every subsequent request differs from what’s inside the cookies, it’s a violation.
After analyzing these reports, come up with an idea of who should have MFA enabled. Eventually, implement MFA for them.

Solution #1: logs analysis

Looking into logs and checking how many unique IPs and devices one user uses is a natural solution that comes to mind. We have implemented it. However, this solution did not derive a “sharing account violations” indicator. The story behind this deserves a separate post. In short, it was a challenging task. Based on this data, we’ve had many false positive reports. This is a challenge for us and giants like Google, LastPass, and even your local banks. For that reason, you get a lot of irritating emails every time you log in to these services. I do, and I have it. Our users could hate it as well. A more straightforward solution should correctly identify the fact of sharing accounts.

Solution #2: unique token per device written in cookies

If we have to limit the users’ login sessions, we could restrict them by device type. We can issue a unique token per user device and store it in the DB along with other important information such as IP and the user agent (device info). The idea was to allow one user to use only one device of a specific type at a time. For example, one user can use one web login on a desktop and one on a mobile app. If someone else uses the same device type at the time, it’s a violation. We successfully implemented this solution, and in fact, it worked well. There were some false positives. But fewer than in the previous solution. We could even stick with this solution. However, the business changed its mind and allowed a limited number of login sessions, independent of the device type.

Nevertheless, even though it’s been rejected, this solution can still be used to implement the “sharing account violations” indicator. We use it to collect and analyze reports.

Using the experience of the previous solution, we implemented a modernized version that elaborated into a login session concept. The idea is the following. One user can have many login sessions. A login session is an entity with a unique token. It’s created right after the user’s login and deactivated after the user logs out. This unique token is injected into cookies. We search for an active login session in every subsequent request and create if it still needs to be added. A user with many such login sessions shares an account. And for them, we should enable MFA.

Having the previous solution ready, we can limit the login sessions in the following way: Every time a user logs in, check if the number of login sessions is too big, say 4. If that’s the case, prevent the user from going further and ask them to log in from some of the current login sessions. This is what we are implementing next.

Our results, analysis, and reports

Now, we have the indicator that shows the dynamic of account sharing violations. We gradually enable MFA for those users with the most violations and check the following dynamics.

New signups and active users on a paid plan. Note that it includes users on a trial that lasts for 15 days. That’s why there is this peak on the right side:

Sharing token reports dynamics:

The report dynamics are based on log analysis. It turned out to be useless, and for that reason, we will drop it:

Active login sessions per user with MFA enabled:

Active login sessions per user with MFA disabled:

Active login sessions for all users regardless of the MFA toggle. This one has the data combined with the 2 previous charts:

Looking into these charts, we conclude that:

The number of new paying signups increases. Roughly 30% more new signups daily.
The number of sharing account reports based on the token solution decreases. The regression line predicts a drop from 170 points to 120, almost a 30% drop when IP and device differ.
The number of login sessions per user decreases for users with MFA enabled. This improvement is significant compared to users with MFA disabled.

Summary

In this post, you learned how the positive impact of MFA enabling in your project can be measured. Now, you know which metrics inside your app you should watch for to understand if your solution works and helps the business survive.

Finally, you got a beneficial insight — MFA positively impacts user behavior. It indeed prevents users from sharing accounts. The improvement is significant — roughly 30% more new signups. Additionally, it’s a security improvement for your app. It is worth considering for your project. But keep in mind that your auditory can be different, so measure the impact.

In the next step, we will implement the login session limits. We expect an even more positive impact and will measure the results. Stay tuned!

Follow me on social networks not to miss the next post:

Prevent account sharing with MFA was originally published by Andrei Kaleshka at Take your Rails development to the next level on March 14, 2024.

Reconcile app users vs Stripe and prevent financial losses

2023-01-30 18:23:20 +0100T00:00:00-00:00

Possible discrepancies in Stripe integrations

Stripe integrations often experience data consistency issues, such as users being on different subscription plans in the app compared to Stripe. This misalignment can lead to lost revenue or jeopardize customer success stories.

For example, a customer may have a premium status within the app, while Stripe shows no active subscription. This type of discrepancy can lead to lost revenue for the business. Another potential issue occurs when a customer overpays. In this case, the customer is on the free plan within the app but has an active subscription to the premium plan in Stripe, jeopardizing the customer success story.

Stripe integration state of our application

This blog post outlines the approach we took to resolve such issues in our app, which had around 80k users, with 10% on the premium plan. We identified instances of both overpayment and underpayment, which could be attributed to manual data manipulation in Stripe, missing webhooks, or bugs in our system.

The plan to reconcile data with Stripe

While we used Ruby for scripting, this solution is universal and can be applied to applications written in other languages like Python, Node.js, Java, Rust, and Go.

Our plan is the following:

Fetch all relevant data from Stripe via Stripe REST API. In our case that included all customer entities and their subscriptions.
Put the fetched data into our database. To avoid polluting the main database schema, use a separate namespace for these tables. In fact, PostgreSQL refers to this namespace concept as schema. The default schema is public. We create the stripe schema and necessary tables inside it.
Analyze the discrepancies using SQL queries. SQL is not only faster and less prone to bugs for this kind of task in terms of data processing but also in development. This means we will obtain results faster with fewer expenses for the business.
Configure Metabase for these reports. Metabase is the system we use to write SQL and build reports. Set up notifications for data discrepancies so that we receive alerts about new cases and can react to them as soon as possible. Luckily, it was already set up for this project. The good news is that its setup takes very little time.
Schedule the data scraper from Step 1 to run automatically every week.

Stripe data store preparation

First, we need to create the DB schema along with the Stripe tables. This is the SQL script we used for that:

create schema stripe;
create table stripe.customers (
  id serial not null,
  stripe_id varchar(250),
  email varchar(250) not null,
  created_in_stripe timestamp,
  description varchar(250),
  metadata jsonb,
  deleted boolean,
  created_at timestamp default current_timestamp,
  updated_at timestamp default current_timestamp
);
create table stripe.subscriptions (
  id serial not null,
  stripe_id varchar(250),
  stripe_customer_id varchar(250),
  plan_id varchar(250),
  status varchar(250),
  created_at timestamp default current_timestamp,
  updated_at timestamp default current_timestamp
);

Inside the Rails app, data migrations could be created for this purpose. However, as we are unsure whether these tables are permanent at the moment, we use SQL and execute it manually on the server.

Our app uses Rails, so it has ActiveRecord, and we can point our models to these tables. These are the ActiveRecord models we created for our convenience while working with these tables in the Ruby script:

class StripeSchema < ActiveRecord::Base
  self.abstract_class = true
  establish_connection :stripe
end

class StripeCustomer < StripeSchema
  self.table_name = :customers
  self.primary_key = :id
end

class StripeSubscription < StripeSchema
  self.table_name = :subscriptions
  self.primary_key = :id

  belongs_to :stripe_customer, foreign_key: :stripe_id
end

We have a special folder in the app, app/scripts, where we put this kind of ad-hoc code. Later, we use Rails runner to execute them on the production server against the real data. They can also be run locally for testing purposes during script development. This script code was put into app/scripts/stripe_classes.rb file.

The Stripe data scrapper

And this is the script we’ve come up with:

starting_after = nil

loop do
  params = {expand: ['data.subscriptions'], limit: 100}
  params[:starting_after] = starting_after if starting_after

  customers = Stripe::Customer.list(params)

  customers.each do |cus|
    ApplicationRecord.transaction do
      StripeCustomer.create(
        email: cus["email"],
        stripe_id: cus["id"],
        description: cus["description"],
        created_in_stripe: cus["created"] ? Time.zone.at(cus["created"]) : nil,
        metadata: cus["metadata"],
        subscriptions: customer_subscriptions,
        deleted: cus["deleted"]
      )

      cus.subscriptions.each do |sub|
        StripeSubscription.create(
          stripe_customer_id: cus["id"],
          stripe_id: sub["id"],
          plan_id: sub["plan"]["id"],
          status: sub["status"]
        )
      end
    end

    starting_after = cus["id"]
  end
  break if customers.count < 100
end

This script fetches all Stripe customers along with their subscriptions. Later, using this data, we can compare it against our app’s database and identify any deviations.

We run this script on the server with the rails runner. Its run can take a while. Not to get the process killed with a closed SSH connection to the server, we use screen utility. At least for the first time, we have to run it manually and monitor for any failures. If there are any issues, we fix them. This way, we verify that the script is valid and reliable. Later, we can automate it to run on a schedule. We’ve collected data on 85k customers and 8.5k subscriptions, and it took around 1 hour. Not bad for this amount of data.

Run the script automatically

After some preliminary data analysis and verification of its correctness, we can set up this script to run automatically on the server. We use sidekiq and its extension sidekiq-scheduler for this, as it’s already in place. The app also has Rollbar configured to monitor exceptions and errors, so if something goes wrong, we can be notified.

This is the job:

class UpdateStripeData
  include Sidekiq::Worker

  require_relative '../../scripts/stripe_classes'

  def perform
    drop_old_data
    record_stripe_data
  end

  private

  def record_stripe_data
    starting_after = nil

    loop do
      params = {expand: ['data.subscriptions'], limit: 100}
      params[:starting_after] = starting_after if starting_after

      customers = Stripe::Customer.list(params)

      customers.each do |cus|
        ApplicationRecord.transaction do
          StripeCustomer.create(
            email: cus["email"],
            stripe_id: cus["id"],
            description: cus["description"],
            created_in_stripe: cus["created"] ? Time.zone.at(cus["created"]) : nil,
            metadata: cus["metadata"],
            subscriptions: customer_subscriptions,
            deleted: cus["deleted"]
          )

          cus.subscriptions.each do |sub|
            StripeSubscription.create(
              stripe_customer_id: cus["id"],
              stripe_id: sub["id"],
              plan_id: sub["plan"]["id"],
              status: sub["status"]
            )
          end
        end

        starting_after = cus["id"]
      end
      break if customers.count < 100
    end
  end

  def drop_old_data
    ActiveRecord::Base.connection.execute(<<~SQL)
      delete from stripe.customers;
      delete from stripe.subscriptions;
    SQL
  end
end

And this is the configuration defined in config/sidekiq_scheduler.yml to run it every Saturday at 12:00PM in UTC time zone:

production:
  update_stripe_data:
    class: UpdateStripeData
    cron: '0 12 * * 6'

We chose that time as the servers are less loaded during those hours.

Analyze Stripe data discrepancies with SQL

We are all set. With the data in place, we can use SQL to identify all deviations. This will involve using common table expression (CTE), views, joins, filters, and aggregation functions.

Note that the script fetches the Stripe data once a week, and it takes around 1 hour to run. Consequently, the app data will always be ahead of the Stripe data. This is crucial to understand because we cannot join the current app data against the cached Stripe data due to this time lag. Therefore, we need the app data snapshot at the moment the script was run.

Creating a real data snapshot is an option, but it would significantly complicate our architectural story. Fortunately, we have Papertrail configured in the app, a gem that stores all changes to users. This means we can reinstall actual data at the moment the script fetched Stripe data was run. The only field of interest for us is plan_id. Therefore, we reinstall only this field. To reuse the reinstalled data, we utilize views. These are kind of virtual tables inside SQL but don’t store the collected data:

create view stripe.users_with_actual_plan as (
    with stripe_update as (
        select created_at as ts from stripe.subscriptions limit 1
    ),
    recent_versions as (
        select * from versions where created_at >= (select ts - interval '1 day' from stripe_update)
    ),
    data as (
        select
            u.*,
            coalesce (
                coalesce(
                    coalesce(
                        (substring((vp.object_changes->>'plan_id') from ', (\d+)'))::int,
                        (substring(vp.object from '\nplan_id: (\d+)'))::int
                    ),
                    coalesce(
                        (substring((vf.object_changes->>'plan_id') from '(\d+),'))::int,
                        (substring(vf.object from '\nplan_id: (\d+)'))::int
                    )
                ),
                u.plan_id
            ) as actual_plan_id,
            rank() over (partition by u.id order by vp.created_at desc nulls last, vf.created_at asc) as version_rank
        from users u
        left join stripe.customers c on c.stripe_id = u.stripe_customer_id
        left join recent_versions vp on vp.item_id = u.id and vp.created_at < coalesce(c.created_at, (select ts from stripe_update))
        left join recent_versions vf on vf.item_id = u.id and vf.created_at >= coalesce(c.created_at, (select ts from stripe_update))
    ) select * from data where version_rank = 1
);

This SQL query might look intimidating, and that’s okay. It’s not essential for understanding everything here. All you need to know is what it does, and you already have that knowledge. It creates a virtual table of users with the actual plan_id that was set just before the script fetched Stripe data.

One might ask, “How do we end up creating SQL queries that appear so complicated and intimidating?” The answer is simple: through small steps, selecting one field at a time, joining step by step, and eventually combining them into a single query using the CTE construction.

And now, we are ready to join these users with the actual plan data from Stripe.

This time, the SQL looks much easier:

with stripe_update as (
    select created_at ts from stripe.subscriptions limit 1
)
select u.* from
stripe.users_with_actual_plan u
left join stripe.subscriptions s on s.stripe_customer_id = u.stripe_customer_id
where u.actual_plan_id is not null and u.actual_plan_id not in (6, 121)
    and u.created_at < (select ts from stripe_update)
    and s.id is null
;

The plan with ID = 6 is the free plan, and 121 is a technical one used only for internal purposes. Therefore, the entire expression u.actual_plan_id is not null and u.actual_plan_id not in (6, 121) indicates that the user is on a paid plan.

We inputted this SQL into Metabase, and this is what it looks like:

Optionally, we can configure notifications to be sent even when a new record is added to these results. See the bell icon at the bottom right; it’s intended for this purpose.

Metabase comes in handy for exporting data into CSV and Excel with just one click. We do that often. That simplifies communication with the business a lot. It’s also possible to share the reports right away with the team via a direct link.

As we can see, there were 983 instances of user data discrepancies found. It’s a significant amount of data among all active subscriptions that match the app user data, which is 8,488. That represents roughly a 10% margin of error! Too much!

We found the number of subscriptions that match user data using this SQL:

with stripe_update as (
    select created_at ts from stripe.subscriptions limit 1
)
select count(u.*) from stripe.users_with_actual_plan u
    join stripe.subscriptions s on s.stripe_customer_id = u.stripe_customer_id
    join plans p on p.stripe_price_id = s.plan_id
    where u.created_at < (select ts from stripe_update)
;

See how the created view “users_with_actual_plan” becomes handy here as well. It’s a very powerful tool that can save a ton of code and coding time!

Further data analysis shows that 514 of these 983 discrepancies are related to deleted users. It turns out our app employs a so-called soft delete feature, meaning they are not actually deleted but marked as such, preventing them from using the app anymore. Well, now the situation looks much better. It’s just a 5% margin of error, not the 10% we initially thought. It’s almost within 3% of the standard deviation. Not so bad.

Fixing the data deviations between the app and Stripe

All actions related to fixing data require a thorough understanding of the app at a good level. We can either examine the instances of discrepancies one by one, allowing us to understand what happened to each of them. When we analyze each instance of discrepancy, we check the app database, logs, Papertrail records, Stripe logs, Rollbar, and any other data sources that could help us determine what happened to a certain user.

By simply looking into the app database, we noticed those 514 softly deleted users. This can be easily done by examining the deleted_at column in the report. Any Excel-like tool can allow us to filter this information, or we can accomplish this in Metabase.

We can move these users to free plan right away by writing a Ruby script that was successfully done.

Now, there are only 469 records with data discrepancies remaining. We go through some of them. That shows that all of them indeed had data discrepancies. Delving into the codebase with some hypotheses about what happened, we spot a serious breach inside the app. Each Stripe webhook has its own handler with specific code manipulating the user subscription data. All processed by Sidekiq. But Sidekiq doesn’t guarantee the order of incoming webhook processing.

At this point, we decide to address this issue by making slight adjustments to the architecture. From now on, all webhooks will be processed by one handler that consistently checks the actual Stripe subscription state before changing the user’s plan within the app. Hence, the multiple webhooks that used to process subscription-related actions will now utilize only one blocking handler, ensuring it cannot run in parallel for several requests for one user.

This is the simplicied version of the code we used to fix the bug:

def sync_app_subscription
  PlanChangeSchedule.transaction do
    # Prevent concurrent plan updates; if another job attempts to acquire the lock simultaneously, it will wait until this one is completed
    PlanChangeSchedule.where(user: user).lock
    if actual_subscription && stripe_plan != user.plan
      synchronize!
    elsif !actual_subscription
      cancel_account
    end
  end
ensure
  PlanChangeSchedule.where(user: user).delete_all
end

PlanChangeSchedule is a special table that stores the user’s plan change requests. It’s used to prevent concurrent plan updates. The lock method is used to prevent concurrent plan updates. If another job attempts to acquire the lock simultaneously, it will wait until this one is completed. The synchronize! method is used to synchronize the user’s plan with the actual Stripe subscription. The cancel_account method is used to cancel the user’s account if there is no actual subscription.

After fixing the bug, we transferred all users who had not used the app in the last 90 days to the free plan. There were 391 such accounts. The remaining users got moved to the paid subscription. In the end, the result looked like that:

30 users got moved to the free plan;
For the rest 48, we tried to reactivate the subscription. 19 of which got successfully reactivated. 5 of them, could not have created the subscription due to a missing payment method. 24 of them created subscriptions but with the payment failing, they will be moved to the free plan after 3 failed attempts, or remain active if paid.

That resulted in roughly a $525 immediate increase in Monthly Recurring Revenue (MRR) and 600$ in potential MRR increase if all the users with failed payments will be reactivated.

Preventing future discrepancies

To prevent future discrepancies, we set up a monitoring system that checks for new discrepancies every week. We use Metabase for this purpose. We set up a dashboard that shows the number of discrepancies. We also set up alerts that notify us when the number of discrepancies exceeds a certain threshold. All of that was done using Metabase and SQL.

Conclusion

Asynchronous communication between services is a painful point. It can lead to customer dissatisfaction, losses to the business, and increased workload for the customer support team. This post shows how we deal with these kinds of issues. Efficiently solving them requires deep expertise in SQL, the business, the tech stack, data analysis, and programming.

Happy coding and bug-free apps to you, our reader!

Reconcile app users vs Stripe and prevent financial losses was originally published by Andrei Kaleshka at Take your Rails development to the next level on January 30, 2024.

Smart route aliases in Rails

2023-12-19 18:00:50 +0100T00:00:00-00:00

Sometimes, for SEO and marketing reasons, you might need to create an alias route in your Rails project. This can get tricky if the original route relies on dynamic elements that change based on the user’s session.

In our project, we wanted to create a quick and easy shortcut, /edit_my_plans, for the user-specific route /users/:id/edit?tab=plans.

For example, Rails offers a way to set up this type of redirect using the following code (taken from their official documentation):

get '/stories/:name', to: redirect { |path_params, req| "/articles/#{path_params[:name].pluralize}" }

With this knowledge in hand, we developed a clear and straightforward method for defining these types of routes, allowing us to embed business logic of any level of complexity directly into the router:

# in config/routes.rb:
get "/edit_my_plans", to: redirect(RoutesAlias.edit_my_plans)

This is our special class, called RoutesAlias, that handles all the complex stuff. It’s better to keep this stuff separate from the router, so we put it in the app/lib folder. You can put it somewhere else in your project if you want.

class RoutesAlias
  include Rails.application.routes.url_helpers

  attr_reader :session

  def self.edit_my_plans
    proc { |_params, request| new(request.session).edit_my_plans }
  end

  def initialize(session)
    @session = session
  end

  def edit_my_plans
    current_user = Authentication.user_from_session(session)

    case current_user&.user_type
    when "vendor"
      edit_user_path(current_user, tab: "plans")
    when "user"
      projects_path
    when nil
      "/auth/auth0?origin=/edit_my_plans"
    end
  end
end

Now, marketing sites, like landing pages or other marketing pages, can easily use the generic URL /edit_my_plans. Rails will handle everything, taking you to the right place, whether it’s a login form, a specific homepage for a particular user type, or something else.

Hope this helps with your Rails project! Happy coding!

Smart route aliases in Rails was originally published by Andrei Kaleshka at Take your Rails development to the next level on December 19, 2023.

Cheaper and Risk-Free Ruby on Rails App Redesign

2023-08-30 15:06:43 +0200T00:00:00-00:00

Ruby on Rails app redesigning challenges

Redesigning a Ruby on Rails application is a well-known challenge for many projects. Any project UI gets outdated. It needs to get a fresh look that’s more appealing to the users. It may not be an issue for web apps without live users. But it’s a tricky task for already launched businesses serving thousands of users per day.

While a development team is redesigning, the application should continue functioning. At the development time, the new design gets validated and tested against the back-end. If the back-end is incompatible, it must be adapted to the new realm. These changes should not break the old functionality. Overcoming these issues is essential in a Ruby on Rails application redesign.

This article shares the approach we took to apply the new design in one of our projects. The changes we made increased the project revenue by 30%. As a bonus, the implemented changes unleashed many other opportunities, including:

Building a modern mobile application.
Making the code more fault-tolerant, performant, and stable.
Adding new features, such as preventing account sharing, that can increase the app revenue.
Making the tech stack upgrade easier.
Implementing traffic control and advanced caching.
Making SEO optimization easier.

Why redesigning a Ruby on Rails app

There are several reasons why an app may consider implementing a new UI/UX design. Regardless of the motive, the ultimate goal is always the same - to increase revenue. Note, that keeping users using the app and not going away is the same goal. Due to an old and unhandy design, an app can make the customers leave. In this case, redesign also can help. If it’s clear that a redesign won’t have a positive impact on revenue, it may be an unnecessary expense. Redesigning is usually an expensive change. So learn from the users if the design is a problem before making this decision.

What is the new design

A new design consists of screens (mockups) created by a designer using software like Figma or Adobe Photoshop.

In our case, the client provided the mockups, and our task was to turn them into code and integrate them with the existing back-end. We aimed to minimize downtime during the transition and reduce development efforts.

Different technical approaches of a Ruby on Rails app redesign

Nowadays, web projects must be responsive and have a mobile application. Modern web app design features a rich UI with many elements on one page. The old-fashioned way of generating HTML on the back-end is going away. Instead, a separate web front-end or mobile app handles the front-end, while the back-end serves data via API.

In pure Ruby On Rails applications, the front-end code lives alongside the back-end. That can fulfill modern web app requirements and is cheap in the beginning. However, it becomes hard to maintain due to the mix of different technologies in one place. It makes it difficult to find developers who can understand and maintain the system. We prefer separate back-end and front-end. The specialists can do their job quickly with high quality on their end.

Risk-free approach of a Ruby on Rails app redesign

The project we received was a Ruby On Rails application with a Rest API implemented on Grape. An iOS app used this API. The web version used ERB and Slim templates with a UI from the previous decade. Some dynamic features on the web used Knockout.js, which is no longer maintained.

To update the UI, we used the Next.js framework with TypeScript and implemented GraphQL for the API. To avoid errors, we created a separate repository for the new UI and extracted functionality that could be reused in both the old app and the new UI.

The project took almost a year with 2 developers and 1 project manager working on it. To deploy the changes, we used CloudFront as a proxy on top of the old app and the new front-end app. We gradually switched web requests to the new UI using a feature flag to reduce the risk of failures or outages. The transition went smoothly without major issues.

As a bonus, we got all requests geolocated since they pass through the AWS CloudFront. That allowed us to control the users’ network traffic and fight against sharing accounts.

Our results of the Ruby on Rails app redesign

Switching to the new design made the project more attractive to users, resulting in more signups and increased satisfaction among old users. This allowed us to increase charges by 20% and revenue by 30%. The redesign expenses were paid off within the first 3 months after release. See below for the paid user dynamics analysis.

The release date was on the 1st of February 2021.

Why our approach of Ruby on Rails app redesign is cheaper and less risky

Redesigning apps can be painful and distracting. The Rails assets pipeline changes often, making sticking with it turn the code into legacy quickly. Finding specialists to maintain this code without sacrificing quality on both front-end and back-end is challenging. Separating the front-end and leaving only the Rails back-end for the API makes redesigning and maintenance smoother, allowing for a diversified team with good specialists on both ends.

Next.js was a wise choice for the front-end, improving SEO with image optimization and cache facilities out of the box.

Acknowledges

I’m grateful and proud to have worked with the following people on this project at different times:

Daniel Dauwe
Vadzim Jakushau
Illia Pruskyi
Soltan Yangibayev
Svetlana Zhuravitskaya
Alexey Mikitsik

When seeking proficient expertise in Ruby on Rails development, explore the option of using a reputable talent marketplace. Toptal provides access to dependable Ruby on Rails developers for hire, assisting companies with their critical web application requirements.

Cheaper and Risk-Free Ruby on Rails App Redesign was originally published by Andrei Kaleshka at Take your Rails development to the next level on August 30, 2023.

Select unique latest grouped records from DB

2023-07-13 17:26:54 +0200T00:00:00-00:00

Nowadays, almost every Ruby on Rails application has a so-called recent records block. This block usually shows statistics or a list of recent things within the project during the last few days searched by some criteria. It can be something like “top 10 products”, “the most popular projects”, or “the most relevant apartments”. Read this blog post the learn how to efficiently build data for these blocks using SQL and window functions in Ruby on Rails app.

Recent records - the task overview

Assume that you’ve got an app that has Project model. It has many ratings. The Rating model has just a value from 1 to 5 assigned by users to some projects.

For the task understanding it’s enough to have a look into the table definition:

db-# \d ratings
                                          Table "public.ratings"
   Column    │              Type              │ Collation │ Nullable │               Default
═════════════╪════════════════════════════════╪═══════════╪══════════╪═════════════════════════════════════
 id          │ bigint                         │           │ not null │ nextval('ratings_id_seq'::regclass)
 reviewer_id │ bigint                         │           │          │
 reviewee_id │ bigint                         │           │          │
 rating      │ integer                        │           │          │
 review      │ text                           │           │          │
 project_id  │ bigint                         │           │          │
 created_at  │ timestamp(6) without time zone │           │ not null │
 updated_at  │ timestamp(6) without time zone │           │ not null │
Indexes:
    "ratings_pkey" PRIMARY KEY, btree (id)

This table has the following data:

db-# select id, reviewer_id, reviewee_id, rating, project_id, created_at from ratings;
 id │ reviewer_id │ reviewee_id │ rating │ project_id │         created_at
════╪═════════════╪═════════════╪════════╪════════════╪════════════════════════════
  8 │           9 │          10 │      5 │         27 │ 2022-12-05 21:46:01.583185
 12 │           7 │           6 │      5 │         26 │ 2022-12-23 14:35:11.047002
 13 │           6 │           7 │      5 │         26 │ 2022-12-23 14:36:48.366411
 18 │           9 │          10 │      5 │         39 │ 2023-03-01 23:27:52.68548
 19 │          10 │           9 │      5 │         39 │ 2023-03-01 23:28:32.880234
 20 │           9 │          10 │      5 │         86 │ 2023-03-01 23:35:15.564763
(6 rows)

Our task is to return the latest reviews per project. So the resulting records should be these:

 id │ reviewer_id │ reviewee_id │ rating │ project_id │         created_at
════╪═════════════╪═════════════╪════════╪════════════╪════════════════════════════
  8 │           9 │          10 │      5 │         27 │ 2022-12-05 21:46:01.583185
 13 │           6 │           7 │      5 │         26 │ 2022-12-23 14:36:48.366411
 19 │          10 │           9 │      5 │         39 │ 2023-03-01 23:28:32.880234
 20 │           9 │          10 │      5 │         86 │ 2023-03-01 23:35:15.564763
(4 rows)

Note the project_id is distinct compared to the all records. And the timestamps are the most recent for those duplicated projects (their id = 26, 39).

There is no way to solve this task efficiently using only ActiveRecord functionality and pure Ruby. But SQL can solve this with the window function technique.

How window function with row number partition works

The idea is the following - we rank all records inside the table from 1 no N for the duplicated records of our search criteria. The most recent record gets 1, older one gets higher rank. The distinct rows will have 1.

For example:

 id │ project_id │ reviewee_id │         created_at         │ row_number
════╪════════════╪═════════════╪════════════════════════════╪════════════
  8 │         27 │          10 │ 2022-12-05 21:46:01.583185 │          1
 12 │         26 │           6 │ 2022-12-23 14:35:11.047002 │          2
 13 │         26 │           7 │ 2022-12-23 14:36:48.366411 │          1
 18 │         39 │          10 │ 2023-03-01 23:27:52.68548  │          2
 19 │         39 │           9 │ 2023-03-01 23:28:32.880234 │          1
 20 │         86 │          10 │ 2023-03-01 23:35:15.564763 │          1
(6 rows)

The ratings with id = 8, 20 receive row number 1 because these projects are distinct (27, 86). But projects with id = 26, 39 have several ratings that’s why the rows with this project id have row_number 1 and 2. The most recent ratings per project receive 1, and the older ones receive row number 2.

Use subselect to filter correct results

If we filter out those row numbers greater 1 we get the required result. If that would be a table we could use the SQL’s where clause. For example, a view (virtual table) could be created for that. But we will keep it simple. We will use subselect: initially we prepare select to return the data as above and immediately use select statement to filter out the correct result.

But first, let’s see how to write SQL statement to assign the row number using the already noticed window function:

db-# select
        id,
        project_id,
        reviewee_id,
        created_at,
        row_number() over (partition by project_id order by created_at desc)
        from ratings
        order by created_at;

 id │ project_id │ reviewee_id │         created_at         │ row_number
════╪════════════╪═════════════╪════════════════════════════╪════════════
  8 │         27 │          10 │ 2022-12-05 21:46:01.583185 │          1
 12 │         26 │           6 │ 2022-12-23 14:35:11.047002 │          2
 13 │         26 │           7 │ 2022-12-23 14:36:48.366411 │          1
 18 │         39 │          10 │ 2023-03-01 23:27:52.68548  │          2
 19 │         39 │           9 │ 2023-03-01 23:28:32.880234 │          1
 20 │         86 │          10 │ 2023-03-01 23:35:15.564763 │          1
(6 rows)

The row_number() over (partition by project_id order by created_at desc) is a window function that assigns row number from 1 to N for the records duplicated by some criteria. In this case the criteria is distinct project_id sorted by created_at desc.

Running this query inside DB console will produce the result above.

Wrap this select with another select and filter only rows with number = 1:

db-# select
  id,
  reviewer_id,
  reviewee_id,
  rating,
  project_id,
  created_at from (
    select *, row_number() over (partition by project_id order by created_at desc)
    from ratings
    order by created_at
  )
  as ratings where row_number = 1;

 id │ reviewer_id │ reviewee_id │ rating │ project_id │         created_at
════╪═════════════╪═════════════╪════════╪════════════╪════════════════════════════
  8 │           9 │          10 │      5 │         27 │ 2022-12-05 21:46:01.583185
 13 │           6 │           7 │      5 │         26 │ 2022-12-23 14:36:48.366411
 19 │          10 │           9 │      5 │         39 │ 2023-03-01 23:28:32.880234
 20 │           9 │          10 │      5 │         86 │ 2023-03-01 23:35:15.564763
(4 rows)

Voila, we’ve got what we want!

Use ActiveRecord.from to return the results as Ruby objects

Since we’ve got the SQL query it’s easy to port it into ActiveRecord and get eventually the list of Ruby objects. We will use the ActiveRecord.from to write the subselect:

> Rating
  .select("id, reviewer_id, reviewee_id, rating, project_id, created_at")
  .from("(select *, row_number() over (partition by project_id order by created_at desc) from ratings group by project_id, reviewee_id, created_at, id order by created_at) as ratings")

  Rating Load (41.9ms)  SELECT id, reviewer_id, reviewee_id, rating, project_id, created_at FROM (select *, row_number() over (partition by project_id order by created_at desc) from ratings group by project_id, reviewee_id, created_at, id order by created_at) as ratings WHERE "ratings"."row_number" = $1  [["row_number", 1]]
=> [#<Rating:0x000000011190d410 id: 8, reviewer_id: 9, reviewee_id: 10, rating: 5, project_id: 27, created_at: Mon, 05 Dec 2022 21:46:01.583185000 UTC +00:00>,
 #<Rating:0x000000011190d348 id: 13, reviewer_id: 6, reviewee_id: 7, rating: 5, project_id: 26, created_at: Fri, 23 Dec 2022 14:36:48.366411000 UTC +00:00>,
 #<Rating:0x000000011190d280 id: 19, reviewer_id: 10, reviewee_id: 9, rating: 5, project_id: 39, created_at: Wed, 01 Mar 2023 23:28:32.880234000 UTC +00:00>,
 #<Rating:0x000000011190d1b8 id: 20, reviewer_id: 9, reviewee_id: 10, rating: 5, project_id: 86, created_at: Wed, 01 Mar 2023 23:35:15.564763000 UTC +00:00>]

You can run this experiment yourself on this demo app.

Conclusion

Advanced SQL understanding allows you to write performant advanced functionality in a Ruby on Rails application efficiently.

If you like this article and would like to see more examples of how SQL can improve your software development life read these articles:

Have a good day ahead and happy coding!

Select unique latest grouped records from DB was originally published by Andrei Kaleshka at Take your Rails development to the next level on July 13, 2023.

Use timestamp for predicates in Rails

2023-06-15 15:19:16 +0200T00:00:00-00:00

Why use timestamp field instead of boolean for checkbox

You are about to add a new boolean attribute into your model inside a Ruby on Rails application. It’s simple as is - add a boolean column in DB and call it a day. But stop and think - consider a timestamp type for the corresponding columns in the database.

This approach allows for tracking the time when the value change. That can be helpful in debugging, especially when dealing with production issues.

Ok, it’s preferable to use the timestamp field type on the back-end. But it is still convenient to have a checkbox on the user interface. Thus, the timestamp column type does not match the UI field type (checkbox). That means the value (such as true/false, yes/no, or any other) from the front-end should be transformed into a timestamp or nil on the back-end. That’s needed, to ensure compatibility with the mass-assignment methods (.new or #update).

Avoid code duplicating with a universal solution

One could write this type of transformation logic ad-hoc inside controllers. But you can create a universal solution. One way to achieve this is by defining a helper method in the base model class. In Rails, the base model class is typically ApplicationRecord. By doing this, you can ensure its availability across all models in the application. See the following example how to do this:

class ApplicationRecord < ActiveRecord::Base
  primary_abstract_class

  # Defines a predicate method and a setter method for the specified attributes.
  #
  # To use this code in the User model, call the following:
  #   timestamp_as_boolean :muted
  #
  # In this scenario, it assumes that a "muted_at" column is defined in the table.
  # After calling the code, the following methods are defined on the User model:
  #   muted? - checks if a user is muted
  #   muted=(value) - sets the muted_at timestamp if the value is equivalent to boolean "true"
  def self.timestamp_as_boolean(*fields)
    fields.each do |field|
      timestamp_field = "#{field}_at"
      predicate = "#{field}?"
      define_method(predicate) do
        public_send(timestamp_field).present?
      end
      define_method("#{field}=") do |value|
        new_value = ActiveModel::Type::Boolean.new.cast(value) ? Time.current : nil
        public_send("#{timestamp_field}=", new_value) if new_value.nil? || !public_send(predicate)
      end
    end
  end
end

We have now implemented a universal solution using some meta-programming techniques in Ruby. Here’s how you can use it. Let’s take the example of the User model and convert the muted_at column into a boolean attribute using the following approach:

class User < ApplicationRecord
  timestamp_as_boolean :muted
end

To utilize this solution in an ERB template on the user interface, follow these steps:

<%= form.check_box :muted, { checked: @user.muted? } %>

Let’s verify its functionality:

> user = User.last
> user.muted? # => true
> user.update!(muted: false)
> user.muted? # => false
> user.update!(muted: true) # => true
> user.muted? # => true
> user.muted_at # => Thu, 15 Jun 2023 15:16:54.582848000 UTC +00:00
> user.update!(muted: true) # => true
> user.muted_at # => Thu, 15 Jun 2023 15:16:54.582848000 UTC +00:00

It is important to note that after the second assignment of muted = true, the timestamp did not change. This behavior is expected and logical because the value itself was not modified. The purpose of tracking the timestamp is to capture the moment when a change in the value occurs. In this case, since the value remains the same, there is no need for the timestamp to be updated. This behavior aligns with the intended functionality. It ensures that the timestamp accurately reflects when a change in the value of the attribute occurs.

Conclusion

Use a timestamp type for columns in the database. Create a universal solution to transform boolean values. As a result, enhance the functionality and debugging capabilities of our models. The timestamp type allows us to track the values change time. That can aid in identifying and troubleshooting issues, particularly in production environments. Avoid code duplication and ensure consistent behavior across models with a universal solution. Metaprogramming can help with that. These improvements contribute to a more robust and efficient application.

Happy coding!

Use timestamp for predicates in Rails was originally published by Andrei Kaleshka at Take your Rails development to the next level on June 15, 2023.

Optimize Rails app performance with ChatGPT

2023-06-07 18:30:34 +0200T00:00:00-00:00

The previous article Make your Ruby on Rails app 80x faster with SQL shows how SQL knowledge can help to optimize your Rails application performance. We discussed it within Belarus User Group community. Not everyone agreed with the point and didn’t find SQL knowledge a good asset for investment. That’s something expected. There is no revelation here. But that meeting had something that everyone was impressed with. We experimented and found out how ChatGPT is good with code optimization. We saw how it transforms Ruby code into performant SQL. The results were great. Check that out within this article.

ChatGPT request to transform Ruby code into SQL

As before, we are going to use this experimental repository.

We took the following code snippet, the slowest and original version, and asked to improve its performance by rewriting it into SQL:

# the original code

projects_full = []
projects_empty = []
Service.where(user: user, status: "approved", active: true).order(category_id: :asc).each do |service|
  ratings_average = 0
  ratings_count = 0
  ratings_total = 0
  Rating.where(reviewee: user).each do |rating|
    project = Project.find(rating.project_id)
    if project.category_id == service.category_id
      ratings_count += 1
      ratings_total += rating.rating
    end
  end
  ratings_average = (ratings_total / ratings_count.to_f).round(1).to_s if ratings_count != 0 && ratings_total != 0
  completed_projects_count = Project.where(vendor: user, status: "Complete", category_id: service.category_id).size
  service_hash = {
    category_id: service.category_id,
    category_name: Category.find(Category.find(service.category_id).parent_id).name,
    subcategory_name: Category.find(service.category_id).name,
    completed_projects_count: completed_projects_count,
    ratings_count: ratings_count,
    ratings_average: ratings_average,
  }
  resolved_hash = service_hash.transform_keys{ |k| k.to_s.camelize(:lower) }
  if completed_projects_count > 0
    projects_full.push(resolved_hash)
  else
    projects_empty.push(resolved_hash)
  end
end
projects_full.sort_by!{ |k| -k["completedProjectsCount"] }
projects_full.push(*projects_empty)

projects_full

And we got the following response from ChatGPT:

SELECT
  c1.id AS category_id,
  c2.name AS category_name,
  c1.name AS subcategory_name,
  COUNT(DISTINCT p.id) FILTER (WHERE p.status = 'Complete') AS completed_projects_count,
  COUNT(r.id) AS ratings_count,
  COALESCE(AVG(r.rating), 0) AS ratings_average
FROM
  services s
  JOIN categories c1 ON s.category_id = c1.id
  JOIN categories c2 ON c1.parent_id = c2.id
  LEFT JOIN projects p ON s.user_id = p.vendor_id AND p.category_id = c1.id
  LEFT JOIN ratings r ON s.user_id = r.reviewee_id AND p.id = r.project_id
WHERE
  s.user_id = :user_id AND s.status = 'approved' AND s.active = true
GROUP BY
  c1.id, c2.name, c1.name
ORDER BY
  completed_projects_count DESC, c1.id ASC;

And these are the performance measurement results:

Warming up --------------------------------------
                ruby     1.000  i/100ms
                 sql    54.000  i/100ms
             sql_gpt    59.000  i/100ms
Calculating -------------------------------------
                ruby      6.846  (±14.6%) i/s -     34.000  in   5.000338s
                 sql    540.320  (± 8.5%) i/s -      2.700k in   5.038711s
             sql_gpt    609.335  (± 6.9%) i/s -      3.068k in   5.059364s

Comparison:
             sql_gpt:      609.3 i/s
                 sql:      540.3 i/s - same-ish: difference falls within error
                ruby:        6.8 i/s - 89.01x  slower

We also checked that the result of the query service is the same for both calls. That means there are no bugs in the produced SQL by the AI.

The ChatGPT result is the fastest one. At the same time, no business logic was defective. That’s a very good result!

Should one use ChatGPT to optimize code performance or not

While the AI results are good, it’s still doubtful who and how to use the tool. Not seasoned developers might don’t understand where the bottleneck is. They would struggle with finding a correct question for ChatGPT. They would not understand how to fix the generated code if it has bugs. Some time later I tried to repeat the experiment and know the machine produced a very different SQL that has bugs inside:

-- Get average ratings and count for each service
WITH rating_summary AS (
  SELECT p.category_id, COUNT(r.id) AS ratings_count, COALESCE(AVG(r.rating), 0) AS ratings_average
  FROM ratings r
  INNER JOIN projects p ON p.id = r.project_id
  WHERE r.reviewee = <user_id>
  GROUP BY p.category_id
),

-- Get completed projects count for each service
completed_projects AS (
  SELECT category_id, COUNT(*) AS completed_projects_count
  FROM projects
  WHERE vendor = <user_id> AND status = 'Complete'
  GROUP BY category_id
)

-- Combine the results
SELECT
  s.category_id,
  c.name AS category_name,
  p.name AS subcategory_name,
  COALESCE(cp.completed_projects_count, 0) AS completed_projects_count,
  COALESCE(rs.ratings_count, 0) AS ratings_count,
  ROUND(COALESCE(rs.ratings_average, 0), 1) AS ratings_average
FROM services s
JOIN categories c ON c.id = s.category_id
JOIN categories p ON p.id = c.parent_id
LEFT JOIN rating_summary rs ON rs.category_id = s.category_id
LEFT JOIN completed_projects cp ON cp.category_id = s.category_id
WHERE s.user = <user_id> AND s.status = 'approved' AND s.active = true
ORDER BY completed_projects_count DESC;

While the AI results are good, it’s still doubtful who and how to use the tool. Not seasoned developers might don’t understand where the bottleneck is. They would struggle with finding a correct question for ChatGPT. They would not understand how to fix the generated code if it has bugs. Later, I tried to repeat the experiment. This time the machine produced a very different SQL:

Warming up --------------------------------------
                ruby     1.000  i/100ms
                 sql    52.000  i/100ms
             sql_gpt    40.000  i/100ms
         sql_gpt_new    38.000  i/100ms
Calculating -------------------------------------
                ruby      5.754  (±17.4%) i/s -     28.000  in   5.039290s
                 sql    433.067  (±20.3%) i/s -      2.080k in   5.029710s
             sql_gpt    561.018  (±14.4%) i/s -      2.760k in   5.044415s
         sql_gpt_new    514.242  (±19.4%) i/s -      2.432k in   5.013023s

Comparison:
             sql_gpt:      561.0 i/s
         sql_gpt_new:      514.2 i/s - same-ish: difference falls within error
                 sql:      433.1 i/s - same-ish: difference falls within error
                ruby:        5.8 i/s - 97.50x  slower

However, it’s still faster than the original rewrite to SQL.

Conclusion

ChatGPT is very good at code refactoring and transforming Ruby code into SQL. Even though the results are impressive it still needs an expert communicating with the tool to form a correct question, check the produced results, and fix minor issues. The results can be a good start in code refactoring and optimization.

That was a great meeting. We had a memorable time together. Thanks to everyone who participated. I am looking forward to our weekly calls and I invite everyone to join the community.

Happy coding!

Optimize Rails app performance with ChatGPT was originally published by Andrei Kaleshka at Take your Rails development to the next level on June 07, 2023.

Boost Your Business with Expert Ruby on Rails Development Consultancy

2023-05-31 13:43:33 +0200T00:00:00-00:00

Nowadays, a robust and efficient web application is crucial for businesses. Ruby on Rails (RoR), is a popular and powerful web development framework. It can help transform your ideas into scalable and fast applications. Yet, RoR development can be challenging without the right expertise. A specialized Ruby on Rails development consultancy can help you with that. It provides you with guidance and support. This article explores the benefits and aspects of outsourcing Ruby on Rails development.

Unleash the Power of Ruby on Rails

Ruby on Rails is made for productivity and streamlining the web development process. A skilled consultancy leverages the full potential of RoR. It utilizes its robust features, conventions, and best practices. It ensures the development is scalable and maintainable. It adds feature-rich web applications that cater to your business requirements.

Custom-Tailored Solutions

A Ruby on Rails development consultancy understands that business is unique. It does the following things:

Works closely with you to analyze your requirements.
Creates a comprehensive development roadmap.
Designs a customized solution that aligns with your business objectives.
Brainstorms ideas to craft a user-friendly interface.
Ensures your web application stands out.

Expertise and Experience

A Ruby on Rails development consultancy supplies you with an experienced professional team. Their extensive knowledge and expertise allow them to solve complex challenges. They can optimize performance and deliver high-quality results. They stay up-to-date with the latest trends and tools. It ensures your application remains cutting-edge and future-proof.

Faster Time to Market

In today’s evolving market, speed is essential. With a Ruby on Rails consultancy, you can speed up your development process and get your web application to market faster. Their agile development approach enables rapid prototyping and iterative development. Integration of new features becomes seamless. It allows you to capitalize on opportunities.

Ongoing Support and Maintenance

Building a web application is the beginning. A reputable Ruby on Rails development consultancy provides post-development support and maintenance services. They ensure your application remains secure, stable, and optimized for performance. From fixing bugs to implementing updates and enhancements. Their dedicated support team ensures to deliver a seamless user experience.

Conclusion

Partnering with a specialized Ruby on Rails development consultancy offers many advantages. From harnessing the power of RoR to receiving custom-tailored solutions and ongoing support. Their expertise and experience will elevate your development process. You speed up your time to market. You boost your business and stay ahead of the competition in the digital landscape.

Boost Your Business with Expert Ruby on Rails Development Consultancy was originally published by Andrei Kaleshka at Take your Rails development to the next level on May 31, 2023.

How to write SQL query in Ruby On Rails

2023-05-25 11:49:18 +0200T00:00:00-00:00

ActiveRecord is a central component of a Rails application. It’s a wrapper for a database used behind the scene. And the database is another essential thing in almost any web application. Understanding how these two things go along is crucial to develop a fast, performant, and correct project. Missing knowledge here leads to overengineered solutions, performance issues, and bad user experience.

In this article, you will see how to write SQL and use that knowledge in a Rails application.

How to see which SQL generated by ActiveRecord

The post uses this app to play with examples.

To see which SQL is generated by queries to models in a common Rails app, use .to_sql method. We can check that in the Rails console (run rails console and then write your experimental Ruby code there):

> Project.all.to_sql
=> "SELECT \"projects\".* FROM \"projects\""

Note, it works for any query, for example, when it uses conditions or joins:

> Project.joins(:ratings).to_sql
=> "SELECT \"projects\".* FROM \"projects\" INNER JOIN \"ratings\" ON \"ratings\".\"project_id\" = \"projects\".\"id\""

> Project.joins(:ratings).where(ratings: {rating: 5}).to_sql
=> "SELECT \"projects\".* FROM \"projects\" INNER JOIN \"ratings\" ON \"ratings\".\"project_id\" = \"projects\".\"id\" WHERE \"ratings\".\"rating\" = 5"

The query can be very complex. It can be constructed from different parts of the app using scopes, and separate classes implementing some patterns like Query Object, etc. In the end, the generated SQL query defines a related feature correctness. Hence, use this trick while debugging code to find a bug in the generated query.

How to write raw SQL in a Rails application

ActiveRecord comes with a handy interface and abstraction to write raw SQL queries. Why should one do that? Well, there can be many reasons for that:

Improving query performance.
Lack of knowledge in ActiveRecord.
Lack of functionalities in ActiveRecord.
Avoiding Arel queries (this thing is used behind the scene of ActiveRecord to generate SQL queries out of the Ruby constructions).

Whatever the reason, it’s reduced to just one desire - demand of controlling SQL queries. If you are one of this kind of person having this desire, use the following approach:

> ActiveRecord::Base.connection.execute("select * from projects").to_a
=> [
{"id"=>1,
  "description"=>"it's a test project",
  "user_id"=>3,
  "created_at"=>2022-09-29 20:10:46.751835 UTC,
  "updated_at"=>2023-01-17 23:22:42.275697 UTC,
  "status"=>"Open",
  "category"=>"Website and landing page design",
  "experience"=>"New to Widefix — under one year",
  "existing_website"=>"Yes, I already have a website set up and live for customers",
  "existing_website_platform"=>"Widefix",
  "category_tasks"=>nil,
  "delivery_timeline"=>"11-21 days",
  ...
}, ...]

Also, this API allows to write SQL queries inside migrations. It’s even easier in migrations as the execute method is available there.

To construct correct SQL you would propaply need a db console. It’s the fastest way to write pure and correct SQL related to your Rails app DB. Use rails db command to open DB console and do your experiments with SQL.

How to measure SQL query performance in Rails

To understand why SQL query is slow you can use explain analyze built-in functionality that every SQL DB has:

Project.joins(:ratings).where(ratings: {rating: 5}).explain
  Project Load (2.1ms)  SELECT "projects".* FROM "projects" INNER JOIN "ratings" ON "ratings"."project_id" = "projects"."id" WHERE "ratings"."rating" = $1  [["rating", 5]]
=>
EXPLAIN for: SELECT "projects".* FROM "projects" INNER JOIN "ratings" ON "ratings"."project_id" = "projects"."id" WHERE "ratings"."rating" = $1 [["rating", 5]]
                                      QUERY PLAN
---------------------------------------------------------------------------------------
 Nested Loop  (cost=0.14..9.63 rows=1 width=1694)
   ->  Seq Scan on ratings  (cost=0.00..1.29 rows=1 width=8)
         Filter: (rating = 5)
   ->  Index Scan using projects_pkey on projects  (cost=0.14..8.16 rows=1 width=1694)
         Index Cond: (id = ratings.project_id)
(5 rows)

If the query was slow, we had to pay attention to the Seq Scan on ratings. That means the it didn’t use index to filter ratings by the rating = 5 condition. We can add a corresponding index to fix the issue.

Another problem that is frequently related to performance penalties is N+1 queries. Why many solutions can help with that, it’s pretty easy to detect the issues by looking into logs. Many repeated lines with the following format indicate that issue:

  Category Load (0.9ms)  SELECT "categories".* FROM "categories" WHERE "categories"."id" = $1 LIMIT $2  [["id", 3], ["LIMIT", 1]]
  ↳ app/queries/services_stats_query.rb:48:in `block in call_ruby'
  Category Load (0.9ms)  SELECT "categories".* FROM "categories" WHERE "categories"."id" = $1 LIMIT $2  [["id", 1], ["LIMIT", 1]]
  ↳ app/queries/services_stats_query.rb:48:in `block in call_ruby'
  Category Load (0.8ms)  SELECT "categories".* FROM "categories" WHERE "categories"."id" = $1 LIMIT $2  [["id", 3], ["LIMIT", 1]]
  ↳ app/queries/services_stats_query.rb:49:in `block in call_ruby'
  Rating Load (0.9ms)  SELECT "ratings".* FROM "ratings" WHERE "ratings"."reviewee_id" = $1  [["reviewee_id", 10]]
  ↳ app/queries/services_stats_query.rb:37:in `block in call_ruby'
  Project Load (1.0ms)  SELECT "projects".* FROM "projects" WHERE "projects"."id" = $1 LIMIT $2  [["id", 27], ["LIMIT", 1]]
  ↳ app/queries/services_stats_query.rb:38:in `block (2 levels) in call_ruby'
  Project Load (0.9ms)  SELECT "projects".* FROM "projects" WHERE "projects"."id" = $1 LIMIT $2  [["id", 39], ["LIMIT", 1]]
  ↳ app/queries/services_stats_query.rb:38:in `block (2 levels) in call_ruby'
  Project Load (0.9ms)  SELECT "projects".* FROM "projects" WHERE "projects"."id" = $1 LIMIT $2  [["id", 86], ["LIMIT", 1]]

Usually, eager loading techniques fix this issue. But that’s a topic for a separate article.

Play with SQL in Rails apps with confidence

Now you know all the essential tricks to work with SQL in a Rails application.

Moving further, you can read the following articles that expand the related knowledge:

These articles show how to use SQL within Rails applications efficiently on practical examples. They also explain some useful but not very popular in the Rails community SQL tricks.

Happy coding!

How to write SQL query in Ruby On Rails was originally published by Andrei Kaleshka at Take your Rails development to the next level on May 25, 2023.

Improve NextJS application performance

2023-05-24 18:23:56 +0200T00:00:00-00:00

To improve the performance of your app built on React and Next.js using TypeScript, you can follow several strategies.

Code Optimization

Minimize unnecessary re-renders by using React.memo, useMemo, and useCallback hooks to memoize components and functions that don’t depend on changing data. Avoid unnecessary state updates and re-renders by optimizing the usage of useState and useEffect hooks.

Using TypeScript’s type checking can catch potential errors and improve code quality.

Bundle Size Optimization

Split your code into smaller chunks using dynamic imports and code splitting. This allows you to load only the necessary code for each page or component, reducing the initial bundle size and improving load times. Analyze your bundle using tools like Webpack Bundle Analyzer to identify and eliminate any unnecessary dependencies or large libraries. Compress and optimize your assets (images, CSS, etc.) to reduce their size and improve load times. Next.js has built-in Image component that allows to compress images on the fly. It also converts then to modern image formats that are lightweight.

Server-Side Rendering (SSR) and Static Site Generation (SSG)

Utilize Next.js’s built-in features for server-side rendering and static site generation to pre-render pages and improve initial load times. This reduces the amount of work required by the client’s browser. Identify pages that don’t require real-time data and generate them statically using Next.js’s getStaticProps or getStaticPaths functions. This eliminates the need for client-side rendering and improves performance.

Performance Monitoring and Optimization

Use performance monitoring tools like Lighthouse, WebPageTest, or Chrome DevTools to identify performance bottlenecks, such as slow-loading components, large files, or long JavaScript execution times. Optimize critical rendering paths by prioritizing the loading of essential content and deferring non-critical scripts or styles. Implement lazy loading for images and other non-essential assets to load them only when they become visible in the viewport. Implement caching mechanisms for API requests or frequently accessed data to reduce server load and improve response times.

SSR Caching and Incremental Static Regeneration

Utilize Next.js’s caching capabilities to cache rendered pages on the server-side and serve them directly for subsequent requests, reducing the need for re-rendering. Implement incremental static regeneration for pages that require dynamic data. This allows you to re-generate and update specific pages at predefined intervals, ensuring the content stays fresh while reducing the load on the server.

Performance Testing and Optimization Iteration

Regularly test your app’s performance using tools like Lighthouse or Chrome DevTools to measure metrics like First Contentful Paint (FCP), Time to Interactive (TTI), and Total Blocking Time (TBT). Set performance budgets and strive to stay within them. Continuously analyze and optimize critical paths, reducing the time required for JavaScript execution, network requests, and rendering. Remember to always profile and benchmark your optimizations to ensure they have a positive impact on your app’s performance.

Improve NextJS application performance was originally published by Andrei Kaleshka at Take your Rails development to the next level on May 24, 2023.

Choosing Top-Tier Ruby on Rails Consulting

2023-05-23 13:47:19 +0200T00:00:00-00:00

Ruby on Rails has long been recognized as a powerful web development framework, enabling developers to build robust and scalable applications with ease. However, navigating the vast landscape of Ruby on Rails development can be a daunting task, especially when faced with complex projects and tight deadlines. This is where top-tier Ruby on Rails consulting services come into play, offering invaluable expertise, guidance, and support. In this article, we explore the benefits of engaging with renowned Ruby on Rails consulting firms, shedding light on why partnering with the best can make all the difference.

Leveraging Deep Domain Expertise

Top-tier Ruby on Rails consulting firms boast teams of skilled professionals. They have honed their expertise through years of hands-on experience. These experts have an in-depth understanding of Ruby on Rails and its ecosystem. That allows them to navigate complex challenges. By leveraging their domain expertise, these consultants can provide invaluable insights. They can recommend best practices and suggest innovative solutions to your project specifics. Their guidance ensures that your application is efficient, scalable, and maintainable.

Accelerating Development Time

Time is of the essence in today’s fast-paced business environment. Partner with a Ruby on Rails consulting firm to hurry your project’s timeline. But make sure you choose a reputable consulting firm. These firms are adept at optimizing development workflows. They leverage reusable code libraries to ensure rapid development cycles. With their expertise, you can deliver high-quality applications within tight deadlines. With that, you gain a competitive edge in the market.

Ensuring Scalability and Performance

Building a scalable and high-performing application is crucial for long-term success. Ruby on Rails consulting firms understand the intricacies of scaling applications. That handles growing user bases and increasing traffic. They use proven techniques and architectural patterns. That ensures your application can handle heavy loads. They incorporate strategies such as caching, load balancing, and database optimization. They ensure your application can scale as your business grows. They provide a smooth user experience and avoid potential bottlenecks.

Security and Risk Mitigation

Data security and risk mitigation are crucial concerns for any business operating. Renowned Ruby on Rails consulting firms focus on robust security practices. They have extensive experience in implementing industry-standard security measures. They can conduct comprehensive security audits. They can identify vulnerabilities and put in place stringent security protocols. All that is to safeguard your application and sensitive data. By mitigating risks, these experts help you build trust with your users. That protects your brand reputation.

Continued Support and Maintenance

Launching your Ruby on Rails application is the beginning. Ongoing support and maintenance are crucial. A good consulting firm ensures smooth operation and addresses any emerging issues. Top-tier consulting firms provide reliable post-launch support. They offer timely bug fixes, performance optimizations, and feature enhancements. At the same time, you can rest. You know that your application will remain up-to-date, secure, and functional. That allows you to focus on your core business activities.

Conclusion

Nowadays, choosing the right Ruby on Rails consulting partner is vital for success. By engaging with top-tier consulting firms, you can leverage their deep domain expertise. You speed up development time. Your project gets scalable and performant. You have risks mitigated and receive continued support. The benefits —higher-quality applications, reduced time-to-market, enhanced security, and peace of mind. Be sure to partner with a reputable consulting firm that can unlock the full potential of your application.

Choosing Top-Tier Ruby on Rails Consulting was originally published by Andrei Kaleshka at Take your Rails development to the next level on May 23, 2023.

Make your Ruby on Rails app 80x faster with SQL

2023-03-30 11:59:17 +0200T00:00:00-00:00

SQL can improve the performance and efficiency of your Ruby on Rails application. No need for heavy technologies. No need for switching to another programming language or framework.

SQL is a powerful tool that can take your Ruby on Rails expertise to the next level. Nowadays many technologies claim to replace SQL or deem Ruby on Rails as “too slow”. But it remains a popular and efficient choice for many web projects. This article will explore the importance of SQL for Ruby on Rails experts. It will show why it’s a must-have skill in today’s development landscape.

Why Ruby on Rails can be slow

Imagine the following class that’s used in a Rails controller to feed data to a page in your application. This class may look familiar to you. I’ve encountered similar classes in real-world applications:

class ServicesStatsQuery
  attr_accessor :user

  def initialize(user)
    self.user = user
  end

  def call
    projects_full = []
    projects_empty = []
    Service.where(user: user, status: "approved", active: true)
      .order(category_id: :asc).each do |service|
      ratings_average = 0
      ratings_count = 0
      ratings_total = 0
      Rating.where(reviewee: user).each do |rating|
        project = Project.find(rating.project_id)
        if project.category_id == service.category_id
          ratings_count += 1
          ratings_total += rating.rating
        end
      end
      ratings_average = (ratings_total / ratings_count.to_f).round(1).to_s if ratings_count != 0 && ratings_total != 0
      completed_projects_count =
        Project.where(vendor: user, status: "Complete", category_id: service.category_id).size
      service_hash = {
        category_id: service.category_id,
        category_name: Category.find(Category.find(service.category_id).parent_id).name,
        subcategory_name: Category.find(service.category_id).name,
        completed_projects_count: completed_projects_count,
        ratings_count: ratings_count,
        ratings_average: ratings_average,
      }
      resolved_hash = service_hash.transform_keys{ |k| k.to_s.camelize(:lower) }
      if completed_projects_count > 0
        projects_full.push(resolved_hash)
      else
        projects_empty.push(resolved_hash)
      end
    end
    projects_full.sort_by!{ |k| -k["completedProjectsCount"] }
    projects_full.push(*projects_empty)

    projects_full
  end
end

Your application is running in production and serving the needs of hundreds of users. You’ve noticed that the related page is becoming slower and slower with each passing day. This can be a frustrating problem to solve. It’s natural to feel tempted to consider drastic measures. You can think of switching to a faster programming language. Or you might plan to use heavy technology.

Before taking such drastic steps take a step back and understand the root cause of the issue.

There are a few things that could be contributing to the slowness of this code:

N+1 queries: The code is making a separate database query for each rating. Then it gets the associated project. That can become slow if there are a large number of ratings.
Nested each loops: The code is using this method to iterate over the Service. For each service in the nested loop, it iterates through all related Rating records. That can also be slow if there are many records. Instead, it would be better to use SQL joins to fetch all the data in a single query.
Redundant queries: The code is calling Category.find many times. Instead, better to fetch all the category data using a single query. And then use it to populate the service_hash object.

Optimizing this code will need a combination of SQL query optimization. That should cut unnecessary database queries and improve the performance of the code.

How to analyze slow Ruby On Rails code

There are plenty of tools out there, like bullet, benchmark-ips, or any others.

But before taking these radical steps use what you already have. Open logs (use command tail -f log/development.log for local). Observe what happens there while you open the slow page in your browser. If you spot many repeating lines like this one you have an N+1 problem:

00:03:22 web.1 | Rating Load (1.6ms)  SELECT "ratings".* FROM "ratings" WHERE "ratings"."user_id" = $1  [["user_id", 15]]

Pay attention to the phrase “Rating Load” as it serves as an indicator. If you notice “CACHE Rating Load”, there’s no need to worry. The object is already in memory, retrieved from there without accessing the database. This suggests that eager loading is already working.

Another tool is to visually inspect the code. You can feel discomfort and uncertainty when trying to understand how the code pieces relate to each other. Yet, this is not related to performance. The most crucial aspect is that the code contains a nested loop, which indicates that its complexity is squared. As more objects are iterated, a squared function grows rapidly:

Sorry for getting into the math, but it’s important to understand that your code should ideally grow linearly or at least logarithmically. This is the best way to ensure that your code’s performance remains optimal for many years to come.

If you are unsure about what all of that means, now is a good time to start learning about the theory of algorithms and data structures.

Use SQL to improve Rails application performance

To fetch all the required data in a single query while performing the necessary aggregation, sorting, and grouping, consider using this SQL query:

select
  s.category_id as "categoryId",
  pc.name as "categoryName",
  c.name as "subcategoryName",
  count(p.id) as "completedProjectsCount",
  r.count as "ratingsCount",
  r.avg as "ratingsAverage"
  from services s
  join categories c on c.id = s.category_id
  join categories pc on pc.id = c.parent_id
  left join lateral (
    select count(r.id), cast(round(coalesce(avg(r.rating), 0), 1) as text) as avg from ratings r
    join projects rp on rp.id = r.project_id and s.category_id = rp.category_id
    where r.reviewee_id = :user_id
  ) r on true
  left join projects p on p.vendor_id = :user_id and p.status = 'Complete' and p.category_id = s.category_id
  where s.status = 'approved' and s.active and s.user_id = :user_id
  group by s.category_id, pc.name, c.name, r.count, r.avg
  order by count(p.id) desc, s.category_id asc

One way to test this query is to replace the placeholder :user_id with an actual user id. Then, we can open the DB console and paste the query to see if it produces the expected results.

Make sure the query is successful and returns the desired results. Then we can replace the slow Ruby code with this efficient SQL query:

class ServicesStatsQuery
  SQL = <<~SQL
    select
      s.category_id as "categoryId",
      pc.name as "categoryName",
      c.name as "subcategoryName",
      count(p.id) as "completedProjectsCount",
      r.count as "ratingsCount",
      r.avg as "ratingsAverage"
      from services s
      join categories c on c.id = s.category_id
      join categories pc on pc.id = c.parent_id
      left join lateral (
        select count(r.id), cast(round(coalesce(avg(r.rating), 0), 1) as text) as avg from ratings r
        join projects rp on rp.id = r.project_id and s.category_id = rp.category_id
        where r.reviewee_id = :user_id
      ) r on true
      left join projects p on p.vendor_id = :user_id and p.status = 'Complete' and p.category_id = s.category_id
      where s.status = 'approved' and s.active and s.user_id = :user_id
      group by s.category_id, pc.name, c.name, r.count, r.avg
      order by count(p.id) desc, s.category_id asc
  SQL

  attr_accessor :user

  def initialize(user)
    self.user = user
  end

  def call
    sql = ActiveRecord::Base.sanitize_sql_array([SQL, user_id: user.id])
    ActiveRecord::Base.connection.execute(sql).to_a
  end
end

This SQL query can provide fast results for most Ruby On Rails applications. Although, it assumes that the DB has appropriate indexes defined.

Native SQL is much faster than the pure Ruby on Rails code

It’s time to perform measurements. First, install the benchmark-ips gem. Then you can prepare the following code and save it in a file. For example, t.rb, in the root directory of your Rails application:

require 'benchmark/ips'

user = User.find(10)
service = ServicesStatsQuery.new(user)

Benchmark.ips do |x|
  x.report("ruby") { service.call_ruby }
  x.report("sql") { service.call_sql }
  x.compare!
end

We change the ServicesStatsQuery a bit to have the two methods defined call_ruby and call_sql instead of one method call:

class ServicesStatsQuery
  SQL = <<~SQL
    select
      s.category_id as "categoryId",
      pc.name as "categoryName",
      c.name as "subcategoryName",
      count(p.id) as "completedProjectsCount",
      r.count as "ratingsCount",
      r.avg as "ratingsAverage"
      from services s
      join categories c on c.id = s.category_id
      join categories pc on pc.id = c.parent_id
      left join lateral (
        select count(r.id), cast(round(coalesce(avg(r.rating), 0), 1) as text) as avg from ratings r
        join projects rp on rp.id = r.project_id and s.category_id = rp.category_id
        where r.reviewee_id = :user_id
      ) r on true
      left join projects p on p.vendor_id = :user_id and p.status = 'Complete' and p.category_id = s.category_id
      where s.status = 'approved' and s.active and s.user_id = :user_id
      group by s.category_id, pc.name, c.name, r.count, r.avg
      order by count(p.id) desc, s.category_id asc
  SQL

  attr_accessor :user

  def initialize(user)
    self.user = user
  end

  def call_ruby
    projects_full = []
    projects_empty = []
    Service.where(user: user, status: "approved", active: true).order(category_id: :asc).each do |service|
      ratings_average = 0
      ratings_count = 0
      ratings_total = 0
      Rating.where(reviewee: user).each do |rating|
        project = Project.find(rating.project_id)
        if project.category_id == service.category_id
          ratings_count += 1
          ratings_total += rating.rating
        end
      end
      ratings_average = (ratings_total / ratings_count.to_f).round(1).to_s if ratings_count != 0 && ratings_total != 0
      completed_projects_count = Project.where(vendor: user, status: "Complete", category_id: service.category_id).size
      service_hash = {
        category_id: service.category_id,
        category_name: Category.find(Category.find(service.category_id).parent_id).name,
        subcategory_name: Category.find(service.category_id).name,
        completed_projects_count: completed_projects_count,
        ratings_count: ratings_count,
        ratings_average: ratings_average,
      }
      resolved_hash = service_hash.transform_keys{ |k| k.to_s.camelize(:lower) }
      if completed_projects_count > 0
        projects_full.push(resolved_hash)
      else
        projects_empty.push(resolved_hash)
      end
    end
    projects_full.sort_by!{ |k| -k["completedProjectsCount"] }
    projects_full.push(*projects_empty)

    projects_full
  end

  def call_sql
    sql = ActiveRecord::Base.sanitize_sql_array([SQL, user_id: user.id])
    ActiveRecord::Base.connection.execute(sql).to_a
  end
end

Run it with the command: rails runner t.rb and see the results:

Warming up --------------------------------------
                ruby     1.000  i/100ms
                 sql    48.000  i/100ms
Calculating -------------------------------------
                ruby      5.658  (± 0.0%) i/s -     29.000  in   5.147460s
                 sql    451.144  (± 8.6%) i/s -      2.256k in   5.042193s

Comparison:
                 sql:      451.1 i/s
                ruby:        5.7 i/s - 79.74x  slower

Performance boost of almost 80 times! The slow-loading page that took over 30 seconds now loads within 300ms. This significant improvement is not the programming language or framework merit.

Demo: Faster SQL in Ruby on Rails App

I have developed a demo application using both Ruby and SQL versions and made it available on GitHub as an open source project. This means that you have the opportunity to experiment with the code and run benchmarks on your own.

Determine whether to use the measurement tools or not

You can analyze performance issues and measure optimization results without fancy tools. benchmark-ips is for demonstration purposes. The best tools are reading the code, and understanding it. Then analyze its complexity. Finally, use SQL knowledge. These tools are enough. Nothing can replace them. Well, except in the distant future, ChatGPT may offer more help.

There are always plenty of built-in tools by your hand. Learn how to use them. For example, moving further, the written SQL can be slow. You will have to check why. Use explain analyze for that. This is a built-in tool in all modern SQL databases.

Why Ruby on Rails expert should know SQL

Ruby on Rails is a powerful web application framework. It provides developers with high-level abstractions and conventions. That allows to build web applications quickly and efficiently. But, despite its powerful abstractions, Ruby on Rails experts need to know SQL.

SQL allows Ruby on Rails experts to write efficient and optimized database queries. That can improve the performance of a web application. By understanding SQL, a Ruby on Rails expert can design the database schema and data access layer. If that’s done well, the application maximizes performance, scalability, and maintainability.

SQL is a widely-used and powerful language. People use it beyond interacting with the database. Ruby on Rails experts use SQL to perform complex calculations and data transformations. They can generate reports that are challenging to achieve using Ruby code alone.

SQL allows Ruby on Rails experts to have more control over their web applications. They write more efficient and optimized code. They make better data-driven decisions.

How can a Ruby on Rails expert learn SQL

Nowadays, there are plenty of courses and books available on the subject. So it’s hard to recommend specific resources. You can choose whatever you like and suits your learning style.

But, if you are like me and prefer hands-on learning, you might find the following resource helpful - https://pgexercises.com/.

You might also find this article I wrote previously interesting - Financial plan on PostgreSQL.

Make your Ruby on Rails app 80x faster with SQL was originally published by Andrei Kaleshka at Take your Rails development to the next level on March 30, 2023.

Send Emails with SendGrid: A Step-by-Step Guide for Ruby on Rails Applications

2023-03-15 15:29:47 +0100T00:00:00-00:00

Sending emails from a Ruby on Rails application can be a critical aspect of many web applications. Whether it’s for sending password resets, notifications, newsletters or transactional emails, you want your emails to be reliable and fast. That’s where SendGrid comes in. This article guides you through the process of sending emails from your Ruby on Rails application using SendGrid.

Before you start, it’s crucial to understand that username and password authentication for email delivery is no longer sufficient. Nowadays, email provider services like SendGrid require more rigorous verification processes to ensure secure and reliable email delivery. As such, the first step in this journey is setting up your SendGrid account properly.

SendGrid Account Setup

To get started with SendGrid in your Ruby on Rails application, you first need to sign up for a SendGrid account and obtain an API key. Once you have created it, make sure to copy it somewhere. Otherwise, you won’t be able to read it later.

It’s recommended to have completed the Domain Authentication process to ensure the deliverability of your emails. This step requires registering your domain, either your own or one provided by other services such as Heroku that generate it automatically. By authenticating your domain, you can verify that you are a legitimate sender, improve email deliverability, and reduce the risk of your emails being flagged as spam.

When using SendGrid to send emails from your Ruby on Rails application, it’s essential to verify the email address from which the emails will be sent. This verification process involves adding the email address to your SendGrid account and proving that you have access to it. Failure to verify the email address can result in errors when attempting to send emails, such as authentication failures or email delivery issues. Therefore, it’s crucial to verify any email addresses you plan to use for sending emails to ensure reliable and error-free email delivery.

After these steps completed, you should have:

The API key (a long abrakadabra string) like this: SG.ve9OolaiLeenoh0iatoon0.hei8geiz1Shoorohtai6choopah8cahjae9vako8uBa
Verified domain, let it be mydomain.com
Verified sender email address, let it be hello@mydomain.com

Configure server

The Rails application will be configured via environment variables, which should be defined on your server (or on your local machine if you want to send emails from it):

SMTP_DEFAULT_FROM:        <your sender email>
SMTP_DOMAIN:              <your domain>
SMTP_PASSWORD:            <your api key>
SMTP_LOGIN:               apikey
SMTP_PORT:                587
SMTP_SERVER:              smtp.sendgrid.net

Note that some of the values are static, while others are placeholders that you should replace with your own values. SMTP_LOGIN, SMTP_PORT, and SMTP_SERVER are static and will always have the same values. It is important to note that SMTP_LOGIN will always equal apikey, and you will not have your own value for that.

Here is an example of how to do that using the Heroku command line:

heroku config:set SMTP_DEFAULT_FROM="Hello <hello@mydomain.com>" SMTP_DOMAIN=mydomain.com SMTP_LOGIN=apikey SMTP_PASSWORD=SG.ve9OolaiLeenoh0iatoon0.hei8geiz1Shoorohtai6choopah8cahjae9vako8uBa SMTP_PORT=587

Configure Ruby On Rails

Emails are typically sent from a production server. Therefore, you need to add the necessary configuration to the config/environments/production.rb file as follows:

  config.action_mailer.smtp_settings = {
    port: ENV.fetch('SMTP_PORT'),
    address: ENV.fetch('SMTP_SERVER'),
    user_name: ENV.fetch('SMTP_LOGIN'),
    password: ENV.fetch('SMTP_PASSWORD'),
    domain: ENV.fetch('SMTP_DOMAIN'),
    authentication: :plain,
    enable_starttls_auto: true
  }
  config.action_mailer.delivery_method = :smtp

Make sure that these settings are not overridden elsewhere in this file.

If you need to send emails from development or staging mode, add these lines to the respective files config/environments/development.rb or config/environments/staging.rb. Deliver these changes to your server.

Testing

That’s all the steps needed to get it done. But before moving on to your next task, let’s make sure everything is working correctly. Open the Rails console and define a variable with the email address you want to send a verification email to (for this example, we’ll use my@example.com; replace it with your own):

to_email = 'my@example.com'

And then paste there the following code snippet:

mailer = ActionMailer::Base.new
mailer.mail(from: ENV['SMTP_DEFAULT_FROM'], to: to_email, subject: 'Test from WideFix guide', body: "Hello, you've got mail!").deliver

Wait a bit and you should receive the email in your inbox.

If you follow these steps correctly, all mailers defined in your Rails application will start using SendGrid for sending emails, and no additional configuration or checks are required.

Send Emails with SendGrid: A Step-by-Step Guide for Ruby on Rails Applications was originally published by Andrei Kaleshka at Take your Rails development to the next level on March 15, 2023.

Unlocking the Power of ChatGPT with Ruby

2023-02-22 22:31:11 +0100T00:00:00-00:00

Are you looking to harness the power of artificial intelligence and machine learning to streamline your coding workflow? ChatGPT and Ruby are two powerful tools that can help you do just that. However, if you’re new to these tools, getting started can be daunting. That’s where our beginner-friendly guide comes in. In this article, we’ll take you through everything you need to know to use ChatGPT with Ruby, from the basics of integration to more advanced features. Whether you’re a seasoned developer or just starting out, this guide will help you unlock the full potential of these powerful tools and take your coding skills to the next level.

Before you start integrating the ChatGPT API, you need to register for an API key and obtain your credentials from the ChatGPT website. To do that, follow this page.

Create the following class in your Ruby On Rails or any other Ruby-based project:

class OpenaiPrompt
  extend Dry::Initializer

  URL = "https://api.openai.com/v1/completions"

  param :prompt

  option :model, default: proc { "text-davinci-003" }
  option :max_tokens, default: proc { 1000 }
  option :temperature, default: proc { 0 }

  def call
    connection =
      Faraday.new do |faraday|
        faraday.ssl[:verify] = false
        faraday.headers = headers
      end
    response = connection.post(URL, body)
    json = JSON.parse(response.body)
    json["choices"].first["text"]
  end

  private

  def body
    {
      model: model,
      prompt: prompt,
      max_tokens: max_tokens,
      temperature: temperature
    }.to_json
  end

  def headers
    {
      "Content-Type" => "application/json",
      "Authorization" => "Bearer #{ENV['OPENAI_ACCESS_TOKEN']}",
      "OpenAI-Organization" => ENV['OPENAI_ORGANIZATION_ID']
    }
  end
end

You can define your ChatGPT class within an existing file or create a new one specifically for it. However, it is generally recommended to create a separate file for your ChatGPT class for better organization and modularity of your code. This makes it easier to find and modify your ChatGPT code in the future without affecting other parts of your project. If it’s a Ruby On Rails application, app/services/openai_prompt.rb is a good file location for this piece of code.

This class has the following dependencies (gems) that should be added to your Gemfile:

faraday - This is a handy library that provides an abstract interface for making HTTP requests. It simplifies the process of making requests to external APIs and handling responses.
dry-initializer - This library allows you to define the new method implicitly, reducing the amount of repetitive code required. This makes it easier to create new instances of your class without having to manually define instance variables and their default values.

To use the OpenaiPrompt class, you first need to define the environment variable OPENAI_ACCESS_TOKEN. If you have multiple organizations registered within ChatGPT, you can also define the optional OPENAI_ORGANIZATION_ID environment variable.

Once you have set these environment variables, you can use the OpenaiPrompt class from any line of your project by simply calling OpenaiPrompt.new('Why is Ruby an awesome programming language?').call.

Here is an example of how you can use the OpenaiPrompt class in a Rails console:

> OpenaiPrompt.new('Why is Ruby awesome programming language?').call
> # => "\n\nRuby is an awesome programming language because it is easy to learn and use, has a large and supportive community, and is highly flexible and powerful. It is also object-oriented, meaning that it allows developers to create complex applications quickly and easily. Additionally, Ruby is open source, meaning that it is free to use and modify. Finally, Ruby is known for its readability, which makes it easier for developers to understand and debug code."

ChatGPT offers a wide range of functionalities and models that can be utilized in various ways, not just limited to answering common questions. For instance, you can leverage GPT-3 to generate text for creative writing, content generation, or chatbot responses.

The OpenaiPrompt class serves as an example of how you can use ChatGPT to answer common questions programmatically. However, the same principles can be applied to build other classes that utilize ChatGPT’s other capabilities.

Furthermore, integrating ChatGPT with a user interface, such as a web form or a chatbot, can allow users to ask questions and get responses in a more intuitive manner. This can be particularly useful for applications that require natural language processing and understanding, such as customer service chatbots or virtual assistants. By integrating ChatGPT with a UI, you can make it more accessible and user-friendly for non-technical users.

If you have questions or need to integrate ChatGPT into your Ruby On Rails or any other Ruby-based project, please contact.

Unlocking the Power of ChatGPT with Ruby was originally published by Andrei Kaleshka at Take your Rails development to the next level on February 22, 2023.

Fake Time.now in production

2023-02-08 13:59:03 +0100T00:00:00-00:00

TL;DR: see this gist.

As a Ruby on Rails expert, you may find yourself wondering how to debug a Rails application in production. In some cases, you may need to mimic the current time to check a time-dependent function result.

While there are third-party gems that offer the ability to fake Time.now functionality, Rails has this built-in functionality as part of the ActiveSupport::Testing::TimeHelpers module. However, this module is only intended for use in testing and not in production environments.

Time.now          # => Wed, 08 Feb 2023 14:01:33 UTC +00:00
travel 1.day.ago
Time.now          # => Tue, 07 Feb 2023 14:01:33 UTC +00:00
Date.current      # => Tue, 07 Feb 2023

Check in production console:

travel 1.day.ago
# => Traceback (most recent call last):
#    NoMethodError (undefined method `travel' for main:Object)

If you want to use the travel or freeze_time method in production, you can load the module source code and include it into the console runtime:

mod = "https://raw.githubusercontent.com/rails/rails/2a2a6ab6219b12e9e77931a60fe83c658db44ac7/activesupport/lib/active_support/testing/time_helpers.rb"
eval(open(mod).read)
include ActiveSupport::Testing::TimeHelpers

travel_to(1.day.ago) { Time.now } # => Tue, 07 Feb 2023 14:01:33 UTC +00:00

Tip: Use Time.current instead of Time.now. This blog post uses Time.now only for demonstration purposes due to its widespread usage over Time.current.

Here’s an example of how I recently implemented this in a production environment. In our project, we have a function called Plan#stripe_id that links to a product pricing object. The pricing is dependent on the current time because on February 15th, the project’s prices will be increased. Before February 15th, the system uses the old prices, but after that date, it uses the new prices.

Here’s how the method is defined:

class Plan < ApplicationRecord
  NEW_PRICES_TIME = '15 Feb 21:00 UTC'.to_datetime

  def stripe_id
    if NEW_PRICES_TIME.past?
      stripe_price_id || name
    else
      name
    end
  end
end

Please note that name is a deprecated column referring to an outdated Stripe product price.

Once this feature is deployed to production, we will verify its functionality across all plans by accessing the production Rails console and reviewing the pre-implementation values.

Checking how it works now:

Plan.all.map(&:name) # => ["a", "b"]

And then we do the same at the traveled time after Feb 15:

mod = "https://raw.githubusercontent.com/rails/rails/2a2a6ab6219b12e9e77931a60fe83c658db44ac7/activesupport/lib/active_support/testing/time_helpers.rb"
eval(open(mod).read)
include ActiveSupport::Testing::TimeHelpers

travel_to("16 Feb, 2024".to_datetime) { Plan.all.map(&:name) } # => ["a_2023", "b_2023"]

With this verification process, we can now confidently say that the production environment is functioning correctly and will be utilizing the correct prices after Feb 15, thereby avoiding any unexpected issues in the final stages.

Be aware of the following security concerns before proceeding with these steps

Loading code from an external source via an HTTP link can pose a security risk as it may contain malicious code. A recommended solution is to use unit tests. However, unit tests cannot guarantee the behavior of code in a production environment. In emergency situations where time is of the essence, a faster and more creative approach may be necessary to ensure the code’s integrity.

The security concern can be addressed by creating the link yourself. To do so, visit the GitHub Rails repository, search for the time_helpers.rb file, and click the “Raw” button. This will generate the link. However, it is important to note that even this manual process does not guarantee the absence of malicious code, as the resource may have been tampered with by hackers. Always review the contents before evaluating them:

url = "<HTTP LINK>"
code = open(url).read
puts code

It’s important to carefully review the code before evaluating it, to ensure it is the original, intended code and not something malicious. Only after confirming the authenticity of the code should you include it as a module:

eval(code)
include ActiveSupport::Testing::TimeHelpers

If there is limited time to review the code, a simple check can help prevent dangerous actions. This can be done by raising an error if a specific line of code is not present. This will serve as a safeguard and ensure that any malicious code is not executed:

raise 'dangerous code' unless code.include?('module ActiveSupport')

Manipulating production systems can be risky and should only be done with a high level of confidence in what you are doing. Although in some scenarios, the console is the only solution to fix a production issue, it should be approached with caution. Before making any changes, consider the potential impact and weigh the decision carefully, as even a small mistake can have significant consequences. In some cases, the cost of fixing the issue through other means may be less than the cost of fixing the mistake made in the production console.

At WideFix, we take pride in our expertise and experience. You can trust that our solutions will not harm your business and will always keep your site running smoothly. You can rely on us to provide confident and effective solutions that meet your needs.

Hire Ruby On Rails expert now

Fake Time.now in production was originally published by Andrei Kaleshka at Take your Rails development to the next level on February 08, 2023.

Take your Rails development to the next level

New UI Features for Schema Tracking and Migration Management in ActualDbSchema

View Schema with Migration Annotations in the UI

Clean Up Broken Migrations

Filter Migrations in the UI

Customize Your Migrated Folder Location

Conclusion

Trace Schema Changes & Run Migrations in Rails Console with ActualDbSchema

Schema Diff with Migration Annotations

Console Migrations

Conclusion

Multiple schemas support added to ActualDbSchema

Rake task added to initialize the gem

DSL for configuring the gem

Support for multiple database schemas

The link to Changelog fixed

Run the git hook on switch branch only

Conclusion

The Importance of Understanding the What and Why in Software Development

Understanding the “What” and “Why” in Software Development: A Mentorship Story

The Task: Implementing a Refund Operation

What Went Wrong?

Why It Happened

The Lesson: Understanding What and Why

Mentoring Junior Developers

Conclusion

Personal Gemfile for development

Configure the gem not to run

Local Gemfile

Conclusion

Prevent account sharing with MFA

Why to prevent sharing account

Prevent account sharing with a third-party service

Our path to a solution for preventing account sharing

Solution #1: logs analysis

Solution #2: unique token per device written in cookies

Solution #3: login session concept

Solution #4: device limit, limit of login sessions

Our results, analysis, and reports

Summary

Reconcile app users vs Stripe and prevent financial losses

Possible discrepancies in Stripe integrations

Stripe integration state of our application

The plan to reconcile data with Stripe

Stripe data store preparation

The Stripe data scrapper

Run the script automatically

Analyze Stripe data discrepancies with SQL

Fixing the data deviations between the app and Stripe

Preventing future discrepancies

Conclusion

Smart route aliases in Rails

Cheaper and Risk-Free Ruby on Rails App Redesign

Ruby on Rails app redesigning challenges

Why redesigning a Ruby on Rails app

What is the new design

Different technical approaches of a Ruby on Rails app redesign

Risk-free approach of a Ruby on Rails app redesign

Our results of the Ruby on Rails app redesign

Why our approach of Ruby on Rails app redesign is cheaper and less risky

Acknowledges

Select unique latest grouped records from DB

Recent records - the task overview

How window function with row number partition works

Use subselect to filter correct results

Use ActiveRecord.from to return the results as Ruby objects

Conclusion

Use timestamp for predicates in Rails

Why use timestamp field instead of boolean for checkbox

Avoid code duplicating with a universal solution

Conclusion

Optimize Rails app performance with ChatGPT

ChatGPT request to transform Ruby code into SQL

Should one use ChatGPT to optimize code performance or not

Conclusion

Boost Your Business with Expert Ruby on Rails Development Consultancy

Unleash the Power of Ruby on Rails

Custom-Tailored Solutions

Expertise and Experience

Faster Time to Market