On the 28th this blog turned two years old and I thought it would be interesting to post up a bit of a summary of the past two years on this blog. I thought it would be interesting to plot posts against comments.
I’ve also decided that for the next month I will not post anything to my blog. I am taking a bit of a break because I have found it hard to keep up the same level of blogging that I had earlier this year. Hopefully I will come back refreshed and with lots of interesting things to say.
Thanks for listening and see you in January!
Last night I was making a few code changes to an application to see what would be involved implementing a new feature. There weren’t that many changes but they were split across several layers of the application. To my dismay when I launched up the application the data field (silently) to read and write that data from the underlying storage system.
Because I had made a few changes it was possible that I had introduced the bug and I wanted to quickly check against the implementation that I got when I took the branch to implement the feature. Rather than manually putting aside the source files that I had modified (what were they again?) I decided to create a shelveset of my changes then undo my pending changes to take me back to the baseline.
I determined that there was an underlying bug in the code and that I hadn’t introduced the bug so I restored the shelveset and continued tinkering. The outcome isn’t that interesting, but I think the use of this unique TFS feature was a real time saver for me, and its not the first time that it has paid dividends.
I’m sitting at the gate lounge waiting for my flight. Bella (my daughter) isn’t here yet, her grand parents will get her here around 4 to 5pm.
When I arrived at the airport it dawned on me that I would need to check-in with Bella, otherwise they wouldn’t give us seats next to each other (not a problem for me, but the person sitting next to Bella might have an issue with it).
Based on previous experience I thought they were unlikely to give me her ticket without her standing next to me so I was potentially looking at a long wait on an uncomfortable seat – it was then that I devised a cunning plan.
The Virgin Blue Quick Check booths were standing there, and I had a soft copy of the itinerary so I positioned the bar code to the top of the screen and fed it into the scanner. Just like clock work it gave me the option to print Bella’s ticket as well.
At this point I’d like to thank the programmers of this terminal for not encoding all the business rules into the Quick Check system. Its comforting to know that someone could abduct my child and fly them interstate without anyone stopping to question them at the airport.
Anyway – back to cutting some code.
I got on the plane this morning at 6:45am with my daughter to fly down to Melbourne to present at the Victoria .NET User Group’s Hands-on Day. Bella needed to come with me because Nicola had a prior engagement that she couldn’t cancel/re-arrange.
Obviously Bella couldn’t be at the hands-on day (she would steal the show) so her grand parents picked her up at the airport and dropped me off at the venue (thanks guys!). My bit started at about 10:40, and I went until about 11:30, then the attendees did a few hands-on labs and I wrapped up with a really quick look at some IDE enhancements.
I think it went down well, but I guess this stuff doesn’t really stick until you get to use it at work in anger.
Yesterday I attended a meeting with a member of a clients configuration management team. Eventually the topic of “what do you want to call your source repository” came up and we all looked at each other and blinked.
Eventually a neuron in my brain triggered and I realised that this was an opportunity to pick a code name! Several good options were put on the table but for some reason the development team leader baulked at them and opted for something mundane and boring ().
I can never understand why people choose grey names for projects, its their opportunity to put some of their personality into the project, but more importantly a good code name serves several useful purposes. A good code name:
- is a short hand way to refering to the system.
- is great for starting elevator pitches to executive management.
- is a way of avoiding analysis paralysis on namespace naming.
If I have convinced you to create a code-name for your project, here are a few rules that I would stick to for .NET projects:
- Avoid acronyms, they look like crap in namespaces.
- Prefer a single word codename, two word tops.
- Make it easy to search and replace in code.
- Place names, people names and funny words make great code names.
Do you have a code name for your project? If not, make one up and just start refering to the project as that – see how quickly your co-workers catch on.
I decided to catch a slightly earlier bus to work today so that I could catch up on a few podcasts. The first one that I had scheduled to listen to was the SQL Down Under podcast. This one is something special because it has Dr. Jim Gray who has had a hand in products such as DB2, Oracle RDB and of course several generations of SQL Server.
The hard questions about why SQL Server 2005 was so late were asked, but also questions about the future. I find the possibilities created by the CLR in SQL and LINQ coming down the line truely facinating. Is SQL going to become a data-aware application server? What happens as boxes scale up – is the midrange getting close to being able to clobber a mainframe without a cluster?
Greg also made a really great point about the reason for getting involved so early in product release cycle. Basically it boils down to being able to avoid having to keep on top of the evolving technology without having a massive learning curve every time a product ships.
Anyway – great show Greg!
I got a few comments (3) when I posted up about coding for testability. Paul took the time to post a detailed comment which came out kind of mangled and then followed up on his blog. Paul extends the pattern, essentially adding a fair bit more code and structure – this is a good thing if you can keep it up, but I wonder if I did a spot inspection of Paul’s code whether he had used it uniformly ().
Actually – the main point that I wanted to make is what effect a simple change can have on testability. I also think that if you can be more surgical in which parts of the program you mock with test harnesses you can reach into different parts of the code. This helps you test specific things, but it also helps drive your code coverage up.