Fran Martinez

Let me introduce myself

2023-11-21T10:00:47+00:00

Hi!

My name is Fran Martinez. Nice to meet you! I am backend developer borned in Barcelona city, although since some years ago I live in an small village in the mountains of Almería, Spain. I started my career in 2005 but it was not until I discovered Ruby that I became a proud developer.

I like all about development culture, from the product definition to development, but I what I most like is to share knowledge and open my mind to other points of view. Every product is the result of a shared artistic process; it’s the result of collaborative work, and that’s why I like responsible and enthusiastic people, who shares knowledge and who spend their time helping others to improve. This is at least what I try to do.

I have been always looking to work remotely and it was on 2016 when I achieved this dream. Working remotely changed my life and now I am currently a proud evangelist of this working culture.

What can I do

> Ruby (and Rails)

11 years experience with Ruby. From the creation of a Rails app to a PORO ruby coder. The Ruby community made me be reborn as a developer in 2012. Since then, I have learn the SOLID principles, design patterns, metaprogramming, git, TDD and Agile.

About APIs, I have strong experience with GraphQL and JSONAPI. About databases, I can handle any SQL challenge and I have experience in NoSQL databases. Also, I briefly worked with Kafka some time ago for an event sourcing solution and I really loved it!

I am clearly a backend developer, but I like to understand how frontend works and I am not afraid of having frontend (Javascript, React, Vue) challenges.

> Design patterns, architecture

I like design patterns and architecture, take part on conversations about refactors, improvements and make scalable solutions. If a solution is not scalable and not easy to understand, then it is not a good solution.

> Javascript and frontend

During my whole professional career I have been trying to keep myself updated in the frontend side. I am not afraid of Javascript, CSS and HTML and I like to play with frameworks like React or Vue. In the frontend area I feel like a junior that can easily become a senior in a very short time.

> Docker and Kubernetes

I used Docker on my local setup for a long time, but it was not as fast as using native installations, so I decided to go back to native! However, I like the versatility of having services up and running without having to take care about installations. Is the best magic ever!

About production environments, I have experience working with Kubernetes, updating memory size, number of replicas, environment variables, etc.

> Srum/Agile and Kanban workflows

I have worked with Scrum and Kanban. I have been scrum master and team lead for a team of 7. On the discussion between Scrum and Kanban I reckon that I am in love with Kanban methodology when it has to be applied to asynchronous remote teams. However, I have years of experience working with Scrum and applying team workflows in companies.

More about me

I am a very friendly person who likes to learn every day as a way of life. I have many hoobies! That’s why I like remote jobs, in order to have this balance between professional and personal skills.

I am a peaceful guy who likes to meet friends, practice yoga, play the guitar, learn about renewable energies, and of course reading about programming, philosophy, science fiction and classical novels. I also take care of my organic vegetable garden.

Create a new Rails project with Docker compose

2018-05-22T16:40:00+00:00

This guide shows you how to use Docker Compose to set up and run a Rails/PostgreSQL app.

Define the project

We need to define four files to start a complete Rails project with Docker:

Dockerfile
docker-compose.yml
Gemfile
Gemfile.lock

Let’s start with the Dockerfile. This file defines an image with a Docker container with Ruby and its dependencies. The application code will be located in the myapp directory.

# Dockerfile

FROM ruby:2.5.0
RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs
RUN mkdir /myapp
WORKDIR /myapp
COPY Gemfile /myapp/Gemfile
COPY Gemfile.lock /myapp/Gemfile.lock
RUN bundle install
COPY . /myapp

We will need an existent Gemfile and Gemfile.lock. The Gemfile.lock is just an empty file:

$ touch Gemfile.lock

About the Gemfile we just need to create a bootstrap one to load Rails. It will be overwriteen with the call to rails new.

# Gemfile

source 'https://rubygems.org'
gem 'rails', '5.1.5'

Finally, create a docker-comspose.yml file:

# docker-compose.yml

