vishal-keshav

Design Principles Part 5 (final)

From previous part, we may not know if a company conform to the APIs it used to design the camera driver. In such a case, we need to use adapter pattern. Adapter pattern bridges the gap of uneven APIs to a set of consistent APIs. Abstraction leads us to tread the device driver consistently.

Implementation

#include "stdafx.h"
#include <iostream>

vishal-keshav

Design Principles Part 5

We better revisit some of the concepts learned previously.

1. Single responsibility principle: An object should perform only one work and not multiple unrelated work. basically, it should have one reason to change, not multiple reseason to change.

2. Open close principal: Open for extension and closed for modification, when client wants to depend on varying implementation. This can be achieved with loose coupling.

Loose coupling can be achieved by creating abstraction for varying implementation.

vishal-keshav

Design Principles Part 4

Callbacks

Callbacks are important pattern in C++. TO understand this, lets consider a problem of printing the multiplication table of a number which is inputed by user.

A naive implementation

vishal-keshav

Design Principles Part 3

RAII pattern

Resource allocation is initialization: This is an important design pattern mostly followed to operate on threading safely.

To understand the criticality of usage of RAII pattenn, we can see the code below.

#include "stdafx.h"

vishal-keshav

Design Principles Part 2

In order to understand the factor pattern and why it is used, we consider to implement a program. The program is described as follow: The program should give the user an ability to to choose among several avaialable shapes (through command line argument) and once choosen, it should accept the parameters of the chosen shape. When user enters the required information, the progrma should display the shape. Moreover, the program should store the displayed entry as well. All the stored shapes can be redrawn at later stage.

Below is a snippet of user interacting with the program:

0 Redraw
1 Circle

vishal-keshav

Design Principles Part 1

SOLID Principals

• S – SRP – Single Responsibility Principle
• O – OCP – Open Close Principle (Code open for extension but close for modification)
• L – LSP – Liskov Substitution Principle
• I – IS – Interface Segregation
• D – DI – Dependency Inversion

All the above pricipal tends to achieve extensibility, reusability, and maintainability of an application.

vishal-keshav

To start anything, we should have a plan. And to execute the plan, we should have a system in place. However, sometimes we start with a plan but we find ourselves in a mess after a while. This mess happens not because our plan was bad, it was because we did not have a system in place that could have helped in easy execution of the tasks.

The same is true with software engineering or working on a research project. For example, suppose we want to work in an area and want to publish something. We create a plan, that includes reading several papers, experimenting with the idea, changing it and coming up with a new idea, experimenting with it and then publishing the good results. The plan is fantastic, but the ground reality is that it will almost always never work unless we have figured out a system to execute is easy. Here, the system would be to gain enough knowledge before reading a paper, setting up the code base where we want to experiment, determining our criteria of a “good” result, and figuring out a met

vishal-keshav

When does a conflict happen?

When someone tries to make changes (edit or delete) some lines in the same file where you are making changes.

git fetch remote will fetch the changes to the current branch. But when we try to rebase with the fetched changes git rebase remote/branch_name, error something like this can come.

First, rewinding head to replay your work on top of it...
Applying: some_commit_name
Using index info to reconstruct a base tree...
A       file_path/file_name.cc

vishal-keshav

How to remain technically relevant in a tech-driven industry

As I advanced in my career, starting from a software engineer to a lead engineer, I have realized that it is very important to remain technically sound, not just by knowing stuff but having the ability to showcase what we really know. Tech industry is changing very rapidly, and in this fast-moving world, it has become very important to quickly pick up what to learn and how integrate ourselves with the skills that may serve great purpose going forward. So, here is my take on what to do to remain technically relevant.

Keep brushing up the concepts acquired during college.

Just like everything else, there is a wear-and-tear that happens to the knowledge we gain when we are at the highest point of our learning career. We may not realize it, but when we are at college, we work for ourselves and just for ourselves. When we join the workforce, things change a little bit, and we are hit by the responsibility and expectations of a larger entity. To

vishal-keshav

Keybase proof

I hereby claim:

• I am vishal-keshav on github.
• I am vkeshav (https://keybase.io/vkeshav) on keybase.
• I have a public key ASDSMW2mvItIolC3rdX7olL4xnF2q-No3vGTVJ6iGoag-wo

To claim this, I am signing this object: