CSharp On The Fritz
See how sharp a Fritz can be
Fall 2012 Philly Code Camp Wrapup

I’m a bit late on this, but I wanted to document my experience at the Philly.Net Fall 2012 Code Camp.  This is a wrap-up post that I need to write more often, as these events are awesome ways to get connected and inspired from some of the developers in the community.

This year, I was caught between jobs for the Code Camp event.  This was the first time that I introduced myself as an “Independent Software Developer”.  I’m not sure how I felt about that.. but not something I need to worry about any longer.

My presentation this fall was “An Introduction to SignalR”.  I have posted my sample code and slidedeck on GitHub at:  https://github.com/csharpfritz/IntroSignalR 

This talk covered the concepts of what the “Realtime web” is and I ran through Damian Edwards excellently simple “Move Shape” demo.  This demo, for those who haven’t seen it, shows how to transmit information from one browser to another through the webserver with no interaction in the other browser.  During the talk, we did a deep-dive on the network interaction between browser and server as well as discussed how SignalR is designed to failover network connectivity based on client capabilities.

I showed a simple console application that could be configured with the SignalR  client library to listen for events from an Asp.Net webserver.  This strategy allows the client to stay connected over the network through network port 80, and thus require no changes to firewalls to maintain connectivity.

Finally, we wrapped up the session by bringing up the fun MMO sample game “ShootR” in our browsers and showing that realitime communications on the web can even power an “Asteroids-like” game.  You can find ShootR at:  http://shootr.signar.net

If there’s some interest, I’ll record a screencast covering this topic and post it here in the weeks ahead.  I will probably write up the content of the talk as a ‘How-To post’ in the next week or so, after I move the blog to its new home.

Finally, I am currently putting together a mid-level SignalR talk that will discuss using SignalR with WebForms and vendor’s control sets.  I hope to give this talk in the Spring at a user group near you.

Future is set: Telerik Asp.Net AJAX!

After last week’s events, the floodgates of opportunity opened, and I evaluated my options very closely.

It is with great pride that I announce:  On December 3rd I will be a Developer Evangelist with the Asp.Net AJAX product team at Telerik!

I’ve been a (quiet) fan of Telerik tools for the past two years.  It’s hard to miss the advertisements on the trade magazines, podcasts, and websites that I consume regularly.  After reviewing a handful of Telerik tools, they grew on me.  I’ve used JustCode for the last few months and find it to be a valuable asset in my daily coding tasks.  I’ve been using the AJAX Controls in a handful of prototypes and really enjoy the flexibility offered to me without having to focus on UI work.  It’s a good fit for me, as I believe I can share my infectious enthusiasm for this technology with others and bring great value to Telerik.

I’m going to still be the wise-cracking passionate Asp.Net developer.  I’m not going to turn into the Sham-Wow guy for Telerik overnight… but I will be using the Telerik tools in everything that I do.  

Those of you who have worked with me know: I am a very loyal and passionate employee who goes out of his way to ensure the success of my employer and my customers.  This is not a position I take lightly, and I feel that this attitude matches the role of Evangelist perfectly.  As an evangelist, I’ll be the technical conduit between sales, customer service, marketing, and the dev team.  I’m going to help take an award winning product and make it even better.

A colleague at my previous employer, after watching me coach a junior developer in a coding technique of some sort commented to me: “Jeff, you’re such a good trainer - you should do this more often.”  Little did I know at that time, just how right she was.  I presented at the Philly Code Camp last weekend (wrapup post to come), and that teaching buzz grabbed me after my session on SignalR, and it was then that I knew that I was so right for this position.

Over the next few weeks, you’ll see my blog ramp up.  I’ll be migrating to a better engine, a better layout, and LOTS more content.  You’ll see my twitter activity ramp up, my StackOverflow interactions ramp up, and most of all: you’ll start to find more video content from me.

The best part about this:  I will not be limited to my budget, or INETA’s budget in my travels to present at your event.  We’ll soon see what my availability looks like, but I’ll be doing a lot more travelling to some places that would NEVER be on my current travel itinerary.  I’m already getting my passport renewed so that I can depart from my friendly confines of the Northeastern United States to bring the good word of Asp.Net and Telerik to conferences and User Groups around the world.

My family and I are positively thrilled about this change, and I know that my teammates at Telerik are VERY eager for me to get started.  Stay tuned friends, because you’re going to get a lot more great content from yours truly!