version: '3'
services:
  db:
    image: postgres
    volumes:
      - ./tmp/db:/var/lib/postgresql/data
  web:
    build: .
    command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'"
    volumes:
      - .:/myapp
    ports:
      - "3000:3000"
    depends_on:
      - db
    tty: true
    stdin_open: true

See that we have defined a couple of services: web and db, and that web depends on db. That means that the web knows the existence and have access to the database.

Build the project

Having those files created, you just need to run next command:

docker-compose run web rails new . --force --database=postgresql

You will see that the content of Gemfile has changed after this last command. Remember that the Dockerfile moves this file into the image and we have now a different one. Because of this change, you need to build again:

docker-compose build

Connect the database

The service of the databse is called db in the docker-compose.yml. We need to configure the database.yml in order to access to this service. To do so, we need to add the host and the username part of the file:

default: &default
  adapter: postgresql
  encoding: unicode
  host: db
  username: postgres

Postgres port

By default, postgres opens the port 5432. If you have a running local instance of postgres this port will be already opened and you won’t be able to run the Docker one. Given that case you have two options:

stop your local instance of postgres
change the port that uses your docker in you image. That could be done adding a port tag in the db configuration in docker-compose.yml.

Try it!

Run migrations:

docker-compose run web bundle exec rails db:create db:migrate

This will run all the services:

docker-compose up

This will run an specific service and its dependencies:

docker-compose run --service-ports web

From here, you can work as always. Maybe it’s timne to create a new model. Remeber that you have to use docker in any call:

docker-compose run web bundle exec rails g model User name:string

Stub methods like Rspec

2018-05-15T14:40:00+00:00

Could you recognise what is it doing next code?

let(:fran_user) { User.new }

before do
 allow(fran_user).to receive(:nickname).and_return("martinezcoder")
end

it { expect(fran_user.hi).to return("Hi, this is martinezcoder!")}

Sure! This is a call to stub a method with Rspec. But,

Could you do the same without using Rspec?
Do you know how to stub the method of a single instance?

In this case, considering that fran_user is an instance of User, I am suposse to have a User class including the method hi and nickname. When running the test, if the instance fran_user uses the method hi, it will respond “Hi, this is martinezcoder!”, instead of the returned value defined in the method.

class User
  def nickname
    "me"
  end

  def hi
    "Hi, this is #{nickname}!"
  end
end

fran_user = User.new
puts fran_user.hi

Last code will puts:

=> "Hi, this is me!"

How to stub the instance of User without using Rspec?

Stub the nickname method of the fran_user instance:

fran_user = User.new
puts fran_user.hi

class << fran_user
  def nickname
    "martinezcoder"
  end
end

puts fran_user.hi

Last code will puts:

=> "Hi, this is me!"
=> "Hi, this is martinezcoder!"

So you now know how to stub an instance method without the dependency of Rspec!

RESTful JSON API With Rails 5

2018-05-15T08:40:00+00:00

The Rails documentation says that Ruby on Rails is a web-application framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern. However, several companies were using rails just to create a backend API, and that was translated into having tons of unnecessary code dependencies. That’s why since version 5, Rails started offering a way to create an API-only applications, which only provides the required things to have a super powerful API.

Find a more detailed explanation in the API-only documentation.

This post is a self-guide to create a new API-only project. It’s not a tutorial that resolves and exercise, but a guide to remember the steps to follow in the creation of an API from scratch.

Creating an API-only rails project

To start creating an API-only Rails applications, ensure that your Rails version is equal or higher than 5.

> rails -v
Rails 5.2.0

Then create a new API-only application:

> rails new my-api --api -T

The --api part, tells Rails that we want an API-only application. The -T part is necessary if you want to avoid the use Minitest as the default testing framework. I normally use rspec, so I would include it.

Arriving here, you have a Rails API-only application with these properties:

It still provides things out of the box. It provices a set of middleware with all the stuff we could need for an API.
The ApplicationController inherit from ActionController::API instead of from ActionController::Base.
As any other Rails application, it will provide routing resources and helpers, caching, authentication, etc.

Project Setup

This would depend on personal preferences, but I normally setup every new project with this gems:

