The Jenkins video always makes me laugh. It’s the short and sad tale of a man who doesn’t have the patience for planning, nor the stamina for statistical analysis. He’s a man who leaps into action without thought of consequence. To Leeroy, there are no 50,000 foot views, no discussions, and … no tomorrow. In the video you can watch as Leeroy’s guild is decimated by dragons who take advantage of the chaos provided by Leeroy’s thoughtless actions.
You might be thinking I’m going to liken Leeroy to the developer who writes 200 lines of untested code inside a method named “SubmitOrder” before his team has even left the conference room where they are discussing what the software is supposed to do – but I’m not going to make that analogy.
Well, not that exact analogy.
I think there is a time and a place to get some Leeroy into your life. I’m always amazed at email threads where participants debate the possible outcomes of psuedocode when it would easier to just jump in and let the computer decide the outcome.
When in doubt – just write the code (preferably with a Leeroyesque shout). Thought experiments are for physicists!
I’ve had an XM radio subscription for a couple years now but I’ve never been entirely happy with any of the options for XM Radio Online. XM’s online player has changed very little over the years, and it is missing many simple features you can find in other third party players and real radio hardware – like artist and song notifications. A couple days ago I started to think about just writing my own XM radio player for the heck of it.
The first step was to see what goes on between the browser and the server when streaming music. Note: this is an attempt to build a legitimate custom player to use with an XM subscription – not an attempt to get XM programming for free.
Fiddler is my tool of choice for web traffic sniffing. If you are just looking for tools to monitor the JSON payload sizes for an AJAX-ified web page, then there are a million tools and plug-ins with this functionality. Fiddler goes well beyond the entry level sniffing tool and touts itself as an HTTP debugger. You can set breakpoints, tamper with requests, build requests (from scratch, or by dragging and dropping a request from the list of previous requests), force requests to trickle (to simulate slow networks – great for testing SIlverlight splash screens), and extend Fiddler with managed code. There is also a CustomRules.js file that one can use to quickly extend and customize Fiddler using JScript.NET. As an example, the following code will place a new “Hide CSS” option in the Fiddler Rules menu and declare a variable to store the state of the menu item:
public static RulesOption("Hide CSS requests") var m_HideCSS: boolean = false;
To hide CSS requests when the menu item is checked, add the following to the OnBeforeRequest function:
if(m_HideCSS) { if(oSession.uriContains(".css")) { oSession["ui-hide"] = "hiding css"; } }
There are dozens of other useful rules in the Fiddlerscript cookbook.
Perhaps the most unknown feature in Fiddler is the QuickExec box (or at least I didn’t know about QuickExec until recently). QuickExec is the little black box at the bottom of the recorded session list. The box serves as a command line interface to Fiddler, and you can use QuickExec to filter the session, perform string matching, set breakpoints, launch a web browser, and more. There is a video demonstration for QuickExec available, and a list of default commands. If you use Fiddler regularly it’s worth your time to learn QuickExec and find the shortcuts that make your job easier.
It only takes a few minutes with Fiddler to figure out the four important endpoints for XM radio online.
This was enough information to decide that building a custom player isn’t terribly difficult. The next step was to write some .NET code just to prove there wasn’t any technical hurdles in walking through these 4 endpoints. We’ll look at that in Part II.
Jeremy’s post “Don’t Check In Spike Code” reminds of something I’ve advocated for years: dedicate a place in your source control repository where each developer can check in their “experimental” code. The rule of thumb is to throw away code you write for a spike, but all code can be valuable, even if it isn’t production worthy.
Here are the kinds of things I’ve checked into “experiments/sallen” over the years:
I’ve found that keeping a dedicated area for these types of check-ins offers some advantages:
If nothing else, you can look back at what you wrote when you were spiking on a new technology and laugh in that “oh man, we really didn’t know what we were doing ” way.
There is a lot of humor in the Bad Variable Names entry on the c2 wiki. I like this confession from Alex:
The worst of which was my counter variable names. I now use i, j, k, and so on for local counts and things like activeRowCount for the more descriptive names. Before, in the early years mind you, it shames me to say, I would name my counters things like Dracula, Chocula*, MonteChristo. They are all counts after all. I apologize for my intial variable naming conventions and shall go beat my face now as punishment.
(*If you are not familiar with Count Chocula, he’s the mascot of a chocolate flavored breakfast cereal of the same name. The cereal is popular in America, as is any corn based cereal that mixes chocolate and sugar.)
One letter variable names are considered bad, unless you need a loop counter (i), a spatial coordinate ( x,y,z) …
… or you’re writing a lambda expression:
var query = employees.Where(e => e.Name == "Tom");
This isn’t just C# – other languages also encourage short variable names in nested function definitions. The short names have been bothering me recently, particularly when the chained operators begin to work on different types.
var query = employees.GroupBy(e => e.Name)
.Where(g => g.Count() > 2)
.Select(g => g.Key);
LINQ joins are particularly unreadable. There is a piece of code I wrote in a presenter class many months ago, and every time I see the code I wince.
var controlsToEnable = results.SelectMany(r => r.RequiredFields) .Join(mapper.Entries, ps => ps.PropertyName, e => e.Left.PropertyName, (ps, e) => e.Right) .Select(ps => ps.GetValue<IAnswerControl>(_view));
I’ve been thinking that one way to improve the readability is to use a custom Join operator. The types used in the query above are PropertySpecifier<T> and MapEntry<TLeft, TRight>. The idea is to join property specifiers against the left hand side of a mapping entry to retrieve the right hand side of the mapping entry (which is another property specifier). The extension method has a lot of generics noise.
public staticIEnumerable<PropertySpecifier<TRight>> Join<TLeft, TRight>(
thisIEnumerable<PropertySpecifier<TLeft>> specifiers,
IEnumerable<MapEntry<TLeft, TRight>> entries)
{
return specifiers.Join(entries,
propertySpecifer => propertySpecifer.PropertyName,
mapEntry => mapEntry.Left.PropertyName,
(propertySpecifier, mapEntry) => mapEntry.Right);
}
At least the custom Join cleans up the presenter class query, which I also think looks better with more descriptive variable names.
var controlsToEnable = results.SelectMany(result => result.RequiredFields) .Join(mapper.Entries) .Select(property => property.GetValue<IAnswerControl>(_view));
For the time being I'm going to avoid one letter variable names in all but the simplest lambda expressions.
Once you know about the magic of Expression<T>, it’s hard not to make use of it.
Or perhaps, abuse it.
Here is an excerpt of a class I wrote that uses Expression<T> as a reflection helper.
public class PropertySpecifier<T> { public PropertySpecifier( Expression<Func<T, object>> expression) { _expression = (expression.Body) as MemberExpression; if (_expression == null) { // raise an error } } public string PropertyName { get { return _expression.Member.Name; } } // ... MemberExpression _expression; }
I use the class to attach metadata to my flowchart shapes about which pieces of data they require via a RequiresField extension method.
.WithShape("FibrinolyticTherapy")
.RequiresField(pd => pd.FibrinolyticAdministration)
The property specifier allows me to find, by name, the property the expression is touching, and also build dynamic getters and setters for the property. For my flowcharts,once each shape is associated with its required data, I can query the flowchart evaluation results to find out what pieces of information the flowchart requires the user needs to enter. This information can be used to selectively enable UI controls.
var controlsToEnable = results.SelectMany(r => r.RequiredFields) .Join(mapper.Entries, ps => ps.PropertyName, e => e.Left.PropertyName, (ps, e) => e.Right) .Select(ps => ps.GetValue<IAnswerControl>(_view));
Now, that particular piece of code is something I’m not too happy about, but more on that in a later post. This code is in a presenter class and joins the PropertySpecifier objects the flowchart requires with PropertySpecifer objects that reference a view class. The query essentially turns Expression<T> metadata into cold, hard Control references with no magic strings and strong typing all the way down. It’s also easy to write unit tests using some reflection to ensure all properties are mapped, and mapped correctly.
All that is needed is a property map to store the associations between model data and view controls. This starts with a PropertyMapEntry class.
public class PropertyMapEntry<TLeft, TRight> { public PropertySpecifier<TLeft> Left; public PropertySpecifier<TRight> Right; }
And a PropertyMapper.
public class PropertyMapper<TLeft, TRight> { public PropertyMapper() { Entries = new List<PropertyMapEntry<TLeft, TRight>>(); } public List<PropertyMapEntry<TLeft, TRight>> Entries { get; set; } }
And a fluent-ish API to build the map.
static PropertyMapper<PnemoniaCaseData, IPnemoniaWorksheet> mapper = new PropertyMapper<PnemoniaCaseData, IPnemoniaWorksheet>() .Property(cd => cd.ChestXRay.Length).MapsTo(v => v.ChestXRay) .Property(cd => cd.ClinicalTrial).MapsTo(v => v.ClinicalTrial) // ... ;
I’m pretty happy with how it worked out – at least it looks like this will produce v 1.0 of shipping product. Yet I still wonder if I’m using Expression<T> for evil or for good. What do you think?
In the last post we talked about needing some Expression<T> background. There is a lot of good information out there about Expression<T>, but if you haven’t heard – this class is pure magic. If you want a long version of the story, see “LINQ and C# 3.0”. For a short version of the story, read on.
.NET compilers like the C# and VB compilers are really good at converting code into an intermediate language that the CLR’s JIT compiler will transform into native code for the CPU to execute. So if you write the following …
Func<int, int> square = x => x * x; var result = square(3); // yields 9
… and you open the assembly with a tool like Reflector, you’ll find the IL instructions created by the compiler.
ldarg.0
ldarg.1
mul
stloc.0
That essentially says – load up two arguments, multiply them, then store the result. These instructions will be part of an anonymous method (as lambda expressions are just a shorter syntax for writing an anonymous method), and you can invoke the method by applying the () operator to the square variable to compute some result. IL is the perfect representation for code that ultimately needs to execute, but it’s not a great representation of the developer’s orginal intent. As an example, consider the following.
var query = ctx.Animals .Where(animal => animal.Name == "Fido");
If ctx.Animals is an in-memory collection of objects, then compiling the code inside the Where method will generate efficient instructions to search for Fido. That’s good – but what if Fido lives in a database, behind a web service, or in some other remote location? Then a LINQ provider needs to translate the code inside the Where method into a web service call, a SQL query, or some other type of remote command. The LINQ provider will need to understand the programmer’s intent of the code inside the Where method, and IL is not designed to express this intent. We don’t want LINQ providers “decompiling” programs at runtime. Thus, we have Expression<T>.
Expression<Func<int, int>> square = x => x * x; var result = square.Compile()(3); // yields 9
Wrapping our function inside an Expression produces something we can’t invoke directly – we have to .Compile the expression before we can invoke it and capture a result. This is because the .NET compilers don’t produce IL when they come across an assignment to Expression<T> - instead they produce a data structure known as an abstract syntax tree (AST). ASTs aren’t the prettiest things to look at, but they are a better representation for the code if you need to figure out what the code is trying to do. The AST for the Fido search will tell us the code consists of a binary expression that tests for equality, and that the left hand side of the equality test is the animal’s name, and the right hand side is a string constant “Fido”. This is enough information for a remote LINQ provider to translate the expression into something like “WHERE Name = ‘Fido’”.
Expression<T> gives us the ability to treat a piece of code as data, which is a relatively old concept (hello, LISP!) and fairly powerful. It gives us the ability to walk through “code” at runtime and examine what it intends to do. This feature facilitates all of the remote LINQ query providers, like LINQ to SQL and the Entity Framework, because they can examine the AST and formulate commands that represent the original code in a different language (SQL). This translation is far from simple, but it would have been impossible if the compiler was generating IL instead of syntax trees.
There are additional scenarios that Expression<T> enables that have nothing to do with queries or databases, which is where Expression<T> gets exciting because you can use it in places you may not have expected, like in a business layer, or a mapping layer, or in the flowcharts I was working on.
flowChartShape.RequiresField(casedata => casedata.SmokingCounseling)
You can think of the RequiresField method call as something that can add metadata to a flowchart shape, and this metadata describes the property on some data object that the shape will use during execution. The metadata is strongly typed, intelli-sensed, and refactor friendly. We can use the metadata at runtime to determine what fields to enable in the UI, or what fields are missing that a user needs to address. We’ll dig into this more in a future post.
In a previous post, I talked about modeling flowcharts with C# code. The flowcharts are designed, documented, and standardized by a non-profit organization charged with measuring the quality of patient care inside of hospitals. They do so by looking at common cases that every hospital will see, like heart failure and pneumonia patients. The logic inside each flowchart can determine if the hospital followed the “best practices” for treating each type of case. Some of the logic becomes quite elaborate, particularly when evaluating the types of antibiotics a patient received, and the antibiotic timings, relative orderings, and routes of administration.
Sitting down with 100 of pages of flowchart logic was intimidating, and realizing that new versions came along every six months was enough to induce fear. I experimented with a few visual tools and rules engines but nothing was making the job easy and producing a maintainable solution.
From the beginning I also was thinking about a domain specific language. At one point I decided to sit down with pen and paper to write down what I saw in the flow charts and what I thought a DSL might look like:
a flowchart for pneumonia case data
has a shape named “Smoking History”
with an arrow that points to “Smoking Counseling” if the patient DOES smoke
and an arrow that points to the shape “…” if patient DOES NOT smoke
has a shape named “Smoking Counseling”
with an arrow that points to …
Not great, but it wasn’t too hard to read. It also made me realize that only a few simple abstractions were needed to make an executable flowchart. Flowcharts contain shapes, and shapes contain arrows, and each arrow points to another shape and has an associated rule to evaluate and determine if the arrow should be followed. I showed the code to a couple of these classes in a previous post.
The only hard part then would be correctly assembling shape, arrow, and rule objects into the proper hierarchy for evaluation. One option was to parse instructions like the text that I had put down on paper, but I wanted to try something simpler first.
“Object graph” is a computer scientist’s term for a collection of related objects. I needed to arrange shapes, arrows, and rules into an object graph. We deal with object graphs all the time in software. ASPX files describe an object graph that is assembled at runtime to emit HTML. An even better example is XAML - the XML dialect for WPF, Silverlight, and WF. XAML is the direct representation of a hierarchical graph of CLR objects. I considered what a flowchart might look like in XML.
<Flowchart Name="Pnemonia Measure 6" CaseDataType="PnemoniaCaseData"> <Shape Name="Smoking History"> <Arrow PointsTo="Smoking Cessation" Rule="?" /> </Shape> <Shape Name="Smoking Counseling"> <!-- ... --> </Shape> <!-- ... --> </Flowchart>
The one stickler was how to represent the rule for an arrow. There are mechanisms available to represent expressions and code in XML (XAML’s x:Code directive element and serialized CodeDom objects ala WF rule sets are two examples), but code in XML is always tedious, cumbersome, and worst of all - impervious to refactoring operations.
Not to mention, I think many developers today are feeling “XML fatigue” – me included. Five years of XML hyperbole followed by 5 years of software vendors putting everything and anything between < and > will do that.
The other option was to assemble the flowchart using a fluent interface in C# – a.k.a an internal DSL. Chad Myers recently posted some excellent notes on internal DSLs, which he defines as “…bending your primary language of choice to create a special syntax that’s easier for the consumers of your API to use to accomplish some otherwise complicated task”. Chad also has notes on the method chaining pattern, which is the approach I took.
First, I needed an extension method to add a Shape to a Flowchart…
public static Flowchart<T, R> WithShape<T, R>(
this Flowchart<T, R> chart, string shapeName) { Shape<T, R> shape = new Shape<T, R> { Name = shapeName }; chart.Shapes.Add(shape); return chart; }
…and another extension method to add an Arrow to a Shape. The trick was realizing that the arrow would always apply to the last shape added to the flowchart.
public static Flowchart<T, R> WithArrowPointingTo<T, R>(
this Flowchart<T, R> chart, string pointsTo) { Arrow<T> arrow = new Arrow<T>(); arrow.PointsTo = pointsTo; chart.LastShape().Arrows.Add(arrow); return chart; }
Similarly, a Rule always goes to the last Arrow in the last Shape:
public static Flowchart<T, R> AndTheRule<T, R>(
this Flowchart<T, R> chart, Func<T, bool> rule) { chart.LastShape().LastArrow().Rule = rule; return chart; }
Using the API looks like:
new Flowchart<PnemoniaCaseData, MeasureResult>() // ... .WithShape("AdultSmokingHistory") .RequiresField(pd => pd.SmokingHistory) .WithArrowPointingTo("Rejected") .AndTheRule(pd => pd.SmokingHistory.IsMissing) .WithArrowPointingTo("Excluded") .AndTheRule(pd => pd.SmokingHistory == YesNoAnswer.No) .WithArrowPointingTo("AdultSmokingCounseling") .AndTheRule(pd => pd.SmokingHistory == YesNoAnswer.Yes) .WithShape("AdultSmokingCounseling") .RequiresField(pd => pd.SmokingCounseling) .WithArrowPointingTo("Rejected") .AndTheRule(pd => pd.SmokingCounseling.IsMissing) .WithArrowPointingTo("InDenominator") .AndTheRule(pd => pd.SmokingCounseling == YesNoAnswer.No) .WithArrowPointingTo("InNumerator") .AndTheRule(pd => pd.SmokingCounseling == YesNoAnswer.Yes) .WithShape("Rejected")
.YieldingResult(MeasureResult.Rejected) .WithShape("InDenominator")
.YieldingResult(MeasureResult.InMeasurePopulation) .WithShape("InNumerator")
.YieldingResult(MeasureResult.InNumeratorPopulation);
Overall I was happy with how quickly we were able to pound out flowcharts using the fluent API. The code is relatively easy to compare to the original flowcharts in the specifications (although with the larger flowcharts, nothing is too easy). It’s also easy to test, diff-able after check-ins, and still works after refactoring the underlying data model. The real measure of success though, will be how well the code stands up to the changes and revisions over time. The verdict is still out.
In a future post I’d like to tell you about the .RequiresField method, as it drove a number of key scenarios in the solution. First, we’ll have to talk about the magic of Expression<T>…
OdeToCode by K. Scott Allen
Subscribe
Twitter
Search
About
Learn C#