Archived Posts from this Category

The Social Justice Tithe

Posted by Jim DeLaHunt on 31 Dec 2012 | Tagged as: culture, personal, robobait

With the year coming to an end, it is the season of making donations to organisations doing good in the world. In both Canada and the USA, this is motivated by a tax deadline; donations to certain charities by December 31 can be tax deductions for that year.  It’s an opportunity to lay out here a concept that I helped draft a decade ago: the “Social Justice Tithe”.

The Social Justice Tithe means giving at least 10% of your income to some combination of charities, religious groups, and political groups that enact your values.

Continue Reading »

Where to find Report Properties and PageSize Properties (Report Builder 3.0, SQL Server Reporting Services 2012)

Posted by Jim DeLaHunt on 30 Nov 2012 | Tagged as: robobait

This is a simple tip, but one which uncovers that which Microsoft’s Report Builder 3.0 hides in plain sight. It took me forever to figure out. Here are some screen shots, so that web searchers of the future won’t have to take so long.

Report Builder 3.0 is an application which lets you design reports for use with Microsoft’s SQL Server Reporting Services 2012 (SSRS). One of my clients has me using SSRS to generate reports, which are formatted as PDF files. Obviously this requires a pagination process: laying out report content into PDF pages of specified sizes, and keeping specified margins of blank space around the page’s edge.

I discovered that SSRS defaults to using 1″ margins around a Letter-sized page (8.5″ x 11″). I wanted to change that, to make the margins smaller, and to let me use more of the page. SSRS has pretty good documentation, including a helpful MSDN article Pagination in Reporting Services (Report Builder and SSRS). This article advises,

“By default, the page size is 8.5 x 11 inches but you can change this size by using the Report Properties, Page Setup dialog box or by changing the PageHeight and PageWidth properties in the Properties pane….  Margins are specified using the Report Properties, Page Setup dialog box or by changing the TopMargin, BottomMargin, LeftMargin and RightMargin properties in the Properties pane.”

SSRS ReportBuilder report body properties (medium)

Great! I clearly wanted to find the TopMargin and BottomMargin properties in the Properties pane. I could see the Properties pane easily (see the first screen shot, click for a full-sized rendition). But I couldn’t find any PageSize or Margin properties. Next, I looked for a way to bring up the Report Properties dialog box. I expected this to be on the Tools or Format or File menu of a Windows app. But Report Builder 3.0 is built with a new UI design, which lacked the traditional Windows menu bar.

So, for a long time I was stuck. I couldn’t find how to make report-level properties like PageSize or Margin appear in the Properties pane. And I couldn’t find the Report Properties dialog box. Nor could I find documentation on how to do these things, just documentation that assumed I could do it.  I was stuck for a couple of weeks, living with unsatisfactory margins, and getting other things done. Until I discovered the trick.

Simply put, the trick is to click outside the report body. The second screen shot adds annotations, showing important parts of the Report Builder 3.0 window.

SSRS ReportBuilder PageSize, Margin properties annotated (medium)

  • A is the report body, an obvious place to click, and not helpful for finding Report Properties and PageSize properties.
  • B is the design surface outside the report body; left-click here and report-level parameters like PageSize and Margins appear in…
  • the Properties Pane, marked as C.
  • D shows the pop-up menu which appears when you right-click on the design surface; select Report Properties… from this menu to bring up the Report Properties dialog box.

I achieved my goal, making the report margins smaller, by clicking at B. The Margins parameter set appeared in the Properties pane. From there, it was easy to adjust the value of the Top and Bottom Margins parameters.

And now I’ve published this robobait, in hopes of seeding search engines with notes of this trick, and helping others get unstuck faster.  Please let me know in the comments if this was useful.

Daytime running lights in a US Mazda 3: lessons learned

Posted by Jim DeLaHunt on 30 Sep 2012 | Tagged as: Canada, robobait

We recently imported our 2005 Mazda 3, built to California standards, into Canada. As part of that, we had to convert it to have daytime running lights — the headlights needed to stay on anytime the car is running. Why? Safety, it is said; a waste of fuel, it is also said; but the main thing is that C.R.C. c. 1038 Schedule IV Standard 108 requires it, and so we did it. It was almost, but not quite, a simple matter of installing a $40 aftermarket controller module (Hamsar 70987) Detail of Hamsar 70987 controllerbought from Canadian Tire.  Here’s the lessons we learned that weren’t in the instructions. I hope they will help others installing daytime running lights in a Mazda 3.

1. Getting physical access to the headlight wiring is hard. The module requires one wire each to be attached to the active (+) wire of the low-beam lights, high-beam lights, and turn signal lights. These lights are, on the left side, hidden under a (removable) battery compartment vent, plus various framework pieces of the engine mounting and body front. Attaching the module wire to the existing headlight wire isn’t hard; the kit includes splice taps which makes the wire splicing a simple matter of placing wires and squeezing with pliers. But physically reaching the existing wires, between and behind all that structure, was hard.

