Archive

Archive for the ‘Programming’ Category

Developing for Windows Phone 7 series

December 4, 2010 Leave a comment

Microsoft has lined up a really nice development framework and support system for developing apps for the new Windows Phone 7 series. Here are some to get started:

1. get the development environment

2. Charles Petzold’s book on developing for WP7

3. WP7 developer training kit

Advertisements
Categories: Programming Tags: ,

Bitwise 2008

February 11, 2008 8 comments

Bitwise 2008, the annual programming contest held by IIT-K is over. I got 58th rank. Better than previous attempts, but way to go:

2006 – No rank

2007 – 623

2008 – 58

Categories: Programming

Making sure to handle all exceptions

February 7, 2008 Leave a comment

Usually if a library or a low level function throws an exception, there is a good possibility that it is handled somewhere. However if a GUI function (e.g. clicking a button) has an un-handled exception then the application goes down (crashes). In debug mode the debugger would point out the error but in release mode – the application plainly crashes, on the user’s desktop.

For GUI apps, this can be a concern.

Languages like Java are strict in this case. If a method declares that it can throw an exception, all the callers of the method are enforced to implement an exception handler. Code simply does not compile without handling the exceptions.

In .net you can do two things:

1. read the documentation and find out what kind of exceptions can be thrown. For example if you see the penbox library, every method does list the type of exceptions that can be thrown.

2. blindly add a handler for the “Exception” class – generic type and handles ‘any’ exception.

Approach # 2 is easy to implement. However it is not really a good practice. Exceptions should be really used in case of exception – something you do not expect to happen. Adding a common type of handler has the risk of losing valuable debug information. The exception might have pointed out a logic error (e.g. FormatException in converting strings to numbers). Using the appropriate handler, you can identify such cases during debug and fix the code. Using a generic type handler usually means that you are going to lose this information.

 Approach# 1 is really good. However it can be a pain to read the documentation.

 There is a new tool called “ExceptionHunter” from RedGate. It goes through your .net assemblies (exe or dll) and identifies what all places you have un-handled exceptions. There is a 15-day free evaluation if you want to check out.

Categories: Programming

C# – Another “finally” trivia

November 4, 2007 Leave a comment

If a function implementation has a try – catch block with a finally clause, then the finally code block is executed in all cases before exiting the function.

For example, in the following case:

int Foo()
{
     try
     {
          //do stuff here
          if(something_happened == true)
               return;
          //do something else
     }
     catch(Exception)
     {
     }
     finally
     {
          MessageBox.Show("exiting method")
     }
}

In the above function, even if the function exits at the first ‘if’ condition, the message will still be displayed.

Categories: Programming Tags: , ,

Model based testing

October 5, 2006 Leave a comment

What is the best way to test software?

Delivering quality code and keeping customers happy is the ultimate goal for any software development effort. Common problems people complain about software are that it does not do what they expect it to. Lot of times, particularly in R&D environments the specs are not clear and there are 2-3 iterations before the customers and developers agree that they have a working solution. While ambiguous specs do lead to some kind of re-work, in my personal experience developers do spend time fixing issues reported by the customer. Instead of adding new features, time is spent on fixing bugs in a previous release. If most of the bugs were to be found before the release, there is a good chance of project success as the customers get a stable ‘working’ build.

Software testing plays an important role in ensuring that the application released to customers does what it is supposed to do and without any errors. The definition for testing that I like most is “software testing is running the code in a controlled environment with the intent of finding errors”.  Automated testing has come a long way in ensuring that a software product is tested consistently through its various releases. Through automated testing it is possible to excercise so many scenarios that are impossible to be executed manually within a limtied time and with limited resources.

Helpful as it is, traditional automated testing suffers from the pesticide paradox. Just like how a pesticide can kill only a particular type of pests and how useless it becomes once those bugs have been killed, the throughput from automated testing drops drastically over time. Automated tests are still good for smoke tests and regression testing where you are interested to find if some core functionality is working or if old functionality remained unbroken.

However one of the bigger challenges for product release is to extensively test the software. All the functionalities have to be tested, all the code in the application has to be excercised with various inputs to ensure that the program behavior is verified in all its possible states.

This verification of program behavior in all its possible states is quite difficult with traditional testing techniques.

Here comes Model Based Testing.

In model based testing, a behavior model of the software is constructed that describes all the possible functionalities of the system and the manner in which the software system transitions from one state to another. A typical tool used to represent such behavior models are the finite state machines.

A typical model based testing framework consists of (or is developed as):

1. Create or define a model of the system under test. Examples of models are state transition table or the finite state machines.

2. A separate component then uses the model to generate test cases. From the state transition table or the FSM a directed graph can be built with the different states of the system as nodes and the transitions as the edges. Using graph traversal techniques it is possible to determine a sequence of input actions that leads the software to a particular state. The sequence of input actions form the test case and the final state is the excpected result.

3. As the software evolves, only the model needs to be updated with any new states and transitions. The test suite can then be updated automatically. Another advantage of this methodology is that the expected behavior (test oracle) is also built into the scheme.

An excellent and comprehensive reference to MBT is available at www.model-based-testing.org and www.geocities.com/harry_robinson_testing. This is maintained by Googler Harry Robinson.

In future posts, I will share examples of creating behavior models and also blog about creating a model based testing framework.

Categories: Programming Tags: ,

Design for a testable rich client application

September 19, 2006 Leave a comment

Using Model View Presenter Pattern for testable applications:

The model-view-presenter pattern can be used to design testable applications. It is quite similar to the MVC pattern except that the view receives messages/ events from the user rather than the controller. The presenter acts as a bridge between the model and the corresponding GUI.

Categories: Programming

A brief note on value type and reference types

September 12, 2006 Leave a comment

A brief note on value type and reference types

Value type variables simply associate a data in memory to a name. The size of the memory slot is dependent on the type of the variable. For example,

int a = 10;

There is a slot of 4 bytes (for integer type) on the stack and the name for the slot is ‘a’.

Reference type variables always point to a location on the heap. The size of a reference type variable is always 4 bytes (32 bit systems, 8 bytes in 64 bit systems). This 4 byte reference points to the actual data on the heap.

Rules:
1. reference variables created on stack get destroyed when the stack unwinds (e.g. control exits out of the function). Note here that the actual data this variable was referring to will stay in memory as long other variables are referring it.

So irrespective of value type or reference type, all local variables are stored on stack.

2. Function parameters are also local to the function and stored on stack. However if the parameter has an ‘ref’ modifier then this argument shares the slot with the variable in the calling function.

3. Instances of a value type are stored in the same context as the variable that declares the value type. For example if a struct (value type) is defined as a data member in a class (reference type) then in all instance of the class, this struct instances will be created on heap.

4. Static variables and strings are always stored on the heap. Static variables are NOT stored on the garbage collected heap but on a different one called the high frequency heap.

5. If you declare two strings in a class like
string s1 = “ABC”;
string s2 = “ABC”;

note that both have same value. In such cases only one “ABC” is created on the heap and s1 and s2 will be referring to this memory location. If either s1 or s2 gets changed then a new string is created.

Further reading:
1. What is “ArrayList” and what are its uses
2. What is boxing in .net and why is this important
3. what are generics in .net 2.0 and what problem do they solve?

Categories: Programming