Verbruiksstatistiek van onze Volvo 240 Station

Ik heb een tijdje bijgehouden hoeveel onze auto, een Volvo 240 Station uit 1991, nou eigenlijk verbruikt. Ik heb in deze periode bijna alleen Shell benzine getankt, want onze auto rijdt daar het lekkerst op. Alleen in Duitsland moest ik een ander merk nemen. Duitsland niet meegerekend, heb ik tijdens de tests twee verschillende benzine's getankt, want men zei mij dat dat uit zou maken op het aantal kilometers per liter. De auto is deze tijd in gebruik geweest voor woon/werk, hond uit laten, weekendtrips, etc.. De snelheid was wisselend lager, gelijk of hoger dan de maximaal toegestane. Hieronder volgen de gegevens met grafiek, waarin duidelijk wordt dat het geen reet uitmaakt wat je tankt en wanneer je tankt en hoe je rijdt - het verbruik blijft gelijk.



De rode getallen onderaan de kolommen zijn gemiddelden van de waarden in de kolom. De kosten per kilometer zijn gebaseerd op de waarde van de volle tank. De waarde van een volle tank bestaat namelijk uit de restwaarde van de nog aanwezige benzine + de nieuwwaarde van de net getankte benzine. Uitgaande van het gemiddelde aantal kilometers wat uit een tank gaat, heb je zo ook steeds een gemiddelde prijs per liter. Daar kan je dan weer de afwijkingen van meten met de werkelijke prijs. Hetzelfde is gedaan met de kosten per kilometer.

De pieken in de grafiek geven respectievelijk 3 en 2 achtereenvolgende tankbeurten weer, waarvan de kilometerstanden tijdens de rit niet bijgehouden zijn. Alleen de kilometerstanden ten tijde van vertrek en de uiteindelijke thuiskomst zijn genoteerd. De gegevens zijn daarom in deze gevallen door 3 resp. 2 gedeeld om weer op een normaal gemiddelde te komen.

Zoals je ziet, verandert het aantal kilometers per liter (oranje balk) praktisch niet. De waarde van een volle tank verandert ook nauwelijks - dit komt natuurlijk omdat de prijzen zo verschrikkelijk fluctueren. Je denkt dure V-Power te tanken terwijl een week later de Euro-Shell duurder is dan de V-Power van toen.

Image dimensions in MacJournal

MacJournal is a great blog and notebook program! However, you cannot see or edit the image's dimensions. You can drag the bottom-right corner when you want to resize an image, but also then there is no feedback regarding the image's dimensions. There is a way, though, to find out what the dimensions are, before you post. Use Art Directors Toolkit ($39.95, upgrade $19.95) or ARTIS Screen Tools ($9.95) rulers. Here is a screenshot of how you can measure an image in MacJournal with Art Director:


Here is also a screen shot with ARTIS rulers. Note that Art Director's rulers move as one block - they're connected like on a drawing table. But ARTIS Screen Rulers float independent from one another. So it is what you prefer.


Both these rulers always stay on top, and that is what is most important.

I looked at Free Ruler but those rulers are just like a document window - they do not float on top of everything. Then there is Rulers which places two rulers at your screen's top / left borders. They float on top of everything and you measure by placing horizontal and vertical guide lines on the screen. Both are not good for my purpose. For those who need it, ARTIS also offers grids and guides on your screen in the Screen Tools package as separate programs, which are, in my opinion a much nicer solution than Omnidea's Rulers.

Update 13-11-2015: Since then Xscope has emerged. Use that one, it is very good.
 

SetEXIFData 2.7

A new version of SetEXIFData is on-line. You can find it here.
This new version has the possibility of adding/subtracting a fixed amount of time and a minor repair.

Web browsers and speed

Where I work we use a home-made Transport Track & Trace System. I can't publish the page here because it contains company material, but I can say that the output for the people who need a complete overview of all ongoing transports, is a page with lots of tables:



and a lot of rows:



I used Coda to find out how many '

The transportation data (truck, shipper, consignee, forwarder, etc.) on this page is pulled from a database and the page is generated on the server, all done by a Lasso script and then send to the browser. We had some complaints about loading times, so I did a perceptual stopwatch test with different browsers and Mac OS X and Windows XP. The stopwatch started as I clicked OK on the HTTP-authentication dialog and stopped when the spinning wheel stops. Here they are:

iMac 24" from 2008 with OS X 10.6 on 3.06GHz Intel Core 2 Duo
Safari 4.0.4 : +/- 55 seconds
Firefox 3.6 : +/- 90 seconds
Chrome 4.0.249 : After 4 minutes an execution dialog and it never ends loading.

Macbook Pro from 2009 with Windows XP Bootcamp on 2.8GHz Intel Core 2 Duo T9600
Internet Explorer 8.0.6001 : After 4 minutes an execution dialog and it never ends loading.
Safari 4.0.4 : +/- 48 seconds
Firefox 3.6 : +/- 61 seconds
Chrome 4.0.249 : After 4 minutes an execution dialog and it never ends loading.

So it is true : Safari is the fastest browser.

Geocodes for SetEXIFData

Ah, I finally got the Geocoding right! I was wondering why the pawn always jumped to the nearest known location or why it always gave the nearest known location although I put the pawn in the middle of nowhere. After examining lots of example's on Google's website I finally got it : the real geocodes are in the response.name field. So now I return those to the caller - in this case SetEXIFData.

You do not need to update; it's all on the web-server side of things.