This blog is an attempt to do just that.

SOLID stands for

1. Single Responsibility Principle (SRP)

2. Open-Closed Principle (OCP)

3. Liskov Substitution Principle (LSP)

4. Interface Segregation Principle (ISP)

5. Dependency Inversion Principle (DIP)

Let us check out these principles one-by-one.

Single Responsibility Principle (SRP)

This principles states that A class should have only one reason to change.

This means a class should be responsible for a single, specific piece of functionality.

Take the example of an Authentication Service versus a User Profile Service. Commonly used by almost all companies which serve Software as a Service to users.

SRP Violation (what beginners often do): Put all User Details & Auth in a single class

class UserService:
    def login(self): ...
    def logout(self): ...
    def reset_password(self): ...
    def update_profile(self): ...
    def upload_avatar(self): ...

Problem:
This class changes for multiple reasons:

• Auth rules change (OAuth, MFA, tokens)

• Profile rules change (new fields, avatars, preferences)

SRP Applied (real startup architecture): Separate classes based on specific functionality (Authentication vs User Profile Details)

class AuthService:
    def login(self): ...
    def logout(self): ...
    def reset_password(self): ...

class UserProfileService:
    def update_profile(self): ...
    def upload_avatar(self): ...

Open/ Closed Principle (OCP)

This principle states that A software entity (like a class, module, or function) should be open for extension, but closed for modification.

You should be able to add new functionality without changing existing code.

Real World Example: Imagine an early-stage product that only supports card payments. Someone writes this:

class PaymentService:
    def pay(self, amount, method):
        if method == "card":
            return self.pay_by_card(amount)
        elif method == "upi":
            return self.pay_by_upi(amount)
        elif method == "wallet":
            return self.pay_by_wallet(amount)

Now when the business expands new payments will start coming. International Payments, Net Banking, Crypto. And because of the current structure, we would need to add a new method. Every single time a new method is added, this class has to be edited. That means touching code that already works, retesting everything, and hoping nothing breaks.

This is exactly the situation companies like Stripe design around, because payment code is too sensitive to keep rewriting. So the design shifts. Instead of modifying the same method again and again, the system becomes extensible:

class PaymentMethod:
    def pay(self, amount):
        raise NotImplementedError


class CardPayment(PaymentMethod):
    def pay(self, amount):
        ...


class UpiPayment(PaymentMethod):
    def pay(self, amount):
        ...


class WalletPayment(PaymentMethod):
    def pay(self, amount):
        ...

And now the Service looks like:

class PaymentService:
    def pay(self, amount, payment_method: PaymentMethod):
        return payment_method.pay(amount)

Whats important here is not inheritance itself. Its the fact that adding a new payment method no longer requires modifying PaymentService. You extend the system by adding new classes, not by reopening old ones. Thats OCP working in a very real, revenue-protecting way.

Liskov Substitution Principle (LSP)

This principle states that The objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program. The use of this principle commonly occurs during file handling, storage, and cloud integrations.

Imagine this base class:

class FileStorage:
    def save(self, filename, data):
        pass

    def delete(self, filename):
        pass

Your code assumes that if a file can be saved, it can also be deleted. Thats a reasonable assumption.

Now someone adds a read-only storage backend, maybe for compliance or audit logs:

class ReadOnlyStorage(FileStorage):
    def save(self, filename, data):
        raise Exception("Storage is read-only")

    def delete(self, filename):
        raise Exception("Storage is read-only")

Again, this compiles fine. But it violates LSP in a very sneaky way.

Any code that works with FileStorage and reasonably expects save and delete to work will now break at runtime. The subclass is saying, I am a FileStorage, but behaving like one that cant actually do what FileStorage promises.

This kind of mistake shows up in systems built on top of platforms like Amazon S3 integrations, where some buckets or backends are intentionally immutable.

The fix is not defensive try/except everywhere. The fix is modeling reality correctly.

You separate the abstraction:

class ReadableStorage:
    def read(self, filename):
        pass


class WritableStorage(ReadableStorage):
    def save(self, filename, data):
        pass

    def delete(self, filename):
        pass

Now a read-only store is a ReadableStorage, not a WritableStorage. Nothing pretends to support behavior it cannot guarantee. Substitution becomes safe again.

Interface Segregation Principle (ISP)

This principle states that no client should be forced to depend on methods it does not use.

Let us take an example which is extremely common in internal tools, admin panels, and dashboards.

Imagine an interface for a user in an admin system:

class AdminUserActions:
    def create_user(self):
        pass

    def delete_user(self):
        pass

    def view_reports(self):
        pass

    def export_data(self):
        pass

At first, this makes sense for a super-admin. Then the company hires support staff. They only need to view users and reports. Now you get something like this:

