describe “An instance of”,‘Cart’ do

before :each do
@cart = Cart.new
end

it “should be properly initialized” do
expect(@cart).to be_a(Cart)
end

context “when new” do
it “contains no items” do
expect(@cart).to be_empty
end
it “has a value of 0” do
expect(@cart.total_value).to be(0)
end
end

context “when a new item is added” do
before do
@cart.items[‘new item’] = “Jonny”
end
it “should no longer be empty” do
expect(@cart.items).not_to be_empty
end
end

Feature to be added

-> Optional Text:
-As a
-I want to
-So that

Feature:Brush teeth

As a human being,

I want to brush my teeth

So that they stay pain free

Scenario: Expected outcome title


Steps within scenario

Given: Sets up initial state

When: Perform action(s)

Then: Check end state

(Optional) And/But: after any Given,When,Then sentence

@Tags: Before step definitions

1. Feature supersets,
2. important
3. slow/fast
4. w.i.p
5. weekly,daily,hourly
6. humanexecuted

Data tables in steps; alternative to multiple ‘And’ steps

Colon at end of a step : Each list item inbetween vertical lines |‘s

Given I have the following tools:

| paste |

| brush |

| water |

Scenario Outlines: parse arguments from a list to the same scenario

Variables inside given,when,then steps surrounded by ’< >‘ marks then a list in a column format with the variable header at the top; vertical lines |’s whole...

1. The cat ate my source code. It’s your responsibility to come up with solutions, not excuses. Sure there’s many things to be taken into account but regardless, JFDI.

2. Broken window theory. Momentum of bad code fucks shit up. Be on top of shit. Patch it up even with a W.I.P sign.

3. Stone soup and boiled frogs. Being a catalyst of change, provoke additional features by going first and showing future promise. Yet, be careful as like a frog in boiling water, they won’t know the progressive deterioration of personal resources.

4. Good-Enough software. The scope and quality of the system you produce should be specified as part of that system’s requirements.

5. Your knowledge portfolio. Very similar to managing a financial one. The fundamentals are:

6. Learn at least one new language each year.

7. Read one technical book each quarter.

8. Read non-technical books too.

9. Take classes.

10. Participate in local user...

Start from the most interesting task first. We’re allowed to do that as developers, a more realistic timeline can be established once we have practical experience in doing. Only then will we know how much time is accurately required to finish off the remaining tasks.

As Parkinson’s law states, “Work expands so as to fill the
time available for its completion.” When I was able to be “at
work” any hour of the day, there was a whole lot of time to
fill up. Suddenly, my 40-hour work week turned into a 168-
hour mush of work, sleep, and kinda-being-around-work.
Working from home is a luxury. Most people would trade
a two-hour commute for a fall-out-of-bed commute. But if
you have that luxury, don’t code in your bedroom. Or your
living room, for that matter. Find a confined area to work,
preferably a second room, where you can physically leave
from after your workday is over. Shut the door...

You can use these commands and operators:
** |, <, >, >>, &, ack, awk, cat, chmod, chown, cp, export, find, kill, locate, ls, mkdir, mv, ps, rm, sed, sort, tail, top, vim, whereis, xargs.**

Found an awesome index resource!
http://www.westwind.com/reference/os-x/commandline/pipes.html
http://www.ee.surrey.ac.uk/Teaching/Unix/
http://cs.brown.edu/courses/bridge/1998/res/UnixGuide.html

Piping : | direct the input of one command into the input of another
< Take the input from a file into a command

Take the output of a command into a file

“>>” Take the output of a command and append (add it) to the end of a file.
& Added at the end of a command to run the command in the background
ack : Better than grep; advanced search http://www.youtube.com/watch?v=sKmyl5D8Da8
AWK : A unix shell scripting language to manipulate the streamed row and column data output given within the terminal
http://ww...

Naming matters

Classes

“Is the class doing too much?

1. It should be a noun
2. It should be specific
3. It should have a single responsibility
4. Does having an instance of that class name make sense?

Methods

"What does this logic attempt to accomplish?”

Just have them own a self explanatory description

Rubber Ducking

That eureka moment by talking to yourself.


Rhetorical questions out loud provoke the subconscious.

Resources

Code Complete 2
Clean Code
The Pragmatic Programmer

Conventions

1. Comparisons vs Snippets
2. Verbalize Code. Literal reading code

Three Principles for Clean Code

1) Right tool for the job: Less logic code required

Learn multiple paradigms for each unique problem.
Don’t be proud of hackery.
Understand the boundaries for the purpose of each language and framework.

Difference between styling, semantic markup ,logic and data storage.
By staying native, code becomes cached and loaded once.
The syntax colour highlighting within an IDE.
Project structure modularisation with files making code reusable as in a framework.
Build tools return no compilation, minifaction and catification errors.

2) High signal to noise ratio : Understanding the intent straight away.

TED Rule.
Terse - Non-wordy
Expressive - Intent
Do one thing
Don’t repeat...