Time for a change

The story is finally out:  After 7 years, I have been given my release by my former employer.  

I have no regrets about my time with that organization or how it ended.  There are many very talented individuals writing, testing, and analyzing some amazing code there. I had a great time working in their environment, and learned a lot from the size, scale, and agility of the development team’s practices.

I am actively speaking to some organizations about roles on their teams.  It is an exciting time for me, as one of these companies has shown significant interest… and I am positively thrilled to be considered for a position in their awesome organization.

In the short-term, I have a project or two that is occupying my time.  Additionally, I can now resume working on the qUnitMetro project, and I see a handful of feature requests out there begging to be answered.  They shall be handled in the weeks ahead.

I can also begin working on some long overdue blog articles as well as other publications that I am interested in.  There are a handful of screencasts inside me that are begging to be published… and I want to re-engage that process.

You’ll probably see a bit more of me in the next few weeks on Twitter and the blog discussing Asp.Net techniques, technologies, and c-sharp development practices.  I look forward to getting more involved with the community, and seeing where my future leads me.

You can find my details on LinkedIn at: http://www.linkedin.com/in/jeffreytfritz and you can contact me at: jeff@csharpfritz.com

It’s almost time for lunch… let’s eat!

Technical Debt or Evolutionary Design

I’ve had several interesting discussions over the last few weeks about the topic of “Technical Debt”.  Besides the negative connotation of the term, it is used to refer to a software design that was not fully implemented to meet a given set of requirements.  Another way to explain it is that developers “cut corners”.

Wikipedia defines Technical Debt as follows:

Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future.

Source: https://en.wikipedia.org/wiki/Technical_debt

In contrast, the Agile methodologies prescribe that software should be built in an evolutionary fashion.  This suggests that designs are crafted for only what is required at the time the software is written.  

This leads to an interesting crossroads.  In the early phases of writing a website, it is acceptable to optimize performance for a few hundred to a few thousand users as part of the requirements at that time.  The development team does not know the full scope of the traffic the website will receive, and performance can be tuned at a later date.  When visitor traffic patterns change, performance concerns start to become more noticeable.  

How should an agile team address these concerns?  Is it technical debt, or have the requirements for the system changed?

MongoDb scalability?

I’m attempting to use MongoDb as a session manager for Asp.Net and I’m seeing some immediate issues.  Consider:

  1. ASP.Net state is not stored and used in set based operations.  All queries from the webserver are key-based, which makes a NoSQL storage option ideal.
  2. MongoDb stores most of its data in RAM, which makes the queries lightning fast
  3. MongoDb can be sharded, allowing for the session data to be spread across multiple servers as your application grows.

The scalability of MongoDb lies in the 3rd item there - sharding.  When we refer to sharding the database, what is meant is that the database will split the contents of a database or even and individual table (or collection in the case of MongoDb) across multiple service instances.

The challenge with MongoDb is that the database service has a single write-lock.  This means that in high-write scenarios there can be contention for writing to the data-store.  The Gilt Groupe recommends keeping requests under 50/second:


Still others demonstrate performance that indicates we should keep our writes under 25/s:


In my state server scenario, we need to keep all writes “safe” - that is, they need to be written so that the next read will find the changes.  Using the numbers from the last benchmark, we should be able to see writes to a single MongoDb node in the neighborhood of 5000 per second.

In a very high-throughput application with several hundred thousand users accessing it concurrently, we will not be able to keep up with a single Mongo node.  This is where sharding will help us.  To manage 100,000 hits per second, we should distribute those writes across a 20-node MongoDb deployment.

Is this good performance?  Is this a valid scalability solution?  I look forward to your comments 

Forgotten c-sharp language features: implicit operator

Note:  This post has been added to The Code Project at: http://www.codeproject.com/Tips/452213/Forgotten-Csharp-language-features-implicit-operat

Every now and again, I run into a situation when coding that makes me think: “Isn’t there a native c-sharp feature that does this?”  … and today I hit another one of those situations.

I was writing some code to isolate the conversion of one class to another.  I knew this conversion was going to be done in several locations throughout my codebase, so I wanted to write the conversion once and re-use that function.

My initial impulse was to write a static class and use a .Net 3.5 extension method similar to those we see when using LINQ.  I wrote some code that looked like:

