Just like NCrunch, it executes your code while you type. But instead of test outcomes, it focusses on the details of the code execution and provides invaluable insight into the contents of variables and even the control flow as you type. You can even drag a slider to see different iterations in loops. All you need is a starting point like a static method, a test method or any method where the parent type can be instantiated with some generic defaults.

This short video (~6 minutes) gives a great first impression so far:

I might take a look at the free 30 day trial as soon as I am back in Visual Studio.

<#= new CodeGenerator().Generate() #>

Next comes the question of how to implement the generator. StringBuilder? Come on, there must be a better way. I checked in another library that I knew was using code generation. Then I saw that the library was using CodeDOM. For my simple needs, I decided that this would be sufficient for the time being (and efficient, since I didn’t want to spend too much time there).

But then I started to wonder. Will CodeDOM still work with the new .NET Core?

The answer was no.

The linked StackOverflow question already includes the “replacement” of CodeDOM (CodeDOM is referred to as some precursor to part of what Roslyn does): The “new” Roslyn compiler platform (which has been around for a while by now). More specifically, the SyntaxFactory that comes with Roslyn.

The only draw-back I see immediately: The code that uses the SyntaxFactory seems a lot more verbose than the CodeDOM API. On the plus side, the Roslyn way should be superior to CodeDOM regarding features and support for language constructs.

There are already articles available for generating code with Roslyn, so I will leave the details to the interested reader.

See this GitHub page for more details and installation instructions.

I have completed half of the exercises by now. Maybe there is time for the remaining ones next week. But the weather is nice, too ;)

AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php

If the file already exists, just append the above two lines at the end.

Thanks to Schnurpsel for this hint.

Please see the MDSD report 2010 (sorry, only in German) for details on the results.

Do you make use of MDSD techniques?

Please see these great articles for more detailed instructions:

• http://techpp.com/2009/12/03/how-to-add-embed-google-wave-in-your-blog-website/
• http://www.victusspiritus.com/2009/10/15/how-to-embed-google-wave-on-your-wordpress-blog/

However, until this is fixed again, use the search term “group:public@a.wave.com” to get to the public waves in the meantime.

Update: “with:public” is working again.

• WAVELET_BLIP_CREATED
  Could not produce this event yet.
• WAVELET_BLIP_REMOVED
  Could not produce this event yet.
• WAVELET_PARTICIPANTS_CHANGED
  Participants have been added to and/or removed from a Wave. Access the new/removed participants via Event#getAddedParticipants() / Event#getRemovedParticipants()
• WAVELET_SELF_ADDED
  The robot has been added to a wave.
• WAVELET_SELF_REMOVED
  The robot has been removed from a wave.
• WAVELET_TIMESTAMP_CHANGED
  The modification timestamp of a wave has changed.
• WAVELET_TITLE_CHANGED
  The title of the wave has changed.
• WAVELET_VERSION_CHANGED
  Haven’t figured out what version means exactly.
• BLIP_CONTRIBUTORS_CHANGED
  The contributors for a blip have changed, i.e. added or removed.
• BLIP_DELETED
  A blip was removed.
• BLIP_SUBMITTED
  A new blip was created.
• BLIP_TIMESTAMP_CHANGED
  The timestamp of a blip has changed.
• BLIP_VERSION_CHANGED
  Haven’t figured out what version means exactly.
• DOCUMENT_CHANGED
  The content of a blip was changed.
• FORM_BUTTON_CLICKED
  Haven’t figured out yet what this really means.

As one can see, the description is not complete yet. Feel free to help me out in the comments ;)

package com.martinklinke.eclipse.jfreechart.demo.views;

import org.eclipse.swt.SWT;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.ui.part.ViewPart;
import org.jfree.chart.JFreeChart;
import org.jfree.chart.plot.MeterPlot;
import org.jfree.data.general.DefaultValueDataset;
import org.jfree.experimental.chart.swt.ChartComposite;

/**
* @author martin
*
*/
public class MeterChartView extends ViewPart {
   public static final String ID = "com.martinklinke.eclipse.jfreechart.demo.views.MeterChartView";

   public void createPartControl(Composite parent) {
      JFreeChart chart = createChart();
      final ChartComposite frame = new ChartComposite(parent, SWT.NONE, chart, true);
   }

   public void setFocus() {
   }

   /**
    * Creates the Chart based on a dataset
    */
   private JFreeChart createChart() {
      DefaultValueDataset data = new DefaultValueDataset(20.0);
      MeterPlot plot = new MeterPlot(data);
      JFreeChart chart = new JFreeChart("Meter Chart",
      JFreeChart.DEFAULT_TITLE_FONT, plot, false);
      plot.setNoDataMessage("No data available");
      return chart;
   }
}

The result should look like the following screenshot:

JFreeChart Speedometer in Eclipse View

Of course, the MeterPlot can be further customized by calling the plot.setXXX(…) methods. However, this exercise is left to the willing reader ;)

The core of this tool is the editor for the textual UML representation that provides many features that developers are used to (syntax highlighting, validation, outline view etc.). Additionally, Graphviz can be integrated to create diagrams from the textual models.

There are detailed instructions for the installation of TextUML and the Graphviz integration and a tutorial to get started with textual modeling.

A huge advantage of textual over graphical notations is in my opinion the possibility to create diffs which means you can easily put those textual models under version control and profit from Eclipse’s compare mechanism. This enables teams of developers to share a common model and to edit it concurrently like any other piece of source code.

According to Rafael Chaves’ (the author of the project) comment on the previously linked article,

[…] the final goal is at some point to submit a proposal to Eclipse.org […]

I hope that this goal will be reached, because TextUML is a very interesting and promising project. Claiming

• increased modeling productivity
• live graphical visualization of your class diagrams

as two of the key benefits of using TextUML, the goal should not be too far away. Productivity is always welcome and the graphical visualization may be one of the key arguments for your manager ;)

Seriously, even if it’s not the core feature of TextUML, a simple and efficient way to create class diagrams quickly would be a great win for any technical documentation or idea sketching as well.