So, if you peruse the sporadic entries up until this one, you might notice that they run long. That's my tendency -- to write long, with exhaustive research and explanations. It's also what keeps me from blogging very often. I'll have ideas, but the prospect of climbing Everest dissuades me from undertaking it. Before I commit the time to explaining the development travails I went thorugh, I'm working on the next idea, and I've left my previous troubles behind.
I thought of an idea that might work for this site. I dig the agile practice of test-driven development, where you start out with an idea of what to do -- write a test, knowing that it's going to fail (red), then work until that test passes (green). That first pass most likely will not be the best solution, so you refactor until you've hit the best solution (given your constraints).
I'm going to try to use a derivation of that method here. I will tee up whatever development issue I'm facing in an initial blog post (call it red). I will then talk about resources I tap into and experiments I attempt in trying to solve that issue. The first idea that works is the green post. And then onto the process of refactoring.
Most likely, the information will not be the definitive answer for the problems I run into. However, the content will be actual issues encountered during actual development. It will not be a contrived example to discuss a new feature. And I won't bother posting about the easy stuff, or the stuff that's a simple google search away.
I will try to keep a consistent set of headlines, so that if you find a topic that interests you, you can search the blog and get an idea of how the problem arose, and how I tackled it.
