This blog has been moved to Redwerb.com.
Microsoft has just announced that they have "released an early preview of the Parallel Extensions to the .NET Framework (ParallelFX) technology." I haven't had a chance to check this out yet, but it looks like it will provide a new API for managing threading. What looks especially interesting are the multi-threaded foreach loops.
I don't want to say too much because I really don't know much about it, but check out the announcement on Somasegar's blog, Parallel Extensions to the .NET FX CTP.
As regular readers might already know, I am taking a certificate program in User-Centered Design. This quarter I am taking a class on usability testing.
One of the things I've learned in the course is that there seems to be a debate on qualitative vs. quantitative results. For the sake of this post, I'll define them as thus:
Qualitative - descriptive, subjective. Not easy to provide objective measurement.
Quantitative - numerical, objective. In sufficient quantity can provide statistically significant facts.
As you can probably imagine, most people would like to see quantitative results. They are easy to understand and see just how important a particular issue might be (not to mention those cool graphs). However, due to budget and time constraints, it is extremely uncommon for a usability test to have a sufficient number of participants to qualify for statistical significance. Without statistical significance, are quantitative results useful?
I have to say emphatically no. Quantitative results are completely useless within a usability test. The goal of usability testing should be to find flaws in the design (from the users perspective) of the software. These flaws should be tracked and prioritized the same as any other defect within the application (hopefully you use issue/bug tracking software).
Usability testing should focus on qualitative feedback. There are many techniques that you can use to elicit feedback from a user (for example, thinking out loud). Post study questionnaires can also be useful, but the questions should be open ended. You can ask a participant to rate the software, but only to lead them to the next question which should ask why they rated it the way they did (the actual rating is useless without statistical significance).
Furthermore, when reporting the results of usability tests, it is important not to imply any kind of statistical significance. For example, don't say that 20% of the participants failed to complete a task when you only had five participants. For all you know, that participant is the only person on the planet that would fail or perhaps the other four just got lucky. Even mentioning something like 1 out of 5 can be dangerous. Always make sure that people that are reading your report understand the limitations of the data.
This just in, Microsoft has shipped Visual Studio 2008! Read Somasegar's Weblog for the official announcement.
I can't wait to try it out. I'm looking forward to trying out all the new features such as XML literals in VB.Net, improved Intellisense, LINQ, integrated unit testing, and much more.
Hopefully I will get a chance to purchase a copy from the MS store soon. Are there any MS employees reading this that wouldn't mind if I bought this on their quota? I don't work too far from Redmond :).
The Commonly Used Types and Namespaces poster for version 3.5 of the .Net framework is now available.
It main sections are Windows Presentation Foundation/Windows Forms (in green), ASP.NET (in yellow), Communications and Workflow (in orange), Data, XML and LINQ (in purple), and Fundamental (in blue).
The poster lists new types as well as what will be available in the 3.5 version of the compact framework and Silverlight 1.1.
There is a lot of new stuff in here. Here is a quick list of what's new in each section:
I found the add-in support particularly interesting. I have been planning on implementing add-ins for the next major version of our product and am hoping to be able to use the add-in support in .Net 3.5. If you are interesting in finding out more about this, check out the article .NET Application Extensibility and the CLR Add-In Team Blog.
Jeff Atwood had a great post today about automating your build process (The F5 Key Is Not a Build Process) and it inspired me to finally write this post (I promised it a while ago - Making the Build).
As mentioned in my post Making the Build, an automated build process is very important. However, most software teams have a tight schedule and budget and find it difficult to justify spending time creating a proper build process, especially when nobody on the team has previous experience creating an automated build process.
Before I get to the benefits of an automated build, let me first describe the build for our product.
Our build process is fully automated. We have it scheduled to run on a dedicated machine every night. The build includes many different things, including compiling the source code, building the database from the previous version of our product using scripts, generating some source code, updating assembly attributes (such as version, company, etc), running unit tests, and more (too project specific to bother mentioning).
The benefits that we have found for our team are as follows:
If you decide to create an automated build process, here are a few suggestions (some of the advice is specific to building .Net projects, but I think much of it should hold true for other technologies as well):
Many people also advocate that build should be able to be run by any developer on their machine. This hasn't been very realistic for our project due to the size of the project and the cost of the software we chose to use (FinalBuilder isn't exactly free). However, it is a goal that I approve of.
If your project doesn't currently have an automated build process, I hope this article has encouraged you to create one. Good luck.