rspec-rails - I have nothing against Minitest, but I normally use Rspec testing framework. It is needed to run rails generate rspec:install to install it in a project.
shoulda_matchers - Include more matchers to Rspec
factory_bot_rails - Very userful tool to use fixtures.
faker - A library for generating fake data such as names, addresses, and phone numbers.
database_cleaner - We can ensure a clean environment before the execution of each test. It needs to include a piece of code in our rails_helper.rb file.

Find here a commit adding all these dependencies.

API Endpoints

Now that we have our project to start, it’s the best moment o start thinking in the endpoints we will need. It will help us to have a clear idea of the models and the controllers that we will need.

Write down a draft of the endpoints.

Model definition

We have a list of endpoints, so we know more or less the main models and its associations.

Create the database: models, associations, migrations
TDD: add tests to check associations and presence validations
Fix the tests adding the validations and associations to the models.
Create factories for each model using Faker value. They will be useful in the next step.

At this point we have valid models and its associations and validations.

Controllers and routes

Generate the required controllers with rails g controller Name.
Create requests tests. You can use this one as a guide.
The errors in the tests will guide you to add the required routes.

Responses

I like controller responses with this structure:

render json: object, status: status

Look at this example.

Exception handler

In the case that a searched record does not exist, Rails will through an error. Instead or raising the error, it would be necessary to rescue that error and notify the user with the problem.

We should rescue any kind of error on which we need to notify the API client. To do this, we can create a concern:

# app/controllers/concerns/exception_handler.rb
module ExceptionHandler
  # provides the more graceful `included` method
  extend ActiveSupport::Concern

  included do
    rescue_from ActiveRecord::RecordNotFound do |e|
      render json: { message: e.message }, status: :not_found
    end

    rescue_from ActiveRecord::RecordInvalid do |e|
      render json: { message: e.message }, status: :unprocessable_entity)
    end
  end
end

And include it in the ApplicationController:

# app/controllers/application_controller.rb
class ApplicationController < ActionController::API
  include ExceptionHandler
end

Versioning

It is not necessary to add versioning in your first version. But when the day comes in which you have to add a second version, you can afford it in different ways.

Have in mind that in any kind of solution you would have to

Add a route constraint to select the version
Use different namespaces for the controllers, depending on the version.

There are different options to apply versioning in our project. The most common are:

Using different routes and namespaces.
Selecting the version from the headers (using a route constraint). Follow this documentation.

Serializers

I have always used Active Models Serializers, but I recently discovered Fast JSON API from Netflix, and sounds promising. I will use that last one in my next project.

https://github.com/Netflix/fast_jsonapi

Pagination

Any serious production API have to include pagination. Will_paginate or kaminari will do the trick.

Authentication and authorization

Follow this guide.

For authorization, the gem Pundit is great.

Caching

Conditional GETs: Rails handles conditional GET (ETag and Last-Modified) processing request headers and returning the correct response headers and status code. All you need to do is use the stale? check in your controller, and Rails will handle all of the HTTP details for you.

Strategy pattern and singleton behavior

2018-05-13T16:00:00+00:00

Imagine that you have a collection of objects representing animals. Some of them can fly and some others not. You would like to include the method fly in all them, although not all them can fly, so you go with the Template Method Design Pattern.

class Animal
  def fly
    raise NotImplementedError
  end
end

class Lion < Animal
  def fly
    "I can't fly!"
  end
end

class Duck < Animal
  def fly
    "I am flying!"
  end
end

Depending on the class, you decide whether it can fly or not. But this is not very clever, because we will be creating a lot of duplicate code. We will have as many fly methods as animals we create, and all of them will have the content repeated again and again.

We can improve the architecture of the code with Strategy Design Pattern.

Strategy Design Pattern

We have two options (strategies) to decide to include on each animal: it can fly or it can not. So we create a module containing both strategies:

module Flys
  module ItFlys
    def fly
      puts "I am flying"
    end
  end

  module CantFly
    def fly
      puts "I can't fly"
    end
   end
end

