Service Station: Run ASMX Without IIS -- MSDN Magazine, December 2004
Always wanted to know how to do this.
Wednesday, November 24, 2004
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
Wednesday, June 23, 2004
mdnug
Yes I have done it...... I have drunk from the cup of Microsoft, I am tainted for the rest of my life.
Ok..... I went to the Melbourne Dot net User Group and ate Pizza and drank softdrink supplied by microsoft.
all in all, it was a good meeting, an interesting discussion on code refactoring, and a good preview of things to come in VS 2005.
I am always amazed at how much money microsoft is willing to throw at developers, I guess it's been their way since the beginning.
Ok..... I went to the Melbourne Dot net User Group and ate Pizza and drank softdrink supplied by microsoft.
all in all, it was a good meeting, an interesting discussion on code refactoring, and a good preview of things to come in VS 2005.
I am always amazed at how much money microsoft is willing to throw at developers, I guess it's been their way since the beginning.
Tuesday, June 01, 2004
327507 - FIX: "Access to the Registry Key Denied" Error Message When You Register .NET Assembly for COM Interop
327507 - FIX: "Access to the Registry Key Denied" Error Message When You Register .NET Assembly for COM Interop
After searching aimlessly with google, and numerous postings on relevant newsgroups, and after substantial loss of hair, I found the solution to my problems installing the smartphone 2003 SDK. As google searches initially gave me no results for the keywords I was typing, I am posting this with the keywords I thought would find the answer in the vain hope that someone else who has the same problem and types in something vaguely similar finds the answer they are looking for.
keywords:
Problems installing smartphone 2003 SDK regasm
After searching aimlessly with google, and numerous postings on relevant newsgroups, and after substantial loss of hair, I found the solution to my problems installing the smartphone 2003 SDK. As google searches initially gave me no results for the keywords I was typing, I am posting this with the keywords I thought would find the answer in the vain hope that someone else who has the same problem and types in something vaguely similar finds the answer they are looking for.
keywords:
Problems installing smartphone 2003 SDK regasm
Saturday, May 29, 2004
.NET Developer's Journal
.NET Developer's Journal
Interesting article on Developing for Pocket PC using the .NET Compact Framework.
Interesting article on Developing for Pocket PC using the .NET Compact Framework.
Tuesday, May 25, 2004
Scott's winge
I have to admit, I have found connecting to progress using JDBC or ODBC to be unbelievably unstable. The amount of times I've had to code around inadequacies in either the ODBC driver or JDBC driver, makes it almost unusable, and certainly negates the purpose of using ODBC or JDBC (ie able to connect to a different data source without re-writing code).
I guess that Progress was meant to be used with their own 4GL, anything else is a hack.... Use it at your own risk.
I guess that Progress was meant to be used with their own 4GL, anything else is a hack.... Use it at your own risk.
Sunday, May 23, 2004
Luke's Blog
Luke Drumm
Here is a reference to the BLOG of one Luke Drumm. A .Net guru who has been working with us on the Pocket PC / smart phone version of our software for the past 3 weeks.
Enjoy.
Here is a reference to the BLOG of one Luke Drumm. A .Net guru who has been working with us on the Pocket PC / smart phone version of our software for the past 3 weeks.
Enjoy.
Introduction
Hi, if you've stumbled across this blog, I guess I'd better give you a quick run down of what the hell you're in for.
My name is Scott Baldwin, I am a software developer, but don't hold that against me.
I have been in software for 8 years now, but my interests extend far beyond software. I am becoming more and more politically active as you may see from my other blog "Musings of a morbid mind". My main passion is Argentinean Tango, and I attend the Viva Dance school, (I am also their webmaster).
I have a genuine interest in technology, and ethics, and as such (don't worry if you can't see the link, it's not obvious) I have recently started to delve into the interesting field of Anthropology.
I hope you enjoy some of my postings, and I look forward to your feedback.
My name is Scott Baldwin, I am a software developer, but don't hold that against me.
I have been in software for 8 years now, but my interests extend far beyond software. I am becoming more and more politically active as you may see from my other blog "Musings of a morbid mind". My main passion is Argentinean Tango, and I attend the Viva Dance school, (I am also their webmaster).
I have a genuine interest in technology, and ethics, and as such (don't worry if you can't see the link, it's not obvious) I have recently started to delve into the interesting field of Anthropology.
I hope you enjoy some of my postings, and I look forward to your feedback.
Subscribe to:
Posts (Atom)
Posts
