Hydro Ottawa's new Time-of-Use rates

I received today the notice from Hydro Ottawa explaining their new Time-of-Use billing scheme.

Quick look at the new rates

My conclusion is that it seems to raise costs for the average use case, but it's possible to lower costs slightly compared to their current level by shifting usage to off-peak periods (though I think it's unrealistic to expect to be able to save money). The price for on-peak usage (6 hours per day on weekdays) rises a lot.

The old "anytime" rate, on my latest bill (April-June), was 6.8 cents/KWh.

The new rates are:
Off-peak: 5.9 c/KWh
Mid-peak: 8.9 c/KWh
On-peak: 10.7 c/KWh

Assuming a constant load (unrealistic), and weighting these rates by the number of hours a week they apply, you get a new composite weighted rate of 7.29 c/KWh, about 7% higher than the current "anytime" rates.

If you want to keep paying the same amount as today, you'd have to have a usage profile solving for (X: off-peak, Y: mid-peak, Z: on-peak):

5.9X + 8.9Y + 10.7Z = 6.8

(any point on that plane will yield the same cost as today's rate, but the practical application is unintuitive)

So with a weighted rate only 7% higher than today, I think it's not going to be terribly more expensive, as long as you make at least a token effort to move usage outside the On-Peak timespan.

Reporting

The reporting is actually pretty cool:

It presents hourly, daily, and monthly stats, and allows downloading the data as a spreadsheet. This is actually an improvement I've been wishing for for a long time, in contrast to the previous data, which only gave you monthly usage. Now I wish I could get the same data for my gas consumption.

Non-saveable PDF forms

I think I just figured out why people create PDF forms that don't let you save the contents typed in, as annoying and unhelpful as that is.



I'll bet they're trying to protect us from ourselves, reasoning that we will fill out the form with sensitive information such as SSN, date of birth, etc., and we can't be trusted to store the saved file securely.

So they don't let us save it. It feels a little nanny-state, but I guess it's at least well-intentioned.

Edit: I think there could be a niche market opportunity here for a little piece of software that allows writing anywhere on a PDF and ignores the do-not-save flag.

Spruce Up Tech Resumes With Skill Timelines

A while back I had a bit of a chat with Jason about making tech resumes more interesting by presenting information differently: The problem I aim to solve is that listing experience with a couple technology stacks as a laundry list of keywords doesn't automatically communicate how recent or deep that experience is (I don't really want to walk into an interview and get grilled about VB.NET, which I haven't used in 6 years.)

I propose to improve things a bit by mapping whatever you'd currently include in a bullet list as a stacked timeline:


I bashed out a bit of code to generate these graphs (grab SkillTimeline on GitHub). An interesting requirement I had was that I wanted the output to be a vector graphic, as my resume is ultimately compiled to PDF by LaTeX. So I wrote something that would read in a plaintext file of skills and dates, auto-size everything properly, and generate an SVG document with the stacked timeline.

The input looks like this (I wrote an EBNF grammar when planning out the project, but it's really just a string, a colon, then comma-separated date ranges):

# Sample SkillTimeline input file.
# Provide one skill per line, and comma-separated date ranges.

SilverLight: 2010-2011.06
JavaScript: 2010-2011.06
C#: 2003.10-2006.06, 2009.01-2011.05
ASP.NET: 2004.01-2006.06
C: 2003.09-2005.12, 2009.01-2010.12
Java: 2003.09-2011.06

And the output looks something like:




Grab SkillTimeline on GitHub.

Nouveau modèle de permissions pour les aggrégateurs financiers

Un récent article de CyberPresse (que j'ai découvert via @MvtDesjardins, merci!) nous rappelle ce que l'on savait déjà: les aggrégateurs de transactions financières, bien qu'extrêmement utiles pour simplifier la gestion d'un budget (je suis un grand fan de Mint, et autrefois de feu Wesabe), présentent certains risques théoriques.

On y lit aussi un fait fort intéressant - et que j'ignorais jusqu'ici - soit que les institutions financières considèrent que l'acte de fournir à un aggrégateur comme Mint.com son NIP d'accès bancaire constitue un bris de confidentialité du NIP (les dégageant de leurs garanties vis-à-vis les opérations non autorisées). [Note: Je ne sais pas comment une banque arriverait à prouver qu'un membre possède en effet un compte sur sur un quelconque aggrégateur de transactions et a volontairement divulgué son code d'accès - la défense "ah, non, ce n'est pas mon compte, quelqu'un d'autre a dû voler mon NIP et l'enregistrer là-bas", semble plausible. C'est une discussion pour un autre jour.]

De l'article:

Ursula Menke n'en déconseille pas l'usage. "Nous suggérons des précautions, indique-t-elle. C'est une question de bien peser les risques et les bénéfices de ce genre de service."

C'est une recommendation totalement vide, car il n'y a en fait aucune précaution possible; soit on fait l'usage d'un tel service (en divulguant notre NIP à une tierce partie), ou on s'en passe complètement.

La faute pour cette situation (que, je prédis, n'est que temporaire, car c'est réglable, bien qu'un peu difficile) repose sur les banques, qui voient leurs services en ligne évoluer à un rythme glacial comparé au reste de l'industrie des services sur le Web. Nous avons besoin de nouveaux standards de transfert de données et de délégation de l'identification des usagers. Je m'explique: Le vrai problème dans tout ça, c'est qu'il n'y a actuellement aucune granularité dans le contrôle d'accès qu'un usager peut offrir aux tierces parties; c'est tout ou rien.

Il m'est actuellement impossible de fournir un accès lecture-seulement de mes transactions financières. Je dois fournir à un aggrégateur de transactions l'accès total à tous mes comptes, et les systèmes de ma banque ou caisse populaire n'ont aucun moyen de différencier un service automatisé d'un réel usager et d'appliquer des permissions différentes le cas échéant.

C'est un problème très commun dans notre industrie (en fait, GMail, Facebook, Twitter et autres ont tous eu ce problème à leurs débuts et ont dû le surmonter), et pour lequel il existe des solutions relativement simples (qui servent, au minimum, d'inspiration). N'importe-quelle archive d'informations personnelles de grande valeur pourrait me permettre de créer des jetons d'authentification afin de donner accès à un sous-ensemble de mes données à d'autres services. Du coup, on élimine totalement la divulgation des crédentiels d'authentification aux tierces parties, on permet aux consommateurs d'offrir différentes permissions à différents services, et on peut rétracter l'accès d'un service à nos données sans impact sur les autres, en invalidant le jeton associé à ce service.

Ça prendra sûrement des années, mais la balle est dans le camp des banques et des caisses populaires, qui sont les seuls à pouvoir régler ce problème.

Fantastic UX Design: the Google Chrome Developer Console

Yet another example of where the simple Chrome UI betrays the huge amount of thought that must have gone into its design and development: this is a log console done right.

If you scroll to any point in the Chrome 10 developer console while new logs are being appended to it, the scrollbar position  stays where you are and the logs are locked in place for your inspection:

However, if you scroll down to the very bottom of the window and release the scroll bar, then you get "tail -f" functionality - the window scrolls down automatically with new logs:

To pick just one example to contrast, Wireshark used a toolbar button to control this behaviour (below), while Google Chrome "just works" and does the right thing without any clutter.

Coffee Shop Subscriptions

It just occurred to me that I’ve never heard of a coffee shop subscription.


Many coffee shops already have loyalty cards, where each 10th coffee is free. This is going further (way further) in the same direction: offer a monthly all-the-lattes-you-can-drink subscription! Consider that repeat daily business is the name of the game for these places, and it’s a wonder that we’ve never seen it tried - can anyone figure out how to price the subscription to maximize revenue?

A few thoughts:

• You’d have to tie it to an individual and make it non-transferable. I think you could profitably supply me with all the lattes I can drink for a fixed price, but there’s no way it’s profitable if I buy a single subscription for my entire office.
• The right price from the consumer’s point of view would be a bit less than the cost of 18 lattes (5 per week x 4 weeks/month x 0.9 to account for loyalty cards).
• The right price from the coffee shop’s point of view is higher than that - they’re taking a risk that I won’t start drinking three a day. I imagine they can do this because the marginal cost of making more lattes is small compared to their huge fixed costs. 
• In exchange for this risk they’re getting guaranteed revenue, in advance, and the guarantee I won’t ever step foot in a competitor’s shop. You can have two loyalty reward cards and go to whichever shop is closest, but there’s no way you’d ever buy two subscriptions to competing shops.
• To mitigate the risk of abuse you could ignore the one-a-day market and target only the two-a-day heavy purchasers (since there’s an upper limit to how much coffee it’s practical to consume). Price it below what it would cost to buy two a day for a month. You’ll probably convert a bunch of your one-a-day drinkers to the subscription for a little more.
• You could market this as a conspicuous luxury item: make it a nice thick golden card that status-seeking scum-sucking yuppies will proudly flash at the register.