the empty quarter

On this blog we have often talked about overriding the default behaviour of the BIRT chart palette by dynamically setting colours based on data values. However, it is perhaps worth looking in more detail at the palette itself to understand the default behaviour and appreciate how it can be tweaked.

Each chart has a palette. The palette determines the colours used for drawing the series in the chart. From the UI perspective, the palette options are accessed on the last tab of the Edit Chart dialog (Format Chart), the first selection in the tree on left-hand-side (Series). It is worth noting that a chart only has one palette, even if the chart contains multiple series.

By default there are 32 entries in the palette. They are used in the chart from top to bottom, i.e. in the default scenario the first category will be coloured blue, the next one red and so on. The Add and Remove buttons in the Series Palette dialog can be used to change the number of entries. What happens when the chart contains more categories than the list of palette entries? The answer is that the palette will wrap around, i.e. the 33rd category will be coloured in the same way as the first one. If the number of categories is known in advance, one can extend the palette using the Add button to create the necessary number of palette entries. (Naturally, one should question the design of such a chart, will the user really be able to extract any meaning from a chart with 32 or more different colours? In most cases, probably not.)

Each palette entry itself can be edited. Not only is it possible to set one of the predefined colours, one can also set a custom colour, a linear gradient based on two colours or even an image file. It is also possible to specify different colour for positive and negative values.

As we already mentioned, the palette colours are applied top to bottom without any further logic, in particular they are not tied to the actual data point values themselves. Several common scenarios and scripting approaches for solving the issue have already been discussed on this blog: Setting BIRT chart series palette dynamically, Setting BIRT chart series palette dynamically, part 2 – area charts, Setting BIRT chart series palette dynamically, part 3 – stacked bar charts.

In the second part of this article we will look at how the palette and related objects can be manipulated programmatically, i.e. through scripting.

By default Firefox populates the Description field of a bookmark with the content of the page’s <meta name="Description" content="..." /> tag. I find is a little annoying and was looking for a way to remove these descriptions.

Since I have a lot of bookmarks I wanted to clean them all up in one go rather than editing them one by one. Luckily there is an easy way to do this since Firefox stores the bookmarks in an SQLite database file which can be opened and manipulated.

1. Install SQLite Database Browser (Ubuntu: sudo apt-get install sqlitebrowser Windows: download and install from SourceForge).
2. IMPORTANT! Export your Firefox bookmarks to have a backup in case something goes wrong.
3. Close Firefox (you can’t edit the bookmarks file while Firefox is running).
4. Run SQLite Database Browser and open the places.sqlite file which is located in your profile folder.
5. Run the following SQL which will remove the description from all bookmarks.
   
delete from moz_items_annos where anno_attribute_id = 2  

    

6. Save and close, run Firefox.

Reference on the places.sqlite file can be found on mozillaZine and Mozilla Developer Network.

After finally getting some time to fully read up on Mono (especially on the excellent The Source) I have decided it is best to remove it from my system. The Open Sourcerer has a nicely written up set of instructions for 10.04 Lucid Lynx and 10.10 Maverick Meerkat.

In case you missed these, Innovent Solutions (one of the corporate backers of Eclipse BIRT project) published papers comparing Jasper and Pentaho to BIRT. Naturally, they conclude that BIRT is top of the pile in open source reporting, however they do justify this conclusion and the papers make an interesting read.

• BIRT versus Jasper
• BIRT versus Pentaho
• OSS Reporting Comparison Matrix

UPDATE: For an improved version of the code which works correctly with parameter groups and cascading parameters please see this updated post. Thank you to Stork for pointing out the problem with this code.

The traditional way of accessing BIRT report parameters from script is through the expression ReportContext.getParameterValue( parameterName ). Naturally this method requires one to know the name of the parameter at design time (i.e. when writing the script), which is fine in most cases.

There are however situations in which a more generic approach is preferable. For example, one might wish to implement a usage statistics system, where each time a report is run certain information is persisted in a usage tracking database. This will include the name of the report, the time of execution and perhaps also the selected parameter values. The obvious difficulty is that different reports are likely to have different sets of parameters. In anything but the simplest and smallest set of reports, it would be impractical to edit the code individually for each report. On the contrary, the appropriate approach is to create a generic library component which can be maintained in one place and referenced from the reports.

The code below is a simple demonstration how the list of parameters and their values can be read dynamically at run-time. To see it working, simply paste it into the onPrepare method of a text element.


