Repeated questions – a help desk problem

A lot of effort at a help desk is spent in answering the xact same type of questions over and over again to different users. And no matter how many time you ask people to search the FAQs first, you still keep getting the same questions. Google groups has a very innovative and simple to it. Just look at the screen shots below and you will know

The google answer to the help desk problem

Class member search – Visual Studio .NET 2005

Being able to search members of classes that your code uses is quite handy. Be it classes that you have written yourself, or classes in other libraries your code references. You can do that by going to View -> Object Browser OR View -> Class View.

Class member search VS .NET 2005

Problem – Unable to reset fonts and colors after Visual Studio import settings

So you have tried making your IDE hot. And turns out you did not like the colors much. So you want to reset Visual Studio settings. You may have tried using the Tools -> Import and Export Settings to reset your fonts and colors. But it DOES NOT RESET colors and fonts.

Tools->Import Export Settings

To reset colors and fonts, here is what you need to do: Tools -> Options->

Reset VS colors and fonts

Hope it helps

Practical Software Quality – Part 1

I have been testing an app for almost a month now. The app has got about 161 features and runs into about 300,000 lines of code. Plus it interacts with 2 other components written in a different languages altogether. So obviously it’s a big task testing this app. I have been running through the (incomplete) test speck, and writing results, communicating the results to the developers, reproducing a given problems so developers can resolve it. Any testing activity will involve the following major parts:

1. Identifying all usage scenarios (you could also call this writing a complete test spec)

2. Verifying that no usage path results in unstable behavior

3. If a instability is found, it should be reproduced and reported

4. Verifying that the software’s output is what the user wants

The real trouble in testing an app is the fact that all these activities have to be repeated for every build that comes around. This could be as often as twice a week. Unfortunately, it is not possible to repeat all test cases in this much time. So we cut corners here and there. The result is, we don’t have control over quality. The question arises: How can you reduce testing time? So lets go point by point here about all testing activities.

Identifying all usage scenarios

This is always THE MOST DIFFICULT TASK in testing. In a moment I will explain why. Let us say we are testing Microsoft Word. I have Office Word SP3 build ver 11.8215.8202 installed on my machine here. So here is what I did:

Steps to Reproduce:

1. Open Word. Word opens with a new document

2. Enter some random text like “The quick brown fox jumps over the lazy dog”

3. Open Find dialog (you could use Ctrl-F) -> Click over the More button at the bottom of the find dialog to open the complete functionality Find Dialog

4. Enter some text in the “Find What:” text box

Here is how it would look

5. Close the opened file through File->Close. The file closes but the search dialog is open

6. Without doing anything else clcik on Format in the bottom. User menu opens

7. Click on Font.. Option and you have your bug

You can read the message box that says that you got to save your file and there is really very less RAM on your drive. All this when you DON’T have any file open. And there is more

7. Try to click on the menu items without closing the insufficient memory dialog. Now navigate to any other application and the menu still appears as on the screen

And more..

8. Navigate back to word and try to close it by hitting the red close button. The app never closes. You can of course close it by calling task manager and killing Word.

Microsoft released three service packs for Word 2003 and I could find a bug in less than half an hour. I am not saying that Microsoft is dumb. I am just saying that there are so many many usage scenarios for Word that unknown bugs are inevitable. There is a big chance that Microsoft already knows about this bug. And they did not fix it because far too less user’s will encounter a problem like this. And fixing this bug would probably need a change in architecture so huge that it will be very very expensive. And this is reality.

If Microsoft let this bug go, even after thousands of hours of testing, there is a big chance that this could happen to many others. Any application of decent size will have bugs. Because there will be some usage scenarios that went untested and unreported before the app was delivered. Identifying all user scenarios is not only close to impossible but also impractical for the project budget. Software developers have an unspoken understating of software quality. I will try and explain some precautions we could take to make sure our software caters well to all usage scenarios.

So the question is how do we make sure we have handled all usage scenarios well. Hopefully I will elaborate on that in the coming articles.

Synchronizing databases modified by multiple clients

A study of syncing databases that are simultaneously being updated by multiple clients where the clients are unaware of each other.

---

It is quite simple to build client server based application that has only one client accessing data at a time. Only one client has access to a database at a time and the diagram below shows how that happens.

A database server that is accessed simultaneously by multiple clients will have issues while the client and server data is being synced. The diagram below shows a client updating a server.

The figure above demonstrates how client C1 could potentially overwrite modifications made to the database by client C2. Client C1 is unaware of client C2.

Design Requirements for Syncing

The following fields are required for every table by the application for syncing:

1. Auto incrementing integer ID
2. Last Modified Time (LMT) field that is updated with current time whenever
   1. A row is ADDED or UPDATED at client end
   2. A row is uploaded to database server

