You Are not the User

Read Ask "What Would the User Do?" (You Are not the User) last week or so.  My thoughts on the article:

• It is always better to have a prototype, on paper or a digital mockup, of the user interface so that a user can work through it, rather than a verbose "user interface requirements" document
• As developers, although we usually are able to figure out new user interfaces we encounter, we often do the same things novice users do especially when things don't work as expected.  E.g. once we figure out a user interface, we may do the same steps all the time instead of looking for a short-cut.  And sometimes we stick with the same tools or older versions because we find it too much of a learning curve to try new ones

97 Things

Making time to read one article everyday from 97 Things Every Programmer Should Know (book format or online) and write about it the following day or soon after.  Advice I've read so far:

• "Act with Prudence" - one way (not perfect) to keep track of technical debt is to use TODOs in the code.  The text associated with a TODO should be specific enough so that someone else reading it in the context of the code understands what still needs to be done.  
• "Apply Functional Programming Principles" - (a) indeed, as the author Edward Garson states, mis-use of object-oriented programming creates bad designs.  In particular, IMO, the difference between using setters versus parameters to a method is not entirely clear.  The advent of Spring also has popularized the use of setters although Spring can just as easily work with constructors so that when an object is instantiated, its state is correct and it is ready to be used.  My rule of thumb is when in doubt, use parameters to a method to pass arguments, not with setters.  (b) As the author also states, test-driven design also helps to promote better design.  IMO it is because as you write automated test cases, you become a user of your API ("Eating your own dog food" principle), and you begin to understand what makes an API easier/cleaner to program against.  

PostgreSQL server starts up but then stops immediately

On Windows, starting through the Services window will indicate the above with a message similar to "The PostgreSQL Server 8.4 service on Local Computer started and then stopped.  Some services stop automatically if they have no work to do, for example, the Performance Logs and Alerts service".


Check the Event Viewer (shortcut:  Type "eventvwr" in Start > Run). In my situation, the data directory I specified at installation time appeared to not exist as indicated by the error message "FATAL:  data directory "XXXXXXXXXXXX" does not exist".  However it appears to be a permission problem, as the directory indeed existed. 
 
The easiest solution is to uninstall and reinstall and specify a directory that you know the postgres user ID will have no issues accessing (e.g. the default data directory suggested by the installer)

Maven project has errors in Eclipse (no changes were made)

Possible fixes:

1. More common:  If Project > Build Automatically is checked off, do a Project > Clean on the problematic project.  Usually this fixes the issue.
2. If compile errors persist, especially indicating dependencies that should be resolved by Maven, Project > Update All Maven Dependencies.  This may be needed if the local repository was moved; Eclipse may need to be refreshed of this.  
• Speaking of which, after moving the Maven local repository, simply update the path in the settings.xml file in the .m2 directory in your home directory (e.g. C:\Documents and Settings\alan.leung\.m2 or ~/.m2 on *nix)

Configuration objects read from/saved to files

For Spring-enabled applications, Spring has a rich configuration scheme, and objects can be fully configured and wired together based on the directives specified.

Alternatively, one can consider defining the application configuration by code, serializing the configuration objects to file as a starting point, and then, as needed, editing the configuration in file format.  When the application starts up, it will read in the configuration, de-serialize it back into object form and the application can work with the configuration.

Not unexpectedly, Spring has a way to set up marshallers/unmarshallers for your application so that it is opaque to the application which XML serialization library it is using.  This makes it easy to swap out for a different library.  I tried three different libraries with Spring and these are my findings:

Library	PROS	CONS
JAXB	"The standard for Java"?	Require jaxb.index file in package's folder Need to annotate class with @XmlRootElement Have to have no-arg constructors even if it is against design practices Doesn't work with Interfaces and cannot de-serialize a class extending from an abstract class
Castor	Popular?	Serializes well but on deserializing, get an error of org.springframework.oxm.castor.CastorUnmarshallingFailureException: Castor unmarshalling exception: The class for the root element 'anonymize-settings' could not be found.; nested exception is org.exolab.castor.xml.MarshalException: The class for the root element 'anonymize-settings' could not be found. For whatever reason, Castor doesn't add the xsi:type attribute on the root element when it serializes.
XStream	Actually works Codebase doesn't have to change for XStream to work with it (no design compromises)	Not popular?  But the library is so simple to use, there is absolutely no learning curve so you don't have to devote a lot of time to it

Notes on early TSS.NET Unit Testing article

• Article
• "A test fixture is a class that contains a series of test methods ... This grouping is important for two main reasons: one, it creates a subset of tests that can be run as a group, separate from other groups of tests, and two, it provides a level of granularity for controlling the lifecycle and context of a test."
• For database code, article suggests using stored procedures to initialize database for a unit test and calling these stored procedures in SetUp and TearDown.  Also, more specific stored procedures to create additional data for specific tests.  More ideas:  Get Test Infected with NUnit: Unit Test Your .NET Data Access Layer 
• a mock object will have the same interface as the "real" object.  The implementation of the mock object should track usage, allowing you to determine if the right calls were made (by the tested code), and expose any methods/properties that test code might use to evaluate results.  Rather than implement yourself, can use a dynamic mock object library such as NMock
• Nester helps verify code coverage by unit testing:  "involves modification of programs to see if existing tests can distinguish the original program from the modified program" (mutation testing)
• So that test code doesn't force breaking encapsulation of the tested code, have tests reside in same assembly and namespace as code being tested.  Then non-public methods/properties that need to be accessed by test code can be marked with internal modifier

UML symbols reference

From Microsoft Visio:

From UMLet: