20 top programming lessons

Mycket läsvärd kort artikel om 20 regler angående programmering

http://www.dcs-media.com/Archive/20-20-top-20-programming-lessons-ive-learned-in-20-years-FH

Öredev Torsdag

x Driven Design

Rebecca Wirfs-Brock talked about the various -DD:s out there. Coming from Smalltalk she's been writing several books on object orientation design, RDD being her baby.

RDD - Responsability Driven Design

• Roles
• Responsability
• Collaborations

informed tools and techniques

localize responsability

CRC - Candidate Responsabilities Collaborations

FDD - Feature Driven Design

Feature lists --> Feature by feature:

1. Domain walktrough
2. Design
3. Design inspect
4. Code
5. Code inspect

Design first week, code second.

TDD - Test Driven Development

1. Write simplest test
2. Run test and fail
3. Write simplest code that will pass
4. Run the test and pass

"Design between the keystrokes"

BDD - Behavioural Driven Development

Given context

When event occurs

Then outcome

DDD - Domain Driven Design

CDD - Contract Driven Development

Making the sausage

Intresting walkthrough on the work of BDD-framework in Clojure. BDD and Clojure is interesting in itself, but also interesting how they worked out their ideas.

NoSQL

ACID doesn't scale out. Problems:

• Data size
• Connectivity
• Semi structure (modeling and sparse data)

4 types of new types

• Key value
• Big table
• Document
• GraphDB

DYNAMO-paper by amazon very influential.

BASE

• Basically Available
• Soft state
• Eventually consistent

Examples:

• Voldemort - key-value store
• Cassandra - BigTable
• Google Bigtable
• Apache Hadoop HBase - Bigtable
• Couch DB - Document (REST)
• Mongo DB - Document
• RIAK - Document (REST with DYNAMO scaleout)
• Neo4j - Graph
• Allegiograph - Graph

The Productive programmer: Mechanics

Kul session om hur man blir effektivare på det personliga planet. NealFord.com.
[slides]

Acceleration

clcl Clipboard enhancement

mousefeed Eclipse-plugin to help learn keyboard shortcuts

Focus

Flow takes 20-30 minutes to reestablish.

TweakUI To turn off windows balloon tips

jedi concentrate Screen dimmer

Turn off notifications like email, phone, etc

Office "quiet time" for example 9-11, 13-15.

Google desktop to find things efficiently, plugin for indexing any filetype.

Out of the frying pan into the fire

Fun scrum-lover sharing real life anectodes.

Öredev Onsdag

Accomplishing more by doing less

Alltid kul med mjuka inslag, det är en av anledningarna att jag gillar Öredev. Började med några övningar: Tyst minut och 2 minuter att svara på tre frågor medans grannen tyst skulle lyssna: Vad skulle du vilja undvika att göra på jobbet? Hur kan du åstadkomma det? Körde övningen med en cool äldre kille från Oslo som visade sig vara Trygve Reenskaug.

Ytterligare frågor: Vad vill du åstadkomma här på jorden? Hur kan du åstadkomma det?

JSF and Seam-notes

Seam and JavaServer Faces(JSF)

MVC-framework used: MyFaces (An implementation of JSF)

Struts, Tapestry, etc all evolved from shortcomings of JSP.
JSF evolved from shortcomings of Servlet.

Other MVC:s
Tapestry - Pages are iPage, not POJO
Spring MVC - not as robust as the other 2
Struts - 1.x popular, but 2.x not widely used
Is seam now widely used?

JSF is a JSR-standard part of JCP

Seam is the glue that gets rid of a lot of xml and backing beans, which makes development faster, code less, maintenance easier.
In effect, the presentation tier talks directly to the business tier.

Sample code from the JBOSS Seam book can be found at http://www.integrallis.com

For components that are missing in MyFaces, like date and calendar, check tomahawk at http://myfaces.apache.org/dowload.html

xml-files

• web.xml is the standard web deployment descriptor for any Java EE web container. More on page 53.
• faces-config.xml is the JSF-specific configuration file. Parsed by the StartupServletContextListener specified in web.xml. Specifies backing beans, navigation rules, customized components and renderers used for those components.
  
• components.xml
  

Konferenser

• Jfokus, http://www.jfokus.se/jfokus/, 27-28 Januari 2009
• SDC, http://www.scandevconf.se/, 24 Mars 2009, 3000:-/pers
• JavaZone, http://jz09.java.no/, 9-10 September 2009
• JAOO, http://www.jaoo.dk/, Aarhus, 4-9 Oktober 2009
• Øredev, http://www.oredev.org/, Malmö, November 2009

Churn in the backlog - what to put in the backlog

From a thread in [leanagilescrum]:

Everything that you KNOW (or are reasonably certain of) about the future can be in the backlog. It gets to be waste when you put in the backlog stuff that has a high likelihood of changing. So the trick is to put in all of those things in the future that are going to happen – trade show, product launch, etc. And put in what you know for sure about what the software will have to do by those deadlines. What I’m proposing that you avoid wishful thinking and guessing in the backlog – only put in what is reasonably unlikely to change.

If you measure the churn (change to backlog items from the time they are entered until the product goes into production), I would say that 10—15% churn is not a problem. But 50-200% churn means someone is wasting a lot of time putting stuff in the backlog that is going to change – they do not have much of a sense of what is certain and what is not. High churn is often a sign the backlog is used to try to deter change and insulate the organization from uncertainty, rather than creating a process that is good at responding to events as they unfold and allowing the organization to deal with uncertainly.

I suggest that you draw the line on putting items in the backlog at the point where you have a reasonable degree of certainty that backlog items won’t change and will get done. You can draw this line for the number of items in the backlog and also for the detail of each item in the backlog. To do this, you measure backlog churn plus the percent of items that are unlikely to get done. If this number is over 20% - 25%, then your process is creating too many backlog items and/or too much detail too soon.

Mary Poppendieck

www.poppendieck.com

Author of: Lean Software Development & Implementing Lean Software Development

Test Driven chapter 1

Går igenom grunderna i TDD. Några intressanta saker:

"Only ever write code to fix a failing test"
Motivering
- Late defects are expensive
- Quality, (good design, no duplication, etc)
- Specification is time consuming, get old fast - TDD delivers
- Test first --> Design "inner API"

Test-->Code-->Refactor

Without refactor we have well tested BAD code.
You cannot get the architecture right on the first try
The human brain can fit 5-7 concepts simultaneosly in working memory

Refactoring preserves behaviour
Regression is existing, once-working functionality getting broken
Tests are an integral part of requirements and specification
Tests as specification
- A LOT faster feedback through automatino
- More reliable test exedcution
- One less translation step

Tools
xUnit
Fit and Fitnesse
Continuous integration - http://www.martinfowler.com/articles/continuousIntegration.html
Lint - www.splint.org
PMD - pmd.sf.net
code coverage - http://www.javaranch.com/newsletter/200401/IntroToCodeCoverage.html

Questions
How do you know it's the right test and not an unnecessary one?
Are there a paper on stated fact that Evolutionary design is less expensive than trying to get the final design on paper in the beginning?
How do ATDD trace onto TDD?
Difference btw user stories vs use cases?