New from Apple: iMagicExpandingBattery

Katrin had some odd problems with her Macbook last week. The mouse button on the trackpad stopped working and the machine began locking up intermittently. I dug around for an hour or so trying to figure it out and finally gave up, figuring it was a hardware problem with the mouse.

1 trip to the Apple Store and $130 later, we had a solution: it was indeed a hardware problem, but with the battery, not the mouse. The “Genius” at the Apple Store (they really should rename that tech support role) explained that batteries in Macbooks can sometimes expand, phsyically swelling up to the point where they push against the edge of the battery container, damaging laptop internals and even cracking the case.

Don’t believe me? Check out these images of bloated and cracked Macbooks. Swollen-battery-itis.

The fix, provided your laptop isn’t irreparably damaged by this problem, is to simply buy a new battery. Although some people report online that they convinced Apple to replace the battery for free, most say Apple won’t cover the problem. Sorry for you.

The kicker: the Genius also explained:

  1. You shouldn’t leave your laptop plugged in for more than one hour after it reaches full charge. Instead, unplug and let it run down to near zero. (One assumes you should also plan your day carefully so that you are near electricity at the right times.)
  2. The expanding battery is “by design”, i.e. the battery is designed to expand so that you know it has reached the end of its life. Uhhh… no, I don’t think so. Can you imagine the battery in a car expanding to the point where it cracks the battery casing and damages the engine? In the auto industry that’s cause for a product recall.

It’s a design flaw, plain and simple. Just admit it.

I like my Macbook a lot, but problems like this and the recent iPhone antenna debacle make me wish Apple would admit failures openly and handle them with grace. I’m reminded of one of Microsoft’s more odious traits back when it was riding high: a notable arrogance and disdain towards customers. It wasn’t Microsoft products that had problems, it was “stupid customers using it wrong”.

Apple, you need us more than we need you.

The identity ‘iPhone Developer: Foo’ doesn’t match any valid certificate/private key pair in the default keychain

Great title, eh? Surprise: this is another entry in stupid stupid stupid, and like the previous one, this too is brought to you by Apple.

The problem and symptoms: you’re trying to rebuild an iPhone app that another developer worked on in the past. <– important.

Let’s say the other developer’s name is “Bert Fiddlesticks”. When you build your app in Xcode you get a build failure with a message like this:

The identity ‘iPhone Developer: Bert Fiddlesticks’ doesn’t match any valid certificate/private key pair in the default keychain.

Workarounds:

First check this great page of workarounds on fixing iPhone code signing errors. It’s way better than Apple’s developer support pages on this same topic.
You’re back? Sorry that didn’t work out for you. Great page though, eh? Hopefully you tried changing the code signing entries in your project settings to get rid of Bert’s name. Me too. No joy.

Here’s what I ended up doing:

  1. Find the project folder on disk.
  2. Open the .pbxproj file with a text editor.
  3. Search for Bert’s name. If you find it, e.g. in the code signing info section, delete everything between the quotes.
  4. Save and close the .pbxproj file.
  5. Restart xcode.
  6. Go to project settings and change the code signing entries to your own name. Do this even if you already did it earlier.
  7. Build clean and rejoice, for all should now be well.
In my case the pbxproj file had a line like this:
  "CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Developer: Bert Fiddlesticks (ABC1232)";

I changed it to look like this:

  "CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "";
Child’s play.
Elapsed time for you: 10 minutes. Elapsed time for me: 3 hours.

Fixing duplicate “login” keychains on a MacBook

Once in a while I run into silly problems — typically, software-related problems — that soak up a great deal of time. In the hopes of saving someone else pain and aggravation I’ve dedicated a blog category called “stupid stupid stupid” to these topics, and I’ll document them along with workarounds. Forthwith:

I use the Keychain Access app on my Macbook to store security certificates, passwords, and the like. A few months ago I noticed that I have two keychains called “login”. I donned my peril-sensitive sunglasses and managed to avoid thinking about it any further until yesterday, international “revive a moribund iPhone app development project” day, when I was forced to emerge from my peril-free state of blissful ignorance.

The problem: if you have two keychains called “login”, installing and using the development and deployment certificates required for iPhone app development becomes impossible. You download the certificates, install them in Keychain, and then try to develop with Xcode, but Xcode keeps failing to build or deploy with mysterious errors. This is because it can’t find the certs.

Workaround:

  1. Caveat Emptor: following these instructions blindly might screw you up. Use at your own risk. Backing up first would be smart. Don’t run with scissors.
  2. Open Keychain Access.
  3. Run Keychain First Aid from the Keychain Access menu. If this fixes it for you, great, it’s your lucky day.
  4. Select one of the keychains, click File > Delete Keychain “login”, and select “delete references only”. This fixed it for me… only one login keychain now.
  5. Delete and re-install the iPhone certificates, restart Xcode, and you should be good to go.

See also:

http://discussions.apple.com/thread.jspa?threadID=1480793

http://macosx.com/forums/archive/t-295133.html

Back to blogging…

It’s been ages since I blogged here on MyOwnPirateRadio. Now that 5 Blocks Out is off the ground I intend to post a bit more here, and on my Twitter account, and on the 5 Blocks Out blog.

You’ll be happy to know, dear reader*, that MyOwnPirateRadio topics will stay just as obscure as they’ve always been.

With that out of the way, let the games begin.

* is there more than one of you? I’ll play it safe and keep this singular.

I swear, I didn’t work on Windows 7

In the silly-marketing-antics department, my buddy Scott forwarded this screenshot around yesterday. It’s from  Steve Ballmer’s Windows 7 launch keynote slides.

Win7_Launch

In that main triangle of people in the center, the back three rows or so is lifted directly from a photo of the Live Search team. I’m in it — back row, 3rd from the left — so it must have been taken in late 2004 or early 2005.

Scott’s in it too, from many moons ago when he worked at Microsoft. In fact he’s in there at least twice.

Can’t wait for my ship-it award!

Join the Toronto Open Data Community

Toronto, we have lift-off!

The City is hosting an “Open Data Lab” on Nov 2 to kick off their community engagement on open data.

The Open Data Lab is an opportunity to explore the innovation possibilities of open civic data in Toronto. Join City subject matter and technology experts, community stakeholders and talented members of Toronto’s vibrant technology and design communities in an interactive and collaborative afternoon imagining commercial, social and civic applications of the City’s newly launched open data program.

Let’s get started.

Mint CEO on Startup Building

Mint.com CEO Aaron Patzer recently did a great presentation called “Everything you wanted to know about startup building, but were afraid to ask“. In it he chronicles the development of Mint.com from the germ of an idea all the way to exit. (Mint sold to Intuit for $170M.)

It’s not just an interesting story. He talks in fine detail about costs, salaries he paid himself and employees, equity, business model… all the things you’d need to know if you wanted to build your own company. This sort of detail is usually kept hush-hush.

The accompanying slides are here.

Every startup founder should watch this.

New York City is doing Open Data too

With an apps competition, no less.

The New York Times says:

Contestants will have access to more than 170 data sets supplied by over 30 city agencies, including weekly traffic updates, schedules of citywide events, property sales, restaurant inspections and mappable data around school and voting districts.

Exciting!

We ought to do something of similar spirit in Toronto, once people have had a chance to dogfood a version 1 “sandbox” release of open data.

See also: Open Data: What’s on Your Wish List?, Open Data: Making Toronto a Better Place to Live

5 Blocks Out has a Blog

Katrin and I have been working for a while now on a project called “5 Blocks Out“. We’ve just launched a blog for it, which you can find at blog.5blocksout.com.

The 5 Blocks Out Blog will mainly chronicle the development of the site.We’ll also post some city-related musings from time to time, similar in spirit to the posts Katrin has been writing on the Mukodu Blog.

Currently 5BlocksOut.com is in the early stages of development – but already a great deal of fun. So whether you are interested in hearing about early stage start-ups, adventures in the City or how to get the most out of the site, the blog should have something for you.

Send me a line if you would like to learn more. Or check out the new blog as it gains momentum.

Open Data: What’s on Your Wish List?