2. Mazda 3 access through wheel wellThe trick to reaching the turn signal lights is to go up from below, through the front wheel well.  The turn signal lights are nestled under a particularly thick tangle of structural members. I thought I would have to take off the headlight assembly to reach the turn signal light wiring. But no; I found a posting on reparing tail lights which explained the brilliant idea of coming up from below. I turned the steering wheel to the left, moving the forward edge of the left front wheel out of the way and opening room in the wheel well. Then I unscrewed the two screws holding the front edge of the (plastic, flexible) wheel well guard to the car body.  This allowed me to pull back the wheel well guard, reach my hand up between the guard and the body, and reach the wire harness at the back of the turn signal light without too much difficulty.

3. Wrapping the green activation wire around spark plug wires was insufficientMazda 3 spark plug wires don’t reliably trigger this module; you need to attach the wire to a wire with a reliable voltage which turns on only when the car is running. The place to find such a wire is in the wiring patch panel in the middle of the fuze box. The module has  a green wire, which controls the module. Put a voltage on this wire (relative to auto-body ground) and the module turns on the headlights. Remove the voltage, and after a few seconds, the headlights go off. The kit suggests wrapping the wire around the spark plug wire, and securing with cable ties. I suppose the idea is that the sparking voltage down the wire will induce a voltage in the wire. I tried this; the result was headlights which were on most of the time, but sagged off during deceleration. This rig failed the import inspection — twice.

Note that Mazda 3 spark plugs are wired with two small-gauge conductors, not one thick conductor. I suspect the electrical properties of the Mazda 3 spark plug wires aren’t what the module required. In any case, the green wire, wrapped around the spark plug wires, wasn’t adequate.

I was not up for determining which wire in the engine had the right voltage at the right time. So I gave up and went to a mechanic. The mechanic, having done a couple hundred such installations, had no trouble finding a wire in the patch panel which had a dependable voltage. Thus, the lights became reliable.

I hope these notes and photos will help other Mazda 3 owners who need to install aftermarket daytime running lights.

Eclipse + Mac OS X 10.5.8 + Java SE 6 => 64 bits

Posted by Jim DeLaHunt on 31 Aug 2012 | Tagged as: robobait, software engineering

I recently had an adventure trying to get a plugin, PDT, installed into my Eclipse software development environment. Diagnosis was hard, and the conclusion was non-obvious, though in hindsight, reasonable. It is that if you want to use an Eclipse plug-in that requires Java SE 6 on a Mac OS X 10.5.8 computer, you will need the 64-bit version of Eclipse.

Let me explain.

Continue Reading »

Canada Post and USPS rate cards

Posted by Jim DeLaHunt on 31 Jul 2012 | Tagged as: Canada, USA, robobait

Canada Post and the US Postal Service raised their postage rates in January, and I’ve just got around to updating my handy Canada Post and USPS postage rate quick reference card on this blog. The Canada Post rate increases were effective January 16, 2012, and the USPS increases were effective January 22.

My Canada Post and USPS Postage Rates project page,, will have links to download the latest charts as I update them.  The spreadsheet source file for the charts is also there. Both are licensed CC-BY-SA, so please feel free to re-use and modify them (as long as you attribute my work and share your product as freely).

Heads up: Canada Post has already received approval for first-class mail rate increases in 2013 and 2014. Both Canada Post and USPS offer “perpetual” or “forever” stamps, which are worth first-class basic domestic postage, whatever the price may increase to.


Ads Factory “GoogleX, GoogleY” means (lat, long) not (horizontal, vertical)

Posted by Jim DeLaHunt on 30 Jun 2011 | Tagged as: CMS, Joomla, robobait, software engineering, web technology

I want to pass along a tip about confusing field names used in the Ads Factory component for Joomla for geographic data.  I encountered this while customising this component for a client. At first I thought it was a bug, but now I think it’s just an odd naming convention.

Ads Factory, by Romanian developers The Factory,  is a commercial component for Joomla 1.5 which lets you add classified ads to your Joomla site. (My client had me working with version 1.x on Joomla 1.5, but I see there is also a version 2.1 of Ads Factory which is Joomla 1.6 native.) There are quite a few places where Ads Factory includes geographic information: each user record can record a latitude and longitude for that user; each ad can record a latitude and longitude for the advertised merchandise; and there is way to make a “radius search”, i.e. find all ads within a given distance of a user-specified location.

These latitude and longitude values are stored in database fields with name suffixes “X” and “Y”. The user’s latitude and longitude are stored in fields “GoogleX” and “GoogleY” of the Ads Factory user table. Similarly, but not completely consistently, the ad’s latitude and longitude are stored in fields “MapX” and “MapY” of the Ads Factory ads table. The confusion comes in understanding which field stores the latitude, and which stores the longitude.

