Simon had a short paper at the Working Conf. on Reverse Engineering (WCRE) last October, presenting his first study on open source Java applications. The paper was quite well received, from what he told us. Simon’s talk was the only non-invited talk the WCRE steering committee chair twittered about, and it was mentioned the next day by Nicolas Anquetil during his most influential paper talk.

Simon has meanwhile enlarged the depth and breadth of the study: he did the analysis at method level (before it was at class level), he compared naming quality with more code quality metrics, and he also compared it with a readability metric. He also did a statistical analysis to see if some naming problems (e.g. not using dictionary words) could be used as a light-weight test to point to methods with readability and quality problems. The paper we submitted to the European Conf. on Software Maintenance and Reengineering (CSMR) was accepted and today we uploaded to our institutional open access repository the camera-ready version that, from past experience, will take some months to show up in IEEE Xplore.

In our paper at the 2008 International Conference on Software Maintenance, my colleague Yijun Yu and I presented an analysis of the evolution of the plugin-based Eclipse SDK architecture. The aim was to see whether some systematic architectural change process was followed and if commonly prescribed design guidelines (like increasing cohesion and decreasing coupling) were followed. Towards that end we collected several metrics (number of plugins, number of dependencies, etc.) and plotted them over various releases of different types (major release, maintenance release, etc.).

We have now analysed a few more Eclipse releases, did more measurements (on extension points) and refined others (distinguishing between forced and unforced changes), and decided to make the data public, by putting the metrics on Google spreadsheets and using Google Visualization to show the evolution of the measurements. One spreadsheet (HTML, CSV, Excel, OpenOffice) contains the metrics for major and maintenance releases from 1.0 to 3.5.1, the other (HTML, CSV, Excel, OpenOffice) has the metrics for the milestones and release candidates of releases 3.2 and 3.3. You’re free to use the data for your own purposes, provided you acknowledge where you got it from, e.g. by providing the URL of this post. Our Javascript code to obtain the charts from the spreadsheets is open source: just use your browser’s ’show page source’ feature! In that way you can reverse engineer what the headings in the spreadsheets columns mean, but an easier way is to just contact us We next present the results, but they will only make sense if you first read the paper.

We use mostly stacked bar charts, with each segment showing a particular subset of the total number of items (plugins, extension points or dependencies). The segments are stacked, from bottom to top, as follows: unforced deletions, forced deletions, items kept since the first release, items kept from the previous but not the first release, forced additions, unforced additions. In general, a change is considered unforced if it is by choice, and forced if it is due to another change. For example, the unforced deletion of a plugin forces the deletion of all its extension points and dependencies. Clicking on a bar segment will say precisely what value is being plotted for what release and what kind of change.

We use line charts to show ratios or other values. Again, it is possible to click on a data point to obtain its precise value, instead of guessing it from the y-axis.

The first charts show the evolution of Eclipse’s size, as measured by the number of plugins. We consider all additions and deletions as unforced, because they are architectural choices. We can see that the set of plugins remains constant during maintenance releases, i.e. additions and deletions are only observed at major releases. A look at the interim milestones and release candidates reveals that most of those changes occur in milestones, although some also occur in the later release candidates. (Note that in this case, the number of kept plugins is with regard to the first release in the sequence, i.e. 3.1.)

The next charts plot the changes to complexity, measured as the number of dependencies between plugins. We distinguish between static and dynamic dependencies (see the paper for what those terms mean in our context). The overall complexity is the union of both, i.e. a dynamic and a static dependency between the same pair of plugins count as one overall dependency between that pair. A forced addition or deletion of a dependency is associated to the creation or removal of at least one of the involved plugins, i.e. the addition (resp. deletion) of a dependency between two plugins is called unforced if both plugins already existed (resp. still remain). Again, we see that dependencies change mostly during milestones and remain the same during maintenance, except for a few deletions in 3.3.1.

Overall, the biggest changes were in releases 3.0 (almost doubled the complexity while retaining the size) and 3.4 (almost doubled the size). Only 3.1 presents a decrease in complexity. If we now compute directly from the spreadsheet the cohesion, measured as the dependency-to-plugin ratio, we note it’s remarkably constant except for the increase at 3.0 and decrease at 3.4.

The next chart shows the changes to coupling, measured as the number of external dependencies, i.e. between an Eclipse SDK plugin and a 3rd-party component. All external dependencies are static. We can see that coupling was drastically reduced in 3.0, with all existing external dependencies being replaced by new ones. The paper explains what happened.

We also measured the number of extension points provided by the Eclipse SDK and how it changed over time. The addition (deletion) of an extension point is considered forced if the plugin that provides the extension point has been created (resp. removed) simultaneously. We first show the absolute, then the relative number of extension points. We note that most extension points are added to already existing plugins. Hence, new plugins have few or no extension points, leading to a decrease in the average number of extension points per plugin.

