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.
It’s taking a bit longer to get out Part 2 of creating a user picker in HTML, CSS and jQuery than I’d initially expected. In the interim the User Picker has evolved into a more generic picker useful for other types of data. As such it’s undergone some heavy modification to strip out specific references to users / employees and gained some additional configuration options.
I had almost the entire Part 2 post written and ready the night I published Part 1. I only needed to do a bit of cleanup of the user picker to remove any traces of specific information and get it ready for people to view publicly. With all the changes that have happened since, the post is basically obsolete. It wouldn’t be kind to force people to wait for it to be rewritten before letting you see the current code and begin using it. I’ll try to get the blog post out soon for those interested in the process of creating a jQuery plugin but I have a feeling the source is much more highly desired!
The picker – now called entitypicker – can be found on GitHub. There is also a hastily thrown-together demo page. The demo uses Yahoo services to do YQL queries for city names.
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!
Recently I started at a new company doing in-house work. The environment is a bit different than that to which I’m accustomed by its large reliance on 3rd party utilities and solutions. While these are great for companies lacking in development staff, many of these solutions are overly generic and can be frustrating to users who are looking for a more integrated experience.
Enter me and my first project.
In my current environment, just as in every other environment I’ve seen, we have users who use and love their file shares. These bastions of untamed digital wilderness have been the bane of many an IT person but their existence continues. To help mitigate some of the drawbacks of these audit-free, backup-less storage areas, Bamboo created a product which synchronizes file share content with a SharePoint document library. The solution uses a timer job to occasionally crawl the share looking for files and folders that have been added/changed and comparing against the files it has in the SharePoint library to see if anything has been deleted. The library is kept in sync (though with the option of archiving deleted items to soften the blow of those occasional accidental share deletes) and each item has a status which reflects the synchronization type.