The SSD in Vanessa’s iMac died and needed to be replaced. In theory, this is pretty simple since we have backups — replace the faulty hardware, restore the backup, and get on with life.

In reality, it’s a little more complicated. I suppose these are small complaints since in the big picture, she didn’t lose any data. Still.

The way I carried out the restore was to

• Attach the replacement SSD in an external USB enclosure (the “drive toaster”)
• Boot off the recovery partition of the failing SSD, which still worked well enough for this purpose (otherwise I would have had to make a bootable USB stick or DVD)
• Invoke restore from Time Machine onto the new drive
• Power down, open the computer, and install the new SSD in place of the old one. (This is the hard part on a recent iMac, involving taking the screen off with suction cups, and so on.)

And we’re done, right? Not quite. Even after the Time Machine restore, a bunch of things were wonky:

• There’s no recovery partition on the new drive. You’d think Time Machine would recreate that, too, but it doesn’t. Internet wisdom says all you need to do is reinstall the current version of Mac OS X over itself and it will automatically recreate the recovery partition; I tried it and that wasn’t the case. What this means is the next failure will be harder to deal with because I’ll need alternate boot media; the manual means of creating the recovery partition at this point seem just as hard as dealing with that problem when it arises, so I’m ignoring it for now.
• Legitimate licensed Adobe CreativeSuite apps had their copy protection crap out, and refused to run with scary messages from the licensing subsystem using the word “catastrophic”. I called Adobe tech support, and they took 20 minutes to tell me to uninstall and reinstall the apps, which took another 20 minutes but worked.
• CrashPlan backups weren’t running because their software uses Java and Mac OS X ships without Java until you launch an interactive Java app at which point you’re prompted whether you want to automatically install a Java runtime.
• Time Machine backups weren’t running because who knows why, until I went into System Preferences and manually prodded them to run once, after which they kept running fine automatically.
• Mac App Store wasn’t automatically updating software until I launched it and manually signed in.

These problems could have been caused by the hard drive replacement, the restore from backup, or the OS reinstall; I don’t really know which. I just know there was a lot more to getting a working system back than letting Time Machine restore the files.

Google recently announced that after January 2013, they’ll be deprecating EAS access to Gmail (and calendar, and address book) for free customers (addresses ending in @gmail.com, and free Google Apps accounts). It’ll still be available for paid Google Apps customers, and it’ll keep working for normal customers who are already using it, but only on their existing devices.

This is bad news because EAS (aka Google Sync) has been and continues to be the best way to get Google services on an iOS device. In my opinion, iOS + Google Sync continues to be the best combination of mobile device and cloud services, but this change makes them work a little less well together.

Google Sync (EAS) is the best way to connect iOS to Google services because

• One “account” (setup step in iOS) handles mail, contacts and calendars.
• Until September 2012, this was the only way to sync contacts between iOS and Google.
• Mail works better: Push works, and the delete button works the way you’d expect. (Supposedly both iOS mail client and Gimap mail server support IMAP IDLE, but they disagree on how, or something, because the result doesn’t work.)
• Also, if you enable Google’s 2-factor authentication, you need to generate fallback “app-specific” passwords for all your devices¹, and for EAS this is one per device, and without EAS it’s at least two².

For these reasons, especially the second one, I’ve been using — and recommending to friends and family — EAS as the preferred way of connecting to Google accounts. In fact, I didn’t even realize that contact sync was now possible without it (Google just added CardDAV support in September 2012).

Similarly, I’ve been using — and recommending to friends and family — Google Apps (Gmail and friends) as my preferred provider for cloud mail/contacts/calendars. Apple’s track record for cloud mail services is spotty; even if iCloud is improving, I just don’t see the advantage over Google, especially if you don’t want to tie yourself to Apple devices forever³.

That leaves us trying to connect iOS to Google’s services as best we can. Which to be fair is pretty good, but losing EAS is a step back⁴. This speaks to something my friend Ken wrote months ago (in the context of the maps kerfuffle):

