Forem: Khushboo Parasrampuria

TheBrag CLI: Save your brags from terminal

Khushboo Parasrampuria — Sun, 19 Feb 2023 16:08:46 +0000

What I built

If you're anything like me, you believe in getting things done as quickly as possible, but when the time comes for a performance review or job interview, you're stuck with a bad memory and a blank page, frantically combing through JIRA tickets, emails, and closed PRs from multiple projects.

Now, you don't have to think about what you did in the last six months or a year with TheBrag!

Brag now, remember later.

TheBrag is a CLI-based application that lets you save your brags (things you want to show off) directly from your terminal.

TheBrag has the following features:

You can add, view, update, or delete brags directly from the CLI.
Create custom categories to sort out your accomplishments like work tasks, personal tasks, blogs, etc.
Use the "export to file" functionality to recieve a copy of your accomplishments via email.
You can export all your data or by selected categories within a date range.

Category Submission:

Wacky Wildcard
Integration Innovators
SaaS Superstars

App Link

Download the CLI application from this link.

Installation Steps:

Download the application from the link above.
Run chmod a+x thebrag from the directory where the file was downloaded. This will make the file executable for all groups on your system.
From the same directory you can run ./thebrag on your terminal to start using it. OR
If you want to access thebrag command from anywhere in your system, you need to add the application path to your $PATH environment variable.
- Navigate to your home directory by typing cd in the terminal.
- Type nano .profile or nano .zshrc.
- Inside this file, add the following line: export PATH=$PATH:/foo/bar (Replace /foo/bar with the location of the downloaded file)

