Bill Blogs in C#

Bill Wagner discusses C#, LINQ, and other items of interest

July 2007 - Posts

We now have physical office space
Well, it’s official.  After several years of working out of our homes, coffee shops, the IT Zone, and onsite at customer sites, we’ve left the ranks of virtual businesses and rented office space.
 
Why did we do this?  Why now?
 
Well, we have several projects running at the same time now, and it’s just getting too difficult to run everything virtually. Skype, IM, email and phones work, but a whiteboard,  drawings, and discussions can be more efficient.
 
In addition, we plan on adding more projects as the year goes on. That means even more developers working with us, and they need space. Now, we have that.
 
And finally, the organizations responsible for growing the business community have changed their focus recently. They now are singularly driven to grow VC backed businesses with the standard ‘hockey-stick’ growth curve.  That’s not us.  Our growth has been steady, but not meteoric. On the other hand, we have not taken on debt (from friends and family, banks, angels, or VCs).  We’ve been fortunate in that we have been able to grow our business totally on revenue from customers. I don’t fault these organizations for focusing on these high-growth opportunities. The rewards might be great. Of course, the risks are great as well. But, the end result for our company is that resources previously available to us, and other small companies like ours, are no longer available.
 
Which gets to the most important reason for opening an office: We are now in a financial state where taking on the additional cost of an office (everything from rent to furniture to utilities) is not a risk. It’s an important investment that we hope will continue to grow the business.
 
So where are we?
 
We’re in Suite 200 at 206 S. Fifth Street, in downtown Ann Arbor.  There’s some build out that has to happen (nothing much, mostly new carpet and paint), and some furniture to buy. Within the next month or so, we should be ready to move in and host an open house.
 
It’s exciting.
 


Posted by wwagner | with no comments
Filed under:
and method invocation precedence

I got the following question about extension methods in email, and I thought it's of general interest, so I will answer it here:

When the CLR is looking at extension methods and the built in methods on a class – what is the order of precedence. Do you know?

Does it look at the extension methods first or the static methods that are on the class?

That's two questions, and I'll start with the second one. You can't call static methods declared on a type using the object.MethodName invocation syntax.  The compiler will force you to use TypeName.MethodName to call a static method declared on a class. Furthermore, you can't declare extension methods inside the intended target type because extension methods must be declared inside a static class. The C# language rules do enforce some reasonable behavior on declaring and using extension methods, or any static method.

Now, let's get to the important question: who wins, extension mehods, or some other candidate method? The answer is in §26.2.3 of the C# Language Spec:

"...if the normal processing of the invocation finds no applicable instance methods (specifically, if the set of candidate methods for the invocation is empty), an attempt is made to process the construct as an extension method invocation..."

Paraphrasing, that means the following:

The compiler first looks for any suitable method (ignoring extension methods altogether). This search includes accessible methods declared on the type, and accessible methods declared on any of its base classes.  It also includes any candidate generic methods declard on the type, and any of its base classes:

obj.MethodName( args );
obj.MethodName< TypeArgs >.( args );

If the set of candidate methods is empty, then the compiler will search any extension methods that are in scope.

The short version: extension methods always lose to other candidate methods when seeking the best invocation match. 

Postscript:  You can get yourself into strange situations if you declare multiple extension methods with similar signatures.  But that'sthe topic of another post.



Posted by wwagner | with no comments
Filed under: ,
ADO.NET Entity Framework Talk

This is a must-see.  Julie Lerman has been diving into the ADO.NET Entity Framework for quite some time, and she knows as much about it as anyone outside of Redmond.  Here's the abstract:

The Entity Framework is the core of Microsoft's evolving data platform and has many layers of abstraction to give developers access to data, client-side views and schemas, as well as mapping of data to objects. This session will give you an understanding of what the Entity Framework is all about. We will inspect it's most important moving parts and learn basics of querying with Entity SQL and LINQ to Entities. You will also learn how to easily leverage its highest level of abstraction in common databinding scenarios. Lastly the session will tempt you with the potential of more complex scenarios and ways in which Microsoft is building services on top of the Entity Framework.

More information here:  http://www.migang.org

And, if you are closer to Lansing than Southfield, she's speaking there on Thursday: http://www.glugnet.org/

Make the time to see it.



Posted by wwagner | with no comments
From the joint AACS / AADND meeting

I've finally uploaded my samples and slides from last Wednesday's joint AACS / AADND meeting.  You can grab them below.



Slide deck
Generic things besdes collections
Samples
A small tool that looks at process statistic

Posted by wwagner | with no comments
Filed under:
Creating mixins with interfaces + extension methods

My latest C# article has been posted on MSDN Online: http://msdn2.microsoft.com/en-us/vcsharp/default.aspx.  This article discusses how you can use extension methods to provide implementation reuse for functionality supported by an interface.

Teaser quote:

The .NET Framework made extensive use of this in the upcoming Orcas release with the Enumerable class and the Queryable class. Enumerable contains more than 30 methods that are injected into the methods supported by IEnumerable<T>. Any class that implements IEnumerable<T>, which contains 1 method, GetEnumerator(), suddenly supports more than 30 operations

