Forem: Jogendra Kumar

How to write proposal for Google Summer of Code

Jogendra Kumar — Fri, 11 Mar 2022 11:38:18 +0000

It worth mentioning that the proposal plays a very big role in selecting in Google Summer of Code. A proposal is basically you describing to your organisation how you would go about the project. Based on this and your credibility, your organisation would contemplate on whether to select you or not. I was Google Summer of Code student in 2018. During the proposal submitting time, I have seen a lot of proposal on the organization chat channels, some are good and some bad. Many people try but some of them get in as there are limited slots in every organization. What stands out the selected student from the student who didn’t get selected is their proposals (there are other factors too). Your proposal should convince the mentors that you’re the right person for the project that can take project to next level.

I did Google Summer of Code 2018 with FOSSASIA and Mentored Google Summer of Code 2019 students. I am sharing my perspective as a mentor, what mentor except in a proposal and what are some things that make you stand out.

Read the full blog post here https://jogendra.dev/how-to-write-proposal-for-google-summer-of-code

Writing maintainable Go code

Jogendra Kumar — Sat, 19 Feb 2022 06:56:26 +0000

Writing maintainable code is essential. Clarity, readability, and simplicity are all aspects of maintainability. It should make the process easy for someone to join your project or maintain it after someone leaves. Maintainability is measured by how effortless it is to introduce changes and the amount of risk associated with those changes. To write Go effectively, it is crucial to understand its properties and idioms and apply the established conventions related to naming, program construction, formatting, etc.

Here are some good practices that will help write maintainable Go code.

Link to full article: https://jogendra.dev/writing-maintainable-go-code

Import Cycles in Golang: How To Deal With Them

Jogendra Kumar — Mon, 18 Jan 2021 19:59:49 +0000

As a Golang developer, you probably have encountered import cycles. Golang does not allow import cycles. Go throws a compile-time error if it detects the import cycle in code. In this post, let’s understand how the import cycle occurs and how you can deal with them.

Read the full blog here:
https://jogendra.dev/import-cycles-in-golang-and-how-to-deal-with-them

Using Vim for Go Development

Jogendra Kumar — Sat, 15 Aug 2020 13:23:44 +0000

As a programmer, you spend a lot of time using text editors, IDEs, etc to code. So it is important what and how you use it. I recently moved to Vim for Go development and I am totally loving it. Initially, I was using VSCode with Go extension and after that, I used GoLand for a while. Visual Studio Code and GoLand both are totally awesome, I loved using them too. It definitely takes some time to learn using vim but it is worth the learning. It is totally up to you what works better for you. Do not use vim just because others are using it. I am very much a beginner to vim and things I am going to explain in this is what I learned after I started using it. I would be really glad if you are a long time Vim user and have some good advice/suggestions. You can put them in the comment section of this post. If you are a beginner, I will put some good resources for learning vim at the bottom of this post.

NOTE: This post is originally posted on https://jogendra.dev.

Read Full Blog here: https://jogendra.dev/using-vim-for-go-development

How to use multiple GitHub accounts on single machine

Jogendra Kumar — Wed, 22 Jul 2020 05:41:37 +0000

Most of us have multiple (mostly two) GitHub accounts, personal and work account. You need to have the ability to push and pull to multiple accounts. This post is about how to setup and use them on a single machine using HTTPS or SSH.

Note: The instructions below have all been executed on macOS and should work fine on all Unix based operating systems.

Read the full blog here: https://jogendra.dev/how-to-use-multiple-github-accounts-on-single-machine

Introduction to Dotfiles

Jogendra Kumar — Tue, 21 Jul 2020 08:08:21 +0000

One of the main advantages/beauty of Unix-like systems is that configurations of everything are very customizable. Dotfiles are simply amazing. They are tiny-little configurations files but they customize/decide a lot of your system. Well-organized and understandable dotfiles basically allow you to automatize complex tasks that you repeat every day. With dotfiles, your machine is more organized, advanced, and customized in the way you like your system to be. Also with dotfiles, you can mess around with new packages and settings quite easily, without ever having to worry about really breaking something important. If you would break something, your dotfiles are always right there to back you up.

Note: This blog is originally posted at https://jogendra.dev/i-do-dotfiles

TL;DR: Invest time learning to configure your machine and automate processes, you'll get that time back tenfold.

Your experience, knowledge and talent are key to success, but some kick-ass dotfiles speed you up.

🚀 ✨ My dotfiles can be found at jogendra/dotfiles

What are dotfiles?

Dotfiles are files and folders on Unix-like systems starting with . (dot) that control the configuration of applications and shells on your system. Dotfiles are shell scripts that are executed to change the environment of your machine. The “dotfiles” name is derived from the configuration files in Unix-like systems that start with a dot (e.g. .zshrc and .gitconfig). For normal users, this indicates these are not regular documents, and by default are hidden in directory listings. You can display dotfiles inside any directory by running ls -a command. GitHub does dotfiles is definitely great place to explore and know more about dotfiles.

