Three Laws of Test Driven Development:

1. You may not write production code until have a written a failing unit test.
2. You may not write more of a unit test that is sufficient to fail, and not compiling is failing.
3. You may not write more production code that is sufficient to pass the current failing test.

Robert "Uncle Bob" Martin
"Clean Code", page 122

public void testDetectHyperlinksDocument() throws Exception {
 setUpTest("DraftReleaseCRs.xsl");
 XSLHyperlinkDetector linkDetector = new XSLHyperlinkDetector();
 int offset = 1200;
 IRegion region = new Region(offset, 0);
 boolean canShowMultipleLinks = true;
 IHyperlink[] links = linkDetector.detectHyperlinks(document, region,canShowMultipleLinks);
 assertNotNull("No links returned", links);
 assertEquals("Unexpected number of links", 1, links.length);
}

public void testDetectHyperlinksViewer() throws Exception {
 setUpTest("DraftReleaseCRs.xsl");
 XSLHyperlinkDetector linkDetector = new XSLHyperlinkDetector();
 int offset = 1200;
 IRegion region = new Region(offset, 0);

 boolean canShowMultipleLinks = true;
 IHyperlink[] links = linkDetector.detectHyperlinks(sourceViewer,
 region, canShowMultipleLinks);
 assertNotNull("No links returned", links);
 assertEquals("Unexpected number of links", 1, links.length);
}

Comments on The Server Side have been voicing concerns about SpringSource’s new maintenance policy, which gives incentive to purchase a support contract if you’re building mission critical apps on Spring. I’ve been amazed at some of the dialog, which ranges from suggestions that SpringSource has neglected its community to recommendations that they should instead ask users for donations. Since well before they became a partner of Tasktop, I have had a deep respect for the innovation and productivity benefits that Rod Johnson and SpringSource have been delivering to enterprise Java. I know first-hand how much work it takes to foster and support an active community around a new technology. When a technology makes it big, it must transition to also supporting the demands of commercial adopters, otherwise its adoption will stall. While the tone of the dialog on The Server Side has been improving, some of it confuses the notions of free software, open source community and commercial solutions.

Clearly everyone loves free software. Free software rules. That is, as long as somebody pays. If nobody paid, free software would be very boring. Innovation requires one form of investment or another, and without ongoing investment, innovation cannot flourish. The neat thing with software is that we have various options for paying.

We can pay with our time, which is typical when first adopting open source tools and frameworks. This is a great option for technologists, because it supports experimentation and encourages involvement in technical communities. For example, at Tasktop we needed a reporting solution for the time tracking feature we released in July. We experimented with Eclipse BIRT, invested considerable time in adapting that code, got involved with the community channels, and have now committed to maintaining that integration in our tool. In a similar fashion, we have been interacting with the Bugzilla community and codebase since we make very heavy internal use of Bugzilla. In both cases, the time investment has paid off.

There’s also the more traditional approach of paying with money. Tasktop Pro supports accessing all of our Microsoft Outlook and Exchange data in a task-focused way. Instead of investing our time in doing more COM programming than we already have to, we instead purchased software from Moyosoft to do this for us. It was under $2000, and reduced our development and maintenance risks. A key feature of money is that it makes it much easier to measure the total cost of adopting a solution.

In the past couple of years, the trend of paying with our eyeballs has become more popular. It’s not quite as painful as it sounds, but you have to watch out for the “death by a thousand cuts” that can result from distractions of advertising. At Tasktop, we have been using the free and ad-supported Google Apps, since the Tasktop product integrates with Google Calendar and Gmail. Our entire mission is about less being more and ensuring that the user interface shows only the relevant information, and the presence of ads is at odds with this mission. So we’re now making the switch from the ad-supported, pay with your eyeballs Google Apps, to the paying with money $50/user/year version.

Finally, if you can manage it, paying with other people’s time and money is definitely cost-effective. There are open source projects whose code comes from the countless volunteer hours of people who love to make the world a better place with great software. There are alternate economical models at our disposal too. My favourite is the gift economy of Burning Man, which I have been frequenting for years, where all get to enjoy a temporary but fully-functioning city whose citizens forego trading money or bartering for sharing gifts and smiles instead.

