Threaddown is a segment on “The Colbert Report” where Steven Colbert runs though the top five current threat that, err, threaten the USA. This particular Threatdown, although a little old now, is the best I’ve seen (even if you don’t know about the running joke regarding Steve Colbert having an acute and irrational fear of bears).

Quote of the day: “Nobody expects the second bear!”

Thus, through this post I am renewing my resolve to get the camera out more often. While I don’t intend to do anything as drastic as the 366 days of Flickr, I do want to make sure I get out at least once a week, even if it is only for a short time. Perhaps something like the Digital Photography School’s Weekly Assignment is worth trying.

Additionally, I want to start trying to photograph things/subjects I haven’t normally had much experience with. My main focus thus far has been on landscapes (like the sweeping mountains I seem to be addicted to), so I really want to step outside that. Primarily I want to learn how to photograph people, both when they are and are not expecting it. Beyond this, more animals (because they’re cute), buildings and flora also seem like fun.

In an effort to keep myself on track I am going to start a “photo-of-the-week” stream here. Each week I will highlight a single photo that I *MUST* have taken in the past 7-days. Hopefully this will put some kind of pressure on me and will hold me to my course. I don’t promise they’ll be good (in fact, I promise they won’t be), but I’m sure that after a year or two it will be interesting to look back and see what progress has been made.

If anyone else has any subjects ideas (or volunteers!) or general advice, I’d love to hear it, so be sure to ping me via IM/IRC/e-mail or comment.

istringstream stringStream( number );

and your compiler gives you an error like this:

main.c:16: error: variable ‘std::istringstream stringStream’
has initializer but incomplete type

what is really means is that you forgot to include <sstream>

This is why I hate C++. Someone just give me Integer.parseInt(String) ffs.

It’s actually quite good, however at the moment it seems that the switching between webcams is broken (at least in Safari, didn’t bother to boot the windows machine and try IE). Useful for those moments when you’re a long way away and missing home.

While I have no doubt of the value that exists in the legacy project, or the quality of its contents, I have found myself cursing it many, many times. Outwardly it would seem that I hold some form of contempt for the project, or the quality of the project, however, that notion this is more assuredly not true. The biggest problem this project has is its build system. While understanding the design and implementation of this large system is difficult enough, it often feels like a developer is actively engaging in a fight with the build system just to compile or package the application or part therein.

This experience has driven home a particular points to me: Although much thought and consideration may be evident in the architecture and design of the product, the same standard hasn’t been applied to the build system itself. A simple build system is fundamental to the experience of developing for a project. The most amazingly elegant, well designed application can be made to feel unstable, unpredictable and generally brittle if the process used to build it is unnecessary complex and convoluted.

Like most commercial environments, this product was developed under real-world pressures and deadlines. Taking time out to focus exclusively on the build system is difficult to justify when the reality is that it adds no direct features of any value for the end user. However, it has been my experience that neglecting these aspects of a system always ends up costing you time and/or money in the end. To go from a clean windows install to a fully functional development environment for this project took 3 entire days. The process involved many, many manual steps, the location, download and installation of countless dependencies, a great many problems with version mismatches for these dependencies and considerable assumptions being made about the level of exposure developers had to particular tools.

In Portico we spent a LOT of time working on the build. When significant changes were made to the project (such as adding a C++ interface that required building C++ code), the effect on the build was considered and a lot of thought, time and effort was expended to make sure we had a process that was both easy to use and required the user have the only the bare minimum environment previously installed (just Java and a C++ compiler). This often involved many iterations and on several occasions we had to throw away significant parts of the existing build, replacing them with something that better suited the problem at hand.

Although we could have spent less time and still come up with something that “worked”, the task was deemed of such high importance that the extra time and effort seemed justifiable. After all, developers would be interacting with this build day-in and day-out. Yes, it cost time, and by extension it cost my employers money. However, the payoff is immediately obvious. The setup time for a new developer is about 15 minutes and involves two steps: 1) checkout from version control, 2) “./ant sandbox”

That’s it. Spending all that time making sure the build was just right translates not only into time saved later on, but to a much more pleasurable development experience. Such a simple build allows a developer to focus on solving problems with the application rather than having to constantly switch mental contexts in order to engage in hand-to-hand combat with the build system. While quality is a function of thought and reflection, the experience of quality extends only as far as the weakest link. If building your software feels like a huge effort that might not even give you what you want at the end, then it doesn’t matter how good the code is, the experience is going to be bad.