Why is it that two tech giants with best-of-breed tech in different areas rarely seem to be able to cooperate to produce an awesome product for the user?

This has been a bright spot in this regard, which is getting a little less bright at the end of January.

Google probably doesn’t care about keeping free EAS working because, in order of preference, they’d like to see

• You using an Android device to connect to Gmail+friends
• You using a (paid) Google Apps for Business account
• And for anyone else, using a non-Google device to connect to a free Google account, there are still the open protocols (IMAP for mail, CardDAV and CalDAV for calendar and contacts).

Apple may not care about optimizing the Gmail experience for iOS users because

• They’d like to see you using iCloud for mail+contacts+calendars
• Plus they’ve already connected you to Google services using EAS, so why should they have to do it again differently.

In fairness to Apple, adding a “Gmail” account to iOS adds both mail and calendars (IMAP + CalDAV), and Google only added CardDAV support on the server side in September 2012 (i.e. after the current iOS release). Maybe, hopefully, Apple will make iOS “Gmail” accounts start supporting calendars via CardDAV in the next release. In the meantime, you have to do it manually.

I don’t see any reason why the open-protocol support from iOS to Google services couldn’t work just as well as EAS — if one setup step added all 3 protocols, and if push were made to work — but it’s not the case now.

I’ve been wanting a way to preview Markdown-formatted text files from the terminal, ideally via less. Primarily, I think, because Github encourages it, a lot of open source projects are starting to include a README.md instead of a plain old README¹,²; these marked-down READMEs are easy to view in Github’s web interface but not after (or before) you clone the repo into your own filesystem.

There’s zless that can understand compressed files; why not mdless that can understand Markdown files?

I went looking and stackoverflow came to the rescue with this question and answer about a less-style markdown viewer for UNIX systems, suggesting pandoc as the tool to translate from Markdown format to troff format. The suggested incantation there works for me under Debian Linux but not under Mac OS X because it relies on man’s -l option, which I’m guessing is a GNU addition not supported by BSD man. I had to figure out how to duplicate the processing that man -l does, which I knew involved troff (or groff); it turns out that groff understands a -man flag which predefines the macros used by manpages. The version using groff instead of man -l seems more portable (it works fine under Linux as well as Mac OS X), so that’s what I’ll use.

Hence, the following incantation to view a README.md file:

pandoc -s -f markdown -t man README.md | groff -T utf8 -man | less

Or, a mdless command implemented as a tcsh alias:

alias mdless "pandoc -s -f markdown -t man \!* | groff -T utf8 -man | less"

Twice in the last few months¹ I’ve had to do troubleshooting steps on Vanessa’s iMac that involved booting from alternate volumes². This is normally easy on a Mac, but not quite so easy on a Mac with a wireless Bluetooth keyboard³.

Both times, it was an exercise in frustration, as I give the reboot command and wait about 10 seconds for the reboot to actually happen; then I hold Command-R, watch the screen blink black, wait, watch it blink white, wait, chime, wait, Apple logo, wait, and… oh hello, login screen! That’s not right. I’ve just wasted a minute and I’m back where I started.

Apple’s support document on recovery mode makes it sound so easy:

Restart your Mac and hold down the Command key and the R key (Command-R), and keep holding them until the Apple icon appears, indicating that your Mac is starting up. After the Recovery System is finished starting up, you should see a desktop with a OS X menu bar and a “Mac OS X Utilities” application window. Note: If you see a login window or your own desktop and icons, it is possible that you didn’t hold Command-R early enough. Restart and try again.

After reading and rereading that, I try a few more times, holding Command-R earlier and earlier as Apple recommends, and, no luck. Wait a minute, I’m using a Bluetooth keyboard. Does that cause complications, like, the computer and keyboard aren’t able to communicate right at the beginning of the boot process? Yes⁴. Do I need to go find a USB keyboard to plug in? Not quite.

It turns out the magic answer is to reboot the computer, wait for the LED on the keyboard to flash (which is after the computer starts booting and chimes and does a self-test which on this iMac with 12GB of memory all takes about 20 seconds), and then immediately press and hold Command-R. Any earlier than that, and you’ll be ignored.

