DEV Community: Anand Soni

Writing Clean Code in Ruby on Rails Applications 🧼💻

Anand Soni — Thu, 07 Nov 2024 18:10:18 +0000

Building robust and maintainable applications with Ruby on Rails is all about writing clean, organized code. Clean code is easy to read, understand, and adapt. In Rails applications, clean code principles help us navigate between models, controllers, views, and other components seamlessly. Here’s how to achieve that clean, well-structured code in a Rails app.

1. Use Descriptive Naming 🎯

Good names are crucial for readability. In Rails:

Use descriptive method and variable names. For example, calculate_total is clearer than calc.
Stick to Rails conventions: user_profile_path for URLs or user_profile for methods related to users.

Naming conventions are a roadmap for anyone reading the code.

2. Keep Methods Small and Focused 🔍

Avoid long methods that try to do too much. Break complex logic down into smaller methods that handle one responsibility. This helps:

Increase readability.
Simplify debugging.
Allow for reusability.

In Rails controllers, keep actions like create, show, and index simple. Complex logic should be offloaded to service objects or model methods.

3. Avoid Hardcoding — Use Constants & ENV Variables 🔒

Hardcoding values can lead to maintenance headaches. Instead:

Use environment variables for sensitive data, like API keys.
Define constants for values that rarely change.

For example, rather than embedding a URL directly in code, place it in ENV['API_URL']. This approach keeps things secure and adaptable.

4. Keep Your Controllers Slim 👀

Controllers are the middlemen between models and views; they shouldn’t be loaded with business logic. Use:

Service objects for complicated workflows or heavy logic.
Concerns to share code between controllers.
Before_actions sparingly for authentication and repetitive tasks.

By keeping your controllers lean, they’re easier to read and maintain.

5. Use Scopes in Models 📏

Rails models can get unwieldy if they handle too many responsibilities. Scopes help filter data cleanly. For instance, instead of repeatedly querying where(status: "active"), define a scope:

scope :active, -> { where(status: 'active') }

This makes your code more readable and removes duplication.

6. Follow DRY (Don’t Repeat Yourself) 🧑‍💻

Redundancy bloats your codebase. Rails provides ways to keep things DRY:

Use partials in views for reusable components.
Extract repeated logic into helper methods, concerns, or service objects.
Embrace Rails built-ins like before_action to eliminate repetitive code.

DRY code is not only efficient but easier to change when needed.

7. Write Tests Alongside Your Code 🧪

Testing is crucial in Rails development, and clean code benefits from it:

Write RSpec tests for models, controllers, and views.
Use factories to simplify test setup.
Embrace Test-Driven Development (TDD): it keeps your code concise and helps detect issues early.

Tests are a safety net for maintaining clean code.

8. Document Your Code Where Needed 📝

While clean code should be self-explanatory, some parts may need additional context. In those cases:

Use comments to clarify complex logic.
Avoid excessive commenting—only add comments where necessary.
For methods that are public-facing, consider YARD documentation to keep things organized.

Comments should add value, not clutter.

9. Avoid N+1 Queries with Eager Loading 🚀

Performance is part of clean code. In Rails, avoid N+1 queries by using eager loading for associations:

# Bad: This causes an N+1 query issue
User.all.each do |user|
  puts user.profile.name
end

# Good: Eager loading solves this
User.includes(:profile).each do |user|
  puts user.profile.name
end

Eager loading improves performance and keeps your database calls efficient.

10. Leverage Rails’ Built-In Helpers 🧰

Rails is packed with built-in methods and helpers that simplify common tasks. Use these to keep your code concise and clean:

Use link_to, button_to, etc., for links and buttons in views.
Use number_to_currency for formatting currency.
Use pluck instead of map for database fields to save on memory.

Rails’ helpers are designed to keep your code elegant and concise.

Conclusion 🌟

Clean code is the foundation of a maintainable, efficient Ruby on Rails application. By sticking to descriptive naming, avoiding duplication, keeping controllers slim, and using Rails’ built-in features, your code remains clear and adaptable. Investing in clean code principles not only improves your Rails app today but ensures that future developers will have an easier time maintaining and extending it. 🚀

Clean code in Rails isn’t just about writing less code; it’s about writing code that communicates its purpose and function clearly. Happy coding! 🎉

