Archive for the ‘Tech/Hacks’ Category

Post

Using Pex to test VB.NET code

In .NET,Tech/Hacks on December 2, 2008 by Sid Tagged: , , ,

In an ideal world one would write unit-tests before writing any new code following the tenants of TDD. In reality it is quite common to have to rely on a legacy library to do some heavy lifting. Pex is a great new tool available from Microsoft Research that can be used to generate unit-tests automatically. It is smart in that it runs the function you wish to test trying to exercise all possible code paths and ultimately generates unit-tests that can be used to test that function.

Using Pex is as easy as right-clicking on a function in Visual Studio and selecting “Run Pex Explorations”. Pex takes a little while running your function and then displays a table with various values that can be used to test your function.

However if your legacy code happens to be in VB.NET, you cannot just right-click on a function to have Pex generate all unit-tests for you. So that’s where I hope this article will help you.

First, let’s define a scenario. Imagine there’s a class called Transaction and a class called PaymentMethod. A transaction contains various payment-methods. A PaymentMethod indicates whether it requires the cash-drawer to be opened or not (e.g. it doesn’t make sense to pop cash-drawer for a credit-card while it does for cash and debit-card). There’s a read-only property PopCashDrawer on Transaction which returns true if any of the payment-methods requires the cash-drawer to be opened.

Public Class PaymentMethod

Private mPopCashDrawer As Boolean

Public Property PopCashDrawer() As Boolean
Get
Return Me.mPopCashDrawer
End Get
Set(ByVal value As Boolean)
Me.mPopCashDrawer = value
End Set
End Property

End Class

Public Class Transaction

Private mPaymentMethods() As PaymentMethod

Public Property PaymentMethods() As PaymentMethod()
Get
Return Me.mPaymentMethods
End Get
Set(ByVal value As PaymentMethod())
Me.mPaymentMethods = value
End Set
End Property

Public ReadOnly Property PopCashDrawer() As Boolean
Get
Dim pop = False
For Each pm As PaymentMethod In Me.PaymentMethods
pop = pop OrElse pm.PopCashDrawer
Next
Return pop
End Get
End Property

End Class

To have Pex generate unit-tests for you, here’s what you need to do:

  • First to get started writing unit-tests, just right-click on Transaction in Visual Studio and select “Create Unit Tests”. Make sure you select “Create a new Visual C# project” for Output Project in the dialog that pops up.
  • Next, in the generated class TransactionTest add the following parameterized unit-test (PUT). This guides Pex to come up with different values of arguments to this method which will exercise all code-paths in PopCashDrawer property. Transaction.PopCashDrawer depends upon the PaymentMethods so we take the array of PaymentMethods as argument to our PUT and set it on the transaction before calling PopCashDrawer. The PexAssume.IsNotNull line further guides Pex to say that we don’t really care about the case when transaction is null because we’re really interested in testing PopCashDrawer method.

    [PexMethod]
    public bool PopCashDrawerPUT(Transaction transaction, PaymentMethod[] paymentMethods)
    {
    PexAssume.IsNotNull(transaction);
    transaction.PaymentMethods = paymentMethods;
    return transaction.PopCashDrawer;
    }

  • Next, just right-click on PopCashDrawerPUT and select “Run Pex Explorations”. Pex will then display a table with various values of arguments and the results it got in each case.
  • However since the VB assembly is separate from the C# test-project, Pex will display an icon indicating that it didn’t explore some methods because they were uninstrumented.
  • Make sure you include all methods displayed as uninstrumented and run Pex explorations again.
  • This time around Pex would show 7 different test-cases that it identified.
  • A file named TransactionTest.PopCashDrawerPUT.g.cs would be generated containing unit-tests for those 7 cases. Take a look at that class to see how much work it saved you.
  • You can run the generated unit-tests by going to Test->Run->All Tests in Solution from the main-menu in Visual Studio.
  • Pex would discover inputs which cause PopCashDrawer to throw a NullReferenceException. Determining fixes for those cases is left as an exercise to the reader :)

