Uwe Hermann | A slightly paranoid Debian developer

My reading list for tomorrow:

• JUnit AntiPatterns
• Test-Driven is Faster
• Defect Driven Test Creation
• Help! I've Inherited Legacy Code

Nothing really big, just some random programming-related blog posts, but all of them look really interesting and helpful.

A very interesting post from Mark Wielaard outlines how we can "ensure that developers can create applications using the java programming language without having to depend on proprietary software". Very good read and definately a very important and worthwhile cause.

Also recommended: ClasspathMigration: practical tips on how to avoid proprietary (java) coding styles.

(via eDev News)

John Musser has a list of contests where you can win money by coding. Nice way to get some more pocket money, I'd say...

I also like his final remark in that blog post:

Life is short, code wisely.

Michael Howard, David LeBlanc and John Viega have written a book called The 19 Deadly Sins of Software Security, which is to be published soon.

It explains the most important security issues one encounters in the software industry in a Design Patterns-like format. Each software security Sin is structured according to the following sections: Overview, The Sin Explained, Sample Code Defect, Spotting the Defect Pattern, Spotting the Defect during Code Review, Testing the Defect during Test, Example Defects, Redemption Steps, Extra Defensive Measures, Other Resources, Summary.

The 19 chapters, or Sins, each 10-15 pages long:

1. Buffer Overflows
2. Format String problems
3. SQL injection
4. Command injection
5. Failure to handle errors
6. Cross-site scripting
7. Failing to protect network traffic
8. Use of "magic" URLs and hidden forms
9. Improper use of SSL
10. Use of weak password-based systems
11. Failing to store and protect data
12. Information leakage
13. Improper file access
14. Integer range errors
15. Trusting network address information
16. Signal race conditions
17. Unauthenticated key exchange
18. Failing to use cryptographically strong random numbers
19. Poor usability

(via Dana Epp)

This is what happens to you, if you try to perform too many code changes at once. It's usually better to perform small, incremental changes and run your unit tests (hopefully many) after each of them to check if you messed up.

I don't want to even think about cases where you don't have any test cases at all. In such a case, debugging nightmares are preassigned.

I'm currently involved in multiple Ruby projects where I make extensive use of unit testing. Ruby ships with a built-in, easy to use unit testing library called Test::Unit, so you really don't have any excuse for not unit testing your code.