Save and quit.
Exit Terminal.app (or whichever term program you're using) and restart it.

You should now be able to run thebrag from anywhere.

Screenshots

thebrag command: Gives the basic information about the app along with a list of commands that can be used.

thebrag login command

Add a new category: thebrag category -c "<category_name>"

List all existing categories: thebrag category

Add a brag: thebrag add -c "<category_name>" -t "<brag title>" -d "<brag details>"

List brags: thebrag get -n <no. of brags>

thebrag get -n <no. of brags> -s <skip_from_start>

Get a specific brag: thebrag get -i <brag_id>

Update a brag: thebrag update -i <brag_id> -d "new details content" -t "new title content" -c "new category name"

Delete a brag: thebrag delete -i <brag_id>

Export brags: thebrag export -d "<from_date>,<to_date>" -c "<category_name>"

Received Email:

Exported Brags CSV:

Description

A high level view of the system:

The user interacts with the application via the CLI to manage their brags.
The request is sent to the thebrag APIs, hosted on Linode servers, for processing .
The API interacts with the MySQL database to get/update the data.
The Export Module will let you export brags into a CSV file.
After generating the file, it is uploaded an Object Storage bucket on Linode and sent to the registered email id using SendGrid Emails.

Link to Source Code

APIs: thebrag-api
CLI: thebrag-cli

Permissive License

MIT License

Background

From trying to come up with things to write about in the year end review for appraisals and giving talking points to help my manager for award nomination at work, made me think that I should start logging the things I've worked on in one place.

Inspired by this post by Julia Evans and practically spending all day in the terminal, I decided to just a write CLI application which will let me log my work directly from the terminal.

The skeleton is me 😵‍💫.

How I built it

Language, Framework and Libraries:

TheBrag-CLI uses the Golang's Cobra library which provides a simple interface to create powerful CLI applications.

TheBrag-API is built using Golang's Gin framework for easy implementation of REST-APIs and Gorm for MySQL integration.

This is my first GoLang Application 🤩

Infrastructure:

APIs are deployed on Linux virtual machines called Compute Instances provided by Linode. For demo purpose this is setup on a shared CPU nanode 1GB.
MySQL is also provisioned on Linode using their high performing managed database clusters. Also on shared CPU nanode 1GB.
Exported brag files are uploaded in a private bucket on Object Storage offering by Linode to save the exported data files on cloud.
SendGrid is used to send the email containing the exported data file.
Thebrag CLI app is hosted in a bucket on Object Storage by Linode with public read access to allow anyone to download the app and start using it.

Future Scope/Roadmap

This is not the end for this project, I'm going to continue adding features to this.

Filter brags by category, date range etc.
Setup Github Actions for deployment.
Convert your brags into a resume.
Performance optimisation: Move export functionality to a worker.
Dashboard for people who prefer a GUI.

PS: Feel free to share suggestions or feature requests.

Additional Resources/Info

[1] Opening a port on linux or this one linux-how-to-open-a-port
[2] Copy files from local to remote server
[3] All go tutorials use localhost for API to listen to, remember to change the IP for production deployment. After 2 days of confusion I found this: port-seems-to-be-open-but-connection-refused
[4] SendGrid for emails

Factory Design Pattern in Python

Khushboo Parasrampuria — Sat, 21 Jan 2023 14:07:50 +0000

Factory pattern is a creational design pattern. As the name suggests, a "factory" is a place where things are created.

The factory pattern defines an interface for creating an object, but it lets the subclasses define which object to build; it does this through a factory method.

Scenario: We want to support several models of cars and their functionalities, like start and stop. But we don’t know which one we will need until runtime.

A brute force approach to implementing this would be: at runtime, when we get the name of the car model, we can write if-else statements or even switch case statements to decide which class object to create and call.

from cars.ford import Ford
from cars.ferrari import Ferrari
from cars.generic import car

def get_car(car_name):
  if car_name == 'Ford':
    return Ford()
  elif car_name == 'Ferrari':
    return Ferrari()
  else:
    return GenericCar()

for car_name in ['Jeep', 'Ferrari', 'Tesla']:
  car = get_car(car_name)
  car.start()
  car.stop()

This code snippet works perfectly, but if we want to support more car models, we will have to modify the above implementation and add more class import statements, which breaks the open/ closed principle.

Also, we are directly instantiating the car classes, which is breaking the dependency-inversion principle as we are depending on the implementation of these classes.

Now let's take a look at how we can refactor our code to avoid breaking the SOLID principles and still be able to extend our application easily.

Class diagram – factory pattern

In the class diagram above, we see an AbsCars class, which is an abstract class that says we must implement start and stop methods in all its concrete classes, and in the bottom, we have three concrete classes; these are the car classes that we want to support: Jeep, Ford, and Ferrari, which implement the AbsCars class.

In the end, we have the CarFactory class, which creates the instance of the desired car class.

The AbsCars class will look like this:

import abc

class AbsCars(abc.ABC):
  @abc.abstractmethod
  def start(self):
    pass

  @abc.abstractmethod
  def stop(self):
    pass

The start and stop methods are declared as abstract methods, which basically means all the concrete classes implementing the AbsCars class need to implement them as well.

For example, the Ford class:

from cars.abscars import AbsCars

class Ford(AbsCars):
  def start(self):
    if is_fuel_present:
      print("ford engine is now running")
      return
    print("Low on fuel")

  def stop(self):
    print("Ford engine shutting down")

Other car classes are implemented in the same way. The factory pattern allows all the concrete classes to have their own implementations of these abstract methods, which may or may not be the same.

For example our GenericCar class can be implement like this:

from cars.abscars import AbsCars

class GenericCar(AbsCars):
  def __init__(self, car_name):
    self.name = car_name

  def start(self):
    print(f"{self.name} engine starting!")

  def stop(self):
    print(f"{self.name} engine stopping!")

Now our CarFactory class

from inspect import getmembers, isclass, isabstract
import cars

class CarFactory():
  cars = {}

  def __init__(self):
    self.load_cars()

  def load_cars(self):
    classes = getmembers(cars, lambda m: isclass(m) and not isabstract(m))
    for name, _type in classes:
      if isclass(_type) and issubclass(_type, autos.AbsCars):
        self.cars.update([[name, _type]])

  def create_instance(self, car_name):
    if car_name in self.cars:
      return self.cars[car_name]()
    else:
      return cars.GenericCar(car_name)

Cars dictionary here will keep a reference to the class against the name of the car model.

The init dunder method will call load_cars() which builds the cars dictionary.

The load_cars method will get all the classes in the cars package that are not abstract classes, and then it will look for classes that are subclasses of our AbsCars class and add them to the cars dictionary.

The create_instance function looks for the car name in the cars dictionary and, if found, returns a new instance of the class; otherwise, it returns an instance of the GenericCars class.

Lastly, in our main module, we just need to import and instantiate the AutoCars class, then loop through the car names, calling the create_instance method for each car.

from cars.carfactory import CarFactory

factory = CarFactory()

for car_name in ['Ford', 'Ferrari', 'Tesla']:
  car = factory.create_instance(car_name)
  car.start()
  car.stop()

With this approach we can keep on adding support for more car models by just adding the car classes implementing the AbsCar class and not touch any other code in our project!

Back to Basics: SOLID Principles (Dependency Inversion)

Khushboo Parasrampuria — Thu, 12 Aug 2021 14:07:51 +0000

In a software development lifecycle, the decision on how accessible and flexible an object is during this object's design phase will ensure its usability, simplicity, ease of implementation, and accessibility towards making reliable software.

In this post, we will try to understand the fifth SOLID principle and how it can help us write easily extendable software applications.

Dependency Inversion Principle:

This principle suggests:

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

By following this approach, it makes the interchanging of modules and classes or services simple.

Let's see how this works with an example:


class MySQLDatabase():

    def insert(self, data):
        """Logic to save the data in MySQL DB"""
        pass

    def delete(self, id):
        """Logic to delete a row from the DB"""
        pass

class CarManufacturer():
    def __init__(self):
        self._db = MySQLDatabase()

    def create_car(self, data):
        self._db.insert(data)

    def delete_car(self, car_id):
        self._db.delete()

In the above example, CarManufacturer class is dependent on MySQLDatabase class. In the future, if we want to change our database from MySQL to suppose Postgres we will have to go to all the classes that are using the MySQLDatabase class and update the code to use the new Postgres implementation.

This violates the Open-Closed Principle.

Solution?

We will use the Dependency Inversion Principle to make our low-level class i.e. MySQLDatabase to extend an abstraction and our high-level class i.e. CarManufacturer will depend on that abstraction to implement the database functions.


class Database:

    def insert(self, data):
        pass

    def delete(self, id):
        pass

class MySQLDatabase(Database):

    def insert(self, data):
        """Logic to save the data in MySQL DB"""
        pass

    def delete(self, id):
        """Logic to delete a row from the MySQL DB"""
        pass


class CarManufacturer():
    def __init__(self, DB: Database):
        self._db = DB

    def create_car(self, data):
        self._db.insert(data)

    def delete_car(self, car_id):
        self._db.delete(car_id)

Now no matter which type of database is used in the application, the CarManufacturer class can connect to the database without any problems or code changes, and the Open-Closed Principle is not violated.

By following the dependency inversion principle, we do not have to change our code, that helps with code readability and extensiveness.

This marks the end of the series, Back to Basics, each covering one SOLID principle.

Back to Basics: SOLID Principles (Interface Segregation)

Khushboo Parasrampuria — Mon, 09 Aug 2021 12:25:22 +0000

Writing clean code is one of the core precepts of software development.

There are various software design approaches to ensure an understandable, flexible, and maintainable code base.

In this post, we will be try understand the fourth SOLID principle and how it can help us become better developers.

Interface Segregation Principle

A client should not be forced to implement an interface that it does not use.

Let's take an example to understand what this means:


class ShapeInterface:
    def area(self):
        pass

class Square(ShapeInterface):
    def area(self):
        """area of square = a^2"""
        pass

class Rectangle(ShapeInterface):
    def area(self):
        """area of rectangle = l*b"""
        pass

The above example is good as it follows all our object-oriented programming principles. Now let's add a volume method for shapes like Sphere or a Cylinder.


class ShapeInterface:
    def area(self):
        pass

    def volume(self):
        pass

class Square(ShapeInterface):
    def area(self):
        """area of square = a^2"""
        pass

    def volume(self):
        raise NotImplemented

class Rectangle(ShapeInterface):
    def area(self):
        """area of rectangle = l*b"""
        pass

    def volume(self):
        raise NotImplemented

class Sphere(ShapeInterface):
    def area(self):
        """area of sphere = 4πr^2"""
        pass

    def volume(self):
        """volume of sphere = (4/3)*πr^3"""
        pass

Since 2D shapes cannot have any volume, the Square and Rectangle class are forced to implement methods of an interface they don't have any use of.

Solution?

ISP says that interfaces should perform only one job (just like the SRP principle) any extra grouping of behavior should be abstracted away to another interface.

To conform to ISP we will segregate the volume method to another interface which will be used by 3D shapes.


class TwoDShapeInterface:
    def area(self):
        pass

class ThreeDShapeInterface(TwoDShapeInterface):
    def volume(self):
        pass

class Square(TwoDShapeInterface):
    def area(self):
        """area of square = a^2"""
        pass

class Rectangle(TwoDShapeInterface):
    def area(self):
        """area of rectangle = l*b"""
        pass

class Sphere(ThreeDShapeInterface):
    def area(self):
        """area of sphere = 4πr^2"""
        pass

    def volume(self):
        """volume of sphere = (4/3)*πr^3"""
        pass

Now we have 2 Interfaces; TwoDShapeInterface and ThreeDShapeInterface. TwoDShapeInterface as the name suggests contains methods that are only required for 2D shapes like square, rectangle, etc. while ThreeDShapeInterface extends TwoDShapeInterface and has 3D shapes related methods like volume calculation for shapes like Sphere.

This post is Part 4 of the series, Back to Basics, each covering one SOLID principle.

Back to Basics: SOLID Principles (Liskov Substitution)

Khushboo Parasrampuria — Sun, 08 Aug 2021 10:25:59 +0000

The five object-oriented programming principles a.k.a. SOLID principles establish practices that lend to developing software with considerations for maintaining and extending as the project grows.

In this post, we'll be going over the third SOLID principle.

Liskov Substitution Principle

The formal definition of the principle says:

Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

Frankly speaking, this just went over my head. So let's try to simplify this.

A sub-class must be substitutable for its superclass. This principle aims to ascertain that a sub-class can assume the place of its superclass without breaking the program.

If LSP is not followed, a new subclass might necessitate changes to any client of the base class or interface. If LSP is followed, clients can remain unaware of changes to the class hierarchy. The client should behave the same regardless of the subtype instance that it is given.

The LSP, therefore, helps to enforce both the open-closed principle and the single responsibility principle.

Let's take an example to see this in action:


class Vehicle:
    def __init__(self, name):
        self.name = name

    def engine(self):
        pass

    def start_engine(self):
        pass

class Car(Vehicle):
    def engine(self):
        return True

    def start_engine(self):
        self.engine()

class Bicycle(Vehicle):
    def engine(self):
        raise Exception("not implemented")

    def start_engine(self):
        raise Exception("not implemented")

    def start_pedaling(self):
        return True


vehicles = [
    Car('queen'),
    Bicycle('booster')
]
def drive_vehicle(vehicles):
    for vehicle in vehicles:
        if isinstance(vehicle, Car):
            vehicle.start_engine()
        elif isinstance(vehicle, Bicycle):
            vehicle.start_pedaling()

In the above example, the Car and Bicycle implement the Vehicle class but they violate the Liskov Substitution Principle in two places.

The Bicycle class doesn't support start_engine and engine methods. It will throw an exception if we try to call those methods. Due to this, we have our second violation.
In the drive_vehicle method we are checking the type of the class instance and accordingly calling the relevant methods to drive the vehicle.

These are direct violations of LSP, as we should be able to change the type of class that implements the same superclass without the client being aware of this change.

Solution?

For the first violation, we will divide our vehicle class into two classes. VehicleWithEngine will implement the Engine class with its relevant methods and the Car and other vehicles with an engine will implement this class.


class Engine:
    def engine(self):
        pass

    def start_engine(self):
        pass

class VehicleWithEngine(Engine):
    def __init__(self, name):
        self.name = name

    def engine(self):
        pass

    def start_engine(self):
        pass

class Car(VehicleWithEngine):
    def engine(self):
        """ define the engine """
        return True

    def start_engine(self):
        """ implement the start up process for the engine"""
        self.engine()

class Bike(VehicleWithEngine):
    def engine(self):
        """ define the engine """
        return True

    def start_engine(self):
        """ implement rest of the steps to start an engine"""
        self.engine()

For the second violation, we will implement another class VehicleWithoutEngine which will not implement the Engine class and will have its methods required for driving without an engine.


class VehicleWithoutEngine:
    def __init__(self, name):
        self.name = name

    def start_pedaling(self):
        pass

class Bicycle(VehicleWithoutEngine):
    def start_pedaling(self):
        """implement the pedaling process"""
        return True

Now our drive_vehicle function will be changed to:


def drive_vehicle():
    car = Car('Queen')
    car.start_engine()

    bicycle = Bicycle('Booster')
    bicycle.start_pedaling()

Car and Bicycle both might be vehicles but both have different ways of working.

This post is Part 3 of the series, Back to Basics, each covering one SOLID principle.

References:

Back to Basics: SOLID Principles (Open Closed)

Khushboo Parasrampuria — Wed, 04 Aug 2021 11:12:30 +0000

SOLID is an acronym for the five object-oriented design (OOD) principles by Robert C. Martin in his book Design Principles and Design Patterns.

Adopting SOLID programming principles can also contribute to avoiding code smells, refactoring, and Agile or Adaptive software development.

In this post we'll be learning about the second SOLID programming principle.

Open Closed Principle

Objects or Entities (classes, modules, functions) should be open for extension, not for modification.

Let's take an example to understand what this means:


class Animal:
    def __init__(self, name):
        self.name = name

    def get_name(self):
        pass

def animal_sounds(animals):
    for animal in animals:
        if animal.name == "lion":
            print("roar")
        elif animal.name == "mouse":
            print("squeak")

animals = [
    Animal("lion"),
    Animal("mouse")
]

animal_sounds(animals)

The above code violates the Open Closed principle as when new animals are added to the animals array we need to modify the animal_sound() function. For every new animal, new logic needs to be added and the same change would be done at multiple places if our application becomes more complex, as is the case with actual projects.

Solution?

Interfaces

What is an Interface?

An interface is a description of the actions that an object can do. For example when you flip a light switch, the light goes on, you don't care how, just that it does.

In Object Oriented Programming, an Interface is a description of all functions that an object must have in order to be "X".
Again, as an example, anything that "ACTS LIKE" a light, should have a turn_on() method and a turn_off() method. The purpose of interfaces is to allow the computer to enforce these properties and to know that an object of TYPE X must have functions called A, B and C.

On a high level it acts like blueprint for designing classes.

How to use Interfaces to conform to Open Closed Principles?

Python doesn't enforce all the classes implementing the interface to define all the interface's abstract functions unlike other languages (Java, C#, C++ etc.)

So let's take a look at how to make this work in Python.

If you are interested in learning how other languages implement interfaces you can take a look at this Digital Ocean's blog.


class Animal:
    def __init__(self, name):
        self.name = name

    def get_name(self):
        pass

    def make_sound(self):
        pass


class Lion(Animal):
    def make_sound(self):
        print("roar")

class Mouse(Animal):
    def make_sound(self):
        print("squeak")

class Cow(Animal):
    def make_sound(self):
        print("moo")

def animal_sounds(animals):
    for animal in animals:
        animal.make_sound()

animals = [
    Lion(name="Big Cat"),
    Mouse(name="Squeakie")
]

animal_sounds(animals)

Animal class now has a make_sound abstract function. Other animal classes (Lion, Mouse etc.) have extended the Animal class and implemented their own definition of make_sound function.

The animal_sounds function iterates over the animals and calls their implementation of make_sound function.

Now if a new animal needs to be added we don't need to change the Animal class, we can implement a new class for that animal and animal_sounds() will call the implementation of make_sound function for that animal.

Thus the Animal class now conforms to the Open Closed Principle of Programming.

My Sources:

This post is Part 2 of the series, Back to Basics, each covering one SOLID principle.

Back to Basics: SOLID Principles (Part 1)

Khushboo Parasrampuria — Tue, 03 Aug 2021 16:41:02 +0000

SOLID is an acronym for the 5 programming principles which stands for:

Single Responsibility Principle
Open Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

Why should you care about these principles you ask?

These principles help you in changing one area of the software without impacting others. Basically, they’re intended to make the code easier to understand, maintain, and extend.

This post is just Part 1 of the series, Back to Basics, each covering one SOLID principle.

Single Responsibility Principle

A class should have one and only one reason to change which means it should only have one job.

If a class has more than one responsibility then changing one responsibility results in modifications in other responsibilities.

Let's take an example:


class Animal:
    def __init__(self, name):
        self.name = name

    def get_name(self):
        return self.name

    def save(self, animal):
        """Saves the animal details to DB"""
        pass

Now the Animal class has two responsibilities:

Maintain the properties of the animal
Save the animal details in a database

If the application changes in a way that it affects the database management functions, for example: save() function, then the classes that use the properties of the Animal class will have to be updated and recompiled.

Solution?

We create another class which will handle all the database management responsibilities.


class AnimalDB:
    def save(self, animal):
        """Saves the animal details to DB"""
        pass

    def get_animal(self, _id):
        """Gets the animal details by _id from the DB"""
        pass

class Animal:
    def __init__(self, name):
        self.name = name
        self._db = AnimalDB()

    def get_name(self):
        """Get animal name"""
        return self.name

    def save(self):
        """Saves the animal to DB"""
        self._db.save(animal=self)

At the time of designing our classes, we should always put related features together so whenever they tend to change they change for the same reason and try to separate the features that will change for different reasons.