Code Beast

Entries categorized as ‘programming’

My Bookshelf

February 8, 2008 · 3 Comments

These are the books I have at work, which mostly reflect the various projects I’ve worked on over the years.  Some are useful, some are not.

General Books:

  1. Design Patterns, GoF: Recommended, but first read Head First Design Patterns.  These two books togther kicked my brain into being able to think critically about design decisions.
  2. The Pragmatic Programmer:  I like it, though I think it’s worth less now in the light of robust discussion of these topics on blogs.
  3. Peer Reviews In Software: Haven’t opened it.  Got it from a mandatory training class that didn’t impress me.
  4. Lean Software Development / Implementing Lean Software Development: Barely cracked them. Put on my desk by my boss, but I think this particular movement (in our organization, anyway) is going to pass before I need to care too much about it.
  5. Extreme Programming Explained: Barely cracked, though I bought it myself.  Once I started reading it, I realized I already learned the content on the web.

Technology-specific books:

  1.  The C++ Programming Lanuage: Essential if you’re using the language.
  2. Effective C++/More Effective C++/Effective STL: Also essential if you’re using the language.  Other books tell you how to write code, but these books tell you how to right GOOD code.
  3. Effective C#: Doesn’t live up to its namesake.  Perhaps there are fewer gotchas in C#?
  4. Java Performance Tuning: I got this for $5 and learned one or two things from it.  But I think it’s about Java 1.1, so it’s more than a little out of date.
  5. Interprocess Communication in Linux: useful when I needed it, but I no longer need it.
  6. Programming .Net components: This is a bit of a weird one.  I was hoping it would explain the mysterious System.ComponentModel namespace, but I never got into it enough to fully understand what’s going on.  I could probably learn a lot from this book if I got into it, but I’m not motivated to do it anymore.
  7. Java development with Ant: I like this one.  Useful whenever I need to do ant, which is more often than one might think.  And my copy is autographed!
  8. Applications=Code+Markup: Meh.  Not that impressed.  If you want a WPF book, get:
  9. Windows Presentation Foundation Unleashed: This is the one you want.  It’s smaller than the previous book, but it has better explanations about the things that matter.
  10. Debugging Microsoft .NET 2.0 Applications: This book has saved my ass on multiple occasions.  If you’re developing for .NET, you need to know how to use your debugging tools.

What does your bookshelf look like?  Are there any bacon-saving books you’d recommend?

Categories: c# · opinion · programming

Rules of the Source Tree

October 16, 2007 · 2 Comments

These are the fundamental rules I use when managing a source tree. To many these are a given, but others don’t know these things.

  1. There must be an automated build.
  2. If you break the build, fix it.
  3. Building the code must be trivial.
  4. The code should run from the source tree, with no installation steps required.
  5. Creating a new build machine be as easy as following the document you wrote saying how to do it.
  6. Things needed to build the code aside from the contents of the source tree must be minimal and well documented. Ideally, this is nothing more than your compiler and your build system.
  7. Source control is for source code. Checking in binaries is allowed only in the pursuit of #4, or when said binaries are a critical part of the software itself. Even then, tread carefully.
  8. If you can choose between a binary and textual representation for a source file, use text. Consider this when choosing your tools. (WiX good, InstallShield BAD)
  9. It must be trivial for developers to run the unit tests in the same way the automated build does.
  10. Be considerate. Think about your fellow developer.

My project is pretty good on this list, I think we’re at 7.5/10. I’ve had major headaches enforcing #7, to my great disappointment. And number 8 is a continuing struggle. We’ll get there, hopefully. The half point is from #10 - turns out it’s hard to create a culture of mindfulness out of nothing.

What’s the score on your project? Are you working any of these things?

Categories: programming
Tagged: , , ,