Download and try out Pex, if you haven’t already!

1 Comment

Post

Mocking indexers with NMock

In .NET,Tech/Hacks on November 25, 2008 by Sid Tagged: ,

Indexers allow objects to behave like arrays. Dictionary class in .NET, for example, provides an indexer that allows the retrieval of the item from the dictionary that corresponds to a particular key.

There are two ways you can go about mocking indexers defined on interfaces when using NMock.

  1. You can use the Get property to describe what should be returned when a particular parameter is passed. The following expectations for example, cause “xxx” to be returned when foo[“aaa”] or foo[“bbb”] is called.

    Expect.Once.On(foo).Get["aaa"].Will(Return.Value(“xxx”));
    Expect.Once.On(foo).Get["bbb"].Will(Return.Value(“xxx”));

    This approach works fine in most circumstances. However you are required to provide all the values with which the indexer can be invoked. This presents a problem in the scenario where you need to return a particular value irrespective of the value of the input parameter.

  2. Indexers are implemented under the hood as methods so NMock’s support for mocking methods can be used to mock indexers. An indexer definition is munged by the compiler to a pair of get_Item and set_Item methods. When you call foo[“aaa”], it is munged by the compiler to a call to the get_Item method on foo with “aaa” as the argument.

    So here’s what you can do to make sure that “xxx” is returned irrespective of the value of the parameter passed to the indexer.

    Stub.On(foo).Method(“get_Item”).Will(Return.Value(“xxx”));

    Now any call of the form foo[<BLAH>] will return “xxx”.

Leave a Comment

Post

Automating windows forms UI testing

In .NET,General,Tech/Hacks on November 6, 2008 by Sid Tagged: , ,

If you have been blessed with a windows-forms application that has business-logic invading the user-interface, I have something that’ll help you. The most practical approach in this situation is to rearchitect the business layer and switch the UI over in a piecemeal fashion. While you’re doing this, automated testing of the user-interface will make your job a lot faster compared to manual testing.

For the purpose of this article let us consider a simple Windows Forms application (download link below). The application allows the user to provide two inputs and then either add them or subtract them. Simple, right?

The application
screenshot

Here’s the code for the event-handlers of interest to us:

private void MainForm_Load(object sender, EventArgs e)
{
this.lblAnswer.Text = “0″;
}

private void btnAdd_Click(object sender, EventArgs e)
{
this.lblAnswer.Text = Convert.ToString(this.numericUpDown1.Value + this.numericUpDown2.Value);
}

private void btnSubtract_Click(object sender, EventArgs e)
{
this.lblAnswer.Text = Convert.ToString(this.numericUpDown1.Value – this.numericUpDown2.Value);
}

The handler for the load event of the form just sets the answer label to display “0”. The handler for the click event of each of the buttons retrieves the selected values from the numeric drop-downs, applies the appropriate operation, and writes the result into the label.

The tests

In order to write tests for this application, you can start by right-clicking on the class of the form (in this case MainForm), and selecting “Create Unit Tests…”. Hit “OK” on the dialog that pops up to create unit-tests in a separate project. Another dialog will pop up asking for the name of the test project. Just hit “Create”.

This will cause Visual Studio to do some heavy lifting for us and generate accessors to allow us to call methods and properties defined on MainForm, from our tests. We don’t have to write code for accessors using the Reflection API ourselves – so this is extremely cool. Doing it on our own is quite painful (proof).

Delete all the tests marked with the TestMethod attribute in the generated class because we’re going to write our own.

The first one is pretty simple. We expect the answer label to display a “0” when the form is initially loaded – so let’s test that.

///

///A test for MainForm_Load
///

[TestMethod()]
[DeploymentItem("AppUnderTest1.exe")]
public void MainForm_LoadTest()
{
MainForm_Accessor target = new MainForm_Accessor();
target.MainForm_Load(null, null);
Assert.AreEqual(“0″, target.lblAnswer.Text, “Initial answer is zero”);
}