Algorithm for syncing database

• Before downloading data the server and client clocks are to be synchronized

• When data is downloaded by client at time Download Time (DT) a copy of the server database (DBsv1) is stored locally. And DT is noted

• Whenever a row is ADDED or UPDATED by the client the LMT field is to be updated with current time

• After modifications are done, the client copy of the database (DBcl) is saved locally. Another copy of server data is to be downloaded (DBsv2)

• Create a list of [ID, LMT] for every table in DBsv1, DBcl and DBsv2. Lock DB at server from accepting any modification

• The following conditions need to be checked for every table in the database. Comparing DBsv1 and DBcl

Rows Modified at Client (By client C1)	Named List 1
ROW ADDED 1. If ID present in DBcl but not in DBsv1	RAcl (ROW ADDED at Clinet)
ROW DELETED 1. If ID present in DBsv1 but not in DBcl	RDcl (ROW DELETED at Clinet)
ROW UPDATED 1. If ID present in DBcl and DBsv1 && LMT in DBcl > LMT in DBsv1	RUcl (ROW UPDATED at Client)

• Comparing Named List 1 and DBsv2

Rows modified at Server (By client C2 or other)	Named List 2
RDcl ROWS UPDATED 1. If ID present in RDcl and DBsv2 && LMT in DBsv2 > LMT in DBsv1	DRUsv (DELETED ROW UPDATED at Server)
RDcl ROWS DELETED 1. If ID present in RDcl and not in DBsv2	DRDsv (DELETED ROW DETELED at Server)
RUcl ROWS UPDATED 1. If ID present in RUcl and DBsv2 && LMT in DBsv2 > LMT in DBsv1	URUsv (UPDATED ROW UPDATED at Server)
RUcl ROWS DELETED 1. If ID present in RUcl and not in DBsv2	URDsv (UPDATED ROW DELETED at Server)

• Start making changes to server. ADD all ROWS in RAcl to database server

• Delete ROWS in DRDsv from database server

• For each ROW in DRUsv alert the user. If possible show the contents at the server and ask for action to be taken

• For each row in URUsv alert user. If possible show the contents at the server and client side by side and ask for action to be taken

• For each row in URDsv alert the user. If possible show the contents at the server and ask for action to be taken

• Ask the user if new data is to be downloaded from the server. If yes load DBsv2 into the client

• Unlock the Database

Joel on Software – Software is fun

Just read this rolling-on-the-floor-with-laughter post by Joel here

I love Joel On Software. It is a kind of blog that reveals the fun of software development. Of course software development is serious business. But you can have a great deal of fun working on it.

Really funny error message

This is one of the funniest error messages I have seen in a long time.

[The name of the software developer removed]

Some Software Design Guidelines

Here are some standards that most users are accustomed to see in windows applications.

A standard menu bar. Keep the menu bar as standard as possible. Here is a standard menu item strip. Of course you will have much more in your menu bar. But here is the bare minimum.

File: New, Open, Save, Save As.., Print, Page Setup, Print Preview, Exit

Edit: Cut, Copy, Paste

Tools: Customize, Options

Help: Check for Updates, About

Display the opened file name in the title bar.

Ask for confirmation when the user deletes anything.

Ask for saving the active file if the user has unsaved changes.

A document processor (like Word or AutoCAD) should open a new file by default. A project management system (like Visual Studio) should not load any project by default.

While the user is to select an option use Radio button instead of combo boxes if there are only three or fewer options and if the number of options are not going to increase in the future. For example see the difference between the Hotmail User Sign Up form and the Yahoo! sign up form.

VS

Validate data only where the lack of validations will crash the application or make a feature unusable. For example validate all email ids in a mailing list app. Do not validate phone umbers in mailing list app.

ObjectDataSource: could not find a non-generic method ‘Update’. Problems using ASP .NET 2.0 DeatilsView and TableAdapter

Note: This problem is resolved in Visual Studio 2005 SP1 and Visual Web Developer 2005 Express Edition SP1. Try installing the service packs to get around this problem. Or you could just download Visual Web Developer 2008 Express!

Using .NET 2.0 TableAdapters wizard and ASP.NET 2.0 DetailsView data source configuration causes many problems including a runtime error during update or a failure to update the data. Many users have reported this error. A little bit of Googling helped me find out that this error is because a mismatch in the parameters generated by the TableAdapter and the DetailsView for the update command. Here is a way that I used to solve this. I did not find anyone writing about this technique. So I thought I might as well write it here.

How to Reproduce the error?

You should be using Visual Studio 2005(ASP.NET 2.0) and SQL Express. I don’t know if this problem exists with SQL Server as well. I haven’t tried it.

