Just got back from Code Camp Oz. I fear my journey to the "geek" side is now fully complete.
Had a great time, met some more of my fellow Readify colleagues. It's always good to be able to put a face to the emails and blogs.
I attended most of the seminars.... (couldn't quite bring myself to get to the VB.net talks...... I feel I've done enough VB6 and VBA in the past that if anybody really wanted me to do some VB.Net I could quite easily wing it). There were 2 talks that had me very interested, both on one of my pet topics...... performance. It's good to see that the developer community is taking performance seriously.
Other talks were also very good, and I think given the circumstances, all the speakers did a really good job. Murphy's law always holds true for demonstrations, worship of the demo Gods sometimes helps, but when you're using beta software, sometimes even the demo Gods give up and go home.
Thanks to all those who organised it, it was well worth giving up a weekend for.
Monday, April 25, 2005
Friday, March 11, 2005
My new laptop
Please forgive the self indulgence, but I thought I'd just post a picture of my new laptop. It's not every day you get a new baby.
For those interested it's an ASUS M6N PM1.8/1Gb/15.4"/80Gb
For those interested it's an ASUS M6N PM1.8/1Gb/15.4"/80Gb
Sunday, March 06, 2005
The performance question
Recently there has been a lively discussion amongst my work collegues at Readify about performance, sparked by a blog article by Rico Mariani. There have been some very interesting points made, but it has prompted me to think about performance. The random thoughts I want to share here, (I am a little too insecure to post my extremely humble (and slightly off topic) opinion to my collegues at Readify), is that dispite all the promises of the computer industry backed up by Moore's Law, in every "serious" project I have been involved in, performance has been a big issue.
At first I put it down to the fact that I was working with Palm OS, and Pocket PC devices and obviuously on memory constrained devices you have to be very careful, but in my current gig, we're writing a PC applicatoin and there are serious concerns about the performance of the system under regular use.
I think that the converse to Moore's Law is that the more powerful we build computers the more ways we find of using that extra power to the point that we are not really much further ahead than we were when computers were slower.
Example, in my previous job, we developed a Pocket PC application which essentially was just a re-write of a Palm OS application we wrote 3 years prior. The PPC app requires a Pocket PC 2002 with 32 Meg of RAM and a 200 MHz processor, and still runs quite slow, where as the Palm Os application was targeted at a Palm OS 3.1 device with 2 Meg of memory and an 8 Mhz processor... and it ran quite fast.
Saturday, February 26, 2005
Unit testing private methods using reflection
Don't know how many other people have come across this problem, but a couple of days ago I was writing a class in C# and I decided I wanted a private method to perform some functionality. I knew the private method would contain some non-trivial logic, but didn't want to expose it to other classes that other developers were working on. I decided that the logic within the method was serious enough to warrant some unit tests, but how could I unit test considering the method was private. Normally I would make the argument that as long as I tested the public interface correctly, then I should be fine, however, I had a suspicion that this time was different, so I sought the advice of my fellow Readify colleagues, and the ever brilliant Mitch Denny came to the rescue with some sample code that used .net reflection to call into the private method.
or in my case more along the lines of
as this was a static private method.
This worked a treat and I very quickly discovered the reason that I'd suspected I should go the extra mile and create this unit test. The very first time I ran my unit tests with just the most basic tests in place, I discovered one of those "doh" type bugs. Had I been attempting to just test the public interface, because there was considerable complexity in the public method that was using this private method I would have been looking in the wrong place for ages trying to debug the public interface, stepping into each line etc..., but because I'd spent 15 minutes setting up the unit test, when I did finally write the unit test for the public method, it worked first time.
Question: So when should you go to the extra effort of using reflection to unit test a private method?
Answer: When the private method contains non-trivial logic, and writing tests for the public interface won't make it obvious what's really happening or you won't be able to get decent code coverage from the public interface tests. There may be other times as well, but this is the rule I'm going to stick to for now.
TestVictim victim = new TestVictim();
Type victimType = typeof(TestVictim);
MethodInfo method =
victimType.GetMethod("PrivateMethodName",
BindingFlags.NonPublic BindingFlags.Instance); //pass parameters in an object array
method.Invoke(victim, . . . .); or in my case more along the lines of
Type victimType = typeof(VictimClass);
MethodInfo =
victimType.GetMethod("PrivateMethodName",
BindingFlags.NonPublic BindingFlags.Static); //pass parameters in an object array
method.Invoke(null, . . . .);
as this was a static private method.
This worked a treat and I very quickly discovered the reason that I'd suspected I should go the extra mile and create this unit test. The very first time I ran my unit tests with just the most basic tests in place, I discovered one of those "doh" type bugs. Had I been attempting to just test the public interface, because there was considerable complexity in the public method that was using this private method I would have been looking in the wrong place for ages trying to debug the public interface, stepping into each line etc..., but because I'd spent 15 minutes setting up the unit test, when I did finally write the unit test for the public method, it worked first time.
Question: So when should you go to the extra effort of using reflection to unit test a private method?
Answer: When the private method contains non-trivial logic, and writing tests for the public interface won't make it obvious what's really happening or you won't be able to get decent code coverage from the public interface tests. There may be other times as well, but this is the rule I'm going to stick to for now.
Wednesday, February 09, 2005
Peer Code Reviews - 2
In my previous article on Peer code reviews I mentioned I didn't like the idea of insisting on a code review before checking into source safe. Well, I still don't like it, but I have discovered one reason which supports the idea.
If developers are left to code and check in/check out as much as they like, and are only required to have a code review before a periodic label, then it becomes tempting to write large chunks of code before getting a code review. now if a reviewer, by definition another developer, is asked to review pages and pages of code, then as the reviewer is also undoubtedly a busy person, they will simlpy use the page down key to scan over vast amounts of code and not really look for anything in particular as to look intently at each peice of code requires significant effort. I guess the conclusion is review early, review often. However, I still believe that there should be very few barriers to checking in building code.
If developers are left to code and check in/check out as much as they like, and are only required to have a code review before a periodic label, then it becomes tempting to write large chunks of code before getting a code review. now if a reviewer, by definition another developer, is asked to review pages and pages of code, then as the reviewer is also undoubtedly a busy person, they will simlpy use the page down key to scan over vast amounts of code and not really look for anything in particular as to look intently at each peice of code requires significant effort. I guess the conclusion is review early, review often. However, I still believe that there should be very few barriers to checking in building code.
Wednesday, February 02, 2005
Peer Code Reviews
Even though I have had 8 years experience in the IT industry, it may or may not surprise you to know that until my current job I have never had a formal peer code review. In the past the only times that a peer has looked at my code has been in a very informal way, and not really looking for the kind of things that should be looked for in a proper peer code review. So as you might guess, I was a little nervous when faced with the prospect of a peer code review, however, I am now completely sold on the idea.
I believe there are 2 elements that make code reviews invaluable to good code production. Firstly, the reviewer has a different perspective on the code. The reviewer is someone with different experiences, and as they are not in the thick of the coding, have time to relax and view the code in a more objective way than the creator of the code. They are not subject to the same line of logic that the coder has gone through to produce the code, so if the coder has written something a certain way after a string of incorrect or sub-optimal logic, the reviewer is free to question the logic, or propose a better way of implementing an algorithm, and the coder then is forced to either justify his logic by tracing through his steps, validating his decisions at each point, or accept the better way and re-code accordingly. The reviewer can also check for consistency with the accepted coding standards, and if the coding standards are good, better adherence will result in more readable, more maintainable code.
The second element is the psychological factor. As a developer, if I know my code is going to be reviewed, I will be very careful to adhere to the accepted coding standards and I will make sure that my code is set out in such a way that it is easy for another person to read. I will also validate my logic, imagining how I will explain complex bits of code to my potential reviewer. And finally I will do a once over of my code before I ask someone to review it, tidying everything up, making sure the review process will go smoothly and there will be no serious issues that the reviewer could potentially pull me up on.
All this doesn’t guarantee bug free code, in fact, the purpose of a code review is not to replace a proper QA process, but it creates an opportunity to catch obvious coding errors that would have otherwise come up in the QA process, and would have extended the whole phase unnecessarily. As the QA cycle is always the largest unknown of any software project, anything that can potentially decrease this phase has to be a good thing.
The only thing I don’t quite agree with is the way in which they use their source control in conjunction with the peer code reviews. Their idea is that there should not be a single line of code under source control that has not been reviewed. This creates an obstacle to checking in regularly. My personal opinion is that there should be very few obstacles to checking in modified source code. At my last work the rules I instated were just the obvious two; only check-in if the project is building (ie don’t break the build), and check-in regularly (usually before you go home at night). I always get nervous if source files are checked out for too long, there are obvious problems that can occur. The issue is that to avoid large amounts of small code reviews developers will wait for multiple days until they have some serious code to review. I think that all though the concept is noble, maybe a similar concept could be achieved by having some simple processes around labeling (or tagging depending on the notation of your source control), that can be administered by the release manager. I'll have to see how the process goes over the next few months, and see if my opinion changes with respects to their source control methodology. One things for sure I'm a convert to peer code reviews.
I believe there are 2 elements that make code reviews invaluable to good code production. Firstly, the reviewer has a different perspective on the code. The reviewer is someone with different experiences, and as they are not in the thick of the coding, have time to relax and view the code in a more objective way than the creator of the code. They are not subject to the same line of logic that the coder has gone through to produce the code, so if the coder has written something a certain way after a string of incorrect or sub-optimal logic, the reviewer is free to question the logic, or propose a better way of implementing an algorithm, and the coder then is forced to either justify his logic by tracing through his steps, validating his decisions at each point, or accept the better way and re-code accordingly. The reviewer can also check for consistency with the accepted coding standards, and if the coding standards are good, better adherence will result in more readable, more maintainable code.
The second element is the psychological factor. As a developer, if I know my code is going to be reviewed, I will be very careful to adhere to the accepted coding standards and I will make sure that my code is set out in such a way that it is easy for another person to read. I will also validate my logic, imagining how I will explain complex bits of code to my potential reviewer. And finally I will do a once over of my code before I ask someone to review it, tidying everything up, making sure the review process will go smoothly and there will be no serious issues that the reviewer could potentially pull me up on.
All this doesn’t guarantee bug free code, in fact, the purpose of a code review is not to replace a proper QA process, but it creates an opportunity to catch obvious coding errors that would have otherwise come up in the QA process, and would have extended the whole phase unnecessarily. As the QA cycle is always the largest unknown of any software project, anything that can potentially decrease this phase has to be a good thing.
The only thing I don’t quite agree with is the way in which they use their source control in conjunction with the peer code reviews. Their idea is that there should not be a single line of code under source control that has not been reviewed. This creates an obstacle to checking in regularly. My personal opinion is that there should be very few obstacles to checking in modified source code. At my last work the rules I instated were just the obvious two; only check-in if the project is building (ie don’t break the build), and check-in regularly (usually before you go home at night). I always get nervous if source files are checked out for too long, there are obvious problems that can occur. The issue is that to avoid large amounts of small code reviews developers will wait for multiple days until they have some serious code to review. I think that all though the concept is noble, maybe a similar concept could be achieved by having some simple processes around labeling (or tagging depending on the notation of your source control), that can be administered by the release manager. I'll have to see how the process goes over the next few months, and see if my opinion changes with respects to their source control methodology. One things for sure I'm a convert to peer code reviews.
Thursday, January 27, 2005
Back to work
If anyone is wondering why I haven't updated updated in ages, it's because I've been on holidays for a couple of months. My adventures can be read on my other blog.
I have now started a completely new job. I am contracting to a company called Readify who are on-selling my skills to a company called QSR. So far the job seems really exciting, QSR are very highly organised, and everyone seems quite friendly. I feel I am going to learn a lot of invaluable lessons about software management.
I have now started a completely new job. I am contracting to a company called Readify who are on-selling my skills to a company called QSR. So far the job seems really exciting, QSR are very highly organised, and everyone seems quite friendly. I feel I am going to learn a lot of invaluable lessons about software management.
Wednesday, November 24, 2004
Service Station: Run ASMX Without IIS -- MSDN Magazine, December 2004
Service Station: Run ASMX Without IIS -- MSDN Magazine, December 2004
Always wanted to know how to do this.
Always wanted to know how to do this.
Monday, November 22, 2004
Mobility: Optimize Your Pocket PC Development with the .NET Compact Framework -- MSDN Magazine, December 2004
I wish this article had been written before we plunged headlong into a Pocket PC project, and found out most of this stuff the hard way. It would have saved a lot of time.
Mobility: Optimize Your Pocket PC Development with the .NET Compact Framework -- MSDN Magazine, December 2004
Mobility: Optimize Your Pocket PC Development with the .NET Compact Framework -- MSDN Magazine, December 2004
Friday, November 05, 2004
subversion.tigris.org
I have just recently downloaded and installed Subversion (version control sfotware) for my own personal use at home, and I must say, I'm a convert. These guys have done a fantastic job.
Couple this with TortiseSVN and you have a winning combination.
Couple this with TortiseSVN and you have a winning combination.
Wednesday, October 27, 2004
mdnug .net CF special
Last nights mdnug was on the .Net Compact Framework with key note speaker Jonathan Wells, and as a Pocket PC developer with experience in this field, I was very interest. Probably the best thing to come out of the night was hints on speed improvements that can be made by knowing how garbage collection works in the .Net Compact Framework. Below is an article that describes this behaviour pretty well.
An Overview of the .Net Compact Framework Garbage Collector
An Overview of the .Net Compact Framework Garbage Collector
Monday, October 25, 2004
Pocket-Sized Design: Taking Your Website to the Small Screen: A List Apart
This has been one of my gripes for a long time, and I'm glad there's someone out there spreading the word about how to make "small footprint" html pages. Thanks Elika.
Pocket-Sized Design: Taking Your Website to the Small Screen: A List Apart
Pocket-Sized Design: Taking Your Website to the Small Screen: A List Apart
Beta tests, a double edged sword
A lot of software companies have a beta test phase for their software before they go to commercial release. It appears to me that there are 2 main reasons companies release beta's of their software.
Firstly the desire to make the product more stable in the real world by getting people in the real world, (not QA staff back in the controlled test environment), to use the software in a way that as close as possible resembles the way in which the software will be used when it is released commercially. This is very valuable, I have seen so many times bugs turn up in real world situations that no matter how much testing you get internal QA staff to do, you would be highly unlikely to see back at the office.
The second reason is to get public exposure of the software before the release date. The idea is to create a certain amount of excitement about the impending release of the product, get potential end users to start using the software for a limited trial period, let them see the benefits that the software will offer, and hopefully have a list of potential customers at the end of the beta phase that are ready to fork out money for the product when it is released.
It is possible that these 2 objectives can easily conflict with each other. By that I mean if you release a beta that has a lot of bugs, then the excitement you are trying to generate will be offset by the mistrust in the minds of the beta testing community that you as are not capable of delivering stable software. On the other hand, if you delay your beta test until the software is perfect, than having a 30 day beta cycle that returns very few bugs is just going to delay getting the commercial release out and consequently delay getting returns on your investment.
A balance needs to be struck and I think there are a few simple rules that need to be followed to ensure that you get the most out of your beta test phase.
1. Beta testing does NOT replace a good internal quality assurance process. Anyone not convinced of the value of a good QA process needs to read Joel Spolsky's rant on testing. My thoughts on the subject are that before a beta goes out, there should be a series of tests that ensure the software is suitable for public consumption. Basic things like it installs and uninstalls fine on targeted systems, There are no serious bugs in the day to day expected use of the software, obvious spelling and grammatical errors will reflect poorly on your companies professionalism, etc... The exact requirements will vary depending on what type of software you're releasing, and the target market.
2. The Beta test phase should be well managed. Someone, ideally from the QA team, should be made the single point of contact for all beta testers, and there should be some kind of forum for beta testers to develop a relationship with this person, say a blog for instance. beta testers should be encouraged to use this blog for reporting bugs, giving feedback, asking question etc.... This should be a place where the person in charge of the process is actively answering questions, dealing with issues, thanking people for input and generally presenting a human face to the whole process.
3. Issues need to be resolved quickly. If there are any serious issues, they need to be dealt with as fast as possible, and a new beta posted within days of the issue being reported. I don't think I need to explain the importance of this rule, it I obvious that perception is everything.
4. Beta testers should be rewarded. These people are essentially doing free work for you, there should be some sort of incentive at the end to show gratitude for there commitment. I would suggest a small discount on the final product would be adequate incentive, and would encourage beta testers to sign up for the next beta process.
5. The beta test needs to be of a pre-determined length. I would say aim at between a 30 and 60 day beta phase, if you go on too long then you lose some of the initial excitement you created when you started the beta test phase. There are exceptions to this rule, and it depends on the size of the application you're developing, and the size of the beta test community, and also if one of your objectives is to get customer feedback about what features they want, then 60 days will probably be too short a time to get that feedback, feed it back through the relevant channels and back into the development cycle.
Beta tests can achieve the goals of creating more reliable software as well as a community of people excited about your software, however, it can also create a distrust of your software and your company if the process is not managed correctly.
Firstly the desire to make the product more stable in the real world by getting people in the real world, (not QA staff back in the controlled test environment), to use the software in a way that as close as possible resembles the way in which the software will be used when it is released commercially. This is very valuable, I have seen so many times bugs turn up in real world situations that no matter how much testing you get internal QA staff to do, you would be highly unlikely to see back at the office.
The second reason is to get public exposure of the software before the release date. The idea is to create a certain amount of excitement about the impending release of the product, get potential end users to start using the software for a limited trial period, let them see the benefits that the software will offer, and hopefully have a list of potential customers at the end of the beta phase that are ready to fork out money for the product when it is released.
It is possible that these 2 objectives can easily conflict with each other. By that I mean if you release a beta that has a lot of bugs, then the excitement you are trying to generate will be offset by the mistrust in the minds of the beta testing community that you as are not capable of delivering stable software. On the other hand, if you delay your beta test until the software is perfect, than having a 30 day beta cycle that returns very few bugs is just going to delay getting the commercial release out and consequently delay getting returns on your investment.
A balance needs to be struck and I think there are a few simple rules that need to be followed to ensure that you get the most out of your beta test phase.
1. Beta testing does NOT replace a good internal quality assurance process. Anyone not convinced of the value of a good QA process needs to read Joel Spolsky's rant on testing. My thoughts on the subject are that before a beta goes out, there should be a series of tests that ensure the software is suitable for public consumption. Basic things like it installs and uninstalls fine on targeted systems, There are no serious bugs in the day to day expected use of the software, obvious spelling and grammatical errors will reflect poorly on your companies professionalism, etc... The exact requirements will vary depending on what type of software you're releasing, and the target market.
2. The Beta test phase should be well managed. Someone, ideally from the QA team, should be made the single point of contact for all beta testers, and there should be some kind of forum for beta testers to develop a relationship with this person, say a blog for instance. beta testers should be encouraged to use this blog for reporting bugs, giving feedback, asking question etc.... This should be a place where the person in charge of the process is actively answering questions, dealing with issues, thanking people for input and generally presenting a human face to the whole process.
3. Issues need to be resolved quickly. If there are any serious issues, they need to be dealt with as fast as possible, and a new beta posted within days of the issue being reported. I don't think I need to explain the importance of this rule, it I obvious that perception is everything.
4. Beta testers should be rewarded. These people are essentially doing free work for you, there should be some sort of incentive at the end to show gratitude for there commitment. I would suggest a small discount on the final product would be adequate incentive, and would encourage beta testers to sign up for the next beta process.
5. The beta test needs to be of a pre-determined length. I would say aim at between a 30 and 60 day beta phase, if you go on too long then you lose some of the initial excitement you created when you started the beta test phase. There are exceptions to this rule, and it depends on the size of the application you're developing, and the size of the beta test community, and also if one of your objectives is to get customer feedback about what features they want, then 60 days will probably be too short a time to get that feedback, feed it back through the relevant channels and back into the development cycle.
Beta tests can achieve the goals of creating more reliable software as well as a community of people excited about your software, however, it can also create a distrust of your software and your company if the process is not managed correctly.
Tuesday, October 19, 2004
Post a message to a non-.Net window
For anyone who is interested, this is how you Post a message to a window from .net (C#). You can always pass in null for either the calssName or windowName if you don't wish to use them to find the window.
using System;
using System.Runtime.InteropServices;
namespace WinUtilities
{
class WinUtil
{
public static int PostMsg(string className, string windowName, int wMsg, int wParam, int lParam)
{
int hWnd = FindWindow(className, windowName);
int nRet = 0;
if (hWnd != 0)
{
nRet = PostMessageA(hWnd, wMsg, wParam, lParam);
}
return nRet;
}
[DllImport("user32", EntryPoint="PostMessage")]
public static extern int PostMessageA(int hwnd, int wMsg, int wParam, int lParam);
[DllImport("user32.dll",EntryPoint="FindWindow")]
private static extern int FindWindow(string _ClassName, string _WindowName);
}
}
A useful interop resource is PInvoke
using System;
using System.Runtime.InteropServices;
namespace WinUtilities
{
class WinUtil
{
public static int PostMsg(string className, string windowName, int wMsg, int wParam, int lParam)
{
int hWnd = FindWindow(className, windowName);
int nRet = 0;
if (hWnd != 0)
{
nRet = PostMessageA(hWnd, wMsg, wParam, lParam);
}
return nRet;
}
[DllImport("user32", EntryPoint="PostMessage")]
public static extern int PostMessageA(int hwnd, int wMsg, int wParam, int lParam);
[DllImport("user32.dll",EntryPoint="FindWindow")]
private static extern int FindWindow(string _ClassName, string _WindowName);
}
}
A useful interop resource is PInvoke
Monday, October 18, 2004
Mobile and Embedded Developer Center: Architecting Disconnected Mobile Applications Using a Service Oriented Architecture
This sounds ineteresting, will give it a proper read when I get a chance.
Mobile and Embedded Developer Center: Architecting Disconnected Mobile Applications Using a Service Oriented Architecture
Mobile and Embedded Developer Center: Architecting Disconnected Mobile Applications Using a Service Oriented Architecture
Friday, October 15, 2004
Tracing the Evolution of Social Software
Very interesting article on the history of social software.
Life With Alacrity: Tracing the Evolution of Social Software
Life With Alacrity: Tracing the Evolution of Social Software
Tuesday, September 21, 2004
Friday, August 20, 2004
xml
xml blog article
Not being an XML guru, I was a little nervous holding my opinion that "XML is just CSV on steroids", but there are people who know a hell of a lot more about it than I do who vindicate my viewpoint.
Another gripe I have with XML (coming from a background in memory constrained devices and all) is it's blatant inefficiency, but anyone developing on PC's won't really know what I'm talking about.
Not being an XML guru, I was a little nervous holding my opinion that "XML is just CSV on steroids", but there are people who know a hell of a lot more about it than I do who vindicate my viewpoint.
Another gripe I have with XML (coming from a background in memory constrained devices and all) is it's blatant inefficiency, but anyone developing on PC's won't really know what I'm talking about.
Wednesday, August 04, 2004
ASP TreeView, Slide Menu - obout.com - .NET TreeView, SlideMenu
ASP TreeView, Slide Menu - obout.com - .NET TreeView, SlideMenu
Link to some interesting asp.net controls
Link to some interesting asp.net controls
Subscribe to:
Posts (Atom)
Posts
