Tuesday, April 26, 2011

Dell Vostro 3350

Memory 8GB US$94:

Lenovo Edge

GoComp $699:


Remap keys


Thursday, April 7, 2011

Agile Principles & Practices

Principles behind the Agile Manifesto

  • 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.


Unit Testing Tips and Tricks

Types of objects used in Unit Testing (from http://martinfowler.com/articles/mocksArentStubs.html):
Type Code Syntax
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
  • 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

"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


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:


Some lessons you can probably only learn by trying it first and seeing what works in your environment:

Ron Jeffries


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:


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)

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

Fast Builds


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


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

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

Prefer Stateless over Stateful

Coding Best Practices (how to code)

Avoid duplication

DRY: Don't Repeat Yourself

Use It or Lose It

YAGNI: You Ain't Gonna Need It

Insert Fixes As You Go

// 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


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.