• take responsibility
• know your field
• collaborate
• mentoring
• learn to say no
• managing your time
• estimations

• QA should find nothing
• Aim for tests to have 90%+ code coverage
• Ensure software is easily changeable (S.O.L.I.D)

• Design Patterns (Gang of Four's 24 patterns)
• Design Principles (S.O.L.I.D, DRY)
• Methodologies (Agile, Scrum, Kanban, Waterfall)
• Disciplines (TDD, BDD & a million other things)
• Artifacts (UML)

• Share knowledge between teams
• Promotes alternative solutions
• Potentially fewer errors

• Quickly realise holes in your understanding
• Long forgotten reasons why to ignore
  certain techniques
• Look after juniors. Give direction

• Don't compromise quality or stability
• Don't agree to 'try'
• When saying 'no', offer compromises
• Help educate management

• Only go to meetings that actually need you
  
  
• Leave a meeting if it becomes a waste of your time
  
  
• Discussions that last longer than 5mins requires data
  
  
• Avoid 'blind alleys' & 'messes' - they're a time black hole
  
• Keep stand-ups short and focused! (yesterday, today, blockers)

• Don't estimate a job by yourself
  
  
• Team members recognise different
  problem areas
  
  
• Break tasks up into smaller sub tasks
  and estimate each individual task.
  Total time will likely end up greater.

• Clear and concise architecture
• Up-front design decisions
• Less errors and more efficiency
• Clarity for new team members

---------------           ---------------
|  ClassName  |           |  ClassName  |---------------           ---------------
|  Properties | --------> |  Properties |---------------           ---------------
|   Methods   |           |   Methods   |---------------           ---------------

• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

• Objects (methods too) should
  have one responsibility (promotes testability)
  
  
• Objects gain
  'high cohesion' (better method relation)

• Signature must match parent
• what to accept must be the same or weaker
• what to expect must be the same or stronger
• Exceptions thrown must match parent

• avoid generic interfaces
• specific interfaces increases cohesion
• avoids side-effects caused by changes

• components should depend upon
  abstractions instead of implementations
  
  
• relies on interfaces and polymorphism
  (similar to Open/Closed principle)
  
  
• inject dependencies and
  use injection containers**

• aka Pimple (see also this blog post)
  
  
• dependencies are clearly defined
  in one place
  
  
• objects don't have to worry about
  dependencies of the objects they use

• over engineered!
  
• need to keep things simple
• use Sass but don't abuse it

 @if $core or $tablet

• Undoing styles (reverses purpose of cascade)
• Magic numbers  (they just work?)
• Qualified selectors  (div.blah)
• Generic selectors (div)
• line-height units (trick question: no unit!)
• Brute forcing styles ()
• IDs
• Generic class names (.card or .credit-card ?)

• write 'plain vanilla' where possible
• follow the GUTS guidelines
• don't re-wrap jQuery objects in jQuery
• dont wrap elements in jQuery unnecessarily
  
• recognise other jQuery smells (see GUTS)
• be wary of overuse...
  
  

 $(this).attr('id') => this.id

• Proxy
• Strategy
• Decorator
• Factory
• Composite
• Command

• place object in-between user 
  and requested object
• many different types of proxies:
  'protection' (controls access)
  'remote' (cross domain data transfer)
  'virtual' (performance)

• Mix of composition and delegation
• 'context' gets passed multiple 'strategies'
• 'context' delegates to appropriate 'strategy'

• Alter functionality of existing object
• Leaving existing object un-modified
• Different to a Facade in that the API
  doesn't change (i.e. Facade creates new API)

• Provides simple interface to
  create new object instances
  
• Allows easy change between
  objects from within the Factory
  (e.g. changing from object X to Y)

The Composite Pattern describes a group of objects that can be treated in the same way as a single instance of an object may be.

• Component class (a task's base class)
• Composite class (container of sub tasks)
• Leaf class(es) (individual tasks)
  
  

• Scenarios should be concise and focused
• Avoid writing too many steps
• Step Definitions shouldn't hold application code
• Utilise Helpers to keep code maintainable
• Scenario Outlines should be 'representative'
  note 'exhaustive' (you may other wise be
  testing code better suited for unit tests)

• Should run fast
• Should be run frequently

• Tests should not depend on other tests
• Should be able to run tests isolated
• Avoid leaky application state

• Tests should be able to run in any environment
• This means without an internet connection
• Tests should be reliable

• Tests should provide clear feedback
• You shouldn't have to read a log file to find out
  why the test failed
• This will avoid long manual evaluation

• Tests should be written first (TDD)
• TDD avoids difficult to test code
• TDD avoids poorly designed code

• Jasmine is a BDD unit-testing framework
• Much more expressive (and stable) than QUnit
• Standard features such as setUp/tearDowns
• Can write your own matchers
• No native AMD support though :-(

// Test Suite (i.e. group of related tests)describe('Acme widget', function(){    // Spec (i.e. individual test)    it('should ...do something', function(){        // Matcher (i.e. assertion API)        expect(true).toBeTruthy();    });});

expect(x).toBe(y);
expect(x).toBeDefined();
expect(x).toBeTruthy();
expect(x).toContain(y)
expect(x).toBeLessThan(y);

...many more...

expect(x).not.toBe(y);
expect(x).not.toBeDefined();
expect(x).not.toBeTruthy();
expect(x).not.toContain(y)
expect(x).not.toBeLessThan(y);

• Spies, Stubs, Mocks
• Fake Timers
• Fake XHR
• Jasmine adapter

• Track application use of methods
• Call count
• Arguments passed
• Execution order with other Spies
• Exceptions thrown
• Return values

• Pre-programmed methods
• Canned return values
• Are just 'fillers' 
• Don't "directly" cause test to fail
• Actual object under test gets the 
  data it needs to be tested
• Sinon.js Stub implementation 
  inherits Spy functionality

• Similar to Stubs in that they
  have pre-programmed responses
• Mocks have expectations of what 
  methods should be called on them
• If expectations aren't met then test will fail
• Sinon.js Stub implementation inherits
  Spy functionality

• Overwrites global setTimeout/setInterval
• Makes them synchronous
• Allows you to flattern timer with `tick()`

function doSomething(x){ console.log(x); }
window.setTimeout(doSomething, 1000, 'xyz');
this.clock = sinon.useFakeTimers();this.clock.tick(1000); // trigger code that would've run after 1 sec
this.clock.restore();

• Overwrites global XMLHttpRequest (i.e. AJAX)
• Makes them synchronous
• Provides both fake XHR API and a high-level
  fake server for multiple XHR requests

this.server = sinon.fakeServer.create();this.server.respondWith('POST', '/success.json', [200, {}, JSON.stringify({reply: 'success', body: 'test'})]);
this.server.restore();

// instead of...expect(spy.calledWith('foo')).toBeTruthy();

// you can use...expect(spy).toHaveBeenCalledWith('foo');

expect(spy).toHaveBeenCalled()expect(spy).toHaveBeenCalledWith()expect(spy).toHaveBeenCalledOnce()
expect(spy).toHaveBeenCalledTwice()expect(spy).toHaveReturned()
...and more...