Fall is here, and I’m eagerly awaiting the sandbox and first release of City of Toronto “open data”. Since I work every day with data on 5 Blocks Out I’ve been thinking about what I would like to see opened up. In that spirit, here’s a short personal wish list.
First, some general “tenet” wishes:
- Publish all data in machine-readable open standard formats instead of just PDFs and unstructured text. JSON, XML, CSV, iCal, etc.
- Publish standard format street addresses, at least, for all location-based data. Better yet is a latitude/longitude pair.
- Publish time-based information such as events in a calendar format such as iCal.
- Any refreshable dataset needs unique durable IDs for every object in the data so readers can detect changes over time.
- Document the data at least enough for people to understand and use it productively.
Second, a few specific data sets that would be very useful:
Lists of places, including place name and location information. A foundational part of what we’re doing on 5 Blocks Out involves situating thousands of places on maps. We’re interested in all kinds of places… businesses, private organizations, and government facilities such as parks, community centres, and libraries. To do this we need trustworthy data sources with at least a name and location for each place.  Ideally the location is already stated as a latitude/longitude, but street addresses also suffice as they can be geocoded into latitude/longitude using various free geocoding web services. << geocoder, google >>
In addition to a place name and location we try to describe each place. For example, if it’s a business or a private organization, what sort of products and services does it provide? If it’s a government facility, what services does it offer to the public? How might one contact this place via phone, email, or fax? Is there a website URL available? And so on. This information is useful, but not essential.
Lastly, we look for unique identifiers, so that we can tell places apart and identify changes in place information over time. For instance, if a business moves from 123 Main Street to 245 Main Street, how do we know it’s the same business? Some data sources publish unique ID information that enable us to detect this sort of change. It turns out that  without unique IDs to rely on you need to come up with funky duplicate detection heuristics.
Here are examples of name-and-location information data sources the City of Toronto publishes today that we would love to have in easily machine-readable format:
- DineSafe lists restaurant names & addresses along with inspection data http://app.toronto.ca/food2/DineSafeMain
- Community centres: http://www.toronto.ca/parks/recreation_facilities/community-centres/index.htm
- Parks: http://www.toronto.ca/parks/parks_gardens.htm
Event data. Like many websites, we’re interested in publishing calendars of events happening throughout the city. We define “event” broadly to mean anything interesting that is time-based. An event might be a major street festival, a running race, a sporting event, a concert, or a city councillor doing a public consultation meeting. Jon Udell has done some great work on this with his ElmCity project; check it out if you’re publishing an event calendar already, or thinking about it. We endorse Jon’s idea of publishing in iCal and related formats.  We’d like to see this go a step further and have each event item include a location, as described above.
Again, the City of Toronto already publishes event data, just not in a machine-readable format. Here’s the Toronto Festivals and Events Calendar, for example http://wx.toronto.ca/festevents.nsf/.
TTC route, stop, and vehicle location information. This sort of data is obviously useful for building all kinds of apps that help people get around the city. Kieran and Kevin have done a great job reverse-engineering TTC route and stop timing data on http://myttc.ca. TTC should provide an official data stream to enable apps like theirs. The data is already in PDF format as route schedules.
There’s lots more on my list, but these are near the top.
What’s on your wish list?

Fall is here, and I’m eagerly awaiting the first release of City of Toronto “open data”. I’ve been thinking about what I’d like to see offered, both for data-hungry citizens in general and, more greedily, for accelerating our progress on 5 Blocks Out. In that spirit, here’s a short wish list.

First, some general “tenet” suggestions:

  • If you’re publishing it for humans, publish it for machines too. We need data in machine-readable open standard formats like JSON, XML, CSV, iCal, and so on. Not just PDF.
  • Publish standard format street addresses, at minimum, for all location-based data. Better yet is a latitude/longitude pair.
  • Publish time-based information such as events in a calendar format such as iCal.
  • Any refreshable dataset needs unique durable IDs for every object in the data set so that machine readers can detect changes over time.
  • Document the data at least enough for people to understand and use it productively. This sounds like a no-brainer, but apparently it has been a blocking issue in use of open data in other cities.

Second, here are a few specific data sets I would find useful for the work I’m doing:

1. Lists of places, including place name and location information.

A foundational part of what we do on 5 Blocks Out involves situating thousands of places on maps. We’re interested in all kinds of places, including businesses, private organizations, and government facilities such as parks, community centres, and libraries. To do this we need trustworthy data sources with at least a name and location for each place.  Ideally the location is already stated as a latitude/longitude, but street addresses also suffice as they can be geocoded into latitude/longitude using various free geocoding web services.

In addition to a place name and location we try to describe each place. For example, if it’s a business or a private organization, what sort of products and services does it provide? If it’s a government facility, what services does it offer to the public? How might one contact this place via phone, email, or fax? Is there a website URL available? And so on. This descriptive info is useful, but not essential.

Lastly, we look for unique identifiers, so that we can tell places apart and identify changes in place information over time. For instance, if a business moves from 123 Main Street to 245 Main Street, how do we know it’s the same business? Some data sources include unique ID information that enable us to detect this sort of change. It turns out that  without unique IDs to rely on you need to come up with funky duplicate detection heuristics.

Here are examples of name-and-location information data sources the City of Toronto publishes today that we would love to have in easily machine-readable format:

- DineSafe lists restaurant names & addresses along with inspection data

- Community centres

- Parks

2. Event data

We’re interested in publishing calendars of events happening throughout the city. We define “event” broadly to mean anything interesting that is time-based… everything from a major street festival, to a sporting event, to a city councillor doing a public consultation meeting. Jon Udell has done some great work on this with his ElmCity project; check it out if you’re publishing an event calendar already, or thinking about it. We endorse Jon’s idea of publishing in iCal and related formats.  We’d like to see this go a step further and have each event item include a location, as described above.

Again, the City of Toronto already publishes some event data, but it’s not in an easily machine-readable format. Here’s the Toronto Festivals and Events Calendar, for example. (Yes, we could build a parser to consume this particular web page, but that would be missing the point.)

3. TTC route, stop, and vehicle location information.

This sort of data is obviously useful for building all kinds of apps that help people get around the city. Kieran and Kevin have done a great job reverse-engineering TTC route and stop timing data on MyTTC.ca. The TTC should provide an official data stream to enable apps like theirs. TTC already offers the data in PDF format as route schedules.

There’s lots more on my list, but these three buckets are near the top.

What’s on your wish list?