Notice that we can call MainForm_Load directly (no ConstructorInfo, MethodInfo – reflection stuff required).

Once that’s done we can just check the text displayed in the answer label and make sure it is “0”.

We can take the same approach to call the click event handlers of the buttons and check the results for addition/subtraction.

Since there are various cases to test, I have a separate function GetTestTable that returns a two dimensional array where each row contains the two test-inputs, result of subtraction, and result of addition – in that order.

public int[,] GetTestTable()
{
// Format of each row:
// A, B, (A-B), (A+B)
int[,] table =
{
{0, 0, 0, 0},
{10, 0, 10, 10},
{0, 10, -10, 10},
{-10, 0, -10, -10},
{0, -10, +10, -10},
{10, 10, 0, 20},
{-10, -10, 0, -20},
{-10, 10, -20, 0},
{10, -10, 20, 0}
};
return table;
}

Following is the function that actually does the testing. We basically process each row returned by GetTestTable one by one. First we set the two inputs on the numeric drop-downs. Next we call the click event-handlers of both buttons verifying what is in the answer label against what we expect. Again notice that we can directly invoke the event handlers and even access properties of the answer label (lblAnswer).

///

///A test for btnSubtract_Click
///

[TestMethod()]
[DeploymentItem("AppUnderTest1.exe")]
public void AddSubtractTest()
{
MainForm_Accessor target = new MainForm_Accessor();

int[,] table = this.GetTestTable();

for (int i = 0; i < table.GetUpperBound(0); i++)
{
int a = table[i, 0],
b = table[i, 1],
subtract = table[i, 2],
add = table[i, 3];

target.numericUpDown1.Value = a;
target.numericUpDown2.Value = b;

target.btnSubtract_Click(null, null);
int result = Convert.ToInt32(target.lblAnswer.Text);
Assert.AreEqual(subtract, result, String.Format(“Subtract {0} and {1}”, a, b));

target.btnAdd_Click(null, null);
result = Convert.ToInt32(target.lblAnswer.Text);
Assert.AreEqual(add, result, String.Format(“Add {0} and {1}”, a, b));
}
}

To run these tests, select Test->Run->All Tests in Solution from the main-menu in Visual Studio. The “Test Results” window in Visual Studio should show that all tests passed.

Summary

There’re multiple ways to go about automating UI testing. You could use an automated testing tool like Mercury Quick Test. However if you want to take things into your own hands and take advantage of greater control, you could write your tests using NUnit or MS-Test and make PInvoke calls to send messages to various controls in the UI of your application under test. You could use the SendKey API in Windows.Forms too.

However if you want to take advantage of knowledge of the internals of the application under test, we have to use Reflection to set properties of the controls, invoke event handlers, call other methods and then test whether this resulted in the changes that we expected. This makes the job extremely painful. I hope this article shows how much easier it is if we leverage Visual Studio Team System to generate accessors for us.

I don’t see why the technique described above cannot be used to test WPF and Silverlight applications as well.

Download
Click here to download the code accompanying this article.

Leave a Comment

Post

Automatic properties with custom logic – part 2

In .NET,Tech/Hacks on October 29, 2008 by Sid Tagged: , , ,

Let’s say we have a class called ShoppingCartItem. We’re going to concern ourselves with two properties here namely TaxID and Taxable. The business logic dictates that an item is definitely non-taxable if it has a tax-id of zero, otherwise it may or may not be taxable which is decided by some code situated outside the ShoppingCartItem class.

How would you write your ShoppingCartItem class?

Now – we cannot really take advantage of automatic properties over here.

public class ShoppingCartItem
{
public int TaxID { get; set; }
public bool Taxable { get; set; }
}

We really want the ShoppingCartItem to unset the Taxable flag when TaxID is zero. The setter for TaxID property seems to be the most obvious place to do that. But since we’re relying on the C# compiler to generate the getter/setter code we don’t really have control over that.