class SupportAgent(AdminUserActions):
    def create_user(self):
        raise Exception("Not allowed")

    def delete_user(self):
        raise Exception("Not allowed")

    def view_reports(self):
        ...

    def export_data(self):
        ...

This design is screaming for trouble. Permission checks are scattered everywhere, and not allowed becomes a runtime surprise instead of a design guarantee.

Large platforms like Shopify handle this by separating responsibilities at the interface level, not by stuffing permissions into one giant abstraction.

The design moves toward something like:

class UserManagement:
    def create_user(self):
        pass

    def delete_user(self):
        pass


class Reporting:
    def view_reports(self):
        pass

    def export_data(self):
        pass

Now a support agent depends only on Reporting. An admin depends on both. No one implements methods they arent supposed to use, and permission logic becomes explicit instead of implicit.

Dependency Inversion Principle (DIP)

This principle states that High-level modules should not depend on low-level modules. Both should depend on abstractions.

Imagine an order service in an e-commerce app:

class OrderService:
    def __init__(self):
        self.db = MySQLDatabase()

    def create_order(self, order):
        self.db.save(order)

This looks innocent. It works. Orders get saved.

Then reality hits. The startup grows. Someone wants to move to PostgreSQL. Or to DynamoDB. Or add a cache. Suddenly OrderService is tightly bound to MySQLDatabase. Every infrastructure change forces you to modify core business logic.

Companies like Amazon ran into this problem at massive scale. Their business logic cannot care whether data is stored in MySQL, DynamoDB, or something custom.

So the dependency is inverted:

class OrderRepository:
    def save(self, order):
        pass

Now OrderService depends on this abstraction:

class OrderService:
    def __init__(self, repository: OrderRepository):
        self.repository = repository

    def create_order(self, order):
        self.repository.save(order)

And the concrete database lives at the edge:

class MySQLOrderRepository(OrderRepository):
    def save(self, order):
        ...

What changed here is subtle but powerful. The high-level code no longer knows or cares about databases. Infrastructure details depend on the business abstraction, not the other way around. That inversion is the core of DIP.

Now, let us move on to OOPs concepts.

OOP stands for Object-Oriented Programming. There are 4 concepts in Object-Oriented Programming namely:

1. Abstraction

2. Encapsulation

3. Inheritance

4. Polymorphism

Let us start with Abstraction.

Abstraction

Abstraction involves hiding complex implementation details and showing only the necessary features of an object. In real codebases, abstraction exists to reduce cognitive load. You dont want every part of the system to understand every detail.

A very common abstraction shows up in databases.

Imagine writing business logic that directly uses SQL everywhere:

def create_order(order):
    cursor.execute(
        "INSERT INTO orders (id, total) VALUES (?, ?)",
        (order.id, order.total)
    )

This works, but now your business logic knows too much. It knows SQL. It knows table names. It knows schema details. When the database changes, business logic breaks.

So teams introduce an abstraction:

class OrderRepository:
    def save(self, order):
        pass

Now the business code talks only to the abstraction:

def create_order(order, repo: OrderRepository):
    repo.save(order)

The database details disappear behind the abstraction. Whether the data goes to MySQL, PostgreSQL, or DynamoDB becomes irrelevant to the caller. This is abstraction doing its job: shielding the rest of the system from complexity.

Encapsulation

Encapsulation is the bundling of data and the methods that operate on that data within a single unit (class). It restricts direct access to some of an object's components, which is a means of preventing accidental interference and misuse of the methods and data. It exists because uncontrolled access to data always turns into bugs.

Consider a naive bank account class:

class BankAccount:
    def __init__(self):
        self.balance = 0

Anyone can now do this:

account.balance = -100000

Nothing stops it. No rules are enforced. This is how systems quietly rot.

Encapsulation fixes this by controlling access:

class BankAccount:
    def __init__(self):
        self._balance = 0

    def deposit(self, amount):
        if amount <= 0:
            raise ValueError("Invalid deposit")
        self._balance += amount

    def withdraw(self, amount):
        if amount > self._balance:
            raise ValueError("Insufficient funds")
        self._balance -= amount

Now the state can only change through valid operations. The rules live close to the data they protect. This pattern shows up everywhere in financial systems because money without guardrails is dangerous.

Inheritance

Inheritance allows a class to inherit properties and methods from another class, promoting code reuse and establishing a relationship between parent and child classes.

Inheritance appears in domain modeling. You might have a base Employee:

class Employee:
    def calculate_salary(self):
        pass

Then specializations:

class FullTimeEmployee(Employee):
    def calculate_salary(self):
        return self.base_salary

class Contractor(Employee):
    def calculate_salary(self):
        return self.hours * self.rate

