UPDATE: I created a project on GitHub. See the follow-up post.
I was recently tasked with solving a rather unusual problem at my company. It was unusual not in the uniqueness of the request but by how common it would seem to be yet we had no existing solution. While we have created standalone web applications to satisfy internal needs, it appears we never really had cause to build a proper user picker. Most of our solutions that needed one happened to be surfaced through SharePoint and made use of its user search and selection methods. That’s why I was surprised to have 3 applications which needed a picker for internal employees pop up at almost the exact same time.
Of course our first thought was to leverage an autocomplete control. Quite some time ago I’d made use of the jQuery plugin from bassistance.de before one was available as part of jQuery UI. Though the autocomplete was quite nice, the free-form nature of the text was not strict enough for our purposes in picking users.
A few suggestions were tossed around including turning an HTML div into a pseudo-input by listening to keypress events and updating the values. A coworker was tasked with turning out a prototype based on this design and he did a pretty good job. It was functional but it lacked some features people have come to expect from an autocomplete-style control like the ability to use arrow keys to navigate the selections. In addition, the input was a bit buggy and there were some race conditions with rendering suggestions from a remote service while a user was still typing. In order to solve the buggy input, the keypress listeners were replaced by a hidden input control nested inside the div and styled in such a way as to be invisible. We still had to address the usability and race condition.
At this point we had a good idea of what we wanted the control to look like – modeled after GMail’s address picking – and what it needed to do. I ended up gutting the prototype and rewriting it. While it is still an early version and could use some enhancement to make it more flexible, we achieved a solution that is working quite well for us.
Posted in HTML, Web
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.
During my time at the World Science Festival this year I had the opportunity to hear a couple presentations on different topics. I enjoyed most but one presentation in particular rubbed me the wrong way. Normally I would just ease over the rough parts and pluck out the gems but in this case I think the rough parts deserve some attention.
The specific presentation was titled “Mentoring Makers: What’s Wrong with DIY.” In his presentation professor Neil Gershenfeld made a few provocative statements. In essence he feels DIY is, at its core, wrong. The DIY culture leads to the reinvention of past mistakes and doesn’t do enough to mentor young people. As evidence he cites the design of a popular 3D printer which uses wood and screws to compose the body. This design, he says, is faulty. Over time the wood dries out and the screws or bolts loosen. It’s a flaw that has been solved by large firm manufacturers long ago.
His disdain for 3D printers in general was quite evident and extended far beyond the materials used in their construction. His entire presentation was punctuated by the repeated refrain “I hate 3D printers!” He makes a good point that 3D printers aren’t the end-all of home custom fabrication. CNC machines, laser cutters and even basic lathes are all very powerful tools that are more efficient for some designs. A 3D printer, he states, should only be used for designs which are too complex to be made any other way.
While his point is valid on the face of efficiency, a 3D printer allows for a wider array of shapes and objects to be produced at a lower cost and smaller space than an entire workshop of machines. To me the usefulness of the machine is self-evident and shouldn’t be discounted on the basis that it’s not the best tool for all jobs.
This year was my first time attending World Science Festival in New York City and I was quite impressed with the variety of events for all ages. I didn’t get to participate in all the events or attend many talks but those I was able to make were diverse and interesting.
My introduction to WSF started with a screening of Icarus at the Edge of Time narrated live by LeVar Burton. I had won 2 tickets the night before and with such short notice, I didn’t have much of a chance to find someone to go. As luck would have it, my boss was a big enough fan of LeVar that he was an easy sell! We both quite enjoyed the experience, held at the amazing United Palace Theater, though it was quite evident the show was meant for a much younger crowd. On the way to the theater from the subway we managed to collide with a family awkwardly looking around for the right way to go. As we all made our way I got lost in a small conversation with mother. The entire family had come for the event because her young son loves physics and science and asked to go! She said there was no way she could turn him down. If I knew how to nominate her for mother of the year, I would have on the spot!
Innovation Square – NYU/Poly at MetroTech, Brooklyn, NY
On Saturday I hopped on the subway and headed to Brooklyn where the NYU/Poly MetroTech campus was playing host to Innovation Square – another family friendly event with booths for people of different ages and interests. Though there were a limited number of exhibits this just made it easier to visit each a few times during the day. I liked to see how people interacted with exhibits and hear the kinds of questions that were asked. At least, that’s the surface explanation. Some exhibits were just so interesting I couldn’t help but revisit them to get a better look as the crowds shifted.
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.