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.

My best guess is that developer’s have a love/hate relationship with tabs. They’re great when they work, but many times they get cluttered, and developers have to go nuclear on them (Close All Tabs).

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.

The International Conference on Program Comprehension (ICPC 2011) was a charming affair, bringing together a diverse set of researchers from around the globe.

Tasks, for the purpose of this post, are assigned units of work. In practice, this may be a “story” or “defect” from an iteration in the agile world, or a “work item” in TFS land, or even a “feature” in trackers such as trac. There are many names given to tasks, but for the programmer, ultimately they are externally assigned responsibilities.

This is my second attempt at a software-related comic, but this time it is completely hand drawn.

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.

Following a successful collaboration with Emerson Murphy-Hill on “How We Refactor, and How We Know It”, we decided on doing another empirical study, this time on Java generics. Turns out Christian Bird had similar interests, so we banded together for a new paper recently accepted for MSR’11.

Developers search the web for many questions they have about using apis. Developers can also use social media sites such as codesnipr, stackoverflow, refactormycode, or blog sites such as this one to provide answers or share knowledge about using apis. For example, this blog gets many hits each week from people looking on how to do programmatic search with the automation api in Visual Studio.

This winter break, I’ve written way too many papers. I’m keeping this list so I can keep track where I’m submitting or may be traveling to.

I have seen many papers justifying how much effort debugging or testing costs by saying something like:

Ever since google released a comic describing the design of the chrome browser, I’ve been fascinated by the idea using comics to communicate software design. There is something compelling about distilling down your concepts into a simple narrative. This is no easy task — here is my first attempt, an illustration describing how the concept of code history can change how programmers work: (see the pdf version here: [pdf])

Never forget where code came from again.