Latitude is, of course, the signed number of degrees north of the equator of a point on the earth’s surface. It ranges from +90.0 (the North Pole) to 0.0 (the Equator) to -90.0 (the South Pole). Thus, it’s a vertical coordinate. Longitude is the signed number of degrees east of the 0° meridian (roughly Greenwich, England). It ranges from +180.0 to -180.0. My part of North America is 122-123° west of Greenwich, so we have longitudes of -123.0 to -122.0 or so. It’s a horizontal coordinate. This is a well-established convention in many mapping standards.

Tidy Cartesian mathematicians like me use the convention of (X,Y) coordinates, where X is the horizontal coordinate and Y is the vertical coordinate. This is a well-established convention in geometry and graphics (though there are some exceptions).

My first interpretation of Ads Factory field names like  “GoogleX” and “GoogleY” was to interpret them according to the Cartesian convention: X is horizontal, and so stores longitude, while Y is vertical, and so stores latitude. Thus (MapX, MapY) would be (longitude, latitude), the opposite of what one expects from mapping. Odd. I was surprised to find some parts of the code storing latitude in X (the horizontal coordinate!) and longitude in Y (the vertical!), which was surely a bug. I was horrified when it appeared that every part of this code had the same bug!

Then I understood the convention. Ads Factory’s developer appear to have used the (X, Y) convention to indicate just the order of the coordinates, but not their Cartesian meaning.  (MapX, MapY) means (latitude, longitude), as is conventional in mapping.  X is the vertical coordinate, Y is the horizontal coordinate, in the Ads Factory context. If you remember that X means “first”, not horizontal, and Y means “second”, not vertical, the Ads Factory field names are self-consistent, and the code uses them correctly.

I haven’t seen any Ads Factory documentation which explains this, so I hope this note will help some of you Ads Factory enhancers who are using these fields.

Postscript: what did my client ask me to do with Ads Factory for their site?  Modify the radius search to search around the user’s latitude and longitude, instead of a location the user enters. Also, to sort the keyword and category search results by distance from the user. Quite straightforward to do, though it requires customisations to the Ads Factory code that have to be re-done everytime one upgrades the Ads Factory component.

USPS rates updated on USPS and Canada Post Rate Cards

Posted by Jim DeLaHunt on 21 Apr 2011 | Tagged as: Canada, USA, robobait

Last January I got around to introducing my handy Canada Post and USPS postage rate quick reference card on this blog. On April 17th, 2011, the United States Postal Service put new, higher postage rates into effect. I’ve revised my rate cards to reflect the new USPS rates.

Continue Reading »

How to resolve EasyEclipse error ‘Eclipse… requires plug-in “system.bundle”‘

Posted by Jim DeLaHunt on 31 Mar 2011 | Tagged as: robobait, software engineering, web technology

I use the EasyEclipse distribution of Eclipse, the free (libre) software development environment. I just figured out how to fix an obscure error message:

Eclipse Web tools editors (2.0.1) requires plug-in "system.bundle"
Eclipse Data Tools (1.5.1) requires plug-in "system.bundle"

When I would start up EasyEclipse (version 1.3.1 for Mac OS X, with Python, C++, Java, PHP and more support added), it would tell me that I had some outdated components, and offer to update them for me.  But when I opened the menu item Help… Software Updates… Manage configuration, I would get the ominous error alert:

“The current configuration contains errors and this operation can have unpredictable results. Do you want to continue? [Cancel] [OK]”.

I wasn’t able to  find documentation about this problem specifically. (My purpose in writing this is to help others benefit from what I learned.)

Continue Reading »

Handy Canada and US postal rate quick reference, updated

Posted by Jim DeLaHunt on 21 Jan 2011 | Tagged as: Canada, USA, robobait

Living as I do with one foot in the USA and one foot in Canada, I find myself sending letters from Canada to Canada, Canada to the USA, and sometimes carrying mail with me over the border to mail in the USA to the USA.  I have one pile of Canada Post stamps, and another of US Postal Service stamps. But looking up the various postage rates, with their grams and ounces, was a nuisance. I couldn’t find a single rate card which covered both countries succinctly. And with each service raising its prices about once a year, my improvised rate cards were going out of date every few months.

Nearly two years ago I came up with a handy quick reference to current Canada Post and USPS postage rates for basic letters between the USA and Canada. Last spring it was polished enough that I posted it on my web site. I just now updated it to reflect the Canada Post rate increase which took effect on 17. January. You can find it at

Continue Reading »

Transparent PNG images in PHP: imagesavealpha() versus imagecolortransparent()

Posted by Jim DeLaHunt on 30 Nov 2010 | Tagged as: robobait, web technology

Are you using PHP (or libGD) to generate PNG images?  Are you having problems getting your text anti-aliased, and also having your “transparent” colour recognised as transparent?  Well, I had that problem too.  libGD, the component which PHP uses to handle image operations, gives you a choice: you can have anti-aliased text, or a designated colour as transparent… but not both.  Here’s why, and what you can do about it.

Continue Reading »

« Previous PageNext Page »