Forem: Incubyte

Learnings From Clean Code

Abhishek Keshri — Mon, 27 Mar 2023 05:00:00 +0000

Learnings from Robert “Uncle Bob” Martin

Robert Martin, fondly known as “Uncle Bob” in software community, is a software engineer and more famously an author and one of the founding fathers of software movements like software craftsmanship, agile methodology, and test-driven development. Some of his most famous works include Clean Code, The Clean Coder, Clean Architecture, and Clean Agile. Martin is also a frequent instructor, with the ability to boil down difficult topics into a simple, understandable format, along with occasional cheeky humor.

One of the most striking qualities of Martin – in all of his writing and lectures, is that nowhere does he claims to have a full-proof solution or a doctrine that could solve all software development problems. He acknowledges that the teachings and lessons are ones he acquired from his 40+ years of experience and encourages the reader to validate the “time-testiness” and accuracy of those lessons. One of the qualities of a software craftsperson, according to Martin, is adapting to changing times and let go of irrelevant principles.

This article can be thought of as a list of learnings from the book Clean Code. By no means this is an exhaustive list, but rather a list of all lessons which had the most impact (personally) while reading.

1. The Meaning of Clean Code

Uncle Bob starts off the book by exploring the term itself.
Without stating a single clear-cut definition, he presents various definitions from prominent computer scientists.
Reading which, one can figure out common themes and characteristics that define 'Clean Code' being – readability, straightforward, maintainable, reads like prose, and doesn’t contain duplication.

Core learning: Clean code has more to do with writing understandable code which is both easily maintainable and changeable, versus clever (read complicated) logic which is harder to maintain.

2. Duplication is the Evil

Uncle Bob goes on a length about various characteristics of bad code.
Amongst them, code duplication holds a special spot, because majority of code problems have their origins linked to duplication.
It has inspired many coding patterns, techniques, and ideologies.

For example, database normalization techniques (1NF, 2NF, 3NF…) by Codd are ultimately about removing redundancy in database design.

In fact, paradigms like OOP, AOP, COP, and Structured Programming, are all different ways to deal with duplication.
Duplications can be of different types, the most obvious one being repetition of the same lines of code.
A more subtle form of duplication includes a chain of if/else statements that test the same conditions over and over.

In some cases, embracing duplication might be the way to go. An example would be hitting a deadline.
An example would be hitting a deadline.
If duplicating code helps in achieving a target, the pragmatic course of action would be to allow duplication and treat it as a technical debt (that needs to be addressed later).
The only risk with this approach is that the duplication is never removed, and it keeps getting accumulated.

Core learning: While writing a piece of software, be mindful of code duplication.

3. One and Only One

Similar phrases appear quite often in the book –

“Classes should have only one reason to change”

“A single source file should contain only one language”

“Functions should descend only one abstraction level”

“One assert statement per test”

Core learning: Doing more than one thing at a time, or trying to “juggle” multiple things will ultimately lead to poor code quality and make the code less flexible. By making sure that we keep things simple, it makes life easier for the entire team.

4. F.I.R.S.T Principle for Tests

Writing tests is often seen as something which takes a lot of time and doesn’t serve a real purpose.

“I wrote the code, I know it works… Don’t you trust me?”

However, that’s far from truth, writing tests unravels many aspects we would have not uncovered otherwise.
A good test suite could be a challenge to write, but the F.I.R.S.T. principle can help us out:

Fast – Tests should run fast. If they are slow, nobody would want to run them.
Independent – Each test should be independent of other tests, and they should be isolated enough to be run individually.
Repeatable – They should be environment-independent. Should run on dev, prod, QA, etc.
Self-Validating – The test should either pass or fail. Anything in between means more time would be wasted on reading log messages.
Timely – Unit tests should be written before writing the production code. Tests serve their purpose only when written in a timely manner.

Core learning: Having a good test suit is important.

5. Clean Code and Concurrency

Coding is hard enough without concurrency.
It has its unique challenges – complexity, overhead, non-repeatability of bugs, etc. and as such it requires a fundamental change in the design strategy.
That being said, some principles must be followed if we want to include concurrency in our system:

Single Responsibility Principle – Keep concurrent code separate from non-concurrent code
Encapsulation – Limit access to the shared data
Know the Library – Understand the concurrency library inside-out
Keep It Simple, Silly – Make sure that non-concurrent code runs and functions properly first
Platforms – Run your concurrent code on different platforms
Go back to the basics – Problems like Consumer-Producer, Dining Philosophers, and Reader-Writers are a good start for selecting an execution method for concurrent code

Core learning: Follow best practices.

Conclusion

This article is a condensed summary of the complete book, highlighting some of the more essential & impactful principles.
The underlying principles remain somewhat same throught the book – a combination of the following principle - Do Not Repeat (DRY), Keep it Simple Silly (KISS) and You Ain’t Gonna Need It (YAGNI).

This book has a lot more to offer including error handling, writing effective comments, meaningful comments, unit testing, etc.
We definitely recommend reading this by yourself for better insights!

Like what you read? then visit our site to learn more.

We are also looking for awesome people to work with, if you'd like to be a part of our team join us!

Five Git Tricks Every Dev Must Know

Abhishek Keshri — Mon, 13 Feb 2023 05:00:00 +0000

Git is the most widely used version control system in the world and it is something that every Software Craftsperson should master.

In this article, we'll be going through five git tricks that will make your software crafting easier.

Here are the tricks we'll be covering in this article:

Quickly set up Git SSH credentials with GitHub CLI

The first thing you want to do before trying out these tricks is to set up git and its credentials.

If you have set up git with ssh credentials earlier then you definitely know how cumbersome the entire process can be, for those who are unaware here's a very brief overview:

Setup your .gitconfig with user name and mail
Generate a new ssh key
Add the ssh key to GitHub

But wait, there's a smarter (and foolproof) way of setting up git with your GitHub credentials. All you need is the GitHub CLI installed on your system.

After that, it's as simple as:

gh auth login

This will take care of all the steps mentioned above + more.

Create a new branch and track it with remote

Now that we are all set up with git credentials and have cloned the repo, it's time to create a new branch and start working on that new feature.

But wait, how do we do all this?

First, you create the branch in your local

git checkout -b <branch> # old way
git switch -c <branch> # new way

Then to track this branch with remote

git push -u origin <branch>

