Recently I’ve been interested in incorporating more automated testing in my projects. The benefits of having tests are heavily covered in other topics so I won’t waste time explaining why I sat in on a few sessions at this year’s Code Camp NYC focusing on automated testing. Needless to say a few of the sessions was all it took to push me into getting my feet wet.
I decided to start out on a demo project just so I didn’t dirty up any formal projects while I tried out the best approach to implementing the tests. I recently created a project to check out ASP.NET Web API as a progressive download host (which allows for streaming video to iOS devices, allows downloads to be chunked and resumed by download managers, etc.) This seemed like a good candidate for tests since the behavior of the library changes based on the HTTP request headers for a resource.
(Update 2014-12-10: The code is now in GitHub and a package is available as a NuGet Package. See the announcement about it.)
Some time ago I read an interesting Stack Overflow question asking about streaming videos to iOS devices from ASP.NET MVC. In researching the answer, I learned about parsing HTTP request headers and constructing responses. In general for iOS devices to support playing video a web server needs to understand requests with the RANGE header and respond appropriately with 206 (PartialContent) and a CONTENT-RANGE header which more or less repeats the original request range.
I originally wrote an answer to this effect but also wanted to test it out to make sure it worked in ASP.NET MVC. While successful, it was not particularly elegant. After getting some feedback and requests, I wrote a second version. Surprisingly I still get pings on this from time to time and it made me wonder if something more integrated has shown up in ASP.NET MVC since my original attempts. Until recently I hadn’t had a need for this myself until a couple days ago I got the urge to stream video content from my Windows laptop to my TV and thought this might be a good time to revisit the library. What I wanted was an iOS compliant video server so I could stream videos to my Apple TV via my phone.
I knew I had a working library for ASP.NET MVC that I could have up and running in a few minutes but I was more curious if there had been any advancements in supporting partial range requests more seamlessly. A few brief searches turned up the ByteRangeStreamContent class and the HttpRequestMessage’s RANGE header used in ASP.NET Web API which looked promising.
A coworker was tasked with finding a good client-side grid for displaying and editing data from WCF services. We’ve had a little experience with WCF services and JSON serialization of simple data to generate some custom HTML but until now we hadn’t touched grids. Typically we’d use a 3rd party ASP.NET control inside a web application but lately we’ve been trying to be a little more lean.
I haven’t done any research into grids myself so I’m taking it on faith that jqGrid is alright for us. Right out of the gate there was some trouble getting the JSON data to be in a format the grid appreciated. Since we didn’t fancy the idea of boxing all our services into returning data in this format we had to get the grid to work with our format.
I went from knowing nothing about this grid to having 20 tabs open on various sites trying to find any information I could regarding options for making the grid work with our data. It is shocking how much information is out there but I didn’t find a single source that put it all together. It was through pure persistence I found a reference to jsonReader and then found the properties it expects.
Constants and Settings are a pretty old topic, right? If you have a simple value you know at compile time which might make code more readable or might change very rarely and you don’t want to hunt through code to change it in multiple places, you use a const.
A const is beautiful. It’s static which means you don’t need an instance of an object to access the value. It’s set during compilation and immutable during the execution of a program which gives you some peace of mind the value isn’t going to get accidentally changed by someone else’s code.
Unfortunately a const can’t handle a value which isn’t known until a program starts up and can access a configuration file. In the face of this limitation I’ve seen the same (anti?) pattern repeated: the configuration value is read in with code in the constructor of a class which needs the value. Unfortunately this means the configuration value is read in every time you create a new instance. This is less than ideal given the value isn’t likely to change very often. Think about it – when you modify a web.config – are the values immediately available? Yes. Why? Because the application pool recycles! All your objects were dumped from memory and everything is loaded fresh and when the configuration code executes again, the new value is picked up.
So if the value is unlikely to change, why read it over and over again? Some people don’t – I’ve seen people use static members and only perform the costly configuration reading if the value hasn’t already been stored. This is pretty close to being optimal but it leaves a bit of clunky code lingering in your constructor and there can be a bit double-work done when an object is created multiple times in quick succession or on different threads at the same time. This is why I use static constructors paired with static readonly members to hold my configuration file specified settings.
What makes this a winning pair? A static readonly member is synonymous to a const except its value isn’t required to be set at compile time. Instead you must set the value by the end of your class constructor. A static constructor is called before you make use of an object for the first time.
Haven’t used a static constructor before? Probably not but you can probably guess it’s a constructor that’s called once – before the normal instance constructor is called. If you put your config file reading logic in this static constructor to set the static readonly configuration values, you’ll have near-const behavior with the added bonus of not cluttering up your instance constructor! More importantly, it is very similar to the code I’ve seen people write already but reduces the cost of re-reading configuration values with each new instance down to a single hit.
Keep in mind the rules go out the window if you mark your static members with the ThreadStatic attribute. Luckily this attribute should be used incredibly rarely and by people who know precisely why no option is optimal for them.
Static constructors are nice, so I’ll say it twice. Static constructors are nice, static constructors are nice.
Static constructors are nice,
In this post I’ll walk through replacing existing, expensive synchronous loop code with an easy to consume generic wrapper to run the code in parallel and increase performance.
I had an interesting challenge today. I was debugging a bit of code related to RSS feed item retrieval and aggregation and saw an opportunity to increase performance by multithreading my calls to different feed urls.
The code in question got List<string> urls which were links to various RSS feeds and returned a single SyndicationFeed item containing all the items from these various feeds ordered by the PublicationDate in descending order. The problem was the loop of the urls was being done one at a time and as anyone who has had to work with WebRequest and WebResponse objects knows, this can be a little costly for one request, let alone many. I knew I needed to get these requests going in parallel to cut down on all the overhead and wait time.
It’s been some time since I posted my early attempts at making parallel execution of threads easy when working with collections in .NET Framework prior to version 4. It might seem out of date but believe it or not there are a lot of developers who are still unable to take advantage of the new runtime yet. For me this is due to our strong dependence on SharePoint which unfortunately still requires the 2.0 runtime.
With this limitation strongly in place, I continue to refine my ability to work with threads.
The week before last I had the opportunity to attend the VSLive NY conference in Brooklyn. I’ve never been particularly conference-oriented – I’m always asked rather than asking to attend – mostly out of anxiety from the travel or being thrown into a large crowd of people I don’t know. VSLive NY was a very positive experience for me. It was a local conference, which is one of the most important reasons I moved to NYC in the first place, and it was the first time I attended a conference with an eye toward architectural concepts. VSLive really delivered.
I had a blast at this conference! I was initially concerned many of the sessions might be too introductory but it gave me an opportunity to listen to audience questions about the material and really get a feel for how information is absorbed. I took the opportunity to see how I could be a better presenter myself. Though I haven’t needed to do large presentations like those at a conference, I do have to do internal trainings. In fact I have to do a series of presentations on the things I picked up from VSLive!