Of course, we have to fall back to the old way of doing it.

public class ShoppingCartItem
{
private int mTaxID;

public int TaxID
{
get
{
return this.mTaxID;
}
set
{
this.mTaxID = value;
if (this.mTaxID == 0)
this.Taxable = false;
}
}
public bool Taxable { get; set; }
}

That solves the problem we initially set out to solve but isn’t future proof. That’s because there’s nothing stopping a future programmer from adding new code in ShoppingCartItem class that directly saves values to mTaxID field instead of using the property setter. This could lead to Taxable being inconsistent with the value of TaxID. It would be better if we could somehow prevent direct setting of the backing field corresponding to the TaxID property even within the class.

Well, here’s an idea that leverages the lambda expression support in C# 3.0 to give us something that’s concise to write.

public class ShoppingCartItem
{
public PropertyValue TaxID;
public PropertyValue Taxable;

public ShoppingCartItem()
{
this.TaxID = new PropertyValue()
{
OnSet = value =>
{
if (value == 0)
this.Taxable.Value = false;
}

};
this.Taxable = new PropertyValue();
}
}

PropertyValue is the new class that I wrote. The idea is that you provide the code that should be executed when the TaxID is set, when initializing TaxID.

Here’s the code for the new class.

public class PropertyValue < T > : System.ComponentModel.INotifyPropertyChanged
{
#region Private fields

private Action mOnGet;
private Action mOnSet;
private T mValue;

#endregion

#region Constructors

public PropertyValue()
{
this.mValue = default(T);
}

public PropertyValue(T initialValue)
{
this.mValue = initialValue;
}

public PropertyValue(T initialValue, Action onGet, Action onSet)
{
this.mValue = initialValue;
this.mOnGet = onGet;
this.mOnSet = onSet;
}

#endregion

#region Properties

public Action OnGet
{
private get
{
return this.mOnGet;
}
set
{
if (this.mOnGet == null)
{
this.mOnGet = value;
}
else
{
throw new InvalidOperationException(“Getter can only be assigned once.”);
}
}
}

public Action OnSet
{
private get
{
return this.mOnSet;
}
set
{
if (this.mOnSet == null)
{
this.mOnSet = value;
}
else
{
throw new InvalidOperationException(“Setter can only be assigned once.”);
}
}
}

public T Value
{
get
{
if (this.mOnGet != null)
{
this.mOnGet(this.mValue);
}
return this.mValue;
}
set
{
this.mValue = value;
if (this.mOnSet != null)
{
this.mOnSet(this.mValue);
}
if (this.PropertyChanged != null)
{
this.PropertyChanged(this, new System.ComponentModel.PropertyChangedEventArgs(“Value”));
}
}
}

#endregion

#region INotifyPropertyChanged Members

public event System.ComponentModel.PropertyChangedEventHandler PropertyChanged;

#endregion

#region Overridden base class methods

public override string ToString()
{
if (this.mValue != null)
{
return this.mValue.ToString();
}
else
{
return base.ToString();
}
}

#endregion

}

While it does appear to solve the issue, I’m not quite satisfied. So let me end this by pointing out the things I don’t like in the implementation and ask for ideas:

  • It is wordier compared to the automatic property support in C# and requires you to know about lambda expressions. Here’s how I think it should have been:

    public class ShoppingCartItem
    {
    public int TaxID
    {
    get;
    set
    {
    if (value == 0)
    this.Taxable = false;
    }
    }
    public bool Taxable { get; set; }
    }

    This doesn’t work in C# 3.0 and generates a compiler error “ShoppingCartItem.TaxID.get’ must declare a body because it is not marked abstract, extern, or partial”.

  • Ideally, I should have been able to write the following which seems more succinct.

    public class ShoppingCartItem
    {
    public PropertyValue Taxable = new PropertyValue();
    public PropertyValue TaxID = new PropertyValue()
    {
    OnSet = value => {
    if (value == 0)
    Taxable = false;
    }

    };
    }

    But I cannot, because it generates a compiler error “A field initializer cannot reference the non-static field, method, or property”. This requires me to do the same thing inside the constructor which introduces an extra step.