This will push the branch to remote and it will be available for everyone to pull from.

Quickly test changes across branches with the help of stash

Let's say you want to try out a new config that you have added to your branch and have tested successfully, but before committing you want to make sure that this config change doesn't break the main branch.

How do you do this?

Here's one way you can quickly do that using stash:

# Stash your current changes
git stash push
# Or if you have multiple stashes
git stash push -m "configs" # Saves stash with an identifier

Now you can switch to main and test your changes

git switch main # Switch to the main branch

git stash apply # Applies most recent stashed changes without removing them from stash
# Or if you have multiple things in the stash
git stash list # Get all stashes with index
git stash apply stash@{<index>} # Apply stash at <index>

Once you are done with your changes switch back to the previous branch and continue

git switch - # Switch to the previous branch
git stash pop # Applies changes and removes the most recent stash

Now you can commit your changes and push them to remote without worrying about the main branch.

Split one large branch into multiple

While working on the feature, you got carried away and accidentally added commits for the next feature to the same branch, and now you want to split the branch into multiple branches.

Here's how you can do that:

Identify the commit hash from where you want to split the new branch using git log, you can also use the following command for prettier logs.

git log --oneline --decorate --graph

Create the new branch, but don't check out yet, the new-branch should point to your current branch's HEAD

git branch <new-branch>

Hard reset the current branch to the splitting commit

git reset --hard <commit-hash>

Force push the updated current branch head to remote

git push --force-with-lease

Switch to new-branch and add it to remote

git switch <new-branch>
git push -u origin <new-branch>

You are done!

To create multiple splits, use git rebase --onto to link the branches.

Delete a branch from remote

What if one of the branches is no longer needed or what if you made a typo while creating the branch.

You definitely want to delete the branch from remote right?

Here's how you can do that:

Delete branch from local

git branch -d <branch>
git branch -D <branch> #Force delete

Delete branch from remote

git push origin :<branch>

This will delete the branch from local and remote.

Bonus: Use git aliases to make your life easier

Alright! you made it to the end of this article and you have already seen a lot of git commands.

But how do you remember all this? Easy!

You can use git aliases to make your life easier. You can add these aliases to your .gitconfig file.

[alias]
    a = add
    c = commit
    l = pull
    p = push
    co = checkout
    br = branch
    st = stash
    sw = switch

Or you can use the following commands to add these aliases to your current shell config file (~/.bashrc,~/.zshrc, etc):

alias g='git'
alias ga='git add'
alias gc='git commit -m'
alias gl='git pull'
alias gp='git push'
alias gco='git checkout'
alias gbr='git branch'
alias gst='git stash'
alias gsw='git switch'

Add as many aliases as you want, saving these few keystrokes will make your life much easier in the long run.

More to explore

This is only the tip of the iceberg when it comes to git, there are many more awesome things you can do with it. Go ahead and explore!

We will be covering more commands and tricks in the future.

Like what you read? then visit our site to learn more.

We are also looking for awesome people to work with, if you'd like to be a part of our team join us!

Rails RESTful API, Outside in TDD

Abhishek Keshri — Mon, 30 Jan 2023 02:00:00 +0000

There is always a disciplined way to do things

I was waiting for the coffee dispenser to finish filling up my cup and my mind started wandering. Suddenly, I felt this rush. Was it a sense of pride? Could be. I had, just a few minutes ago, been able to solve a race-condition problem that was bugging me for a while. Sipping at the coffee I could see out the glass door, that it was raining. This is a good moment, I thought to myself. One thing I didn’t want to think about were the open tickets in the backlog. Unchallenging and menial, they bored me. With soothing sounds of the rain in the background and the warmth of the fuel of the Gods, I was now thinking of ways I could avoid working on them!

I had a train to catch, later that evening to travel to “a remote place with some historical significance”. This workation was in planning for months, so I was excited about it! I scoped out my work for the week I was travelling; a small RESTful API (Redacted to a Todo), of course I thought it to be menial as I went over it. All I wanted to do was to be done with so I could spend more time exploring.

Coming up with the fix for the race condition took a while, which meant, I had little to no time to pack and make sure that I didn’t miss my train! So, I called home to get some help gathering my things to shove into my backpack. Tough times call for desperate measures, folks!

The train-ride to my destination lasted the entire night and day. The relief of finally getting off and checking-in to my place of stay was short lived though, because soon enough, I realized that I’d completely forgotten to pack my dental kit. And thus began the wait for the stores to open and realization hit that even a checklist of essentials would have made my life easier!

Over breakfast, while chewing on a piece of bread I remember thinking to myself that the success of this workation depended on my ability to find a balance between finishing work stuff and finding the time to relax and enjoy my surroundings. I took a sip of coffee to help wash down the food and also cement that fact in my mind.

I had quickly set up the Rails API only project.

Rails is a web-application framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern.



To start a new rails api only project
rails new project_name --api

Active Record

Generated an active-record, if no data type is provided string is considered as default



rails generate model Todo title description done:boolean

rails db:create
rails db:migrate

In Active Record, objects carry both persistent data and behavior, which operates on that data.
Rails ORM(object relational mapping) connects objects of an application to tables in a relational database management system.

Spent few extra hours that night and finished the work.

I woke up the next morning, feeling a little tired and soon figured out that my memory had betrayed me yet again in my packing frenzy as I’d forgotten to bring along my medication as well. The worst part? I couldn’t get it in that town.
Oh well, couldn’t do much about it now. So, I set about reviewing the major functionalities [the challenging parts] of my project before I had to submit it. And soon found out that the day was going to get worse. The model accepted inputs for the title as an empty string, which it shouldn't have, and sure enough I found a few other minor issues soon after. How many more of these errors were there!? I started worrying

Gut feelings can be good sometimes, but it wasn’t working out for me right now so I set to work on creating a safety-net for the RESTful API just like the check-list I thought of having for the backpack.

When is the right time to write unit tests

RSpec is a domain-specific language testing tool written in the programming language Ruby to test Ruby code.

Gemfile



group :development, :test do
  gem 'rspec-rails' # testing framework for rails
end
$ bundle install
`$ rails generate rspec:install`
This generated the configuration files (.rspec, spec/spec_helper.rb, spec/rails_helper.rb)



Included the following gems that come in handy while writing unit test cases
group :test do
  gem 'database_cleaner' # It can be used to ensure a clean slate for testing
  gem 'factory_bot_rails' # To create test data
  gem 'faker' # To generate fake data for fields
  gem 'shoulda-matchers' Reduces error prone lengthy specs to one-liners.
end

Configure the added gems by adding their configuration to spec/rails_helper.rb



# Database cleaner requirement
require 'database_cleaner'
# shoulda matchers configuration
Shoulda::Matchers.configure do |config|
 config.integrate do |with|
   with.test_framework :rspec
   with.library :rails
 end
end

RSpec.configure do |config|
  #Factory Bot configuration
  config.include FactoryBot::Syntax::Methods
  #Database cleaner configuration
  config.before(:suite) do
    DatabaseCleaner.clean_with(:truncation)
    DatabaseCleaner.strategy = :transaction
  end

  config.around(:each) do |example|
    DatabaseCleaner.cleaning do
      example.run
    end
  end
end

Test Data Preparation For Controller Tests



# Created a file todo.spec inside factories folder in spec directory.

FactoryBot.define do
    factory :todo do
        title {Faker::Name.name}

        description {Faker::Lorem.word}
    end
end

**Active Record Specs**
RSpec.describe Todo, type: :model do

 # Validation tests
 it { should validate_presence_of(:title) }
 it { should validate_length_of(:title).is_at_least(3)}

I wrote unit-tests for the Active record model followed with tests for the controller.
Very soon into creating the safety-net, towards the end of that day, I’d realized that I’d written specs that affirmed that the code that’d been written was correct.

Just like picking up an item from the backpack and checking it off in the checklist and placing it back in the backpack. Completely redundant!

Well, it was too late to write unit tests now.

A minute spent on planning can save an hour of work

I had to take a break from it all to digest the fact that all my effort had gone down the drain and ended up in a fiasco. This wasn’t the quality that was expected of me and by extension my company!
Never would I’ve imagined that the work that I considered to be menial would end up posing such a challenge to me!
It is at that moment that I made up my mind to re-build the application from scratch and do it the right way by writing specs first.
I did not want to revisit the realization of it being "too late".

Never underestimate the impact just a few minutes of planning can make.

Did some research and found out the basic checks my code was supposed to pass for optimum results.

[x] Fulfill Requirements without errors.
[x] The code should be maintainable and scalable.
[x] The code should adhere to Single Responsibility Principle(SRP).

Test-driven development is a software development process relying on software requirements being transformed to test cases before software is fully developed.

Write production code only to pass a failing unit test.
Write no more of a unit test than enough to fail.(RED)
Write no more production code than necessary to pass the one failing unit test.(GREEN)

A quick glance at my previous piece of code tells me that is neither maintainable, nor scalable and it also violates one of the basic SOLID principles, which is SRP.

Single Responsibility Principle states that every module of class should have one responsibility in a program.

This is what my controller’s create action (to save a todo) looked like. Everything was in the controller - be it Rails specific code, active record specific code or application logic code.



def create
    todo_params = params.require(:product).permit(:title, :price, :published)
    todo = Todo.new(todo_params)
    if todo.save
        render json: todo, status: :created
    else
        render json: todo.errors, status: :unprocessable_entity
    end
end

Need to fish out the application logic and active record code from the controller



def create
    todo_params = params.permit(:title, :description)
    result, status = create_todo(todo_params)
    render json: result, status:status
end

def create_todo(todo_params)
    todo= new_todo(todo_params)
    if(save_todo(todo))
        return todo, :created
    else
        error=Hash.new
        error["message"] ="Invalid Input"
        return error, :unprocessable_entity
    end
end

def new_todo(todo_params)
    Todo.new(todo)
end
def save_todo(todo)
    todo.save
end

The above three methods need to be shifted into their own respective independent classes, and their instances should be invoked from the dependent classes and to reduce the coupling between dependent classes, need to create the instance at the class level and provide it to the methods.



class TodosController < ApplicationController
    def initialize(runner=CreateRunner.new)
        @runner = runner
    end

    def create
        todo_params = params.permit(:title, :description)
        result, status = @runner.create_todo(todo_params)
        render json: result, status:status
    end
end


class CreateRunner
    def initialize(repository = Repository.new)
        @repository = repository
    end

    def create_todo(todo_params)
        todo= @repository.new_todo(todo_params)
        if(@repository.save_todo(todo))
            return todo, :created
        else
            error=Hash.new
            error["message"] ="Invalid Input"
            return error, :unprocessable_entity
        end
    end
end


class Repository
    def new_todo(todo_params)
        Todo.new(todo)
    end

    def save_todo(todo)
        todo.save
    end
end

Simplicity is key

Where should I start first? Model specs, Controller specs, Runner specs or Repository Specs? This question has to be responded to every time a new resource or functionality is addressed.

In 1952, William Edmund Hick and Ray Hyman a pair of psychologists conducted an experiment to examine the relationship between the number of stimuli present and an individual’s reaction time to any given stimulus. The result was obvious, the more options the user had to choose from, the longer it took them to decide on which one to interact with.

Outside-In Test Driven Development solves this problem.

Using this approach I started with the feature or end point specification and worked my way inwards towards the repository layer.
This test dropped me to the next layer, Controller, whose implementation is written after writing a spec for it.
Fixing the controller spec should have fixed the end point specification, but it dropped further down to the next layer, Runner (which contained the application login), whose implementation is written after its spec.

The model is independent, and the spec for it can be written independent of the above flow.



Failing Test Case:
RSpec.describe "Todos", type: :request do
  context 'with valid request attributes will create a Todo and return 201' do
    it 'returns status code 201' do
      post '/todos', params: {title: "Todo-1", description:'First todo' }, as: :json
      expect(response).to have_http_status(201)
    end
  end
end

$ rspec

running the above specification resulted in the error

RED:
  1) Todos with valid request attributes will create a Todo and return 201 
     Failure/Error: post '/todos', params: {title: "Todo-1", description:'First todo' }, as: :json

     ActionController::RoutingError:     

I need not ponder what to do next as the spec failure suggested what needed fixing.

GREEN:
    found routes.rb in app/config directory and added the route as following

    resources :todos, only: %i[create ]

Running the test after fixing it resulted in another error that reads



 $ rspec

      Failure/Error: post '/todos', params: {title: "Todo-1", description:'First todo' }, as: :json

     ActionController::RoutingError:
       uninitialized constant TodosController