The Importance of Test-Driven Development (TDD) and What Companies Expect from Candidates

Anand Soni — Tue, 15 Oct 2024 16:47:02 +0000

Test-Driven Development (TDD) is a software practice where you write tests before the code itself. It follows a clear cycle known as Red-Green-Refactor:

Red: Write a test that fails (🔴).
Green: Write just enough code to make the test pass (🟢).
Refactor: Improve and clean the code while keeping the test passing (🔄).

Why TDD Matters 🚀

1. Improved Code Quality

By writing tests first, you ensure the code behaves exactly as expected, leading to fewer bugs and more reliable software. Tests act as a safety net as the code evolves. 🛡️

2. Faster Feedback Loops

When a test fails, you get immediate feedback, making it easier to find and fix issues early in development. This minimizes long debugging sessions later. 🕒

3. Modular Design

TDD encourages breaking down complex features into small, manageable units. This leads to better, more maintainable designs, where each function does one thing well. 🧩

4. Clear Communication and Collaboration

Tests serve as living documentation for the code. This helps other developers, testers, or stakeholders understand what the code is supposed to do. 📝

5. Reduced Maintenance Costs

A stable codebase, backed by tests, is much easier to maintain. Changes are safer, and you can extend functionality without fear of breaking existing features. 🛠️

6. Fit for Agile/DevOps

TDD works well in Agile and DevOps environments, where continuous integration (CI) and delivery are crucial. It ensures code is always in a deployable state. ⚡

What Companies Look for in TDD Candidates 👀

1. Testing Framework Proficiency

Companies want candidates who are comfortable using tools like RSpec (Ruby), JUnit (Java), PyTest (Python), or Jest (JavaScript) to write tests that cover key scenarios. ⚙️

2. Experience with TDD Cycle

Being able to demonstrate experience with the Red-Green-Refactor process is crucial. Explaining how you’ve used it in real projects makes a strong impression. 💡

3. Clean Code and Design Patterns