You’d think Apple’s help docs could mention this, since they’ve been shipping Bluetooth keyboards by default with all their desktop machines for years now.

Vanessa and I wanted to take a real destination trip with Dominic, kinda sorta just to see if we could do it. Not that we were hoping or envisioning that it would be impossible, but it was hard to visualize, so we had to try.

We settled on Ireland as the destination based on two propositions: we can take the baby to the pub, and the people love babies. (These were the actual reasons recommended by an Irish friend of Vanessa.) OK, not that we’re such raging alcoholics that we can only travel to pubs, but “can take the baby to the pub” is actually a pretty good proxy for “is not uptight, and will be forgiving of people traveling with a baby”, which turned out to be true. Also true is that the Irish were not only gracious and charming hosts, but that many of them indeed like babies and know how to show it. For us, this translated to both people being prepared and understanding, but also to a lot of free entertainment. Dominic likes a lot of stimulation, and he got it.

I’m pretty proud of our itinerary, in retrospect, because we were making it up as we went along and it turned out really easy. No doubt it helps that Ireland is a small country, native English speaking (almost), and the people and culture are easygoing, so probably anything you do there is likely to go well. Still, for us it turned out remarkably easy to travel.

Here’s where we went:

The itinerary, of which I’m proud because the transfers were so easy and involved only public transit: We flew from San Francisco to London and then immediately to Dublin and caught the city bus to our hotel. Dublin: 3 days walking around, with a side DART trip to Howth. Then we walked from our hotel to Heuston Station and caught the Irish Rail train to Galway, where we stayed at a hotel a block away from the train station. Galway: 2 days walking around, with a bus/boat trip to Inishmore (largest of the Arran Islands). Then we rented a car from the Budget office right next to the train station and drove south to the Cliffs of Moher, with an overnight stay at Ennis, then to Dingle. Dingle: 2 days walking around, with a drive around the peninsula loop. Then we drove onwards to the Kerry Peninsula and around the Ring of Kerry, then to Kenmare. Kenmare: 2 days walking around including a hilly and marshy segment of the Kerry Way. Finally, leaving Kenmare, we drove past Cork to Waterford, dropped our rental car off at the tiny airport there, and caught a flight back to London Luton, from where it was an easy train ride to the London neighborhood we were staying in.

Some photographic evidence of highlights from Ireland:

Howth, a scenic day trip from Dublin:

Dominic disembarking the train in Galway with aplomb:

Galway’s Dominick Street:

O’Brien’s Castle above the Cliffs of Moher:

Dominic playing in the window seat at Murphy’s ice cream shop in Dingle:

Dominic and Vanessa taking a break from hiking the Kerry Way, above Kenmare:

Have a look at the rest of our pictures.

One more post on the topic of PG&E bills for solar (NEM) customers.

PGE’s NEM billing scheme blends usage across seasons to allow for seasonal variation in generated power, and their E-6 billing scheme separates usage into 5 time-of-use periods to encourage customers to shift usage away from peak periods.

A question that just occurred to me is whether you can game their billing results by time-shifting usage around inside the same true-up period, between TOU zones, months, or even seasons.

It’s pretty easy to move usage between TOU zones of the same day (say between summer on-peak and summer off-peak) by delaying energy-hungry activities like baking pies until night; that’s both tractable for a home customer and exactly the kind of behavior the E-6 TOU billing rates are designed to encourage. Moving usage between TOU zones of different seasons (say between summer on- peak and winter off-peak), or even from one monthly billing cycle to another, would be more difficult (it’s possible in theory but doesn’t really match human activity patterns to delay all your energy-hungry activities for months and then execute them in a big batch months later; alternatively you’d need a really big battery which is exactly what grid tie-in lets you avoid), but I’m still curious if it would be advantageous in some circumstances.

Again drawing on the example of my last year’s experience, the answer turns out to be yes for both forms of time-shifting. Say you’re going to bake a bunch of pies, and need to run the oven at 3KW for a little over 3 hours, consuming 10 KWh of electricity. (The 3 KW figure is realistic for an electric oven; the heating element running continuously is not; ignore that in the service of an example.) If you’re going to consume that 10 KWh, does it matter when you consume it; what’s the effect on your final true-up bill of adding 10 KWh at various different times?

If you can move that 10 KWh from a higher-value TOU period to a lower-value TOU period in the same day, you win; this turns out to be independent of tiering, consumption, or which month or season you’re in, which is a nice property. It won’t change your overall consumption for that day or month, so it won’t change your tiering calculation. If you had a surplus in the higher- value TOU period, you’ll now have a bigger surplus, which at the higher rate is more than enough to buy the same electricity back from PG&E later in the day, even if the solar cells aren’t producing at that time. (Basically, it wasn’t immediately obvious to me what the credit/charge calculations do in this case, because my intuition keeps wanting to tell me it’s better to consume energy when I’m getting it free from my solar panels than when I’m buying it from PG&E. That turns out not to be true; the NEM system means if you buy and sell the same amount of electricity at a given rate, it’s a wash, and the TOU system actually rewards you for selling it at a higher rate and buying it back at a lower rate.) So yes, you can “game” the E-6 billing system by moving usage from peak times to off-peak times, which use of “game” gets scare quotes because it’s actually the behavior they want to encourage.

Meanwhile, if you could move that same 10 KWh across months, the story is a lot more complicated. Due to tiering, you may be paying more than the baseline rate for some of your electricity, and since PG&E applies the tiering calculations entirely inside each month, based on that month’s usage, you can actually get crossover between “high-value” and “low-value” TOU periods. More concretely: as a solar generator, you may be paying more for winter off-peak electricity at 3rd-tier rates than you are for summer part-peak electricity where you never exceed the first tier. This is exactly what happened to me over the last year (note in the E-6 schedule that winter off-peak and part-peak above 130% of baseline cost about what summer on-peak baseline usage does, and winter off-peak and part-peak above 200% of baseline cost more than the summer on-peak baseline). While from the previous example you’d expect the result of time-shifting your usage to depend on the TOU rates (and you would win by shifting from a high-rate TOU to a low-rate TOU, and lose by doing the reverse), in fact it also depends on the tiering calculations, and you can also win by shifting usage out of a month where you had higher-tier usage into a month where you didn’t, and this can even be true if it involves shifting that usage from a low-rate TOU to a higher-rate TOU. So, surprisingly, you could see a net benefit from moving usage from winter to summer; it’s pretty easy to make the numbers work out if moving from winter part-peak to summer part-peak, and in extreme cases, you could even win by moving from winter off-peak to summer on-peak. This is decidedly not the result they want to encourage, so I’d call it gaming the system. (Of course, you’d need a way to actually buffer your usage across months; a better way to lower your winter bills is to simply use less electricity, without compensating in the opposite direction in the summer.)

I’ll note again that this perverse result derives from the fact that PG&E calculates and finalizes the tiering calculations entirely inside each month, instead of smoothing them across the true-up period, so it’s actually possible for a big energy user with an even bigger solar array to generate a net surplus for the year but be paying 4th-tier rates for winter electricity when the array is underperforming.

As a follow-on to my article on understanding the PG&E NEM bill, I decided to go back and recalculate our usage charges for the normal E-1 billing schedule, in addition to the E-6 I’m actually using.

I also threw in the calculation for the E-1 value of the electricity we generated instead of buying from PG&E, that is, how much we would have spent to buy all the electricity we used from PG&E if we hadn’t installed the solar array.

In short, E-6 was a solid win for us: a usage charge of $64.54 would have been $275.10 with E-1¹.

The results:

E-6 was a solid win for us. In the 6 winter months where we had a usage charge, the usage charge was about $10/month higher with E-1². In the 6 summer months where we had a usage credit, the usage credit was about $30/month lower with E-1³.

