DEV Community: Shubham Kumar

Open Source 101: Getting Ready for Hacktoberfest 2023

Shubham Kumar — Sat, 30 Sep 2023 15:03:11 +0000

With Hacktoberfest 2023 kicking off tomorrow, developers are gearing up to contribute to open-source projects. But have you ever stopped and wondered: What does "open source" truly mean?

When I kicked off my coding journey, "open source" sounded like just another buzzword for sharing code. But as I read more about it, I realized its significance came from the ideas of community, collaboration, and freedom. This philosophy is defined by the Open Source Initiative (or OSI, to keep it short) which sets clear standards for what genuinely counts as "open source."

The OSI presents these 10 points that software must check off to wear the open-source badge proudly. While I've listed them below for a quick glance, dive deeper into The Open Source Definition if you're curious.

1. Free Redistribution

You can share the software freely, sell it or give it away. No one should charge you just for the right to share it.

2. Source Code

The software should come with its recipe (code). If it doesn't, there should be an easy way to get it, preferably for free.

3. Derived Works

You can make changes or improvements to the software, and you should be able to share those too under the same rules/license.

4. Integrity of The Author’s Source Code

If you change the original software, you might have to mark your changes or give it a new version number. It’s a way to respect the original creator's work.

5. No Discrimination Against Persons or Groups

The software is for everyone, no matter who they are.

6. No Discrimination Against Fields of Endeavor

Whether you're using the software for work, play, research, or anything else, you're good to go.

7. Distribution of License

When you share the software, the rules should go with it. Nobody should have to get a new license to use or share it.

8. License Must Not Be Specific to a Product

The rules should be the same, whether the software is part of a package or stands alone.

9. License Must Not Restrict Other Software

If you want to bundle this software with another, the license shouldn’t have issues or conditions about the other software.

10. License Must Be Technology-Neutral

No matter what technology you're using (old, new, or futuristic), the software rules shouldn't favor one over another.

So as you can see, the spirit of open source goes beyond software development. Think about it like sharing a recipe or jamming together in a garage band. It’s about everyone chipping in, whether it’s in projects, art, or even that side-project app, hence upholding the principles of redistribution, collaboration, and non-discrimination

So, as you gear up for Hacktoberfest 2023, remember that each of your contributions is more than just a pull request — it's a step toward a vision of shared knowledge and innovation. Each bug report, feature enhancement, or documentation update carries the weight of this philosophy.

Every single contribution, however small, will be impactful, one way or the other. This Hacktoberfest, as you contribute, know that you're not only adding to a project, but you're also embracing and promoting a philosophy that believes in the limitless potential of collaborative innovation.

Happy Hacking !!

Converting date to relative time format in TypeScript

Shubham Kumar — Sat, 16 Oct 2021 05:31:02 +0000

If you are developing an application which has to display timestamp for posts/comments/notifications, you might come across this requirement where you have to format time in "from now" format. This is sometimes called timeago or relative time.

You can either use a third party library like dayjs or momentjs for this, but for small projects, it is better to come up with your own utility function. In this tutorial we will write a util function which will accept a javascript Date object/ a string in ISO YYYY-MM-DD format/ or a date timestamp and convert it to relative time.

Eg:  2020-10-15 will be converted to "an year ago"

JavaScript Date objects represent a single moment in time in a platform-independent format.It is is fundamentally specified as the number of milliseconds that have elapsed since midnight on January 1, 1970, UTC.

To convert the an input date to relative format, first we will define our time boundries in unit which we want to keep out least count. I am taking it in seconds, so the smallest difference that my method can return will be in seconds.

const units = [
  { label: 'year', seconds: 31536000 },
  { label: 'month', seconds: 2592000 },
  { label: 'week', seconds: 604800 },
  { label: 'day', seconds: 86400 },
  { label: 'hour', seconds: 3600 },
  { label: 'minute', seconds: 60 },
  { label: 'second', seconds: 1 }
];

