Matt Callanan's Blog: April 2011

Tuesday, April 26, 2011

Thursday, April 7, 2011

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.

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:

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:

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

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_yourself http://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.

Wednesday, April 6, 2011

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

High Performance Web Applications In Haskell

http://qconlondon.com/dl/qcon-london-2011/slides/GregoryCollins_HighPerformanceWebApplicationsInHaskell.pdf