Labels

.net (1) *nix (1) administration (1) Android (2) Axis2 (2) best practice (5) big-data (1) business-analysis (1) code re-use (1) continuous-integration (1) Cordova-PhoneGap (1) database (2) defect (1) design (3) Eclipse (7) education (1) groovy (2) https (2) Hudson (4) Java (1) JAX-RS (2) Jersey (3) Jetty (1) localization (1) m2eclipse (2) MapForce (1) Maven (12) MySQL (1) Nexus (4) notes (4) OO (1) Oracle (4) performance (1) Perl (1) PL/SQL (1) podcast (1) PostgreSQL (1) requirement (1) scripting (1) serialization (1) shell (1) SoapUI (1) SQL (1) SSH (2) stored procedure (1) STS (2) Subclipse (1) Subversion (3) TOAD (3) Tomcat (4) UML (2) unit-testing (2) WAMP (1) WAS (3) Windows (3) WP8 (2) WTP (2) XML (4) XSLT (1)

Thursday, October 13, 2011

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

Monday, October 3, 2011

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.