Eric Juta

Lead Software Engineer - Arcadia Group

Read this first

Test Driven Development in Ruby tuts+ course - Stubs and Mocks notes

 Stubbing - A technique used in TDD/BDD allowing you to simulate using third party dependencies for your own code.



Example, retrieving data from a database, you pass a “splat” = dummy data to a stub.
We have no control over what our data model is; as an example for the usage of stubbing.


pass a stub to a list for fake data

before { competition.stub(:questions => [stub] ) }


 Mocking - A technique used to allow you to assert messages; specifically method calls without actually implementing any code for that method.



Example, a competition class should be able to receive and react to a competition.close method once it has started. However we may assume that the close method logic is not going to be written or implemented by us truly. In real life situations, simulate API calls and pretend that we have data received from such a third party method call.

context:“when started” do

it

Continue reading →


Rspec example

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

Continue reading →


Cucumber BDD notes

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

Continue reading →


The Pragmatic Programmer notes

  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

Continue reading →


Notes from The Developer’s Code book

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

Continue reading →


Thoughtbot trail - Unix

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

Continue reading →


Writing Code for Humans course notes part 2 - Naming

 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.

Continue reading →


Pluralsight - Clean Code: Writing Code for Humans course notes part 1

 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

Continue reading →