LiOn battery care: it's the heat

Apple has a page up on maximizing iPhone battery life. Some of its universally applicable to all portable devices, others apply to all iPods (see also). The list below includes the web site info, and some of my own superstitions. The item new to me is bolded ...

• Heat. LiOn batteries are damaged by heat. (I don't know if extreme cold damages the battery or simply transiently reduces output.) Keep your iPod, iPhone or laptop cool, especially when charging. Temps over 95C will reduce lifespan, so avoid leaving it in car in the summer. (A LiOn battery that's very hot during charging may be malfunctioning, as in pre-explosive. Don't wait for it combust, get it replaced.)
  
• Use the battery at least monthly. LiOn batteries don't like storage, they age even if they are never used, though this effect is less severe than it once was. If you buy a device that's been on-the-shelf for a year you should expect inferior battery performance.
  
• Run the charge from 100% to about 15-20% and recharge. (I've read this elsewhere and it gets periodically repeated. Others say there's no real problem with frequent "top off" charges except that the "battery life prediction" becomes less accurate.) A full discharge every 1-2 months will make the battery indicator more accurate. LiOn batteries age faster if they're totally drained repeatedly.
  
• Turn off bluetooth, 802.11, etc unless you need it.
• EQ settings: "Adding EQs to playback uses more of your processor, since they aren’t encoded in the song. Turn EQ off if you don’t use it. If, however, you’ve added EQ to tracks in iTunes, you’ll need to set EQ to “flat” in order to have the effect of “off,” because iPhone keeps your iTunes settings intact. Go to Settings > iPod > EQ."
  

Google Apps: An evidence-based impression

I've done enough with Google Apps, including some tech blog and notes comments, that I can provide some experienced, nay, bloodied, opinions. A short opinion, because I need to get to sleep.

1. Google Apps are vastly easier to work with if you get your domain and application set through Google (eNom) rather than trying to convert an existing site.
2. You can create and share a document, but that doesn't mean anyone else in your domain can see it. You have to send an email for them to open it, I think then it stays in their document list.
   
3. The services are very loosely "integrated". There's not even a common "start page" link. You move from service to service. Blogger is sort of integrated through the esoteric and obscure "blogger custom domain" feature -- but Blogger doesn't show up in the service list. There's no maps integration.
4. Google's Page Creator and file sharing functions are abysmal. The Page Creator is buggy.
   
5. If you want someone to be able to edit a web page they need to be a full administrator. There are only three privilege levels: administrator, user and outsider.
6. The Calendaring integration is clumsy. You can add a "Calendar" to the "start" page, but it's only a user's calendar. You can't add the shared organizational calendar or any other calendar to the start page. Calendar discovery is obscure.
   
7. Speaking of widgets, there's an lot of junk in the widget collections Google offers. Google doesn't tell us which are written by their people, and which are marketing efforts.
8. There are are bugs everywhere. Did I mention bugs? Also lots of missing functionality.

On the upside, it's free and the deal for non-profits is particularly good. On the downside it's very raw.

Aperture launchus interruptus due to Shuffle dismountus interruptus?

Most of the many bugs I run into with OS X involve the combination of managed users (less than standard user privileges), fast user switching, and devices "owned" by a single user (try switching users while an iPod is associated with a user).

I wonder if this bug falls into that category. I'd updated QuickTime and iTunes and restarted. Everything seemed well, but Aperture wouldn't launch fully. It displayed the splash screen and hung -- as though it was waiting for something. No SPOD, no spinning wheel, nothing.

I tried a few times and decided to restart. My iMac then hung on shut down, with the "spinning radial lines" effect. I left to do a few things, and 20 minutes later it was still "spining". Then I noticed the iPod shuffle light was blinking yellow. I pulled the shuffle from its cradle and the system shut down immediately. On reboot, with the Shuffle removed, Aperture opened normally.

Presumably on startup Aperture is polling disks, and the Shuffle was in an odd half-mounted state (OS X is prone to dismountus interruptus).

Something worth remembering ...

Google Apps: Configuration for a non-Google managed domain

I now have four Google App/Domain pairs and I've created a fifth Google App for Minnesota Special Hockey (at the moment the latter is down for the migration). I've also suffered through more-or-less migrating several blogs to "custom domains". Even if I ignored recent Gooflops at Gmail and Blogger my experience with Google Apps would confirm Google has way too many partially finished products. Here's some help.

If you create a Google App and register a domain (via eNom, Google isn't a registrar (!)) it's not too bad, though the documentation is scant. If you have an existing domain you want to migrate into the Google Apps suite ... well, prepare to gnaw a limb off. Unless, of course, you read this first, in which case you'll probably decide this is ridiculously complex and do something else.

Here's the secret sauce, hidden away in the help file, I found it because I knew to search help with the string "ghs.google.com".

1. Sign up for your free Google Apps. Non-profits like MN Special Hockey can start out with the regular freebie and then easily upgrade for more free support and services.
2. Now you need to validate your ownership. You can either do this with a CNAME record or you can create a file in the root of your domain that Google will look for. I prefer the file trick since CNAMEs can be treacherous. The Google page for validation will tell you what to do. (See [1] below for a bug in Google's directions.)
   
3. Change your CNAME records (these are simple redirects) to both validate your ownership (if you choose the CNAME validation) and setup your custom URLs for your content at the same time. [2]
   For example (using kateva.org, the domain that hosts this blog), create these CNAME entries all with a relationship to ghs.google.com
   news.kateva.org (for your blogger blogs, I prefer this to blog.kateva.org)
   www.kateva.org
   start.kateva.org (this is the Google Apps "desktop" page)
   calendar.kateva.org
   docs.kateva.org
   mail.kateva.org
4. Google help tells you to do use a "CNAME Lookup" service to test the CNAMEs, but when I followed their advice to "Google" for a service I found nothing. Dumb. Until you validate you can't do anything. Once you validate you can use Google App services at Google URLs.
5. Wait until you're validated, then login to your Google App (https://www.google.com/a/cpanel/kavteva.org for example) and change to the custom URLs that match the above. A bug in Google's "start" page means it always displays the non-custom URL but users can reach it via the custom URL.
6. Now go to blogger and change your blog to the custom domain of blog.kateva.org (for example)
7. If you want the email to work, you have get your ISP to change MX records: "Mail Exchange (MX) records control how incoming email is routed for your domain. Before Google can host your email, you'll need to change these MX records to point to our servers." Until then users get fairly useless generic emails.
   

[1] I attempted to validate using the old "upload file" trick, but Google's documentation of this was nonsensical. Here's exactly what they wrote (changing the secret token):

"Create a HTML verification file named googlehostedservice.html , copy the text specified below into it, and upload it to http://mnspecialhockey.org/ . googledwkgf4845250

Here's what they meant:

1. Create googlehostedservice.html
2. Put the text "googledwkgf4845250" in the file googlehostedservice.html
3. Upload googlehostedservice.html to http://mnspecialhockey.org/

[2] Some registrars let you change CNAMES yourself (yay!) others (boo, hiss) make you write them an email.

Update 7/21/07: I'm still working through this, when I'm done I'll revise this entire post. A few things to note:

1. When you're trying to integrate a pre-existing domain and hosting arrangement with Google Apps you really want direct control over you CNAME redirects. It's a pain to do this otherwise.
2. If you have a pre-existing hosting arrangement your main decision is whether to keep the original web page and file hosting or switch to Google Apps (very weak) web page designer(Google Page Creator) and file server. If the former you want to keep your domain name under the control of your host and keep a CNAME redirect of www.kateva.org (for example) to the domain name. If the latter you probably need to give up the hosting arrangement entirely and plan to recreate all web pages in Google Page Creator (impractical for any but the simplest sites). The case of mnspecialhockey.org is unusual in that we will want to move the web hosting to Google Page Creator because we need something very simple that anyone can maintain.
3. You may need to restart your router to see some of the CNAME changes. I suspect my router was caching old IP addresses, I didn't see the changes until I restarted it. Might have been coincidental.
4. There's a bug in the Google Apps "start" page. Even if you change to a custom URL and create a CNAME redirect, it still publishes to the original "partner" URL and the custom URL resolves to the "partner" URL. I thought this was a Lunarpages error, but I see the same behavior with Google/eNom managed pages.

Update 7/23/07: I've got most of the configuration working, and now I'm implementing workarounds for the one residual intractable problem -- there's no simple way to have mnspecialhockey.org redirect to www.mnspecialhockey.org. It always directs to the lunarpages "subdomain" IP address. I can redirect from index.html on that machine of course, but that doesn't help with other page requests.

Lunarpages recommended URL rewriting using my /public_html/mnspecialhockey/.htaccess file:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^mnspecialhockey.org [NC]
RewriteRule ^(.*)$ http://www.mnspecialhockey.org/$1 [L,R=301]

I'm not positive Google approves of url rewriting, but this example is fairly benign. I reviewed Matt Cutts writings on the topic and I didn't see an obvious red flag.

Update 7/24/07: The URL rewrite seems to work, though the original one I was sent had an error in it (above is corrected). Lunarpages, to their credit, quickly adjusted the MX records so the email now works.

Update 8/31/08: Things were far simpler when I switched from Lunarpages to DreamHost in August 2008. I also have a more detailed explanation of how things work.

Skype on a Mac - the authoritative review

The best I've seen: TidBITS: Choosing Mac-Compatible Skype Hardware

iPhone without the cellphone plan costs: Activate by prepaid card

A thorough analysis: iPhone + Disposable Cellphone + Prepaid Cards + New Activation Tool = Holy Cow - The Unofficial Apple Weblog (TUAW). Phone hackers are working overtime on the iPhone, and achieving some nice results. 

How to insure your iPhone and/or laptop - use your home insurance company

Great research from TUAW:

Insure your iPhone, because AT&T won't - The Unofficial Apple Weblog (TUAW)

... I decided to call a few insurance companies in the Colorado area to see if they could cover it. What many people might not know is that these companies typically cover electronics like mobile phones and even notebook computers, often at prices far cheaper than extended warranty plans from manufacturers and retail stores. While I'm not entirely familiar with how fast actin' or comprehensive this kind of coverage is from every provider, I do know that mine - State Farm - will cover both hardware failure and accidental damage (though accidental damage will cause my premiums to increase, while an incident like theft will not).

Back to getting coverage for your shiny new phone, however, the summarized rundown I got from calling three of the big general insurance providers (Allstate, Geico and State Farm) is that attaching a clause to a renter or homeowner insurance policy specifically for covering an iPhone would add only $5-20/year to a policy. Keep in mind these were estimates based on a $600 iPhone, and it appears that you can't simply ask these guys to insure a phone; you need to have some kind of a primary policy with them first, then attach this specific clause. Surprisingly, every representative I spoke with knew exactly what an iPhone was, and a couple of them asked me whether I was happy with mine.

I admit, I've been lax. I haven't been insuring my laptop with my homeowners insurance. I need to do that, and if/when I get my iPod do that too. Thanks TUAW.