We decide that animals can’t fly as a default. And we include the CanFly strategy in the animals that can fly:

class Animal
  include Flys::CantFly
end

class Lion < Animal
end

class Duck < Animal
  include Flys::ItFlys
end

irb> lion = Lion.new
irb> lion.fly
"I can't fly"
irb> duck = Duck.new
irb> duck.fly
"I am flying"

Asigning it by injection

We can still go further and apply the behavior on each instance by injection:

module Flys
  module ItFlys
    def self.fly
      puts "I am flying"
    end
  end

  module CantFly
    def self.fly
      puts "I can't fly"
    end
   end
end

class Animal
  attr_accessor :fly_behavior

  def initialize(fly_behavior = Flys::CantFly)
    @fly_behavior = fly_behavior
  end

  def fly
    fly_behavior.fly
  end
end

class Lion < Animal
end

class Duck < Animal
end

irb> lion = Lion.new
irb> lion.fly
"I can't fly"
irb> duck = Duck.new(Flys::CantFly)
irb> duck.fly
"I can't fly"
irb> duck.fly_behavior = Flys::ItFlys
irb> duck.fly
"I am flying"

For the issue of flying animals, this last way of doing strategy design seems not the most appropiate. All ducks fly, so I personally prefer the previous solution for this case.

But, we have seen that in this last example we have the option to change the fly_behavior of an instance. How could we do this with the code of the previous solution? I will do it in the next example using a mixin to change the flying behavior of an instance. That means, overwrite a singleton method.

Singleton behavior

But wait, a duck with 1 day of life is not able to fly, so, can a duck fly? Well, it depends. Next code will demostrate how to change this behaviour depending on the value of the instance variable age.

When the duck is old enough, it can fly!

module Flys
  module ItFlys
    def fly
      puts "I am flying"
    end
  end

  module CantFly
    def fly
      puts "I can't fly"
    end
   end
end

class Duck
  include Flys::CantFly

  DAYS_TO_FLY = 50

  def initialize(age=0)
    @age = age
    @can_fly = false
    try_to_fly
  end

  def age=(days)
    @age = days
    try_to_fly
  end

  private

  def try_to_fly
    return if @can_fly
    self.extend(Flys::ItFlys) if @age >= DAYS_TO_FLY
  end
end

With this solution, an instance of a Duck will be able to fly at its seventh week of life, but not before.

Fibers, Procs and Enumerables

2018-05-13T16:00:00+00:00

Last day I spend some hours investigating a bit deeply about Enumerable. It is that kind of stuff that shows the magic of the Ruby language. Once you have the whole control of enumerables, you feel the power of being a Ruby developer.

Fibers, Procs and Enumerables are different things in Ruby. But I will resolve the very traditional example of showing prime numbers with each one of them.

We will define a module with the common code to find the prime numbers:

module PrimeFinder
  private

  def find_next_prime(x)
    x += 1 while !prime?(x)
    x
  end

  def prime?(x)
    i = 2
    while i <= Math.sqrt(x)
      return false if x % i == 0
      i += 1
    end
    true
  end
end

Proc

Proc saves the last state of the x variable, so in every call it will return the value of the next prime number:

class Prime
  include PrimeFinder

  def proc
    x = 1
    Proc.new do
      x = find_next_prime(x+1)
    end
  end
end

irb> p = Prime.new.proc
=> #<Proc:test/fiber.rb>
irb> p.call
=> 2
irb> p.call
=> 3
irb> p.call
=> 5
irb> p.call
=> 7
irb> 5.times { puts p.call }
11
13
17
19
23
=> 5

Proc objects picks up the surrounding environment. Any variables that are visible when a Proc is created remain visible inside the Proc when it is run. That’s why x inside the Proc object is the same as the x outside.

Also, a Proc always returns the last value computed in the code block. This is because Proc objects have a lot in common with methods, so the last expression in the block will be the returned value of call.

In summary, this solution does the trick, but it doesn’t seem the best solution for this issue.

Fiber

