DEV Community: David Martinez

Mail Pilot ✈️ – Your Inbox, Now a Remote Control

David Martinez — Sat, 07 Jun 2025 19:36:18 +0000

This is a submission for the Postmark Challenge: Inbox Innovators.

What I Built

Mail Pilot is a lightweight, email-driven control system for home automation. It turns any inbox into a secure command center capable of operating physical devices—from light switches to door locks—via simple email instructions.

More than just a clever use of Postmark's inbound parsing, Mail Pilot explores a future where remote control can work reliably over the most ubiquitous and low-barrier protocol of all: email.

The MVP connects an ESP8266 device to a Rails API that receives and processes email commands. But the concept scales: with authentication, scheduling, and multi-device orchestration, Mail Pilot could offer a resilient, accessible layer of automation on top of existing smart home systems.

Demo

For judging purposes, the system is running locally with ngrok and a Wi-Fi-connected ESP8266. Commands like ROOM_1_ON or DOOR_OPEN can be sent via email, and the device will fetch and execute them.

🖼️ System Diagram:

📽️ Demo video: Watch on YouTube Shorts

⛓️ Test it (on request): I’ll gladly expose the instance via ngrok for live review. DM me if you'd like to try it.

Code Repository

🔗 Backend (Rails API): github.com/davidmrtz-dev/mail_pilot

🔗 Firmware (ESP8266): github.com/davidmrtz-dev/mail_pilot_firmware

How I Built It

Backend: Ruby on Rails 7 with a RESTful interface and Postmark's inbound webhook to receive emails as commands.
Device: NodeMCU ESP8266 polling the API and executing commands using relays, servos, and OLED display feedback.
Infra: Dockerized PostgreSQL + Rails stack for portability. Ngrok is used to tunnel the local API during testing.

Postmark’s reliability and ease of use made it ideal for converting emails into executable actions in real-time.

Thanks for reading, and thank you Postmark for the opportunity to build something unexpected, fun, and potentially useful.

🔒 Exploring the Singleton Design Pattern in Ruby

David Martinez — Wed, 06 Nov 2024 16:35:15 +0000

Welcome! Today, let’s dive into the Singleton design pattern, a fundamental yet powerful pattern in object-oriented programming.
We’ll explore its structure, benefits, and practical use cases in Ruby.

Introducing the Singleton Pattern 🧩

The Singleton is a creational design pattern that ensures a class has only one instance and provides a global point of access to it.

This pattern is ideal for managing resources like database connections or configuration settings where only one instance is necessary.

When to Use the Flyweight Pattern?

🔸 Use Singleton when you need to control access to shared resources or ensure that only one instance of a class is used throughout the application.

🔸 This pattern is helpful for scenarios requiring centralized management, such as logging, caching, or connection pooling.

Problem Scenario

Imagine an application where multiple parts of the code access configuration settings.
Without a Singleton, you risk multiple, inconsistent instances of these settings, leading to bugs.

Solution

The Singleton pattern ensures only one instance of the configuration class exists.
Any part of the application can access this instance without worrying about duplicates.

In this example, the Singleton pattern is applied to manage application configuration.

🔹 The Singleton class controls access to the single instance.

🔹 The


 method provides a global point of access, ensuring only one instance exists.

## How does it Work?
1️⃣ Define a

 ```self.instance```

 method to return the single instance of the class.

2️⃣ Use

 ```@instance ||= new```

 inside the method to create the instance if it doesn’t already exist.

3️⃣ Privateize

 ```new```

 to prevent external code from creating additional instances.

💡 Note: The Singleton pattern restricts object creation, ensuring only one instance exists.

## Why Use the Singleton Pattern?
🔒 Simplifies access to shared resources.

🔒 Reduces the risk of inconsistent states across the application.

🔒 Provides centralized control and management of instances.

🔒 Optimizes memory usage by limiting unnecessary instance creation.

## Show me the code


