Friday, October 28, 2011

Current Blog

Current blog can be found here.

Wednesday, May 6, 2009

Activity Timeline

Completed a tool for viewing getting an overview of your change history:



In addition to the TaskPad, there is a Context View (filtered solution explorer), LaunchPad (a semi-cloud tag of changes in the method bodies) and of course the activity timeline.

The activity timeline has a draggable filter that updates the other views.

Sunday, April 26, 2009

TaskPad for Visual Studio

TaskPad is now usable in Visual Studio:

Friday, April 24, 2009

TaskPad

Sometimes you want something simple for tracking personal tasks for a project. In a recent survey I did, I found a lot of people (including myself) tended to just use notepad for this purpose.

Basically, I wanted the simplicity of using notepad, but with better task-aware support and formatting. For example, indenting task sub-items, marking items done, or collapsing sub-items. Here is the result of a recent prototype for a text-only task manager.



Try it out at here.

Some next steps include making a version that works in Visual Studio.

Friday, June 20, 2008

Visualizing Development Sessions



Some interesting work has been going on in recording development sessions.

If you use Smalltalk, there is an interesting project,
Spyware, going on that allows you to visualize your development sessions. In addition, "Change Factory is a tool we are implementing which allows one to define a program transformation by first recording a concrete example of it."

I've been doing similar work focusing on C# and Visual Studio. Here is a visualization of one programmer's sessions over a period of few days:



Each pixel in the x-axis is one minute. The y-axis is the amount of activity. Blue pixels are navigation, and green pixels are edits.

Thursday, June 19, 2008

Stacking Visualization Results

Tools, like rule-checking systems, tend to generate a lot of output. Too much output to look at once, so we usually just sorting on something like severity and/or category to focus on the more interesting findings.

Another dimension that should be considered more often is grouping findings together based on other attributes. I would like to see more tools use a "gather and scatter" approach in collapsing results together. For example, I might want to gather all findings based on the corresponding class and browse the collapsed summaries.

I have been thinking about what a visualization would do to better support this concept. One interesting metaphor is creating "piles" or stacks. I have added this new feature to NosePrints to support gathering items as stacks. The biggest problem is giving more information about the other items in the pile. You could do things like averaging, but I think jitter might produce the best results. Maybe something like the Picasa photo collage would be interesting.

Visual Stacks

Saturday, June 14, 2008

Keeping out Bad Code



Our needs for keeping out bad code may be different, but finding the time and tools for supporting this process is still a challenge for many software projects.

There are some good tools that are helping:

For Java,
Find Bugs
pmd
xRadar
Glean
Qalab

For C#,
Gendarme
Monoxide
NDepend
FxCop

These tools fall short in different ways. Some tools act like the overly verbose, picky lint. This can be good your project is built from the ground up with an agreed set of rules to enforce. Rules are good for keeping out well-defined behavior, but not necessarily good at finding "funky" or bad-smelling code.

Other tools take a more 'screening' mindset. The tools have the sense that you might want to know how code quality metrics are changing over time and can be integrated with build processes such as maven or cruise control.

Almost none of the tools have been designed for doing a quick but comprehensive peer review. Crucible might be an exception.

Overall, these sets of tools tend to stick to a more conservative set of rules. Steps into code smell detection has seen timid, but has seen budding support in the tools. But as always, it is hard to define these as rules because the answer always ends up being "it depends".

My take for dealing with design problems has been with software visualization:

As part of my research, I have developed a tool that examines C# byte-code and produces mini-diagrams of source code that can be screened for design problems.

http://se.ninlabs.com/noseprints/index.html