Let's write our util method now. We will input a date and find the difference between the input and the current moment. We can get the current date by using the Date API and calling the valueOf method on a new instance of Date object. The inout date is then subtracted from this value. Now we find the nearest unit to the input date. The method calculateTimeDifference will take the milliseconds equivalent of Date for simplifying calculations. The nearest unit will be the one which has the quotient greater than 1 as we have defined our units in decending order. Once we get the quotient greater than 1, we will return that value with the respective unit. That will be used to contruct our string. You can check the snippets below:

const timeAgo = (date: string | number | Date) => {
  const time = Math.floor(
    (new Date().valueOf() - new Date(date).valueOf()) / 1000
  );
  const { interval, unit } = calculateTimeDifference(time);
  const suffix = interval === 1 ? '' : 's';
  return `${interval} ${unit}${suffix} ago`;
};

const calculateTimeDifference = (time: number) => {
  for (let { label, seconds } of units) {
    const interval = Math.floor(time / seconds);
    if (interval >= 1) {
      return {
        interval: interval,
        unit: label
      };
    }
  }
  return {
    interval: 0,
    unit: ''
  };
};

Want to avoid git's annoying password prompts for every push? Configure SSH keys for Github

Shubham Kumar — Sat, 02 Oct 2021 21:52:47 +0000

Are you using HTTPS protocol to communicate between your local repos and Github? If yes, then just think–all of that time you spent entering your email address and password into the terminal every time you push a commit could have been spent coding. Guess what? you could have saved all that time by simply enabling SSH for your GitHub account. In this post, we will try to create an SSH key and add it to your Github account for "better" way of GitHub authentication.

What the heck is SSH anyway?

SSH or Secure Socket Shell, is a network protocol that gives users a secure way to access a computer over an unsecured network. It allows the remotely login to a server using the connection established between your system's shell and the server's shell.

Let's Setup SSH Keys for your GitHub

Navigate to your $HOME and change into .ssh directory.

Inside the .ssh folder, you can generate a key using the following command:



ssh-keygen -t rsa -b 4096 -C your@email.com

Replacing your@email.com with your Github email. You can either keep the default filename id_rsa or you can provide a custom file name.

Dissecting the command

The ssh-keygen command creates RSA and DSA keys for public key authentication. It can also used to edit properties of existing keys, and to convert file formats. The command takes the following options

ssh-keygen [-b bits] -t alog-type [-N [passphrase]] [-C comment] [-f output_keyfile]

When no options are specified,ssh-keygengenerates a 2048-bit RSA key pair and queries you for a key name and a passphrase to protect the private key. Public keys are created using the same base name as the private key, with an added .pub extension. The key location is displayed when key generation is complete.

Important Note: You should never reveal your private key, and only use your public key for things like GitHub authentication.

Add your SSH key to ssh-agent

ssh-agent is a program that starts when you log in to your system. It has all your private keys. To add the key to the ssh-agent first we need to check if it is up and running.



// If you are on Mac/Linux:
eval "$(ssh-agent -s)" # for Mac and Linux

// If you are using Windows use:
eval `ssh-agent -s`
ssh-agent -s

If it is running you will see and output like this:

This tells us that the agent and up and running on the specified port number.

You can then move ahead to add your key to the agent by using the following command:



ssh-add ~/.ssh/id_rsa

Note: If you used a custom file name for your keys, use that instead of id_rsa

Now we have to copy our public key:



// For linux/mac terminal use this:
cat ~/.ssh/id_rsa.pub # Linux

//For Windows use this:
clip < ~/.ssh/id_rsa.pub

Adding the public keys to your Github account:

Go to your GitHub Account -> Settings -> SSH & GPG Keys.
Click on add new key.
Provide a title and paste in your public (id_rsa.pub) key:

Testing Github Authentication

Try this in the terminal



ssh -T git@github.com

If everything goes well, it will return:



Hi GithubName! You've successfully authenticated, but GitHub does not provide shell access.

Note: If you provided a passphrase during generating the key, you might have to use that as the password.

That's it you have successfully generated and configured an SSH key for your Github authentication. Happy Coding !!!

JavaScript Hoisting - behind the scenes

Shubham Kumar — Sun, 26 Sep 2021 08:49:35 +0000

In this post, I want to talk about how hoisting mechanism occurs in JavaScript.Before we dive in, let’s define what hoisting is.