TDD naturally leads to cleaner, more modular code. Companies value developers who write DRY (Don't Repeat Yourself) code and follow solid design principles. 🧼

4. Collaborative Team Player

Since TDD is often part of team-based workflows, being able to communicate and collaborate effectively is essential. Companies look for developers who can align with QA teams and product managers. 🤝

5. Problem-Solving Skills

Companies want candidates who can write tests that catch edge cases and prevent future issues from slipping into production. They want problem solvers who think ahead. 🔍

6. Continuous Learning

With frameworks and tools constantly evolving, companies expect developers to stay up-to-date on best practices and continually improve their TDD and testing skills. 📚

How to Shine in Interviews 🌟

Show Real-World Examples: Share projects where you’ve applied TDD, explaining how it improved the development process.
Demonstrate Refactoring: Highlight the importance of refactoring and how you’ve used it to enhance the performance and structure of your code.
Prepare for TDD Coding Tests: Practice writing tests first and developing features based on them during technical assessments.

Conclusion 🔑

Test-Driven Development is a crucial skill in today’s development landscape. It ensures high-quality, maintainable software, and companies increasingly prioritize candidates who excel in TDD. Mastering this practice not only helps you write better code but also makes you a standout candidate in the job market.

Ruby Interview Questions - Part 2

Anand Soni — Sat, 31 Aug 2024 12:20:52 +0000

1. How would you implement a thread-safe Singleton in Ruby?

Answer:

The Singleton pattern ensures that a class has only one instance and provides a global point of access to it. In Ruby, the Singleton module can be used, but it may not be thread-safe. Here’s a custom implementation using mutex for thread safety:

   class MySingleton
     @instance = nil
     @mutex = Mutex.new

     def self.instance
       return @instance if @instance
       @mutex.synchronize do
         @instance ||= new
       end
       @instance
     end

     private_class_method :new
   end

2. Explain how Ruby handles method dispatch and how you can modify it.

Answer:

Ruby handles method dispatch through the method lookup path: first checking the object's singleton class, then its class, then included modules, and finally parent classes.
You can modify method dispatch using techniques like alias_method, prepend, method_missing, or even overriding respond_to?.

Example using prepend:

 module LoggerModule
   def greet
     puts "Logging: Calling greet"
     super
   end
 end

 class MyClass
   prepend LoggerModule

   def greet
     "Hello!"
   end
 end

 puts MyClass.new.greet # => Logs the message and then returns "Hello!"

3. How does garbage collection work in Ruby, and how can you optimize it?

Answer:

Ruby uses a mark-and-sweep garbage collector, which tracks objects in memory and cleans up those no longer in use.
The generational garbage collection (introduced in Ruby 2.1) improves performance by categorizing objects into generations and focusing on cleaning up younger objects more frequently.
Optimization techniques include avoiding the creation of unnecessary objects, using symbols instead of strings when appropriate, and utilizing tools like GC.start judiciously to control when garbage collection occurs.

Example:

 # Force garbage collection (usually not recommended in production)
 GC.start

 # Tune the garbage collector (for advanced scenarios)
 GC::Profiler.enable

4. What is the difference between `Marshal` and `YAML` for object serialization in Ruby?

Answer:

Marshal:

Binary serialization format.
Faster and more compact than YAML.
Limited portability (Ruby-specific, not human-readable).
Example:

   data = { name: "Ruby", version: 3.0 }
   marshaled_data = Marshal.dump(data)
   restored_data = Marshal.load(marshaled_data)

YAML:
- Text-based serialization format.
- Slower and more verbose, but human-readable and language-agnostic.
- More suitable for configuration files and data exchange between different programming languages.
- Example:
```
   require 'yaml'
   data = { name: "Ruby", version: 3.0 }
   yaml_data = data.to_yaml
   restored_data = YAML.load(yaml_data)
```

5. How would you implement method chaining in Ruby?

Answer:

Method chaining is a technique where multiple methods are called on an object sequentially in a single statement. Each method returns the object itself (or a modified version of it), allowing the next method to be called.

Example:

 class Calculator
   def initialize(value = 0)
     @value = value
   end

   def add(n)
     @value += n
     self
   end

   def subtract(n)
     @value -= n
     self
   end

   def result
     @value
   end
 end

 calc = Calculator.new(10)
 result = calc.add(5).subtract(3).result # => 12

6. How would you handle large numbers and precision in Ruby?

Answer:

Ruby’s Integer type automatically handles large numbers by switching from Fixnum to Bignum. However, for floating-point numbers, BigDecimal is preferred to maintain precision in financial calculations or when dealing with very large/small numbers.

Example:

 require 'bigdecimal'
 require 'bigdecimal/util'

 number = BigDecimal("1.234567890123456789")
 result = number + BigDecimal("0.000000000000000001")
 puts result.to_s('F')  # => "1.234567890123456790"

7. Explain the difference between `public`, `private`, and `protected` methods in Ruby.

Answer:

Public:
- Accessible from anywhere. Methods are public by default unless specified otherwise.
Private:
- Can only be called within the context of the current object. Cannot be called with an explicit receiver, even self.
Protected:
- Can be called by any instance of the defining class or its subclasses. Unlike private methods, protected methods can be called with an explicit receiver if the receiver is of the same class or subclass.

Example:

 class MyClass
   public

   def public_method
     "Public"
   end

   protected

   def protected_method
     "Protected"
   end

   private

   def private_method
     "Private"
   end
 end

 obj = MyClass.new
 obj.public_method      # => "Public"
 # obj.protected_method  # => NoMethodError
 # obj.private_method    # => NoMethodError

8. How would you implement a custom enumerable in Ruby?

Answer:

To create a custom enumerable, a class must include the Enumerable module and define an each method that yields items to a block.

Example:

 class MyCollection
   include Enumerable

   def initialize(items)
     @items = items
   end

   def each
     @items.each { |item| yield(item) }
   end
 end

 collection = MyCollection.new([1, 2, 3, 4])
 collection.map { |x| x * 2 }  # => [2, 4, 6, 8]
 collection.select(&:even?)     # => [2, 4]

9. What are fibers in Ruby, and how do they differ from threads?

Answer:

Fibers:
- Fibers are a form of lightweight concurrency in Ruby, allowing you to pause and resume code execution manually. They provide finer control over the execution flow but are non-preemptive (the programmer must explicitly yield control).
Threads:
- Threads are system-level concurrency primitives. Ruby uses green threads or native threads (depending on the Ruby implementation). Threads can run in parallel (in JRuby or Rubinius) or time-slice (in MRI) but require careful handling of synchronization and resource sharing.

Example of a Fiber:

 fiber = Fiber.new do
   puts "Hello"
   Fiber.yield
   puts "World"
 end

 fiber.resume # => "Hello"
 fiber.resume # => "World"

I hope that Helps!!
Check out more About me

Ruby Interview Questions - Part 1

Anand Soni — Mon, 26 Aug 2024 13:28:22 +0000

When preparing for a Ruby test, especially in an interview setting, it's important to cover key concepts and be ready to demonstrate your knowledge through code. Here are some common questions and sample answers to help you prepare:

1. What are the main features of Ruby?

Answer:

Ruby is an object-oriented programming language, which means everything is an object.
It is dynamically typed and uses garbage collection for memory management.
Ruby supports multiple programming paradigms, including procedural, object-oriented, and functional programming.
It has a simple and easy-to-read syntax, emphasising convention over configuration.
Ruby has a rich standard library and a vibrant ecosystem, particularly around web development with frameworks like Ruby on Rails.

2. Explain the difference between `proc` and `lambda` in Ruby.

Answer:

Both proc and lambda are used to create blocks of code that can be stored in variables and passed around, but they behave differently.
Lambda:
- Enforces the number of arguments passed to it. If the wrong number of arguments is provided, it raises an error.
- Returns from itself, not from the method that called it.
Proc:
- Does not strictly enforce the number of arguments. Missing arguments will be set to nil.
- Returns from the method that is called it, which can cause the enclosing method to return early if not handled properly.

3. How does Ruby's garbage collection work?

Answer:

Ruby uses a mark-and-sweep garbage collection algorithm. Objects that are no longer referenced or accessible are "marked" for deletion.
The garbage collector then "sweeps" through and frees up memory occupied by these unreferenced objects.
Ruby 2.1 introduced a generational garbage collector, which divides objects into different generations based on their lifespan, optimizing the process by focusing more on newly created objects that are more likely to become garbage.

4. What are symbols in Ruby, and when should you use them?

Answer:

Symbols in Ruby are immutable, reusable constants represented internally by an integer value. They are often used as identifiers, keys in hashes, or for representing method names.
Unlike strings, symbols are immutable, which makes them memory-efficient for use cases where the same value is used repeatedly, such as in hash keys or constant values.

5. What is a module in Ruby, and how is it different from a class?

Answer:

A module in Ruby is a collection of methods and constants. It is similar to a class but cannot be instantiated or inherited.
Modules are often used for namespacing and as a mixin to add functionality to classes via include or extend.
The primary difference between a module and a class is that a class can be instantiated to create objects, whereas a module cannot. Modules are also used to achieve multiple inheritance by mixing in functionalities to classes.

6. How do you handle exceptions in Ruby?

Answer:

Ruby uses the begin...rescue...ensure block to handle exceptions.
begin starts the block of code where exceptions might occur.
rescue defines the code to be run if an exception occurs.
ensure is an optional block that runs regardless of whether an exception was raised, often used for cleanup activities.

Example:

 begin
   # Code that might raise an exception
 rescue StandardError => e
   puts "An error occurred: #{e.message}"
 ensure
   puts "This will run whether an exception occurred or not."
 end

7. Explain the concept of mixins in Ruby.

Answer:

Mixins are a way to share code between classes using modules. By including a module in a class, you can "mix in" the module's methods and constants into that class.
Mixins allow Ruby to support multiple inheritance since a class can include many modules.

Example:

 module Walkable
   def walk
     "I'm walking!"
   end
 end

 class Person
   include Walkable
 end

 p = Person.new
 p.walk # => "I'm walking!"

8. What is `self` in Ruby?

Answer:

self refers to the current object instance in Ruby. It is a special variable that points to the object that is currently being operated on.
Inside an instance method, self refers to the instance of the class.
Inside a class method, self refers to the class itself.
Understanding self is crucial for defining instance methods, class methods, and working with scope.

9. How do you define and use a singleton method in Ruby?

Answer:

A singleton method is a method that is defined for a single instance of an object, rather than for all instances of the class.

Example:

 str = "Hello"
 def str.shout
   self.upcase + "!!!"
 end

 str.shout # => "HELLO!!!"

10. How would you optimize the performance of a Ruby application?

Answer:

Use memoization to avoid recomputation.
Profile the application to identify bottlenecks using tools like ruby-prof or StackProf.
Optimize database queries by using eager loading (e.g., includes) to reduce the number of queries.
Use caching (e.g., fragment caching, page caching) to reduce the load on the server.
Optimize code algorithms and logic for efficiency, avoid unnecessary computations, and use efficient data structures.
Offload expensive tasks to background jobs (e.g., using Sidekiq).

I hope that Helps!!
Checkout more About me

Understanding the Decimal Datatype in MySQL

Anand Soni — Wed, 21 Aug 2024 06:41:54 +0000

The Decimal datatype in MySQL is essential for finance-related projects, where precision in numeric values is crucial. Recently, I encountered an issue while working with this datatype in one of my Ruby on Rails projects. Let me share my experience and what I learned.

The Challenge: Out-of-Range Value Error

During my project, I defined a Decimal field in a migration file and faced the following error:

Out of range value for column 'db_field' at row 1

This error happened because I tried to insert a value that exceeded the defined range. Here’s the snippet from my migration file:

t.decimal :rate, precision: 3, scale: 3, default: 0.0

This definition corresponds to, meaning the rate column can store values between -0.999 and 0.999. Notice the scale of 3, indicating there are always 3 digits after the decimal point.

Breaking Down Precision and Scale

In MySQL, the Decimal datatype is defined as Decimal(P,S), where:

P (Precision): Total number of digits.
S (Scale): Number of digits after the decimal point.

How to Determine Precision and Scale

To decide the appropriate precision and scale, use this simple formula:

Precision - Scale = Maximum digits before the decimal point

Example:
If you need to store values like 12.345:

You want 2 digits before the decimal point and 3 digits after.
Total digits (Precision) is 5.
Therefore, the definition will be Decimal(5,3).

Real-World Application

Here’s an example from my project:

t.decimal :rate, precision: 5, scale: 2, default: 0.0

In this case, I needed to store values up to 999.99. Hence, Decimal(5,2) allowed me to have 3 digits before the decimal point and 2 digits after.

Conclusion

Understand
ing the Decimal datatype in MySQL is vital for accurately handling numeric data in your applications. By setting the correct precision and scale, you can avoid common errors and ensure data integrity. I hope this explanation helps you in your projects!

Solving Cypress Preflight Request Errors in Rails Test Environment

Anand Soni — Wed, 21 Aug 2024 06:22:39 +0000

Introduction

While developing and testing web applications, encountering errors is a common part of the process. Recently, I stumbled upon an issue while writing test scripts in Cypress and running a Rails server in the Test environment. The error messages were perplexing:

"No content available for preflight request in Chrome."
"ERR_EMPTY_RESPONSE."
"Failed to load response data. No data found with the resource with a given identifier."

Despite checking my CORS configuration, everything seemed to be in order. However, the error persisted, hindering communication between the browser and the server. Oddly enough, this issue only arose when the server was running in the Test environment, while everything worked smoothly in the Development environment.

The Problem: A Strange Behavior in the Test Environment

The error was quite frustrating, as it only occurred in the Test environment. This discrepancy led me to investigate the root cause further. After scouring various forums and documentation, I discovered that the issue was tied to how the browser was communicating with the server - specifically, how the server was being accessed.

The Culprit: Localhost vs. 127.0.0.1

The problem boiled down to the usage of the term "localhost." In the Development environment, the Rails server accessed via localhost worked perfectly fine with Cypress. However, the Test environment localhost was causing these preflight errors.

After some trial and error, I found a simple yet effective solution: replacing localhost it with 127.0.0.1 in the API URL. This change resolved the issue immediately, allowing Cypress to communicate with the Rails server without any errors.

Why Did This Work?

The difference between localhost and 127.0.0.1 is subtle but significant. Although both point to the local machine, localhost is resolved via the operating system's host file, which 127.0.0.1 is a direct IP address reference. In some cases, especially in testing environments, the resolution of localhost might introduce issues that aren't present when using the raw IP address.

Conclusion

If you encounter similar preflight request errors while using Cypress with a Rails server in the Test environment, consider swapping localhost with 127.0.0.1 in your API URLs. This small change can save you hours of debugging and ensure that your testing process runs smoothly.

By sharing this experience, I hope to help others avoid the same frustration and get back to what we love doing - building great software.

LinkedIn connect: https://www.linkedin.com/in/anandsoni11/

How to Use Mutex in Ruby: A Comprehensive Guide

Anand Soni — Wed, 21 Aug 2024 05:07:59 +0000

Introduction

Concurrency is a powerful tool in programming, enabling multiple threads to execute code simultaneously. However, with this power comes the responsibility to manage shared resources safely. In Ruby, Mutex (short for mutual exclusion) is a key component in ensuring that only one thread can access a resource at a time, preventing potential data corruption or unpredictable behaviour.
In this blog, we'll explore how to use Mutex in Ruby, supported by sample code and a real-life scenario to illustrate its practical application.

What is a Mutex?

A Mutex is an object used to manage the synchronization of threads. When one thread locks a Mutex, any other thread that attempts to lock the same Mutex will be put on hold until the first thread releases it. This mechanism ensures that critical sections of code, where shared resources are accessed, are executed by only one thread at a time.

Why Use a Mutex?

Imagine a scenario where multiple threads are modifying the same variable or writing to the same file. Without proper synchronization, the result could be unpredictable or incorrect. A Mutex helps to avoid such issues by ensuring that only one thread can access the shared resource at any given time.

How to Use Mutex in Ruby

require 'thread'

# Initialize a Mutex
mutex = Mutex.new

# Shared resource
counter = 0

# Create threads
threads = 10.times.map do
  Thread.new do
    1000.times do
      # Lock the mutex before modifying the shared resource
      mutex.synchronize do
        counter += 1
      end
    end
  end
end

# Wait for all threads to finish
threads.each(&:join)

puts "Final counter value: #{counter}"

In this example:

We initialize a Mutex object.
We create a shared resource (counter) that will be accessed by multiple threads.
We create 10 threads, each incrementing the counter 1000 times.
Inside the mutex.synchronize block, we ensure that only one thread can modify the counter at a time.
Finally, we print the final value of counter, which should be 10000 if the Mutex has properly synchronized the access.

Real-Life Scenario: Managing Bank Account Transactions

To understand the real-life application of Mutex, let's consider a scenario where multiple threads represent transactions on a bank account. Each transaction may involve depositing or withdrawing money, and we must ensure that the account balance remains accurate.

require 'thread'

# Initialize a Mutex
account_mutex = Mutex.new

# Bank account class
class BankAccount
  attr_reader :balance

  def initialize(balance = 0)
    @balance = balance
  end

  def deposit(amount)
    @balance += amount
  end

  def withdraw(amount)
    @balance -= amount
  end
end

# Shared bank account
account = BankAccount.new(1000)

# Transactions
threads = []

# Deposit thread
threads << Thread.new do
  100.times do
    account_mutex.synchronize do
      account.deposit(50)
    end
  end
end

# Withdraw thread
threads << Thread.new do
  100.times do
    account_mutex.synchronize do
      account.withdraw(30)
    end
  end
end

# Wait for all threads to finish
threads.each(&:join)

puts "Final account balance: #{account.balance}"

In this scenario:

We define a BankAccount class with deposit and withdraw methods.
We create a shared BankAccount instance with an initial balance of 1000.
We create two threads: one for depositing money and one for withdrawing money.
We use a Mutex to synchronize access to the deposit and withdraw methods, ensuring that only one transaction can modify the account balance at a time.
Finally, we print the final account balance, which should accurately reflect all transactions.

Conclusion

Using Mutex in Ruby is essential when dealing with concurrency and shared resources. It provides a simple yet effective way to ensure that only one thread can access a critical section of code at a time, preventing potential issues like data corruption or race conditions.

SOLID principles using some fun analogies with Vehicle Example

Anand Soni — Wed, 21 Aug 2024 04:52:17 +0000

SOLID is an acronym for a group of five good principles (rules) in computer programming. SOLID allows programmers to write code that is easier to understand and change later on. SOLID is often used with systems that use an object-oriented design.
Let's explain the SOLID principles using the vehicle example. Imagine we're designing a system to manage different types of vehicles, like cars and electric cars, for a transportation service.

S - Single Responsibility Principle (SRP)

Vehicle Example: Imagine you have a car. It's responsible for driving, but it shouldn't be responsible for handling its own maintenance (like oil changes or tyre rotations). Instead, a separate mechanic is responsible for that.
Explanation: In our code, the Vehicle class should only handle things related to the vehicle itself, like storing its make and model. If we need to manage maintenance, we create a separate Maintenance class for that. This way, each class has one job or responsibility, making the code easier to manage.

class Vehicle
  def initialize(make, model)
    @make = make
    @model = model
  end
end

class Maintenance
  def initialize(vehicle)
    @vehicle = vehicle
  end

  def perform_maintenance
    puts "Performing maintenance on #{@vehicle.make} #{@vehicle.model}"
  end
end

O - Open/Closed Principle (OCP)

Vehicle Example: Suppose you have a basic car, and now you want to add an electric car to your system. You shouldn't have to modify the existing car class to add features for electric cars. Instead, you can extend the existing functionality by creating a new class for electric cars.
Explanation: The Vehicle class is open for extension (you can create new types of vehicles like ElectricVehicle), but it's closed for modification (you don't need to change the Vehicle class itself to add new types).

