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:
vishal-keshav
/ random_thoughts.md
Created
January 12, 2019 14:30
How to remain technically relevent!
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.
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
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
/ software_engineering.md
Created
January 15, 2019 17:06
Importance of writing a good piece of code
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
/ oops_part1.md
Last active
January 25, 2019 08:41
On Object oriented programming and design patterns in C++ part 1
- 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
/ oops_part2.md
Last active
January 25, 2019 09:20
On Object oriented programming and design patterns in C++ 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
/ oops_part3.md
Last active
January 25, 2019 10:12
On Object oriented programming and design patterns in C++ part 3
vishal-keshav
/ oops_part4.md
Last active
January 25, 2019 12:03
On Object oriented programming and design patterns in C++ part 4
vishal-keshav
/ oops_part5.md
Last active
January 26, 2019 10:36
On Object oriented programming and design patterns in C++ part 5
We better revisit some of the concepts learned previously.
-
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.
-
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
/ oops_part5_last.md
Last active
January 26, 2019 12:29
On Object oriented programming and design patterns in C++ part 5 (complete)
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.
#include "stdafx.h"
#include <iostream>OlderNewer