Why dotfiles start with . (dot) is an interesting example of a bug that has become a feature. Checkout interesting reads on Why do hidden files in Unix begin with a dot?.

GitHub Codespaces and Dotfiles

Recently GitHub announced Codespaces. According to GitHub, Codespaces uses your dotfiles repository on GitHub to personalize every new codespace that you create. Anyone can create a dotfiles repository to personalize Codespaces for their user account. If your user account on GitHub owns a public repository named dotfiles, GitHub automatically uses this repository to personalize your codespace environment. Read more about this here.

Sharing your dotfiles

The main reason behind creating dotfiles is customizing your machine the way you like. Imagine the situation when your machine got broken or some reason you have to change your machine or you have changed your workplace so the machine, in that case, if you haven’t put your dotfiles on some remote machine, you will have to create the dotfile again which was was your long time iterations. With dotfiles, you can have a new machine ready in hours, providing the exact same user experience as the previous one. You can publicly put them on GitHub/Dropbox/etc or keep them private. It is worth keeping your dotfiles under version control for several reasons. Keeping a history of your changes allows you to safely experiment with new configurations, revert bad changes, and review the details of past changes. It is recommended to use different branch for different systems eg. you can put macOS focused dotfiles in one branch and linux system focused dotfiles on another branch so that it become easier for you when you shift between systems. I have made my own dotfiles open sourced, and parts of my configuration are inspired by other people’s dotfiles. Afterall, dotfiles are meant for sharing.

Do not blindly copy dotfiles

Mostly, dotfiles are very specific to the individual developer. What works for someone else isn’t necessarily optimal for you. Rather than using someone else's dotfiles, it is recommended to create your own dotfiles. But it is always great to look into other’s dotfiles to get better ideas, also you can use a bit and pieces of their profiles if you think that will be helpful to you. Going through other’s dotfiles is a great way to improve your own dotfiles. Before creating mine, I went through a lot of other's dotfiles on GitHub. I took this idea of organizing (structure) dotfiles from Holman dotfiles. You can get ideas from different dotfiles and cherry pick some of their part into yours, so for the same reason you can make your dotfiles public on GitHub/GitLab etc. and let the other developers pick and choose from it. I do not agree with “dotfiles are meant to be forked”.

Securing the dotfiles

Dotfiles often contain some private data like plain text passwords and some pieces of information you don’t wanna share publicly. Anything that is a security risk, like files in your .ssh/ folder, is not a good choice to share using this method. Be sure to double-check your configuration files before publishing them online and triple-check that no API tokens are in your files. You can use gitattributes for git related sensitive information. Version controlled folder’s files that contain sensitive information and should not be published are kept secret using package-specific .gitignore files.

git config credential.helper store is not a very secure way to store your git server passwords. According to git credential store documentations, store helper will store your passwords unencrypted on disk, protected only by filesystem permissions. The ~/.git-credentials file will have its filesystem permissions set to prevent other users on the system from reading it, but will not be encrypted or otherwise protected. So it stores your password as is. So if you are running macOS on your machine, Git allows to use your keychain, which is way more secure. To set osxkeychain as your git credential helper, run:

git config --global credential.helper osxkeychain

If you are runnning Linux on your machine, you can use git config credential.helper cache, which stores passwords in your memory. This way stored credentials never touch the disk, and are forgotten after a configurable timeout. To set cache as your git credential helper, run:

git config --global credential.helper cache

Mistakenly, if you commit sensitive data, such as a password or SSH key into dotfiles Git repository, you can remove it from the history. To entirely remove unwanted files from a repository's history you can use either the git filter-branch command or the BFG Repo-Cleaner (an alternative to git filter-branch) open source tool. You can check out GitHub's guide on Removing sensitive data from a repository.

I would recommend you to use Passwordstore (pass), the standard Unix password manager. It provides a secure way to encrypt, share, manage, and use private data or passwords. pass makes managing these individual password files extremely easy. All passwords live in ~/.password-store, and pass provides some nice commands for adding, editing, generating, and retrieving passwords. It is a very short and simple shell script. It's capable of temporarily putting passwords on your clipboard and tracking password changes using git. You can read more about pass here.

Do checkout Keep sensitive data encrypted in dotfiles. Also, check out how to secure your dotfiles.

Using dotfiles through SSH

This section is for those who login often on remote servers using SSH. When you enter into the remote server, your ZSH, plugins, all of your aliases, completions, color schemes, NOTHING is there. Everything set to their default values because your remote shell does not have access back to your local configurations. Terrible?. The solution to this, what I would recommend is to write a script that contains everything you want to put on your remote machine and install there whenever you log in. Keep this script separate from your dotfile installation script because you may not want/need to install everything that is inside your dotfiles repository. Also, because you may not want to slow down your remote server login process. You can also use this SSH wrapper tool called kyrat that allows you to source local dotfiles on an SSH session to a remote host. It works either from/to a Linux or OSX machine.

Some Interesting/Helpful Reads

I hope this post will give you enough push to start with your own dotfiles. Looking forword to your freshly brewed dotfiles. You can reach out to me on Twitter in case of anything. Thanks for the read :)