Once I had to send a couple of pictures via e-mail (there were about 20 images). I am aware there are more efficient and smarter options to share images with other person, although sometimes the other side demands it to be an accually e-mail. đđ€·ââïž
I decide to reduce the size, pack it and send it. I realized that images are stored in a strange Apple extension called *.heic
, so this is not a desired extension that someone on the other side would like to see. Furthermore, the original images were big (3-5MB) and I really donât want to end up with manually resizing and saving all images with desired extension.
Fortunately, there is a brilliant program called imagemagic which saves my ass a thousand times - and btw itâs actually now a group of different programs, but never mind.
With this tool, you can in a good well spirit of automation convert all images from HEIC to more popular JPEG and reduce the size (quality), so they can fit in a standard email size.
Install imagemagic
on your computer (itâs free and available on all platforms). If you like my editing, especially the heic
type of images, you may need to install an additional library called libheif
. For other platforms use alternative.
brew install libheif imagemagick
Now you just need to specify a directory where your images are stored and execute the command:
magick mogrify -format jpg -quality 60 *.HEIC
Pay attention to the case sensitivity of the letters in the image extension, as it may be different than in my command.
You can also use instead full of magick mogrify ...
, just mogrify ...
because after the installation of imagemagic all its sub-programs should be available for you directly in the command line.
Yay! A few seconds later all images are converted and theyâre ready for upload. Thanks, thatâs all đ€. Have fun further exploring imagemagic secrets. Itâs definitely extremely helpful software.
]]>Like you, for years my sound taste also was changing. My childhood, my character, the place I lived, and the people I grow-up with, shaped the music taste I have today - possibly it was similar for you.
When I was a child, I listen to a lot of rock/pop/hip-hop/rap music and played video games (mostly RPG where I wasnât a good player tho). After the years, I noticed, the time I spent in my youth, created unique moments/atmospheres in my brain, that forged my music taste. For example, I really enjoy nowadays getting back to the move & game soundtracks while focusing, as this bringing me some kind of relief while working with micro breaks for my brain which the music-memory reveal, and then have a feeling I am much more focused/productive.
Over time, I build a sentiment of oldâschool grove, jazz, electronic, ambient, house/trance, pop, and rock vibes. Not forget about great movie & game soundtracks I love to listen to and of course some classical pieces.
This is a special article for me. It has a much more personal touch with the music that, is with me for years. I hope you find it likable, and inspirational, and maybe you find something interesting and think someday it was worth your time to check out this post.
Thank your time, and enjoy it as much as I do!
Disclaimer: I am not the owner of the songs, therefore, I keep the full names & authors of the songs (or mixes) with links to the sources I know where they still exist. In case some songs will not be available anymore by the time you read them, they could be removed mean, and I am sorry. When this happens, just let me know (tweet me, or use comments), and I will do my best to keep them updated.
There are a couple of songs I dear the most over time, although not all I wish, I could put in here. The question is âwhy do actually these songs land in the lists belowâ? I think there were many reasons âwhyâ. I feel some sort of connection to the songs below, simply from just being sentimental to the past memories I had with them, while some events happened in my life, ending on just liking the kind & vibe the music is giving me.
Below I gather a few lists and grouped them into sections that should be a bit useful for you. The order of the songs is mostly random (there is no 1st/last nor best/worse), and some of them are grouped if they come from one artist to have easier sneek.
Unfortunately many programs will need Apple developer tools, so we install them as well via terminal command. Pay attention as this step might take a while⊠(this step took me ~10-15min)
xcode-select --install
The brew is de facto standard macOS Package Manager.
Following https://gist.github.com/ChristopherA/a579274536aab36ea9966f301ff14f3f
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
# disable analytics
brew analytics off
Optionally: I am installing my usual packages from my dotfiles. If you are interested take a look on my Brewfile.
# to install from Brewfile curl https://raw.githubusercontent.com/egel/dotfiles/main/configuration/Brewfile -o ~/Brewfile brew bundle install --file=~/Brewfile
Later you can save all installed packages with:
brew bundle dump --file=~/.private/Brewfile
Installed via brew. In case use: brew install --cask iterm2
font, size, window theme
If you like hack font, do not rush with installing it via: brew install font-hack
. Instead you may want to have Hack Font with Powerline symbols from the NERD Fonts https://www.nerdfonts.com/font-downloads. To see a small difference take a look on screenshot below with Neovim.
Hack Font (Standard) | Hack Nerd Font (with powerline symbols) |
---|---|
brew install font-hack |
brew tap homebrew/cask-fonts; brew install font-hack-nerd-font |
In case you have already downloaded dotfiles locally you can copy all fonts into your local user folder. Nerd Fonts are also there đ.
cp ~/privatespace/github.com/egel/dotfiles/assets/fonts/* ~/Library/Fonts
Below you will find some screenshots with configuration I usually setup.
Colorscheme Gruvbox
curl https://raw.githubusercontent.com/herrbischoff/iterm2-gruvbox/master/gruvbox.itermcolors -o ~/Downloads/gruvbox.itermcolors
Import downloaded gruvbox color preset into iTerm (2), and after importing activate theme (3).
Iterate through the arguments of previous commands - this is awesome feature of ZSH shell, so if you are interested follow my other post how to loop through previous arguments.
Finally you should see something like this:
Download the basic editors and IDEs.
Mobile App development:
I put this out of dotfiles as git is essential to do any further steps. Later we will update .gitconfig
to be in synch with our dotfiles repo.
wget https://raw.githubusercontent.com/egel/dotfiles/main/configuration/.gitconfig -P ~/
wget https://raw.githubusercontent.com/egel/dotfiles/main/configuration/.gitconfig.local -P ~/
wget https://raw.githubusercontent.com/egel/dotfiles/main/configuration/.gitconfig.local -O ~/.gitconfig.local_work
Later in GPG section, we will make sure that gpg keys will be properly added to .local
& .local_work
files, as they will be needed to sign the commits.
For linux & macOS (Intel), at this moment you would need to run this command git config --global gpg.program $(which gpg)
, so the path to gpg program can be correctly updated in .gitconfig
.
I love gitlab page for configuration of SSH keys.
ssh-keygen -t ed25519 -C "johndoe@example.com"
If you forgot to add passphrase for your key use this command. See more at update your ssh-key passphrase.
ssh-keygen -p -f /path/to/ssh_key
# ~/.ssh/config
# Connect to gitlab.com
Host gitlab.com
HostName gitlab.com
Preferredauthentications publickey
IdentityFile ~/.ssh/id_ed25519
If you want you can also use ssh-agent
, but if you plan to use GPG to sign messages, ssh-agent
you can replace with gpg-agent
.
More information you can find in here: gpg-agent instead of ssh-agent.
I like to make my files synchronized with my remote repository - this helps me to update main origin when my local changes arise.
mkdir -p ~/privatespace/github.com/egel
cd ~/privatespace/github.com/egel
git clone git@github.com:egel/dotfiles.git
Re-linking the files that was directly downloaded from the repo, in order to get full synchronization with the private dotfiles repository.
# gitconfig
ln -sf ~/privatespace/github.com/egel/dotfiles/configuration/.gitconfig ~/.gitconfig
# idea (for vim plugin)
ln -sf ~/privatespace/github.com/egel/dotfiles/configuration/.ideavimrc ~/.ideavimrc
Optional: In my configuration I setup few additional files, that help me manage my dotfiles. Like storing private passwords, having additional private configurations, ect. Those files by the design are meant NOT BE STORED under version control systems.
Also make sure the files have correct permissions, only for you.
touch ~/.zshrc.local chmod 600 ~/.zshrc.local touch ~/.envpass.private chmod 600 ~/.envpass.private
At this moment you should check if your connection is established. Running the command the second time should give you message with your git user.
ssh -T git@gitlab.com
# run it 2nd time, to get user
$ ssh -T git@gitlab.com
Welcome to GitLab, @john.doe!
Letâs start with basics, like linking configuration folder with local directory.
mkdir -p ~/.gnupg
ln -sf ~/privatespace/github.com/egel/dotfiles/configuration/.gnupg/dirmngr.conf ~/.gnupg/dirmngr.conf
ln -sf ~/privatespace/github.com/egel/dotfiles/configuration/.gnupg/gpg-agent.conf ~/.gnupg/gpg-agent.conf
ln -sf ~/privatespace/github.com/egel/dotfiles/configuration/.gnupg/gpg.conf ~/.gnupg/gpg.conf
ln -sf ~/privatespace/github.com/egel/dotfiles/configuration/.gnupg/sks-keyservers.netCA.pem ~/.gnupg/sks-keyservers.netCA.pem
Now, download your gpg keys (private & public) for all your accounts private (or/and work), as we will add them to gpg configuration in order to sign your things (like commits, private emails).
gpg --import public_key.asc
gpg --import private_key.asc
Get your gpg fingerprint as we will need to use in git. Execute command below and get âsigningKeyâ = last 16 chars of your fingerprint key. (I add arrow, to make it easier for you).
$ gpg --list-secret-keys --with-fingerprint --keyid-format LONG your@email.com
|- this would be your "signingKey" ------- |- or here
⌠|
sec rsa4096/RPGLBRKNFTAZ2S9K 2019-03-17 [SC] âŒ
Key fingerprint = VXE7 T2QX FCJZ YQ6L BEGJ MLMM RPGL BRKN FTAZ 2S9K
uid [ unknown] John Doe <johndoe@example.com>
ssb rsa4096/EBEE77C5734494A6 2019-08-23 [E]
Restart gpg-agent
in order to use latest configuration.
$ killall gpg-agent
2023-03-27 15:13:12 gpg-agent[2253] SIGTERM received - shutting down ...
2023-03-27 15:13:12 gpg-agent[2253] gpg-agent (GnuPG) 2.4.0 stopped
$ gpg-agent --daemon
2023-03-27 15:14:46 gpg-agent[2253] gpg-agent (GnuPG) 2.4.0 started
Fill the key in ~/.gitconfig.local
. So itâs look more-less like:
[user]
user = "John Doe"
email = johndoe@example.com
signingKey = RPGLBRKNFTAZ2S9K
[commit]
gpgsign = true
Test applied config by reloading terminal and commit something, to see if your commits are signed successfully.
git commit -S "test commit with signing"
If everything will went successfully, you should get pinentry window, like the one below:
Without a doubt vim is the king of simple text editors. Many of you may argue, but I donât want to lead you astray đ. When I discoverd vim, I was so much confused âwhy the heck there is so much noise about this thingâ! After looong time later, I understood why and I wrote Is worth to know the Vim Editor and why? and The Vimâs hidden superpowers.
Letâs start as usual with configuring vim and neovim.
# nvim (my primary editor)
mkdir -p ~/.config
ln -sf ~/privatespace/github.com/egel/dotfiles/configuration/.config/nvim ~/.config/nvim
# vim (after switch to nvim, using this config rarely)
ln -sf ~/privatespace/github.com/egel/dotfiles/configuration/.vimrc ~/.vimrc
ln -sf ~/privatespace/github.com/egel/dotfiles/configuration/.vim/ ~/.vim/
# Open nvim & vim and install plugins via
:PlugInstall
Tmux - terminal multiplexer and Tmux Plugin Manager.
# link configuration
ln -sf ~/privatespace/github.com/egel/dotfiles/configuration/.tmux.conf ~/.tmux.conf
ln -sf ~/privatespace/github.com/egel/dotfiles/configuration/.tmux-osx.conf ~/.tmux-osx.conf
# install tmux-plugin manager
git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm
# type this in terminal if tmux is already running
tmux source ~/.tmux.conf
Open new session abd type tmux new -t new
. Next, install plugins from the .tmux.conf
file via prefix + I (pay attention, itâs big âiâ. Prefix = ctrl + b).
I was positively surprised that by default M1 use zsh shell.
Install missing oh-my-zsh
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
For years I use honukai theme, as it gives me best orientation in the shell.
mkdir -p ~/.oh-my-zsh/custom/themes/
curl https://raw.githubusercontent.com/oskarkrawczyk/honukai-iterm/master/honukai.zsh-theme -o ~/.oh-my-zsh/custom/themes/honukai.zsh-theme
Reopen terminal to apply changes.
For all types of screen records, I use default mac screenshot tool, with some combinations from Snagit. The combination of both give the fastest experience to finish a screenshot or record a screen for documentation.
I like to have one path for all type of screen records and usually choose something like:
# Set new default path
defaults write com.apple.screencapture $HOME/Documents/Screenrecords
# kill current UI to apply new write path (no worries, it will not destroy anything)
killall SystemUIServer
Setup list view as a default view for all folders.
Next after accepting âUse as Defaultsâ, open terminal and remove all .DS_Store
files from system used by the Finder, in order to remove all overrides (finder save all meta data about folders in .DS_Store).
sudo find / -name ".DS_Store" -exec rm {} \;
Additionally, I like to display file extensions and sort folder first, therefore my usually setting for finder window is like following:
For the mac trackpad I like to setup 2 things I am so get used to, that I cannot imagine work without:
Swiping between screens with 4 fingers
dragging elements with 3 fingers
I think this is pretty standard, although having one screen in vertical position is very helpful as this sometimes enable to look on things from different perspective.
In new version of macOS Sonoma, they introduce widgets on the desktop. One of the new default features is when user will click on the background it reveals the desktop.
I prefere to disable this feature and below paste small video-tutorial.
# install nvm
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash
# install specific version of node
nvm install 18
nvm alias default 18
# test
which node
node --version
# apply changes
source ~/.zshrc
Yarn is connected to version of node running, so best way to install it is via current used node/npm.
Info: If you will use many node versions (via nvm), you also should to install yarn for each node version.
# install yarn globaly
npm install -g yarn
# test
yarn -v
Follow my other post how to setup ruby on macOS - If possible do not use the ruby system version on mac osx
Standard link for configuration file
# create symlink from dotfiles dotfiles repository
ln -sf ~/privatespace/github.com/egel/dotfiles/configuration/.gemrc ~/.gemrc
Follow my other post how to setup python on macOS - How to properly set up Python project?
I did not found better way to install Java, like through SDK-MAN. I am not much fan of Java but this is really awesome Java Version Manager similar to rbenv
.
To install it start with:
# install
curl -s "https://get.sdkman.io" | bash`
# test if succeeded (or reload terminal)
skd version
Some programs may require installing Appleâs rosetta
softwareupdate --install-rosetta
It was not so obvious to me at the beginning what I am dealing with when I discovered this feature. I read some articles on the web where after pressing Alt + . in the terminal, you could start iterating through previous arguments of your past shell commandsâŠon the fly, instantly! At this moment I thought, âehhh⊠yet another boring, not worth my time thingâ. Although I will give it a try, I was amazed at how useful it is.
It may sound silly, but itâs well-visible when you try it on your own. Just imagine when you had to type a long and complex path in some of your previous commands, and after a few others, now you write the next command, which you could reuse âthis long pathâ you used before. What do you do then? Are you going back, copying it, and pasting it common again? or, are you trying to remember and retype it? Some people are strivng to be lazier (efficient), and they use some system clipboard managers and get back by 2-3 clicks. Although, imagine you can reuse them with just 1 click away. Guess whatâŠ, after pressing Alt + . you could resurrect those long and complex past parameters you previously typed in the terminal exactly now while writing your current command and continue rocking on further. This is so a stupidly brilliant and extremely effective trick.
But it would be too perfect to be true, if this great feature would be available for everyone - unfortunately, at the moment, this neat feature is only available in the ZSH shell.
In your ~/.zshrc
paste the following code below. This will adjust your configuration to have correct
key binding in your terminal.
# ZSH key-bindings
# specyfic for OS
case $(uname -s) in
Darwin)
bindkey '^[.' insert-last-word # insert last word (Alt+.)
;;
Linux)
bindkey '\e.' insert-last-word # insert last word (Alt+.)
;;
esac
In the last part, we need to correct the behavior of the Alt key in the terminal so it starts behaving as expected.
As you already possibly noticed I changed the key to only one Alt key (left). The reason did it, is to preserve
a default writing compatibility while using special characters in languages other than English. For instance, in the Polish language,
Alt + <letter>
produce special characters, like Alt + l = Ć.
If you want a similar case to have in IntelliJ, just update in Settings and search for the âTerminalâ section and enable âUse Option as Meta keyâ.
Puff! Done. I hope you will enjoy this small tiny and incredibly powerful feature, as I do. Now go, and do your magic đ.
Thanks for reading and until next time.
]]>But you would question yourself, âwhy this might be a problemâ? The core of the story begins with fact that all operating systems usualy having own versions of python installed and supported/maintained by default by the authors of Operating Systems. They use those specific versions to fulfill their needs in systems. Then you, developer, when you wanted to start a new project you may be tempted to use a version of Python installed in your system. It will work normally, as usual, and you will not notice any problems possibly until the next upgrade, when your OS may upgrade the system version of your Python and puff⊠something in your project stopped working due to some changes in the version of Python (which may be difficult to find/diagnose). A good rule to remember is: using the system version of Python (or any other language) is usually perceived as bad practice, so please donât do use any system default version for development purposes.
Over the years, the Python community developed a better and more secure way to handle this fragile problem - itâs called a Virtual environment. You can think about it as an encapsulated environment, where you can use any version of python you wish, which is additionally saved to the other elements of your system.
At the time of writing this article, there are at least a couple of ways to set up a virtual environment, although I find the pyenv
and virtualenv
as the most suitable/versatile tools for this role.
I will be basing my example on the macOS system, but I believe it can be also translated almost 1:1 to other operating systems by utilizing its own package managers.
Install pyenv
in your system. It will install a program that will be managing your python versions. I.e.: itâs something similar like nvm
for NodeJS or rbenv
for Ruby.
brew instal pyenv
If you using ZSH you may need to add to your
.zshrc
&.zprofile
.echo 'eval "$(pyenv init --path)"' >> ~/.zprofile echo 'eval "$(pyenv init -)"' >> ~/.zshrc
You may need to reload the terminal, so the changes could be applied.
In case of further readings, follow installation instructions in the official documentation https://github.com/pyenv/pyenv#how-it-works.
Now, we want to install a version of python, which we will be using for our application or also for other applications (it is like reusable python executives which can be shared).
I will pick the latest version just for demo purposes 3.9.7
.
# pyenv install --list # list all available python versions to install
pyenv install 3.9.7
I also like to change my default/system Python version and use the one from pyenv
, therefore in pyenv I set up a global system version and thanks extending .zshrc
and .zprofile
, each time I will open a new terminal I will be using the version of python I set as global system version in pyenv
. Awesome!
pyenv global 3.9.7
Reload a terminal again, and try out if everything has been set correctly. You should get something like this.
$ pyenv global
3.9.7
$ which python
/Users/myuser/.pyenv/shims/python
We finally using a version of python, which is not a system default version and we have the full access/freedom to install/modify anything, by not using sudo
! Letâs install virtualenv
pip install virtualenv # FYI: under the hood, it's should use pip3
If you need to use
sudo
to install some packages, you are possibly doing something wrong. I.e. you as âthe userâ is not owning âthe pythonâ, which later may cause some troubles while the development process.
Now, when we set up everything, we are ready to massively produce new projects in python.
cd /to/your/desired/location
virtualenv venv # will create new venv directory in your location.
new directory venv
is a directory (you can change the name to anything else, although I usually use always venv
), which should be kept out of the repository. In venv directory, there is all information on how to set up a virtual environment for your executable python version. you donât need to modify it, itâs only just FYI.
At the moment, everything is ready to activate the virtual environment and start the fun!
$ source venv/bin/activate
(venv)
$
After activating, your prompt will change, and at the top, you will get printed the virtual environment name you are using. Itâs expected and it will remind you that you are still it.
If you want to quit this virtual environment and do something else, you can quit by typing (see below), and your prompt will quit the venv.
(venv)
$ deactivate
$
Thatâs all. As in all programming languages, there are always some nuances that are good to know before start working - as in general, they may save some time/frustration/problems and help you focus on developing things instead of fighting with them.
Thanks for reading, hope you enjoy it. Wish you happy coding sessions and with that knowledge create something great!
]]>Are you a developer and working genuinely hard with your team on some awesome project which should change the world? I know this feeling, itâs great, you feel thrilled. Moreover, it reassures you that this project of yours is something you want to engage with! Although after a while, when the excitement frenzy is getting away, then comes an everyday routine. This is the time, when code reviewâs angels and demons reveal themselves, especially when everyone is busy with their own, important tasks that have to be done.
Disclaimer: I might use Pull Request (PR for short) or Merge Request (MR for short) equivalently while writing. The difference is mainly that the PRs come from Github users, and MRs is the term used in Gitlab.
Letâs start with some formal definition to remember what a code review is, so we could grasp a good starting point and focus on iterating the possible pitfalls.
Code review (sometimes referred to as peer review) is a software quality assurance activity in which one or several people check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation. At least one of the persons must not be the codeâs author. The persons performing the checking, excluding the author, are called âreviewersâ. - Wikipedia
Honestly, I am not a perfect reviewer. I wish, I would be a one, but even now after 7 solid years in the industry, sometimes I still just forgot how important is to say few nice words about someoneâs great work accomplished in a PR. I always strive to give the best possible feedback to the author to improve a feature/product in order to, or additionally just simply to give someone a tip because I believe (s)he would benefit from it. I am doing this because I honestly appreciate it if someoneâs giving me detailed feedback, so at the end of the day, I can improve myself and be a better companion for my team. However, this process of writing and reviewing sometimes can be obscured by internal or external factors. In this article, I will try to tackle down those factors and severe you in a couple of essential mistakes with a tip on how to improve or solve them.
You need to be aware, that you can take a look at the code reviewing process from 2 perspectives (or even more but itâs out of our scope):
Those two perspectives look similar, but they carry a completely different charge. Sometimes this charge is connected with external factors which are everything around a single person (e.g.: finding the best approach for the project, following best practices, respecting company hierarchy) or internal factors which mainly focus on a single person itself (e.g.: an emotional connection with work, character, hold resentment/sympathy for a person).
In the first few sentences, I want to emphasize that code reviews should always hold a positive change. Itâs important to remember the code review process aims to improve, not to destroy nor question someoneâs work. When we take a positive attitude while the code review, all the work we do as professionals and also as persons, would be much better - like a win-win scenario. Shall we begin?
Leaving only negative comments. Iâve chosen this as a first reviewing sin due to its highest impact on the whole code review process. Why? We are humans, people with emotions - let put ourselves in a situation when all do is âincorrectâ or âwrongâ - itâs not a good feeling, right? Generally, developers sometimes tend to get too emotional about the things they create. This connection is sometimes so strong, that an innocent comment, which might sound negative while reading could be just a trigger to multiple scenarios of having a bad mood, frustration, start disliking someone, or even unnecessary tensions between people in the project - generally speaking, nothing good. It would be an extremely rare situation if someone would think about negative comments through the prism of a good and constructive critique because, in the end, it would make him a better developer/person.
Win: âLight it the tunnelâ approach. Among the comments, leave in someoneâs PR also a few good words what did you like, e.g:
âWoah man, I wish I would more often write a code so clean as yours. It was a pleasure to read it. Nice work!â
Itâs not about to suck up to somebody (no, far from it), rather show you appreciate someoneâs work, even despite a fact that a couple of things need to be improved - you see a solid work which the author put in it.
Taking code reviews too personal. As I already mentioned above, each person may take the work they do differently. Someone will have a higher threshold regarding receiving the critique, but another with a much more fragile character would feel like under a cannon shot. This should never be like that, and this case is mostly connected with higher self-awareness and work on self-development.
Win: Itâs important to take code reviews in an impersonal way. This is for all sides, the authors and the reviewers. In other words, this means, to take the job without so many emotions. Also to not favor or disrespect someone, if we like somebody or not (due to unknown reason) and should not obscure the real feedback you should write as the reviewer.
Do not forget to describe what you are referring to and provide a good reason why you wish to change it. While doing a review, some people tend to be too minimalistic and condense their thoughts in too few words, like:
Win: Either you write a comment regarding a specific line in code, or starting a more general thought, always justify, why this change is important to be updated. You need to remember that, someone who will read your comment canât âread mindsâ and usually need 2 things to understand: what and why.
If at least one point is missing, the review doesnât make much sense because from at least one side it will be incomplete, and to solve the discussion, it will require guessing to understand and/or additional ping-pong discussion which usually leads to losing time. Think, how faster and more effective you could be, just if you would never, ever forget about providing âwhatâ and give a reason âwhyâ đ?
A written text is much poorer in information than a speech. If someone talks to you, except a piece of pure information, you perceive much more, like:
In other words, speech is richer with information than a purely written text. If you would compare speech to static text, many people may misinterpret the words you wrote. A good example would be the school language lessons, where we all have to analyze/guess âwhat the author intended to sayâ except the words he wrote.
Win: When writing a text/comment for a programmer, IMO itâs good to use emojis đ. The emojis add this additional emotional charge to the bare text, so the other side may better perceive and understand the information. I understand, that some companies may not be allowed emojis, or some people may think about emojis as a habit of immature people, but itâs not about judging who is the author of the text, itâs about what kind of information this text (with emojis) could pass on to you so could you get best of it - and this should matter đ.
A review without executing/running the code. I am calling it a âdry-reviewâ, so as not to get your hands wet (dirty) đ. This problem is about reviewing the code without even checking if the code which was changed is running correctly (a part of executing automated testing in the pipeline) in the product.
Win: This is a tricky one because âit dependsâ on what your team agreed on. But for now, letâs say if someone is expecting from you, that you will make a review of his code - just do it, it might take a bit more time but if your team follows these practices then honor them and in the next retrospective meeting say that you would like to automate some repetitive tasks from the review process.
Apart from reading the code, itâs best practice to execute it and check if:
new changes are running and not breaking the application
e2e test could help to âauto-detectâ some cases, but it cost time of maintaining them.
Checking the only added or removed code. This is somehow connected with the previous point âfit to the concept of the whole applicationâ. In here, additionally to the previous point, I want to emphasize how the added or removed code can impact the application and already running features (production code), if it would not be checked. In the best case, it would not do any harm, but in the worst case, it could cost the team much more at a later time with refactoring the existing codebase or even your client losing their clients. Like a poison, these problems are nasty and I consider them as the most difficult to learn for Jung developers.
Win: The reviewer should consider (and in this case âassumeâ would be a good thing) that the code which is under the revision âis a not working codeâ, so only then a solid review could prove you wrong. Although, of course, Iâve got to draw the line somewhere, how deep you should go. The simplest answer would be: âdo not go into a rabbit holeâ or in other words, do not sink for hours in deep review, the other projectâs automation tools should do it for you - focus on the surface.
Too frequently pointing out code syntax. This point for some purists might be a huge problem therefore they are strict as hell while reviewing a code and pointing all, even the smallest syntax problems. This is not the perfect solution to the problem. I can only imagine that those purists strive to have a perfect, clean code. However, in my career, itâs almost impossible to achieve, especially when working with 10+ developers on the same codebase. There will always be âsomethingâ.
Win: reading code is highly important, this unquestionable point. Programmers spend most of the time reading the code than writing it, so it supposes to be good readable, or simply clean. But in this cleanliness must also have some limitations. Each person may find reading code better in another way. If you noticing that someone is leaving a code âdirtyâ or the style of a code donât match with the rest - this is a good point to discuss if everyone is using the same code formatters and more important if everyone is aware of the same way of styling the code in the team. Leave a comment only when itâs important, but when itâs too easy to criticize, please stop for a moment and discuss how each of you do/would/should write the code. Additionally raise this topic in the team (e.g: during stand-up or retro) and document somewhere what are your code standards.
My rule is simple while writing the code, I always try to keep the style of my code to the code I find in the file. Additionally, Iâll always try to follow The Boy Scout Rule and leave the code âcleanerâ as I found before. Only then I do have a feeling that the code I wrote is good and I would give the reader (and me in the future, as well) the best possible experience and starting point for implementing a new feature. Any exceptions I am reporting to my team in the meetings.
Leaving checking tests out of reviewing scope. A lot of developers forgetting to check if the tests are matching to newly applied changes. Usually, the thinking is:
âOh, the tests are passing, so the code works well. Next!â
Oh, how far it could be from true. Nevertheless, I will cover testing of code in another article as this topic is for me genuinely interesting, mostly because when you would ask each developer in the team, possibly they might have a different understanding of âwhat the tests areâ, âwhat they suppose to testâ or âhow to work with them when I donât have much timeâ.
Win: A winning scenario is simple, check if the code has been tested and if so, then check if the test cases are matching with newly implemented updates to the code. Do not go too deep,
Heavy PRs. When you have a PR, which has more than 500 lines of changes, you might toil at reviewing the code you got, and a nice, pleasant review could become a nightmare. PRs tend only to grow, so putting so many things to do in a single ticket/issue, can be a terrible choice - terrible for a developer, but intuitive or obvious for other parties (PO, managers).
Win: Itâs important to know what needs to be implemented and then divide this into a smaller task that can be implemented and easily understand by developers. Developers do usually from 1 to 10 issues per day (depends on the size) and tend to jump between those problems frequently. They load in their mind tons of information and they need to process them, therefore itâs so crucial to make issues relatively small. My golden ratio is to fit with the issue in 1 day. Of course, sometimes itâs not possible, then I always start wondering if it would be possible or/and wise to divide it into smaller chunks - if not at least sort them thematically. For bigger issues that are difficult to divide, I find it the most practical, to divide the implementation of views from the application logic and connection with the backend. In the end, it gives a different variation of difficulty for issues, so everyone in the team can find some task which suits his best.
Confusing and supply disinformation commits. Ah, commits. How poor the world would be without them? They can be the greatest advantage or dead weight. âShow me your commits and I will tell you how good you areâ - in other words, about using a version control system the man could write a book. The subjugation of the version control system is one thing, but using it to the advantage of documenting the project is another thing.
Win:
Fixing too much in a single PR. The Boy Scout Rule, when used too literally may bring you to the place when except for what you need to deliver in the issue, you also fixing few other bugs. This is usually practiced by undisciplined developers, but should not happen. The reason is simple, fixing one bug may bring others, therefore:
Win: Fix only things which your team agreed on in the issue, nothing more. You can report things to improve in comments sections, where they could be evaluated by your team and finally become real bugs reported in the system. Some managers also may bring to the top a financial aspect of doing too many in a single issue because the client may not wish this fix or even pay for it.
Not doing a self-review before requesting a review. Self-reflection on what you did is often underestimated but IMO is a crucial part of a developer career and self-improvement in general. The better you can reflect on your code the better developer and team player you would be.
Win: after writing the code, sent it to PR, and do a self-review in the tool your team is using (GitHub, Gitlab, JIRA, or other). Seeing your code as the reviewer would see it, would give you an opportunity to yourself in the position of the reviewer (reviewing your own code) and potentially find obvious bugs which a reviewer would detect. This step is not about finding all possible pitfalls in your own code, but mostly the obvious ones. Itâs also an important step in reflection on your code and what you still need to improve. Additionally, the fewer things the reviewer would need to write in your PR, the more they will love to review your PRs again - as they will assume you are good and deliver quality stuff.
Requesting a review of a dirty code. After you have complete your solution (itâs finally workable) do not send it directly to the review. Clean your solution first and then send it to the review. Reviewing a dirty code is basically useless because even when the solution is working the code may look incorrect and not be accepted by team code standards.
Win: Remove added comments, run code formatter against updated files and never send a dirty code to review unless you want to be considered a newbie or dumb. The other people spent their time and skills reviewing your stuff, so appreciate it and learn from them. If you will value others, then others will value you and your work.
Lack of good information flow. Communication in web development is essential and equally important to the skills you will bring to the team. Even when you are a god of coding but suck in communication, you might become an outcast and feel bad in the team and vice versa. Great communication can speed up any project progress for days or weeks and additionally build good vibes in the team. I see it as:
Win: When you finish your PR, mark it in your source code management tool (GitHub, Gitlab, JIRA, âŠ) and inform your team about it in some communication channel. This may speed up work due to some of your colleagues may wait for it (or/and need it as a base for something else). Collaborate and work together.
Do I reach the bottom of this topic? Definitely not. I wish, I could write here more, but then this would be a book instead of an article đ.
Remember, all things about the code review is to discover and learn. Discover possible ways to improve the project and learn to make things better in the future. Do better and be better.
Good feedback always should strive to be positive with enough space for reasonable but gentle critique.
I would love to know your opinion about it. Let me know what are your top sins and wins of code review. The comment section is yours.
]]>The fact I love Vim doesnât change another fact, that I use also other text editors or IDEs during work. The reason behind it is because configuring Vim to do some special, sophisticated tasks can be tedious, difficult and a lot time-consuming.
For example, configuring Vim to work as a real IDE is hard and here I mean the configuration, not for a single programming language like - Vim as Python IDE. No, this should not be so difficult. I rather think about configuring Vim as IDE for multiple languages - THIS is difficult.
Using Vimâs powers only for 1 language would be just so much waste of the greatness this text editor brings to the table. As a webdeveloper, I use multiple languages (not only a single one), so for me, itâs not sufficient to have a Vim config designed to operate only for a single language. I am using daily: Typescript/JavaScript, HTML/CSS, Golang, C#, Python, SQL. So now I need to pick what I want? Or having a config for each language? Crazy! No!
Therefore I use Vim almost exclusively for efficient document edition or creation but in sense of a single operation which takes a max of a couple of minutes. Vim is extremely efficient for opening and editing even multiple GBs of files. Although, Vim was not designed to work in a single window session for multiple hours (like IDEs doing it) - believe me or not, but Iâve already tried that multiple times with a different set of configurations and workflows. Of course, if someone is stubborn and wants to do it, will do it, but it does not make much sense for me so far.
At this time on the scene enter IDEs. Editors on steroids, designed for great development experience, and when mastered, they increase developerâs productivity far more than just regular text editors. I very much like IDEs, especially when working multiple hours doing standard CRUD operations on files, saving to git, sending to server, comparing between branches - Ay Captinâ, they are great for this. Period! đ
However, recently I received a task that was perfect to show off how effective Vim could be and how it can save your time during development!
The task was simple while working in pairs on the issue. I had to implement a tedious creation of a C# dictionary from a list of countries Iâve received from a client in a CSV file (you can download it below), so my colleague could utilize it in his program.
There were 351 rows with ISO Code
and the name
of that country in English - quite simple.
If you are interested here is the file to download and try it out.
Ok, then âcopy & pasteâ into the Vim and we get something like this:
Domain Name,Ref Code,Ref Description
COUNTRYCODE,-,-
COUNTRYCODE,AFGH,Afghanistan
COUNTRYCODE,ALAB,Alabama
COUNTRYCODE,ALAN,Ă
land Islands
COUNTRYCODE,ALAS,Alaska
...
Letâs get rid the first line (the one with column names) and COUNTRYCODE,
by column editing.
We have a nicely prepared file. Now we should focus on the next part - building our macro where the whole magic will happen.
But before jumping into writing, letâs think for a second - how we can construct this macro? đ§ - because the whole trick lies in it.
The plan is to record a âsmartâ macro for a single line and later repeat it for all other lines. But again - how to build this âsmartâ macro? - To do this we have to think about what kind of pattern we could notice by looking at our cleaned file? Letâs look at a fragment of this file:
...
ARKA,Arkansas
ARME,Armenia (Republic)
ARMES,Armenian S.S.R.
AUS,Australia
...
We have:
ARME
. Irregular length of characters. Sometimes 3, other time 5.,
) characterWell, the simplest way I could think of, would be something like I{"<ESC>ea"<ESC>wi"<ESC>A"},
, and the version with a full macro to q
register could look like this:
qq<ESC>I{"<ESC>ea"<ESC>wi"<ESC>A"},<ESC>q
FYI:
<ESC>
= represents a single key on the keyboard (escape)
The last step would be to repeat this macro to all other lines (the first line is already done).
VG::normal @q
Yes, the core of our class is almost done. The last part would be to wrap it in a class and our work is done! Wow! Honestly, even when I know about Vim macros, this still impresses me.
Disclaimer: This task could also be accomplished with any editor which supports a multi-cursor feature (like in SublimeText or IntelliJ). But if this task would be a bit more complex (letâs say, we would have additional 3rd and 4th columns) AFAIK only Vim would be able to do it with its âmotion operatorsâ (another superpower of Vim).
So, the final result should be like this:
namespace MYPROGRAM.API.Features.FeatureA {
public static class CountryCodes {
public static Dictionary<string, string> Countries = new Dictionary<string, string> {
{"AFGH","Afghanistan"},
{"ALAB","Alabama"},
{"ALAN","Ă
land Islands"},
{"ALAS","Alaska"},
{"ALBA","Albania"},
{"ALBE","Alberta"},
{"ALGE","Algeria"},
...
{"YUKO","Yukon Territory"},
{"ZAMB","Zambia"},
{"ZIMB","Zimbabwe"},
{"ZZZZ","Non taxable countries"},
};
}
}
And here we are, at the end of this trivial presentation âwhat Vim could do for youâ.
In last finishing lines I would say that as a programmer while doing some task I am usually time-constrained (previously estimated) to prepare a feature. Therefore, I donât have luxury to spend all of it on searching new tools, which could help me accomplish repetitive tasks. The decision is most of the time simple: searching a solution for a few minutes and if I canât find something that solves my problem quicker then I do it with existing knowledge/tools. Sometimes, it require writing using some CLI program, sometimes a small script, and literally if noting else can help, I must apply changes manually. With Vim manual changes are really rare. Honestly, I donât know any other tool which so easily and simple help me with accomplishing the result I need.
The true advantages of Vim donât show up because editor is developing more then 30 years and it came along with âmulti-lineâ cursor. Today we have 2020 and any more advanced editor have multi-cursor. Its true power is hidden in motion operators (w, e, b, etc.), explicit diverge for typing modes (insert, visual, block, etc.) and macros. IMHO, those 3 makes from Vim an ancient artifact with superpowers. Once mastered, the man can make things the others can only dream about đ.
Thank you for your precious time and reading this article.
]]>A few days ago I received an encrypted message from a stranger. Unfortunately, I canât read it. I stumble upon a problem, that I forgot my GPG passphrase! Oh, no!
Iâve searched for potential solutions on the Web and found this nice article Oh no, I forgot my PGP private keyâs passphrase from Esteban Sastre where he describes his almost identical problem about forgetting GPG passphrase.
But the conclusion from Estebanâs article wasnât encouraging because it seems that there is no other way to get a GPG passphrase back after you lose it. Sad.
I didnât stop searching. Although, unfortunately for me, I only found a couple of other confirmations the hypothesis (of no way to retrieve a password), in the following websites:
I still could not stop thinking âhow can I get my passphrase back? I thought, maybe I could just write an e-mail to one of PGP server admins, so they can remove my key and I will be able to just create a new pair of keys and the problem would be solved. Quick search and⊠No! Officially there is no way to remove a key from public servers without having a passphrase to your key (to create a recovery certificate). Reference link you can find here.
AaaaahâŠ! đ€ But I get it, I understand. Itâs about freedom and security reasons. It makes sense. For the same reason, I also published my key online⊠đą
When frustration went away, I become even more determined to get my lost passphrase back! My key hadnât any expiration date! In other words - this will never be invalid or removed from any key servers! Among the results of âhow to get GPG password backâ, I was only thinking that the only way to get it back, will be through using John the Reaper. Wait, wait, wait. Iâm using a password manager, and this passphrase must somewhere there. I got a one, last try and peek once more into my password manager⊠I dig deep, through hundreds of entries, and also the history of those entries and⊠puff! Iâve fount it! Uff!
The problem was that there was a bug in my password manager (and I think it is still there until today - the publication of this article). The bug is about: when you create a secure note and lock password manager or quit, the note is dropped/erased. Itâs somehow overwritten by an empty string. The only way to get it back is to take a peek into a history of this note! A nightmare of any users who use password managers! đ±
Lesson for users with password managers
Always create new item/entry per each key or passphrase, so the key is easy to search.
Lesson for GPG users
Always create your keys with expiration dates and store your GPG passphrase in 2 places. Really, just do it!
Oh, there was a lot of frustration and irritation in the last couple of paragraphs. Instead of just feeling positive emotions and thrill whatâs inside I got a package of disappointment that I presented for myself supported by a silly but nasty software bug.
Ok, but what to do now?
Except for the pieces of advice I posted at the end of the previous section, I would recommend you creating the recovery certificate and store it in a safe place. Creating a recovery certificate will allow you to start the process of removing the GPG key from all key servers, in case your passphrase will be lost again. In other words, communicating all other users that this passphrase has been compromised and is no longer valid.
Letâs do this. First, list your GPG fingerprints to reveal (you can have much more entries)
$ gpg --fingerprint
--------------------------------------
pub rsa4096 2019-03-17 [SC]
78CA 0E18 1F71 CFD6 F02A C05E 10BC 01ED A682 7DC8
uid [ultimate] Maciej Sypien <maciejsypien@gmail.com>
sub rsa4096 2019-03-17 [E]
Create a certificate using your e-mail address:
$ gpg --output ~/revocation-certificate.asc --armor --gen-revoke your@email.com
gpg: Sorry, no terminal at all requested - can't get input
Whatâs that? Iâve made another search for the given error message and found the problem. As Iâm using a macOS and Iâve configured my Automatic Git commit signing with GPG on macOS, I have to temporally comment no-tty
in my ~/.gnupg/gpg.conf
.
$ gpg --output ~/revocation-certificate.asc --armor --gen-revoke your@email.com
sec rsa4096/10BC01EDA6827DC8 2019-03-17 Maciej Sypien <maciejsypien@gmail.com>
Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
0 = No reason specified
1 = Key has been compromised
2 = Key is superseded
3 = Key is no longer used
Q = Cancel
(Probably you want to select 1 here)
Your decision? 1
Enter an optional description; end it with an empty line:
>
Reason for revocation: Key has been compromised
(No description given)
Is this okay? (y/N) y
Revocation certificate created.
Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable. But have some caution: The print system of
your machine might store the data and make it available to others!
Now, when you have your key revocation certificate time to secure it in a protected place. I would recommend not putting it in a single place and additionally use 2 different ways to store it: analog (print) and digital (in your password manager).
Using macOS, install a library that helps us to generate a QRCode locally on my machine.
brew install qrencode
Generating the QRCode is really simple, important is to get a good quality of the output format, therefore I like to use SVG.
qrencode --output revcert.svg --dpi=600 --size=20 --type=SVG --read-from=~/revocation-certificate.txt # SVG ~10cm
Now, print it and store it safely.
Links used while writing:
In this article, I would like to analyze what is web-development a favorable behavior, human model. Furthermore, I want to dispute what kind of factors advocate, that a person is promising or when the attitude could suggest to the others to be an anti-programmer type.
Disclaimer: this topic is huge and the man could write a book about it. In this article, I will try to emphasize some points which might be a bit different from the well-known stereotype (intelligent, educated, fast typist, fast thinker). This topic will also try to answer the question of how to discover some true potential even in a programming newbie.
What could advocate for being a promising/awesome programmer to the others? I will not take into consideration the obvious part - skills (which are crucial to getting the job done), in here, I will try to focus on behavior and character of each personality and how this might correspond to become an effective programmer.
Being patient is an important skill and often underestimated by people. Why? Being patient should be somehow written in the programmerâs profession. Being a code writer is not like making up a novel where anything you will write doesnât need to make logical sense. It is more like a fight, where every single day you will make a battle against the logical structures of the code. On this battlefield, your enemy is the code and the opinions of other people about your code because, in the end, both things have to meet together.
For a programmer, there are many occasions in each day where you will have to deal with other people who wonât share your opinion of accomplishing stuff. For this human interaction, the patient is the key. Being patient in this profession has a major foundation upon which you will build your digital career - without it, burnout is guaranteed, it will be just a matter of time when it happens.
As I already mentioned, this type of job is almost all about analyzing and solving problems. So being naturally curious helps with daily tasks and reinforces the feeling in the eyes of others that youâre the right person in the right place. Builtin curiosity and the strong need to learn new stuff usually leads to the holy grail of programmers world, the solution.
Open to constructive critique. Being a programmer is not a fairy tale - itâs difficult. There is a lot of hidden frustration or sometimes even rage, about the code in the codebase (search for any infamous rage discussion in OpenSource projects). The high ability to talk about the code from the perspective and being as much objective as possible, will in the end give you the best of the best - inner relax (and to the teammates) which in the end will be forged in high-quality code.
A need for code reviews, should be high in good daily team workflow. The reason for this is, the more code will be reviewed by the programmer, the more he learns. This also works in other directions, the more critique you get about your code the better you will be in future solutions. Primary, good programmer learns as much as possible from the others, to not make those mistakes himself. Secondly, to write better code, a programmer must be open-minded and applying a constructive critique from the reviewers in his solutions.
Keep It Stupid Simple (or KISS for short), this is without a doubt the central motto of many programmers with well-developed habits. E.g.: by keeping your code small and simple (small diffs) there will be a great chance, that your change will be soon accepted by the code reviewers and merged. Hence your job will be done sooner, the others will have a feeling youâre more productive than the general average.
Keeping an eye on the goal - programmers tend to be like a Captain of a pirate ship, they sail in various oceans of digital bits, but the goal changes along with the wind. This shouldnât be like that. Itâs a tempting carrier to be like the Captain of a pirate ship, but often it will lead to troubles. In some example scenarios, if you will not keep an eye on the goal, it could exceed the estimated time to accomplish the issue (if you follow agile) and besides somebody waits for your solution to continue his work - this could lead to misunderstanding, frustration in a team, or working late to deliver the feature. To omit these problems, try to be more like navigator on the ship, no matter what will surround you, by looking at the stars (i.e.: issueâs acceptance points and your knowledge) you will always find a way for yourself (and for your crew) to get to the port. This will put more light on you, as a leader of a group.
If youâre a web developer and you get the task which you know how to accomplish just after youâve heard it - great, it should be easy, right? Although, itâs not always like that! Most of us (programmers), when getting some task, usually donât have a clue how to finish it, nor how much time they will need for this. However, do not afraid to get out from your comfort zone - itâs important to go further because this is a part of our profession to learn and discover - uncertainty is high, but usually reward as well. Being a good programmer is never to be closed only in the solutions you already know, rather be open on new, unknown possibilities. This is the power of a true effective specialist, being adaptive.
Programming is almost all about collaboration and sharing ideas or solutions. If you donât believe me, take a look at this piece of electronic on which youâre reading this article at the moment. Now, think for a few seconds and ask yourself a question: Do you believe that this device (and its software) has been made only by one person? Definitely not! So this means to be a good programmer, you should a good team player? Yes, you should be a team player, but fortunately at some point programmer must do some solo activities.
If I would summarize in a simple scale factor of 10 points how much of teamwork is to do compare to solo - I would say itâs like 3-5:7-5. Depend on the type of task, 3 up to 5 points will be spent on team collaboration, analyzing the problems, and pressing the goals. The rest, 7 up to 5 points will go in the research and physical implementation which is usually a solo activity.
Doing exercises. I think I would not lie to you if I would say that itâs popular that IT guys (of any sort) are either fat or thin like a stick. Fortunately itâs not always the true in XXI century. Many âoffice workersâ follow new health trends. But for many people who work in the office, itâs hard to resist the higher need of always having something sweet on the side. I think this case applies especially for programmers, where there is a trend to provide all possible sweets or soft drinks in the office (aka. âkitchen goodiesâ, or something similar). Then the temptation of not trying anything of that is huge! But a âroundâ programmer is not a bad programmer! I know a couple of extremely good programmers who are really great big guys. Although, IMHO this has a deeper meaning. Some of them are overweight because (Iâm not involving in it any illnesses nor disabilities) programmers tend to work in front of a desk for long hours. Moreover, to be a better programmer, usually, the person has to learn a lot and cover this with practice, which usually means that you have to spend even more time sitting. While your code skill will rise, the same does your weight. This means the truly effective programmer will also take care of his health by doing some activities to keep the body (and the mind!) in good shape.
For some of you, this also might be silly but good position while sitting might tell if youâre treating your job seriously, and you want to be the most effective as possible. People who have a good position while sitting in front of their computers have fewer health problems which means they will be more compelling at work for a longer range of time.
Drinking a lot of water. This usually isnât even noticed by other people. For a second try to be 100% honest with yourself, and ask yourself a question?
How often have you noticed that your buddy at work drinking water instead of Coke or other soft drink?
A possible chance 30-0% that youâve noticed someone. Nevertheless, this simple habit of drinking water will have a significant meaning for your mood and general health. Itâs well known, that sugar is some sort of âa legal drugâ, and it wonât increase your thinking capabilities, rather the opposite. You might think, that it gives you a boost, but sweets will tell your brain to âfeel goodâ, but itâs only a feeling, temporary feeling. Pure water instead will boost your organism to correct and effective work in a long time range.
Now, if you will see a programmer with a bottle of water nearby and the same one with Coke you will know which one will be more effective at work đ
Becoming a better programmer is not easy. I donât want to sound pessimistic nor discriminates anybody here from the future in the IT industry. I just want to emphasize that not all people have mental predispositions to become one. As analogy example is the Psychiatrist job - it requires a specific immersion on how you work, involvement, and some psychological resistance to things that are happening around. The same is in programming - for some, programming is the most boring job around the world (e.g.: clicking the whole day on a keyboard), although for others, it is a dream job, like the best way to spend time improving this world.
Some of the characteristics below might strengthen, that a person you think of, could have some difficulties with becoming a better programmer.
Having no daily routine could be one of the key features of inefficiency. The work of web-developer is almost all about routine and repeatable tasks. For instance, checking new emails 4-5 times a day, daily stand-ups, sprint planning, sprint retro, reviewing available merge requests, etc. If there is no routine, then it will be hard for that person to synchronize with the team.
No design docs. By this term, I have in mind omitting a sketching session (or whiteboard session) and just a straight way to start writing code. If a person doesnât know what she is doing, this will definitely (in the best scenario) extend only the estimated time for implementation. But in the worst scenario, this could fail finishing project/feature on time.
No effectiveness. Simply saying, this could be visible, by just being extremely slow at work and not doing much during the day. This could suggest either this person is a programming beginner or really something is wrong (maybe some personal problems - is always good to ask). Sometimes producing a âhackyâ code that is difficult to understand could also be a case for low effectiveness since this person is no ability to create a clear understandable code.
Low APM (actions per minute) - this situation may affect people which are constantly connected with their social platforms (e.g.: watching Reddit, Instagram, or YouTube videos) that in the end distract them from being focused in their productive window (see picture below). But donât get me wrong, everything is for humans - e.g.: Iâm listening to music on YT while working, but I donât watch the video. I just enjoy the music, so the video isnât distracting me. The problem arises when someone doesnât know the difference or simply canât stop - easily distracted, not a productive person.
Source: Quora, âIs it better to work 5 eight-hour days or 4 twelve-hour day shifts?â
Lack of motivation or being constantly tired - itâs could sound silly when youâll read it for the first time. Moreover, this could be assigned to any other profession (not only to programmers!) and will also fit. But the difference that distinguishes programmers from other IT professions, or professions in general, is the extreme focus while working (writing a program). The program has to follow some logic, whatever this logic is, but have to be some and must make sense. When youâre tired of your motivation is somewhere else, itâs difficult to write correct/good code because youâre thinking about completely something else.
No room for tests - oh, if I heard something like this:
âMy code is working, you saw it - I donât need to test this, I already did that!â
I immediately start having a goose-flesh when I just look at this person đł. Itâs not about ânot knowing how to write tests or testing in generalâ, itâs more in the way of human attitude or/and ignorance towards the work to make code better (less error-prone). In the end, nobody wonât need to clean somebodyâs else mess (e.g: a nasty case where the code crash the program).
Every good programmer knows that tests are for everyone involved in the project (not for the entity), so they can claim with high certainty that the code they produced (or change) works in given test scenarios. Without tests, even the best code may be worth nothing to other programmers, because as professionals if they change something and there are no tests, they literally cannot assure the correctness of code running. Tests are for making your work-life balance sane again.
Asking for everything and not thinking for himself or something similar like donât ask for any help after spending a lot of time on an issue. Those to things are incomplete opposite, although both might a negative impact on the team velocity. E.g: having a person who is a beginner and learning things. Then after a couple of sessions, youâve noticed that she keeps asking the same question over without any reflection on them, then this in the real world sprint may crush the objectives in the sprint vision (or miss the deadline!).
The second one, ânot asking for help, and waitingâ - this is far worse than being overactive. As you have in a team a âticking bombâ, you donât know when this bomb will blow one of your deadlines - really nasty and stressful character/behavior - so itâs good to keep yourself just in the middle.
In sum: âKeep up with asking questions, but think along as well!â
Having no interest in personal development after the working hours. There are 2 opposite camps on this topic. Group one, the one being against spending personal time (time not given in the working hours) on self-development nor reading news from the world, will IMHO always sooner or later fail. The world of IT is changing so rapidly, that sometimes a couple of months missing in the field, might impact a lot of troubles.
Also to be frankly speaking, I am not saying that you need to spend all your free time to learn stuff for work. I want to tell you, you should spend some free time to expand yourself in general-IT way, and âthe wayâ itâs up to you. As a programmer youâre âsellingâ your skills by writing fast the qualified code, therefore your skill has to up to date in order to be useful at all. If this is not happening, as a programmer you are useless (itâs hard/firmly said, but itâs true).
No blogging nor side projects. If programming could be shortened to 3 things, it would be planning, implementing, and reflection. All those things coexist with each other and itâs difficult to separate them. Planning with implementation is OK, but if you do not reflect on what you did it will not give you anything in your future career, you will just reproduce what you already know. Therefore, blogging helps to rethink and reflect on ideas you had which in the end can help you to:
Accomplishing side projects can usually help to systematize and consolidate your knowledge into a skill(s). Usually, itâs this combine implementing and reflecting on what youâre doing, and by its physical form of practicing you learn the fastest way.
If someone is not blogging nor doing side projects you can with high probability claim this person is not progressing with his knowledge/skills.
Below I gather some points that could reveal an inexperienced programmer or suggest that there is still a room before he will become an independent developer:
lack of best practices (Spaghetti code) - she believes that âhow the code is organized doesnât matter, it just needs to runâ
large diffs - combining multiple problems in the single solution (pull request), or the problems that âwould be niceâ to finally have.
huge methods - building a complex method which does a bit of everything inside, including bear-dance - OK, just joking here, but you get a point.
inappropriate variable names - constructing variables or methodâs parameters which are like a math-teacher function names f(x) = x, y, z ...
. No
dozens of âifâ statements - not knowing how to properly use if
statements or without any good reason nesting them in few levels.
not writing tests because:
pre-optimized code - before writing any line of actual working code, a person just debating about the advantages of while
over the for
loop, to just a display a simple list.
I would agree, but later - at first, the code must work, and only then you can optimize it when there will be a real need. Only in rare cases, this optimization makes sense.
over-engineered code - providing, unnecessary options of customization without any good reason (e.g. because itâs cool to have it there, isnât it?)
copy & paste code without thinking about it - coping the code from other projects as is, or overusing the great help given from the stack overflow.
Of course, this has to be in a reasonable range. When you write component or service which is meant for reusing, it how it supposes to be. Here I am talking about when someone copy a whole section of solution from one place, change only a couple of things, but the majority of it is just not used (dead code).
arrogance (not respecting the opinion of others) or heavily arguing about own code - I.e. itâs about thinking that the code written by this person is perfect and no one is allow disputing or question it.
donât like code reviews - code reviews are for the weak!
We should always try to search for goodness and positives sides in people. Although sometimes the truth is difficult, sometimes inconvenient, but in the end, itâs a result of many factors.
Many, may not agree with me, but I think there is no quick or best way to say how good is the person you just met (or objectively measure yourself). Many points I wrote, also I had a problem with, even after a couple of years in the programming industry. To become a good programmer is never a switch case - puff, and I am a one. Itâs a process that requires time for learning, practicing, and perceiving all in this process.
On the other hand, each programmer will be finally dragged through exhausting testing steps. Itâs common pattern at the moment, that mid-size and big IT companies have longer and more exhausting recruiting procedures (to testing different levels of your skills like: core skills, human interaction, psychological tests, decision-making test etc.) to check all hallmarks they looking for in the potential candidate. I do not believe this is best way but each company may require a bit different skill-set than the other.
In this article Iâve mentioned only a small collection of my remarks, which in the end, are only a drop in the ocean of recruiting characteristics, usually processed by highly skilled recruiters or head-hunters. Honestly, I am not a fan of in-depth person for a couple of days just to hear: Welcome aboard, now you can code for us. I believe that talk and small, concrete code-puzzle-case will do the job. As the main part of working with the person for few weeks will reveal the full picture.
For the first time, I could experience in real life that someone knows how to use encryption, and sends a message to me. From my experience, itâs rare to see it if someone sends you an encrypted message, therefore I was motivated to read what this person has to say.
After searching for some help on how to safely process reading this message further, unfortunately, the ocean of tools and not precise tutorials only get me even more confused, so I thought after figuring all things out, I will summarize this process here.
Although, if it does not scare you, and you find this interested in how I did it anyway, you can read more about it in The lesson of verifying Git commits. đ
Letâs say you received an encrypted message and now the question is, how to read this message?
It depends on the format you have received it. You can receive the whole e-mail encrypted, or an e-mail with an encrypted message, as I did below. Nevertheless, generally, you should get something that looks like this:
-----BEGIN PGP MESSAGE-----
hQIMA+vud8VzRJSmAQ//TEZwWw77MXJMXLds5zTEznJlyuRIIN/DR5xi+Fc/CX4u
FnGdS8lMlczDeQj5u1607HhmB/2MqnzZUlYATA+OLJswX4B2nqdWVo+u4Z+ijjCW
...
...
...
+FC1gpSOnEH9TMGtvW/ogKcAYkbFj4FMhfT+1cfcyEQ=
=c4x/
-----END PGP MESSAGE-----
Ok, there is an encrypted message. The best would be to save this message in some text file, like for example encrypted_message.txt
(as it will be a bit easier to decrypt it in a later step). Additionally, it does not matter which extension you will use to encode your message.
Now, is the time to check if this person who sends us the message has a public key in one of the public PGP servers. So I am checking it, and there is a mystery guy.
â gpg --search-keys matbit@secmail.pro
gpg: data source: http://83.227.87.55:11371
(1) Hu2020 (Hu <matbit@secmail.pro>) <matbit@secmail.pro>
3072 bit RSA key CBFD27BAA73638F2, created: 2020-06-14
Keys 1-1 of 1 for "matbit@secmail.pro". Enter number(s), N)ext, or Q)uit > s
After I search something about secmail in general, it become more obvious to me that this person just paid for anonymity and an easy pre-configured platform for sending encrypted emails. At this moment I knew that there was something not right - disappointing.
Ok, letâs download a public key of our stranger, and read this message.
gpg --receive-keys CBFD27BAA73638F2
Tada! The message is decrypted and I can finally read it!
â gpg --decrypt ~/encrypted_message.txt.gpg
gpg: encrypted with 4096-bit RSA key, ID EBEE77C5734494A6, created 2019-03-17
"Maciej Sypien <maciejsypien@gmail.com>"
Dear Maciej,
...
Thatâs all. Hope you enjoy this small, simple explanation of how to read encrypted emails. Stay secure, and until next time.
]]>