Richie Khoo evolve2k

Subject

We can use an implicit subject, meaning we don't need to specify the subject (and we revert back to #it):

subject { Customer.new(:name => "Frank Reynolds") }  

it { should be_valid }

We can also use an implicit subject based on the object we are describing:

Don’t do it, a comment is a lie waiting to happen

If a comment is needed because the code is unclear, move it into it's own method with a nice name.
Write a unit test to explain things instead of using code comments.
Unit tests are executable, self verifying documentation.

It’s the universal ‘check here first’

Meditations

“As the tests get more specific, the code gets more generic.” [1] (http://cleancoder.posterous.com/the-transformation-priority-premise)
"Test code is just as important as production code" [1] (http://cleancoder.posterous.com/the-transformation-priority-premise)
"Do the simplist thing that could possibly work" (see What is Simple Code for guidance)

You are not allowed to write any production code unless it is to make a failing unit test pass.
You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

Write a failing test starting from the smallest simplist thing you have certainty about (inside out approach)
Get the test to report the failed state that you EXPECT.

	<!DOCTYPE html>
	<html>
	<head>
	<title>Sideways Example</title>
	<link href='stylesheets/global.css' media='all' rel='stylesheet' />
	</head>
	<body>
	<h2 class="rotate">Look Ma Im sideways</h2>
	</body>
	</html>

	1. Utilise a good programmer task management tool
	I strongly recommend you utilise pivitol tracker.
	Have the developer keep the tasks they are working on up to date and ask them to communicate with you through pivitol tracker.

	2. Have the developer keep their source code in an online repository that you both have access to all the time.
	I strongly recommend that the code is kept at github.com in a private repository that you maintain.
	(It will costs you aprx $9 per month to do so).
	Have the developer tag each batch of code they work on with the specific task(story) they are working on at the time.

	3. Ensure your developer writes tests.

	<date>

	<Previous Developers’s Name>
	<Previous Developers’s Position>
	<Company Name>

	Dear <Previous Developers Name>

	Ethical Clearance Letter
	Re: <Name of client>

	$ git reflog

	5ee192a HEAD@{0}: checkout: moving from master to 5ee192a62f39323c61a3b2527bbda1b6fbd669c8
	63322f5 HEAD@{1}: merge suite_spike_1: Fast-forward
	58c63d4 HEAD@{2}: checkout: moving from suite_spike_1 to master
	63322f5 HEAD@{3}: merge master: Merge made by the 'ours' strategy.
	713e4ae HEAD@{4}: commit: Update ProductSuite with website, discount text and omnium code
	ef7eb28 HEAD@{5}: checkout: moving from master to suite_spike_1
	58c63d4 HEAD@{6}: checkout: moving from suite_spike_1 to master
	(copy the head part for the commit I want to restore to)

	Steps to get postgres working on OSX (as I currently understand it)

	1. Install Postgres
	- A bunch of files are placed in uknown places?
	- A service starts running which is the database service
	- An initial conf file and conf database file are created?

	It's not working, steps to find out what exactly is not working.
	Eg which level the problem is at

	1. Add versions to all the gems in the Gemfile.
	(This app may be picked up again months or years later, its terrible to try to compile it when the versions aren't present.)
	2. Update the README
	3. Ensure the test suite is passing.
	4. Add a 'handover' note in the README which outlines the state of the specs and the pointy bits of the project and in non-political terms where things are at.