Payroll systems rely on this kind of inheritance because different employee types share identity but differ in behavior.

Polymorphism

Polymorphism allows objects of different types to be treated as objects of a common base class. It enables a single interface to represent different underlying forms (data types).

A very real example is payment handling.

class PaymentMethod:
    def pay(self, amount):
        pass

Different implementations:

class CardPayment(PaymentMethod):
    def pay(self, amount):
        print("Paid by card")

class UPIPayment(PaymentMethod):
    def pay(self, amount):
        print("Paid by UPI")

Here pay method is implemented differently for CardPayment Class and UPIPayment Class though they inherit the same method from the PaymentMethod Class. As you can see, Polymorphism means the same call behaves differently depending on the object. The calling code does not care which one it gets:

def checkout(method: PaymentMethod, amount):
    method.pay(amount)

This is polymorphism in its purest form, and companies like Stripe build entire platforms around this idea.

And that is it, hope you had a clear idea of what SOLID Principles and OOPs concepts are and how they are used in real-world projects and implementations.

If you liked this blog, please write to me on shreyastaware.work@gmail.com. And for anything else, feel free to visit my website: shreyastaware.me

Until next time,

Shreyas

That is when you need Docker.

In this article, youll find common commands you would need while testing and deploying applications.

Refer to this article as a quick reference guide for commands you'll need to look up regularly.

Build a docker container

docker build -t <image_name> .

Key thing to note here is that a docker container runs in isolation to the rest of the operating system it is built on, but, it does need the same architecture in the operating system as a base to be rebuilt on.

So, for example, if a docker container was built on the x86 architecture pc, it would need any computer with a variant of this architecture to rebuild it. It would not work on the AArch64 architecture in the macOS mX series.

You can also specify the operating system corresponding to how the image should be built:

docker build --platform=linux/amd64 -t <image_name> .

Running the docker container

docker run --name <container_name> <image_name>

In the above command, slt-container is the name of the docker container which contains the docker image slc-vnc-test.

Checking running containers

docker ps

Checking stopped containers or container ID or name

docker ps -a

Checking Logs using Container Name or ID

docker logs <container_name>

Stopping a Docker Container

docker stop <container_name>

Deleting a Docker Container

docker rm <container_name>

Remove Unnecessary Space occupied by the container (Cache) after deleting the Docker Container

docker system prune -a
docker builder prune --all

List Docker Images

docker images

Delete a Docker Image

docker rmi <image_name>

Remove all unused images

docker image prune

And that is it, you can now deploy your application which contains the DockerFile and your application code to any cloud provider.

Also, if you need more commands, feel free to refer to the official docker documentation here, or the CLI CheatSheet linked here.

Happy Deployment!

Until next time,

Shreyas

There are couple of things you should know before reading this blog:

• Basics of the Python Programming Language
• What is a Virtual Environment in Python?

With these prequisites being fulfilled, let's dive straight into the blog.

Motivation

Having multiple Python projects is a common occurence as a programmer.

Each project would have their respective python version and their compatible dependencies.

Thus, it is necessary to isolate these python versions and their dependencies from the global python installations and its dependencies so that we reduce version conflicts and have better control over our code.

What is pyenv?

Pyenv is a tool designed to manage multiple Python versions whether they are local installations ie virtual environments or global installations and their dependencies without interfering with each other.

How Pyenv works:

Pyenv operates by using "shims," which are small executable scripts that intercept Python commands. When you execute a python command, Pyenv's shims redirect the command to the currently selected Python version, ensuring that the correct interpreter is used.

How to install pyenv?

If you are using macOS, you can simply install it using:

brew install pyenv

For operating system specific installation, feel free to follow the guide mentioned here.

How to manage pyenv?

Below are the essential commands every developer would need to manage python installations and different virtual environment.

Frequently Used Commands

First, find your username using:

whoami

To check the list of python versions installed using pyenv

pyenv versions

To check the global list of python versions installed

ls /Users/<username>/.pyenv/*

You can see the "shims" or the aliases which are being used by pyenv, but they refer already installed python versions inside the operating system.

Now, we move towards installation of global and local python versions.

To install a python globally using pyenv

pyenv install 3.13.0

Set a global python environment

pyenv global 3.13.0

Please Note: Setting a Global python version works only once you are outside of the local directory that has a pyenv virtual environment (explained further). So, feel free to set a global python anywhere outside of the local projects' directory, and you won't face any errors.

To install a local environment, use

pyenv virtualenv <python_version_no> <env_name>

for example:

pyenv virtualenv 3.11.8 aifc

Now, there are two ways using which you can activate a virtual environment: manually, and automatically (that is, when you change directory or cd into it).

For manual virtual environment activation:

pyenv activate aifc

This commands activates the virtual environment as and when we invoke it.

For Directory Based Activation:

pyenv local aifc

Pros (& when to use it?):

• This command activates the virtual environment.
• Along with that it also sets the current directory it is in, as the local directory of that environment. So, whenever you change directory to that folder, this environment gets activated by default by pyenv.

When to use it?:

• This command is best for recurring projects and projects which require collaboration.

Cons (& how to mitigate it):

• Entering this command also saves "aifc" the local environment name instead of the actual python version used by that virtual environment in your ".python-version" file.

This is not ideal, since once we push this code, we or our peers won't be able to identify which python version needs to be installed for this project.

What we ideally want is say instead of "aifc" it was "3.10.13" the python version that was saved. Let's learn how to do that:

How to mitigate this?

1) Add the ".python-version" file name to your ".gitignore" file.

2) Once you do that, save the python version number of the local environment by creating the ".python-version.example" file and saving inside it.

This way the exact version number of the project is saved into the ".python-version.example" file, while the file that sets your environment ".python-version" gets ignored by version control (since you put it inside .gitignore file).

This lets you or your peers know about the python version for that particular project, while you get the benefits of locally changing directory without having to activate or deactivate the respective virtual environment!

Till now, we have learnt how to install pyenv, lookup different python versions, install, and activate local and global pyenv python versions.

Now let us learn how to deactivate the virtual environment:

Once we activate the virtual environment, the directory is ready to be used for the project.

To deactivate the virtual environment (for Directory based activation):

pyenv local --unset

To deactivate the virtual environment (for manual activation):

pyenv deactivate

How to check the currently active pyenv virtual environment

pyenv version

To check python version of the currently active pyenv virtual environment

python --version

Finally, we may need to delete the global python version or the virtual environment we created. Here's how to do that:

Deleting the global python version

pyenv uninstall <version>

Deleting the virtual environment

pyenv virtualenv-delete <env-name>

And that is it!

If you came till the end, thank you so much! It means a lot to me!

"Every strike brings me closer to the next home run." -- Babe Ruth

Inspired. Motivated. Ready to Go🚀 (@Inspire_To_Win) January 6, 2024

Cheers.

Until next time,

Shreyas

Use Case - A web developer or a graphic designer needed to record various versions of a specific file so that they could compare different versions and select the best one.

Originally, the straightforward way was to just create another copy of the file make changes to it, and then use it. Like this:

But as it was too clumsy to handle, there was a need to create a system that would handle this, without the need to create a new copy of the file.

TADA! Here comes Version Control

What is Version Control?

Version Control is a system that records modifications to a file or a repository (folder of files) over time so that you can recall specific versions of that later.

What is Git?

Git is a distributed version control system (DVCS) whose goal is to track and manage file changes and collaborate with multiple developers working on the same project.

A distributed version control system decentralizes the data, and every client computer not only records the snapshot of the latest files but fully mirrors the repository.

You might also have come across the term - Github. But, its not the same as Git.

So, What is Github?

Github and similar services like Gitlab or BitBucket are websites that hold a Git server program to hold your code.

Git Basics

Git stores snapshots of files at every interval and not differences. So, if a file has not changed in some interval, it reuses the same file instead of creating another copy.

The 3 main states

1. Modified - It means that you made changes to the file, but did not stage those changes.

2. Staged - It is an area where snapshots of files are added temporarily so that they are ready to be committed/ saved permanently.

3. Committed - It means taking a permanent snapshot of the files that are staged. It also means saving the files in your Git Version Control System.

But, we also need to know few things -

Local/ Working Directory - It is the directory that you work with on your local computer. These files are pulled from the database in the Git Directory and placed on the disk on your computer for you to modify or this directory is directly synced with another newly created repository on Github and thus works as a Git Repository.

Git Directory - It is where Git stores the metadata and object database for your project.

Staging area/ Index - This is a file that stores information about what will go into your next commit.

Basic Git Workflow

1. You modify files in your working directory.

2. You stage the files, adding snapshots of them to your staging area.

3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.

First Time Git Setup

If you are on ubuntu, the process is pretty straightforward. Just open your terminal and type -

sudo apt-get install git-all

To get a list of settings you can type

git config --list

to check your preferred editor you can type

git config core.editor

To set the username, email address and the editor (I would highly encourage using vim as it is great, though nano will work fine too)

git config --global user.name "Shreyas Taware"
git config --global user.email shreyastaware13@gmail.com
git config --global core.editor vim

Once this is done, we are good to go. But wait, we need to figure out a way if we are stuck.

Getting Help using Git

git help <verb>
git <verb> --help
man git-<verb>

Try this:

git help config

Part 2 of the series will be coming shortly.