Hoisting is a JavaScript mechanism where variables and function declarations are moved to the top of their scope before code execution.

Consider this code. Can you guess what is the output at line 3? :

a = 2;
var a;
console.log( a );

Many of us would expect it as 'undefined' , since the 'var a' statement comes after the a = 2 , and it would seem natural to assume that the variable is redefined, and thus assigned the default undefined . However, the output will be 2, due to hoisting.

Hence,hositing allows us to use variables and call functions before even writing them in our code. Now this can be very confusing if you are coming from a different language like Java, where you need to define a variable first before using them.

Let's consider another example, can you guess the output now?:

console.log( a );
var a = 2;

The output here will be undefined. This goes on to show that the hoisting mechanism only moves the declaration. The assignments are left in place.

But, this doesn't mean that during the compilation the JS Engine magically restructures your code to move all the declarations to the top of the scope. This behaviour is a result of the two phases that the program goes through - the compilation and the execution phase.

During compilation phase, the code lexing and tokenizing phenomenon occurs. This simply means it will split our code into atomic tokens like a, = and 2.(A token is a single element of a programming language).
Note that no assignment or evaluation takes place during this phase.

Each time the compiler encounters a declaration, it sends it to the scope manager to create the binding. For each declaration it allocates memory for that variable. Just allocates memory, doesn’t modify the code to push the declaration up in the codebase. And as you know, in JS, allocating memory means setting the default value undefined.

After the compilation phase we go to execution phase, Where each time the engine encounters an assignment or an evaluation(e.g a function call/expression evaluation), it asks the scope for the binding. If not found in the current scope, it goes up into parent scopes until it finds it, and then the evaluation is done with that binding.

Hence the second snippet is excecuted as follows:

Compilation phase or first pass:

console.log(a) // skipped as it is an evaluation

var a = 2; 
/* 
This has two parts -
    1. A declaration part: var a 
    2. An assignment part: a = 2. 
The compiler only deals with the declaration part, 
and allocates memory for variable 'a'. 
The assignment will happen in excecution phase.
*/

Execution phase or second pass:

console.log(a)
/*
console.log() function called with a. 
The engine looks for the variable 'a' in the scope, and finds it,
for now has the value undefined, so prints it.
*/
var a = 2;  
/* 
The engine executes the assignment operation.
Looks for the variable 'a' in the scope chain and finds it.
Assign 2 to it.
*/

This also happens with function declarations. Let's look at this example.:

foo();
function foo() {
    console.log( a );
    var a = 2;
}

// Compilation Phase:
foo(); // As this is evaluation, this line is skipped

function foo() {
    console.log( a );
    var a = 2;
}
/* 
The complier sees a declaration with identifier foo, hence memory is allocated to it
As it is a function and a new scope is also created.
It then again encounters a declaration for an indentifier a, so it allocates it to the memory.
*/

// Excecution Phase:
foo();
/* 
The engine looks for the identifier foo in the
scope chain. 
It finds and pull out the value that foo is referencing to- the statements inside it.
() executes the function,and the excecution moves inside foo function
It encounters a call to console.log() with argument a, which at this time is 'undefined'.
It prints undefined.
Execution moves to next line and encouters an assignment.
It looks for identifier a in the function scope and assigns value 2 to it.
The execution moves outside to global scope.
There are no more execution statements, so the program stops.
*/

We should also note that, Function declarations are hoisted, as we just saw, but function expressions are not. The reason being, assignment is done during execution phase.

foo(); // not ReferenceError, but TypeError!
var foo = function bar() {
    console.log('Inside bar')
};

Here, the variable identifier foo is hoisted and attached to the global scope, so foo() doesn’t fail as a ReferenceError .
But foo has no value yet, so foo() is attempting to invoke the undefined value, which is a illegal operation. Hence it throws TypeError

Note: Both function declarations and variable declarations are hoisted, but as function declarations take precedence to variable declarations, functions are hoisted first and then variables.

This can be illustrated by below snippet:

foo(); // Output is: 1
var foo;
function foo() {
    console.log( 1 );
}
foo = function() {
    console.log( 2 );
};

Hositing with `let` and `const`

