The project

I’m building a school administration platform as a side project: a Rails app, a React Native (Expo) mobile client, and a GitHub Projects board that tracks everything as issues. I’m the only developer, so the board is my memory. Every bug, feature, and idea becomes a ticket that moves from Backlog to Ready, In progress, In review, and Done.

Claude Code does most of the typing now. My job is deciding what to build and reviewing what comes back.

Before: the same prompt, every time

My early sessions all started with some version of this:

Read issue 124, including the comments. Look at the code it mentions. Tell me your plan before changing anything. Then create a branch named after the issue, move the ticket to In progress, implement it, run the tests and RuboCop, open a PR that says “Fixes #124”, and move the ticket to In review. Don’t merge.

It worked, but only if I remembered every line. When I forgot one, I got a PR without the Fixes line, a branch cut from whatever branch I happened to be on, or a ticket still sitting in Ready when the work was done. Each mistake was small, but I kept fixing the same ones over and over.

The fix for most of them was the same: stop typing the procedure, and write it down once where the agent can find it.

What a skill is

A skill is a folder in your repo with a SKILL.md file inside:

.claude/skills/
  work-ticket/SKILL.md
  check-ticket/SKILL.md
  create-ticket/SKILL.md

The file starts with a short front matter block. The description matters most, because Claude Code reads it to decide when the skill applies:

---
name: work-ticket
description: Pick up a ticket from the School Admin board by issue number,
  issue URL, or board link. Assesses the ticket, confirms a plan with the
  user, moves it to "In progress", creates a numbered branch, implements
  the work, and opens a PR for review.
---

Below that is plain Markdown, with numbered steps and the exact commands I’d otherwise type. There’s no framework or plugin to install. Because the skill lives in the repo, it gets versioned and reviewed like any other code.

The first skill: work-ticket

I wrote work-ticket at the end of July. It was mostly my old prompt, cleaned up and split into steps:

1. Turn the reference into an issue number (a bare 124, an issue URL, or a board link).
2. Read the ticket, including the comments, since that’s where scope changes live.
3. Look into the code.
4. Write an assessment and a step-by-step plan.
5. Stop and ask me to confirm. Nothing changes before I say yes.
6. Move the board item to In progress.
7. Create a branch named <number>-<short-description>.
8. Implement.
9. Run the tests and RuboCop.
10. Open the PR with Fixes #<number> and move the item to In review.

It ends with two guardrails I care about more than any single step:

## Guardrails
- Never push directly to `main` and never merge the PR yourself.
- If the plan needs to change significantly mid-implementation, pause
  and re-check with the user before continuing.

After that, my prompts got very short. “Work on 131” was enough.

Skills grow from corrections

What I didn’t expect was how the skills would change over time. Almost every edit started as a correction I made during a session, which I then wrote into the file so I’d never have to make it again. From the git history:

• Same night: “Check the current branch before creating a new one,” so it never branches off something I’m halfway through.
• Same night: a merge step, but only after I explicitly say the PR is reviewed and approved.
• Three weeks later: “Check CI before merging.” My “yes, merge it” shouldn’t count if a check went red after I said it.
• September: size the investigation to the ticket. For a one-file fix, read the file directly instead of starting a search subagent, and run only the tests you touched unless the change is broad.
• Late September: the board passed 500 items, and the way the skill looked up a ticket’s board entry quietly stopped working. The fix was to ask the issue for its board item instead of listing the whole board.

None of these were planned. Each one was a moment where I thought “I’ve told it this before,” and the right response was to edit the file instead of the prompt.

Splitting the job: create, check, work

Once work-ticket was solid, the same pattern showed up at the other end of the board. Tickets I’d filed months earlier were often stale. The bug had already been fixed, or the file the ticket mentioned no longer existed.

So I added check-ticket. It reads a ticket, investigates whether it’s still true, and does one of two things:

• If it’s no longer valid, it posts a comment with the evidence (a file and line, a merged PR, a duplicate issue) and asks whether to close it.
• If it’s still valid but missing something, like repro steps or acceptance criteria, it comments with exactly what’s missing and offers to hand off to work-ticket.

