Off to New Zealand

My wife and I are off to New Zealand tomorrow for one week. We're flying out of Adelaide about midday, to Sydney and then on to Christchurch. Arrival time in Christchurch is about 1am Friday which means we'll probably not get to the hotel until about 3am.

Spending Friday and Saturday in Christchurch. No definitive plans yet for what to see or do. My wife has compiled a brief list of possibilities.

Sunday morning we board the TranzAlpine train through Arthur's Pass to Greymouth. I'm probably looking forward to this train trip the most. I've not been on a train for about a year and I've not been on a train through any real mountainous terrain. Hopefully I can get a few good snapshots out the train window.

In Greymouth we pick up a hire car and head for the Franz Josef Glacier. A few photographic opportunities exist on the drive at Hokitika, Lake Wahapo, and Lake Mapourika. Not sure how much of the glacier we'll actually get to see. Depends on when we arrive and when we depart the next day.

Monday 22nd we depart Franz Josef Glacier headed for Queenstown. Possible stops along the way at Fox Glacier (just 20 or 30km from Franz Josef), Haast Beach, Wanaka, and the Queenstown surrounds.

The day after we are driving to Mt Cook to have a look and take photos. Then we drive back to Lake Ohau for the night. I am hoping this will provide good scenery and late afternoon light for some landscape photos.

On the 24th we head back to Christchurch, stopping at Lake Tekapo. Flying back to Adelaide, via Sydney, on Christmas day.