Variables declared with let and const are also hoisted, but unlike for var the variables are not initialized with a default value of undefined. Until the line in which they are initialized is executed, any code that accesses these variables will throw an exception.

Variables declared with the keyword let are block scoped and not function scoped. It just means that the variable’s scope is bound to the block in which it is declared and hence during compile time, memory is allocated for the variable declared with let, but it is initialized to a value only when a parser evaluates it.

Note: Unlike var, accessing the variable declared as let or const before the initialization results in a ReferenceError. For var variables, they return a value of undefined if they are accessed before they are declared.

Hence, the below code snippet will return ReferenceError

console.log(a); 
// Output: ReferenceError: a is not defined ...
console.log(b);
// Output: ReferenceError: b is not defined ...
let a = 10;
const b = 11;

To conclude, we can say that a JS program is parsed and executed in two passes, because of which concept of hoisting comes in to picture.

Spring Projections

Shubham Kumar — Thu, 31 Dec 2020 14:04:58 +0000

If you have used Spring Data JPA, you must be knowing that all the query methods of Repository classes will return an entity object. There may be cases where we do not want an entire entity from the query method. We may be interested only in few attributes of that entity or subset of that entity with some manipulation in it. In those cases, we can use "Projection" which projects us only the required data out of entire entity class.

For example, lets say we have an entity class for Employee and we want to query our database based on this entity.

@Entity
@Table(name = "employee")
public class Employee implements Serializable {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id", unique = true, nullable = false)
    private Long id;

    @Column(name = "firstName")
    private String firstName;

    @Column(name = "lastName")
    private String lastName;

    @Column(name = "designation")
    private String designation;

    @Column(name = "salary")
    private Integer salary;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "departmentId", updatable = false, insertable = false)
    private Department department;

    @Column(name = "departmentId")
    private Long departmentId;

    public Long getId() {
        return id;
    }

    public String getFirstName() {
        return firstName;
    }

    public String getLastName() {
        return lastName;
    }

    public String getDesignation() {
        return designation;
    }

    public Integer getSalary() {
        return salary;
    }

    public Department getDepartment() {
        return department;
    }

    public Long getDepartmentId() {
        return departmentId;
    }
}

And instead of returning the whole entity we only need Id, First Name, Last Name, and Department Name of Employee.

One way could be to use Data Transfer Object(DTO). The goal of a DTO class is to provide an efficient and strongly typed representation of the data returned by your query. To achieve that, a DTO class typically only defines a set of attributes, getter and setter methods for each of them, and a constructor that sets all attributes. But, this process can be simplifed by using spring projections.

There are two ways in which we can use projections while using Spring Data JPA:

Interface based
Class based

In this article, we will discuss Interface based projections.

Interface based projections

As the name suggests we will use an interface here. One can create an interface with only getter methods of properties we want from an entity class. This interface can then be the return type of query method we write in Spring Data JPA’s Repository interface.

Example 1 -

First we will create a interface with our desired properties:

public interface EmployeeProjectionOne {
    Long getId();

    String getFirstName();

    String getLastName();

    DepartmentDetails getDepartment();

    interface DepartmentDetails {
        String getName();
    }
}

You can simply add this interface as a return type of query method in your Repository interface:

@Repository
public interface EmployeeRepository extends JpaRepository<Employee, Long> {
    List<EmployeeProjectionOne> findByFirstName(String firstName);
}

This type of projection is called "Closed Projection" and in this case, the getter methods of interface match exactly with the getter methods of Entity’s properties.Also note that, recursive projections only work if we traverse from the owning side to the inverse side(Employee to Department). Were we to do it the other way around, the nested projection would be set to null.

Example 2 -

One can also use so called Open Projection,where we create interface with getter methods of selective properties only with Spring Expression Language(SpEL) expression. These projections enable us to define interface methods with unmatched names and with return values computed at runtime.
The SpEL expression will help us to define a new property from existing properties. Like in the above case if we want a property “fullName” then we can define it using SpEL expression and @Value annotation. Likewise, we can also define a new property from nested property of entity class.

public interface EmployeeProjectionTwo {
    Long getId();

    @Value("#{target.firstName} #{target.lastName}")
    String getFullName();

    @Value("#{target.department.name}")
    String getDepartmentName();
}

