Dan Pink: Team motivation

http://blog.agilegamedevelopment.com/2011/03/team-motivation.html

1. Money does not incentivise better work (except in monkey work).
2. If-then rewards often destroy productivity
3. The secret to high-performance is unseen intrinsic drive to do things because they matter
4. We already know this, the science confirms this, business ignores it

Building blocks for a new way of working:
Autonomy - The urge to direct our own lives
Mastery - The desire to get better at something that matters
Purpose - The yearning to do what we do in service of something larger than ourselves
Intinsic motivation

ROWE - Results Oriented Work Environment
No schedules - show up when you want
Just have to get their work done.  How, when, where up to them.

Haskell Syntax

(.) Function Composition

(.) :: (b -> c) -> (a -> b) -> a -> c

negate . (* 3)  returns a function that takes a number, multiplies it by 3 and then negates it

:t negate . (* 3)
negate . (* 3) :: Num c => c -> c

> let neg = negate . (* 3)

> neg 4

-12

($) Application Operator - This operator is redundant, since ordinary application (f x) means the same as (f $ x). However, $ has low, right-associative binding precedence, so it sometimes allows parentheses to be omitted;
($) :: (a -> b) -> a -> b


Monad functions
(>>=) Bind

(>>=) :: forall a b. m a -> (a -> m b) -> m bSource

Sequentially compose two actions, passing any value produced by the first as an argument to the second.

(>>) Then

(>>) :: forall a b. m a -> m b -> m bSource

Sequentially compose two actions, discarding any value produced by the first, like sequencing operators (such as the semicolon) in imperative languages.

return :: a -> m aSource

Inject a value into the monadic type.

fail :: String -> m aSource

Fail with a message. This operation is not part of the mathematical definition of a monad, but is invoked on pattern-match failure in a do expression.

(<-)

read - is sort of the opposite typeclass of Show. The read function takes a string and returns a type which is a member of Read.
read :: (Read a) => String -> a
If type can not be inferred, can use a type annotation:
let x = read "5" :: Int
 ::
Type annotations are a way of explicitly saying what the type of an expression should be. We do that by adding :: at the end of the expression and then specifying a type.
(since Haskell is a statically typed language, it has to know all the types before the code is compiled (or in the case of GHCI, evaluated).)

Enum, succ, pred 
ghci> ['a'..'e']    
"abcde" 
ghci> succ 5
6

Bounded, minBound, maxBound
ghci> minBound :: Int
-2147483648

Num, Integral, Floating

fromIntegral :: (Integral a, Num b) => a -> b


data = typeclass
deriving = make type instance of typeclass
type = type synonym - doesn't make anything new just a synonym for existing type
class =
instance =

Lambda = closure
Basically anonymous functions that are used because we need some functions only once
We write \ because it looks like greek letter lambda) and then parameters separated by spaces, then -> then the function body.

Lambdas vs implicit currying (and partial application)
Both (+3) and (\x -> x + 3) are functions that take a number and add 3 to it
These two are the same:
addThree x y z = x + y + z
addThree = \x -> \y -> \z -> x + y + z
and:
flip' f = \x y -> f y x
flip' f x y = f y x

(:) cons
Put something at the beginning of a list