In my opinion, gift economies are not feasible for driving major software innovations. As soon as an innovation gets traction, it needs to cross the chasm from techy early adopters to the very different requirements that come from an onslaught of commercial adoption. The adopters of the technology who think they will get a free ride, and invest neither time nor money, take on substantial risk. They have neither a contract nor the community influence necessary to adapt to the ongoing evolution of the technology. For example, I’d be concerned if SpringSource didn’t provide 24×7 support to the major airlines who use their Web Flow technology, because I’m already having a hard enough time getting my Christmas bookings without the Air Canada site going down. Similarly, if Tasktop didn’t provide additional support, training and integration for Mylyn, the task-focused interface could not stay on its amazingly fast adoption path, because too many of the new teams adopting it want a commercially supported product instead of investing their time in the open source project.

When adopting a free technology or solution, it’s a good idea to explicitly plan on how you’re going to pay for it. One of the great benefits of open source is that you can start by paying with time, and when your dependence on the technology increases, you can identify committers or vendors who can support you beyond the time investment that you’re willing to make. Or you can decide to get involved with the project. If it’s governed on the principle of meritocracy, as is the case with all Eclipse projects, you will have some assurance that it will be time well spent. It’s nice to have options.

Oct. 7: There has been an update to the SpringSource maintenance policy.

If you are doing something specific to Mac platform, so far you might have been doing like SWT.getPlatform().equals("carbon"), stop doing it. Moving forward to 3.5, SWT will be supporting Cocoa as well, so you have to check for the cocoa string as well. This issue also pops up for Windows. You can't rely upon the platform String to be "win32", it could be "wpf" for the Vista. Just to make your life easier, there are new methods in the JFace Util class: isMac(), isWindows(), etc. You should be using these methods instead of the String comparison. More details on these methods are available in the associated bug.

private TextAttribute getXSLAttribute(String type) {

  if ((type == DOMRegionContext.XML_TAG_OPEN)
      || (type == DOMRegionContext.XML_END_TAG_OPEN)
      || (type == DOMRegionContext.XML_TAG_CLOSE)
      || (type == DOMRegionContext.XML_EMPTY_TAG_CLOSE)) {
      return (TextAttribute) getXSLTextAttributes().get(
          IStyleConstantsXSL.TAG_BORDER);
  }

  if (type == DOMRegionContext.XML_TAG_ATTRIBUTE_NAME) {
      return (TextAttribute) getXSLTextAttributes().get(
   IStyleConstantsXSL.TAG_ATTRIBUTE_NAME);
  }

  if (type == DOMRegionContext.XML_TAG_NAME) {
      return (TextAttribute) getXSLTextAttributes().get(
       IStyleConstantsXSL.TAG_NAME);
  }

  if ((type == DOMRegionContext.XML_TAG_ATTRIBUTE_VALUE)) {
      return (TextAttribute) getXSLTextAttributes().get(
       IStyleConstantsXSL.TAG_ATTRIBUTE_VALUE);
  }

  return null;
}

protected HashMap<String,TextAttribute> getXSLTextAttributes() {
   if (xslTextAttributes == null) {
     xslTextAttributes = new HashMap<String,TextAttribute>();
     loadXSLColors();
   }
   return xslTextAttributes;
}


protected void loadXSLColors() {
  addXSLTextAttribute(IStyleConstantsXSL.TAG_NAME);
  addXSLTextAttribute(IStyleConstantsXSL.TAG_BORDER);
  addXSLTextAttribute(IStyleConstantsXSL.TAG_ATTRIBUTE_NAME);
  addXSLTextAttribute(IStyleConstantsXSL.TAG_ATTRIBUTE_VALUE);
}

private TextAttribute getXSLAttribute(String type) {
  TextAttribute attribute = null;
  HashMap<String,String> regionMap = getXSLRegions();
  HashMap<String,TextAttribute> textAttributes = getXSLTextAttributes();
  
  if (regionMap.containsKey(type)) {
    attribute = textAttributes.get(regionMap.get(type));
  }
  return attribute;
}
 
protected HashMap<String,String> getXSLRegions() {
  if (xslRegionMap == null) {
    xslRegionMap = new HashMap<String,String>();
    loadXSLRegions();
  }
  return xslRegionMap;
}
 
