I’ve been to Spur twice now; the first time was to grab drinks with a friend after a pretty disappointing visit to the Seattle Art Museum for one of their “SAM Remix” events. We both ordered beer, if I recall correctly, rather than avail ourselves of the cocktail selection (which Spur usually receives high praise for) — cocktails aren’t really my thing. That visit, essentially, didn’t count. I finally returned last Tuesday to actually try the food.

This time around I was accompanied by Katie, my usual partner in (food-related) crime. We ordered and shared three small entrées and two desserts. First out of the kitchen was a pair of pork belly sliders with a nectarine mostarda and a gelée of champagne. These were, hands down, the best entrée of the night — the sumptuous belly paired wonderfully with the nectarines, and incredibly intense gelée added a really unique accent.

Next we had an oxtail terrine. The tail was braised, formed into a terrine, and fried — it arrived warm, which is atypical (but not in a bad way at all). The dish was accompanied by sous vide apples and a shallot jam.

Our last course was a pasta — tagliatelle with oyster mushrooms, a duck egg, and parmesan foam. This was my least favorite course. I loved the egg, and the deep flavor its yolk brought to the pasta when combined with the foam. I found the parmesan shavings — slates, really — and interesting presentational piece but not really worth the trouble of trying to eat. There was a acerbic nature to the dish, possibly from the intensity of the foam, that wasn’t the most pleasing.

But dessert made up for it. Katie ordered the chocolate cake after our waitress’s extremely enthusiastic recommendation. It was very thin and quite dense — imagine taking a regular chocolate cake and running it through one of those car compactors. In spite of this property, the cake wasn’t overpoweringly sweet, which prevented it from outshining the accompanying fruit.

I ordered the peach sorbet. According to the menu, I would see some “playful accompaniments.” This turned out to be a foie gras mousse. While it’s definitely “trendy” to be doing weird things with foie gras right now, it is entirely forgivable because the mousse was amazing. It is the classic sweet/salty juxtaposition brought to a whole different level. Easily the star of the meal.

As I said before, I passed entirely on the cocktails, but they did appear to have a really interesting selection. Katie had two of their house-made sodas: a lavender soda, which was too thick and sweet for me (she thought it might have been poorly mixed) and a basil-cucumber soda, which was really interesting. The cucumber was hard to detect, but the basil notes were definitely front-and-center.

The portions at Spur are small — they were pretty much ideal for me, but I don’t eat much. Some people will certainly be turned off by the price-to-food ratio. But even splitting the dishes as we did, we were both full at the end of the evening and immensely satisfied. The price notwithstanding, I think I’m going to try and gather some of my co-workers together to hit the place after PAX next week.

Hopefully they’ll still have that foie gras mousse.

Visual Studio has pretty powerful code reformatting features, but the configuration of those features are scoped to the user, not the solution file. You can export those settings and import the correct ones as you switch projects, but there’s a lot of friction along that path.

One solution is to use an external code reformatter, such as Artistic Style or Uncrustify. The latter is currently my personal favorite (but see below for a warning) due to the huge variety of configuration options it supports. More options certainly means a more tedious initial configuration, but it also means the tool will be adaptable to a broader range of styles. Besides, there are useful tools like the Universal Indent GUI, which provide user-friendly ways to configure a variety of popular code formatters.

Once you have configured Uncrustify, you can check the config file in to an appropriate spot in your repository (you can check in the Uncrustify binary as well, but it’s GPLv2 so be aware of the ramifications); that way all developers will have access to it. The best place for it is probably next to the solution files or in another root-like location within your source tree.

You can then configure your IDE(s) so that their default formatting commands instead use Uncrustify. In Visual Studio, for example, one can set up an external tool. Assuming uncrustify.cfg is next to the solution file, then the command line “-c $(SolutionDir)uncrustify.cfg –no-backup $(ItemPath)” will reformat the current source file. You can then assign a keyboard mapping (or reassign the one for Edit.FormatDocument, like me) for quick access.

This doesn’t work flawlessly, unfortunately — such a simple external command requires you to make assumptions about where the format configuration is stored, and that assumption may not hold across all your projects if you don’t have the necessary degree of control over them. External commands also require you to tolerate that obnoxious, brief console window pop-up (or redirect the command to the output window, which will steal your keyboard focus). But overall it’s much better than having your fellow developers come and complain that you screwed up the bracing style in ReallyImportantFile.cs yet again.

Note that as of this writing, however, the released binaries of Uncrustify have a bug that prevents them from handling files with BOMs, such as those created by Visual Studio by default. The bug has been fixed, but you will need to build the application from source to get it. This is fortunately relatively painless, but if you don’t have the capability to run “configure” (i.e., you’re on Windows and don’t have it) you won’t have the “uncrustify_version.h” file you’ll need for the VS project to build. You can just rename “uncrustify_version.h.in” and change the #define for UNCRUSTIFY_VERSION to something sane, though — a bit of a crude solution, but it will suffice until the next release.

Two of the current articles are worth calling out specifically: the component pattern is something that has become increasingly trendy in game development recently, but most available material on the subject covers one particularly approach or another, which tends lead people to wonder which way is “best.” Nystrom tries to point out that there are many approaches, each with advantages and disadvantages, and that there is no “best.”

The other article I enjoyed reading was the one on the singleton pattern. This was really the make-or-break piece for me: I’ve found that a developer’s thoughts on (and arguments for) the pros and cons of the singleton can reveal a lot about how they approach software design and development, and in this regard Nystrom did not disappoint. Like me, he is ultimately not in favor of the pattern, but he presents a very balanced view of the issue.

There is a definite barrier to entry involved in the fact that Fever is a web application that you need to host yourself. The actual installation is smooth and painless, and all the compatibility tests can be run prior to purchase, so you can be assured that the application will function before you part with your $30. But you are completely out of luck if you don’t have your own web host, which is probably the case for a lot of potential users. It’s kind of unfortunate because Fever is a really cool idea by a really cool developer, and well worth supporting.

The general idea behind Fever is to divide your RSS feeds into two categories: important feeds (“kindling”) and lesser-value feeds (“sparks”). Articles in spark feeds are used to determine which articles from kindling feeds are really important, and those articles are displayed in Fever’s “Hot” group. The more an article is linked to or discussed by entries in spark feeds, the more important Fever will consider that article. Importance is represented to the user as a temperature relative to optimal human body temperature.

I’ve never really had too much of a problem with RSS management, but this is mainly because I’ve always been extremely selective about which feeds I subscribe too. I stayed away from major news feeds like those of 1UP and Shacknews because they generate a huge volume of articles and I cared about very few of them. Mainly, I subscribed to the blogs or sites of friends or people I respected. Before using Fever I had about 25 RSS feeds, most of them low-traffic. Fever’s clever tricks don’t work that well with so paltry a subscription count, however, so I’ve added subscriptions to the aforementioned sites (and others).

The impression that I’ve developed over the past week is mostly positive — I’ve run into some user interface weirdness (I can’t drag feeds from the sparks group to the kindling group, but I can drag them the other way, for example), but nothing serious. Overall the UI is quite pleasing, especially compared to Google Reader. The most jarring UI issue? Sometimes Fever chooses to display a headline that’s a little odd:

Honestly, though, this probably has more to do with the site serving up the feed than Fever itself. I suspect I could reduce the number of occurrences of issues like that if I tended my kindling/sparks with more care, as well. But that brings me to my only real serious gripe with Fever, which is that figuring out where to put a feed is sometimes a bit of a mystery. Since I’m not sure precisely how the dynamic between kindling and sparks works, I am currently tending to leave everything as kindling and “demoting” things after a while, one at a time. Initially, I’d tried exactly the opposite, but I found I got almost no useful results (this could also be because the corpus of data available to Fever is still quite small, since I still don’t have that many feeds).

Additionally, because of the way Fever works (and how long it takes to refresh the feed heuristics), it’s probably not that suitable for people who must know everything that happens as it happens. I’ve definitely had more success treating it as an occasional thing — something I log in to at lunch, or after work, rather than something I keep open in a browser tab all the time.

Fever functions as a “normal” RSS reader as well, although I don’t have much to say about it’s performance in that domain since I wasn’t a heavy RSS consumer beforehand. I set up a group for the handful of feeds I want to read every post from, set that specific group to show unread counts, and between that and Fever’s Hot group, everything’s been great.

Up until recently I’d used Subversion to store all my vim (and other) configuration files. This is a reasonably common practice. But I’ve had two issues with this approach. First, I had a few makefiles (or batch files for Windows) that I used to sync the contents of the repository to to appropriate locations on each type of machine. I did this largely to keep my home directories clean, but having to maintain them — even in a limited capacity — was obnoxious. Second, I had to remember to actually commit any changes I made back to the central repository. On a number of occasions I made some tweak at work, went home, and realized I’d failed to commit. A minor annoyance, but an annoyance nonetheless.

This is why I decided to try storing the configuration using Dropbox. Since Dropbox storage is accessible like a local directory, I could easily create symbolic links to the .vimrc file and .vim directories stored in my Dropbox drive on all my machines. This means I don’t have to manually commit any local changes back to the repository. It also obviates the need for the synchronization makefiles; while they provided a bit of a buffer for changes, which was occasionally nice, they existed largely to keep the temporary cruft created by a Subversion working copy out of my home directories. That’s not a problem with Dropbox.

So far I’ve had no trouble using this approach, and the additional streamlining is a huge boon. I was very pleased, in particular, that the symlinks worked out so well. My fallback was to create shim .vimrcs that set $VIMRUNTIME and sourced the Dropbox version of the file, but fortunately I didn’t need to.

Also, in an effort to try and get a better sense of our users and community, we’ve put together this quick SlimDX developer survey and would appreciate your time in filling it out if you use, have used, or are considering using SlimDX for anything.