foldl applies a binary function to a list from the left starting with an accumulator value and the left-most value of the list
foldr applies a binary function to a list from the right starting with an accumulator value and the right-most value of the list
 (the ++ function is much more expensive than : so we usually use right folds when we're building up new lists from a list.)
The foldl1 and foldr1 functions work much like foldl and foldr, only you don't need to provide them with an explicit starting value. They assume the first (or last) element of the list to be the starting value and then start the fold with the element next to it
sum = foldl1 (+)

The following are the same:
foldl (flip (:)) [] (words "hello world")
foldl (\acc x -> x : acc) [] (words "hello world")


scanl and scanr are like foldl and foldr except they show all the intermediate values in a list

Prelude> scanl (+) 0 [1,2,3,4]
[0,1,3,6,10]
Prelude> scanr (+) 0 [1,2,3,4]
[10,9,7,4,0]

Microsoft Buys Skype

Ben Horowitz: Microsoft Buys Skype

Data, Context and Interaction

http://debasishg.blogspot.com/2010/02/scala-self-type-annotations-for.html

http://www.infoq.com/news/2009/05/dci-coplien-reenskau

Windows 7 Tweaks and Tips

Ultimate Windows Tweaker
http://lifehacker.com/5532578/the-power-users-guide-to-the-windows-7-taskbar
http://lifehacker.com/5364198/master-windows-7-jump-lists-to-boost-your-win7-productivity

Network Activity Indicator: http://www.itsamples.com/network-activity-indicator.html

Dell Vostro 3350

Memory 8GB US$94:
http://www.crucial.com/store/mpartspecs.aspx?mtbpoid=50D925F3A5CA7304

Lenovo Edge

GoComp $699:
http://www.staticice.com.au/cgi-bin/redirect.cgi?name=Gocomp&linkid=2&newurl=http%3A%2F%2Fgocomp.com.au%2Findex.php%3Fcpath%3Dproduct%26catpath%3D0_3_44&query=lenovo%20edge%2014%20i5&uca=600-0-0&kwi=&rpos=2

Memory:
http://www.amazon.com/dp/B001MX5YWI/ref=asc_df_B001MX5YWI1521469?smid=A13BNE3P7C8THK&tag=nextagusmp0350122-20&linkCode=asn&creative=395105&creativeASIN=B001MX5YWI

Remap keys

http://vlaurie.com/computers2/Articles/remap-keyboard.htm

Agile Principles & Practices

Principles behind the Agile Manifesto

http://www.agilemanifesto.org/principles.html

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity - the art of maximizing the amount of work not done - is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Practices

• Identify Technical Debt: http://martinfowler.com/bliki/TechnicalDebt.html
• Avoid Duplication: Don't Repeat Yourself , Once And Only Once
• Follow the team's Proposed Coding Conventions
• Add FIXME breadcrumbs as you go

Unit Testing Tips and Tricks

Types of objects used in Unit Testing (from http://martinfowler.com/articles/mocksArentStubs.html):

Type	Code Syntax	Description
Dummy	dummyOperator	Dummy objects are passed around but never actually used (e.g. no methods are called on it). Usually they are just used to fill parameter list.
Stubs	stubOperator	Provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.
Mocks	mockOperator	Mock objects are pre-programmed with expectations which form a specification of the calls they are expected to receive.

Why using Mock Controls is better than Mock Objects
http://www.michaelminella.com/testing/mock-controls-with-easymock.html

• Using a strict mock control (mock controls have they same three types as mock objects: regular, nice and strict) to create our mock objects means EasyMock will not only verify that the methods we record were executed, but in the correct order across objects.
• Instead of having to specify all the mock objects to replay and verify, our mock control kept track of what was recorded where so all we have to do is tell it to replay and verify.

Pair Programming

http://www.extremeprogramming.org/rules/pair.html
"All code to be sent into production is created by two people working together at a single computer. Pair programming increases software quality without impacting time to deliver. It is counter intuitive, but 2 people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality. With increased quality comes big savings later in the project"
...
"Don't expect people to be good at it from the start. It helps if you have someone on your team with experience to show everyone what it should feel like."

Move People Around

http://www.extremeprogramming.org/rules/movepeople.html

Rules (guidelines)

Some fun pairing rules (guidelines) you can print out and stick on a wall maybe once people have tried pairing for a few weeks:
http://www.extremeprogramming.org/stories/pair.html

Lessons

Some lessons you can probably only learn by trying it first and seeing what works in your environment:
http://www.extremeprogramming.org/stories/pair2.html

Ron Jeffries

http://www.xprogramming.com/Practices/PracPairs.html

Coding Conventions

This is a page to collect our "best practices" for developing agile code (i.e. code that is testable, maintainable, understandable, etc).  It is a work in progress, add to it as you go.  If you don't understand something or disagree, speak up, ask questions, or rewrite it.
Josh Bloch himself suggests we don't look to Sun for conventions ("I wouldn't take that document too seriously. It is not actively maintained or used at Sun.")
For example of others' "best practices" have a look at:

• http://docs.codehaus.org/display/PICO/Good+Citizen
• http://www.assembla.com/wiki/show/burro/Development_Principles
• http://www.ivanism.com/Articles/AgileXPSoftwareDevelopmen.html
• http://www.architech.ca/2010/03/agile-development-9-rules-to-live-by/

Build/Integration

Build Before Committing

If it doesn't work on your PC it will break the build.

Consistent Dev Env

Fixing a broken build is always highest priority

Commit Often (and rollback often)

• Commit Often: http://www.codinghorror.com/blog/2008/08/check-in-early-check-in-often.html
• Don't Go Dark: http://www.codinghorror.com/blog/2008/06/dont-go-dark.html
• Revert often: http://stackoverflow.com/questions/1286057/continuous-builds-and-agile-vs-commit-often/1286126#1286126

If In Doubt, Spike It Out (on a branch)

Fast Builds

Testing

Prefer Molecular over Atomic Tests

No Prod Code Just for Tests

• Code needs to be testable but not exist solely for testing

Shared Code Ownership

All Prod Code is Paired (or reviewed)

See Pair Programming

No Individual Code Ownership

The team owns the code.  See http://www.xprogramming.com/Practices/PracOwnership.html

Changing the following is a team decision:

• Reducing Coverage
• Changing Checkstyle Rules
• Upgrading/Adding Dependencies (libraries/plugins)

Coding Standards (what to code)

Why the need for common coding standards?  See http://www.xprogramming.com/Practices/PracCodingStandards.html

Follow Naming Standards

• For tests use dummy*, stub*, and mock*, see Unit Testing Tips and Tricks
• Concrete classes are named with interface name + "Impl" suffix. Don't prefix interfaces with "I".
  • e.g. Use Thingy + ThingyImpl instead of IThingy + Thingy
• Use the following suffixes for tests:
  • *UnitTest - for testing one or more units while mocking out other systems/components
  • *IntegrationTest - for testing integration with other systems/components
  • *SmokeTest - for quick happy path tests
  • *FunctionalTest - for end-to-end test that prove user requirements

Avoid Nulls

See:

• http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake
• http://andyp-tw.blogspot.com/2008/08/returning-null-considered-dishonest.html
• http://en.wikipedia.org/wiki/Null_object
• http://martinfowler.com/eaaCatalog/specialCase.html
• Chapter 7: "Error Handling" of Clean Code

Avoid Inheritance of Implementation (i.e. avoid "abstract" classes)

Prefer Delegation over Inheritance.
See Why Extends is Evil

Avoid Static Methods

Static methods are not testable
http://codeliability.blogspot.com/2007/07/statics-are-evil.html

Avoid Inner Classes

Inner classes generally reduce readability, though in some cases they may increase readability.  Use them sparingly.

Keep Classes and Methods Small

Use Outlandish Class Names

Avoid "new"

• introduces tight coupling
• without an injection framework, try to limit the use of "new" in prod code to field declarations so that tests can inject mocks/dummies/stubs.

Prefer Unchecked (Runtime) Exceptions over Checked

Think carefully whether you need a checked exception.
See Chapter 7: "Error Handling" of Clean Code

Isolate 3rd Party code behind Boundaries

See Chapter 8: "Boundaries" of Clean Code

Avoid having Packages and Classes in same folder

Prefer Immutable over Mutable

• See Why getter and setter methods are evil
• and More on getters and setters

Prefer Stateless over Stateful

Coding Best Practices (how to code)

Avoid duplication

DRY: Don't Repeat Yourself
http://en.wikipedia.org/wiki/Don%27t_repeat_yourselfhttp://c2.com/cgi/wiki?DontRepeatYourself
http://www.redhillconsulting.com.au/products/simian/
http://pmd.sourceforge.net/cpd.html

Use It or Lose It

YAGNI: You Ain't Gonna Need It
http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it
http://www.xprogramming.com/Practices/PracNotNeed.html
http://c2.com/xp/YouArentGonnaNeedIt.html

Insert Fixes As You Go

Use

// FIXME :

comments throughout code as a breadcrumb reminder to fix something before you sign off the card/task

Avoid java.util.Date and Calendar

"The JDK classes Date and Calendar are very badly designed, have had numerous bugs and have odd performance effects"

Maintain field ordering

In order:

• Public constants (public static final)
• Private constnats (private static final)
• Public fields (these should not exist at all)
• Private fields

Maintain method ordering

Public methods first.

Coding Philosophies (how to think about code)

Code is a Liability

Groovy style for Java developers

http://groovy.codehaus.org/Groovy+style+and+language+feature+guidelines+for+Java+developers

Optional typing advice

• Groovy lets you decide whether you use explicit strong typing, or when you use 'def'.
• Whenever the code you're writing is going to be used by others as a public API, you should always favor the use of strong typing, it:
• helps making the contract stronger, 
• avoids possible passed arguments type mistakes, 
• gives better documentation, 
• helps the IDE with code completion
• Whenever the code is for your use only, like private methods, or when the IDE can easily infer the type, then you're more free to decide when to type or not.

langref

www.langref.org

Comparing Languages

Language Comparison

http://news.ycombinator.com/item?id=2414035

Types Comparison Chart

http://james-iry.blogspot.com/2010/05/types-la-chart.html