class Vehicle
  def initialize(make, model)
    @make = make
    @model = model
  end

  def description
    "#{@make} #{@model}"
  end
end

class ElectricVehicle < Vehicle
  def initialize(make, model, battery_range)
    super(make, model)
    @battery_range = battery_range
  end

  def description
    "#{super} with #{@battery_range} miles battery range"
  end
end

L - Liskov Substitution Principle (LSP)

Vehicle Example: Imagine you have a fleet of vehicles, and you can replace any regular car with an electric car without any issues. Both should be able to perform their basic function - driving - without breaking the system.
Explanation: Any subclass (like ElectricVehicle) should be able to replace its parent class (Vehicle) without altering the behaviour of the program. This ensures that our code can handle different types of vehicles in the same way.

class Vehicle
  def initialize(make, model)
    @make = make
    @model = model
  end

  def drive
    puts "Driving the #{@make} #{@model}"
  end
end

class ElectricVehicle < Vehicle
  def drive
    puts "Driving the electric #{@make} #{@model} quietly"
  end
end

def test_drive(vehicle)
  vehicle.drive
end

car = Vehicle.new("Toyota", "Corolla")
ev = ElectricVehicle.new("Tesla", "Model 3")

test_drive(car)  # Driving the Toyota Corolla
test_drive(ev)   # Driving the electric Tesla Model 3 quietly