Then I added create-ticket, which turns one sentence into an issue on the board in Backlog. It deliberately does very little itself. Its last step is to call check-ticket on the new issue, so the investigation logic lives in one place instead of two.

The result is a pipeline that matches how I already thought about the board:

one sentence ──> create-ticket ──> check-ticket ──> work-ticket ──> PR
                  (file it)        (is it real?    (plan, branch,
                                    what's missing?) build, test)

Here’s a real run. I typed:

/create-ticket Ability to delete cancelled events from calendar

A minute later I had issue #1073 in Backlog with a follow-up comment from check-ticket raising three things to settle first: only allow deleting a meeting that’s already cancelled, add the first action to the cancelled-meeting card, and reuse the refresh pattern from the PR that had just landed so we wouldn’t reintroduce a stale-calendar bug. I answered the three questions in one message, and it added my decisions to the ticket.

The mobile app got its own copy

The mobile repo has the same three skills, adapted to its own board and with one important addition. The mobile app is a client for the Rails API, so before filing a ticket, create-ticket checks whether the request can actually be built against the existing API contract:

If backend work looks needed, stop and tell the user what appears to be
missing and why (cite the specific endpoint/field gap), then ask for
explicit confirmation on how to proceed. Do not create the issue until
they confirm.

That one paragraph has saved me from filing mobile tickets that couldn’t be built yet.

What I’ve learned

Start with the prompt you keep retyping. My first skill was a cleaned-up copy of a prompt I already used every day. You don’t need to design anything up front.

Edit the skill, not the session. When the agent gets something wrong in a way it’ll get wrong again, fix it in the file. Corrections in chat disappear when the session ends; corrections in the file stay.

Keep each skill small and hand off. create-ticket doesn’t investigate, it calls check-ticket. Small skills that call each other are easier to fix than one big one.

Write guardrails as rules, not suggestions. “Never merge without explicit confirmation” and “never close an issue based only on this skill’s assessment” are the lines that let me trust the rest. The agent handles the steps; the irreversible decisions stay with me.

Put the commands in. Exact gh commands with the real project number make the skill both reliable and fast. The agent doesn’t have to rediscover how my board works every time.

I’ve since added skills for pre-merge reviews, visual mockups, and keeping Dependabot PRs moving, and I’ll write about some of those next. They all started the same way, as a prompt I was tired of typing.

This blog post will be a brief overview of how to configure Sidekiq in Rails.

The very first thing is to add the gem in the Gemfile like this

gem 'sidekiq', '~> 6.1.0'

and run bundle install

Now let’s assume that we’re working on a Blog project where we have a User, Post, and Comment models like this…

class User < ApplicationRecord
    has_many :posts
end

class Post < ApplicationRecord
  belongs_to :user
  has_many :comments
end

class Comment < ApplicationRecord
  belongs_to :post
  belongs_to :user
end

And for whatever reason we want to create a background job that creates a random comment on a random post… the cool thing about Rails and background jobs is that Rails has the ActiveJob framework that is some sort of interface for background jobs so you can switch the backend to whatever you want.

So in order to create a background job in Rails for Sidekiq we first need to configure sidekiq and since in this case I’m just going to test it in development I’ll go ahead and open config/environments/development.rb and add the below lines in stating that we want to use sidekiq as the backend for background jobs and the queue name prefix…

config.active_job.queue_adapter = :sidekiq
config.active_job.queue_name_prefix = "sidekiq_example_development"

Next we configure an initializer for Sidekiq in config/initializers/sidekiq.rb

Sidekiq.configure_server do |config|
    config.redis = { url: 'redis://localhost:6379/0' }
end
  
Sidekiq.configure_client do |config|
    config.redis = { url: 'redis://localhost:6379/0' }
end

Here’s where we configure Sidekiq’s client and server pointing to redis, in my case it’s a local redis server using Redis.app

The final step in the configuration is to specify Sidekiq what queues from Redis to pick up, we do that by creating a file in config/sidekiq.yml

:queues:
  - sidekiq_example_development_default
  - sidekiq_example_production_default

And that’s pretty much it on the configuration side unless you want to configure the UI which I’ll show you how in config/routes.rb

Rails.application.routes.draw do
  # For details on the DSL available within this file, see https://guides.rubyonrails.org/routing.html
  # ...
  require 'sidekiq/web'
  mount Sidekiq::Web => '/sidekiq'
end

It’s as simple as that not too bad, now let’s go ahead and create a Sidekiq background job through Rails via ActiveJob, in the terminal we type…

$ rails g job generate_random_comment

This creates a file app/jobs/generate_random_comment_job.rb

class GenerateRandomCommentJob < ApplicationJob
  queue_as :default

  def perform(*args)
    # Do something later
  end
end

Now let’s do something not efficient to do in the background like creating a random comment on a random post and for that we’ll use the Faker gem

# Inside Gemfile

gem 'faker'

And now inside app/jobs/generate_random_comment_job.rb

class GenerateRandomCommentJob < ApplicationJob
  queue_as :default

  def perform(*args)
    # Fetching a random user
    user = User.find(
      User.pluck(:id).sample
    )

    # Fetching a random post from user
    post = Post.find(
      user.posts.pluck(:id).sample
    )

    # Creating a random comment with Faker
    post.comments.create(
      title: Faker::Lorem.word,
      content: Faker::Lorem.sentence,
      user: user
    )
  end
end

Right before we run the background job we need to make sure both Redis and Sidekiq are running, in order to run Sidekiq we go to the terminal run

$ sidekiq

And you should see this nice graphic

               m,
               `$b
          .ss,  $$:         .,d$
          `$$P,d$P'    .,md$P"'
           ,$$$$$b/md$$$P^'
         .d$$$$$$/$$$P'
         $$^' `"/$$$'       ____  _     _      _    _
         $:     ,$$:       / ___|(_) __| | ___| | _(_) __ _
         `b     :$$        \___ \| |/ _` |/ _ \ |/ / |/ _` |
                $$:         ___) | | (_| |  __/   <| | (_| |
                $$         |____/|_|\__,_|\___|_|\_\_|\__, |
              .d$$                                       |_|
      

Now let’s take the background job for a spin in the rails console $ rails c and type this…

> GenerateRandomCommentJob.perform_later
Enqueued GenerateRandomCommentJob (Job ID: f2a594a9-9b9f-4900-8f32-a07d030b04e8) to Sidekiq(sidekiq_example_development_default)
 => #<GenerateRandomCommentJob:0x00007f9d88287788 @arguments=[], @job_id="f2a594a9-9b9f-4900-8f32-a07d030b04e8", @queue_name="sidekiq_example_development_default", @priority=nil, @executions=0, @exception_executions={}, @provider_job_id="8ab54cb7e77b2d218bec63e2">

And if you have the Rails server running $ rails s and go to http://localhost:3000/sidekiq/queues you should see something like this

Awesome, this means that we have successfully ran our background job with Sidekiq through Redis inside a Rails app, now let’s make things a bit more fun running the background job multiple times to see a bit better Sidekiq in action.

Let’s run the background job 100 times through the Rails console

> 100.times { GenerateRandomCommentJob.perform_later }

And see what happens in the web UI

Awesome now we have a basic configuration for Redis + Sidekiq + Rails running locally :)

Happy coding! if you have any questions please let me know in twitter at @fcastellanos.

Minitest is a small, simple and fast testing framework that not only facilitates testing, TDD, etc, but also provides mocking and benchmarking, and on the comparison before between Cucumber and Steak, RSpec is a DSL while Minitest is just Ruby which not only will it be faster but also you can customize however you want.

Minitest is also part of the standard library meaning that you don’t have to add external libraries which also means that it’s available for you to use in Rails which is what I want to show. Here’s a brief example.

Let’s imagine we have an ActiveRecord model like this…

class Airline < ApplicationRecord
    validates :name, presence: true
    validates :image_url, presence: true

    has_many :reviews
end

You might want to validate that the name and image_url are present and it’s a very simple assertion, you might create an airline with name and image_url and if you’re going to test the name validation you set it to nil assert that the model is not valid and might also check the errors collection and repeat for the image_url, simple, right?

Now what about the reviews association? we have several options, one is to check if the airline model includes the reviews method via respond_to? but that’s not accurate because we could have a def reviews; nil end method defined which will give a false positive, same if we assert that reviews returns a collection or a number of items if we have a method like this def reviews; [1,2,3] end it’s still a false positive.

A good thing that I liked about minitest was that there is no out of the box way for you to check for ActiveRecord associations like what you can do with RSpec/Shoulda, you need to dig a bit into how ActiveRecord handles and reports associations which is good because you get to know ActiveRecord a bit better.

Now ActiveRecord has a class method reflections that you can use in your models which returns associations and aggregations of Active Record models and classes, we can take advantage of that to make sure that we have an actual association instead of a method getting rid of a false positive.

2.7.1 :001 > Airline.reflections
 => {"reviews"=>#<ActiveRecord::Reflection::HasManyReflection:0x00007ffc1a28d6d8 @name=:reviews, @scope=nil, @options={}, @active_record=Airline (call 'Airline.connection' to establish a connection), @klass=nil, @plural_name="reviews", @type=nil, @foreign_type=nil, @constructable=true, @association_scope_cache=#<Concurrent::Map:0x00007ffc1a28c3f0 entries=0 default_proc=nil>>} 

With this knowledge we can create a custom assertion or a helper method inside our Rails test_helper.rb

# Add more helper methods to be used by all tests here...
def assert_association(model, association, association_type)
    assert_includes model.reflections, association.to_s

    assert_equal association_type, model.reflections[association.to_s].macro
end

Now in airline_test.rb we can have this test

test 'has_many reviews' do
    assert_association Airline, :reviews, :has_many
end

Or we can make it a bit more readable by adding two more helper methods inside test_helper.rb

def assert_has_many(model, association)
    assert_association model, association, :has_many
end

def assert_belongs_to(model, association)
    assert_association model, association, :belongs_to
end

So we could have…

test 'has_many reviews' do
    assert_has_many Airline, :reviews
end

and in review_test.rb

test 'belongs_to airline' do
    assert_belongs_to Review, :airline
end

See? minispec can be very easy to write and to extend to meet your needs.

If you have any comments or questions feel free to reach out on twitter at @fcastellanos.

Here’s an example built in Python:

class Director:
    __builder = None

    def setBuilder(self, builder):
        self.__builder = builder
    
    def getCar(self):
        car = Car()

        # First goes the body
        body = self.__builder.getBody()
        car.setBody(body)

        # Then engine
        engine = self.__builder.getEngine()
        car.setEngine(engine)

        i = 0
        while i < 4:
            wheel = self.__builder.getWheel()
            car.attachWheel(wheel)
            i += 1
        
        return car

# The whole product 
class Car:
    def __init__(self):
        self.__wheels = list()
        self.__engine = None
        self.__body = None
    
    def setBody(self, body):
        self.__body = body
    
    def attachWheel(self, wheel):
        self.__wheels.append(wheel)

    def setEngine(self, engine):
        self.__engine = engine
    
    def specification(self):
        print("body: %s" % self.__body.shape)
        print("engine horsepower: %d" % self.__engine.horsepower)
        print("tire size: %d\'" % self.__wheels[0].size)

class Builder:
    def getWheel(self): pass
    def getEngine(self): pass
    def getBody(self): pass

class JeepBuilder(Builder):
    def getWheel(self):
        wheel = Wheel()
        wheel.size = 22
        return wheel
    
    def getEngine(self):
        engine = Engine()
        engine.horsepower = 400
        return engine
    
    def getBody(self):
        body = Body()
        body.shape = "SUV"
        return body

# Car parts
class Wheel:
    size = None

class Engine:
    horsepower = None

class Body:
    shape = None

There’s a lot of thing happening here so let’s break it apart. First we see the Director class which is sort of the director of an orchestra orchestrating the building of a car by setting the different properties of the car like the body, the engine and the wheels. Then we have the Car class which is basically a shell that receives the different parts of the car with the help of the Director. Down the code we see the Builder class which acts more like an interface defining the basic methods for building a car. The JeepBuilder class inherits from the Builder class and define the specifics for building a Jeep car by defining the size of the wheels, the horsepower and the shape of a Jeep car, we can create multiple builder classes for different brands of cars. Lastly we have the “placeholder” classes Wheel, Engine and Body we can use for every type of car.

Here’s how we to tie everything together:

jeepBuilder = JeepBuilder() # initializing the class
director    = Director()

# Build Jeep
director.setBuilder(jeepBuilder)
jeep = director.getCar()
jeep.specification()

Now on this part we instantiate a JeepBuilder instance and a Director instance separately and then we set the jeep builder to the director because builder is the one that provides the car parts to the director so it can “attach” them to the car object when calling the getCar() method. Lastly we call the specification() method on the jeep instance which displays the car properties showing that everything’s working properly.

This might take a bit of time to get used to but it’s a very powerful pattern that allows you to have everything separated and just build complex objects like if they were LEGO blocks.

As always if you have any comments or questions feel free to reach out on twitter at @fcastellanos.

Let’s see an example.

import types

class StrategyExample:
    def __init__(self, func = None):
        self.name = 'Strategy Example 0'

        if func is not None:
            self.execute = types.MethodType(func, self)

    def execute(self):
        print(self.name)

def execute_replacement1(self):
    print(self.name + ' from execute 1')

def execute_replacement2(self):
    print(self.name + ' from execute 2')

If we see the StrategyExample class it has an execute function that just prints out the name property, but in the initializer it can receive a func parameter that would be a function that replaces the execute function if func is present.

Down below we also see two functions execute_replacement1 and execute_replacement2 that just prints out a property name plus something else, the purpose of these functions is to act as replacements for the execute functions for the StrategyExample class

Now let’s see how we can implement it

strat0 = StrategyExample()

strat1 = StrategyExample(execute_replacement1)
strat1.name = 'Strategy Example 1'

strat2 = StrategyExample(execute_replacement2)
strat2.name = 'Strategy Example 2'

strat0.execute()
strat1.execute()
strat2.execute()

We create 3 instances of the StrategyExample class, one with no replacement and the other two with replacements for the execute function with execute_replacement1 and execute_replacement2, after the three initializations we call execute on the three instances of the same class but see three different results, in this case the three implementations use the name property but in three different ways, this is the flexibility of the Strategy Pattern.

If you have any comments or questions feel free to reach out on twitter at @fcastellanos.

For the Campaign Auction that I was rewriting for the Ad Server there were around 27 rules, there were rules to check if the requested Creative existed, GeoIP related rules, Language rules, among a bunch of other rules, in order to find a marching Campaign for that request, all 27 rules had to apply. To make this a bit more complicated the order of some of those rules did matter and it was not rare if we had to add or remove some of those rules. Now the reason why we had the need to rewrite this part of the Ad Server it was because the way that this was written in the first place, I’ll try to illustrate this without showing the actual code.

if client['creative_id'] in campaign['creatives']:
    if client['country'] in campaign['countries']:
        if client['region'] in campaign['regions']:
            if client['city'] in campaign['cities']:
                if client['language'] in campaign['languages']:
                    if client['param_1'] == campaign['param_1']:
                        if client['param_2'] == campaign['param_2']:
                            if client['param_3'] == campaign['param_3']:
                                if client['param_4'] == campaign['param_4']:
                                    if client['param_5'] == campaign['param_5']:
                                        if client['param_6'] == campaign['param_6']:
                                            if client['param_7'] == campaign['param_7']:
                                                if client['param_8'] == campaign['param_8']:
                                                    if client['param_9'] == campaign['param_9']:
                                                        if client['param_10'] == campaign['param_10']:
                                                            if client['param_11'] == campaign['param_11']:
                                                                if client['param_12'] == campaign['param_12']:
                                                                    if client['param_13'] == campaign['param_13']:
                                                                        if client['param_14'] == campaign['param_14']:
                                                                            if client['param_15'] == campaign['param_15']:
                                                                                if client['param_16'] == campaign['param_16']:
                                                                                    if client['param_17'] == campaign['param_17']:
                                                                                        if client['param_18'] == campaign['param_18']:
                                                                                            if client['param_19'] == campaign['param_19']:
                                                                                                if client['param_20'] == campaign['param_20']:
                                                                                                    if client['param_21'] == campaign['param_21']:
                                                                                                        if client['param_22'] == campaign['param_22']:
                                                                                                            # Finally found a matching campaign

No joke this was exactly how it was built but in PHP, the cherry on top was that this code had no tests at all, no wonder why programmers hate PHP but don’t blame PHP, it’s the lack of programming principles.

Each rule was not as simple as it’s portrayed here, some had multiple conditions, some of those multiple conditions called other functions, if there was something to rescue from this was that each condition had a comment explaining briefly what it was evaluating.

The first thing that I thought that I should do to refactor this mess was to have some test coverage as a safety net to make sure I was going in the right path, but by looking at the amount of nested conditions it was going to be a nightmare to create the different test scenarios to try and reach the maximum test coverage, next thing that I thought that would help was to give each condition a name and by that I mean to use the “extract method” pattern to extract each condition into its own boolean function, that would give a meaningful name to each condition in order to start giving it some shape and form. But definitely my best move was to ask my coworkers for suggestions, one suggested to build an array of functions and loop through each function and the moment that one function returned false we could break out of the loop because all conditions must meet in order to proceed, that suggestion was clever because it prevented the need to have nested if statements and reduced the code and the complexity by leaps and bounds, my other co-worker suggested to take a peak at an Avdi Grimm post called “Your business rules are objects too” which is a great article that helped take my solution an even greater form.

Now, there’s a twist to this story, the logical or conceptual Campaign Auction code was inside a a file that was around 2000 lines of code within a function that was probably 300 lines give or take, first thing was to extract the Campaign Auction code into a CampaignAuction class that would only do the Campaign Auction and nothing else long live SRP (Single Responsibility Principle). Once I managed to logically constrain the Campaign Auction code, it was time to get working on the refactor, I started by also extracting each condition into its own rule class that followed a simple interface with an applies boolean function, this means that I ended up with 27 rule classes all following the same interface.

class CreativeExistRule:
    def __init__(self, campaign, client_data):
        self.client_data = client_data
    
    def applies(self):
        return self.client_data['creative_id'] in campaign['creatives']

class CountryRule:
    def __init__(self, campaign, client_data):
        self.client_data = client_data
    
    def applies(self):
        return self.client_data['country'] in campaign['countries']

class RegionRule:
    def __init__(self, campaign, client_data):
        self.client_data = client_data
    
    def applies(self):
        return self.client_data['region'] in campaign['regions']

class CityRule:
    def __init__(self, campaign, client_data):
        self.client_data = client_data
    
    def applies(self):
        return self.client_data['city'] in campaign['cities']

This separation of concerns is great because it makes the code really testable by being able to test each rule in isolation.

Let’s see how the Campaign Auction class looks like after separating the logic from the 2000+ lines of code file.

class CampaignAuction:    
    rules = [
        'CreativeExistRule',
        'CountryRule',
        'RegionRule',
        'CityRule',
    ]

    def __init__(self, campaign, client_data):
        self.campaign = campaign
        self.client_data = client_data

    def perform(self):
        meets_all = True
        for rule in rules:
            rule_constant = globals()[rule]
            rule_instance = rule_constant(self.campaign, self.client_data)
            if not rule_instance.applies():
                meets_all = False
                break
        return meets_all

It’s really easy to see how this is much better than having all those nested if conditions that are virtually impossible to test under the current conditions. Now allow me to explain how this rule system works.

First thing to notice is the rules property in the CampaignAuction class, this is a list of the string representation of the class names of each rule class, we should be able to easily add and remove rules. Next is the __init__ function that takes the campaign data that we’re currently evaluating, we’ll be instantiating a new auction for each campaign that we want to check against, we’re also passing the client_data that will hold data coming from the request. Lastly we see the perform function that performs the actual auction. The “magic” happens by looping through each rule and finding the rule constant/class in the Python globals globals()[rule] and then we create an instance of that rule with rule_constant(self.campaign, self.client_data), after we have the instance we call the applies() function if any of the rules return false we break out of the loop and return False to the perform function, if none of the rules return false then we’ll be returning True to the function. We are able to do this regardless of the rule that’s being evaluated because all rules follow the same interface.

Final thoughts for this will be that we should always be testing our code, it works as a design tool, as documentation and also to give us peace of mind before we deploy to production. Another thing to keep in mind is to never be afraid to ask your coworkers for opinions, always keep an open channel for conversation around the ideas on how to solve a problem. Lastly inform yourself about software patterns and principles that will guide you to be a better developer, read blogs, books, talk to other developers, attend meetings, join developer groups, give talks and in general be involved in the overall developer community, you’ll always learn something new.

If you have any comments or questions feel free to reach out on twitter at @fcastellanos.

The Adapter pattern acts as a bridge between two incompatible classes by “adapting” the functionality of one class into the other via an interface. One of the most popular examples of the Adapter Pattern is how different programming languages uses Adapter classes to access a database, it’s very common to se MySqlDataAdapter, PgSqlDataAdapter, etc, what these adapters are doing is creating a bridge or “adapting” into the specificities of each database engine so you don’t have to worry about those minor details or worse having to create your own adapters.

Now let’s look at an example with an electrical socket analogy.

class EuropeanSocketInterface:
    def voltage(self): pass
    def live(self): pass
    def neutral(self): pass
    def earth(self): pass

# Adaptee
class Socket(EuropeanSocketInterface):
    def voltage(self):
        return 230
    
    def live(self):
        return 1
    
    def neutral(self):
        return -1
    
    def earth(self):
        return 0
    
# Target interface
class USASocketInterface:
    def voltage(self): pass
    def live(self): pass
    def neutral(self): pass

# The Adapter
class Adapter(USASocketInterface):
    __socket = None

    def __init__(self, socket):
        self.__socket = socket
    
    def voltage(self):
        return 110
    
    def live(self):
        return self.__socket.live()
    
    def neutral(self):
        return self.__socket.neutral()

# Client
class ElectricKettle:
    __power = None

    def __init__(self, power):
        self.__power = power
    
    def boil(self):
        if self.__power.voltage() > 110:
            print("Halt and catch fire!")
        else:
            if self.__power.live() == 1 and self.__power.neutral() == -1:
                print("Coffee time!")
            else: 
                print("No power.")

In this example we have a socket which is European type (EuropeanSocketInterface) and we have a Kettle which have an electrical plug of the type we use in the US (USASocketInterface), now in order for us to be able to plug the Kettle in the European style socket we need to use an adapter (Adapter) that will use the USASocketInterface, if you check both socket interfaces the European and the USA we see that both have similar interface (voltage, live, neutral).

Now let’s see the example.

socket = Socket()
adapter = Adapter(socket)
kettle = ElectricKettle(adapter)

kettle.boil()

The output being

Coffee time!

Here you can see the ElectricKettle class using the adapter (Adapter) to adapt to the European style socket. And if you check the Adapter we can see that we’re really only overriding the value of voltage with 110 which is what the ElectricKettle use, in the case that it’s higher than 110 it will "Halt and catch fire!", on the other hand if everything else is correct it’s going to be "Coffee time!" or "No power.".

And this is it for the Adapter pattern hope it’s clear enough, if you have any comments or questions feel free to reach out on twitter at @fcastellanos.

I’ll explain it with an analogy of the state of a computer.

class ComputerState(object):
    name    = "state"
    allowed = []

    def switch(self, state):
        # Switch to new state
        if state.name in self.allowed:
            print("Current:", self, " => switched to new state", state.name)
            self.__class__ = state
        else:
            print("Current:", self, " => switching to", state.name, "not possible.")
    
    def __str__(self):
        return self.name

class Off(ComputerState):
    name = "off"
    allowed = ['on']

class On(ComputerState):
    # State of being powered on and working
    name = "on"
    allowed = ['off', 'suspend', 'hibernate']

class Suspend(ComputerState):
    # State of being in suspended mode after switched on
    name = "suspend"
    allowed = ['on']

class Hibernate(ComputerState):
    # State of being in hibernation after powered on
    name = "hibernate"
    allowed = ['on']

class Computer(object):
    #  A class representing a computer

    def __init__(self, model='HP'):
        self.model = model
        # State on the computer - default is off.
        self.state = Off()
    
    def change(self, state):
        # Change state
        self.state.switch(state)

There’s a lot going on here so let me break it down. First we see the ComputerState class which is the one that will orchestrate the switching of the state by checking if we’re allowed to change the state of the process or not, in this case it’s doing the checking/switching via the switch function.

Then we also have the Off, On, Suspend and Hibernate classes which inherits from the ComputerState class, each of those state classes have their own name and allowed properties, the name property is self explanatory but the allowed property is a list of allowed states to switch from the current state of the state machine.

Finally we have the Computer class which have two properties, model that specifies the model of the computer, and state that indicates the state of the computer via a state machine, at the beginning the computer’s state will be Off, the Computer class also defines the change function which takes the state that we want to switch to. If we look closer to the change function in the Computer class it’s calling the switch function in the current state instance, now going back to the ComputerState class we can see that the switch function checks if the state that we want to switch to is in the allowed list, if it is in the allowed list we switch to that state if it isn’t we print out that switching to that state it’s not possible.

This pattern might take a bit of upfront work to fully define the states and the rules but once you define them it’s going to make your life easier and it will also avoid having a bunch of if statements checking rules and states.

As always if you have any comments or questions feel free to reach out on twitter at @fcastellanos.

This pattern can be really useful because we could build a workflow where we can have the Publisher publish to the subscribers that an image have been downloaded and then have the subscribers transform that image into multiple formats. This pattern also allows us to extend features via “plug n play” without the other subscribers knowing, we can also remove subscribers without affecting the whole workflow.

Here’s how you’d build the Observer pattern in Python:

class Subscriber:
    def __init__(self, name):
        self.name = name
    
    def update(self, message):
        print('{} got message "{}"'.format(self.name, message))

class Publisher:
    def __init__(self):
        self.subscribers = set()
    
    def register(self, who):
        self.subscribers.add(who)
    
    def unregister(self, who):
        self.subscribers.discard(who)
    
    def dispatch(self, message):
        for subscriber in self.subscribers:
            subscriber.update(message)

In this example you see the Subscriber class that have a property name and an update function that the subscriber will call whenever it publishes a message. On the other side we have the Publisher class that have a subscribers property which is going to hold a list of subscribers that it needs to send messages to, it also have a register and unregister functions to add or remove subscribers from the list. Finally the Publisher class also have a dispatch function which is the one responsible to receive a message and passing that message to all of its subscribers.

This is how you’d run this

pub = Publisher()

juan = Subscriber('Juan')
julia = Subscriber('Julia')
jaime = Subscriber('Jaime')

pub.register(juan)
pub.register(julia)
pub.register(jaime)

pub.dispatch("It's lunchtime!")

Juan got message "It's lunchtime!"
Julia got message "It's lunchtime!"
Jaime got message "It's lunchtime!"

pub.unregister(juan)

pub.dispatch("Time for dinner")

Julia got message "Time for dinner"
Jaime got message "Time for dinner"

This is another simple pattern that can go a long way and not difficult to understand and implement.

If you have any comments or questions feel free to reach out on twitter at @fcastellanos.

Happy Coding!

This pattern is great because it reduces complexity when you need to instantiate objects which have the same behavior so you can focus the business side of the application.

Here’s an example.

class Animal(object):
    html = ""
    def make_sound(self):
        return self.html

class Cat(Animal):
    html = "meow meow"

class Dog(Animal):
    html = "woof woof"

class Lion(Animal):
    html = "roaaaaar"

class AnimalFactory():
    def create_animal(self, typ):
        targetclass = typ.capitalize()
        return globals()[targetclass]()

The Animal class will act as the interface or the behavior for the Cat, Dog and Lion classes which are technically inheriting the behavior from Animal, in this case all classes inheriting from Animal all will have the make_sound function. Now for the good stuff, the AnimalFactory class will be the one responsible for instantiating the Cat, Dog and Lion classes.

animal_factory = AnimalFactory()
animals = ['cat', 'dog', 'lion']
for a in animals:
    animal_instance = animal_factory.create_animal(a)
    print(animal_instance.make_sound())

And the result should be this

meow meow
woof woof
roaaaaar

If you see you don’t really know what class the animal_instance belongs to, you just know that it should have a make_sound function.

And that’s it, this is a simple but a very powerful pattern that it does not take a lot of effort to start using it.

If you have any comments or questions feel free to reach out on twitter at @fcastellanos.

Happy Coding!