March 13, 2010

bye bye fly

Finally plane commuting ends. After 4 months of flying up and down beween bxl and fco I'm on 'my last flight'. The flight's delayed of course, according to great brussels airline tradition but none is talking cancellation until now.
I'm looking forward to being with my wife and daughter every day again.
It was nice flying but trop is te veel en te veel is trop.

March 11, 2010

kubuntu kde globe wallpaper


While I was cleaning up the desktop of my laptop, I noticed (toying with the screensaver) that under wallpapers the option 'globe' had appeared.


After enabling it, I noticed that some Google Earth View like kind of map had appeared as my desktop wallpaper. Not just an image, but a 'live' view (or simulated live view) of the planet. Cool.

So now, while I'm hacking my way through the night, I can actually follow where on the planet it is night, and where it is daytime. Maybe this will help me to get back to a normal day rhythm?

Anyway, it is tremendously pleasant to stumble upon such nice features in kde. I know it's eye candy. But it's very well done, for free and 'just there', without need for installing. I'm not entirely sure how easy a Windows 7 user can get something similar. But then again, I haven't touched Windows for some time :-)


March 10, 2010

Stop getting burned

I guess this add have been out there for some time already, but still, for those who didn't see it yet, and want to have a laugh, check out Pentaho's pop-art marketing on commercial BI vendors. Those guys at Pentaho must have a lot of fun  :-)


sudo to the rescue

March 8, 2010

user defined command line parameters in the kitchen


Just recently I stumbled upon a way to pass custom command line parameters to PDI jobs that are executed through kitchen. Somehow, this isn't documented in the user documentation , so I thought a few lines were in place.

According to the Pentaho documenation, kitchen supports the following series of command line parameters:
  • file: xml file (job) to execute
  • log: log file
  • level: logging level (Nothing, Error, Minimal, Basic, ... Rowlevel)
  • rep: repository name
  • user: user to log in to repository
  • pass: password to log in to repository
  • listdir: list directories in repository
  • listjobs: list repository jobs
  • listrep: list available repositories
  • norep: don't log into repository
  • dir: set repository directory
  • job: repository job to run
  • export: file to export a job/trf too (including all related jobs/trf)
These are however all standard parameters. If you want to pass your own parameter into the job you are launching, I thought I was down to postional arguments, however that seemed not to be true.

An undocumented parameter - at least it wasn't in any user documentation I was capable of finding - is the parameter called param, used to pass named parameters. E.g. you could specify the following when executing a job using kitchen:

sh -file=/daily_run.kjb -level=Basic -param:AFFILIATE=affiliate01 -logfile=/daily_run.log

This would pass the value "affiliate01" to the variable AFFILIATE in the job "daily_run.kjb". For this to work the job needs to have the input parameter defined in the parameters tab of the job properties.

Simple as that.



Some links that could have brought you there:
- Kitchen user documentation
- Pentaho forum: "pass env variables into job via kitchen from cmd line
- Matt's blog (--> where I found the mustard :-)  )
- Jira by Sven Boden who actually asked for this feature

March 7, 2010

333 rule to keep your BI apps in check

I really loved this post of Boris Evelson on Information Management Blogs, March 3, 2010.

The essence of the 333 rule:
  • Whenever there is a request for a new report that requires new data source or additional data sets from existing sources, first create manual extracts, pull them into text files and create "reports" on top of these extracts
  • If, and only If, after 3 weeks, the new reports are still being actively used, they then point the reports directly to the operational data sources.
  • If, and only If, after 3 months, the reports are still being actively used, they then create new DW tables and populate them with the new data sets.
  • If, and only If, after 3 quarters, the reports are still being actively used, they then completely productionalize  the process with QA, UAT, DR and other production controls, risk management, and operational procedures.
 Although this is a great rule of thumb for assuring that your BI environment doesn't get clogged up with junk, the rule kind of creates a difficulty in budget management. Of course you need to explain your business users that the "cheap" report you created for them initially, based on a simple extract, will need to be "rewritten" 3 times. That is they will have to pay several times over for the exact same functionality. Not impossible, but you'd better take that communication upfront. And you'll have to do some user "education" to explain them the why and how.