public static class Converters {
    public static Receipt AsReceipt(this Order myOrder) {

        return new Receipt {
            // set properties in the Receipt from the Order object


I could then call this code as follows:

Receipt thisReceipt = myOrder.AsReceipt();

Clean… simple… easy.

But then it hit me: I can do this automatically with the implicit operator keywords.  Here is the link to the technical article on MSDN describing the feature:


To summarize that article: this feature allows us to define how to implicitly convert to and from an enclosing user-defined reference type (a class) with a static method.  Sweet!  I moved my code from the static “Converters” class back into the Receipt class and it now looks like:

public class Receipt {

    // other properties and methods...

    public static implicit operator Receipt(Order myOrder) {

        return new Receipt {
            // set properties in the Receipt from the Order object

and now my code to perform the conversion looks like this:

Receipt thisReceipt = myOrder;

That made my code so much easier to manage without having to litter static classes with conversion functions or use interfaces throughout my code.  As an additional benefit, now my Receipt object is now aware of how to convert to and from other types.  I prefer the isolation of this conversion logic, as it keeps me from searching my codebase to determine how best to convert from one custom type to another.

If you would prefer to be more declarative in the conversion statement, there is also an explicit operator keyword that you can use in the same fashion.  If you were to mark the conversion function as explicit operator, the usage statement would then look like this:

Receipt thisReceipt = (Receipt)myOrder;

We still maintain a very simple syntax that is descriptive of the code operation desired.  


These operator keywords are a powerful tool, one that many of us don’t know about or we forget that they are available to us.  Let’s try to make better use of these native language features, as they will help us improve our class design by keeping all of our object’s conversion concerns in one location.

I have a few more of these ‘forgotten features’ that I’ll highlight over the next few weeks.  I hope you check back to catch some of the other language features that I intend to discuss in the future.

Until next time, may all your code compile, and all of your unit test pass!

Should I submit to CodeMash?

This is a tough one for me..  I am not usually one to stray from the spotlight, but I saw Jim Holmes post on Twitter that CodeMash is now open for speaker submissions, and I got nervous.

CodeMash is a different conference for me.  I have only ever spoken at User-Group and CodeCamp conferences… this would be my first “pay to attend” conference that I would be submitting to.  

Additionally, the timing for CodeMash is goofy for me.  My wife just started back to college full-time and my daughters both attend elementary school.  CodeMash is scheduled for the middle of the first week of January, in Ohio… a good 8 hour drive from home.

I’m nervous about this one… a first for me.  I think I gotta do it.. after all, I’ve already given a shot at Tech Ed 2012.  How am I going to feel when THAT call for submissions goes out?

You may have heard of me before…

Okay okay… I’ve made the rounds on the internet over the past few weeks:

I’ve been discussing all kinds of good things surrounding the Windows 8 release and coding applications with WinJS, particularly using my open source tool QUnitMetro.

For the next few weeks, I am completing a pair of Windows 8 applications and preparing a series of presentations that I will be giving at the following events:

Its going to be an absolute thrill to be at these three events where I know I’ll run into some of my favorite voices in the .Net community, and get to discuss all of the new bits from Microsoft…

Additionally, I’ve had several inquiries about unit testing strategies…  After my initial ‘test screencast’ a few weeks ago, I’ve started outlining a series of ‘unit testing recipes’ that I’ll be making available.  Depending on interest, we’ll see where these screencasts land  ;)

I hope to see you at one of my events in September.  Thanks for reading!

C-Sharp Casting of Types

This post is a response to an article from a series of posts from Iris Classon called “Stupid Questions”, and this particular article discusses the preferred way to cast types in c-sharp.  


So… how should we cast a type in c-sharp?  The ‘as’ keyword gives us the capability of casting reference types without an error.  In other words, if you are attempting to cast to a type that is NOT supported by the type submitted, no error is thrown.  This is a VERY good thing.

For reference, if you are casting a value type (int, long, double, decimal) you don’t have the choice of using the “as” statement.  Instead, you will need to use a Convert.ToInt32() statement (or something similar) to change types.  However, this discussion isn’t about value types…

Consider: If you want to ensure that an object is cast properly to another type, you will need to wrap your direct cast statement in a try-catch block to ensure that no error is thrown.  Your statement will look similar to the following:

            var c = new object();

                var x = (Customer)c;
            catch (Exception e)

This seems like a very simple statement, and an acceptable way to handle the scenaro.  The same operation with an “as” clause will look like:

            var c = new object();

            var x = c as Customer;
            if (x == null)
                Console.Out.WriteLine("Did not cast properly");

But lets look a little closer at the IL (Interpreted Language) generated by the compiler by these two examples.  First, the direct cast:

.locals init ([0] object c,
           [1] class CastDemo.Customer x,
           [2] class [mscorlib]System.Exception e)
  IL_0000:  nop
  IL_0001:  newobj     instance void [mscorlib]System.Object::.ctor()
  IL_0006:  stloc.0
    IL_0007:  nop
    IL_0008:  ldloc.0
    IL_0009:  castclass  CastDemo.Customer
    IL_000e:  stloc.1
    IL_000f:  nop
    IL_0010:  leave.s    IL_0023
  }  // end .try
  catch [mscorlib]System.Exception 
    IL_0012:  stloc.2
    IL_0013:  nop
    IL_0014:  call       class [mscorlib]System.IO.TextWriter [mscorlib]System.Console::get_Out()
    IL_0019:  ldloc.2
    IL_001a:  callvirt   instance void [mscorlib]System.IO.TextWriter::WriteLine(object)
    IL_001f:  nop
    IL_0020:  nop
    IL_0021:  leave.s    IL_0023
  }  // end handler
  IL_0023:  nop
  IL_0024:  ret

You can clearly see that the Try statement is ALWAYS fired in the first example… we will always run through the test for the exception.  In fact, the exception object is already allocated in memory on the first line!  Additionally, the call to castclass on line IL_0009 is where we attempt to make our conversion.. if no error is thrown, it jumps to line IL_0023.

… and then the IL for the “as” statement example:

  .locals init ([0] object c,
           [1] class CastDemo.Customer x,
           [2] bool CS$4$0000)
  IL_0000:  nop
  IL_0001:  newobj     instance void [mscorlib]System.Object::.ctor()
  IL_0006:  stloc.0
  IL_0007:  ldloc.0
  IL_0008:  isinst     CastDemo.Customer
  IL_000d:  stloc.1
  IL_000e:  ldloc.1
  IL_000f:  ldnull
  IL_0010:  ceq
  IL_0012:  ldc.i4.0
  IL_0013:  ceq
  IL_0015:  stloc.2
  IL_0016:  ldloc.2
  IL_0017:  brtrue.s   IL_0029
  IL_0019:  call       class [mscorlib]System.IO.TextWriter [mscorlib]System.Console::get_Out()
  IL_001e:  ldstr      "Did not cast properly"
  IL_0023:  callvirt   instance void [mscorlib]System.IO.TextWriter::WriteLine(string)
  IL_0028:  nop
  IL_0029:  ret

This snippet shows that the code on line IL_0008 checks for the instance type and on line IL_0017 will exit the method if the variable is set to null.  The difference in our safety check is that the second example is directly asking if the type was converted properly, instead of relying on the try-catch to rescue us when the code doesn’t behave properly.

The performance cost of the try-catch block is trivial, a few microseconds on each call.. but the practice that is troubling here is the use of try-catch to control flow.

In computer science, we define “control flow” as the order in which coded statements are executed.  We can control flow with constructs like if, switch, and for.  If you suspect that your try-catch wrapping the cast statement is going to fail ‘regularly’ and that the catch will not truly be an ‘exceptional’ case… then you are using the try-catch to control flow.  This is considered an anti-pattern, as it changes the intent of the catch clause.

Consider:  if you have coded a catch block that traps the abstract Exception object, you have now hidden EVERYTHING that could possibly go wrong with your cast statement.  There are plenty of reasons why your cast failed, and the exception that the runtime will throw when your cast fails is System.InvalidCastException  If you need to go this route, then catch this exception, because otherwise you are hiding all kinds of events that COULD be happening to your application.

Either of these techniques is valid for casting variables.    I hope this gives some insight into what the CLR is doing when you cast types, and also demonstrate good practices when converting reference types in c-sharp

This is my first screencast in a planned series of videos that will demonstrate and discuss some unit testing and test driven development practices that I have found to be useful.  In this video, we verify that a RESTful client is communicating with a webserver by redirecting it to a hosted NancyFX server under our control.