Ruby on Rails In Eclipse
http://www.oreillynet.com/pub/a/ruby/2007/04/26/ruby-on-rails-meets-eclipse.html
http://www-128.ibm.com/developerworks/opensource/library/os-rubyeclipse/
Monday, May 26, 2008
Thursday, May 15, 2008
Effective Exception Handling
be specific, throw early, and catch late
Three Rules for Effective Exception Handling
http://today.java.net/pub/a/today/2003/12/04/exceptions.html
Three Rules for Effective Exception Handling
http://today.java.net/pub/a/today/2003/12/04/exceptions.html
Friday, April 11, 2008
Split lossless audio (ape, flac, wv, wav) by cue file in Ubuntu
http://aidanjm.wordpress.com/2007/02/15/split-lossless-audio-ape-flac-wv-wav-by-cue-file/
Friday, February 15, 2008
Thursday, January 31, 2008
Thursday, January 17, 2008
OOAD Toolbox
Analysis and Design
1. Well-designed software is easy to change and extend
2. Use basic OO principles like encapsulation and inheritance to make your software more flexible
3. If a design isn't flexible, then CHANGE IT! Never settle on bad design, even if it's your bad design that has to change
4. Make sure each of your classes is cohesive: each of your classes should focus on doing ONE THING really well
5. Always strive for higher cohesion as you move through your software's design life cycle
OO Principles
1. Encapsulate what varies
2. Code to an interface rather than to an implementation
3. Each class in your application should have only one reason to change
4. Classes are about behaviour and functionality
1. Well-designed software is easy to change and extend
2. Use basic OO principles like encapsulation and inheritance to make your software more flexible
3. If a design isn't flexible, then CHANGE IT! Never settle on bad design, even if it's your bad design that has to change
4. Make sure each of your classes is cohesive: each of your classes should focus on doing ONE THING really well
5. Always strive for higher cohesion as you move through your software's design life cycle
OO Principles
1. Encapsulate what varies
2. Code to an interface rather than to an implementation
3. Each class in your application should have only one reason to change
4. Classes are about behaviour and functionality
Subscribe to:
Posts (Atom)