The fix would be to add a new controller but according to Test driven development we need to have the test file before the Controller itself.
I created a new folder in the spec directory and named it controllers and added a spec file and named it todos_controller_spec.rb

The primary goal of writing this spec file is to check if controller exists, and the secondary goal is to check if it can invoke the instance of the runner, which serves the application/feature logic.

At this moment neither the controller exists, nor the runner exists, for the controller runner is an external class and to check if it can invoke I had to create a double for the runner and make the double react, as if it is the original, when it is called.
This concept is also called mocking.



Failing Test case:
RSpec.describe "Todos", type: :controller do
    describe "Controller" do
        it "invokes the instance of CreateRunner successfully" do
            todo = Todo.new({"title": "Todo-1", "description":'First todo' })
            mock = double("TodosRunner")
            expect(mock).to receive(:create_todo).with(todo)
            create_new_todo = TodosController.new(mock)
            create_new_todo.create
        end
    end
end

RED:
    1) Todos Controller invokes the instance of Create_Runner successfully
     Failure/Error: create_new_todo = TodosController.new(mock)

     ArgumentError:
       wrong number of arguments (given 1, expected 0)
GREEN:
    class TodosController < ApplicationController
        def initialize(runner="")
            @runner = runner
        end
    end

Run the tests



$ rspec

RED:
     1) Todos Controller invokes the instance of CreateRunner successfully
     Failure/Error: create_new_todo.create(todo)

     NoMethodError:
       undefined method `create` for #<TodosController:0x0000000000bba8>
GREEN:
    def create

    end



$ rspec

RED:
  1) Todos Controller invokes the instance of Create_Runner successfully
     Failure/Error: allow(create_new_todo).to receive(:todo_params).and_return(params)
       #<TodosController:0x000000000069a0> does not implement: todo_params

GREEN:
    def todo_params

    end



$ rspec

RED:
  1) Todos Controller invokes the instance of Create_Runner successfully
     Failure/Error: expect(mock).to receive(:create_todo).with(params)

       (Double "TodosRunner").create_todo({:description=>"First todo", :title=>"Todo-1"})
           expected: 1 time with arguments: ({:description=>"First todo", :title=>"Todo-1"})
           received: 0 times

GREEN:
    def create
        @runner.create_todo
    end




$ rspec

RED:
  1) Todos Controller invokes the instance of Create_Runner successfully
     Failure/Error: @runner.create_todo()

       #<Double "TodosRunner"> received :create_todo with unexpected arguments
         expected: ({:description=>"First todo", :title=>"Todo-1"})
              got: (no args)

GREEN:
    def create
        @runner.create_todo(todo_params)
    end
    def todo_params
        params.permit(:title, :description)
    end



$ rspec

RED:
  1) Todos with valid request attributes will create a Todo and return 201 
     Failure/Error: @runner.create_todo(todo_params)

     NoMethodError:
       undefined method `create_todo` for "":String

GREEN:
    def initialize(runner = TodoRunner.new)
        @runner = runner
    end

With this all the controller specs were fixed before moving further I had ran the request spec to check if fixing the controller had fixed the request spec.
The request spec is not fixed, but I got my next direction to move forward.



$ rspec  - The request spec pops the following error.

RED:
  1) Todos with valid request attributes will create a Todo and return 201
     Failure/Error:
       def initialize(runner = TodosRunner.new)
           @runner = runner

     NameError:
       uninitialized constant TodosController::TodosRunner

Created a spec file for the TodosRunner before creating the class TodosRunner by adding the file to the runners folder in the spec directory.

The basic responsibility of this class is similar to the controller in terms of invoking the instance of the class it is dependent on, which is to invoke the Repository Class.



GREEN:
    I followed a similar process here, as I did to fix the controller.



Failing Test Case:
RSpec.describe "Todos", type: :runner do
    describe "Runner" do
        it "invokes the instance of Repository successfully" do
            todo = Todo.new({"title": "Todo-1", "description":'First todo' })
            mock = double("Repository")
            expect(mock).to receive(:new_todo).with(todo)
            create_new_todo = Respository.new(mock)
            create_new_todo.new_todo(todo)
        end
    end
end

Testing the Todos Runner spec resulted in the following error which was expected

$ rspec
RED:
  1) Todos Controller invokes the instance of Create_Runner successfully
     Failure/Error: create_new_todo = TodosRunner.new(mock)

     NameError:
       uninitialized constant TodosRunner

GREEN:
    Created new file todos_runner.rb in runners folder of app directory.



$ rspec
RED:
 1) Todos  Runner  invokes the repository method new_todo
     Failure/Error: todosRunner.create_todo(new_params)

     NoMethodError:
       undefined method `create_todo` for #<TodosRunner:

GREEN:
    def create_todo

    end



$ rspec

RED:
  1) Todos  Runner  invokes the repository method new_todo
     Failure/Error:
       def create_todo

       end

     ArgumentError:
       wrong number of arguments (given 1, expected 0)

GREEN:
    def create_todo(add_params)

    end



$ rspec

RED:
  1) Todos  Runner  invokes the repository method new_todo
     Failure/Error: expect(mock).to receive(:new_todo).with(new_params)

       (Double "TodosRepository").new_todo({:description=>"First todo", :title=>"Todo-1"})
           expected: 1 time with arguments: ({:description=>"First todo", :title=>"Todo-1"})
           received: 0 times

GREEN:
    def create_todo(add_params)
        @repo.new_todo(add_params)
    end

Now that the runner spec is fixed, so has run the request spec to check if it has been fixed too?



RED:
  1) Todos with valid request attributes will create a Todo returns status code 201
     Failure/Error: @repo.new_todo(add_params)

     NoMethodError:
       undefined method `new_todo for` "":String

GREEN:
    def initialize(repo = TodosRepository.new)
        @repo = repo
    end



$ rspec

RED:
1) Todos with valid request attributes will create a Todo returns status code 201.
     Failure/Error:
       def initialize(repo = TodosRepository.new)
           @repo = repo

     NameError:
       uninitialized constant TodosRunner::TodosRepository

The repository has no further interactions with an external client and all the methods the repository would include querying the ActiveRecords and testing them would be testing the ActiveRecord API, which must have been thoroughly tested before becoming available.

Created a repository repository.rb and added a method that handles creating new todo



GREEN:
    class TodosRepository
        def new_todo(add_params)
            Todo.new(add_params)
        end
    end

