skipcloud

BASE = 11
MODULUS = 81

class Person
  def secret_num
    @num ||= rand(50).to_i
  end

  def prime_to_the_power_of_secret_num
    BASE ** secret_num

skipcloud

I wrote a shell function to fetch the Word of the Day from Wordnik.com.

You need to have jq installed as well as a Wordnik developer API key.

I've added it to my .bashrc file so I get the word of the day every time I start a new shell. To save making a request to the API each time a shell is opened I've saved the word of the day in a dotfile in the users home directory. If the dotfile is a day old then it will make a request and update the file.

If the -f option is provided it will fetch the word of the day anyway and update the dotfile.

# wod() returns the Word of the Day from Wordnik. 

skipcloud

A few posts ago I introduced git commit --fixup to help you better organise your commits (https://skipgibson.dev/2020/02/09/git-fixup.html) , but what if you have made two changes in the same file that are better suited to being in different commits? git add <file> will stage the entire file so that won't do, I think it's time we spoke about git add --patch.

From the git man pages:

Interactively choose hunks of patch between the index and the work tree and add them to the index. This gives

skipcloud

Have you ever tried to merge two branches only to end up in conflict hell? You fix a bunch of conflicts only to run git merge --continue and be presented with the same conflicts. Repeat this process and after a few iterations you give up because it just isn't worth the pain and effort.

Would you be surprised to know that there is a git feature specifically for this problem? It's called rerere and I'm going to enrich your life with it now. (I'm going to talk specifically about merging but I think it also helps rebasing)

rerere stands for Reuse Recorded Resolution. The TL;DR version is you ask git to remember how you've resolved hunks in the past, and if the same one comes up for a file in future just redo what you did last time.

To enable this feature just run this lovely command git config --global rerere.enabled true. You can also turn it on by creating this directory in your projects .git/rr-cache, although the global setting is much clearer.

I'll try to take you through an example of how th

skipcloud

Have you ever branched off what you thought was master, done a bunch of work, only to then realise that you actually branched off staging, or some other branch? I have done that a few times and it's mighty annoying. I used to just created a new branch and cherry-picked the commits from my failed branch. As is always the case with git, there is a command to fix this scenario.

Before getting to the meat of this tip I think it's good to understand what happens when you rebase normally. The git rebase command takes two arguments git rebase [] [], if you don't supply the `` argument it will assume you want to use HEAD which is the current branch you're on. For example, say you are on branch `dev` and you want to rebase with `master` (the branch that you branched off originally), you could write `git rebase master dev` or `git rebase master`. Git then takes all of the commits from `dev`, puts them in a temporary area then reapplies them one by one to the end of the upstream branch.

skipcloud

Have you ever been digging around in the bowels of a repo on the command line

app
├── spec
│   ├── base_application_spec.rb
│   ├── call_center
│   │   ├── consumer
│   │   │   ├── application_spec.rb
│   │   │   ├── areas
│   │   │   │   ├── account_spec.rb <---- you are here

skipcloud

Git is a great tool, one that (when commits are created correctly) makes PRs easier to review and even makes life easier for developers in the future who might need to investigate your code. This isn't a post about what makes a good commit but generally you want to avoid things like "fixed typo" or "removed comment", these are of no use to anyone. But say you realise you need to make a change that's relevant to a commit that's a few commits down in your log, like this:

e8e6ecb (HEAD -> master) Change relevant to commit B
01d71d1 commit C
064b768 commit B
7519200 commit A

If that change was instead better suited to go with commit C then you could've added it to it with git add <files> && commit -v --no-edit --amend which will add it to your previous commit without seeing if you want to amend the commit message.

skipcloud

Good morning! Couldn't think of a tip for you but still wanted to write something to spread some knowledge. This is about how computers handle numbers, specifically how it affects dates. This might be a little waffle-y.

Do you remember the Y2K problem? To understand why this was an issue we need to know a little about computers back when they were in their infancy, the 50s and 60s, when memory was at a premium. In 1965 the PDP-7 computer[1] had a whopping 9KB of memory, which could be expanded to a eye watering 144KB. As we got into the 70s memory improved but not by much, this meant that when programs were being written they had to be as economical as possible when it came to memory. One way of doing that is to store dates as two digits 00-99, after all this won't be an issue in the future because computers will improve and this code won't be running then, right? If you know anything about programming you know there is a lot of code running in production that has been there a long time.

The issue here is

skipcloud

Most of you use vim everyday as it's the default editor that is opened when editing git commits. Instead of dealing with a wall of white text why not enable syntax highlighting? If you use vim as your editor or you have $EDITOR set to something else then this one isn't as useful for you.

Create a file .vimrc in your home directory with syntax on. This file is sourced everytime you start vim.

echo syntax on >> $HOME/.vimrc

There's a bunch of default colour schemes to choose from, to enable one just append colorscheme <name-of-color-scheme> to your .vimrc

blue
darkblue

skipcloud

Just had a fun moment where I didn't realise I was on the master branch of repo and was able to force push after a rebase (a dance I'm so used to during development I do it almost without thinking). If you're like me and don't want that to happen to you you can set up a safe guard to stop you ever being able to push to master. What you need in your life is a simple git hook. Here are the steps to create your own if you want

Tell git where to find your templates for new repos:

> git config --global init.templatedir $HOME/.git_template

Next, create that directory with a hooks directory inside it

> mkdir -p $HOME/.git_template/hooks