Are you bored of colours on your internet?

Experiencing information carnival of rainbow puke overload?

Here’s the Chrome browser plugin for you !

(un)clrd

No nonsense, black and white www.

A module contains methods. These methods can be included in a Ruby class.

module Chicken
 def ChickenOrEgg
   puts "Chicken"
 end
end

module Egg
 def ChickenOrEgg
   puts "Egg"
 end
end

class WhichCameFirst
  include Chicken
  include Egg
end

WhichCameFirst.new.ChickenOrEgg
=> Egg

This forms an ancestor tree/array of methods for the new instance object WhichCameFirst.
The methods themselves are still stored in the class WhichCameFirst.
Method dispatch is Ruby’s way of running through this ancestor tree.
The last to be included, will be the first in the ancestor tree.
This is the order Ruby runs through for WhichCameFirst, from Left to Right.

WhichCameFirst.ancestors
=> [WhichCameFirst, Egg, Chicken, Object, Kernel, BasicObject]

Chicken would come before Egg, if Chicken had been included last instead of Egg.

Ruby will dispatch method order differently depending on whether modules are included, extended, or super’ed’.

Include will make the ChickenOrEgg method available to an instance of a class and extend will make the ChickenOrEgg method available to the class itself.

WhichCameFirst.new.ChickenOrEgg #include

WhichCameFirst.ChickenOrEgg #extend

So what happens to the ancestor order of methods when we extend?

class WhichCameFirst
  extend Chicken
  extend Egg
end

WhichCameFirst.ChickenOrEgg
=> Egg

WhichCameFirst.ancestors
=> [WhichCameFirst, Object, Kernel, BasicObject]

The result is still Egg, as we would expect. However it seems Egg and Chicken have disappeared from the ancestor tree. This is because we have extended the class’s metaclass to contain the methods, rather than including the methods in the class of a new instance object.
“Instances don’t store methods, classes do.”

Extend means extending a class object’s metaclass – it’s “alter-ego” – it’s “ghost class” – it’s eigenclass / ownclass – so the methods are stored here. Hidden from the ancestor tree.
“Instances don’t store methods, classes do.”

Where as include still had the methods available – to the new instance object of the class – in the class – so the methods are still stored in the WhichCameFirst class.
“Instances don’t store methods, classes do.”

My Git Epithany happened by first viewing Jamis Buck’s presentation “Algorithm is not a 4 letter word” and then reading through Sam Livingston-Gray’s the “Think-like-(a)-Git” steps.

Taking in the “Algorithm is not a !@%#$@” knowledge first, helped make the Graph Theory section of “Think-like-(a)-Git” chime all the more.

The path finding logic behind maze algorithms chimed with the idea of Git Garbage Collection. ‘git gc’ makes git list every commit it can reach, meaning when it gets to a dead-end, it deletes whatever is behind that dead-end. Everything behind that end is dead to git. I am yet to use ‘git gc’ but I hope as my practice with git progresses, it will become clearer when it’s worth using.

References

I’m still unsure what Tags are exactly, but finding out what References are and their 3 different categories (including Tags) was useful. Rightly or wrongly, thanks to the REFERENCES MAKE COMMITS REACHABLE mantra section, this is how I now imagine a git repo to be composed.

Reading about the ‘git commit –amend’ command was also very enlightening. To make another separate commit after spotting a syntax error, whitespace, or unused variable always felt very inefficient and like excessive data entry.  This will probably become my new favourite git command.

Prune

I enjoyed going through the savepoint and scout repo patterns. Most enjoyable was typing ‘git branch -d test-branch’. I think this is because one of my favourite things to do Away From Keyboard is cutting back bramble bushes and hedges.

“Creating a branch is like saving a game before you battle the boss.”

Visualise

For a git visualiser, I chose to install gitg in Ubuntu. To run it from the terminal, you simply type ‘gitg’ in the directory path of the repo you are currently working on. You then have to close it to continue your usual commands.

Rebasing – WHAT WHAT WHAT are you doing ???

Daily work emails say mysterious things like ‘please rebase this repo’. I sat and watched someone take me through a rebase of my repo. I still had no idea what a rebase was, or the point of rebasing. It was seemingly the most whimsical Git thing to do, even more arbitrary than Tags*.

Thanks to Think-life-(a)-Git’s section on rebase, I now imagine rebase to be like cutting old film negatives to re-order them and change the scene order of an old movie reel.

Once different teams have agreed on the best features to merge into master, you’ll want to all be starting from the same commit history from master again. You want to all have the same ‘base’ to branch off from again.  This is when you rebase. You’ve agreed on what the first 5 scenes of the film will be, and you want everyone to have the same first 5.

That’s the base of your film. Then your teams will go off and film 20 new scenes, but you’ll only agree on the next best 5 to merge onto the first 5. So you’ll rebase, and have the first 10 scenes of your film.

 

Sidenote:

Talking of parallel universes, maybe our universe really is a branch of an infinite repo movie reel / Samsara wheel. With each universe node being pointed to with an amplituhedron for reference. git branch -d epithany.

*Tags are for when something really significant has happened. Like a new version of your project. You can Tag it as ‘v1.4’ and always refer to a version by it’s Tag for future reference.