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

Screen Shot 2017-03-02 at 9.23.34 AM.png

If we want to squash all our work down to Story X, we need to go one beyond and grab the SHA from the one after the one we want to squash down to.

Screen Shot 2017-03-02 at 9.24.44 AM.png

Cntl-v enter visual mode
Select text
c – to delete
Type what you want to appear (s)
Press ‘Esc’ x2
Add a ‘p’ to top commit (reverse order)
Save (:wq)

Screen Shot 2017-03-02 at 9.28.19 AM.png

Screen Shot 2017-03-02 at 9.29.07 AM.png

Screen Shot 2017-03-02 at 9.29.27 AM.png

If you have a conflict, fix the conflict then…

git add .
git rebase --continue

If you make a mistake

git rebase --abort

If you want to change a commit message

git commit --amend

If you want to add another author to a commit

git commit --amend --author "peter+paul " -C HEAD
git commit --amend
git push -f

Squash specific number of commits together

Screen Shot 2017-04-10 at 9.30.54 AM.png

If you want to squash say x3 commits together to this

git rebase --interactive HEAD~3

And that will produce this

Screen Shot 2017-04-10 at 9.34.49 AM.png

So when you go ~3 it squashes three down into one. But doesn’t affect the one before it.

Rebase master

Then when ready to run master onto of your changes on your local branch.

git rebase master

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


How to add IntelliJ Google Style Guide to IntelliJ


For some reason intelliJ doesn’t let you import code style guides.
Like the Java one I wanted to use from Google.

To import the style guide (intellij-java-google-style.xml) after cloning the repository, to this.

> cd ~/Library/Preferences/IntelliJIdeaXX
> mkdir codestyles
> cp /intellij-java-google-style.xml .

Fire up intelliJ, goto preferences, search for Coding Style, and you should see Google Coding style there.

Screen Shot 2015-08-07 at 2.19.55 PM

Links that help

Classical vs Mockist testing


I’ve been looking for language to help articulate the difference between two styles of unit testing, and really like how Martin describes it in Mocks Aren’t Stubs.

Mocks use behaviour verification.
Classical uses state verification.


Classicist Mockist
Like working with real objects Prefer working with fake objects
State verification Behavior verification
Use mocks to test collaborations Use mocks all the time
Will hard code collaboration Will mock collaborations
TDD from middle out TDD from the outside in
Use ObjectMothers/Factories for test setup Will mock only what they need for test collaboration
Test tend to be more coarse grained – approaching more integration style tests Tests tend to be very fine grained – may miss integrations
Classists don’t couple tests to implementation Mockists do
Classists don’t like thinking about implementation when writing tests Mockists do
Don’t mind creating query methods to support testing Mockists typically don’t have to
Classists style can encourage Asking Not Telling design Mockists style encourages Tell Don’t Ask

Classical vs Mocking

I generally prefer the classical style to the mocking mostly because I don’t like thinking about implementation when writing a test.

I do however like having the mocking option in my back pocket, for those cases when a system is difficult to test, an object has a nasty setup, or I am refactoring legacy code.

The other piece of advice I recommend (my ex colleague Jonas Claesson turned me onto this) is to keep your calculations separate from your orchestrations.

If you can do this you get the best of both worlds. Calculations can be classically testing. Thin orchestrations mocked. Should keep both set easy to read, and easy to setup.

Here are some more summary notes from Martins article.

Article summary

Regular tests

  • state verification

Mock tests

  • behavior verification

Classical and Mockist Testing

  • Classical style uses real objects
  • Mocking style is to do everything with mocks
  • Classicists will use mocks for creating doubles

Choosing between the differences

  • If collaboration of objects is easy – classic is obvious choice
  • If collaboration between objects is awkward – mock
  • No big choice to be made here
  • Where things get more interesting is when we talk TDD

Driving TDD

  • Mockist will TDD there systems from the outside in
  • They will start with the GUI, describe their collaborations, and progressively marching deeper and deeper into the stack one layer at a time
  • Classical TDD doesn’t offer that kind of guidance
  • Whenever a classist requires something from a collaborator they simply hard code it
  • But classists take a slightly different approach – middle out
  • Here a classist will create an object for whatever domain they need and once they are working then you layer on the UI
  • Doing this you may never need to fake anything
  • Focuses the attention on the domain model, which helps keep the logic from leaking into the UI

Fixture Setup

  • Classic TDD needs to create SUT with all it’s collaborators
  • Mockists need only create SUT and mocks for immediate neighbours
  • Classics will do this using ObjectMothers – reuse whole objects
  • Mockists will say this is more work
  • Classists will say we do this once and reuse – you setup every time

Test Isolation

  • If you introduce a bug mocking, only those tests whose SUT contains the bug will fail
  • In classic, any tests of client objects also fail – ripple effect throughout system
  • Mocksts will say make finding bug harder to find
  • Classists say its usually pretty obvious – little bit more noise


  • Classic tests can be more coarse grained than mockists as they test overall interaction of objects
  • In essence classic xunit tests are not just unit tests, but also mini-integration tests
  • Classists like this
  • Mocksts lose that quality – also run the risk that the mocks are incorrect masking inherent errors
  • Which ever way you go you need both – coarse and fine grained

Coupling Tests to implementation

  • Mockists couple their tests to implementation
  • Classiss don’t care about implementation – only the final state – not how it was arrived
  • With mock testing, writing the test makes you think about the implementation behavior
  • Mocksist like this – classists dont
  • Coupling implementation also interfere with refactoring, since implementaiton changes are more likely to break tests than classic testing

