I’ve been using NHibernate as the back end for a web service and ran into a little problem when returning the NHibernate objects to clients via the web service. I had a Person object which had a child collection of Addresses which I had explicitly set to lazy load depending on the request from the client. The lazy loading was fine, however when I went to serialize the Person object the serializer would check the Address property and therefore cause a lazy load of the Address collection.
I couldn’t find a way to tell NHibernate to ignore future requests on the Address collection once the Person object had been populated so in the end I had to handle it manually and return custom DTO objects via the web service.
As yet I haven’t found a better way to deal with this situation but hopefully there will be a way to remove objects from the NHibernate session or at the very least tell NHibernate to ignore specific objects in session.
In Australia we are in the unfortunate situation where no matter where you are, you have to pay line rental for your landline phone. Then on top of that you have to pay for your phone calls. The catch was that even though I didn’t use my home phone for phone calls, I had no choice but to pay line rental because my ADSL connection relies on the phone line. Even more annoying is the fact that I have VoIP hooked up through PennyTel so even if I did use my home line, I wouldn’t be using the private carrier.
So, my monthly "Telecommuncations" bill looked like this:
- $49.95 for my internet connection through netspace (40gb Downloads)
- $29.95 line rental
- $5.00 per month contract with PennyTel (plus calls)
Which left me with a total bill of $84.90 and feeling like I wasn’t getting great value.
It was also a pain because there was 3 different bills and it was just generally a hassle.
For a while now, Australian ISP’s have been offering "Naked" ADSL plans which effectively allow you to have an ADSL connection through your phone line without paying line rental. It’s not quite how it works, because you do pay a premium for the "Naked" plans. Recently Netspace released their Naked ADSL plans and for me, it worked out being cheaper and better value than ADSL with line rental. I now just have a Netspace bill and a PennyTel bill which I like.
So now my monthly "Telecommunications" bill looks like this:
- $74.95 for ADSL through netspace (50gb downloads)
- $5.00 per month contract with PennyTel (plus calls)
I now have a total bill of $80 / month and it’s only a $5 / month saving, however I do get more downloads and I don’t feel like I’m paying for something I’m not even using.
One of the things I struggle with is documentation. Jeff Atwood and Mike Pope both suggest that “if it’s not documented it doesn’t exist ” and I have to agree. Despite knowing how important good documentation is, it often gets put down the priorities list as deadlines approach. So recently I that enough was enough and decided to set aside a day to catch up on my documentation. My goal was to try and document the systems I had been working on recently and I figured that a day would be plenty.Â
I fired up our documentation wiki and was all ready to write down everything I knew about the systems but after an hour I’d achieved very little. After 2 hours I’d deleted everything and wanted to start again.
I couldn’t understand what the problem was. I had a hand in designing and writing the systems so I knew plenty about them. I’d been working on the systems up until the previous day so the code was still fresh in my mind. I generally don’t have too much difficulty trying to articulate what I want to say and yet I was struggling to put into words anything that I felt would be any help to anyone.
I thought if I just sat down and made a conscious effort to write documentation the rest would be easy. Turns out I was wrong. Maybe the reason I’ve been lax about documentation in the past wasn’t because I didn’t like it, but maybe it’s because it’s just damn hard.
After some contemplation I realised that I hadn’t put any planning into what I wanted to document so I came up with these rough guidelines:
- Identify your target audience. You may find that you need to write different documents to appeal to different audiences. Developers will need different information to BA’s. Trying to make your documentation appeal to everyone will end up in a document that isn’t very useful to anyone.
- Work out a rough structure before you start. Try and spend 10 minutes working out a rough outline of what you want to include in your documentation. Doing this will help you structure your thoughts as you’re writing.
- You’re final document can be as big as you want but try to keep each section within the document small and relevant. Try not to include details that are irrelevant.
- Identify what parts of the documentation are most important and focus on those first.
- Get someone from your to look over what you’ve written to make sure it makes sense to them. The documentation is every bit as much for them as it is for you
- Isolate yourself. Turn of email, unplug your phone, whatever. Just avoid yourself getting distracted as you’re going to need every bit as much mental concentration to write your documentation as you did to write the systems you’re documenting.
I strongly believe that developers should be responsible for writing their own documentation too. Who better to write the documentation for the system than the person who created it?
I downloaded and installed RescueTime recently after reading about it on Tim Ferriss’ blog.
It’s a neat little application that keeps track of where you’re spending your time on your computer. It’s important to me that I know where I’m spending my time but the only way to be able to analyse where my time is going is by collection hard evidence. Since installing the personal version of RescueTime I’m already noticing that I’m actively thinking a lot more about where I can spend my time productively, so from that perspective, it’s a win. It has also highlighted that there’s a lot of time during my day where I’m literally just wasting time in front of the screen. I’ve found myself become more and more aware of it and now, instead of just burning more screen time, I’m more inclined to stop and either get back to doing something productive or take myself away from the computer completely to stop myself going stale.
I’m only using the personal version at the moment but it’s chock full of features including detailed stats of where you’re using your time, the ability to set goals and alerts and to track stats from multiple computers.
I also really like how polished the application is. It doesn’t have any bells and whistles in terms of UI, but it seems to me like the team has spent a lot of time focusing on the core features of RescueTime and making sure they work well.
If you’d like to see where your time is going on your computer, I’d thoroughly recommend RescueTime.
I had an interesting email discussion with a colleague about how interfaces should be used in our codebase the other day and it made me think about the role of interfaces in code. To give a bit of background information I’m a big fan of interfaces and like to use them wherever it makes sense. The question my colleague and I were having was about how I have a tendancy to define an interface even though there is only a single implementation of the interface.
My first response was that it allowed classes to be de-coupled from each other as per the Dependency Invesion principle which states you should depend on abstractions rather than concrete implementations. Despite being perfectly valid, I felt it was a little weak if that was the only reason.
Thinking about it a little longer I realised that the most common usage for an interface was when you needed to have multiple custom implementations of an object that could be used in common scenarios. For example you might have an IEmployee object that would be implemented by multiple employee classes. This had gradually evolved into a design mindset that encourages people to only use interfaces when there is an immediate need for multiple implementations of a common object. The danger with this mindset is that people tend to forget that an interface is nothing more than a contract for implementers. It does not imply that it is a contract that will be implemented by more than one class.
Karl Seguin’s article on interfaces words it nicely:
The role of an interface is to define the contract that implementers must follow
Nothing more, nothing less. It’s just a contract. Just because you are only implementing the contract once now, doesn’t mean that you should do away with the interface. In fact, providing interfaces for single implementations of classes may well save you time in the future because if you have to re-implement the class, having an interface means you’ll know in advance exactly what needs to be implemented.
In any case, don’t be afraid to use interfaces to define contracts even if you only have a single initial implementation.
I had and interesting experience with the Linq Min method today. I got an error in production saying
System.InvalidOperationException: Sequence contains no elements at System.Linq.Enumerable.Min[TSource](IEnumerable`1 source)
It was produced by this line of code:
DateTime minDate = parcels.Min(p => p.StartDate)
I have to admit I was a little taken aback by this error because it’s a fairly innocent looking line of code. But upon further consideration it’s actually a fairly dangerous line of code. If you have a parcels collection that has no elements, you can get yourself into some pretty serious trouble and the Min function will throw the System.InvalidOperationException. At first glance you might think that if there are no parcels in the collection it should just return null, however if you think about it, this isn’t the correct behaviour because null isn’t a valid value for something that is supposed to be a “minimum”.
The answer of course is to check that the collection does have one or more elements before you call the Min function however it was an interesting look at how dangerous making assumptions can be when working with what looks like trivial code.