```python
# Singleton class for AppConfig
class AppConfig
  @instance = nil

  # Ensures only one instance of AppConfig exists
  def self.instance
    @instance ||= new
  end

  # Stores application configurations
  attr_accessor :settings

  # Sample initialization of settings
  def initialize
    @settings = { app_name: "MyApp", version: "1.0.0" }
  end

  # Prevents external instantiation
  private_class_method :new
end

# Client code
def main
  config1 = AppConfig.instance
  config2 = AppConfig.instance

  puts config1.settings  # => {:app_name=>"MyApp", :version=>"1.0.0"}
  config2.settings[:version] = "2.0.0"

  puts config1.settings  # => {:app_name=>"MyApp", :version=>"2.0.0"}
  puts config1.equal?(config2)  # => true
end

main

# Output
# {:app_name=>"MyApp", :version=>"1.0.0"}
# {:app_name=>"MyApp", :version=>"2.0.0"}
# true

Conclusion 🔖

The Singleton pattern is a powerful tool to control resource usage by ensuring a class has only one instance.

🔺 It’s ideal for scenarios where centralized control is needed, like managing configurations.

🔺 The Singleton pattern simplifies code, minimizes memory footprint, and ensures consistency.

🔺 By implementing Singleton, you create a reliable way to manage shared resources across the application.

Join the Quest!

💻 You can find this and other design patterns here 📚

Coding Standards in the Software Industry: A Focus on Ruby

David Martinez — Sat, 15 Jun 2024 23:46:16 +0000

Introduction to Coding Standards 📚

In the dynamic and ever-evolving realm of software development, coding standards stand as a cornerstone, guiding developers towards crafting maintainable, readable, and robust codebases.
These established guidelines dictate the structure, formatting, and overall style of code, ensuring consistency and facilitating seamless collaboration among developers.
Embracing coding standards not only elevates the quality of the code but also streamlines the development process, fostering a culture of shared understanding and minimizing the potential for errors.

This post delves into the profound significance of coding standards in the software industry, with a particular focus on their application in Ruby development.
By examining the rationale behind these standards, exploring prevalent conventions, and showcasing practical examples, we aim to illuminate their crucial role in fostering high-quality software development.

The Compelling Case for Coding Standards 🔎

Coding standards transcend mere aesthetics, offering a multitude of benefits that permeate the very fabric of software development.
Their implementation fosters a cohesive and consistent codebase, enhancing its readability and maintainability.
As developers navigate through the code, they are presented with a familiar and structured environment, reducing the cognitive burden associated with deciphering unfamiliar coding styles.
This, in turn, expedites the debugging and troubleshooting process, enabling developers to swiftly identify and rectify issues.

Furthermore, coding standards promote collaboration and teamwork within development teams.
By establishing a common language and set of guidelines, developers can seamlessly integrate their contributions, ensuring that the codebase remains cohesive and well-organized.
This collaborative approach fosters knowledge sharing and reduces the risk of introducing inconsistencies or conflicts.

The Role of Coding Standards in Ruby Development 💎

The Ruby programming language, renowned for its elegance and expressiveness, also adheres to a set of well-defined coding standards.
These guidelines, meticulously crafted by the Ruby community, aim to promote consistency, readability, and maintainability across Ruby codebases.

One of the fundamental tenets of Ruby coding standards is the emphasis on indentation.
Ruby utilizes spaces for indentation, typically two spaces per level, to visually delineate code blocks and enhance its readability.
This consistent indentation scheme fosters a clear understanding of the code's structure and flow, enabling developers to quickly grasp the relationships between different code segments.

Beyond Aesthetics: The Far-Reaching Benefits of Coding Standards ✨

🔮 More consistent: Uniform coding practices ensure a consistent codebase, which is vital when multiple developers work on the same project.

🔮 More Readable: Consistent indentation, meaningful naming conventions, and well-structured code blocks make it easier for developers to understand and navigate the codebase,
saving time and effort during code reviews and maintenance tasks.

🔮 More Maintainable: Well-formatted code is easier to modify and extend, reducing the likelihood of introducing errors and facilitating future enhancements.
This maintainability not only saves time but also ensures the codebase remains adaptable to evolving requirements.

🔮 Less Prone to Errors: Consistent coding conventions minimize the potential for syntax errors and logical mistakes, leading to cleaner, more reliable code.
This reduction in errors translates to fewer bugs, improved application stability, and a more positive user experience.

🔮 Enhanced Collaboration: Shared coding standards foster a common language among developers, enabling seamless collaboration and knowledge sharing.
This collaborative approach streamlines the development process, reduces conflicts, and promotes a sense of ownership among team members.

🔮 More efficient: Adhering to standards can streamline the development process, as developers spend less time understanding code written by others.

Practical Applications of Coding Standards in Ruby ⚙️

Ruby is renowned for its elegant syntax and readability. Adhering to coding standards enhances these attributes. Below are some widely accepted Ruby coding standards:

Naming Conventions - Classes and Modules

Class and module names should be written in CamelCase, starting with an uppercase letter.

class MyClass
end

module MyModule
end

Naming Conventions - Methods and Variables

Method and variable names should be written in snake_case, all in lowercase with words separated by underscores.

def my_method
end

my_variable = 10

Indentation

Use two spaces per indentation level. Avoid using tabs as they can be rendered differently in various editors.

def my_method
  if some_condition
    do_something
  else
    do_something_else
  end
end

Line Length

Keep lines to a maximum of 80 characters. This promotes readability and helps prevent horizontal scrolling.

# Good
def calculate_area(length, width)
  length * width
end

# Bad
def my_long_method_with_a_descriptive_name(arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8)
  # Method body here
end

Method Definitions

Avoid defining methods with more than one or two parameters. If a method requires multiple parameters, consider using a hash to pass them.

# Good
def create_user(name:, age:, email:)
  # method implementation
end

# Bad
def create_user(name, age, email)
  # method implementation
end

String Literals

Use single quotes for string literals unless you need string interpolation or special symbols.

# Good
name = 'John Doe'

# Bad
name = "John Doe"

# Interpolation
greeting = "Hello, #{name}!"

Blocks and Lambdas

Prefer the do...end syntax for multiline blocks and {} for single-line blocks.

# Multiline block
[1, 2, 3].each do |number|
  puts number
end

# Single-line block
[1, 2, 3].each { |number| puts number }

Use lambda for anonymous functions and -> for concise syntax.

# Good
my_lambda = ->(x) { x * 2 }

# Bad
my_lambda = lambda { |x| x * 2 }

Comments and Documentation

Use comments judiciously to explain the why behind the code, not the what. Ensure that comments are up-to-date and reflect the current state of the code.

# Good
# This method calculates the area of a rectangle
def calculate_area(length, width)
  length * width
end

# Bad
# Calculate the area
def calculate_area(length, width)
  length * width
end

Use RDoc or other documentation tools to generate detailed documentation for your classes and methods.

# Good
# Calculates the area of a rectangle.
#
# @param length [Integer] The length of the rectangle.
# @param width [Integer] The width of the rectangle.
# @return [Integer] The area of the rectangle.
def calculate_area(length, width)
  length * width
end

Error Handling

Handle errors gracefully using exceptions. Ensure that errors are logged appropriately and provide meaningful messages to the users.

# Good
def divide(x, y)
  raise 'Division by zero error' if y == 0
  x / y
rescue => e
  puts e.message
end

# Bad
def divide(x, y)
  x / y
end

Conclusion 🔖

Coding standards serve as an invaluable tool in the software development arsenal, particularly in the realm of Ruby programming.
By adhering to established guidelines, developers can craft code that is not only functional but also maintainable, readable, and collaborative.
The benefits of coding standards extend far beyond aesthetics, encompassing enhanced code quality, reduced development time, and improved team productivity.
As the software industry continues to evolve, embracing coding standards will remain paramount in fostering the creation of robust, scalable, and enduring software solutions.

Key Takeaways 💡

🔺 Consistent coding standards enhance code quality, readability, and maintainability.

🔺 Ruby coding standards emphasize indentation, naming conventions, and readability.

🔺 Adhering to coding standards fosters collaboration, reduces errors, and streamlines development.

🔺 Practical applications of coding standards in Ruby include naming conventions, indentation, line length, and error handling.

By embracing coding standards as a guiding principle in software development, developers can navigate the complexities of code with clarity, confidence, and cohesion,
ultimately paving the way for the creation of exceptional software solutions.

🚀 Keep coding, keep creating, and keep innovating! 🚀

References

🎨 Exploring the Abstract Factory Design Pattern in Ruby

David Martinez — Thu, 09 May 2024 04:31:49 +0000

Welcome! Today, let's embark on a journey into the Abstract Factory design pattern.
We'll dive deep into its workings, explore real-world scenarios, and unveil its magic!

Unveiling the Abstract Factory Pattern ✨

The Abstract Factory is a creational design pattern that furnishes an interface for creating families of related or dependent objects without specifying their concrete classes.

This pattern revolves around a super-factory, known as an Abstract Factory, which generates other factories. These factories, in turn, produce objects related to specific families.

When to Use the Abstract Factory Pattern?

🔸 Use this pattern when your code needs to interact with various families of related products, yet you prefer not to bind it to the concrete classes of those products.

🔸 It's beneficial when providing a library of classes for users to extend.

Problem Scenario

Consider developing a native application intended for multiple operating systems like Windows, Mac, and Linux.
This application incorporates various UI elements such as buttons, inputs, text areas, and dialogs.

Rendering these UI elements in accordance with each operating system's style poses a challenge.
Additionally, avoiding code alterations whenever a new OS is supported is crucial.

Solution

The Abstract Factory pattern suggests creating separate factory interfaces for each UI element type, like buttons, inputs, text areas, etc.
Each factory interface defines methods to create these UI elements, returning abstract products such as Button, Input, Textarea, etc.

Further, interfaces are declared for each distinct product of the UI elements, such as Button, Input, Textarea, etc., with common methods.

Concrete factories implement these interfaces and produce concrete products like WindowsButton, WindowsInput, WindowsTextarea, MacButton, MacInput, MacTextarea, etc.

In this example, the Abstract Factory pattern is utilized to create UI elements for Windows and Mac operating systems.

🔹 The Abstract Factory interface declares factory methods to create UI elements like createButton, createInput, createTextarea, etc.

🔹 Concrete factories implement these factory methods to create OS-specific UI elements.

🔹 Concrete products implement UI element interfaces like Button, Input, Textarea, etc.

🔹 Client code utilizes the Abstract Factory interface to create UI elements without knowledge of their concrete classes.

🔹 All UI elements are treated uniformly by client code, regardless of their concrete class.

🔹 Client code is aware of the render method in all UI elements but doesn't concern itself with how it's implemented in each concrete class.

How does it Work?

1️⃣ Concrete products implement UI element interfaces like Button, Input, Textarea, etc.

2️⃣ Concrete factories implement the Abstract Factory interface, producing concrete products tailored to specific OSes.

3️⃣ The Abstract Factory interface declares factory methods for creating UI elements like createButton, createInput, createTextarea, etc.

4️⃣ Abstract factories spawn concrete factories that adhere to the Abstract Factory interface.

💡 Note: The abstract factory can optimize by reusing existing objects rather than creating new ones every time.

Why Embrace the Abstract Factory?

🔮 Ensures compatibility among products obtained from a factory.

🔮 Avoids tight coupling between concrete products and client code.

🔮 Facilitates seamless replacement of the entire product family by switching concrete factories.

🔮 Enables introducing new product variants without disrupting existing client code.

🔮 Aligns with the Open/Closed Principle by extending the codebase with new classes instead of modifying existing ones.

🔮 Adheres to the Single Responsibility Principle by consolidating product creation in one place, enhancing code maintainability.

Show me the code

# GUIFactory "Interface"
# (since interfaces do not exist in Ruby, we will use a module to define the interface)
module GUIFactory
  def create_button
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end

  def create_checkbox
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end
end

class WinFactory
  include GUIFactory

  def create_button
    WindowsButton.new
  end

  def create_checkbox
    WindowsCheckbox.new
  end
end

class MacFactory
  include GUIFactory

  def create_button
    MacButton.new
  end

  def create_checkbox
    MacCheckbox.new
  end
end


# Checkbox
module Checkbox
  def render
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end

  def on_change
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end
end

class MacCheckbox
  include Checkbox

  def render
    puts 'MacCheckbox render'
  end

  def on_change
    puts 'MacCheckbox on_change'
  end
end

class WindowsCheckbox
  include Checkbox

  def render
    puts 'WindowsCheckbox render'
  end

  def on_change
    puts 'WindowsCheckbox on_change'
  end
end

# Button
module Button
  def render
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end

  def on_click
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end
end

class MacButton
  include Button

  def render
    puts 'MacButton render'
  end

  def on_click
    puts 'MacButton on_click'
  end
end

class WindowsButton
  include Button

  def render
    puts 'WindowsButton render'
  end

  def on_click
    puts 'WindowsButton on_click'
  end
end

# Application
class Application
  def initialize(factory)
    @factory = factory
  end

  def create_ui
    button = @factory.create_button
    checkbox = @factory.create_checkbox
    button.render
    checkbox.render
  end
end

# Client
def main
  op_system = 'mac'

  if op_system == 'win'
    factory = WinFactory.new
  else
    factory = MacFactory.new
  end

  app = Application.new(factory)
  app.create_ui
end

# Output
MacButton render
MacCheckbox render

Conclusion

The Abstract Factory pattern furnishes an interface for creating families of related or dependent objects without specifying their concrete classes.

🔺 This pattern is advantageous when your code interacts with various families of related products without relying on their concrete classes.

🔺 It's beneficial when providing a library of classes for users to extend.

Join the Quest!

💻 You can find this and other design patterns here 📚

Factory Method Pattern in Ruby

David Martinez — Wed, 17 Apr 2024 18:28:50 +0000

This is the first post in the series on design patterns in Ruby.
This series will cover different design patterns, including creational, structural, behavioral, and others.

In this post, we will address the Factory Method design pattern. We will see how it works, use cases, advantages and disadvantages,
as well as tips on cases where it is useful to implement this pattern.

What?

The Factory Method is a creational design pattern that provides an interface for creating objects in a superclass,
but allows subclasses to alter the type of objects that will be created.

This pattern defines a method that should be used for creating objects instead of a direct call to the constructor.
Subclasses can override this method to change the classes of objects that will be created.

When?

🔸 This pattern is useful when a class cannot anticipate the class of objects it should create.

🔸 This pattern is useful when a class wants its subclasses to specify the objects it will create.

🔸 This pattern is useful when you want to provide a library of classes so that users can extend it.

🔸 This pattern is useful if you want to save resources and improve performance by reusing existing objects instead of creating new ones.

Problem

Imagine you are working on a Windows application that deploys multiple UI elements such as buttons, inputs, textareas, etc.
In the first version of the application, you create a class for each UI element, so the Dialog class stores the code to create,
manipulate, and display a dialog on the Windows OS. Your app gains popularity, so after some time, you are asked to add support for other operating systems.

Since much of the Dialog logic is based on Windows, you need to create a new class for each operating system your app supports.
Worse, if support for another operating system is requested in the future, you will have to create a new class to support the new operating system.

As a result, your code becomes difficult to maintain, as each class has similar logic but with small differences.
Additionally, every time support for a new operating system is requested, a new class must be created to support the new operating system.

Solution

The Factory Method pattern solves the previous problem by defining a method that should be used for creating objects instead of a direct call to the constructor.
Subclasses can override this method to change the classes of objects that will be created.

Now it is possible to override the create_button method in the Dialog subclasses to create a specific button for each operating system.
However, the subclasses of the products can return different types of objects, which is why the factory method of the product base must return
a defined type as an interface.

In this example, both WindowsButton and MacButton implement the Button interface, which declares a render method that will be implemented by the subclasses.
Each button class implements the render method differently, so that the Windows button renders a button with a Windows style, and the Mac button renders a
button with a Mac style.

🔹 The factory method in WindowsDialog returns WindowsButton objects, while the factory method in MacDialog returns MacButton objects.

🔹 The client code does not see a difference between WindowsButton and MacButton objects, since both implement the same interface.

🔹 The client treats all buttons in the same way, regardless of their concrete class.

🔹 The client knows that all buttons have a render method, but it does not know how this method is implemented in each concrete class.

How?

1️⃣ A common interface is declared for all products that will be produced by the creator and its subclasses.

2️⃣ The concrete products are different implementations of the common interface.

3️⃣ The creator declares a factory method that returns an object of the concrete products. It is important that the return type is the common interface.

4️⃣ The subclasses of the creator override the factory method to return different types of products.

💡 Note: The factory method should not create new objects all the time. Instead, the factory method should return existing objects stored in a cache or other source.

Why?

📍 The Factory Method pattern follows the Open/Closed principle, which states that classes should be open for extension but closed for modification.

📍 The Factory Method pattern allows subclasses to extend the logic of object creation without modifying the superclass code.

📍 The Factory Method pattern follows the Single Responsibility Principle, which states that a class should do only one thing and do it well.

📍 The Factory Method pattern allows subclasses to change the type of objects that will be created without modifying the superclass code.

📍 The Factory Method pattern allows subclasses to reuse the superclass code to create objects of different types.

Show me the code

# Button "Interface"
# (since interfaces does not exist in Ruby, we will use a module to define the interface)
module Button
  def render
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end

  def on_click
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end
end

class MacButton
  include Button

  def render
    puts 'MacButton render'
  end

  def on_click
    puts 'MacButton on_click'
  end
end

class WindowsButton
  include Button

  def render
    puts 'WindowsButton render'
  end

  def on_click
    puts 'WindowsButton on_click'
  end
end


# Dialog
class Dialog
  def initialize
    @button = create_button
  end

  def render
    @button.render
  end

  def on_click
    @button.on_click
  end

  def create_button
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end
end

class WindowsDialog < Dialog
  def create_button
    WindowsButton.new
  end
end

class MacDialog < Dialog
  def create_button
    MacButton.new
  end
end

# Client
def main
  dialog = WindowsDialog.new
  dialog.render
  dialog.on_click

  dialog = MacDialog.new
  dialog.render
  dialog.on_click
end

# Output
WindowsButton render
WindowsButton on_click
MacButton render
MacButton on_click

Conclusion

The Factory Method is a creational design pattern that provides an interface for creating objects in a superclass,
but allows subclasses to alter the type of objects that will be created.

🔺 This pattern is useful when a class cannot anticipate the class of objects it should create.

🔺 This pattern is useful when a class wants its subclasses to specify the objects it will create.

🔺 This pattern is useful when you want to provide a library of classes so that users can extend it.

🔺 This pattern is useful if you want to save resources and improve performance by reusing existing objects instead of creating new ones.

References

💻 You can find this and other design patterns here 📚