$ rspec

RED:
  1) Todos with valid request attributes will create a Todo and returns status code 201
     Failure/Error: expect(response).to have_http_status(201)
       expected the response to have status code 201 but it was 204

The application logic has not been implemented yet, to save the todo that has been initialized and return the saved todo.

Wrote a spec on Runner class to save the initialized todo and return it back.



Failing Test Case:
        it " invokes the repository method new_todo" do
            save_params = {title: "Todo-1", description:'First todo' }
            todo = Todo.new(save_params)
            mock = double("TodosRepository")
            allow(mock).to receive(:new_todo).and_return(todo)
            expect(mock).to receive(:save_todo).with(todo)
            todosRunner = TodosRunner.new(mock)
            todosRunner.create_todo(save_params)
        end

RED :
  1) Todos  Runner  invokes the repository method new_todo
     Failure/Error: expect(mock).to receive(:save_todo).with(todo)

       (Double "TodosRepository").save_todo(#<Todo id: nil, title: "Todo-1", description: "First todo", created_at: nil, updated_at: nil>)
           expected: 1 time with arguments: (#<Todo id: nil, title: "Todo-1", description: "First todo", created_at: nil, updated_at: nil>)
           received: 0 times

GREEN:
    def create_todo(add_params)
        todo =@repo.new_todo(add_params)
        @repo.save_todo(todo)
    end



Failing Test Case:
        it " calls save_todo to save initialized todo and returns created" do
            save_params = {title: "Todo-1", description:'First todo' }
            todo = Todo.new(save_params)
            todosRunner = TodosRunner.new
            todo, status = todosRunner.create_todo(save_params)
            expect(status).to eq(:created)
            expect(todo["id"]).to eq(1)
        end
$ rspec

RED:
  1) Todos  Runner  calls save_todo to save initialized todo and returns created
     Failure/Error: expect(status).to eq(:created)

       expected: :created
            got: nil

GREEN:
    def create_todo(add_params)
        todo =@repo.new_todo(add_params)
        @repo.save_todo(todo)
        return todo, :created
    end

$ rspec

The Request Spec still returns 204 whereas it expects 201 this is because the controller has not rendered the output it received.



Failing Test Case:
        it "invokes the instance of Create_Runner successfully and renders the json" do
            params = {title: "Todo-1", description:'First todo' }
            mock = double("TodosRunner")
            expect(mock).to receive(:create_todo).with(params)
            create_new_todo = TodosController.new(mock)
            allow(create_new_todo).to receive(:todo_params).and_return(params)
            allow(create_new_todo).to receive(:json_result).and_return(true)
            create_new_todo.create
        end

$rspec

RED:
 1) Todos Controller invokes the instance of Create_Runner successfully and renders the json
     Failure/Error: allow(create_new_todo).to receive(:json_result).and_return(true)
       #<TodosController:0x000000000069f0> does not implement: json_result
GREEN:

    def create
        result, status = @runner.create_todo(todo_params)
        json_result(result, status)
    end
    def json_result(object, status)
        render json: object, status:status
    end

$ rspec

All Greens

I went on to write the request spec(todos_spec.rb) that expects 422 when the title, which is a mandatory field, is not passed.



Failing Test Case:

  context 'with invalid request attributes ' do

    it 'returns status code 422' do

      post '/qwerts', params: {title: "", description:'First todo' }, as: :json

      expect(response).to have_http_status(422)

    end

  end

$ rspec

RED:

  1) Todos with invalid request attributes returns status code 422

     Failure/Error: expect(response).to have_http_status(422)

       expected the response to have status code 422 but it was 201



The fix has to be done at Runner layer as this layer contains the application logic.

todos_runner_spec.rb

Failing Test Case:

        it " returns unprocessable entity when title is not passed" do

            save_params = {title: "", description:'First todo' }

            todo = Todo.new(save_params)

            todosRunner = TodosRunner.new

            todo, status = todosRunner.create_todo(save_params)

            expect(status).to eq(:unprocessable_entity)

            expect(todo["message"]).to eq("Invalid input values")

        end

Fix:

    def create_todo(add_params)

        todo =@repo.new_todo(add_params)

        if(@repo.save_todo(todo))

            return todo, :created

        else

            error = Hash.new

            error["message"] = " Invalid input values"

            return error ,:unprocessable_entity

        end

    end

 $ rspec

All Green

All Green - quite a wonderful sight!

I was so immersed in conversing with rspec while developing this application that I kind of got distanced from reality. I felt like I’d embodied this character in a play that was being watched and I was to only act out my lines on cue lest I’d mislead the audience. Rspec called the shots here!

And there you have it, folks! I finally ended up finishing the assignment and got it ready to be handed over to the client!
With a couple of days left of my stay, I started out on my journey exploring the unknown!
At one such moment, I was looking at a tomb over at the distance when dreadful thoughts started to creep back in! Thoughts of possible errors in the app! But, I put all of that to rest as I’d let the tests do their magic now.

Now, with my mind at ease and feeling a sense of achievement, the sights all around seemed a bit more pleasant!

Like what you read? then visit our site to learn more.

We are also looking for awesome people to work with, if you'd like to be a part of our team join us!

Learnings From Terraform

Abhishek Keshri — Mon, 16 Jan 2023 08:44:37 +0000

Preface

Terraform is infrastructure as a code. I know it is a fancy word, here is the meaning.

If you want to create one virtual machine in AWS, you go to their website and click a few buttons, and it creates the instance. What if there are 15 such VMs and all have some security configuration, doing it manually is not only tedious but erroneous as well.

Terraform provides a nicer way to manage infrastructure in code. The following example creates a virtual machine in AWS

resource "aws_instance" "app_server" {
  instance_type = "t2.micro"
}

It will create, update, or delete resources using simple commands

Goal

After using terraform in multiple projects, here are my learnings from experience.

It can be used as best practice as well.

Feel free to add yours.

State in cloud

Terraform stores its 'state' in a local file. The state is a list of created resources using Terraform.

In the above example, it will make an entry in the state file with aws_instance with ID generated by AWS. So when we try to apply the configuration again, it won't create already created resources.

Since the default way of storing the state is in a local file, most beginners don't change that. That is highly risky.

We should always store the state in cloud file storage. For example, for AWS store the state in 's3', for Azure store in 'Azure Blob Storage'. The reason behind that is, if your local machine got crashed, the state is always stored in the cloud, somewhere safe.