I'll be twittering (http://twitter.com/anthonycramp) as we go along, so feel free to follow me if you'd like to keep track. I also hope to be able to regularly upload photos to Flickr and you can keep track of my photostream (http://flickr.com/anthonycramp) if you are interested.

Or you can just subscribe to my FriendFeed and get everything in one place: http://friendfeed.com/anthonycramp.

Adelaide Panorama

My wife and I spent the latter half of this afternoon taking a few photos of Adelaide. Well, I maybe took a few more than a few. Below is the result of stitching together a few of those photos. 13 photos to be exact. Each was captured in RAW format on my Canon 400D with a 300mm lens. Each file converted to TIFF is 57.6MB. I stitched them together using DoubleTake. The stitched image saved as a TIFF is 270MB and about 20000x1300 pixels. I've got a few HDRs to process as well. I'll post the best of them to my Flickr stream.

My Software Development Technology Stack

I want to focus (a little) on my technology stack for software development so that I can proceed away from being a jack of all trades, master of none. However, software development encompasses such a broad scope of technologies and skills, there will still be lots to learn. At a minimum I can select certain tools and technologies to use exclusively in my software development and direct my learning in those areas.

Here is the technology stack I have selected:

• Operating System - Mac OS X: I have an iMac (one generation back) and a MacBook (one or two generations back) so Mac OS X is a default choice to work on. Not that I mind. I find Mac OS X provides a superior development experience compared to Windows and a better desktop experience compared to GNU/Linux. The best of both worlds. Though I will be using Mac OS X as a development platform, I will not necessarily be targetting it exclusively as the platform for any software I write.
• Programming Languages - C++ and Python: C++ is my language of choice. I like its expressiveness and freedom compared with other statically typed languages. I add Python to the mix as my dynamic language of choice. Again, I am a fan of the syntax including the meaningful whitespace. I may throw Objective-C into the mix as I have some thoughts of writing an app for the iPhone/iPod touch.
• Editor - TextMate: I am not much of an IDE person. I much prefer having a powerful text editor that is not tied to any particular editee technology. TextMate fills this role.
• Version Control: Haven't completely decided on this yet. It will be Subversion (because it is something I know) or Mercurial. Possibly both.
• Build: SCons will be my choice here. It is not as fast as some other build systems. But it is simple to use and is developed in Python.
• Unit Testing: For C++ I really like the simplicity of UnitTest++. Not yet sure for Python.
• Libraries: This list will evolve over time. The only thing I can say definitively now is that I will make use of the Boost C++ library.
• Documentation: Right now I am most familiar with LaTeX for documentation. However, I would like to spend some time exploring DocBook for capturing my documentation. This will require learning about DocBook itself and also the technologies for taking a source file and creating a pdf.
• Bug Tracking: I've signed up for an account on FogBugz. Currently I just have a trial account and I will switch over to the free startup version soon.
  

Wrapping all of this technology is my ongoing reading and learning about general software construction best practices.

This blog is intended to contain my day-to-day thoughts and ramblings. My Know Thy Tools blog (which will have address www.knowthytools.com soon) will be the place I record my learning about the items in my technology stack. I will also be creating another site to capture more static information regarding any software projects I start. I'll post here once I have that up and running along with my intended software projects.

Project Layout Revisited

As has happened with me previously, getting a topic off my mind by writing about it or expelling it in some other way has left my brain free to proceed further with the topic. This happened today with the topic of my previous post on laying out a project folder structure on the filesystem and in a version control program.

I expressed dissatisfaction with the typical branches, tags, trunk structure of a subversion project as I felt it did not allow for independent version control of individual items generated during development. Items such as the documentation and test rigs, I stated, could only be version controlled along with everything else in the product.

The solution I presented was to have separate projects for each of the configuration items of a product: requirements, design, implementation, documentation, test, and release. Each of these would have their own branches, tags, trunk.

Today I realised that this solution was borne out of a conceptual block with the way subversion is used, particularly in the creation of tags and branches. My default process for creating a tag, for example, is to go to the root of the trunk folder and perform an svn copy to a new tag folder in the root area of the tags folder. Doing this copies the contents of everything in trunk, which I didn't want to do.

What didn't occur to me before today was that it is completely permissible to do an svn copy from a subdirectory in the trunk to a subdirectory in tags or branches. This would effectively tag or branch a particular folder of a subversion project. If those folders are the requirements, design, implementation, documentation, test, and release areas I expatiated previously, then I get the same result as the separate project per configuration item.

This alternate layout looks like this:

product_name
- branches
 - requirements
   - b1
   - b2
   - ...
 - design
   - d1
   - ...
 - implementation
   - ...
 - documentation
   - ...
 - test
   - ...
 - release
   - ...
- tags
 - requirements
   - tag1
   - tag2
   - ...
 - design
 - ...
- trunk
 - requirements
 - design
 - implementation
 - documentation
 - test
 - release

As with everything, there would be advantages and disadvantages with this layout and the layout presented in my previous post. The big advantage for me with the structure above is that I can just check out product_name/trunk and have everything at my fingertips. I just need to remember to define the destination correctly when performing an svn copy.

An advantage with the layout presented in my previous post is that it allows better separation of concerns. This is particularly relevant in large teams where certain people will only be involved with requirements and a completely different set of people may be involved in the release.

For myself, basically a sole-developer, to get everything with the per project structure means checking out six trunks or checking out at the root and getting all branches, tags, and trunks for all configuration items.

I'll play with this new structure soon and see if it is effective in practice. Now that I have this extra information off my mind, I wonder what my brain will tell me tomorrow.

Project Layout

One of the areas of professional software development that (I think) doesn’t get much coverage is how to layout a development area for a product on the filesystem and inside a version control package. I have been using subversion for the last four years and have always defaulted to the typical

product_name/
  - branches
  - tags
  - trunk

layout. The layout inside trunk will be dependent on product but would have at least

trunk/
  - src
  - doc
  - test

However, I’ve recently been encountering a few problems with this structure. The problems basically boil down to not being able to isolate the version control of various items generated within the product. All version control operations (eg, tags/branches) affect the entire product.

Documentation is the real bug-bear in the scenarios I have been thinking about. One could consider a scenario where a final release of a product has been shipped but a bug has been found in some documentation shipped with the product. Fixing the bug in the documentation is easy, but because the documentation resides in the same configuration area as the implementation, shipping the fix would possibly necessitate an entirely new release of the product with a new version.

I am fairly sure that what I have presented above is a problem that has been solved (potentially many times). A solution I have been toying with recently is to have multiple sub-folders for a product each of which are projects in version control in their own right. For example:

product_name/
- requirements/
  - branches
  - tags
  - trunk
- design/
  - branches
  - ...
- impl/
  - ...
- documentation/
  - ...
- test/
  - ...
- release/
  - ...

A brief explanation of these folders is:

• requirements: Stores all documents capturing the requirements for the product. Most small products won’t need detailed requirements. However, I feel that at the very least there should be some stated (and documented) vision/purpose for the product to clarify why the product is being built. Having a separate requirements area in version control allows the requirements to be version controlled just like anything else. For example, once requirements have been agreed upon between with a client, the requirements area could be tagged as “version 1.0”.

• design: Analogous to the requirements area, the design area capture all the documents related to the design of the product. Again, for a smaller product, having a completely separate area might be overkill. As I’ll mention later, there is scope for including the test planning in this design area.

• impl: This contains the code, unit test code, build scripts, and api documentation generation scripts. I would include unit test code here instead of the test area as I consider unit testing an integral part of writing the final code.

• documentation: This is the area that contains the documentation that will be shipped with the product. It is separate from the impl section so that it can be version controlled separately.

• test: This area contains formal test documentation and results. Testing is an interesting area as it is a practice that contains parts that should be conducted before implementation and after implementation. Before implementation there is the development of a test plan and a test description. After implementation there is the actual testing and the compilation of test results. I’m not yet clear how to capture these two roles. Options are to capture the test planning phase in the design area, create a separate area explicitly for test planning, or include everything in the one test area. Thinking about it now, I’d probably put the test plan in the design area and the test description in the test area along with the test results. The test area will likely also contain numerous automated test rigs that implement parts of the test description.

• release: This contains scripts to generate a final package ready for distribution and documentation of what is contained in a particular version of a product.

In addition to these core product areas, I might also add areas for storing third party dependencies (for example, libraries and build tools) and perhaps an area for reference material (coding standards, documented best practices). These things would generally be applicable to multiple products so could be stored in a central area and drawn in to each product area for easy reference. This inclusion could be conducted using svn:externals, for example.

This structure seems fairly large and unwieldy and flies in the face of extreme/agile programming. However, for products that require traceability and verification, this structure is possibly minimalistic and/or naive. I’d be really interested to hear from others on how they set up their product areas (both casually and professionally). I’d recommend anyone wishing to share to create a blog post of their own and send me a link (either in a comment or via Twitter (see the follow me link on the right)). Feel free to comment on the content of this post below.

Know Thy Tools: New Content

Some new content on the Know Thy Tools.

cmd.exe: help and character completion
For some reason character completion is not enabled by default in the cmd.exe shell available on Windows. Fortunately it can be switched on as is described in the help page for cmd.exe. I have written a page on Know Thy Tools that describes how to get help for cmd.exe's commands and how to enable character completion.

TextMate: Editing multiple lines
I move away from the command line for the first time with a snippet of information on TextMate's column selection/edit mode. This is particularly useful if you need to replace or enter characters at the same location on multiple lines simultaneously. The example I give in the linked page is how to replace an * at the start of multiple lines with a #.

Google Group for Know Thy Tools
I have also created a Google Group for Know Thy Tools. I intend to use that Group as the discussion forum for the Know Thy Tools site. Feel free to join the group and post a question or provide feedback.

Know Thy Tools posts on this blog will hopefully run once a week. Although, that will depend on how much time I have to add content to the site.

Thanks for reading.