Coding for Real
[Part 11 of 11]

That's it! You've learnt all the main coding bits! Are you terribly disappointed? Never mind, there's one or two little code nuggets in the materials below, but they are mainly about the practicalities of programming: how to structure your time and any teams you happen to be working with, but also how to write the best possible code, and where to find good coding advice.

Further info:

You can find out more about specific processes/process elements at the following links (full list):

The Waterfall Process
Iterative development
Extreme Programming
Rational Unified Process
Release early, release often (RERO)
Continuous Integration
Pair programming


For 'Open' licenses, see:

The Open Source Initiative
Creative Commons


Information on installing and installers (but see Key Ideas for a walk-through.


For an insight into the day-to-day lives of real coders, see:
Higgins, A. (2007) 'Code talk' in soft work. Ethnography 8(4), pp.467-484.


In 1942, author Isaac Asimov introduced the "Three Laws of Robotics" to the world. These were:

1) A robot may not injure a human being or, through inaction, allow a human being to come to harm.
2) A robot must obey the orders given to it by human beings, except where such orders would conflict with the First Law.
3) __________________________________________________.

  1. On hearing the phrase Domo Arigato, Mr Roboto, all robots must respond with "Domo. Domo."
  2. A robot must protect its own existence as long as such protection does not conflict with the First or Second Law
  3. A robot must know it is a robot
  4. A robot can only pop some moves on their own time

Correct! The "Three Laws of Robotics" are a classic example of early thinking about the relationships between people and computers, and have, therefore, had a suprisingly large influence on computational ethics, at least informally. The correct response to "Domo Arigato, Mr Roboto" is, of course, "Dou itashimashite". "A robot must know it is a robot" is Kesarovski's Fifth Law of Robotics. Robots, strangely, can't do robotic dancing half as well as humans: see? Far too fluid. Rubbish.

Further info:

For more on patterns, see this list: Software Design Patterns.

For info on their evil twins, anti-patterns, see: Anti-patterns (caveat lector, some of these we'd put in the 'good' category, so there's considerable controversy around some).


You can find more info on running external processes from within Java at Steve Liles' site; and some nice examples at Réal Gagnon's How To site. There's also an interesting example of how to use the java.awt.Robot class to write to an external application on Stackoverflow by Dominique Gallot.


Given these patterns:

1) Observer: Define a one-to-many dependency between objects where a state change in one object results in all its dependents being notified and updated automatically.

2) Wrapper: Convert the interface of a class into another interface clients expect. An adapter lets classes work together that could not otherwise because of incompatible interfaces. The enterprise integration pattern equivalent is the translator.

3) Iterator : Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

The Java Event Based Programming model is an implementation of _____________.

  1. the Observer pattern
  2. the Wrapper pattern
  3. the Iterator pattern

Correct! The Wrapper pattern is implemented by things like java.lang.Double, that wrap around primitives. The Iterator pattern is implemented by classes like java.util.Vector -- this provides an alternative way to loop through them.

Further info:

Types of test:

Unit Tests
Stress testing
Alpha/Beta releases
Regression testing
Software testing

Unit Testing is a major part of the design philosophy called Design by Contract, which concentrates on loose but well defined coupling.

See the Key Ideas page for an example of how to run unit tests. After this, if you want to investigate Unit Testing in more depth, some good tutorials on Unit Testing using JUnit are:

Tutorialspoint's JUnit tutorial
Lars Vogel's Unit Testing with JUnit

When you've got the hang of it, you might also like to look at:

The JUnit API
Joe Schmetzer's JUnit Antipatterns

You might also be interested in Java's built in Assertion testing which is a component of Unit Testing, but can be used independently to test the internal dynamics of methods.


When developing code using test driven development you should _____________________________________.


  1. write your code and then test it to make sure it works
  2. write your code to cover as many eventualities as possible and then write your code to satisfy these conditions
  3. write your code and tests in parallel so that you can adapt your tests to fit the situation as it evolves
  4. adjust your tests to make sure that they all pass

Correct! The idea is that tests structure the writing of the code, not the other way around. If the tests correctly match your specification of the interactions between classes, you shouldn't need to adjust them at all.

[Key ideas from this part]