On the flip side, E-6 has a “meter charge” of approximately 25 cents per day, or $92 per year⁴, which E-1 does not. So our true E-6 cost (for electrical usage, plus the privilege of E-6 TOU billing) is $156.88 for the year, and E-1’s true cost remains at $275.10.

It seems like E-6 would be an easy win for anyone who can generate all of their summer on-peak electricity, or especially all of their summer on-peak and summer partial-peak electricity. (You can compare the exact prices in the E-1 and E-6 billing schedules, but the E-6 off-peak rates and winter part-peak rates are lower than E-1 rates; E-6 summer part-peak rates are a little higher than E-1 rates; E-6 summer on-peak rates are a lot higher than E-1 rates.)

I also remember being told that PG&E will let you switch from E-1 to E-6 and then at the end of the first year, if you didn’t save money, you can take a mulligan and retroactively undo the switch and pay the E-1 rate. I can’t find confirmation of that on PG&E’s website today, though.

When I got solar panels installed on the roof of our house last fall, friends immediately started asking how well they were working out, and my answer had to be that while they’re generating a nice amount of power, I wouldn’t know how well they were doing on the actual goal of zeroing our electric bill until a year had passed. That year has now passed, and it’s time to answer the question.

If you add solar power to your grid energy, at least the way it’s done in California, two things will happen:

1. Your electric bills will be lower, but
2. You won’t understand them.

The problem:

California electric rates are confusing because they’re complicated and variable. You pay a different rate depending on how much you use (tiering)¹. You can opt into time-of-use (TOU) billing², which makes electricity more expensive at peak times and cheaper the rest of the time to encourage you to shift usage away from peak times. The normal residential billing schedule is called E-1 (“residential services”) and shows 5 different rates according to tier; the TOU residential schedule is called E-6 (“residential time-of-use service”) and shows 25 different rates according to tier and time.

Once you introduce solar (or other generation capabilities) into the mix, there’s another wrinkle. Assuming you stay connected to the grid, PG&E will convert your billing to what they call NEM (Net Energy Metering), which means your electric meter will measure the flow of power in both directions — from the grid into your house when you’re using more than you’re generating, and from your house back to the grid when you’re generating more than you’re using. But solar panel output varies by season and with weather, in addition to the obvious day/night cycle. To account for this seasonal variation, PG&E bills NEM customers on a yearly cycle called the true-up period. Your monthly bills are only an approximation, and at the end of the year they calculate the actual balance owed compared to what you already paid, and have you “true up” to that amount, hence the name.

For NEM customers, that’s 3 different axes of variation³: tiered rates based on total consumption, variable rates due to time-of-use, and true-up billing to account for seasonal variation of generated output.

Before adding solar generation

You have to calculate how much electricity you want to generate to produce the desired effect (economically or ecologically or both⁴), and then you need to calculate the size of a PV solar array that will produce that effect.

Both of these calculations actually turn out to involve a fair amount of prediction. Companies that specialize in solar installations (for example, Luminalt, who installed ours) can help you with these predictions and calculations.

But even after you’ve done the calculations, decided to go solar, and had the array installed and it’s live, you still won’t know if you were right, at least for a while. That’s what this post is about. I wanted to know if we’d predicted correctly, and I also wanted to know if PG&E’s billing methods fairly account for the seasonal variation. (If I have a large surplus in summer on-peak in July, and a big deficit in winter off-peak in January, do these cancel out, and how?)

After adding solar generation

I said that after activating a solar array and switching over to PG&E’s NEM program, you’ll get lower bills that you won’t understand. Here’s what I mean. Each month with my electric bill⁵, I get a separate “Net energy metering electric statement”. It includes three amounts:

1. “total current month’s billed amount”, which is always in the neighborhood of $12.
2. “current month energy charge or credit”, which is the actual charge for electricity I used, or credit for electricity I produced, after accounting for tiered TOU rates.
3. “cumulative energy charges or credits for the current true-up period”, which is the sum of the #2 values.

