To ensure a dependency is installed with the engine during gem install, it must be specified within the Gem::Specification block inside the engine's .gemspec file (e.g., blog.gemspec for an engine named Blog, located at the root)

s.add_dependency "pagy"

#rails #rails-engines

In Rails, gems are libraries that add specific functionality to a Rails application. They can be used across different projects and typically do not have their own structure or generators.
Examples include devise for authentication and nokogiri for XML parsing.

Engines, on the other hand, are miniature Rails applications that can have their own routes, controllers, models, and views. They are used to encapsulate and modularize specific features or components within a Rails app. An engine can be packaged as a gem, but it provides more extensive, self-contained functionality compared to a typical gem.

#rails

A Rails engine is a pattern used to modularize a Rails application. These engines are self-contained applications with their own models, views, controllers, and routes, allowing them to function autonomously. They can be integrated into a larger Rails application. For example, in an e-commerce application, modules like orders, products, users, and payments can each be separate engines.
#rails

Resolving gen_random_uuid() Error with PostgreSQL While Implementing CI
When configuring CI with GitHub Actions, I encountered the following error:

PG::UndefinedFunction: ERROR:  function gen_random_uuid() does not exist

This error occurred because the gen_random_uuid() function is not available in PostgreSQL versions older than 11. UUID generation functions were only available through external modules like uuid-ossp and pgcrypto in these older versions.

To resolve this issue, I upgraded to PostgreSQL 13, which includes the gen_random_uuid() function to generate version-4 UUIDs. After upgrading, the error was resolved.



#rails #postgresql #uuid #ci-cd #github-actions

Jupyter Labs

• To install Jupyter Labs in Mac using Homebrew:

brew install jupyterlab

• To run Jupyter lab:

jupyter lab

This will open JupyterLab in your default web browser.

#python #homebrew

The fields_for helper in Rails creates form bindings without rendering a

tag. This is particularly useful for rendering fields for additional model objects within a single form.

Imagine you have a Book model with an associated Author model. You can create a single form for both the Book and Author models using the fields_for helper.

<%= form_with model: @book do |book_form| %>
  <%= book_form.text_field :title %>
  <%= book_form.text_area :description %>

  <%= fields_for :author, @book.author do |author_form| %>
    <%= author_form.text_field :name %>
    <%= author_form.text_field :email %>
  <% end %>
<% end %>

#rails #fields-for #rails-view

rails db:prepare in Ruby on Rails, This command sets up and prepares the database for my application, ensuring everything's ready to go, including populating the database.
#rails #databasesetup

Handling Terraform State Errors with S3 Backend:
We use an S3 bucket to store our Terraform state. If Terraform fails to update the state, it creates an errored.tfstate file in your working directory. Reapplying will cause errors because the resources already exist.
To fix this, push the errored state back to S3:
terraform state push errored.tfstate

#devops #terraformstateS3 #errorhandling

In Ruby, exception handling is done using begin, rescue, ensure, and end blocks. Here's a brief overview of how they work in a general Ruby context:

begin
  # Code that might raise an exception
rescue SomeExceptionClass => e
  # Code that handles the exception
ensure
  # Code that will always run, regardless of whether an exception was raised
end

begin: Marks the beginning of a block of code that might raise exceptions.

rescue: Specifies what to do if a specific exception is raised. We can rescue multiple exception types by chaining rescue blocks.

ensure: An optional block that will always execute, regardless of whether an exception was raised or rescued. It's useful for cleanup code that must run no matter what.

#ruby #rails

Using Ruby's built-in URI::MailTo::EMAIL_REGEXP for email validation is generally better than using a custom regular expression due to its robustness, reliability, and maintenance by the Ruby core team.

class User < ApplicationRecord
  has_secure_password
  validates :name, presence: true

  # Using a custom regular expression for email validation
  validates :email, presence: true, format: { with: /\A[^@\s]+@[^@\s]+\z/ }, uniqueness: true
  
  # Using Ruby's built-in URI::MailTo::EMAIL_REGEXP for email validation
  validates :email, presence: true, format: { with: URI::MailTo::EMAIL_REGEXP }, uniqueness: true

end

#ruby #regex #rails