Keeping it Simple: Customizing the WPF Expander Icon 2011-04-21

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.

The main reason the style is so bulky is that Expander style is written to account for several different orientations and positions of the expander icon. But most likely you’ll only need one anyways.

Finally, here is a simple example of customizing the expander icon with just 25% of the code produced by Expression Blend:

Get the full demo from github, or checkout these snippets below.

First the style for header and icon.

<Style x:Key="ExpanderHeaderFocusVisual">
    <Setter Property="Control.Template">
                    <Rectangle Margin="0" SnapsToDevicePixels="true" Stroke="Black" StrokeThickness="1" StrokeDashArray="1 2"/>
<Style x:Key="ExpanderDownHeaderStyle" TargetType="{x:Type ToggleButton}">
    <Setter Property="Template">
            <ControlTemplate TargetType="{x:Type ToggleButton}">
                <Border Padding="{TemplateBinding Padding}">
                    <Grid Background="Transparent" SnapsToDevicePixels="False">
                            <ColumnDefinition Width="15"/>
                            <ColumnDefinition Width="*"/>
                        <Image x:Name="icon" Source="closed.png"  Width="9"/>
                        <ContentPresenter Grid.Column="1" HorizontalAlignment="Left" Margin="4,0,0,0" RecognizesAccessKey="True" SnapsToDevicePixels="True" VerticalAlignment="Center"/>
                            <Trigger Property="IsChecked" Value="true">
                        <Setter Property="Source" TargetName="icon" Value="open.png"/>

Java Generics Adoption: How New Features are Introduced, Championed, or Ignored 2011-03-13

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.

Adding features to a programming language is a difficult prospect. Politics, committees, compatibility, and egos don’t make it any easier. And once a feature has finally made it and shipped, there is a whole other question of how does it plays out? Did designers get it right, does adoption occur? Does the promises of the new feature actually solve the software developer’s pain? How do developers decide to use a new feature, do they plan to migrate old code, coordinate coding standards?

To look at these questions, we looked at how Java generics were adopted in open source projects, which was officially released in 2004. There has been a long history of infighting and arguments for adding generics from the very start. For example, generics were strongly argued for in Guy Steele’s 1998 OOPSLA Keynote, “How to Grow a Language”.

In the process, we analyzed a half billion lines of Java code across the entire lifetime of 20 Java projects to see how the projects grew to use generics or not. We looked at these basic questions (see paper for those in gray, results are shown below for those in black):

  • What percentage of projects and developers used generics?

  • What was the breakdown of feature use?

  • What was the impact on casts after generic adoption?

  • What was the impact on code duplication on container classes?

  • Was there an effort to migrate old code to use generics?

  • Was the adoption of generics concerted (did every start using it at the same time)?

  • Did support of generics in the IDE have an impact on adoption?

Measuring API Documentation on the Web 2011-02-20

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.

In a recent paper accepted for web2se, Christoph Treude and I wanted to know what potential role social media had in answering these questions. Especially, when we contrast them with other information provided through official venues such as the official api websites.

To answer our research questions, we performed an preliminary study, where we searched for 173 api methods from jQuery and manually inspected and analyzed the first page of search results on google (1730 search results in total). For example, if searching for “jquery”, we would see results for the official api method documentation, a stackoverflow question, and a blog post.

Search Result Type Coverage   Mean Rank
code snippet 8.7%   9
q&a 9.8%   9
forum 20.2%   8
official bug tracker 21.4%   3
mailing list entry 25.4%   7
official documentation 30.1%   3
official forum 37.0%   3
unofficial documentation 63.6%   6
stackoverflow 84.4%   6
blog post 87.9%   5
official API 99.4%   1

Upcoming Conferences 2011-02-07

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.

Some topics on the paper’s I’ve written: a post-mortem study of java generic adoption, API documentation and web search, using EMG to study programmers, a study about a fault localization tool’s effectiveness with real programmers, code history, and software development blogs.

Conference Deadline Notification Dates City
MSR Jan 31, 2011 March 4, 2011 May 21-22, 2011 Honolulu, Hawaii
web2se Jan 28, 2011 Feb 18, 2011 May 24, 2011 Honolulu, Hawaii
ICPC Feb 14, 2011 March 07, 2011 June 22-24, 2011 Kingston, ON, Canada
ISSTA Feb 4, 2011 April 15, 2011 July 17, 2011 Toronto, ON, Canada
VISSOFT May 23, 2011 June 27, 2011 Sept. 29-30, 2011 Williamsburg, Virginia, USA

Wild-ass guess: Myths in software engineering 2011-01-15

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

“fixing bugs in software account for 50-70% of maintenance costs”

Just checked this source [1], as far as I see, the guy was making a wild-ass guess for the purposes of making an exciting introduction:

“The rapid expansion of computers into virtually all aspects of society has led to enormous growth in the software-development area. Unfortunately, the increases in complexity and capabilities of these systems have not been matched by an equivalent expansion in software-development technology. Thus, these systems are becoming more expensive and many are error-prone. In an attempt to reduce the number of delivered errors, it is estimated that most companies spend between 50- 80% of their software-development effort on testing. These testing efforts are normally identifiable as unit testing, integration testing, and acceptance testing.”