This is hard to interpret month by month, partly because there’s no relationship between what I’m asked to pay (#1) and what I used (#2), and #3 will swing wildly one direction⁶ and then correct over the course of the year. All of this evens out at the end of the year, which is the reason for the 1-year true-up method of billing.

But when the 1-year anniversary arrives, and with it the final true-up payment, there’s a new confusing quantity: “total current month’s billed amount” is replaced with “total true-up billed amount”. This amount, which is your actual bill for the 12th month, is not the usual $12, bears no obvious relationship to the cumulative energy charge, and isn’t explained or derived by PG&E on the bill or elsewhere that I could find⁷. (In my case: my cumulative energy charge after 12 months was $60.22, and the “total true-up billed amount” was $22.02.) Why?

There’s a method to their madness, but I had to dig deep into PG&E’s rate documentation and then spend a few hours messing with a spreadsheet to try to derive the calculations that would map my usage to my bills.

Understanding true-up billing

First, the monthly bill. Where does this $12 come from? It turns out PG&E charges E-6 (TOU) customers a “meter charge” of approximately $0.25 per day. E6 and E-1 both also have a “minimum charge” of approximately $0.15 per day; they don’t explain what this means, but if my reverse engineering of my bills is correct, for NEM customers it’s essentially a placeholder for your usage before they know what your usage is. These fees added together and multiplied by the number of days in a billing cycle yield the approximately $12 amount that I was billed for each month (billing cycles ranged from 28 to 32 days, so the monthly bill ranged from $11.22 to $12.83, with the most common bill being $12.02 for a 30-day billing cycle).

Second, the usage charges. These are not simple (since they involve both the tiering and TOU calculations), but they are actually decently explained on the monthly NEM statement itself, and with one nitpicky exception⁸, they’re the same as what you had before you added NEM, and the true-up calculation doesn’t affect them.

Third, the cumulative usage charge. This one is completely straightforward: add the usage charges for the current true-up period, to date. Each NEM statement shows the current cumulative charge (this amount) and the amount by which it changed (the month’s usage charge), and you can verify that the current cumulative balance is equal to the previous month’s balance plus/minus the current month’s usage charge/credit. However, as mentioned above, this amount will swing one direction and then correct due to seasonal variation,

Fourth, the true-up amount. This is a simple calculation if you know where it comes from, but PG&E doesn’t explain it, so I had to reverse engineer it, learning to understand the daily meter and minimum charges. What it boils down to is that the $0.15 “minimum charge” is not a real charge once the true-up period is over, but a provisional placeholder: you pay this with each month’s $12 bill, but at the end of the year, when your real usage is known, you get back the provisional amount and pay the real amount. At the end of the year, you take your usage charge/credit, and add the meter charge ($0.25 per day or about $7.50 per monthly bill or $92.33 in a full year⁹), and that’s what you owe for the year. Except you’ve already paid that meter charge, plus you’ve paid the “minimum” usage charge as a provisional placeholder. So subtract the provisional usage charge ($0.15 per day or about $4.50 per monthly bill or $53.96 in a full year), and you have the amount that’s unpaid, that you must still pay in order to True Up. So, your first 11 bills are for 30-ish days of meter charges and minimum charges, totaling about $12; your 12th bill is for 30-ish days of meter charges, minus 335-ish days of minimum charges, plus your cumulative usage charge for the whole year. In my case, actual usage at the end of the year was $60.22, of which $46.27 had already been paid monthly as that “minimum” charge, so what I’d call the actual true-up component was $13.95; add in $8.07 in meter fees (32 days at $0.25/day) for the final billing period and we have what PG&E calls my true-up bill of $22.02.

Cancelation across TOU periods

I was curious whether a surplus in one TOU period (for example, summer on- peak, which is likely the best case for residential solar customers) can partially or wholly cancel a deficit in another TOU period (for example, winter off-peak, which is pretty much entirely dark, and thus worst-case for solar customers). As it turns out, PG&E doesn’t directly add and subtract usage across TOU periods; they convert usage to a dollar amount every month (based on TOU periods and tiering), then add and subtract the monthly dollar amounts. This is a clever way of accounting, since it’s pretty easy to understand, and does a pretty fair job of reconciling the amounts from different TOU periods. (In fact, it works out pretty well for residential solar customers, since your summer on-peak surplus is credited at a higher rate than that winter off-peak deficit.) My only complaint here is again that the tiering calculations are done per month and only affect you on the downside.

Raw facts

Here are the actual numbers from my house over the last year, which may be helpful in understanding the derivations here, making the descriptions more concrete, and/or planning your own PV solar system.

• Generated by solar: 7195 KWh
• Bought from PG&E: 1601 KWh
• Total consumed: 8796 KWh
• Months with positive grid usage, resulting in PGE charge: 6 (Oct-Mar)
• Months with negative grid usage, resulting in PG&E credit: 6 (Apr-Sept)
• Whole-year usage charge: $60.22
• Value of electricity consumed if I had to buy it all from PG&E: $2052.34 (assuming E-1 and not E-6 billing, since I don’t have the generated KWh broken out by TOU period)
• Prior-year electric bill: $1403.77
• Granular usage (from PG&E’s point of view), broken down by month and TOU billing period:

Sum-up

The true-up billing method mostly but not entirely allows you to smooth out the seasonal variation, canceling bad performance one month against good performance in another month.

You can understand your monthly bills if you think of them like this: $12 a month, $7.50 of which is just for the privilege of being connected to the grid, and $4.50 of which is a deposit against your actual usage. Meanwhile, the actual usage bill accrues in the background, and at the end of the year, you pay this balance minus a $49.50 refund for those eleven $4.50 deposits.

Due to the low NCS reimbursement it still seems to me that the optimal array size is what brings you very close to even for the year, offsetting your usage without generating much of a surplus. However, due to the way usage tiers are finalized each month instead of across the true-up period, sizing your array slightly larger than this may pay off by reducing higher-tier winter bills, even though the net surplus KWh aren’t themselves valuable in the NCS calculation.

Here are the stats on my cellular data usage over one year on Sprint’s network¹. (I got the phone on Halloween of 2011, and took this screenshot on Halloween of 2012.)

7 GB down and 1 GB up; 8 GB total; that averages to 666 MB per month. Clearly I’m not a heavy cellular data user and not making the most out of Sprint’s unlimited data allotment; this would fit comfortably within the other carriers’ smallest real² data plans (1GB/month).

Speaking of unlimited data plans: this might sound heretical to some, but I really wouldn’t mind metered data at a fair price. Say a penny a megabyte, billing you only for what you use. That comes out to $10 per gigabyte, which is actually the marginal rate that AT&T and Verizon are charging now anyway, except first they make you pay a minimum $30/month commitment and then they round up to the next gigabyte.

Of course, I also wouldn’t mind an unlimited plan that was cheap and fast and allowed tethering³.

In the meantime, here in the US we have Sprint offering unlimited data at a price that’s fair for heavy users but not especially cheap for light users, and their network isn’t the fastest and they have surcharge for tethering. Then we have AT&T and Verizon saying unlimited plans don’t incent them to invest in their networks so they’ve moved to metered plans; on the plus side their networks have gotten markedly faster and they don’t charge extra for tethering on the metered plans; however their metering methods don’t meet my definition of fair.

I’ve updated my utility for importing notes from Palm Desktop into Evernote again.

The big change is that it now uses OAuth for authentication to the Evernote service, instead of asking you for Evernote account credentials directly. This is a step forward in general; utilities like this one shouldn’t have unrestricted access to your entire account, nor should they know your actual password in case you use the same password for other services¹. Evernote has disabled username/password logins for third party apps to force them to use OAuth, a move which I think more services should make².

I also made some smaller changes to further improve the chance of success for people outside the USA, using nondefault character encoding or locale settings.

Finally, I added the public source repository to my github account. (I’ve always made the source codefor the current version available, but now the complete repository with history is public.)

Download here: http://www.maddogsw.com/evernote-utilities/evernote-palm-importer/.