ninlabs research

Commonly, we need to perform a programming task that we do not know how to do or is not well-documented. Collectively, we perform these reoccurring programming tasks all the time, but only a few of us actively blog or contribute to sites like stackoverflow with answers. Thus, there are many remaining programming tasks, which are never documented for other teammates (on internal company blogs), don’t have any (good) official documentation, or discussion on blogs or Q&A; sites.

Continuing my last post on creating a basic history extension, let’s actually do something! Here, we dive into capturing events to code documents in Visual Studio and using that to create a help build a local code history for edits.

I will publishing a series of blog posts describing how to extend Visual Studio (VSX in particular) to maintain a history of code changes or actions within the IDE. The audience for these articles would most likely be researchers who are trying to understand how to do interesting developer analytics, intelligent work summaries, or build interesting work history visualizations, or next-gen developer tools.

VSX extensions/packages published and installed through the visual studio gallery will automatically check for updates and allow you to install the newest versions.

The default WPF expander is functional but is ugly. Many people have asked for simple examples for changing the look+feel, and most responses point to ripping the style template from Expression Blend and then customizing it. This is probably the third time I’ve needed to do this and each time looking at pages and pages of all that style code leaves me queasy.

Never forget where code came from again.

Display of search results in Visual Studio has been remarkably primitive despite numerous improvements in other areas. Eclipse, in contrast has added some compelling features such as clustered results grouped by packages and classes and the ability to prune results. Now, simplicity has its place, sometimes the simple list of text makes it easier to scan.

Viewing source code differences is something programmers do almost daily. Yet, how we view diffs is little changed since some of the first tools came out in the 1970s. Sure, techincal improvements have been made (accounting for whitespace, word-level diffs, providing more context, structural diffs).

Some quick code I cooked up to extract text from a collection of word/pdf:

If you want to log searches for code or perhaps wanted to provide a better UI for search results, then you need to listen to search events with a Visual Studio Addin/VSPackage.

When recording EMG signals, you want to be able to segment and associate those signals with certain events, e.g., the presentation of a stimuli.  Because one of my goals is to recognize subvocalized words, it is even more important to get tight segmentation.