I - Interface Segregation Principle (ISP)

Vehicle Example: Imagine you have different types of vehicles: some can be charged (like electric cars), and some can only be driven (like gas cars). You don't want a gas car to have to deal with charging-related methods.
Explanation: Classes should only implement the interfaces (or behaviours) they need. For example, an ElectricVehicle might implement both Drivable and Chargeable interfaces, while a regular Vehicle only implements Drivable.

module Drivable
  def drive
    raise NotImplementedError, "This #{self.class} cannot drive"
  end
end

module Chargeable
  def charge
    raise NotImplementedError, "This #{self.class} cannot be charged"
  end
end

class Vehicle
  include Drivable

  def initialize(make, model)
    @make = make
    @model = model
  end

  def drive
    puts "Driving the #{@make} #{@model}"
  end
end

class ElectricVehicle < Vehicle
  include Chargeable

  def initialize(make, model, battery_range)
    super(make, model)
    @battery_range = battery_range
  end

  def drive
    puts "Driving the electric #{@make} #{@model} quietly"
  end

  def charge
    puts "Charging the #{@make} #{@model}"
  end
end

D - Dependency Inversion Principle (DIP)

Vehicle Example: Imagine a car can have different types of engines: a gas engine or an electric engine. Instead of directly depending on a specific engine type, the car should depend on a more general Engine interface so it can use any type of engine.
Explanation: High-level modules (like the Vehicle) should not depend on low-level modules (like GasEngine or ElectricEngine). Both should depend on abstractions (like an Engine interface). This makes the system more flexible and easier to change.

