Skip to main content

What's Your Octane?

Wherever I go in eastern Canada and the US, I've found three octane options at the gas pump. Bronze, Silver, Gold. 87, 89, 91. Regular, Plus, Premium. Western states add a discount option, 85; I'm not sure whether they're stingy or whether conditions allow a cooler fuel. I know 85 is throughout Utah, but I'm sure I've seen it elsewhere.

Just about everywhere, the button for the inexpensive, low-octane option is on the left, with the higher priced options further to the right. Except, every once in a while, you'll come across a station where they put the low octane in the middle, and the medium octane on the left.

I don't think it's an accident, or a local tradition of reading out from the middle. I think because the owner of that station believes that tricking people into buying a higher octane than the customer actually wants, is more important than serving the customer honestly.

It can't make much of a difference. Regular customers know which button is which, and buy the grade of fuel they intended to buy. Even if the profit margin is better on the higher grade, is it really worth it? Perhaps the supplier imposes some quota, or varying price levels based on quantity. That last one sounds most likely to me; a small increase in the quantity of medium grade fuel leads to a lower price on a large quantity delivered to the station.

But a business that sets out to trick customers will probably cheat them, as well. It will probably stiff the employees, use sub-standard tools and supplies. The product or service you get from them may look as good as any competitor, when it's installed, but how about months or years later?

Contrast that with the people we admire, David Strobist Hobby, Chase Jarvis and others who view photography as not just a business but a profession. They'll pursue someone who tries to rip them off, but they'll go out of their way to ensure the client is satisfied with the results.

It's the little things that enable you to identify one from the other. Not all companies can afford snazzy locations, but if you're nervous about sitting on their chairs, they may skimp on the important stuff, too. Nothing wrong with plain and simple, but the attitude toward the toilets, the secretary or tool and supply storage may indicate the attitude toward the product, as well.

Comments

Popular posts from this blog

Creating Perl5 Objects with Moxie

Having in the previous article prepared data types for car suits and card ranks, I can now combine them to provide a playing card class, using Stevan Little's Moxie module (version 0.04, so definitely early days.) The goal is to provide an object-oriented paradigm to the Perl 5 programming language which is more sophisticated, more powerful and less verbose than manually bless()-ing hashes. To achieve that goal it needs to be faster and light-weight compared to Moose. Currently, Moxie.pm and and MOP.pm are add-on modules, but eventually, when they are more complete, when the wrinkles have been ironed out, and when they have gained acceptance and a community of users, they might be merged into the Perl core.

One significant feature of Moxie is that it reduces boilerplate code. You don't have to specify warnigns or strict. As well, the features or the perl you are using are enabled, among them say, state, signatures, and post_deref.
A Simple Moxie Class package Card { …

Perl5, Moxie and Enumurated Data Types

Moxie - a new object system for Perl5 Stevan Little created the Moose multiverse to upgrade the Perl 5 programming language's object-oriented system more in line with the wonderfull world of Perl 6. Unfortunately, it's grown into a bloated giant, which has inspired light-weight alternatives Moos, Moo, Mo, and others. Now he's trying to create a modern, efficient OO system that can become built into the language.

I've seen a few of his presentations at YAPC (Yet Another Perl Conference, now known as TPC, The Perl Conference), among them ‎p5 mop final final v5 this is the last one i promise tar gz<. So I was delighted to recently see an announcement of the module Moxie, and decided to try implementing a card game.

While the package provides some POD documentation about the main module, Moxie, it doesn't actually explain the enum package, Moxie::Enum. But delving into the tests directory reveals its secrets.
Creating an Enum package Ranks { use Moxie::Enum; …

Adventures in Autovivification

Having recently started a new job, I was exposed to old code with multi-step tests against autovivification in multi-level hashes. You get used to the code you have seen, but in a new environment it‘s irritating and jarring.
Moose does not generally have the problem, first because class structure is pre-declared, because values are accessed using accessor functions rather than directly, and because responsibility is delegated down to attributes, avoiding long chains. On the other hand, Moose has it's own overhead, so hand-rolled objects, and bare structures still have their use.
If you don‘t protect against autovivification, then mis-spelling a key, or referencing keys which haven‘t been instantiated in this instance, causes those keys to instantly come into existence.
#!/usr/bin/perl use warnings; use strict; use Data::Dump 'dump'; use 5.024; my $var = {key1 => {key2 => {key3 => 'a'}}}; say dump $var; if ( $var->{key1}{key2}{key3b}[13]{foob…