Preparing for our Safari in Botswana

Busy entering waypoints into the Garmin GPS, here's where we're going: 

 
With a tented 4x4 that Bushlore is going to deliver to us in Kasane, we're going camping during our two week safari in and aroung the Okavango Delta. Hans (owner of Come Along Safaries) provided excellent help in organizing our trip, and was so kind to make the Garmin available to us.Without his help, I would never have been able to organize all this myself. If ever you have plans yourself go and use him, serious.

Here's some video (sorry for the google ad):


Will be posting more once we're back... (and we're back!)

Wie zit ernaast, NOS of CBS? Of misschien ikzelf?

Beste NOS,

Bij het lezen van een bericht op nos.nl (dit bericht: http://nos.nl/artikel/253897-bevolking-groeit-naar-166-miljoen.html) kreeg ik spontaan de neiging even de StatLine toepassing op het CBS te gebruiken. Ik vind StatLine (en hun gelijknamige iPhone app) een geweldige toepassing.

Tot mijn verbazing lukte het mij niet om de cijfers van het NOS artikel te matchen met die uit de StatLine toepassing van het CBS (http://statline.cbs.nl).

Ik zal proberen het punt voor punt toe te lichten.

Punt 1:
De NOS zegt: "De Nederlandse bevolking is de eerste 10 jaar van de eeuw met 700.000 mensen gegroeid tot 16,6 miljoen inwoners. Dat blijkt uit cijfers van het Centraal Bureau voor de Statistiek (CBS)." Dit is volgens mij onjuist.

In mijn beleving omvat de periode "de eerste 10 jaar van de eeuw" de volgende jaartallen: 2000,2001,2002,2003,2004,2005,2006,2007,2008 en 2009). Op 31-dec-1999 bedroeg de totale bevolking 15,865,950 mensen. Op 31-dec-2009 waren dat er 16,574,989. Het verschil is 711,039, niet 700,000.

Enfin, wellicht is 700 gemakkelijker om te lezen dan 711. Ook is het mogelijk dat de NOS per ongeluk 2001 t/m 2010 hebben genomen als periode, maar in dat geval is de groei 667,904 en dus niet 700,000.

Punt 2:
De NOS zegt: "Migratie speelde in Nederland relatief een kleine rol: 22 procent van de groei komt door migratie...". Dit is volgens mij ook onjuist, want de rol is beperkt tot 15%. In de totale periode zijn 1,077,974 mensen ge-emigreerd en 1,186,197 mensen ge-immigreerd. Totale saldo bedraagt dus 108,223 mensen (meer immigratie dan emigratie dus),  Op een totale bevolkingsgroei van 711,039 is dat 15.2% en niet 22%.

Waarschijnlijk maakt de NOS een denkfout want als we kijken naar het aandeel van geboorteoverschot t.o.v. de bevolkingsgroei, dan kom ik uit op 78%. De NOS concludeert dat de rest dan maar toegeschreven moet worden aan migratie, maar dat klopt niet. Als ik de cijfers voor migratie-saldi en geboorteoverschot bij elkaar optel, kom ik namelijk niet uit op de groeicijfers die het CBS publiceert. Gemiddeld mis ik een paar duizend mensen per jaar, en een totaal van 49,270 over de gehele periode 2000 tot en met 2009.

Ik zet het maar even op een rijtje:
                                   Aantal       Percentage
Migratie Saldo            108,223         15.2%
Geboorteoverschot      553,546         77.9%
Missende cijfers           49,270           6.9%

Totale Groei                711,039        100.0%

De spreadsheet met raw data is hier: https://spreadsheets.google.com/spreadsheet/ccc?key=0ArbwWe2DZHaNdGxnZUlVZmk4Unc3VENHbURkMTBzaEE&hl=en_US
Ik ben werkelijk benieuwd wie mij kan uitleggen waarom 6.9% van de groeicijfers lijkt te ontbreken.

Fixing a complex corruption in PostgreSQL

Since many years, we have been using PostgreSQL as the backend to our DNA Analysis solution. And very successfully so; we now have approximately 10TB of statistics in almost 500 schema's.

In order to backup a particular schema or table, we use pg_dump. However, this week it started to produce a nasty error, see below:


THE PROBLEM:
C:\Program Files\PostgreSQL\8.3\bin
>pg_dump -f c:\tmp\out.back -i -F p -v -a -h d2host -t ibmmat0001_sta.sta_db d2dna
pg_dump: reading schemas
pg_dump: reading user-defined functions
pg_dump: reading user-defined types
pg_dump: schema with OID 2613175388 does not exist
pg_dump: *** aborted because of error

With the help of google, I soon discovered we may have a corruption in one of the vital tables: pg_class.
Analyzing the problem, I first identified which tableor schema we have an issue with:
executing "select oid, * from pg_class where oid = 2613175388" shows we're dealing with a table named ls_tmp1. I know we have some of these tables in several schema's.

Next, I executed "select * from pg_tables where tablename = 'ls_tmp1'". The result is shown in the screendump below:

Notice how the troubled table does not belong to a schema (it should!). Hence the trouble reported in the pg_dump.

THE SOLUTION:
In order to repair this corruption, I created a new schema named "for_corrupt_table."
I then looked up the OID for this newly created schema.
create schema for_corrupt_table;  -- its oid became: 2613195672
Next I updated the relnamespace column to make this troubled table point to the new schema:
update pg_class set relnamespace = 2613195672 where relnamespace = 2613175388

Refreshing my pgadmin window revealed the new schema and the existing table.

Tableau with Exact Compact 2000

Today, I managed to connect Tableau with our Exact Compact 2000 application (accounting software).
Again proof of Tableau's superior capabilities to visualize virtually any source of data.

Must admit that I could have made the dasboard a bit more appealing. But my main point is that it works, without any hassle!

My next mission is to reverse engineer the data model within Exact a bit deeper, so I can start to make really appealing dashboards! (this example -of course- is giving me a life view on the entire book keeping).

Drop me a message if you;re interested in more of this stuff.

Pros and Cons of the new T-Loc Systainer from Festool

While working on my new kitchen cupboard (see this post) I decided to buy a DTS 400 at my favorite store in The Hague: Van der Toorn en Stolp. This is when I learned that Festool had introduced a new T-Loc model for their systainers.

About the New Systainer:
The new model has a cool new feature that makes life a lot easier: systainers can now be stapled with just one convenient turn of the single green handle on the front of the systainer; the T-Loc.

(zoom)

What's not so cool is the fact that I own a big tower consisting of traditional boxes only. This new systainer is not 100% compatible with these traditional models. What it means is that you can only use the new model with your 'old' tower, when you place the new one all the way at the top. Not somewhere in the middle. For me this is a disadvantage, because I want my most frequently used tools on top.

What's the problem? The picture here shows my existing configuration, with my Protool Quadrive and Centrotec on top. The systainer of the Quadrive has a powerful feature that allows me to store many attributes in the lit of the systainer. Notice on the left how efficient it is that all bits can be accessed from the top of the systainer.

There is no way you can place the new systainer in the middle of your tower. It will connect from the bottom, but there's no way you can connect it to the one above. And unlike traditional systainers -that stand relatively stable even if you do not connect them with the handles, this new container does not offer that same level of stability. See below:

My opinion:
I understand why Festool came with this new innovative T-Loc Systainer, it's great and much more efficient than the traditional ones.

What I'm a bit disappointed about is the fact that these new systainers are not backwards compatible. I would have preferred to have my new DTS shipped with the old systainer. Why doesn't Festool offer this option?

Oh, and bytheway: my new DTS is fantastic!