class Engine
  def start
    raise NotImplementedError, "This #{self.class} cannot start"
  end
end

class GasEngine < Engine
  def start
    puts "Starting gas engine"
  end
end

class ElectricEngine < Engine
  def start
    puts "Starting electric engine"
  end
end

class Vehicle
  def initialize(engine)
    @engine = engine
  end

  def start
    @engine.start
  end
end

gas_engine = GasEngine.new
electric_engine = ElectricEngine.new

gas_car = Vehicle.new(gas_engine)
electric_car = Vehicle.new(electric_engine)

gas_car.start        # Starting gas engine
electric_car.start   # Starting electric engine

By following the SOLID principles in this vehicle example, we can build a system that is easy to maintain, extend, and adapt to new requirements.

LinkedIn: https://www.linkedin.com/in/anandsoni11/

DEV Community: Anand Soni

Writing Clean Code in Ruby on Rails Applications 🧼💻

1. Use Descriptive Naming 🎯

2. Keep Methods Small and Focused 🔍

3. Avoid Hardcoding — Use Constants & ENV Variables 🔒

4. Keep Your Controllers Slim 👀

5. Use Scopes in Models 📏

6. Follow DRY (Don’t Repeat Yourself) 🧑‍💻

7. Write Tests Alongside Your Code 🧪