Also interesting is to see how many unused extension points there are, i.e. whether the SDK is ‘eating its own food’ or providing extension points mostly for 3rd-party plugins. The addition of an unused extension is considered to be forced if it is due to the deletion of a dynamic dependency (and hence the extension point became unused). The deletion of an unused extension point is forced if due to the deletion of the corresponding plugin. We note that most additions are unforced and for external plugins, because the percentage of unused extension points is constantly rising. Release 3.5 removed a large part of the plugins with unused extension points.

Using WordPress’s text widget, which allows to put any plain text or HTML in the sidebar, it’s a breeze to make such a list. The HTML code

<ul><li>
<a href="http://bibsonomy.org/user/michelw" title="papers"><img
src="http://bibsonomy.org/favicon.ico" style="vertical-align:middle"
> Bibsonomy</a>
</li><li>
<a href="http://www.linkedin.com/in/michelwermelinger" title="contacts"><img
src="http://www.linkedin.com/favicon.ico" style="vertical-align:middle"
> LinkedIn</a>
</li></ul>

will generate this list:

• Bibsonomy
• LinkedIn

The only problem is if the site doesn’t have a favicon file. The best is to use Google to obtain the favicon for a given domain, because  it will return a default globe icon if no favicon can be found. In the HTML code above, simply use as image source src="http://www.google.com/s2/favicons?domain=bibsonomy.org" or similar.

Of course, if you have added lots of widgets to and customized the theme of your retired blog, all that will be lost, and you will have to decide whether and how to change the look and feel of the kept blog in order to accommodate the content of the retired blog. No automation can help you in that… However, I’d expect links and their categories to also be exported, but they aren’t. Hence, if you have lots of links and blogrolls on your sidebars, I have no clue how to easily copy them to another blog. Fortunately, that was not the case with my digital art blog to be retired; a simple transfer of posts (and their comments, categories and tags) was all I needed.

I was pleasently surprised when the import process offered to also get the files uploaded to the retired blog. Since it used some Java applets, this would be really useful. Unfortunately, I got error messages saying ‘unknown file extension’: apparently only certain file attachments can be imported. Oh well, no big problem. I logged into my web hosting service, where I keep all my blogs in separate sub-folders, and used the cPanel file manager to move all uploaded files from one blog’s folder to the other, and then delete the retired blog’s folder. Back to the main cPanel view, I used the Manage redirects functionality in the Domains sub-panel, in order to make all URLs of the form http://michel.wermelinger.ws/digitar-te (the retired blog) redirect to http://michel.wermelinger.ws/chezmichel (this blog). Since I use the same permalink format in both blogs, namely year/month/post-title, any links to my retired blog will correctly resolve to the corresponding posts or files in this blog.

To sum up, the export/import facilities of WordPress go a long way to help the merging of blogs, but be prepared to do quite some manual tweaking, especially if the two blogs are very dissimilar in the presentation of their content. Among the things to consider are the merging of different permalink structures, ‘About’ pages, and blogrolls.

The theme is very easy to use. When writing each post, add two custom fields, named lead_image and secondary_image. The value of each field is the URL of an image, which can be external to your site or have been previously uploaded. The larger lead image will appear at the top of your blog post, while the smaller secondary image will appear in the index pages. The theme automatically crops the images to the dimensions needed. This means you can use the same URL for both custom fields, which is what I do in my stamp blog: each post is about a group of stamps and I select one of them to be featured both in the post header and in the index pages. I think that using the same image is better, because it provides ‘navigational continuity’ when the blog visitors select a post from an index page. The theme demo site also uses the same images for post headers and index pages. The theme crops the images by selecting the central part and enlarging to the required ratio. This usually works fine, but occasionally the relevant part of the image is not in the middle. In those cases you have to crop your images on your computer (593 x 225 pixels for the lead image and 293 x 150 pixels for the secondary image) and then upload them.

Version 1.2.1 of the theme has some problems, and to fix them I had to find my way through the PHP and CSS files in the Appearance>Editor administration panel. Here is a list of the problems, my fixes, and the solutions I’d like to see in the next release of the theme, in the hope it’s useful for other users of this great theme.

1. Problem: Clicking the ‘About’ button at the top of each page doesn’t do anything.
   Fix: Replace /# by /about in header.php.
   Solution: This change should be part of the next version, so that at least there is an error message if the user hasn’t created the ‘About’ page.
2. Problem: Categories are shown in multiple columns at the bottom of each post. I prefer them on the sidebar, using the usual categories widget.
   Fix: In files page.php, single.php and index.php delete the line of code that includes the show_categories.php file.
   Solution: Create a theme option that allows to turn categories at the bottom on or off.
