Fueling Curiosity, One Insight at a Time

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

Fixing Image Rendering in Rails with Active Storage
How to fix the error PG::UndefinedTable: ERROR: relation "active_storage_attachments" does not exist

This error occurs because Active Storage in Rails relies on specific database tables (e.g., active_storage_attachments and active_storage_blobs) to store metadata about attached files. If these tables do not exist, Rails cannot store or retrieve the necessary metadata for file attachments, resulting in the mentioned error.

By following these steps, we ensure that the necessary Active Storage tables are created, allowing Rails to store and retrieve image metadata correctly.

Run Active Storage Installation:

rails active_storage:install

Migrate the Database:

rails db:migrate

Restart the Rails Server:

rails server

Then in views we can simply use the helper and render the image

<%= image_tag url_for(recipe.image), class: "w-full h-64 object-cover" %>

#rails #activestorage

Terraform Import :
terraform import allows you to bring existing resources into Terraform's state management without recreating them.
Syntax: terraform import <RESOURCE_TYPE>.<RESOURCE_NAME> <RESOURCE_ID>
Example: terraform import aws_s3_bucket.bucket my-existing-bucket

#devops #TerraformImport

To create a dump of all the inserts with data and column names using pg_dump

pg_dump -U your_username -d your_database -h your_host -p your_port --column-inserts --data-only -f output.sql

#postgres #database

To set the autoincrement number in PostgreSQL, use the following query:

ALTER SEQUENCE "users_id_seq" RESTART WITH 1000;

#database #postgresql

Automating Terraform with GitHub Actions:
I learned how to automate Terraform linting, planning, and applying using GitHub Actions. This helps ensure code is always in good shape and deployed correctly. Here’s a step-by-step guide to set it up:
Steps:
• Create a .github/workflows/terraform.yml file in your repository. This single file defines the entire workflow for GitHub Actions.
• Set up the workflow to trigger on pull requests and pushes to the main branch. This ensures that the Terraform configuration is checked and applied automatically whenever changes are made.

name: Terraform CI/CD

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  terraform:
    name: Terraform Lint, Plan, and Apply
    runs-on: ubuntu-latest

    steps:
    - name: Checkout repository
      uses: actions/checkout@v2

    - name: Set up Terraform
      uses: hashicorp/setup-terraform@v2
      with:
        terraform_version: 1.8.3

    - name: Terraform Init
      run: terraform init

    - name: Terraform Format
      run: terraform fmt -check

    - name: Terraform Validate
      run: terraform validate

    - name: Terraform Plan
      run: terraform plan

    - name: Terraform Apply
      run: terraform apply -auto-approve
      env:
        TF_VAR_user: ${{ secrets.TF_VAR_USER }}

• Single Workflow File : By using a single .github/workflows/terraform.yml file, I streamline the CI/CD process, making it easier to manage and maintain.
• Checkout Repository : The actions/checkout@v2 step checks out the repository so that the workflow has access to the Terraform configuration files.
• Set up Terraform : The hashicorp/setup-terraform@v2 action sets up the specified version of Terraform on the runner.
• Terraform Init: The terraform init command initializes the working directory containing Terraform configuration files.
• Terraform Format : The terraform fmt -check command ensures that the Terraform configuration files are properly formatted. This helps maintain a consistent coding style.
• Terraform Validate : The terraform validate command checks the syntax and configuration of the Terraform files to ensure they are valid.
• Terraform Plan : The terraform plan command creates an execution plan, showing what actions Terraform will take to reach the desired state. This step allows you to review changes before they are applied.
• Terraform Apply : The terraform apply -auto-approve command applies the changes required to reach the desired state of the configuration.
#devops #Terraform #GitHubActions #HashiCorp