Store and run as a pipeline

Always run the Terraform commands from the pipeline and not from your local machine.

At least transactional commands like apply (to create/update) and destroy (to delete!)

The idea behind Terraform is to have 'infrastructure as code'. Since it is a 'code' it needs to be committed inside a repository.

Version number is mandatory

Always specify a version number for any resource you create.

Following is an example for creating one AWS RDS MySQL instance,

resource "aws_db_instance" "default" {
  db_name              = "mydb"
  engine               = "mysql"
  instance_class       = "db.t3.micro"
}

Here we are not defining a property called engine_version. It is taken by default as latest. Suppose now the latest is 5.7 but after a few months, the latest becomes 8. The version change might have breaking changes introduced. The application will start breaking.

The biggest issue is, nobody would know why the app is crashing without any code change.

MySQL might be a poor example because the version number is very important in that, however, things like docker image version, helm chart version are ofter taken/used as latest

No manual changes in managed services

We might face some important issues or requests that require immediate fixes. Or we might be trying to play around with resources to do POC or want to check capabilities. In these cases, instead of updating resources using Terraform, we often go to the web console and update the resources there.

This is a big no-no. Don't manage the resources that are managed by Terraform.

For example, we had one 'AWS Cognito' user pool (it is AWS's managed Identity Service), and someone introduced a custom parameter to that. Then someone tried to deploy something else, since the Cognito didn't have that parameter in Terraform configuration, it 'understood' that now this field needs to be deleted, so it tried to delete that field.

The problem with this example is, Cognito does not support field deletion. So the whole pipeline failed, and we had to recreate the whole user pool.

If you want to play around, do it using Terraform or create a separate resource.

Think about the environments

When we get a requirement to create resources, we jump into the task, create a bunch of resources, and declare that the task is done. The developers start using those resources and are happy.

As soon as we have to create a 'test' or a 'staging' environment, we are stuck because we only created resources for 'dev' environment, we have to now replicate the whole code chunk to create other environments.

Always create the resources in such a way that when we have to duplicate the resources, we have to pass a few configurations.

There are multiple ways to manage the environments like modules, variable files, or ENV variables. It might require a separate post to weigh the pros and cons. But think about the reusability at the start.

Think about duplication of resources

Let's assume you thought about environments and now creating templatized resources.

For example, here is the code to create one role

resource "aws_iam_role" "reader" {
  name = "reader"
}

The problem with this approach is, since the naming is static, if you create two environments from the same account, it will try to create the role reader in the same account. Roles have a validation that its name cannot be duplicated.

Always define the name of the resources dynamically like below. So for each environment, it creates a uniquely identifiable resource

resource "aws_iam_role" "reader" {
  name = "${clustername}-${env}-reader"
}

Think about enabling and disabling a feature

Always think about enabling or disabling a feature, in other words, most of the resources should be created optionally, preferably using variables.

It might be possible that one of the environments does not require RDS MySQL instance. Here is the code to create one MySQL

resource "aws_db_instance" "default" {
  db_name              = "mydb"
  engine               = "mysql"
  instance_class       = "db.t3.micro"
}

Since you now want to make this optional, you will introduce a variable that will create the resource only if the variable is true, for example as below

resource "aws_db_instance" "default" {
  count        = var.is-mysql-required ? 1 : 0
  db_name          = "mydb"
  engine           = "mysql"
  instance_class   = "db.t3.micro"
}

The problem with this transition is, since we introduced a count property, it will destroy the old instance and try to recreate a new one.

It might not be a problem for cattle type of resources (a resource that does not persist any state and can be destroyed and recreated at any time). However, resources like MySQL have data and if we recreate it, we might lose the data.

Think about the availability of managed services

This is not specifically for Terraform but can be applied to any cloud architecture.

When you are trying to create a resource that is the managed service of that cloud provider, always make sure it is available in all the regions you are intending to create environments in.

For example, we are using 'HTTP API Gateway' of AWS as the entry point to our kubernetes cluster. However, when we tried to set up our 3rd PROD environment, we came to know that 'HTTP API Gateway' is not available in the Indonesia Jakarta region.

There are two problems here, if we didn't have the resources as optional using variables, the whole pipeline would fail.

Another thing is, when we are choosing the services, always think about alternatives and don't rely too much on one specific service. (this is subjective and use your judgement)

Think about how to pass a value instead of creating a resource

This is loosely related to the previous two topics, if a resource is not created, then try to think if there is a way to pass a value instead of creating that resource.

For example, AWS Cognito is not available in Indonesia Jakarta as well. Since that resource is optional, we are not creating it. The problem is, there could be some other resources, that might require the issuer URL of the Cognito. Now we choose to use Cognito from some other environment. So if we keep a provision to provide the issuer URL directly in case a resource is not created, that would be helpful.

Another example is, if we don't want to terraform to create a security group but want to reuse an existing one, we might provide the id of an existing security group.

Common things

Don't keep everything under the template boundary.

For example, one time thing like ECR (it is a repository for docker images), you would want to create that only once and all the environment needs to access the same repository.

If that resource is inside the template then it would be created multiple times, which is a waste of money as well as creates issues of unnecessary duplication.

Think about account separation

This is again more related to the cloud instead of Terraform. However, when you create multiple environments, think about how you want to separate them.

Some options are:

Create in the same account
Create in the different account
Create in separate the resource group (Azure).

Cross access

Since some resources should be accessible from any environment, think about how will you provide cross env access.

For example, ECR (Container registry - docker image repository) needs to be accessed from any authorized env.

If you are intrigued by this visit our site to learn more.

We are also looking for awesome people to work with, if you'd like to be a part of our team join us!

How to use Angular Provider

Abhishek Keshri — Fri, 30 Dec 2022 15:36:57 +0000

Angular Provider is like a command to Angular Dependency Injection system regarding how to get an object/instance for a particular dependency.

This helps us to register dependencies, like classes or functions or even values with the Angular Dependency Injection system.

Now you must be wondering what on earth is the Angular Dependency Injection system?

Dependency Injection

Let's first see what is a Dependency.

Dependency is a service or an object that a class needs to perform its function.

Dependency injection, or DI, is a design pattern in which a class requests dependencies from external sources rather than creating them.

Example

We have a CarFactory in which Car object is created.



class CarFactory {
  car: Car = new Car(); 
}

And here is our Car



export class Car {
  engine: Engine;

  constructor() {
    this.engine = new Engine();
  }
}

export class Engine {}

In the above example, in order to create a Car, we first need to create an Engine.

Because we are instantiating the Engine class inside the constructor of the Car class with new keyword, there is a tight coupling between the Car class and the Engine class.

And this is a Problem.

Actually there are many types of Engine

Like a Flat Engine



export class FlatEngine {}

or an Inline Engine



export class InlineEngine {}

The problem here is that if a Car class requires a specific type of Engine it can't have one.

This Car can only have a generic Engine because of the tight coupling.



export class Car {
    engine: Engine;

    constructor() {
        this.engine = new Engine();
    }
}

This problem can be resolved by making both the class loosely coupled with each other.
For that, first we will turn our Engine class to an interface like this



interface class Engine {}

and let our FlatEngine and InlineEngine implement it.



export class FlatEngine implements Engine {}

export class InlineEngine implements Engine {}

With that our Car class will look like this



export class Car {
    constructor(private engine: Engine) {}
}

The responsibility of object creation of Engine is no more with the Car class. And the dependency will be directly injected through the constructor of the Car class.

The Car Factory can now have Car with different Engine types



class CarFactory {
    flatEngine: Engine = new FlatEngine();
    porsche911: Car = new Car(this.flatEngine);

    inlineEngine: Engine = new InlineEngine();
    bmwM88: Car = new Car(this.inlineEngine);
}

That was just a basic example of dependency injection.

Now let's get back to Angular Provider.

Configuring the Angular Provider

To Provide an instance of the dependency, we need to register it in the Providers metadata.



 providers: [CarService]

The above is an actual shorthand notation for the following syntax:



 providers: [{ provide: CarService, useClass: CarService }]

As you can see in the above example, the object has 2 properties. They are provide and provider.

1. Provide

The first property is Provide holds the Token or DI Token
The Injector uses the token to locate the provider in the Providers array

Type Token

Here the type being injected is used as the token.
For Example, we would like to inject the instance of the CarService, we will use the CarService as the token as shown below



 providers: [{ provide: CarService, useClass: CarService }]

The CarService is then injected to the component by using the following code.



export class CarComponent {
    constructor(private carService: CarService) { }
}

String Token

We can use a string literal to register the dependency. This is useful in scenarios where the dependency is a value or object etc., which is not represented by a class.



{ provide: 'CAR_SERVICE', useClass: CarService },
{ provide: 'API_URL', useValue: 'https://randomcar.com/api' }

It is then injected using the @Inject in the constructor of the service/component.



constructor(
    @Inject('CAR_SERVICE') private carService: CarService,
    @Inject('API_URL') private apiURL: string
) {}

Injection Token

The Angular provides InjectionToken class to ensure that the Unique tokens are created.
The Injection Token is created by creating a new instance of the InjectionToken class.



  export const API_URL = new InjectionToken<string>('api.url');



   providers: [{ provide: API_URL, useValue: 'https://randomcar.com/api' }]

It is then injected using the @Inject in the constructor of the service/component.



  constructor(@Inject(API_URL) private apiURL: string) {}

2. Provider

The second property is the Provider definition object.
It tells Angular how to create the instance of the dependency.
The Angular can create the instance of the dependency in four different ways.

Class Provider

useClass is used when you want to provide an instance of the provided class.
It expects us to provide a type. The Injector creates a new instance from the type and injects it. It is like calling the new operator and returning instance. If the type requires any constructor parameters, the injector will resolve that also.



  { provide: CarService, useClass: CarService }

We can also switch dependencies easily. You can provide a mock class for Testing purposes as shown below.



  { provide: CarService, useClass: MockCarService }

Value Provider

useValue is used when you want to provide a simple value.
The Angular will inject whatever provided in the useValue as it is.
It is useful in scenarios like, where you want to provide API URL, application-wide configuration etc



export const APP_CONFIG = Object.freeze({
  devUrl: 'https://dev.randomcar.com/api',
  IsDevelopmentMode: true
});

And we can use the APP_CONFIG as provided in the providers array.



  providers: [{ provide: 'API_CONFIG', useValue: APP_CONFIG }]

Factory Provider

useFactory expects us to provide a function.
It invokes the function and injects the returned value. We can also add optional arguments to the factory function using the deps array. The deps array specifies how to inject the arguments.
We usually use the useFactory when we want to return an object based on a certain condition.



{
   provide: CarService,
   useFactory: (config: any, loggerService: LoggerService) => return config.IsDevelopmentMode 
        ? new MockCarService(loggerService) 
        : new CarService(),
   deps: [APP_CONFIG, LoggerService]
}

Aliased Provider

The useExisting provider key lets you map one token to another.
In effect, the first token is an alias for the service associated with the second token, creating two ways to access the same service object.



  { provide: CarService, useExisting: 'MOCK_CAR_SERVICE' },
  { provide: 'MOCK_CAR_SERVICE', useClass: MockCarService },

Like what you read? then visit our site to learn more.

We are also looking for awesome people to work with, if you'd like to be a part of our team join us!

Monnai: A Product Launch Journey

Abhishek Keshri — Mon, 05 Dec 2022 13:30:00 +0000

A technical deep dive

Client: Monnai

Reinventing global consumer insights for fintech

The fintech market size stood at USD 112.5 billion in the year 2021. Yet, consumer data used for decissioning remain outdated and fragmented. Most provide limited data points and do not even work across countries and continents.

Monnai is on its way to changing this by providing over 500+ global and standardized consumer insights which may be a better predictor than just one’s Social Security Number or similar other identifiers.

What we did

Defining a vision for the product and the partnership
Automation, automation, automation
- Continuous Integration and Deployment (walking skeleton)
- Test strategy (BDD)
- Fault tolerance (AWS and automation)
Architected cloud infrastructure
- AWS architecture (Terraform)
Observability and monitoring
- Tools

Outcomes

11 Countries

17 Data partner integrations

3 Months for going live

92%+ code coverage

On-demand deployment, always prod ready

Defining a vision for the product and the partnership

The first seven seconds

Monnai had a very clear vision of how they wanted to change the fintech industry when they started. To jump-start their development, they decided to engage Incubyte in parallel with creating their internal engineering team. We were able to get from a sales call to starting work in under 15 days.

As green as it can get

Starting with a blank slate, in this case, a blank Confluence page, wouldn't be a wrong statement when we started the project. The Monnai team had initial ideas on the endpoints they wanted to create to support their API business, which we started building on. Such greenfield projects can cause imaginations to run wild and in our experience, we have seen projects accrue technical debt very fast as the team size and product complexity increase. That's why our focus was on the right practices like TDD and automation from day-one, while we worked closely with the client to uncover the thinnest slice that could become an MVP. The aim was not only to go to market quickly, but to also enable sustainable growth of the feature set as time passes.

The productivity pattern of a growing company typically looks like the following, exponential at first and then a dip!

We focused on the "right way" let's see how

Automation Automation Automation

Walking skeleton

Most teams do not take up ops work like build, deployment, infrastructure allocation, and database versioning until the very last moment. This becomes a reason for hurdles at the later stages of PDLC.

Starting with a walking skeleton of the software ensures smooth deployments from the very beginning since every component needed for the software architecture and practices is made available. This includes, at the very least, automated builds, code scans, testing, database upgrades, and code deployment.

Essentially we started with automating the process along with every component needed to achieve the end architecture.

Test Strategy

First, there was TDD! We have been practicing outside-in TDD for some time. While TDD enabled us to achieve high code coverage and incremental evolution of the architecture, the missing piece causing project delays were because of lack of collaboration, high cost of coordination, failure to agree on things, longer test cycles, etc.

This is why we decided to layer on BDD and the Three Amigos working model for the Monnai engagement. We took the QA function, that typically occurs almost after all work is done, and shifted it all the way left in the timeline. That meant we started automating test cases and involved all three amigos - analysts, developers, and QA, in the discovery process itself. This increased buy-in from all stakeholders and reduced back and forth between the proverbial walls.

Automated fault tolerance

We knew that we won't have the luxury of a "maintenance window" due to customers being located worldwide. So we designed our components in a way that any new deployment will create and start a server, make sure it is ready to accept traffic, only then route traffic to new servers, and then destroy old servers. This allowed us to deploy without any downtime, even in peak traffic conditions.

But, what if servers crashed or worse, what if a server is running but for some reason, not accepting the traffic? We put a liveness probe to each component that checks if the server can accept traffic, and if not, restart it. Also, there are always two load-balanced replicas in case of a server failure.

But wait, there is more! What if servers receive requests such that memory or CPU consumption shoot up? We put in horizontal scaling such that before an overload, a standby server is started and makes itself ready to serve the increased traffic. The mechanism will kill the extra instance once a dip in traffic is observed.

Cloud infrastructure

We emphasize on automation everywhere. Not just artifacts, and testing, but infrastructure should be automated as well. We use Terraform to create and manage the infrastructure. It has served us very well so far, eliminating any chance of human error in creating infrastructure.

Human errors are not limited to system crashes, but security lapses as well. A security lapse can cause more damage than other system issues. Since the infrastructure is in code, and each code change (read infrastructure change) is peer-reviewed and scanned automatically by a code scanner, there are fewer chances of deploying vulnerable infrastructure.

As an added bonus since everything is automated, replicating an environment became trivial too.

Observability and Monitoring

Due to the dynamic nature of components and the need for our system to communicate with multiple external data sources, we had to employ elegant observability solutions. We rely on proprietary solutions that support open-source implementation to avoid vendor locking.

Logs

All logs are captured and sent to a centralized server for query and review. Such centrally aggregated logs make your humdrum data insightful and real-time!

Metrics

Different levels of metrics like CPU, memory, threads, number of requests, number of active servers, etc. are collected and sent to a centralized server. A custom-made dashboard helps keep an eye on the health of infrastructure and become proactive as opposed to reactive!

Traces

Observing one API call is difficult as we have a distributed system with several internal and external endpoints. We capture and store traces of each call and allow developers to view the whole tree in a nice graphical way so that debugging and finding the cause of failure or slowness becomes easy.

Alarms

None of these are helpful if a person has to sit and analyze logs, traces or metrics manually, we believe in automating these as well. Any anomalies like errors in logs will throw an alarm email to relevant stakeholders.

TL;DR

A carefully selected tech stack, high levels of automation and following best practices from day one, helped us achieve the following for Monnai:

Go to market in three months
The ability to respond quickly to feedback from potential customers
On-boarding their first customer within six months
Sustained frequent releases to ensure the product evolved rapidly and incrementally
An amazing team morale!

Want to be part of this team that made this happen? join us!

Why Incubyte?

Abhishek Keshri — Mon, 28 Nov 2022 03:30:00 +0000

Quality is usually an implicit requirement when it comes to developing software. Users ask for a beautiful UI, outstanding performance, and the functionality they need, but quality is never on the list - it is just expected! And because it is so, it is often overlooked. Users end up getting only what was explicitly stated.

Incubyte's goal is to focus equally on the implicit aspects of software development, that include better scalability, maintainability, test-ability and security.

For companies that have been writing code for years, we help break the status quo, modernize their technology, upgrade their practices and up-skill their teams. With newer products, we help from inception to delivery, intensely collaborating with clients to design user-centric solutions, get fast feedback, start delivering value as soon as possible and make continuous improvements.

Pragmatic teams believe in continually developing and delivering value in small slices. These teams are constantly refining outcomes, iteration by iteration, moving towards perfection, but incrementally. This perfection itself becomes a moving target, as the team delivers small improvements, finds the next starting point and starts improving again from there.

Businesses benefit the most when their engineers also acknowledge the economic impact of the work they do. With this principle in mind, teams continuously deliver value, serve user needs and meet business goals.

These teams understand that a dollar earned today is better than one earned tomorrow and employ practices like incremental design, test driven development and automated builds and deployments, to get their work in the hands of their end users faster.

Most developers end up developing software for machines. When they start developing for humans, they are always looking for opportunities to better their users' experience and make an impact.

None of the quality we talk about is possible without continuous learning and up-skilling.
People that acknowledge this, make a conscious effort to grow the depth and breadth of their skill set.
This not only reflects in the work done, but also in more effective pairing sessions, educative lightning talks and stimulating conversations.

These are the teams and the people at Incubyte and they help create quality products, happy users and satisfied clients.

If you are intrigued by this visit our site to learn more.
We are also looking for awesome people to work with, if you'd like to be a part of our team join us!