8. Document Your Code Where Needed 📝

9. Avoid N+1 Queries with Eager Loading 🚀

10. Leverage Rails’ Built-In Helpers 🧰

Conclusion 🌟

The Importance of Test-Driven Development (TDD) and What Companies Expect from Candidates

Why TDD Matters 🚀

1. Improved Code Quality

2. Faster Feedback Loops

3. Modular Design

4. Clear Communication and Collaboration

5. Reduced Maintenance Costs

6. Fit for Agile/DevOps

What Companies Look for in TDD Candidates 👀

1. Testing Framework Proficiency

2. Experience with TDD Cycle

3. Clean Code and Design Patterns

4. Collaborative Team Player

5. Problem-Solving Skills

6. Continuous Learning

How to Shine in Interviews 🌟

Conclusion 🔑

Ruby Interview Questions - Part 2

1. How would you implement a thread-safe Singleton in Ruby?

2. Explain how Ruby handles method dispatch and how you can modify it.

3. How does garbage collection work in Ruby, and how can you optimize it?

4. What is the difference between Marshal and YAML for object serialization in Ruby?

5. How would you implement method chaining in Ruby?

6. How would you handle large numbers and precision in Ruby?

7. Explain the difference between public, private, and protected methods in Ruby.

8. How would you implement a custom enumerable in Ruby?