Design style

  • Classist are more comfortable creating query methods to support testing
  • Mockists don’t have to do that as much
  • Mocking also encourages Tell Don’t Ask
  • Classis can encourage Asking Not Telling – though in practice this is easily hadnleld
  • Mocking can also result in more classes (interfaces in various languages)
  • May not be as true now, but i remember many more interfaces and classes being ccreated than was necseary when mocking
  • Also DHH dislikes the designs mocking sometimes creates – mockists like it

Classic or mockist?

  • I have never seen a reason to go all mock
  • Mockists focus solely on implementation details of the SUT – never felt nature to me


  • Don’t combine logic with orchestrations
  • Logic classis – classic mock
  • Orchestrations – simple as possible, no calcs, mockist

Links that help

How to create a new rails app with twitter bootstrap

1 Comment


I find myself doing this a lot lately. Here are some notes to help me do this quickly in the future.

Step 1: Create new rails application

> rails new myApp

Step 2: Install twitter bootstrap

This method installs bootstrap using the Less style sheets.

Add these gems following to your Gemfile

gem "therubyracer"
gem "less-rails" #Sprockets (what Rails 3.1 uses for its asset pipeline) supports LESS
gem "twitter-bootstrap-rails"

> bundle install
> rails generate bootstrap:install –no-coffeescript

Step 3: Add some scaffolding to test things out

> rails g scaffold Post title:string description:text
> rake db:migrate
> rails g bootstrap:themed Posts (optional)

Start your server and check your progress.

> rails s
> http://localhost:3000/posts


Step 4: Make use fluid layout


<div class="container-fluid">
  <%= yield %>


Step 5: Add some twitter bootstrap layout columns



<div class="container-fluid">
  <div class="row">
    <div class="span9"><%= yield %></div>
    <div class="span3">
      <h2>About Us</h2>
      <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>


Step 6: Add a navbar (inverse)



<div class="navbar navbar-inverse navbar-fixed-top">
  <div class="navbar-inner">
    <div class="container">
      <a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse">
        <span class="icon-bar"></span>
        <span class="icon-bar"></span>
        <span class="icon-bar"></span>
      <a class="brand" href="#">Some Store</a>
      <div class="nav-collapse">
        <ul class="nav">
          <li><%= link_to "Browse Posts", posts_path %></li>
          <li><%= link_to "Price List" %></li>
          <li><%= link_to "Contact Us" %></li>
          <li><%= link_to "Cart" %></li>

<div class="container-fluid">

Now, when you run this, notice how everything looks good when the collapsed navbar kicks in.


But when you expand the window to full screen the navbar overrides what appears at the top.


To account for this we need to add some padding to the twitter bootstrap non-responsive state. You can do this by adding this body padding between the two import lines below.


@import "twitter/bootstrap/bootstrap";
body { padding-top: 70px; }
@import "twitter/bootstrap/responsive";

Your page should now look like this:


Links that help:

How to install minecraft forge for mac


This was a frustrating process for me, but I finally got it.

Watch this video. It’s good and may give you everything you need.

If not (there were a few extra things I needed to do) read on.

1. Download minecraft forge.

Goto and download the ‘Installer’ for the most recent recommended version (1.6.4 at this time of writing).

To skip the adds, click the ‘*’ beside the word ‘Installer’ on the ‘1.6.4-Recommended’ and download the jar file (it will save to your downloads directory).



2. Save old profile.

The next thing we are going to do is save your current minecraft configuration, before blowing it all away with the new minecraft forge client.

Open up your ‘finder’ and click ‘Go to Folder…’


Then type in exactly exactly what you see below into the textfield and hit the ‘Go’ button.


This will take your to your minecraft application directory where your profile is stored (sorry, I forget to mention you will need to install minecraft on your Mac first before installing forge).

Once there drag and drop these files and folders to your desktop.



Then blow everything else away in the directory.

3. Create forge profile.

Now start your minecraft application. This is going to download the latest minecraft version.

Now here is where things differ from the video. If your minecraft client version (1.7.3), is different from the latest forge version (1.6.4), it’s not going to work (at least not yet).

We need to create a 1.6.4 profile (the same version as forge) and then things will work.

So if your latest client version differs from the forge version, create a new profile matching them up.

For example to to create a 1.6.4 profile, click ‘Profile Editor’ at the top of your login screen.
Then click ‘New Profile’.


Then file in the profile name (pick whatever you want, maybe put 1.6.4 in there so you know the version), and then select ‘release 1.6.4’ for the Use Version, and then ‘Save Profile’.


Now you have a compatible client that is going to work with your forge!

No you can go back to your login screen, select your new 1.6.4 profile, and login.


Click ‘Quit Game’ and shut down your minecraft launcher (Command-Q) or right click quit in your application toolbar.


4. Install forge client

Drop the files we dragged to the desktop earlier, back into the minecraft application folder we deleted everything from earlier.


Select ‘Apply to All’ and then ‘Replace’


Then double click your minecraft forge jar file that we downloaded at the start (downloads directory).


If you get this warning message


Open your ‘Finder’ and go to your ‘Downloads’ directory manually and ‘right-click’ on the jar file and select open


The click ‘Open’ to run the installer


Click install client, and make sure that the path in the install directory points to the directory where we stored all your profile stuff. It should look something like this:


We are almost there! Click ‘OK’.

You should then see a completion window that says ‘Successfully installed client profile …’

5. Create client forge profile.

Open up minecraft. In the profile areas, a profile option should now appear!


Select that. Click the ‘Play’ button. And congrats! You should be in.


You can tell your are running forge by the data in the bottom left hand corner.

6. Installing mods.

Forge mods go in the ‘mods’ folder in that directory we where looking at earlier where we did all our profile stuff.



This is where you put your forge mods.

That’s it for now! Happy forging!

Older Entries Newer Entries

%d bloggers like this: