How to gitignore sub projects

Leave a comment

If you have dirty subprojects (say in a project named core) do this

Screen Shot 2017-01-11 at 1.51.22 PM.png

How to quickly find a PR on github or ghe

Leave a comment

Go to your repos


Click Pull Requests

Screen Shot 2016-12-07 at 12.07.28 PM.png

Click the type of PR you are looking for

Screen Shot 2016-12-07 at 12.07.42 PM.png

Then search

Screen Shot 2016-12-07 at 12.07.51 PM.png

How to git rebase and squash commits

Leave a comment

Find the SHA of the commit you want squash to

Commit: SHA1
Commit: SHA2
Commit: SHA3
git rebase -i SHA3
git rebase -i HEAD^^^

Cntl-v enter visual mode
Select text
c – to delete
Type what you want to appear
Press ‘Esc’ x2
Add a ‘p’ to bottom commit

Edit your file appropriately. Then save.

If you make a mistake

git rebase --abort

If you want to change a commit message

git commit --amend

Two squash two commits together:

git rebase --interactive HEAD~2

Dont reorder. Just take as is and change commit message when done.

Then force push your changes back to branch.

git push --force -n

How to interactive select and replace text in Vi

Leave a comment

Edit file

Screen Shot 2016-03-17 at 2.26.28 PM.png
Cntrl – V to enter Visual block mode

Select the text you want to replace

Screen Shot 2016-03-17 at 2.27.05 PM.png

Press c – to delete

Screen Shot 2016-03-17 at 2.27.36 PM.png
Type what you want to appear

Screen Shot 2016-03-17 at 2.28.02 PM.png
Press esc to see it all magically appear

Screen Shot 2016-03-17 at 2.28.25 PM.png

Altervativly can do a global replace in with with


The Computer History Museum

1 Comment

Yesterday I had the pleasure of adding a museum I have been looking forward to for some time. The Computer History museum in Mountain View California.

Screen Shot 2016-02-21 at 3.26.47 PM.png

This place was incredible. It has old IBM Mainframes, PDPs, Mini-Computers, ancient analytical machines. My old Apple 2. I day for someone how is into computer and history just isn’t enough.

You start off by seeing homepage being paid to Robert Noyce and the original group that kicked off what is considered the first start up in Silicon Valley – the traitorous 8 as they are called for leaving Fairchild Semiconductor (for those of you who don’t know Robert Noyce co-founded Intel years later with Gordon Moore and Andy Grove).

Screen Shot 2016-02-21 at 3.27.18 PM.png

You then proceed to a section that they have dedicated to the Google self driving car.

Screen Shot 2016-02-21 at 3.27.48 PM.png

The tech this car has is incredible, and I still can’t believe we are even talking about self driving cars. Still seems amazing to me.

Screen Shot 2016-02-21 at 3.28.00 PM.png

Then just casually sitting out in the open they have a 1976 Cray Supercomputer. These things were so fast and advanced that they cost $14M at the time to buy, took a year to manually assemble, and were in the shape of a cylinder because the length of the wires actually mattered for sending signals internally in the machine. Incredible story.

Screen Shot 2016-02-21 at 3.28.31 PM.png


They had a nice expose to Ada Lovelace and her contributions, along with the Babbage machine to computing.

Screen Shot 2016-02-21 at 3.28.54 PM.png

And then they had a great demo of one of the two working IBM 1401’s in the world and demonstrated how it sorted cards at lightning speeds.

Screen Shot 2016-02-21 at 3.29.25 PM.png

Then there were 14 more sections to the museum that I won’t go into great depth on this post. But needless to say, it’s amazing how much through, work, ingenuity has gone into this industry, much of it right around this very museum.

And needless to say, I has blown away by how far we have come, in such a short period of time.

They paid home a little to the computer gaming industry. Here were some of my favorites

Screen Shot 2016-02-21 at 3.30.15 PM.png

And who could forget the impact of space invaders.

Screen Shot 2016-02-21 at 3.30.27 PM.png

And of course my favorite machine of all time.


Screen Shot 2016-02-21 at 3.30.41 PM.png

Needless to say, this was an incredible, exhausting day. You wouldn’t believe how amazing people are / were when it comes to making these incredible machines to things.

It was inspiring, education, and just made you want to go out there and build something.

Thanks Dima (my friend from Belarus) for a wonderful day. I will definitely be coming back.

Here is a short video of one of the original MIT hackers who got music working on a PDP one back in the 60s. Yes he was actually there. Yes they found the music he created over 45 years ago. And yes it still plays. Amazing!














Lessons learned in TDD

Leave a comment

This was an excellent talk Ian Cooper gave at NDC a couple years ago.
It hits on a lot of the challenges and common problems Ian and others have seen with test suites and TDD in general.

It’s a great talk. Which you can watch in it’s entirety here.

Here are some notes.

The Problem

Screen Shot 2016-02-16 at 8.54.34 AM

Where did it all go wrong

Screen Shot 2016-02-16 at 8.54.40 AM

Two keep points
Not writing tests against behaviors.
Coupling our implementation details to our tests.

If we fix these we will have smaller test suites, much more self explaining, and much less painful to own.

There was advice in early TDD that said when you are given a new method on a class, that was the trigger point for writing a new test.

And that’s really wrong.

The trigger for writing a new test is to have some piece of behavior that I want to implement. The test needs to capture that behavior.

The reason why when you go back to your tests that you find them so hard to read is there is a lost connection between the low level test you are writing and the high-level feature you are trying to solve. It’s lost in the noise.

What you need to do is express in your test that we are testing a given behavior of our system.

Before you get to the point where you are going to put the implementation details down, you first put down the behaviours you are trying to capture, and then the implementation. Don’t jump ahead too early.

Testing outside in

Start with the use case, the story, the scenario or feature we want to solve, on the outside, then work your way in from there.

Recommendation: don’t start this at the UI level. Start one level beneath at the plain old object level. Then if your UI changes, it won’t matter. Focus on the domain models.

Test the public API of classes. Not the internals. Test the surface only, and it should be quite narrow.

As soon as you start testing the internals you are coupling your tests to your implementation details. To change your implementation details you now have to change your tests. And that’s the key problem.

So your surface area should be much narrowly than many people are testing today. Just the API.

That means you will write less tests, tests against the use cases, and refactoring the contract remains the same, the internals change, and you don’t break any tests.


This is what BDD is all about. Testing behavior, and not low level details, and methods on classes.

What is a unit test

Screen Shot 2016-02-16 at 8.54.48 AM

The simplest thing

Screen Shot 2016-02-16 at 8.54.55 AM

The real problem with TDD is Kent asked us to go green as fast as possible, committing as many sins as we want in that step. So go to project, cut and paste some code, and stick in application. Hack it. Make it work. Don’t worry about the design. Get it green ASAP.

Kent’s point here is that it’s difficult to do two things at once. Make the test pass and design at the same time. Better to separate out.

Green is about solving the problem. Refactoring is about doing the design.

Screen Shot 2016-02-16 at 8.55.00 AM

You do not write new tests here when refactoring. You already have the high-level behavior tests written. So long as those pass, you are OK. If you need another test, write it at that level.

But when you are refactoring, you are free to focus on design and engineer it right.

If you write tests here you bind your implementation details to your tests.

Coupling is the biggest problem in software. It is the enemy. Forget DRY. Coupling will kill you. Do you couple tests to implementation details.

Screen Shot 2016-02-16 at 8.55.06 AM

Dependency is the key problem in software development at all scales.

We need to eliminate the dependency between our tests and our code. Tests should not depend on details. Tests should depend on contracts or public interfaces. This allows us to change implementations without changes tests.

Test behaviors not implementations.

Means less tests.
Moving faster.
Going quickly to green.
Now you are refactoring and making it cleaner.
Better forward progress, the tests aren’t slowing you down so much.

Screen Shot 2016-02-16 at 8.55.13 AM

How to fork and clone a repos

Leave a comment

When contributing to an GHE project the first thing to do is to fork the main repository and then clone it to your machine.

This is normally known as a triangular workflow.

Screen Shot 2016-02-01 at 6.48.37 AM


  1. Navigate to the GHE page for the project that you want to contribute to (for instance and fork it.
    • Click on the “fork button” in the top right corner of the repo’s page.
    • Click on your account in the modal which appears.
    • You’ll then be taken to your fork.
  2. In the right column of the page you’ll find the git clone URL. Make sure to select the SSH URL.
  3. Clone your fork.
    • git clone git@xxx:$USER/yyy.git && cd xxx

  4. Add the main repository as your upstream remote
    • git remote add upstream git@xxx:yyy.git

  5. Disable pushes to upstream, to minimise the risk for mistakes:
    • git remote set-url --push upstream no_push

  6. Make sure git pushes to your fork by default.
    • git config remote.pushdefault origin

  7. Make sure git only pushes the current branch.
    • git config --global push.default simple

  8. Tell git and GHE who you are.
    • git config --global "Your Awesome Name"

    • git config --global "${USER}"

  9. Optionally (although highly recommended); set your master branch’s remote to upstream. This way you don’t need to manage to master branches, your fork’s is quite useless anyways. Making your life over 9000 times easier.
    • git fetch upstream

    • git branch --set-upstream-to=upstream/master master


Suggested workflow

This is our suggested workflow for day-to-day work, after having setup your fork (origin) of the main repository (upstream).

  1. First, make sure to base your changes on latest master:
    • git checkout master && git pull upstream master

  2. Make a topic branch for your change
    • git checkout -b my-fix

    • Note: you must to do this or bad things will happen.
  3. Do the changes and commit them. Keep the commits small and atomic; for instance, don’t do code style changes in the same commit as something that fixes a bug, and don’t do refactors and behavior changes in the same commit.
  4. Push the changes to your fork:
    git push -u origin my-fix

  5. Open a pull request (PR) from your topic branch to master in the main repo. Either via;
    • hub pull-request -b xxx:master


    • the GitHub web interface.
  6. Mention the relevant people or teams in the body of the pull request using the@username syntax (also works for teams, i.e. @the_org/team_name).
  7. It is OK to merge a PR once it has been reviewed and the reviewer has written a comment that clearly states that it is approved, for instance by writing “+2” or “Approved”.
  8. If merging a PR to upstream conflicts, merge master to your branch and update the PR:
    • git fetch upstream master && git merge upstream/master

  9. The person who created the PR is typically the one who is expected to merge it (and fix conflicts if necessary). Although an approved PR can be merged by anyone if needed.
  10. Once your topic branch has been merged into master go ahead and remove it in your own fork.
    • Either via the GHE pull request interface by clicking on “Delete Branch” or,
    • via the CLI: git branch -d my-fix && git push origin :my-fix


Older Entries

%d bloggers like this: