As I’m sure everyone knows by now, NHProf is a nice tool which helps you spot when you’re doing something boneheaded when using NHibernate and gives you handy suggestions on what to do to fix it. It’ll also show you a every SQL statement you’re throwing at your database, nicely formatted for your convenience. It groups these statements into individual ISessions. So if I have three integration tests based on Northwind that look like this (InTransactionalSession is just shorthand for using(ISession) ... using(ITransaction)):

 [Test]
public void CanLoadCustomer()
{
    InTransactionalSession(session =>
    {
         var v = session.Load<Customer>("ALFKI");
         Assert.That(v.CompanyName, Is.Not.Null & Is.Not.Empty);
    });
}

[Test]
public void CanGetCustomersByRegion()
{
    InTransactionalSession(session =>
     {
         IList<Customer> customers = session.CreateQuery("from Customer c where c.Region = 'OR'")
             .List<Customer>();
         Assert.That(customers.Count, Is.GreaterThan(0));
     });
}

private const string TestCustomerId = "FLURB";
[Test]
public void CanDoRoundTripPersistenceTest()
{
    InTransactionalSession(session =>
        session.Delete(
            string.Format("from Customer c where c.CustomerId = '{0}'",
                TestCustomerId)));

    InTransactionalSession(session =>
        new PersistenceSpecification<Customer>(session)
            .CheckProperty(c => c.CustomerId, TestCustomerId)
            .CheckProperty(c => c.CompanyName, "Flurb's Jelly")
            .CheckProperty(c => c.ContactName, "Mr. Flurby")
            .CheckProperty(c => c.Region, "OR")
            .VerifyTheMappings());
}

I can see four InTransactionalSession calls in those three tests, and the output from NHProf gives us what we might expect:

NHProf Numbered Sessions

Perfectly accurate, but if I had a hundred tests I’d struggle to notice which test had caused a problem and I’d lose time tying a session back to a test (ok, not too much time – NHProf has a stack trace tab which lets you double-click jump back to your code, after all, but I like “at-a-glance”). Post-NHProf v1.0, Ayende asked for feedback on what should go into future releases. Since he’d already covered showing DB plans, I thought I’d take a punt on named sessions.

A week or two back Ayende mailed me to say he’d added support (great customer service!). Now all you’ve got to do is call

NHibernateProfiler.RenameSessionInProfiler(session, sessionName);

and the next session that NHProf hears about will take that name. Combining this with a stack trace gives me exactly what I wanted in just a couple of overloads:

        private string lastTestMethodName;
        private int sameMethodCount;

        protected void InTransactionalSession(Action<ISession> action)
        {
            string currentTestMethodName = new StackTrace().GetFrames()[1].GetMethod().Name;
            sameMethodCount = currentTestMethodName == lastTestMethodName ? sameMethodCount + 1 : 1;

            string methodName = string.Format("{0} #{1}", currentTestMethodName, sameMethodCount);
            InTransactionalSession(methodName, action);

            lastTestMethodName = currentTestMethodName;
        }

        protected void InTransactionalSession(string sessionName, Action<ISession> doDataAccess)
        {
            using(ISession session = SessionFactory.OpenSession())
            using(ITransaction tx = session.BeginTransaction())
            {
                NHibernateProfiler.RenameSessionInProfiler(session, sessionName);
                doDataAccess(session);
                if(session.Transaction.IsActive)
                    tx.Commit();
            }
        }

This results in something that lets me tie sessions to methods at a glance:

At the moment, this is great for people new to NH who want a quick way of demonstrating concepts, but it’s also great as a quick way of running a few tests at once and getting an idea of where your problem areas are. Cheers Ayende.

WCF’s support for ReST

WCF is designed as a transport-agnostic support framework for services based on Operations (which have a natural mapping to methods) and Contracts (which have a natural mapping to behaviour-free data transfer objects). This means that your design is inherently RPC in nature. Initially, we thought this’d be a good fit. We knew we needed ReST (or at least, POX over HTTP). This being the Syndication arm of NHS Choices, we also thought that in order to conform to government standards we might need SOAP as well. WCF seemed to fit the bill – we could write our operations as needed and just host a couple of endpoints: one SOAP, one ReST. To start with, the development model also seemed simple and familiar.

Well, we had articles to syndicate, we had images, we had some videos and audio clips. And it’s at this point that WCF started to let us down. We also knew we needed various representations of each thing we were syndicating (JSON for digital set-tops and handset consumers, XHTML for a discovery channel), and WCF out of the box didn’t support multiple representations.

For a while we used the open source library WcfRestContrib, which goes a long way to providing some kind of content negotiation for WCF. Based on the HTTP Accept header, WcfRestContrib will switch content type according to its own formatters. Even this has a limitation, though. For example, a JSON representation of a video makes almost no sense, and yet we could only supply a fixed set of representations which had to apply to all URIs. At this point it started to become clear that we were asking too much of a service-based technology with strong RPC overtones. While we could have extended WCF, the learning curve was steep and unpalatable. In addition, because we were primarily focussed on the usability of our ReST URI set, our “Operations” had become so ReST-centric we wouldn’t really even have had the mooted “SOAP-in-parallel” benefit anyway.

Stumbling across OpenRasta

The comments in this StackOverflow post put me onto OpenRasta. Two things put me off in the middle of last year, though: there wasn’t much documentation and there appeared to be only a single committer. However, a number of things encouraged and intrigued. The fluent configuration gave me warm fuzzies immediately, both from the point of view of meeting our conneg requirements instantly and also being vastly easier to read than the WCF XML configuration:

        public void Configure()
        {
            using (OpenRastaConfiguration.Manual)
            {
                ResourceSpace.Has.ResourcesOfType<Customer>()
                    .AtUri("/customer/{customerId}")
                    .HandledBy<CustomerHandler>()
                    .AsXmlDataContract()
                    .And.AsJsonDataContract();
            }
        }

Score! Two representations that are attached specifically to that URI, with some class called CustomerHandler providing some kind of output. Wondering what kind of output that could be, I was won over by the absolute simplicity in the handlers:

    public class CustomersHandler
    {
        public Customer Get(int customerId)
        {
              return CustomerRepository.Get(customerId);
        }
    }

This simplicity is entirely brought about by OpenRasta’s built in, convention-based approach to method matching. No configuration files were harmed during the mapping of this URI to its method; OpenRasta simply looks for a method starting with “Get” and with a parameter called the same thing as you put in the squiggly braces in the URI, and ends up returning a POCO Customer object. Another beautiful thing was that no handlers need to inherit from any special type of object, leaving your one shot at inheritance still available to you.

Note: this attention to preserving individual developer productivity appears again and again in OpenRasta. You’ll go to do something that you thought you might have to write (creating URIs for other resources, or HTTP digest authentication, for example) and you’ll find it baked into the framework.

So if that handler could return a straightforward POCO, what was responsible for wrapping that up in the format that the HTTP GET had asked for with its Accept header? The answer lies with codecs, and while OpenRasta ships with most that you’d need (for (X)HTML, XML and JSON), again the extensibility model wins with its simplicity – you simply implement a couple of interfaces with one method each to handle encoding and decoding.

I’ve stated many things I like about OpenRasta but I’ve barely scratched the surface. I’ve not mentioned extending the pipeline (which meant we were able to bolt API key-based resource governance right in) or even the core developmental nicety that is OpenRasta’s built in support for IoC containers. Windsor and Ninject support are there out of the box, though there’s a basic implementation that’ll serve 80% of small to medium-sized projects anyway. When you start to put together HTML pages, you can do that with the familiar ASPX markup model – though even that has had a spruce-up and has extended the ASP.NET build provider in some useful ways.

In Summary

Why we found WCF isn’t a great fit for ReST

• WCF is designed as a transport-agnostic support framework for services based on Operations and Contracts. This means that your design is inherently RPC in nature. For simple cases, this might be enough.
• ReST is an afterthought in WCF (hey, we *can* do this quite easily and we’ll service the needs of 80% of developers and they can continue to think about methods in services as the One True Way). However, given that it’s so different to, say, SOAP, it requires that you structure your WCF app in such a way that it can barely reap any of the rewards of transport agnosticism anyway
• Content negotiation is not a given in WCF. It requires use of third party extensions such as WcfRestContrib, and even then you cannot negotiate content on a per-URI basis. For example, I can’t say that at /videos/1 I will have a text/html representation and at /conditions/cancer/introduction I will have text/html and application/json. Even with WcfRestContrib you will only have a fixed set of representations which will have to apply to all URIs.

Why we found that OpenRasta is

• OpenRasta – like HTTP since the mid 90’s – focuses on resources and their representations, not RPC.
• A resource is just a POCO which is addressable by one or more URIs
• A representation is just an encoding of the resource (JSON, XML, byte stream) negotiated on what you said you’d Accept in your HTTP headers
• A URI can have as many or as few representations available as it requires.

WCF is designed around the concepts of Services and Contracts. HTTP, and by extension ReST are not – they are about resources and representations of those resources. OpenRasta understands this and has been designed from the ground up to support ReST-based architectures simply and elegantly – it’s a natural fit with HTTP whereas WCF is a slightly incompatible mismatch.

I needed two WCF books from Safari Online and WcfRestContrib to even begin to implement what we needed in WCF and it still fell short of what we wanted to achieve and compromised the design at the same time. OpenRasta not only freed us from WCF’s overbearing and config-heavy complexity – its elegant MVC model (with IoC at the core) made our code easy to write, easy to read, and above all a pleasure to maintain.

And if a project is only to have a single committer, better it be a “self-proclaimed, egotistical doofus” who also happens to be a borderline genius.

1. I always liked REST (die, SOAP, die) and have rolled my own more times than I’d care to mention
2. WCF has an almost shiny, nearly-new REST Starter Kit

I’ve seen enough about WCF to know that I like the separation of contract from implementation and I thought I’d be able to get a good idea of whether it did enough of the following to make the effort invested in a “starter kit” with no go-live license worthwhile: -

• Authorization / API key implementation (check – one sample project has an interceptor-based solution)
• Serialization to XML and JSON (check – it’s baked right into the kit when you implement a collection service base)
• Error handling and presentation (half a check – nice and RESTful, with a nice WebProtocolException that lets you tailor what just happened to the most appropriate HTTP status code, but I would like more control over what gets rendered back)
• Documentation/discoverability (half a check – there’s a nice .../help URL based on standard WCF contract/member attributes but there’s no WADL. Did we need it anyway?)
• General syndication support (check, thank you SyndicationItem)

In any case it all looks terribly promising. The templates are good, the screencasts are good … hang on, wait – Aaron Skonnard’s screencasts are mucking about with a Service.svc.base.cs file I don’t have, and that’s how he’s customising the output XML. That’s not in Preview 2. Suddenly I find that this stuff’s moved into Microsoft.ServiceModel.Web and I can’t edit it any more. So the customisation story must have moved. Then I discover that the way to customise is apparently to move the source code into your project and change the namespace so it doesn’t conflict with the existing ServiceModel. Woah. That’s not even as nice an “extensibility point” as we had in Preview 1… oh well. So I’m stuck with ItemInfoList and ItemInfo in my output XML. Suddenly the lack of the aforementioned go-live license doesn’t seem so bad. I wouldn’t be able to use this as it is now.

So this leaves me in quite an odd place – clamouring for half of a very promising toolkit that just isn’t quite finished and which I wouldn’t be legally allowed to use anyway. However, the source code appears to be all there. And we need a REST strategy really soon. Not to denigrate the excellent effort from the MS REST team, but it’s at times like this you wish the effort you’d just put in had been directed at an open source project – at least you’d have somewhere to go, even if you had to pedal that last mile yourself. I’ve been titillated and subsequently frustrated – I’m not allowed to touch, as the chaperone’s an army of lawyers.

Looks like I’ll be rolling my own again.

EDIT: Hmm, I might have been a bit hasty – there’s plenty in WCF 3.5 as it stands to build REST services. Just not quite as easily. I’ll miss WebProtocolException and I’ll miss having the zero-config approach. I might also miss the interceptor-based auth and the in-built help generation. But it’s still doable, if just somewhat harder…

A confession – I’ve come to the multi monitor thing rather late. For five years or so I’ve been getting by on a 1280×1024 LCD like everyone else, and since I’m freelance I work in a lot of places where you’re lucky if you get that. Most of the time you can expect an old 17″ monitor that looks like it was smeared in fruit-based conserve (or worse, the core dump of a baboon – I’ll spare that particular company a mention, though I do hope their erstwhile IT Guy has discovered his shower – or at least toilet paper – by now). As a result, given the usual small constellation of developer apps you’ll have open at any one time and their natural predilection for consuming what the entire software development industry has, irony-free, come to call “real estate”, I’ve become deft with ALT-TAB, CTRL-TAB, CTRL-F6, SHIFT-CTRL-F6 and ALT-CTRL-SHIFT-FN-pasa doblé-reverse triple somersault with pike. Quite a lot of people (alright, one that I know of) will state their preference for some other kind of window manager shoehorned into XP at this point, and probably with good reason, but the aforementioned freelance status means it behoves you to learn to cope with default tools before coming to rely on yet another thing you’ll just have to set up at the start of your next gig.