Fibers are light weight primitives in the Ruby standard library which can be paused, resumed and scheduled manually. Fibers are commonly used in combination of concurrence processes, because they simplify asynchronous code.

In this case, it will just return next prime number and pause the loop.

class Prime
  include PrimeFinder

  def fiber
    Fiber.new do
      x = 1
      loop do
        Fiber.yield x = find_next_prime(x+1)
      end
    end
  end
end

irb> f = Prime.new.fiber
=> #<Fiber:(irb):3 (created)>
irb> f2 =  Prime.new.fiber
=> #<Fiber:(irb):3 (created)>
irb> f.resume
=> 2
irb> f.resume
=> 3
irb> 3.times { puts f.resume }
5
7
11
=> 3
irb> 3.times { puts f2.resume }
2
3
5
=> 3

Basically, Fiber#yield returns control back to the context that resumed the Fiber and returns the value which was passed to Fiber#resume. Each defined fiber, will control its own independent state. That’s why it is useful in concurrence executions.

Enumerable

Option A

The traditional way with the include Enumerable and defining an each method. This way, we can use all the methods for enumerables like take, first, etc.

class Prime
  include PrimeFinder
  include Enumerable

  def each(&block)
    x = 1
    loop do
      yield x = find_next_prime(x+1)
    end
  end
end

Note that using take and first of Enumerable always start by the first prime number 2. But if we use to_enum, the result saves the last state of the loop.

irb> p = Prime.new
=> #<Prime:>
irb> p.take(3)
=> [2, 3, 5]
irb> p.first(3)
=> [2, 3, 5]
irb> e = p.to_enum
=> #<Enumerator: #<Prime:>:each>
irb> e.next
=> 2
irb> e.next
=> 3
irb> e.next
=> 5
irb> e.next
=> 7
irb> e.next
=> 11

Option B

Instead of using the include Enumerable, we define an enumerable for an specific method. Is the same as using to_enum in the last example.

class Prime
  include PrimeFinder

  def enum
    x = 1
    return enum_for(:enum) if !block_given?

    loop do
      yield x = find_next_prime(x+1)
    end
  end
end

irb> p = Prime.new.enum
=> #<Enumerator: #<Prime:>:enum>
irb> p.next
=> 2
irb> p.next
=> 3
irb> p.next
=> 5
irb> p.next
=> 7
irb> p.take(3)
=> [2, 3, 5]
irb> p.first(3)
=> [2, 3, 5]
irb> p.next
=> 11

Note how the last p.next has continue the list showed before in the last call to p.next. But in the middle, we called p.take and p.first and the index of the state was not altered.

Conclusion

Ruby offers us different ways to do the same. In this case, the use of Enumerable is the best approach.

I have been playing with Fiber and Proc to achieve similar results, but their purpose are not to resolve this kind of issues. Also, I investigate about Fiber and I found that Matz proposed to include the Enumerable to Fiber by default. The proposal was finally rejected because they didn’t find any reasonable use case.

FIFO queues!

2018-05-10T15:14:47+00:00

When I was a C developer we used very frequently FIFO queues. FIFO means first input, first output. This kind of queues have a fixed size. When the queue is full of elements, if a new element is enqueued, the first element enqueued has to fall out (has to be returned and removed from the queue).

How would you implement this behavior with Ruby language?

Here is how I would do it:

## fifo_queue.rb

class FIFOQueue
  attr_accessor :size, :arr

  def self.[](*values)
    obj = self.new(values.size)
    obj.arr = values
    obj
  end

  def initialize(size)
    @size = size
    @arr  = Array.new
  end

  def push(element)
    arr.push(element)
    arr.shift if arr.length > size
  end
end

class Array
  def to_fifo
    FIFOQueue[*self]
  end
end

Adding the method to_fifo to the Array class permits us to create a new Array as we normally do and convert it a FIFO queue.

> irb -I . -r fifo_queue.rb
irb> b = ["a", 2, 3].to_fifo
=> #<FIFOQueue: @size=3, @arr=["a", 2, 3]>
irb> b.push "b"
=> "a"
irb> b.arr
=> [2, 3, "b"]