What do you think?

5 Comments

Post

Automatic properties with custom logic

In General,Tech/Hacks on October 24, 2008 by Sid Tagged: , , ,

There should be a compiler supported way in C# to declare a property with custom getter/setter logic without having to explicitly declare a backing field. In the absence of such a feature, if you want to have custom getter/setter logic you have to ditch automatic properties, declare a backing field explicitly and then there’s nothing stopping a future programmer from assigning directly to the backing field and the custom getter/setter logic not getting executed probably leading to bugs.

Update:Check out part 2 where I take an example to bring the problem into perspective and propose a solution…

2 Comments

Post

“Add Service Reference” option not appearing in Visual Studio 2008

In .NET,Tech/Hacks on July 22, 2008 by Sid Tagged: ,

Had to do a bit of head-scratching on this one. New projects created in Visual Studio 2008 did show the “Add Service Reference” when right-clicking on a project in Solution Explorer while some existing ones didn’t.

Using “Add Web Reference” instead of “Add Service Reference” has its own set of issues in that WCF services are meant to be used with DataContractSerializer. “Add Web Reference” utilizes XmlSerializer which might lead to some surprises when consuming WCF web-services. The way the two serializers handle WSDL is different. This article explains why you might find that property values of your complex types in web-services do not reach all the way to the web-service from the client.

Somebody logged a Microsoft Connect ticket on this but didn’t receive an answer because the issue couldn’t be reproduced.

Anyway, if you’re facing this issue – make sure that the target framework for your project is .NET 3.0 or later (you can do this in the Application tab of your project’s properties). You need to do this extra step if you upgrade your project to Visual Studio 2008 from older versions otherwise “Add Service Reference” wouldn’t appear. You can target .NET 2.0 from Visual Studio 2008 projects and that’s the default behavior during upgrade.

Update: This didn’t fix the issue for you? Check the comments for more alternatives.

18 Comments

Post

A simple RTF report generator

In .NET,Tech/Hacks on June 10, 2008 by Sid Tagged: , , ,

I was describing how a simple yet extensible report-generator could be implemented quickly to somebody. I’m posting it here as some of you might find it useful (and I can refer to this link in future conversations :) ).

The concept:

…is really simple. The idea is to look for a placeholder like @Fruit and replace it with “Apple”. However to make the whole thing extensible, reflection is used. When calling the report generator, you need to specify a reportInput object (can be of any type), in addition to the file-paths of input and output reports. The report-generator uses reflection to determine the properties available on the reportInput object. For each property, it derives a tag name and substitutes the derived tag name with the actual property value in the input file. The text read from the input file after making replacements is finally written to the output file. For further extensibility, the tag format is not hard-coded and can be specified as an argument.

Before (an RTF file with placeholders):

After (an RTF file with placeholders replaced with values):

The code:

public static class SimpleReportGenerator
{
public static void Generate(string inputFilePath, string outputFilePath, object reportInput, string tagFormat)
{

if (string.IsNullOrEmpty(inputFilePath))
throw new ArgumentException(“inputFilePath”);
if (string.IsNullOrEmpty(outputFilePath))
throw new ArgumentException(“outputFilePath”);
if (reportInput == null)
throw new ArgumentNullException(“reportInput”);
if (string.IsNullOrEmpty(tagFormat))
throw new ArgumentException(“tagFormat”);

string inputFileText = File.ReadAllText(inputFilePath);
StringBuilder reportOutput = new StringBuilder(inputFileText);

Type reportInputType = reportInput.GetType();
PropertyInfo[] properties = reportInputType.GetProperties();

foreach (PropertyInfo property in properties)
{
string propertyTag = String.Format(tagFormat, property.Name);
object propertyValueObj = property.GetValue(reportInput, null);
string propertyValue = (propertyValueObj != null) ? propertyValueObj.ToString() : String.Empty;

reportOutput.Replace(propertyTag, propertyValue);
}

File.WriteAllText(outputFilePath, reportOutput.ToString());

}
}

