External images in a local report

We've been playing with Reporting Services at work lately, in particular the use of Local Reports.

Adding external images to these reports is a bit fiddly. The "handling images" section of this devx article sheds some useful light on what the path must look like, and how to handle relative paths.

As local reports require an absolute path, one means of doing this to use an embedded VB.NET function:

Public Function GetAppPath() As String
   Return System.AppDomain.CurrentDomain.BaseDirectory
End Function

Using this function, here's how you can set up the Value property of an image to point to the external image file.

=System.IO.Path.Combine(Code.GetAppPath(),"image.jpg")

I'm a DHTC programmer

Interesting programmer personality test. My programming personality breakdown is below. Do you agree with this? What kind of a programmer are you?

DHTC

You're a Doer.
You are very quick at getting tasks done. You believe the outcome is the most important part of a task and the faster you can reach that outcome the better. After all, time is money.

You like coding at a High level.
The world is made up of objects and components, you should create your programs in the same way.

You work best in a Team.
A good group is better than the sum of it's parts. The only thing better than a genius programmer is a cohesive group of genius programmers.

You are a Conservative programmer.
The less code you write, the less chance there is of it containing a bug. You write short and to the point code that gets the job done efficiently.

A user story story

Although I've known about user stories for about five years, I've only now been in the position to practise what I preach.

Having promoted them within my team (particularly following QCon 2007), I'm trying to use them on every project I work on and have to say I am blown away by their effectiveness! Although we captured them onto a wiki, their power immediately became apparent when we started using the real paper/card versions.

First off, estimating (complexity) became immediately easier: we analysed each card and divided them into three piles (easy, medium and complex). Unknowns and design notes were made direct onto each card, for later reference. The cards could also be simply arranged in dependency groups. Pieces of paper divided into piles made the shuffling back and forth incredibly easy and low cost.

We then assigned effort estimates (weeks) to each story and grouped them into possible iterations. Again, the ease with which changes could be made, and the effects so easily seen gave the analysis extra power. I've always previously used Excel to do this kind of work, but whilst it "looks" professional and does the sums for you, it lacks the speed and imprecision of paper!

The power of paper was further demonstrated when we met with a system commissioner, and talked them through our analysis. Each piece of paper could be referred to in turn, to address unknowns and discuss implementation considerations. The story groups could be simply seen, but also easily rearranged.

The ironic twist is that we kept our wiki versions of the story up-to-date as we changed the paper ones. However, we came to the conclusion that whilst the paper stories looked unprofessional (my writing is not the neatest :-), the real paper ones were just so much more powerful.