And in the respository we can simply use:

@Repository
public interface EmployeeRepository extends JpaRepository<Employee, Long> {
    List<EmployeeProjectionTwo> findByLastName(String lastName);
}

We can also define default methods in the projection-type interface to achieve the same thing, but it will just like writing boilerplate code.

Example 3

Now, based on your needs you can define 'n' number of projections for your entity class, but defining separate repository interfaces or methods for these multiple return types is too much of work.
To simplify this Spring data enables you to define what projection type to return from the query method at runtime dynamically. One will often come across this scenario while developing REST APIs so this is really a handy one.
Include a new argument to query method of type Class and set it with your projection type as follows:

@Repository
public interface EmployeeRepository extends JpaRepository<Employee, Long> {

 List<T> findByFirstName(String firstName, Class<T> tClass);
}

Then invoke the repository method from the service class:

@Override
public List<EmployeeProjectionTwo> getAllByDynamicProjection() {
    return employeeRepository.findByFirstName("A", EmployeeProjectionTwo.class);
}

This type is called Dynamic projection because the attributes to return from the query method can be set during runtime.

These are the 3 types of Interface based projections that can be used in Spring Data JPA- Open, Closed and dynamic types. I will also be covering the class-based projects in a separate article, so if you liked this article stay tuned for part 2.

Git Rebase vs. Git Merge

Shubham Kumar — Mon, 28 Dec 2020 19:44:11 +0000

Every developer from the Git community has either faced the git merge vs git rebase dilemma or has been a part of this debate. Any git beginner is advised to stay away from git rebase as it is a destructive process, but I find it as a great tool to simplify our development process within a team if used carefully.
In this post, I’ll compare git rebase with the related git merge command and identify all of the potential situations where we can use rebasing in the typical Git workflow.

Rebase and merge, both solve the same problem - both these commands are designed to integrate changes from one branch into another branch. They differ in the manner in which they achieve this.

To understand the working of these commands, let assume that you started working on a new project. You head to the repository, fork it, set up your local workspace, and start working in your feature branch. Meanwhile, a colleague of yours makes a commit in the master branch of the repository. And your history looks something like this:

To get these new commits into your feature branch, you have two options: merging or rebasing.

Git Merge

Suppose you use the following commands and merge your changes:



git fetch
git merge feature-branch master

This creates a new “merge commit” in the feature branch that ties together the histories of both branches, giving you a branch structure that looks like this:

This will also create a new merge commit in your log. Merging is nice because it’s a non-destructive operation. The existing branches are not changed in any way and the history of your branch is preserved.

But, every time you sync your fork with the upstream you will be creating an extra merge commit to incorporate the changes. If your master is very active, your feature branch history will be loaded with the merge commits. This might give hard time to someone who goes through your branch/project history.

Git Rebase

As an alternative to git merge you can do:



git fetch
git checkout feature-branch
git rebase origin/master

This moves the entire feature branch to begin on the tip of the master branch by combining all the changes of the master branch into a single “patch” and then integrate it onto the feature branch. But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the master branch. In the process, unwanted history is eliminated. Hence, your tree will look like something like this:

And this is the major benefit of rebasing - A clear and linear project history. It has eliminated the unnecessary merge commits required by git merge. And now that you have a linear project history, you can follow the tip of the feature all the way to the beginning of the project without any forks. This makes it easier to navigate your project with commands like git log or git bisect. The only downside of using this is that now we will never know when was the upstream changes incorporated in our feature branch.

But what if I told you that you can completely alter the project history and make it look as you want it? Powerful isn't it?

Interactive rebasing - rewrite history your way

Interactive rebasing will give you complete command over your commit history as you can alter commits as they are moved to the new branch. Usually, we use it to clean up a messy history before merging a feature branch into master. For example combining previous "work in progress" commits, which have been completed.



git checkout feature git rebase -i master

This will open the editor with the list of your commits, and you can choose to pick, squash the commits to make the history look as you want.

When to use rebase???

If you are working on your branch individually, rebasing makes a lot of sense. You can use rebasing to streamline a complex history, you can also change the commit history by interactive rebase. You can remove undesired commits, squash two or more commits into one, or edit the commit messages before creating your Pull Request. This will also simplify the work of the reviewer as he/she will have to go through a clean commit history.

