Some interesting points from Martin Fowler a few years ago on XP, patterns, design, etc. Was worth skimming through quickly.

Quoted: "enabling practices of continuous integration, testing, and refactoring, provide a new environment that makes evolutionary design plausible"

Quoted: "don't want to spend effort adding new capability that won't be needed until a future iteration. And even if the cost is zero, you still don't want to it because it increases the cost of modification even if it costs nothing to put in."

Quoted: " * Invest time in learning about patterns
* Concentrate on when to apply the pattern (not too early)
* Concentrate on how to implement the pattern in its simplest form first, then add complexity later.
* If you put a pattern in, and later realize that it isn't pulling its weight - don't be afraid to take it out again."

Quoted: "First keep in mind what you're drawing the diagrams for. The primary value is communication. Effective communication means selecting important things and neglecting the less important.
* keep them short
* don't try to address all the details (just the important ones)
* treat the resulting design as a sketch, not as a final design
"

Jason M. recently forwarded this around again, good to quickly re-read.

Quoted: Flayer is a tool for dynamically exposing application innards for security testing and analysis. It is implemented on the dynamic binary instrumentation framework Valgrind [17] and its memory error detection plug-in, Memcheck [21]. This paper focuses on the implementation of Flayer, its supporting libraries, and their application to software security.

Skimmed this a while back, but just re-read and found a few more nuggets.

Quoted: It is unlikely that every programmer is familiar with Icarus, but I bet that almost all programmers have something in common with him. Programmers are saturated with advice not to do things, similar to the advice Icarus' dad gave him about aviation. Don't use threads unless you really know what you're doing (and then don't use them anyway.) Don't use new language features (they're too dangerous.) Use the "right tool for the right job" (whatever that means.) Don't "prematurely" optimize (heck, don't optimize your code at all!) Don't use macros, because nobody will be able to read your code. Don't use multiple inheritance. You ain't gonna need it (you dork!) Don't, don't, don't; no, No, NO! For the rest of this essay I will refer to such advice as "Dead" advice, in honor of Icarus' father, Daedalus (and also to honor my own lack of spelling ability.)

Quoted: Let's remember one thing about Icarus. Yes, he died a fiery, horrible death. But at the same time, he flew close to the freakin' Sun!

Quoted: This is primarily a reference resource on the TCP/IP protocol suite. If you want to really understand what TCP/IP is and what makes it work, you’ve come to the right place. If all you want is simple instructions on how to connect a few PCs together in your home using TCP/IP, this probably isn’t the Guide for you

Always important to keep handy when debugging/memory profiling static C/C++ apps ;)