An example:

Defining ReportInput

public class ReportInput
{
public string ReportTitle { get; set; }
public string ReportHeading { get; set; }
public string ReportBody { get; set; }
public string ReportAuthor { get; set; }
public DateTime ReportDate { get; set; }
}

Creating a ReportInput for testing

public ReportInput GetTest()
{
ReportInput input = new ReportInput() { ReportAuthor = “John Doe”, ReportBody = “A quick brown fox jumped over a lazy dog”, ReportDate = DateTime.Now, ReportHeading = “The new report”, ReportTitle = “Here we go” };
return input;
}

Generating a report

string input = “testreport.rtf”;
string output = “testreport_out.rtf”;

ReportInput reportInput = GetTest();
// “@{0}” indicates that a property named “Foo” corresponds to “@Foo” tag in the input file.
SimpleReportGenerator.Generate(input, output, reportInput, “@{0}”);

kick it on DotNetKicks.com

3 Comments

Post

ArrayList item comparison

In .NET,Tech/Hacks on June 6, 2008 by Sid

What’ll be the output of the following piece of code (asked here)?

ArrayList a = new ArrayList();
ArrayList b = new ArrayList();

a.Add(1);
b.Add(1);
a.Add(2);
b.Add(2.0);

Console.WriteLine(a[0] == b[0]);
Console.WriteLine(a[1] == b[1]);

One might expect…

True
True

But what you’d actually get is…

False
False

…because of boxing.

a.Add(1) boxes the integer 1 into an object and stores it in a, while b.Add(1) boxes the integer 1 into a separate object and stores it in b. Since a[0] and b[0] are going to be different objects, the check is going to fail. Same logic applies when comparing a[1] and b[1].

However, it gets interesting. If you tried to do a similar thing in VB.NET, the output would be different.

So with a code like this…

Dim a as new ArrayList()
Dim b as new ArrayList()

a.Add(1)
b.Add(1)
a.Add(2)
b.Add(2.0)

Console.WriteLine(a(0) = b(0))
Console.WriteLine(a(1) = b(1))

The output is going to be…

True
True

Surprised :) Well, VB.NET compiler translates the equality check (“=”) to a call to a helper function part of VB.NET runtime which would cast the left and right hand sides appropriately before comparison. In the first case, it would compare the two objects as integers, while in the second case it would compare the two objects as doubles after converting the integer on left hand side to a double.

That’s why we have generics – no surprises like these…

2 Comments

Post

What you should do…

In General,Tech/Hacks on May 1, 2008 by Sid Tagged: ,

I am fortunate enough to work with a couple of great individuals. Recently I was able to hypnotize persuade them into discussing things which should and shouldn’t be done in a software project :)

I am absolutely sure that the discussion will help me in the future (and them). However I thought the merged list is generic enough to help anyone, and hence this post.

In the beginning…

  • Before you start on a project, follow up with your managers and ensure that a detailed feasibility analysis has been done. This should include business planning, market analysis, and of course technology investigation to identify major road-blocks that are likely to be encountered in the future. For the technical analysis, you must involve the person who is going to actually write most of the code later on – because he’s the only one who’s most likely to consider all the possible issues.
  • Involve engineers during requirement gathering phase. If possible, ask each of them to take a good look at a system of other competitors and report back with their findings. This will help the Product Manager in that there’s a better guarantee of the surface area of features being covered. The other bigger benefit is that the engineers would have a much clearer idea of the sort of product they’re supposed to build without having to read hundreds of pages in the requirements documents. This will also make them, I believe, more receptive to changes made in the requirements later on as they’ll have a better picture of the landscape. Being receptive to changes is very important.
  • Identify major fears and unknowns that can negatively affect the outcome of a project. Make a proactive effort to address them at the start of the project.
  • Make responsibilities of all individuals involved in the project clear for accountability. Assign roles to them appropriately.
  • There should be a designated Project Manager whose role should be to maintain timelines, and escalate issues up to and from senior management. Asking a person in another role to also perform as a PM might not be effective always.

