Getting Selenium working with Groovy

Selenium downloads: http://seleniumhq.org/download/
Selenium with Java: http://seleniumhq.org/docs/appendix_installing_java_driver_client.html
Groovy: http://groovy.codehaus.org/Tutorial+1+-+Getting+started

Extract selenium-remote-control
Copy selenium-server.jar and selenium-java-client-driver.jar into groovy/lib

Start Selenium server: java -jar selenium-server.jar

Start groovyconsole
Open selenium script
Run with Ctrl+R

How to ssh/scp/sudo without being prompted for password

As source user run:
ssh-keygen -t rsa
This will geenerate ~/..sh/id_rsa.pub

Copy ~/.ssh/id_rsa.pub to target machine e.g. /tmp/tmpkey

As target user run:
cat /tmp/tmpkey >> ~/.ssh/authorized_keys


Ensure correct permissions

chmod go-w $HOME $HOME/.ssh $HOME/.ssh/authorized_keys

The Land that Scrum Forgot By Bob Martin

http://www.scrumalliance.org/articles/300-the-land-that-scrum-forgot

Should a method that can be static be static?

http://stackoverflow.com/questions/731763/should-c-methods-that-can-be-static-be-static/731779

It depends. There are really 2 types of static methods:

1. Methods that are static because they CAN be
2. Methods that are static because they HAVE to be

In a small to medium size code base you can really treat the two methods interchangeably.

If you have a method that is in the first category (can-be-static), and you need to change it to access class state, it's relatively straight forward to figure out if it's possible to turn the static method into a instance method.

In a large code base, however, the sheer number of call sites might make searching to see if it's possible to convert a static method to a non static one too costly. Many times people will see the number of calls, and say "ok... I better not change this method, but instead create a new one that does what I need".

That can result in either:

1. A lot of code duplication
2. An explosion in the number of method arguments

Both of those things are bad.

So, my advice would be that if you have a code base over 200K LOC, that I would only make methods static if they are must-be-static methods.

The refactoring from non-static to static is relatively easy (just add a keyword), so if you want to make a can-be-static into an actual static later (when you need it's functionality outside of an instance) then you can. However, the inverse refactoring, turning a can-be-static into a instance method is MUCH more expensive.

With large code bases it's better to error on the side of ease of extension, rather than on the side of idealogical purity.

So, for big projects don't make things static unless you need them to be. For small projects, just do what ever you like best.

Find deleted file in SVN

svn log -v > svnlog.txt
Then find filename in svnlog.txt

http://stackoverflow.com/questions/401331/examining-history-of-deleted-file

13 Big Programming Failures of 2010

http://www.eweek.com/c/a/Application-Development/Skype-NYSE-Error-Top-List-of-13-Big-Programming-Failures-of-2010-119831/

Design principles

GRASP

• 1 Patterns
  • 1.1 Creator
  • 1.2 Information Expert
  • 1.3 Controller
  • 1.4 Low Coupling
  • 1.5 High Cohesion
  • 1.6 Polymorphism
  • 1.7 Pure Fabrication
  • 1.8 Indirection
  • 1.9 Protected Variations

SOLID

S	SRP	Single responsibility principle the notion that an object should have only a single responsibility.
O	OCP	Open/closed principle the notion that “software entities … should be open for extension, but closed for modification”.
L	LSP	Liskov substitution principle the notion that “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”. See also design by contract.
I	ISP	Interface segregation principle the notion that “many client specific interfaces are better than one general purpose interface.”[5]
D	DIP	Dependency inversion principle the notion that one should “Depend upon Abstractions. Do not depend upon concretions.”[5] Dependency injection is one method of following this principle.

http://www.codinghorror.com/blog/2009/02/the-ferengi-programmer.html

• SINGLE RESPONSIBILITY - DON'T MAKE A BIG BALL OF MUD.
• OPEN CLOSED - DON'T MAKE A THING THAT CAN BE INADVERTANTLY TROUNCED BY ANOTHER THING.
• LISKOV SUBSTITUTION - WHEN POSSIBLE MAKE THINGS MODULARLY SO YOU CAN CHANGE LESS LATER.
• INTERFACE SEGRATION - DON'T MAKE A CLIENT DEPEND ON INTERFACES THEY DON'T NEED.
• DEPENDENCY INVERSION - DON'T MAKE SOMETHING CONCRETELY DEPENDENT ON SOMETHING ELSE, RELY ON ABSTRACTIONS

Maven Clover Coverage

mvn clean clover2:instrument clover2:clover clover2:check 


Checkstyle:
checkstyle:checkstyle