protected void loadXSLRegions() {
  xslRegionMap.put(DOMRegionContext.XML_TAG_OPEN, IStyleConstantsXSL.TAG_BORDER);
  xslRegionMap.put(DOMRegionContext.XML_END_TAG_OPEN, IStyleConstantsXSL.TAG_BORDER);
  xslRegionMap.put(DOMRegionContext.XML_TAG_CLOSE, IStyleConstantsXSL.TAG_BORDER);
  xslRegionMap.put(DOMRegionContext.XML_EMPTY_TAG_CLOSE, IStyleConstantsXSL.TAG_BORDER);
  xslRegionMap.put(DOMRegionContext.XML_TAG_ATTRIBUTE_NAME, IStyleConstantsXSL.TAG_ATTRIBUTE_NAME);
  xslRegionMap.put(DOMRegionContext.XML_TAG_NAME, IStyleConstantsXSL.TAG_NAME);
  xslRegionMap.put(DOMRegionContext.XML_TAG_ATTRIBUTE_VALUE, IStyleConstantsXSL.TAG_ATTRIBUTE_VALUE);
}

protected HashMap<String,TextAttribute> getXSLTextAttributes() {
  if (xslTextAttributes == null) {
    xslTextAttributes = new HashMap<String,TextAttribute>();
    loadXSLColors();
  }
  return xslTextAttributes;
}
 
protected void loadXSLColors() {
  addXSLTextAttribute(IStyleConstantsXSL.TAG_NAME);
  addXSLTextAttribute(IStyleConstantsXSL.TAG_BORDER);
  addXSLTextAttribute(IStyleConstantsXSL.TAG_ATTRIBUTE_NAME);
  addXSLTextAttribute(IStyleConstantsXSL.TAG_ATTRIBUTE_VALUE);
}

I’ve been tinkering on-and-off for a couple of years on some Eclipse-based presentation software. My primary motivation is my distrust of existing presentation software. Curiously, I get a new head of steam on the “project” every time PowerPoint or Open Office fries one of my documents. Last week was one of those times.

The effort has been two-fold. Actually laying out slides is probably a pretty obvious first target. I’ve been using draw2d from GEF for this and have had some success. One of the things that drives me nuts about existing presentation software is the whole WYSIWYG editing paradigm. Frankly, I hate pushing pixels around to make stuff look right and to simply fit on a slide. Open Office is particularly annoying in this regard; in some of my presentations, the title is in a different place on almost every slide and, frankly, I can’t be bothered to spend the time to tweak each slide to make it right. Most of my effort in this area has been to automate the assembly process as possible.

Some of my effort has been around just making stuff automatically fit. I just specify a bunch of bullets, and slide render makes it fit by reducing the font size until everything fits. Its a simple algorithm, but it works. Want to add a picture? No problem, a few simple rules govern the placement and the text just flows around it. Graphics inside text is also easy using draw2d (the text management stuff is quite awesome).

The missing piece as always been the mechanism for editing slide content. A while back it occurred to me that content can just be specified using wiki markup. For example:

=Slide One Title=
* Bullet one
* Bullet two

=Slide Two Title=
[[Image:fascinating.png|right]]
* Bullet three
** Nested bullet one
** Nested bullet two
* Bullet four

The basic idea is that the heading, denoted by the equals sign (=), the slide title. Everything between this heading and the next is the content of the slide. The second slide shows a picture that will be rendered to the right of the bullets. I envision adding support for some other tags. For example, [[Method:/MyProject/src/org.eclipse.stuff.MyClass#myMethod()]] will render the contents of the specified method on the slide (taken live out of the workspace). I’m not quite there yet, but I think it’d be cool.

Using the wiki-style text will make it easier to collaborate, track changes, change templates, borrow slides from other presentations (imagine an “include slides” markup), and more. My presentations will just be projects in my workspace (images are found relative to the markup file). Most of my images are screen shots anyway, so they’ll be easy to include. More interesting images can be created with GIMP, or possibly with an SVG editor (I’ve read that GEF provides some SVG import support that I need to look into).

I’ve decided on using the MediaWiki markup for this as it’s what we use on Eclipsepedia, so I’m already familiar with it.

The best part is that most of the work has already been done. The WikiText SOC project (completed under the supervision of the Mylyn project) has implemented a Wiki parser that I’ve managed to leverage. I haven’t looked at the editors yet, but I imagine they’ll be helpful as well.

My intent is to clean up the code and contribute it to the Examples project. The initial version will provide basic image and text support. At some point in the future, I’ll sort out the method displaying option, and look into things like table support. I’ll post some pictures in the coming week.

In the meantime… is this a crazy idea?