Day to day…

  • Obtain sign-off for technical decisions and have a general plan for proceeding if a sign-off is not made within a specific amount of time.
  • Daily standup meetings help a lot in keeping every one up to date on status and outstanding issues. There’s a lot to be learned from body language which might otherwise be lost in other forms of communication. However it is important to keep the meetings short – 10 to 15 minutes. There’s lots of literature about how the meetings should and shouldn’t be done. I’ll just say that you need to try out different things and pick the one which works best with the personalities of the individuals in the team.

In the meetings…

  • Long weekly meetings drain the energy out of people and consequently the project. While I have my doubts on whether people pay attention after 45 minutes on average, I have even stronger doubts on the effectiveness of the meetings that go on for more than 2 hours. There might be exceptions of course, and I’d be interested in knowing what they did differently.
  • After the weekly meeting, ensure that the meeting minutes are sent out describing each item discussed in the agenda along with the decisions made, open issues, and action items (assigning a person responsible).
  • Be on time in meetings. Try to attend the meetings physically instead of over phone.
  • Try to avoid taking calls on your cell phones during meetings – especially when you are actively involved in a discussion.
  • Making decisions based on consensus is not always effective. Making decisions without considering inputs from others is equally bad.

When conducting code / design / UI reviews…

  • If the process is to do design / code reviews in the meetings, to make the review more effective, try to restrict the number of attendees to the minimum absolutely necessary. Assigning reviewers to subsystems, if possible, might help in this regard.
  • When performing a code review ensure that you enforce the positive aspects of the code, while identifying the aspects that need improvement. Too many details are bad; only give as many specifics as you think are needed to send the developer whose code is being reviewed forward in the right direction. When performing a review, pay attention and make an honest effort to understand the problem being posed to you.

When your code / design / UI is being reviewed by someone…

  • When asking someone for a code / design review, make a dedicated effort to get their feedback. This might require you to spend an hour preparing a sample application to demonstrate the problem, but the time spent in it would be worth the effort. Be open to feedback. Negative feedback is still better than no feedback at all.

In general…

  • Do not shoot down ideas point blank. This erodes the enthusiasm of the contributors which is very difficult to get back. Make sure you identify the positive aspects of every idea.
  • Do not be afraid to hire temporary contractors and subject matter experts if required. That’s why a feasibility analysis is important.
  • When involving new people in a project, ensure that they have received adequate training on other internal products and frameworks as required.
  • If you’re required to use a common piece of code, ensure that it has an adequate test-bed. Secondly, push for dedicating engineering resources for their maintenance, depending of course on the size of the common code. If there aren’t any developers accountable for the upkeep of the common piece of code, you’re likely to lose the confidence of the developers who’re supposed to use it.

But most importantly…

  • Work to a level where you can be proud of your contributions tomorrow. In the end, that’s all that matters.

Leave a Comment

Post

Two (useless but potentially) interesting tid-bits

In .NET,General,Tech/Hacks on April 29, 2008 by Sid Tagged: , ,

Try-Catch-Finally

A try-catch-finally is converted into IL by the C# compiler as a try-catch inside the try block of another try-finally. This allows for finally block to execute even when exceptions are raised in the catch block. Use ildasm and check it out yourself!

throw football;

Though you cannot throw an arbitrary managed object as “throw myObj” (you’ll get a compilation error), you can modify the generated IL to do so. However your catch block will actually receive a RuntimeWrappedException in these scenarios. Why is this allowed? Well, unlike C#, it is legal to throw arbitrary objects in managed C++ and in those cases a RuntimeWrappedException is thrown too.

Leave a Comment

« Older Entries
« Back to Home