Wednesday, June 30, 2004
Congratulations to Dave and Lexi on their recent marriage. Melanie and I are looking forward to the reception in October.
posted by Kirby Turner | June 30 11:11 AM | comments (0)Tuesday, June 29, 2004
"This is a warning for any creator of computer programs: that software quality matters, that applications must be foolproof, and that-whether embedded in the engine of a car, a robotic arm in a factory or a healing device in a hospital-poorly deployed code can kill."
This quote comes from an article my friend Matt pointed to me from Base Line Magazine titled Why Software Quality Matters.
This article really illustrates the importance of software quality. As more software is used in the daily lives of people the importance of quality software increases. Recently I read in Consumer Reports that a particular model of luxury car is being recalled due to a problem related to a transmission controller chip. The software in this chip can cause the car moving forward to shift into reverse. Imagine the pileup that could be caused by a car suddenly shifting into reverse as it and other drivers speed down the NJ Turnpike during rush hour.
Many programmers like me can and have argued that our business applications pose no threat to human life. But does this mean we can set quality levels for our work to a lower standard? Does it mean we can intentionally deploy poorly written applications? I say absolutely not! Software developers must start accepting the responsibility of writing high quality code and they should be held accountable for any code not adhering to a high standard of quality.
Friday, June 25, 2004
I was a grumbling VB developer for a number of years. At the time Delphi was my language of choice but in the part of the country I lived customer work using it was almost non-existent. In the summer of 2000 at PDC, a friend of mine from Microsoft showed me the .NET Framework and C#. I was instantly drawn to C# because it reminded me of Delphi, which is no surprise for those who know their C#/Delphi history.
At last there was [is] a language and framework from Microsoft that generated the same level of excitement in me that Borland's Delphi had done a few years prior. Best of all it was from Microsoft which would mean customer work in the future. And as luck would have it, I started working exclusively with the .NET Framework and C# in the fall of 2001.
For better or worse I have not spent much time with VB.NET, or Visual Basic 6.0 for that manner, since the fall of 2001. I have done a few small project using VB.NET but nothing to brag about. For the most part, both .NET languages are very similar with regard to features but there are some differences. For example, you can write unsafe code in C# but you can't do the same in VB.NET. Depending on your point of view this is an advantage or a disadvantage.
Another difference is that in VB.NET you can specify the scope of a member that implements a particular interface as something other than public. I needed to do this in more than one occasion in C# but was resolved to the fact that a member implementation of interface in C# had to be scoped as public.
Public Interface IMyInterface
Sub Foo()
End Interface
Public Class Class1
Implements IMyInterface
Private Sub Foo() Implements IMyInterface.Foo
End Sub
End Class
So if you can do this in VB.NET why can't you do the same, or something similar in C#? This question lead me to the discovery (thank you google) of explicit interface implementation in C#. By using an explicit interface implementation you can scope the member implementation as private. It's a little messy because a member explicitly implemented cannot be access through the class instance. Instead it must be accessed through an instance of the interface.
interface IMyInterface
{
void Foo();
}
abstract class MyAbstractClass : IMyInterface
{
// Explicit interface implementation
void IMyInterface.Foo()
{
Console.WriteLine( "bar" );
}
}
class MyConcreteClass : MyAbstractClass
{
public void FooBar()
{
// Must use an instance of the interface to access
// the explicit implementation.
((IMyInterface)this).Foo();
}
}
public class MyApp
{
public static void Main( string[] args )
{
MyConcreteClass c = new MyConcreteClass();
// Will not compile because Foo() is private.
// c.Foo();
c.FooBar();
// This works because we are all in the same module.
((IMyInterface)c).Foo();
}
}
While an explicit interface implementation does give the C# developer the ability to scope a member implementation as private, it is still not as powerful as VB.NET's ability to scope a member implementation as anything other than public. Score 1 point for VB.NET. posted by Kirby Turner | June 25 08:22 AM | comments (0)
Thursday, June 24, 2004
Over the last month a lot of my time has been spent focusing on security as I design a security framework and strategy for a customer. One comment I hear often is "we don't need to worry about internal security threats" or "internal security threats are minor and represent a low priority". I couldn't disagree more and have been repeatedly emphasizing the importance of protecting ones assets from internal attacks, which for some companies is a greater threat.
Yesterday's report of an AOL software engineer being arrested for stealing 92 million customer screen names proves my point. Some people will do crazy things when offered enough money. And companies that believe "it won't happen here" or "our employees would never do such a thing" are fooling themselves. Why risk it? Invest in reducing security threats, both external and internal.
I thought Microsoft's patent on //TODO was silly but Microsoft's patent for using human skin as a power conduit tops it. Actually this patent sounds interesting. I can see how wearable devices can benefit from a personal area network.
posted by Kirby Turner | June 24 09:33 AM | comments (0)Saturday, June 19, 2004
My friend Phil was in town this week which means one thing. Time for BenZona to rock Luna Lounge. They had a great gig last night and it was good to see Phil, Keith and others again. We also stuck around to hear San Francisco based Candy From Strangers who I definitely got into.
Speaking of NYC visitors, my mom, brother Andy, and his son [my nephew] Lucas will be arriving in New York within a few hours. It will be Andy and Lucas's first time to the Big Apple. We have the next few days planned out to wear them out. From Central Park to Time Square to Coney Island to a Staten Island Yankees game, Melanie and I will definitely keep the family busy.
And the fun doesn't stop there. My good friend John from Cleveland by way of St. Louis will be in town too. Of course we will be meeting up for a drink or two. A week of catching up with friends and family. What could be better?
Thursday, June 17, 2004
For those new to Firefox, be sure to check out the list of extensions. They're easy to install and there are many helpful extensions that will improve your browsing experience. As a matter of fact, I'm using the BlogThis! extension right now to post this entry.
posted by Kirby Turner | June 17 04:13 PM | comments (0)While nothing really new, other than security updates has happened to IE in quite some time, Mozilla has continued work on its next generation web browser called Firefox. Firefox 0.9 is available for download and I feel it is a worth while download.
I have been running Firefox as my default browser for the last 24 hours. I really like tab browsing and how Firefox blocks pop-up windows. It works fine for almost all sites I visit including a Microsoft SharePoint Window Services 2.0 site that I use daily. I don't get the drop down command list on SharePoint documents like I would in IE but I'm still able to do everything I need with a document through the document design page.
My only complaint to date is when I attempt to open a link in a new window from SharpReader, the RSS aggregator I use. For some reason the web page is displayed in both a Firefox window and an IE window. I doubt this is the fault of SharpReader and is more the fault of the IE component used within SharpReader. In other words, I think the IE component is launching the additional IE window when Firefox is set as my default browser.
Aside from that one problem, I enjoy browsing with Firefox based on my 24 hour experience and will probably keep it as my default browser for a while.
I agree with Scott. Unit Testing support should be included with all versions of Visual Studio 2005 and not just with Team System. However, I am not sure I agree with the unit testing support using a new framework developed by Microsoft. NUnit is here today and works with all released versions of the .NET Framework. And I am sure support for version 2 of the .NET Framework will be included in NUnit once Microsoft has released it.
I doubt many of my customers will be ready to move to VS.NET 2005 and the .NET Framework 2.0 when it is released, but I will still be developing solutions for them. And I will continue to provide unit tests for custom written production code. So while I agree that all versions of Visual Studio.NET 2005 should include support for unit testing, I would like to see stronger support for NUnit and not some new testing framework. This will help ease the migration to the new tool and framework.
Wednesday, June 16, 2004
A friend pointed me to BindingPoint, which is an XML web services directory. I did a quick search on "snow report" and found my snow report web service. I checked out the service description that I setup in UDDI over a year ago and ran the quick test from BindingPoint. It brought back memories of my UDDI and Web services work I did last year. And I still think UDDI rocks!
Microsoft has published the latest Visual SourceSafe Roadmap, which outlines where VSS is heading with the release of Visual SourceSafe 2005. The new version will still be geared towards individual developers and small teams, i.e., teams with less than 5 developers but it will finally include remote access. I'm glad to see VSS is finally getting a much needed upgrade but I doubt the new release will convince me to switch back from CVS.
Apple's new AirPort Express sounds simply amazing. It can act as a wireless bridge, provides wireless access to USB printers, and play music broadcasted wirelessly from your computer. The device fits in the palm of your hand and it has a built-in AC adaptor meaning no cables or power supply. This little puppy will be great to take on the road too. You can connect it to the hotel's ethernet and access the Internet wirelessly. Or use it at the home of friends and family who have broadband Internet access but no wireless access point. I might have to buy one once Apple starts shipping it.
Saturday, June 12, 2004
Microsoft recently announced MSN Alerts for Xbox Live users. It works by linking your Messager account with your Xbox Live gametag. You can receive alerts for game invites, friend requests, know when friends sign in, and more. Sounds cool but unfortunately I use Trillian as my IM client.
Trillian is awesome in that it is a single IM chat interface for different IM services such as AIM, Messager, ICQ, and Yahoo. With Trillian I no longer need to run different IM programs. Instead I run one program and it communicates with the different services. The only beef I have with Trillian is the lack of support for MSN Alerts, but I'm sure that has more to do with Microsoft then with the Trillian folks. And as much as I like the concept of MSN Alerts I'm not going to give up Trillian.
Friday, June 11, 2004
Microsoft has created a patent on // TODO. Fortunately it only applies to software development environments so individuals can still produce their own TO-DO list for things such as grocery shopping.
posted by Kirby Turner | June 11 08:26 AM | comments (0)This is too funny. I would have never thought you could find such a detailed guide to Springfield USA.
posted by Kirby Turner | June 11 08:03 AM | comments (0)Thursday, June 10, 2004
Lately I have seen a handful of developers blog the list of tools they use so I've decided to do the same. Here are the ones that come to mind because I use them daily.
- Eudora Pro
- My e-mail reader of choice. I configure it for text base only so I don't have to worry about all the problems associated with HTML based readers.
- VS.NET 2003
- My primary development IDE. I've become a sucker for Intellisense.
- MultiEdit
- My text editor of choice and the tool I use to write small snippet code. My only compliant is the lack of Unicode support, which prevents me from selecting MultiEdit as my IDE of choice.
- CodeRush
- Enhances the VS.NET editor with templates and other useful features. Makes up for the fact that I don't use MultiEdit daily any more.
- NUnit
- I don't write a line of production code these days without first writing a unit test. NUnit has changed my programming life.
- TortoiseCVS
- I gave up on VSS long time ago and exclusive lock source control. CVS is a great repository and TortoiseCVS makes working with CVS repository a breeze.
- Reflector
- This tool allows me to review the internals of an assembly. The decompiler is great especially when working with generated code or trying to trouble shoot a problem with a 3rd party assembly.
- NAnt
- NAnt is an open source build tool that allows me to write build scripts in XML. I find that for more complex applications NAnt is much better for building applications then VS.NET. Plus, it can also send e-mails, retrieve latest source code from a repository, and more.
- WinCV
- WinCV is a class view for the .NET Framework and comes with the .NET Framework SDK. I use it to find all sorts of things about the framework and it's much faster then the MSDN documentation.
- Beyond Compare
- This is a great tool for comparing files or directory of files. It will even compare files on your local machine with an FTP server. And best of all it has merge and synch features.
- SQL Query Analyzer
- I know it is probably old skool but I still use the query analyzer for much of my SQL Server work.
- tcpTrace
- This tool from Simon Fell is a must have when you want to see what is going on the wire when calling a web service. And I can't imagine writing a SOAP extension without it.
- SharpReader
- I don't read blogs as often as I would like but when I do I use SharpReader.
- RoboCopy
- This is an unsupported tool from Microsoft that is a copy command on steroids. I use it daily to backup my laptop to an external hard drive.
Wednesday, June 09, 2004
I had an interesting chat with a team member today about which XML parsing API from the .NET Framework to use for a particular situation. He mentioned that using the XPathNavigator with an XmlReader would not load the document into memory. However, after some quick research I found this to be incorrect. XPathNavigator is different than XmlDocument in that it is optimized for XSLT processing and the XPath data model, but it is similar in that the entire document is read into memory. XPathNavigator appears to use a cursor-base model for traversing the document while XmlDocument uses a tree-base model.
The rule of thumb I have come up with is this: Read-only, forward-only XML parsing API tend to read from a stream and do not store the entire document in memory. Random access XML parsing API, which typically use a tree-base model or cursor-base model, will traverse in-memory the XML document which means this entire document is stored in memory.
Tuesday, June 08, 2004
I have been using NUnit since its early days but it has only been in the last six months that I have made the move to test driven development. TDD is concept of writing production code based on unit test cases that are written first. And using a framework such as NUnit enables the developer to write automated unit tests that will test the features of an application at a functional level thus encouraging test driven development.
TDD is a paradigm switch for many developers as it was for me. Sure I have been unit testing my code for years. I would employ techniques such as console applications, shell programs, and other types of test harnesses to test the functions of my code. But until recently I never
started the development of a module by writing unit tests first.
Test driven development is an investment up front in the quality of your code. That investment is in the form of the unit tests before production code. Many developers today write the production code first (after the design phase of course), followed by commenting the code, then followed by testing the code. And in many cases the later work of commenting and testing never happens because bug fixes become the developer's top priority. But by investing in the quality of the code at the start developers will find that bugs are reduced, the classes and functions of the code are better designed, and over all quality of the work is greatly improved. Best of all, refactoring code becomes less of a risk with TDD because recursion testing at the unit level is possible.
Here are some tip I would like to share that will hopefully help you make the move to test driven development:
- Just do it. Force yourself to write your unit test first. Over time the quality of the unit test will improve, writing unit test will be easier, and it will because almost second nature for you to start with a unit test.
- When testing data changes to a database, start a transaction in the SetUp of the unit test and roll back the transaction in the TearDown. This provides an easy way to clean up the data after each unit test.
- Writing a unit test prior to writing the production code will give you insight into the design of your class or function. Use this insight to improve on the design prior to writing production code.
- Use composite unit testing to test implementors of interfaces.
- Write a unit test for each defect reported. This provides a great way to ensure a problem never reoccurs. And for those who already have existing applications but no unit tests, this approach will give you an introduction to writing unit tests.
posted by Kirby Turner | June 8 10:22 AM | comments (0)
Monday, June 07, 2004
I forgot to mention that pictures from Laura's graduation have been posted in the gallery on thecave.com. Enjoy.
posted by Kirby Turner | June 7 08:12 AM | comments (1)I just read an article about a new service called DidTheyReadIt. In a nutshell, this service places a small Web bug in HTML formatted e-mails that acts as a tracking device. When the e-mail recipient reads the e-mail a script on the DidTheyReadIt site logs the action. It will even log how long it took to read the e-mail message. Based on logged information the e-mail sender can know if you read the e-mail or not. Fortunately this service only works with e-mail readers that support HTML formatted e-mails, which is something I have never liked. Unfortunately most people view e-mail message as HTML.
HTML e-mails look nice but too much can happen behind the scenes that the message reader does not know about such as tracking when the e-mail message was read. I use Eudora as my preferred e-mail reader. It allows me to turn off viewing e-mail as HTML. I can still see the e-mail and read it, but it is not rendered as HTML. This means the e-mail message might not look as nice but it also means there is no unknown activity happening behinds the scenes when I read the e-mail. And I still have the option for view the message as HTML if I like.
Melanie and I have just returned from our first of three double wedding weekends for this year. Congratulations to Brooke and Josh on their marriage Saturday, and congratulations to Alex and Meg on their marriage on Sunday.
Tuesday, June 01, 2004
I have become a firm supporter of writing unit tests for most if not all code I write, and NUnit is an ideal framework for implementing unit tests. But one problem I have had repeatedly is finding a good way to test specific implementations of an interface. My approach has always been to write a new test fixture for each implementor of an interface. But the problem with this approach is that I end up duplicating unit tests for each implementor, and if I need to write a new test I have to copy it to multiple fixtures.
As a programmer I consider myself lazy. I don't like having to write the same code over and over. Instead I would rather write it once and forget about it. Having to write multiple test fixtures for each implementor of an interface doesn't suit my lazy style. I need a better approach and a quick google.com search pointed me in the right direction.
I came across a blog from Jonathan de Halleux that talks about composite unit testing using MbUnit. Jonathan presents an approach that splits the testing effort by class functionality rather than writing a test fixture for each class. This is exactly what I am looking for but as much as I like this approach and MbUnit I still have one issue. I want an approach that works with NUnit and does not require another framework such as MbUnit.
The development environment I have created for my customer is solid and I do not want to introduce new problems by introducing a new framework, in the case MbUnit. In other words, I do not want to change what has been currently written including the NAnt build scripts. So I did the next best thing. I took Jonathan's design and wrote a helper class to provide composite unit testing and include this class in my unit test projects.
Introducing CompositeTestFixture, a class that enables composite unit testing within NUnit test fixtures. Because this is a class and not a new framework there are limitations but the limitations do not affect the unit tests I am writing today. I will discuss the limitation later in this article.
To use CompositeTestFixture, begin by writing your test fixtures as you normally would. In the spirit of Jonathan's blog I will show an example that provides a test for implementors of the IEnumerable interface. In this example I will show how to test the ArrayList and Hashtable classes which both implement this interface. The only requirement in this test is that the IEnumerable instance is not null.
using System;
using System.Collections;
using System.Diagnostics;
using NUnit.Framework;
namespace Samples.FunWithNUnit.MyClassLibrary.UnitTests
{
[TestFixture]
public class EnumerableTest
{
[Test]
public void GetEnumeratorNotNull()
{
// Write unit test here.
}
}
}
Now we need to write the unit test for the GetEnumeratorNotNull test. However we must first tell CompositeTestFixture about the factories needed to create an instance of class that implements the interface to test. I call the instance of the class the implementor.
[TestFixture]
[ProviderFactory(FactoryType=typeof(ArrayListFactory),
ReturnType=typeof(IEnumerable))]
[ProviderFactory(FactoryType=typeof(HashtableFactory),
ReturnType=typeof(IEnumerable))]
public class EnumerableTest
{
...
}
Next we need to write the code that will test the implementor. The NUnit framework is going to call the GetEnumeratorNotNull method that is decorated with the [Test] attribute. This is where we call into the CompositeTestFixture helper class. A static method RunTest is provided for those who do not want to create an instance of the CompositeTestFixture class.
[Test]
public void GetEnumeratorNotNull()
{
CompositeTestFixture.RunTest( this );
}
Now we write the method that will perform the actual test. This method will have the same name as the test method. The only difference is that the method signature takes a single parameter of the interface type we are testing. Note that this method is not decorated with the [Test] attribute since we do not want NUnit calling this method.
public void GetEnumeratorNotNull( IEnumerable en )
{
Debug.WriteLine( "Testing " + en.GetType().ToString() );
Assert.IsNotNull( en.GetEnumerator(), "Must not be null." );
}
That's it. CompositeTestFixture will do all the heavy work of calling the appropriate unit test method to test a specific implementor.
How Does This Work
CompositeTestFixture will reflect on the class instances provided in the RunTest method call and retrieve the collection of ProviderFactory attributes decorating the test fixture. Each factory declared by the FactoryType property will be called to create an instance of a class that implements the type defined in the ReturnType property. In other words the factory will be used to create an instance of an implementor.
A factory can declare one or more methods that return an instance object. I call these methods creators since each is responsible for creating a instance of a class. Having multiple creators gives the unit test writer the option to provide implementors that are initialized differently. For example one creator might return an empty ArrayList while a second creator might return an ArrayList filled with random numbers.
CompositeTestFixture determines creators by inspecting the factory class type and discovering each method with a return type that implements the type defined in the ProviderFactory.ReturnType property that decorates the test fixture. Creators must be defined with a public scope and no parameters on the method signature.
using System;
using System.Collections;
namespace Samples.FunWithNUnit.MyClassLibrary.UnitTests
{
public class ArrayListFactory
{
public ArrayList CreateEmpty()
{
return new ArrayList();
}
public ArrayList RandomFilled()
{
ArrayList list = new ArrayList();
Random rnd = new Random();
for(int i=0;i<15;++i)
{
list.Add(rnd.Next());
}
return list;
}
}
}
After CompositeTestFixture calls a factory creator it calls the unit test method matching the name of the [Test] method that invoked CompositeTestFixture.RunTest( this ). In our example this is the GetEnumeratorNotNull( IEnumerable en ) method. This is repeated for each creator declared on a factory and for each factory declared on the fixture.
Limitations
Although this approach works for many cases it is not perfect. The SetUp and TearDown methods of the fixture will only be called when NUnit calls the wrapper test method. CompositeTestFixture does not call the SetUp and TearDown methods before and after calling the internal test method, although it would not be hard to add that feature.
Conclusion
With the CompositeTestFixture helper class, I now have an easy way to provide composite unit testing within introducing a new framework into my development environment. Hopefully you will find this code as useful as I have. Click here to download the complete source code. posted by Kirby Turner | June 1 08:42 PM | comments (2)
Just came across this dandy project called RAIL - Runtime Assembly Instrumentation Library. RAIL provides "an API that allows CLR assemblies to be manipulated and instrumented before they are loaded or executed." Imagine if you will loading an assembly, inspecting it, altering the IL, and executing the mutated assembly or even saving it. This has some interesting applications for aspect-oriented programming.
posted by Kirby Turner | June 1 12:53 PM | comments (0)