1. Create a table in SQL Express or SQL Server. The table should have an Identity field.

2. Add a Dataset to the Project.

3. Drag and drop the table from VS 2005’s Server Explorer to the Dataset. This creates a DataTable along with a TableAdapter. Note the TableAdapter has a Fill Query, and Delete, Insert, Select and Update Command. The Update Command is not generated if the table does not contain an Identity field. Alternatively you can add a TableAdapter to the dataset and configure the table adapter using the TableAdapter Wizard.

4. Add an ASPX file to the project. Add a DetailsView to this file. From the DetailsView Tasks (that shows up on clicking the arrow mark on the right top of the details view in the designer mode) select the TableAdapter as the datasource. Enable Paging, Inserting, Editing and Deleting.

5. Run the Page. Try Updating. You should either get a runtime error or the update just doesn’t work.

If you are getting either of these, read on.

How to fix the problem?

1. Create a Table in the SQL Express. Make sure it has and Identity field and all other field have “allow nulls” as true. You may change it later but you need to have it enabled while generating the TableAdapter. Here I have used three fields id, Name, Type

2. Create a dataset. Drag and drop the table from the server explorer to the xsd file.

3. Right click on the TableAdapter and go to properties. Expand UpdateCommand click on the Paratemetrs. Remove all ISNull_and Original except Original_ID.

4. Open CommandText and remove text after WHERE (id=@Original_id). Save the XSD file.

5. Create a DetailsView in an ASPX file and slect the TableAdapter as datasource. Enable Paging, Inserting, Editing and Deleting.

6. Click on the edit fields of the DetailsView and Make the ReadOnly property of Id field as False. You can change it to ReadOnly = True later.

7. Run the aspx file. Things work just fine.

Hopefully this helps.

Managing Software Updates for Windows Applications

A great thing about web applications is that there is no application setup required at the client end. Plus updates are automatically available as soon as they are deployed on the server. Windows applications however are not so fortunate in this area. Many a times we need to send software updates to windows applications. This could be a new feature that one has added to the application or a bug fix that was written after the software was released. Most windows based applications are distributed by MSI installers. But it would be really irritating for the user to uninstall and install new version every time a bug fix is released. There is however a new internet based approach to windows application updates. This post examines and explains the same.

Most applications distribute a separate application to along with the main app to check for updates. For the sake of reference we can call it an Update Manager or Just UM. Here is how a Mozilla Firefox also uses one called Software Updater (updater.exe) that can be accessed by clicking on Help->Check For updates.

Here is how it looks.

In reality an Update Manager will need to control the client environment. Here is the minimum set of requirements for an update manager.

Requirements

Check for Updates. The software publisher will have to maintain an updates file on a web site. This file will keep the filenames and latest version numbers of all files that are to be deployed in the client system to install the update completely. An XML file is most convenient for this purpose. Also a similar XML file needs to be placed in the client system that contains file names and version numbers of the files currently installed on the client machine. Updates will be checked by comparing the two XML files.

Replace files in the installed path. Most updates are just bug fixes or minor features that can be made available to the user by replacing the main executable in the application’s root directory. Wether a file is to be replaced or not is decided based on version number of the files.

Add new files to the install path. Some features or bug fixes need more than just one new executable file. For example the new build will depend on an XML file or a DLL.

Download and run patch files. Finally there could some changes required in the registry or elsewhere in the client environment as well. This is typically done by running patch files. Patch files will contain the word “patch” (or any other keyword) in the file names so the UM knows that it has to run these files after downloading them.

Automatically close and restart the main application. Most updates are deployed by replacing files; mostly the main exe file. So the UM will have to close the main application before replacing and restart the app after updates are downloaded.

Create back up of all files before replacing. There is no guarantee that the app’s new features are bug free. In fact the user may not want them at all. So the user should be able to “roll back” to his previous set up. This can be done if the UM creates back up of all files that are to be replaced.

Working

All application updates will be placed in a website location along with the Updates XML file. The UM will first download the updates XML file from a pre-define URL. The URL for the Updates file could be kept in a configuration file or hard coded in the application (I prefer the later). The Updates file contains three columns for each file namely File Name, Version Number, URL location.

UM will then compare the update files on the sever and files on the local machine and prepare of list of files to be downloaded. This list will contain

1. Newer versions of existing files 2. New files 3. Patch files

UM will then create new “temp” folder and download the files to this folder. It will then check the files that are to be replaced and create a back up of these files. Finally the UM will kill the main app, copy the downloaded files to the application path, delete the temp folder, run patch files if any and restart the main app.

Updates installed!

This method of publishing windows application updates is almost as hassle free as deploying web applications.