Footnote:  If you visited the site yesterday, you saw the article was posted, but the teaser and byline still referenced Mark Michaelis's previous article. Charlie Calvert quickl got that corrected.  Thanks Charlie!



Posted by wwagner | with no comments
Filed under:
where 2 + 2 = 5, for large values of 2

I had a question last week about floating point accuracy.  A customer was having some issues with a sampling algorithm that was supposed to grab timings every 0.0125 seconds. As he sampled data, he returned the elapsed time with every sample.  The timing values in the returned structure weren't what he expected. 

He was being bitten by the rounding that takes place in all floating point math. 

Inside his code, he was adding 0.0125 to a running sum with every iteration.

Instead, to get avoid accumulating the error everytime, you need to keep track of the number of samples (an integer, with no rounding error), and calculate the elapsed time in one multiplication.

Here's a sample that demonstrates the difference:

static void Main(string[] args)
{
    double interval = 0.0125;
 
    double sum = 0;
    double product = 0;

    for (int i = 0; i < 100000; i++)
    {
        product = interval * (i+1);
        sum += interval;
        Console.WriteLine("Sumation: {0,15}, Product: {1,15}", sum, product);
    }
}

Go ahead and run the code yourself to see the difference.

The lesson: There is always rounding in floating point math. Make sure you structure the operations so that you minimize any accumulated rounding error. In this case, it's a simple matter of replacing the repeated additions with a single multiplication. Your mileage may vary, but it's always important to remember these issues.

 



Posted by wwagner | with no comments
Filed under:
Two resources, with different histories

I've started reading Marc Andreessan's blog recently (http://blog.pmarca.com/). I find it interesting to contrast Marc's view on everything with Eric Sink's blog (http://software.ericsink.com/

For those of you outside the business, a little perspective may be necessary. Both men are fellow University of Illinois Alumni. (At almost the same time, I think). The biggest difference is in the type of careers they've had.  Marc was one of the founders of Netscape, and has since been involved in several tech startups, as an investor, founder, or director, or some combination of them.  (His current project is Ning, www.ning.com). Marc long ago left the cornfields of the midwest for the culture of Silicon Valley.
Eric, on the other hand, has been involved in a few startups that were self-funded.  His current company is Source Gear (www.sourcegear.com). And, of course, he's Not a Legend (http://notalegend.com)

The contrast between these two men is pertinent for the Southeast Michigan area, which is trying to diversify its economy away from its heavy automotive roots. Marc Andreessen's career is a series of highlights: Big money deals, some of which succeeded beyond expectations, and some of which were tremendous busts. Eric, on the other hand, has been slowly but surely building a small to medium size company with a real market and a real product. They are both successful, but in very different ways.

Both of their blogs are interesting reads.  Marc's discusses the world of high finance, raising capital for startups, At times it feels like everything is at a rushed pace. Grow fast, develop product fast, hit the right market fast, and liquidate fast. All the risks are big, and all the potential rewards are big too. Eric's blog discusses how he built Source Gear while in Champaign. There was less venture capital available (he was in Champaign after all), the market he entered (developer tools) wasn't one of those classic 'hockey stick growth curves'. As a result, he simply focused on product, the market, and building the company.

Both are interesting reads, but with a different focus. 

So, what does this have to do with business in Southeastern Michigan?

Well, some of the advice is clearly applicable anywhere: focus on your market, (high tech only) recruit and retain a great product team, don't waste money, and preserve your reputation at all costs.

However, the differences between growing a company slowly (like Eric) and getting on the VC roller coaster (like Marc) are striking. I'm not taking anything away from Eric, but there is less risk in the slower growth path than in the VC funded path. (Note 'less risk' here is comparing a moon landing with a mars landing. Neither should be considered easy, or safe.)

And Marc is very blunt in his commentary about the pull (both logical and physical) that VCs will exert on their funded companies. So because of that, I'm concerned about current public policy in Michigan focusing on VC funded startups to the exclusion of everything else.  In short, we need every Eric Sink in our back yard to stay, and grow, and be encouraged. Of course, if another Marc Andreessan is around, we need him to stay as well.



Posted by wwagner | with no comments
Filed under:
Or an Enigma, and a sunken submarine

Part of the silence on the blog has been that our family to a week long vacation on the Outer Banks of North Carolina. 

One of the sights we visited was the newly opened Graveyard of the Atlantic Museum (http://www.graveyardoftheatlantic.com/).  It's very small, but the collection and the information was fantastic.

One historical note I didn't know:  During World War II, German U Boats had been attacking shipping lanes just off the Outer Banks.  One of the subs was sunk near Hatteras.

Just recently, dive teams recovered the parts from the Enigma machine used on that sub. The super cool part about it being a small museum is that currators were photographing and catalogging parts the day we were there.  We go to chat about the recovery operation, the salvage and restoration operation, and about cryptography in general.

Pics:



Posted by wwagner | with no comments