3. Problem: HTML tags like <strong>, <code> and <em> are ignored, forcing one to use the HTML editor to write posts, in order to use alternative HTML tags like <b>.
   Fix: Delete those tags in reset.css, so that their default behaviour is in effect.
   Solution: I’m not a CSS expert, so there may be a better way to do it.
4. Problem: The blog’s tagline is not shown below the blog’s name.
   Fix: Insert a PHP call to bloginfo('description'); in header_text.php.
   Solution: Do proper styling of the tagline.
5. Problem: The number of comments is superposed on the secondary images. This obscures them and doesn’t look good if most posts have no comments.
   Fix: Delete the post-comments class in index.php.
   Solution: Provide a theme option that allows this feature to be turned on or off.
6. Problem: The date format of a post is hard-wired to 'M jS Y' (e.g. ‘Aug 31st 1999′).
   Fix: Changed it to 'j F Y' (i.e. ‘31 August 1999′) in single.php.
   Solution: Ideally, the theme would automatically pick up the format chosen in the Settings>General administration panel.
7. Problem: If a blog post hasn’t been tagged, the box below the post will just state ‘This post has been tagged’, because it assumes a list of tags will follow.
   Fix: In single.php, change the text within the for-tags paragraph to the following (note the punctuation and spacing):

This post is <?php if (!get_the_tag_list()) echo 'not'; ?>
tagged<?php the_tags(' ', ', ', ''); ?>.

I also did another small change to the theme, which is a matter of taste: in style.css I reduced the opacity of the title box over the stamp images from 80% to 70%.

I could have just replaced the falling leaves photo in the header by some photo of beach and sea or the like, but it wouldn’t match the foliage on the sides. Moreover,  I wasn’t complete satisfied with the greyish green or the fonts used by Maple Leaf. Installing and trying out different Wordpress themes is a breeze, the problem is choosing among the thousands of freely available themes.

After spending several hours during the past days (I’m insane, I know) surfing the web and trying out various ones, I settled for the Amazing Grace theme you’re looking at. Its green-based colour scheme establishes some continuation with the previous look of my blog, while definitely improving on the typography, with a large and readable font. Other things I like about Amazing Grace:

• the compact header, avoiding wasting valuable screen estate on small laptops and netbooks;
• the RSS feed icon and its placement in the header;
• the small colourful icons to provide visual cues on a post’s date, categories and comments;
• the horizontal layout of the categories in the header;
• the rotating photos in the header, which can help keep the blog in tune with seasons.

Unfortunately, no theme is perfect and there are also some drawbacks:

• the title of the blog doesn’t appear in the browser window and tabbed windows in Firefox;
• the date and author of a post are unnecessarily repeated;
• there is no icon for tags and they aren’t separated from the post;
• the second sidebar makes the main column narrower, leading to more scrolling.

Fortunately, Amazing Graze has a dedicated forum on the author’s website, so hopefully someone will be able to help me fix some of those minor snags. Overall, it’s a good looking, clean and readable theme.

His approach consists of first extracting a graph of the program’s identifiers and how they are related (e.g. X is-a Y if class X extends class Y). Given a similar graph representing the domain’s ontology, he then uses the identifiers and the graph’s structure to try to match the program’s concepts to the domain’s concepts. This then allows one to see the conceptual coverage of a program, its conceptual redundancy, the logical cohesion of an architecture, etc.

However, there are usually no domain ontologies available. So, he and other colleagues used the approach to extract the concept graph from several APIs for the same domain (e.g. GUIs) and then do pairwise intersections: any concept belonging to at least 2 APIs would be added to the ontology. In this way they obtained e.g. an ontology of GUI artefacts (menus, buttons, etc.) and could see which implementations don’t cover important artefacts (e.g. AWT doesn’t provide tables). The approach of course relies on the program using good identifiers (not just cryptic abbreviations), and that the identifiers reflect the domain’s vocabulary.

Another example he showed was a visualisation of packages or classes of a program that refer a certain concept. This can expose non-optimal modularizations of code w.r.t. the domain’s concepts.

Daniel also gave me a demo of his tool, available as an Eclipse plugin. I especially liked the fact that the extraction of the concept graph and the matching of graphs can be parametrized in a simple configuration file. For example, one can choose Wordnet to make identifiers uniform (e.g. children is mapped to child), although Wordnet has several shortcomings for technical domains as used in most software e.g. concepts related to GUIs. I also liked that Daniel made the concept graphs he extracted publicly available, in two easy to process formats, namely OWL and also as a text file with one triple (node-relation-node) per arc.

Overall, a quite nice talk and body of work; a pity it was very poorly attended.

As an added bonus of taking the time to go to Cambridge, the Microsoft Research reception hall has some goodies for visitors: copies of the DVD of the Royal Institution’s Christmas 2008 lecture and of the 2020 Science report. I’m already looking forward to watch and read them.