var sOutput = "";
var parameterArray = reportContext.getDesignHandle().getParameters();
var paramaterCount = parameterArray.getCount();
for( var i = 0; i < paramaterCount; i++ )
{
  var sParName = parameterArray.get( i ).getFullName();
  var sParVal = reportContext.getParameterValue( sParName );
  sOutput = sOutput + sParName + " = " + sParVal + "n";
}
this.content = sOutput;


The following expression will dynamically get the file name of the report:

reportContext.getReportRunnable().getReportName();

Two points to note:

• The expression actually returns the full report URI rather than just the name, i.e. something like file:/C:/BIRT/Report01.rptdesign.
• The URI is percent-encoded and so space characters will be returned as %20 and so on for other special characters, e.g. file:/C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%205.5/webapps/birt-viewer/Report01.rptdesign.

Here’s a quick way to remove empty lines from a file using the Linux command line:

cat file1 | sed /^$/d > file2

Where file1 is the input file containing empty lines and file2 is a newly created file with empty lines removed.

In what is rapidly becoming a mini-series, we have so far discussed how to set BIRT chart palette dynamically (based on category values) for pie charts and area charts. Today we cover stacked bar charts, i.e. bar charts with the Optional Grouping data element.

Once again, let’s start with a quick recap. In what is a fairly common scenario, one chooses the palette colours to match with particular category values. For example, in the chart below “High” is represented in green, “Mid” in orange and “Low” in red.

However, if for a particular dataset one of the of category values is not present, the palette colours are still used in the same order, meaning the “Mid” area is now shown as red and “High” as orange. This is confusing for the end user:

As in the previous examples, we solve this problem by adding a little bit of script to override the chart’s default behaviour.


function beforeDrawDataPoint( dph, fill, icsc )
{
  var sValue = dph.getSeriesDisplayValue();
  // set( R, G, B, alpha )
  if( sValue == "1-Low" )
  {
    fill.set( 242, 88, 106, 255 );
  }
  else if( sValue == "2-Mid" )
  {
    fill.set( 232, 172, 57, 255 );
  }
  else if( sValue == "3-High" )
  {
    fill.set( 128, 255, 128, 255 );
  }
}


We also need to override the beforeDrawLegendItem method, so that colours in the legend match the chart colours.


function beforeDrawLegendItem( lerh, bounds, icsc )
{
  var sValue = lerh.getLabel().getCaption().getValue();
  var fill = lerh.getFill();
  // set( R, G, B, alpha )
  if( sValue == "1-Low" )
  {
    fill.set( 242, 88, 106, 255 );
  }
  else if( sValue == "2-Mid" )
  {
    fill.set( 232, 172, 57, 255 );
  }
  else if( sValue == "3-High" )
  {
    fill.set( 128, 255, 128, 255 );
  }
}


The palette colours are now assigned dynamically based on actual category values. The rendered chart looks as shown below, independent of the colours selected in Chart Wizard and their order.

Series labels can be shown in BIRT area charts by opening the Chart Wizard and navigating to the Format Chart tab, then selecting Series > Value (Y) Series > Show Series Labels checkbox. The result will look as shown in the screenshot below:

Often there is one particular grouping (series) which is especially important and we want to draw the report viewer’s attention to it by showing the labels for that series only. This cannot be achieved through the Chart Wizard UI but can be done with a bit of scripting.

The method which needs to be overriden is beforeDrawSeries. In this example, series labels will be shown for the “1-Low” series and hidden for the other ones.


function beforeDrawSeries( series, isr, icsc )
{
  // get class of the renderer
  var type = isr.getClass().toString();
  // check for area chart renderer
  if( type == "class org.eclipse.birt.chart.render.Area" )
  {
    var val = isr.getSeriesRenderingHints().getDataPoints()[0].getSeriesDisplayValue();
    if( val == "1-Low" )
    {
      series.getLabel().setVisible( true );
    }
    else
    {
      series.getLabel().setVisible( false );
    }
  }
}


The result looks as follows:

Changing the port number of SSH daemon is a quick way of reducing the number of SSH brute force attacks your server might face (check the file /var/log/auth.log to see if there are many failed SSH login attempts).

1. Just to be on the safe side, create a backup copy of the SSH daemon config file.
   
   sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.vanilla

2. Edit the config file.
   
   sudo vi /etc/ssh/sshd_config

3. Change the port number on the following line, e.g. to 2201 or some other unused port. Make sure you note down the port number.
   
   Port 22

4. Restart the SSH daemon. You might get kicked out of your existing session.
   
   sudo /etc/init.d/ssh restart

5. When you login next remember to include the correct port.
   
   ssh youruser@yourserver -p 2201