Forem: Yeganathan S

Every developer should have these three things

Yeganathan S — Wed, 05 Jan 2022 14:07:34 +0000

Hi there,

Starting career as a software developer? Then this article is for you! Here I'm gonna discuss three main things that every developer should have. Being a developer myself, I found out how important they are. So let's start!

LinkedIn is one of the power tools which helps you connect with people, strengthen professional relationships and find the right job or internship. It provides a professional environment where people share their learnings, interview experiences, and many more. Even if you are not a developer, LinkedIn helps you connect with the people in your field of interest. You could connect with experts from top companies and ask your queries directly regarding the role, interview preparation, and more.

The main reason I joined LinkedIn was to make connections with talented professionals in my domain of interest. It's not just about creating an account on LinkedIn but optimizing the profile perfectly also matters.

To make it simple, LinkedIn is another version of your resume. Sometimes while recruiters search for professionals, one might look into your profile, which could eventually lead to job opportunities.

Github

Github is one of the core elements of every developer's life. For those who don't know about the platform, it's the place where ideas get crafted by builders, codes are stored/shared, and collaborations with other developers happen. Although there are quite a few platforms with the same beat, Github is still considered to be one of the most popular platforms in the developers' community.

It is a paradise for many developers. Most recruiters check our Github profile for our past projects as it shows the consistency and gradually working with tools & technologies. There are n-number of open-source projects to work on in Github. Same as in LinkedIn we can collaborate with other developers on Github, especially on open-source projects, and learn from them. Anyone who loves to code can contribute, so why wait? Start your contribution today.🛠

Portfolio / Personal Website

Last but not least, every developer should have a portfolio that shows their skills and achievements. Your portfolio has to display that you're a technology expert and that you write good quality code. If you've worked on personal projects a lot and the technology you've used is relevant then you should include them in your portfolio.

It simply serves as proof of your accomplishments. By now, you may wonder, why have both Github and Portfolio when both more or less shows our skills? Well, in Github you show only your technical side whereas, in a portfolio, you could also add non-technical side achievements and a lot more about you.

I want to conclude that these, although the key elements are not the only requirements that a developer should fulfill. Just creating an account on LinkedIn or Github or making a simple portfolio doesn't make much impact, and that optimizing those matters equally.

Hope this article helps you,

Happy Coding❤️

Updating the deployed hugo site

Yeganathan S — Fri, 19 Mar 2021 08:17:58 +0000

Hi there!
In the previous article, we were discussing how to create a portfolio with Hugo and deploying the same in Github pages. if you didn't check out yet, then do check out here and give it a read 😃

This blog is a continuation of the same and in this, I'm going to share how to update hugo site which has already been deployed.

For instance, let's say I need to add my previous article to the blog section of my portfolio and update the same in the deployed site.

Since we created 2 separate repos for our hugo site, we need to push commits of both the repositories ( hugo_site and username.github.io )

In order to start, we need to open our hugo_site directory in the terminal.

First, make sure all the commits in local and remote are the same. so let's pull those if there are any changes in the remote.

$ git fetch origin 
$ git rebase origin master

Now as usual open the files in the editor and shoot up the terminal and write the following commands in order to start our local server.

$ hugo server -D

Do the updates/changes and make sure everything is perfect.

Stop the server now and type the following commands in the terminal...

$ hugo

This is to regenerate HTML files in our username.github.io submodule

After generating the HTML files, go to the username.github.io directory and push all the commits to the same.

$ cd <username.github.io>
$ git add .
$ git commit -m "committing the regenerated html files"
$ git push origin main

the last command triggers Github to rebuild our page with the changes we've made.

Now again come back to the parent/previous directory and push all those commits to our hugo_site repository.

$ cd ..
$ git add .
$ git commit -m "committing the hugo changes and updated submodule"
$ git push origin master

⚠️ Note ⚠️
Make sure that you push files to the respective repos and branches.