Anyway, just recently I’ve been working at a place where multi-monitor setups are the norm and despite my previous reluctance to come to rely on something that may not be there at that next gig, I’ve rather taken to it. In a limited sort of way, at any rate – I might only use the second monitor for having a browser open for reference, or a query window, or perhaps a Terminal Services session (though this last one is less likely since the TS client’s support for multiple monitors, especially when those monitors are of a different resolution and/or aspect ratio is, to put it charitably, absent).

The thing that really struck me is that my cognitive load is immediately lightened. Those with a background in psychology (and even those with only a passing interest) will no doubt be acquainted with George A. Miller’s magical number seven, plus or minus two – the idea that we have between 5 and 9 short term memory “slots” available to us. Not having to ALT-TAB or task switch using the task bar frees me from needing to remember where I left a program I haven’t used for a minute or nine.

As a developer, anything that gives you back one of your 7 +/-2 short term memory items is invaluable. Software development is a constant assailment of our limited mental faculties by almost overwhelming detail, and we constantly have a little “stack” of our own: can’t do x until y is complete, can’t do y until z and b are complete, b is awaiting consent from Harry in ops and we can’t do z right now because it’s lunchtime. And multiple monitors really do help with this (although they can’t nip out and get you a chilli beef ramen). I’ve seen it said by Scott Hanselman that: -

You just can’t have enough screen space. Any space in front of your face that isn’t a working monitor but is still in your field of view is a waste if it’s not conveying information.

I’d hesitate to go that far – the biggest benefit in terms of order of magnitude for me has come with going from one to two. I suspect three would increase that benefit, but not to the extent that going from one to two did, and anyway, you do have to remember not to hit DEL indiscriminately when your cursor is on a physically different monitor.

So, given that we have a Very Small Brain and Very Large Problems which require Looking At Lots Of Stuff at once, may I suggest a trusted old tool which has been available for a good number of years now and which provides a handy way of viewing lots of pertinent information in a persistent, multipage readable form and which will be available at any modern desk at which you might find yourself sat? It’s the good old pencil and paper (or pen and paper, should you be the kind of super being who never makes mistakes). This all leads nicely on to the next article I’ll never write, in which I take to task every single developer who doesn’t use them - Less Coding, More Thinking.

As a small learning exercise, I’ve made a search command for the site that I currently work on – NHS Choices. Visit the Ubiquity Commands page to subscribe to the command (you’ll need to have previously installed Ubiquity).

1. The heat: actually, I suffer from this less than Andres does but it’s about freezing in the UK at the moment. There are two graphics cards in the MBP – a GeForce 9400M and a 9600M. Windows can only use the 9600M, which is great for gaming but not a deal of use for development, because of…
2. … The battery life: again, I’m pointing the finger squarely at the graphics card usage here. OS/X uses the 9400M to get as much as 4-5 hours light use out of the machine. You’ll struggle to get an hour and a half out of Windows XP.
3. The keyboard: As Andres notes, it’s missing a delete key (which is “simulated” with FN+BACKSPACE. This is probably the biggest downside for me. There are other annoyances in the UK too – the MBP does not come with a traditional keyboard layout. Backslash and tilde are in the wrong places, there’s an odd §/± key in the corner, and – crucially for me, particularly when editing CSS or using regions in C#, or even saying C# – there’s no ‘#’ key (though see below for a fix). CTRL and FN are the “wrong” way round – your muscle memory is severely hampered for the first two or three weeks.
4. The trackpad: it’s a thing of beauty in OS/X, but BootCamp down to XP and you’ll be tearing your hair out. It’s almost as if they went out of their way to deliberately cripple the driver so that you’d hurry back to your new “favourite” OS/X. The “two-finger tap” right-click method I use in OSX is cruelly transformed into a “three-finger-claw click” (even though I’ve told the driver I’d like to tap to click, which it does for left clicks and not for rights). The sensitivity seems off and the tap-drag threshold for window dragging is insanely large.

The above sounds like a fairly exhaustive list of why you wouldn’t want a MacBook. Apple have done what they probably wanted: to make Windows usable but make it so irritating that you’ll long to be back in OS/X just to use multitouch properly. Oddly, though, I love it. This is probably because development isn’t the main thing I do on it. So what is it I love?

• The keyboard: Yes, the very thing I’m maligning above. The travel is small, the feedback (to me) seems excellent, and typing this post I’m struck by the speed at which my thoughts are hitting the page. Also, I can regain my ‘#’ key (in OS/X) and shift the other keys back where I’m used to having them with the excellent (and mis-spelt) Ukelele. The only thing I still can’t do is swap FN and CTRL or jury-rig a DELETE key on the EJECT button…
• The touchpad feels lovely once you’ve set it up to taste. The poor Windows drivers are inexcusable when you know how good the pad can be.
• VMWare Fusion: Weirdly, when running my BootCamp installation through Fusion, the trackpad works exactly as I expect it. This is probably the best way to develop on it. I boot into Windows only when I want to play Fallout 3. Which I’ve finished. So I never boot into Windows.
• The construction: The unibody construction, the LED backlighting of both screen and keys … it’s got heft and there’s no give or play in any of it. The only downside is that the body is so cold first thing in the morning in this freezing weather we’re having.
• OS/X: There’s plenty to like. Exposé is as good as everyone says. iTunes and iScrobbler are a joy compared to the Windows equivalents and it all integrates beautifully with the dedicated player keys on the keyboard. Safari is fast and usable (once you’ve installed the excellent Glims). iCal integrates with my Google Calendar well using the excellent Calaboration. I can check my GMail from the great desktop widgets (which knock Vista’s sidebar into a cocked hat). The typography is excellent (especially in the excellent and ubiquitous Dictionary), even if Quartz doesn’t quite come up to ClearType standards at small font sizes. “Spaces” is the first “multiple desktop” solution I’ve ever wanted to continue using. The Unix underpinnings are solid, packed with open source gems and don’t require the amount of tinkering that my last dalliance with Linux (admittedly over a decade ago) did.

It’s a shame that Apple haven’t put as much effort into their Windows drivers as they have the rest of the overall experience. Really, the big two things that the drivers need are: the ability to select the graphics card and the same trackpad driver capabilities as OS/X has. As Andres has already said, this means it’s not the best choice for Windows development – though if you’re close to a power outlet it’s all do-able. However, for personal use and even just as an exercise to see how digital life is through a non-Microsoft prism, I’ve found it to be a thoroughly useful and enjoyable experience.

I’d buy it again, but knowing that I’d only use it for digital photo manipulation, surfing and music. I am trying other languages with it (Python and vim ship with the system and I’ve dipped my toes), but it’s not quite the full ticket for Windows-based .NET development and the keyboard issues, while not insurmountable, do mean that (for me, anyway) it’s better suited for general writing than source file editing.

“But the ability to locate reference materials isn’t an important criterion in hiring programmers; it’s an important criterion in hiring librarians.”

As I commented over there about a nanosecond before I realised it’d make a decent post for the first time in about ten months:

Au contraire I feel that the ability to locate the right kind of reference materials in the right situation is something that is sadly lacking in even some otherwise wonderful coders. In fact, one of my interview questions in the late 90s was “What do you read?”

Even today, it seems that many coders think themselves too busy to actually read up on the right ways to deal with certain challenges, preferring instead to use their ‘initiative’ and fudge around the problem rather than seeking out prior art.

I know, I know – I’m quoting myself, on a comment I made on someone else’s blog. I’m pretty certain this contravenes some basic blogger’s code of conduct that I’d have read if only I’d have found the time (hey, I’m too busy. See above). But my point remains – too many coders struggle for way too long by themselves before reaching for the great white google search box in the sky. And when they do reach for that search box, they use it poorly. Very poorly. I see too few people even use double quotes to indicate that words should occur in sequence, and many give up after one or two searches, whereas I’ll try up to a dozen rephrasings before I’m satisfied that I’ve exhausted the possibilities.

So really all I’m saying is this: the world’s full of people who are cleverer than you and who post to their blogs more often than you do. Use their effort, not yours, since the chances are good that whatever you’re doing is a solved problem. The next interview I perform, I’m going to confront the hapless code monkey in front of me with an obscure ADO.NET issue and a laptop running Firefox and see how long he takes to winkle out the solution. Then I might show him some code and ask him what’s wrong with it, and finally I’ll ask him what flavour doughnut filling he takes (custard is a no-hire).

And Mr. Bowkett, I’d never dream of posting something as potentially career-threatening as this (scroll down to the blue photo, which is probably SFW but not for small children), but props to you for having the brass knackers to so do.

static void ObjectQuery()
{
    var people = new List() {
        new Person { Age=12, Name="Bob" },
        new Person { Age=18, Name="Cindy" },
        new Person { Age=13 }
    };

    var teenagers =
        from p in people
        where p.Age > 12 && p.Age < 20
        select p;

    Console.WriteLine("Result:");
    foreach(var val in teenagers)
    {
        Console.WriteLine("> Name = {0}, Age = {1}", val.Name, val.Age);
    }
}

It’s the foreach(var val in teenagers) that gets me – what’s wrong with foreach(Person teenager in teenagers)? Ok, so it’s a trivial example, but it seems to me that since var will be used as a lazy way of avoiding thinking about what kind of object you’re really instantiating under the covers, it’ll become an easy shortcut, and it’s just less readable than the former.

And how about this (From the C# 3.0 Language Enhancements Guide, also in the LINQ May preview)?

var x = 7;
var s = "This is a string.";
var d = 99.99;
var numbers = new int[] { 0, 1, 2, 3, 4, 5, 6 };

Console.WriteLine("x: " + x);
Console.WriteLine("s: " + s);
Console.WriteLine("d: " + d);
Console.WriteLine("numbers: ");
foreach (int n in numbers) Console.WriteLine(n);

Of course, no-one in their right mind would write var x=7 unless they had no idea that C# was a strongly-typed language and could confer certain compile-time benefits (a particularly insular JavaScript programmer, perhaps). So why allow it? It’s perfectly reasonable to allow var in the case where it’s required: i.e. when the compiler has constructed an anonymous class to deal with a projection of data. In nearly all other circumstances, however, this lazy shortcut will allow mediocre programmers to believe that they need to think even less about data typing than they did before, and in the process add an extra barrier to maintenance. Perhaps the compiler (or FxCop) could be set to enforce readability where the type of var is expressible?

It’s the fact that you can now create an XML document, for use in an example, where the C# code structure used to create the document mirrors almost exactly that of the resulting output document.

This is brought about by the ancient magic of variable parameter lists and well thought-out constructor overloads, and whoever’s responsible, I’d like to buy him a drink and look after his cat while he’s on holiday. This technique sits right between ugly raw DOM hacking (of which, I confess, I have done much) and beautifully-generated but hard-to-keep-in-sync XML Data Binding.

This is from the LINQ hands-on labs:

public static XDocument CreateDocument()
{
   // create the document all at once
   return new XDocument(
      new XDeclaration("1.0", null, null),
          new XElement("organizer",
             new XElement("contacts",
                 new XElement("contact", new XAttribute("category", "home"),
                 new XElement("name", "John Smith")),
                 new XElement("contact", new XAttribute("category", "home"),
                 new XElement("name", "Sally Peters")),
                 new XElement("contact", new XAttribute("category", "work"),
                 new XElement("name", "Jim Anderson")))));
}

Wonderful, n’est pas? The only shame is that the “X” classes are a little divorced from the rest of the XML namespaces; their primary purpose is to provide something for LINQ to talk to. So if I do want to use XPath, I’ll have to .Save this doc into a memory stream and reload it. Sigh…

Now at least I know why, as it seems the VS.NET Lead Program Manager thinks enough of Jeff’s blog to shed some light on the matter:

It is a very oddball regex syntax, and as best we can tell it comes from Visual C++ 2.0. We did want to add additional support for .NET 2.0-style regular expressions in the Visual Studio 2005 release, but unfortunately due to time pressures it didn’t make the final list of features. We were able to make a number of bug fixes to the existing engine though, to give some improvement over VS 2003.

We do keep this on our list of things we want to fix. Ideally at some point we’ll actually build in a nifty little extensibility point so you can wire up any regex engine you want for searches.

Extensibility point schmextensibility point. Just plug in the regular framework classes (but leave the great shortcuts like :q). Thanks