9. What are fibers in Ruby, and how do they differ from threads?

Ruby Interview Questions - Part 1

1. What are the main features of Ruby?

2. Explain the difference between proc and lambda in Ruby.

3. How does Ruby's garbage collection work?

4. What are symbols in Ruby, and when should you use them?

5. What is a module in Ruby, and how is it different from a class?

6. How do you handle exceptions in Ruby?

7. Explain the concept of mixins in Ruby.

8. What is self in Ruby?

9. How do you define and use a singleton method in Ruby?

10. How would you optimize the performance of a Ruby application?

Understanding the Decimal Datatype in MySQL

The Challenge: Out-of-Range Value Error

Breaking Down Precision and Scale

How to Determine Precision and Scale

Real-World Application

Further Reading

Conclusion

Solving Cypress Preflight Request Errors in Rails Test Environment

Introduction

The Problem: A Strange Behavior in the Test Environment

The Culprit: Localhost vs. 127.0.0.1

Why Did This Work?

Conclusion

How to Use Mutex in Ruby: A Comprehensive Guide

Introduction

What is a Mutex?

Why Use a Mutex?

How to Use Mutex in Ruby

In this example:

Real-Life Scenario: Managing Bank Account Transactions

In this scenario:

Conclusion

SOLID principles using some fun analogies with Vehicle Example

S - Single Responsibility Principle (SRP)

O - Open/Closed Principle (OCP)

L - Liskov Substitution Principle (LSP)

I - Interface Segregation Principle (ISP)

D - Dependency Inversion Principle (DIP)

4. What is the difference between `Marshal` and `YAML` for object serialization in Ruby?

7. Explain the difference between `public`, `private`, and `protected` methods in Ruby.

2. Explain the difference between `proc` and `lambda` in Ruby.

8. What is `self` in Ruby?