error: src refspec master does not match any

If you face any similar error like this then probably you should check the branching you're pushing.

Pro-Tips for faster page loads 🔫

Check PageSpeed always after deployment.
Avoid using 4k resolution images or videos on your site.
Try using Webp format for images rather than jpeg and png.

Hope this article helps you!
Happy coding 👨🏻‍💻

Create and Deploy your portfolio with Hugo!

Yeganathan S — Thu, 04 Feb 2021 18:27:55 +0000

Hello everyone 👋🏻

Have you just thought of making a portfolio or any static site then you're in the right place. In this article, I'm gonna share my experience ( also experiment ) with Hugo.

But before getting into it, let me give a brief introduction about Hugo...

What is Hugo?

Hugo is a general-purpose website framework. Technically speaking, Hugo is a static site generator. Unlike systems that dynamically build a page with each visitor request, Hugo builds pages when you create or update your content. Since websites are viewed far more often than they are edited, Hugo is designed to provide an optimal viewing experience for your website’s end users and an ideal writing experience for website authors.

What we are going to do?

We're gonna take a theme and customize as per our needs and deploy it on Github pages.

Why Github pages?

This is one of the easiest and simplest way of all. But still, we can also do the same in any other services like Netlify, Heroku and etc.

Prerequisites 🚀

Hugo and Git should be installed. if you didn't install it yet, then check out the following links.

[1] - Installation of Hugo
[2] - Installation of Git

A Github account and knowledge of basic git commands.

To make it simple, I have made this blog into step by step process just like farming 🍀

Let's start making wonders with Hugo 🎉

Preparation of soil 🪵

The best part of Hugo is, we can take a theme and pretty much work on it just like a word doc. so I have chosen a template already if u didn't yet, then go and find one for yourself here.

This is the template I have chosen for today's demo Hello-friend-ng 💐

Sneak peek of it 🤩

Note:

Github pages can't render Hugo files directly so we will be creating 2️⃣ repositories. Once we complete making changes in the template, Hugo helps us to generate static files. The reason for the 2️⃣ repositories is that one is used for Hugo files and the other for static files generated out of it.

Hope you have installed Hugo & git already, now it's time to fire up your terminal.

Type the following command,

$ hugo new site quickstart

quickstart - it's just a directory name the files will be created.
After doing the same now, if you check out the quickstart directory you will be seeing some files/folders. Those are necessary files required for any hugo site and hugo generates those for us.

Now let's move into the quickstart directory and import the theme,

$ cd quickstart
$ git init
$ git submodule add <them_github_repo_link>

Note: An empty git repository is initialized inside the quickstart directory so that we can add the theme as a submodule.

Now when you check the themes directory you will be seeing all those files of our theme.

Sowing ⚙️

There will be an examplesite folder inside the themes directory, copy and replace all the contents of examplesite under project directory ( or outside of themes directory )

When it comes to hugo, config.toml is the main file for our site.

Look at the config.toml file and change the necessary details in it except the baseURL.

We can find a description/comments of each variable inside the config.toml so that we can make changes without messing up with the other things.

baseURL = "localhost"

baseURL should be always localhost before deployment.

Prototype 🔫

Shoot up the terminal now...

$ hugo server
Start building sites … 

                   | EN | FR  
-------------------+----+-----
  Pages            | 35 | 21  
  Paginator pages  |  0 |  0  
  Non-page files   |  0 |  0  
  Static files     | 12 | 12  
  Processed images |  0 |  0  
  Aliases          | 18 |  7  
  Sitemaps         |  2 |  1  
  Cleaned          |  0 |  0  

Built in 65 ms
Watching for changes in /Users/yeganathan/quickstart/{archetypes,content,data,layouts,static,themes}
Watching for config changes in /Users/yeganathan/quickstart/config.toml
Environment: "development"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop

Open a browser and enter the webserver address (localhost) to see the changes made. We can also make changes/ add content once we start our live local server and see the result instantly, this makes it even easier since we can see the result once we save our file with each change made.

We can also edit the core components of the theme by editing the required file for the required component inside the themes directory.

Adding manure and fertilizers 🌱

We can also add few more components other than in the theme...

For instance,

If we need an extra menu (Photography) apart from the one given in the theme, we can easily make one by editing the config.toml

[menu]
  [[menu.main]]
    identifier = "about"
    name       = "About"
    url        = "about/"
  [[menu.main]]
    identifier = "posts"
    name       = "Posts"
    url        = "posts/"
  [[menu.main]]
    identifier = "photography"
    name       = "Photography"
    url        = "photography/"

also, the contents of the page can be added to the content directory same as posts.

Basically, we can add anything that we want on our site. Just go around the files and start doing wonders ✨

Irrigation 📦

So for we made changes to our site and the files are only in our local system, in order to deploy in web it should be stored in remote right!? here comes Github.

As said already we need 2️⃣ repos for our hugo site.

Create your 2️⃣ remote repos on Github, one as [username].github.io and the other as quickstart.

⚠️ Remember ⚠️
The quickstart is nothing but the project_name we can always use anything of our own but keep in mind that it should be uniform throughout the process.

when creating [username].github.io repo always includes file .gitignore so that it won't shoot an error.

Inside the .gitignore file,

