See http://www.JornH.person.dk ... unfortunately only in Danish language at the moment, sorry!
But at least my e-mail address is there.

Let's explore this WikiWiki thing:

   1. JørnsTodo?
   1. JørnsRememberToUpdateCalendar
     1. Hmm

A Learning Guide To Design Patterns - http://www.industriallogic.com/papers/learning.html

System Testing Patterns - http://www.agcs.com/patterns/papers/systestp.htm

## Spanning multiple coloumns see HelpOnTables
|||| So I can have a ||
|| Table ||Here||
----
= The Programming Process =

 1. Introduction
 1. Object-oriented Software Engineering
  * History: OMT (Rumbaugh) - Booch - Coad/Yourdon - Shlaer/Mellor - OOSE (Jacobson)
  * Now: UML 3 Amigos
 1. Why Object-oriented?
  1. Route Planning - an Allegory (på dansk: analogi)
   * Turn, left, right, left, left - not good solution if going on a different trip tomorrow - better to give a map and teach how to use it (a short term cost - but pays off in the long run)!
   * [Same problem with Exbert's first ShowBoat solution]
  1. Problem Domains
   * Base your design on ''problem domain'' = ''context for particular problem'' => more robust solution
   * Problem domain for route planning is e.g. maps, route planning, travelling and strategies for moving around
   * ''SA/SD'' based on top-down => leads to solution based on ''specific'' problem => rigid structure with centralized control 
   * ''OO'' based on middle-out => details based on abstractions
    - core: problem domain abstractions - stable! 
    - downward: code in classes [handling of class responsibility]
    - upward: overall structure developed using associations and interitance
 1. Writing programs
  1. An Overview
   * RUP: Inception (2) - Elaboration (3-4) - Implementation (5) - Testing and Delivery (6)
   * /!\ Design tries to predict the future - be prepared to get it wrong.
  1. User Requirements Gathering
   * Scenarios (or more rigorious - Use Cases)
  1. Analysis
   * UML notation for class and object diagrams
   * CRC [User Stories]
  1. Design, Implementation and Testing
   * <!> Tip: Be proud of your code. Let others read it. When they find errors don't be upset - just fix them.
  1. Review and Iterate
   * Add subsets of full requirements - review work so far [refactoring?]
   * ''Common pitfall: Procedural design partitioned in classes (linear sequence of events) => create objects that encapsulate data and provide services''
   * <!> Tip: Throw away design/code that doesn't work or is going nowhere.
  1. Program Testing and Delivery
  1. Debugging
 1. Maintenance
 1. Practice and Experience
  * Learn to judge the quality of programs. (Good structures that exhibit '' good abstraction, flexibility, modularity and elegance'' )
  * Study design patterns [http://www.industriallogic.com/papers/learning.html A Learning Guide To Design Patterns]
  * <!> Tip: Spend a significant amount of time reading the literature [TBD ladder]
    - aim to read one text book a month along with 2-3 journals!!

----
BTW, if you create personal pages, '''do''' prefix them somehow, like JørnsTodo. Because maybe other people would like to have a todo page too? ;) 

''Ohh.. I think I get the point :) ''

What do ArneDoToday
----
CategoryHomepage