programming

Reading List

My reading list for tomorrow:

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

How to Win Money Coding

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.

The 19 Deadly Sins of Software Security

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)

Just Ten Minutes Without a Test

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.

Syndicate content