If you want to see the history completely the same as it happened and avoid the risk of re-writing public commits, you should use git merge.

The most important thing to learn about rebasing is when not to do it. The golden rule of git rebase is to never use it on public branches, the common branch which all developers will use as it will create inconsistent repositories which can result in your fork diverging from the main repository.

For example, let's say we rebased our master onto our feature branch using



git checkout master
git rebase origin/feature-branch

This action will move all the commits in your feature branch first, then the commits of the master will be put on its tip. The problem is that this only happened in your repository. All of the other developers are still working with the original master. Since rebasing results in brand new commits, Git will think that your master branch’s history has diverged from everybody else’s.

The only fix now is to merge the two master branches together, but it will result in an extra commit with both sets of changes, the original master commits, and your rebased feature branch too...

So, before you run git rebase, always ask yourself, “Is anyone else looking at this branch?” If the answer is yes, bad news, stick to the normal git merge process, otherwise, feel free to rewrite history as you like.

5 things I learnt in 2020 for productive git collaboration.

Shubham Kumar — Sat, 26 Dec 2020 19:32:28 +0000

Until last year, I used git quite recklessly, writing bad commit messages and never taking a pause to think about the code and the manner in which it was being pushed. Things changed as I collaborated more and more with other developers for projects and after working with agile teams for over a year now, here are 5 things I have learned form my experience:

1. Keep your PR's "Atomic"

Let’s say you are working on designing the layout of your web app, and you were tasked with a simple bug fix in the same component. Though it is tempting to commit both the changes and to raise a PR together, our layout changes and the bugfix should go as separate PRs. By doing that you are creating an organized log of commits, which makes it easy for other developers to read and maintain the code base. It will also help your code reviewers, who can glance through the commit history and find what they are looking at easily.

You should also be aware of what you are committing in your repository, and not just do git add . blindly every time and put it up in your PR.

2. Use branch workflows

Try to create and follow a git workflow within the team, the main advantage of doing so is that you will be keeping your development process organized and improving the overall code quality. A good git workflow ensures a clean state of branches at all times.

In my current project, we follow the feature-based git workflow and have 4 types of branch, each for a specific purpose:

master: "The golden copy" of the source code.
develop: The stable branch from where new branches are cut. How is this different from master? The master branch stores the official release history, and the develop branch serves as an integration branch for the features.
feature: When we start working on a new feature, we cut off a feature branch for it from develop branch. For example, if we start working on a login page for a web app, we can create a branch as feature-login.
This helps in tracking the progress of user stories/defects in an agile development environment and also keeps your features separated in commit logs.
release: For every release, a new branch is cut and maintained. Why? Because the new additional features of v2.0, should not be present in v1.0. It is cut from develop branch when the release is production ready.

3. Mark incomplete commits with "WIP"

If you are not finished with the feature you have been working on by the end of the day, make a temporary commit with “WIP” appended to the message. This signifies that your commit is a “Work in progress”. When finished, one can squash all the commits in a single one and create the PR.

4. Give meaningful commit messages:

When you are ready with your changes and ready to make a commit, do your best to make it a meaningful one by giving a proper message. Before crafting a commit message, take a minute and put yourself in the shoes of your fellow developers seeing this change for the first time. Would you understand what code has changed in this commit? Would you know why the code changed?
Your commit message is supposed to convey these messages. I follow this pattern:

"[feature/defect id] - type: description"

The general types of commits one can encounter are as follow:

feat - a new feature
fix - a bug fix
docs - changes in documentation
style - everything related to styling
refactor - code changes that neither fixes a bug or adds a feature
test - everything related to testing

5. Write unit tests

One thing that I always ignored while learning programming was unit testing. If a developer performs proper unit testing, his defect density can drop significantly.
Writing unit tests forces us to consider how well the production code is designed in order to make it suitable for running our tests. It will also help you to code from a different perspective, encouraging you to consider corner cases and error conditions in the implementation. Most importantly, it identifies defects at early stages and also helps in safely refactor your code later, since tests can be re-run quickly to validate that behavior has not changed.