Finally, we’ve received several queries through various channels about contributing to SlimDX, especially the upcoming version 2.0 redesign. If you are at all interested in participating in or simply observing the discussions about the redesign, you should join the slimdx-devel mailing list.

We arrived, all dressed up, shortly before our 8PM reservation. The valet took my car without giving me a ticket — one of the things the staff is known for is their ability to operate their valet service smoothly without such pedestrian aides as tickets — and we were promptly shown to our table. We were seated on the opposite side of the dining room from the main windows, and there was another party at a table between us and the view. However, the windows were large enough that we still were able to see out across Lake Union, and we were near the kitchen (which I always enjoy).

We were there for the three-course dinner offered as part of the Seattle Restaurant Week promotion, and since there were two of us and two options for each course we were able to experience everything on the menu. I carelessly left my phone in my car, so credit for all of these wonderful photos must go to the lovely Ms. Clark:

A wine pairing was offered to accompany each dish; we both ordered it, but since I have a terrible memory for wine I couldn’t really tell you much about it. All of it was awesome, though, especially the dessert wine — which isn’t something I normally enjoy. The service was excellent, and the staff was attentive and responsive, very knowledgeable about the food and preparation. We only had to suffer through one minor delay, just before placing our order, but given how busy the dining room was that evening I was not terribly bothered and our server’s affable mood more than made up for it.

In addition to the items on the menu, we were served a small cup of gazpacho as an amuse bouche and pair of wonderful petit fours along with the coffee we had after dessert. Once the meal was concluded, our server took us on a quick tour of the restaurant, showing us the various private dining rooms that were not currently in use, and offering a lot of interesting information about the history of the Canlis family and the restaurant itself. At the conclusion of the tour, somebody was waiting with Katie’s coat and my car was ready outside. Impressive.

Despite the upscale dress code, ironed tablecloths, and general air of “fancy,” the atmosphere of the restaurant wasn’t stuffy — they take your dining experience seriously, but not so seriously as to make you worry about stepping out of line. You can get an idea of the attitude of the place by taking a look at the light humor on their Q&A page.

I will definitely make the time to go again.

A C-style string is just an interpretation of an actual type (a char*) that adds some additional semantics. These semantics are not enforced by the language, except implicitly and very poorly via some C library functions. This approach, which presumably grew out of the “pay for what you use” mentality, is a huge part of what makes C-style strings cumbersome and error-prone.

That topic is how we’re not going to use IDisposable any longer.

More specifically, we’re not going to use it as much. Almost every SlimDX 1 object implements IDisposable, because IDisposable is all about cleaning up unmanaged resources and SlimDX objects are, for the most part, exactly that. But the sort of resources IDisposable is geared towards are those with very explicit lifetimes: you create it, do your thing, and then Dispose() of it. C# using-blocks allow you to implement this exact pattern for locally-held objects quite efficiently.

Long-time readers will recall that our IDisposable wrappers around COM objects have caused us a lot of trouble in the past, largely because the interface’s contract does not really jive with COM’s reference counting. To account for this, we implemented an object table based loosely on the same principles that the .NET RCW uses — specifically, we tried to maintain exactly one COM reference to any object known to SlimDX so that we could do the correct thing when Dispose() was called. This eventually led us to an overly-complicated system burdened with multiple creation code paths and inconsistent ownership semantics.

Our solution is to, essentially, side-step the issue entirely and just expose the reference counting directly. All SlimDX 2 objects that are backed by actual COM interfaces implement IComObject, which provides the familiar-looking methods AddReference() and Release(). For the trivial scenarios where you just want quick, scoped access to a COM object, we’ll be providing a simple IDisposable utility wrapper you can use in conjunction with a using-block to automatically drop the reference count when appropriate.

While it first might seem like this change is a step backwards, we think that it’s an improvement in the long run: it obviates the need for the exceedingly complex object ownership rules that existed with SlimDX 1 (which, we suspect, most of our users were getting wrong). Plus, it makes the SlimDX ownership semantics match those of the already-familiar native API.

In any event, the purpose of Ada Lovelace Day is to write a post celebrating the achievements of women (or a particular woman) in the technology industry and thus, I would like to call out Tess Ferrandez, ASP.NET escalation engineer extraordinaire.

But this post isn’t about Ferrandez’s achievements in the domain of ASP.NET, specifically. Instead, this is about commending her for her work in educating the development community about debugging in the .NET environment. Ferrandez has been at Microsoft for more than a decade, working with .NET technology since it was in alpha, and offering her knowledge to the community at large through blog posts, podcasts, interviews and by speaking at conferences. She often discusses techniques for diagnosing obscure bugs or memory issues, providing great insight into the tools used or the systems affected — and she’s always informative, easy to follow, and extremely helpful.

I, personally, can attribute the entirety of my understanding of WinDbg and SOS directly to her, as well as a good portion of my understanding of the .NET internals. I am certainly not the only developer to have benefited from her work. So I want to congratulate you, Tess Ferrandez, on what I feel is the greatest achievement of all: teaching others through your own wisdom and experience.