categories/*
tags/*

Write the following commands in terminal...

$ git remote add origin https://github.com/<github_username>/quickstart.git
$ git add .
$ git commit -m "Initial commit for our Hugo site."
$ git submodule add https://github.com/<github_username>/<github_username>.github.io.git
$ git add .
$ git commit -m "Initial commit for our generated HTML."
$ git push -u origin master

this only pushes to quickstart repo.

We still need to generate our HTML pages for our [github_username] repo, but before generating we need to change our config.toml file to output our HTML files to our submodule [github_usernam].github.io.

Open your config.toml

Change these things to as shown below...

Hugo already has a built-in command, that generates your files to a Public folder.

Let’s generate them by running the following command,

$ hugo
Start building sites … 

                   | EN | FR  
-------------------+----+-----
  Pages            | 35 | 21  
  Paginator pages  |  0 |  0  
  Non-page files   |  0 |  0  
  Static files     | 12 | 12  
  Processed images |  0 |  0  
  Aliases          | 18 |  7  
  Sitemaps         |  2 |  1  
  Cleaned          |  0 |  0  

Total in 136 ms

And that should be it. If you look in your [github_username].github.io folder now you should see HTML and CSS files, stuff that Github pages understand❗️

Before we finally deploy, we need to make sure our remotes are set up correctly.

$ cd <github_username>.github.io
$ git remote -v
> origin https://github.com/<github_username>/<github_username>.github.io.git (fetch)
> origin https://github.com/<github_username>/<github_username>.github.io.git (push)

Now after doing the above, you should probably see the same fetch and push.

Harvesting 🌾

We are gonna push all those generated HTML and CSS files to [github_username].github.io repo

Once again make sure your inside [github_username].github.io directory in the terminal...

Now let’s host it!

git add .
git commit -m "Hosting my first Hugo website!"
git push origin main

Now go and check the [github_username].github.io repo

you will see Github pages in the repo, click that

If your deployment didn't show up wait for a couple of minutes and reload the same.

Finally, we hosted our first Hugo site 🥳

Feel free to check out 👉🏻 my portfolio 👈🏻

Do Like 👍 and follow for more interesting blogs 👨🏻‍💻
Comment you're valuable feedbacks down ✌️

Squashing commits in Git!

Yeganathan S — Fri, 04 Dec 2020 17:16:06 +0000

Hello Everyone! back with another topic, Have ever felt that your repository in Github has a lot of commits history in which few don't make sense? for example, fixing typos in the readme in my case. If you're a Beginner then you may think of creating a new repo and push all those pretty useless commits in a single commit message "First commit". Well, then you're in the right place. Actually, there is a way you can squash multiple commits into a single one.

Basically, We squash commits to make our git log more concise.

Prerequisites:

Git should be installed.
Knowledge of Terminal and Git commands.

⚠️ Disclaimer ⚠️
Before experimenting with these, always have a backup of your files!

All being set let's dive into our topic! For easy understanding, I broke this into pieces and tried explaining in a noob way.

Getting Started 🥳

This is the commits history of my example repo.

So in the above example, I don't want the 5 commits history which is in-between the last and first since it doesn't make sense. let's make those commits history into a single commit!

Shoot up the terminal and go to your repo folder directory

$ cd <repo-folder>

Make sure your repo folder is updated with all those commits you made and Write the following command...

$ git rebase -i HEAD~<n>

In this case we are gonna give n as 6, where n is the number of commits history we need and these commits are from top-bottom. if we give n including the first commit we made, probably it shoots an error.

Experimenting 🧪

Executing the previous step will bring up the below interface with commit history and options to perform the following:

pick d8c1963 Adding contents
pick 5e4ea01 added
pick a3e1b06 removed few content
pick f9d4b67 Added few contents
pick 9e69811 Fixed typos and added content
pick 42dbace final

# Rebase 5f5302b..42dbace onto f9d4b67 (6 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.

Squashing Begins❗️

Now, press S and it goes into editing mode. Replace pick as squash, for the commits you need to squash.

pick d8c1963 Adding contents
squash 5e4ea01 added
squash a3e1b06 removed few content
squash f9d4b67 Added few contents
squash 9e69811 Fixed typos and added content
pick 42dbace final

# Rebase 5f5302b..42dbace onto f9d4b67 (6 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
-- INSERT --

basically, all these 4 commits history is gonna be squashed into the previous one with a commit message which we are going to give in the next step. Always don't include squash in the first commit(Well! in this case, "d8c1963"), probably it shoots an error.

Now save the changes made by pressing Esc + : + w + q and after saving press shift + z two times, which brings you to an interface like this...

# This is a combination of 5 commits.
# This is the 1st commit message:

Adding contents
# This is the commit message #2:

added
# This is the commit message #3:

removed few content
# This is the commit message #4:

Added few contents
# This is the commit message #5:

Fixed typos and added content

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date:      Fri Dec 4 12:14:48 2020 +0530
#
# interactive rebase in progress; onto 5f5302b
"~/Dev-test-repo/.git/COMMIT_EDITMSG" 33L, 839C

here what it does is

Processing 🔄

Now it's our chance to delete the commit messages and create a new commit message

final test

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date:      Fri Dec 4 12:14:48 2020 +0530
#
# interactive rebase in progress; onto 5f5302b
# Last commands done (5 commands done):
#    squash f9d4b67 Added few contents
#    squash 9e69811 Fixed typos and added content
# Next command to do (1 remaining command):
#    pick 42dbace final
# You are currently rebasing branch 'main' on '5f5302b'.
#
# Changes to be committed:
#       modified:   README.md

Again, press Esc + : + w + q and after saving press shift + z two times. Now you will be thrown out that environment.

Takeoff ✈️

All these efforts should be reflected in our repo right!? So, let's push all those to our example repo in Github...

$ git push -f

here, we use -f since we're force pushing it.

Finally 🎉

We squashed multiple commits to a single one!

For Beginners, remember deleting a commit is different from squashing commits.

Hope this article helps you!, Do like and share it if you find it useful. Post your valuable suggestions in the comments below!

How to Open a Pull Request in Github?

Yeganathan S — Sun, 25 Oct 2020 03:12:07 +0000

Hello Everyone! I'm going to share my experience on creating a pull request in Github, Trust me that's easier than what we think.

Let's get started,

Prerequisites:

Git should be installed.
Basic knowledge of Git.
Github account.
Knowledge of terminal commands.

In this article, we are going to add badge to the README.md file by pulling a request.

Badges basically help in increasing the readability of the readme file. just like tags!

Now the real part of git begins!😂 and let me break it down into steps...

Step - 1

Fork the repository you need to pull a request. when we fork, we get a copy of that project in our Github profile.

Step - 2

Copy the Fork URL.

Open up a terminal type the following command.

$ git clone your-fork-url

Now we have the project locally,

Step - 3

Go to the project directory now!

$ cd project-name

Step - 4

Now check the issue of the repository which you forked, you will find something like this...

Step - 5

Open the README.md file using an editor and add the badges that are mentioned in the issue.

you can find the Markdown codes for badges here.

Save the README.md after editing.

Step - 6

Type the following command...

$ git status

Now you can see there will be something like modified README.md in red color.

We have a change in README.md file right!? so we need to save that change. In other words, we need to commit those changes that are made.

Step - 7

Open up and type the following...

$ git diff

This command shows the changes made by us!

Don't ask me why are we checking it again since we know what are all changes we made! as said before I'm taking you guys through a path...

Just relax and continue reading!

Step - 8

Most forgets the usage of all these commands including myself 🤦🏻‍♂️
let me explain this too,

$ git add README.md

This adds README.md file including your project.

$ git add file1 file2 file3

When you are having many files.

$ git add .

When you want to add all files.

The last command mentioned above is not a good practice though! what if you don't want a file after pushing it. Believe me, it really sucks! myself when I was new to git I use to delete the whole repository for this problem🙆🏻‍♂️😬

Back to the path!

We are going to use the first command mentioned in Step - 8.

Step - 9

Now again...

$ git status

This time you get modified: README.md but in green color! since we added the files, it changes from red to green.

The whole process is like packing chocolates for gift in the factory!

Eww! that sounds a little weird I know but trust me! with a real-life example, you will understand it better than anything else.

Step - 10

Now type the following command in the terminal...

$ git commit -m "Add the License badge to README.md"

Remember committing is like packing

When you pack, you add a note too! like bday wishes and this part should be sensible too right!? we don't write happy bday for an anniversary function, similarly, commit messages should be sensible.

Step - 11

Now again...

$ git status

you will be probably getting the working tree clean & nothing to commit.

This happens because we had change earlier but we committed it which means we saved a checkpoint for it.

Type...

$ git log

We can see our commit in the log!

Step - 12

Now we have to send the chocolate(we can eat it too!), for sending we need an address. Our code should finally go to the repository which we forked in the beginning but do we have access to that? No right!? so for sending it we need a delivery service. Let's say for example you forked a project from user "A" and now the forked one which has some changes is with you so in this instance you are "B". Now "A" is Europe and "B" is India so for sending the chocolates from India to Europe we need a delivery service which is our Pull Request.

Now type this command...

$ git remote -v

Basically, this shows fetch and push, try to remember like this...

fetch - from where you want to fetch the commits
push - where do you want to push the commits

Step - 13

We didn't push the commit yet right!? so let's push it...

$ git push -u origin master

Now our file gets pushed into our Repo.

Basically push command pushes all the new commits to the Github repository.

Let me conclude,

snitch3s/hackbunch was the main project here and ours is a fork so initially, both are at the same level but you made a new commit recently so you are 1 commit ahead of the main project.

Remember: Only when there is a change (ahead/behind) you can make a Pull Request(PR)

so your PR should go from your fork:master branch to snitches:master

Now you can find something like compare or pull request basically both do the same...

Pull a request and create one

The above image shows something similar to git diff command which is nothing but one final check!

Now it totally depends on the maintainer whether to accept the PR or not!

Kudos to my mentor who taught all these stuffs @vchrombie

Thanks for reading my article and Comment down your feedback!😃