Categories
Uncategorized

iPhoney

iPhoney is an iPhone simulator for web designers and developers that runs on Mac OS X. You can grab a copy of it from Marketcircle’s iPhoney page. (iPhoney is open source, and you can also find it on Sourceforge, though as of this writing the version there is not the latest.)

iPhoney does an ok-but-not-great job of replicating the iPhone Mobile Safari browsing experience. There is an option for Zoom to Fit as well as Hide/Show Location Bar, and it does let you View Source. You can also rotate it. (You can’t pinch/zoom or change the magnification beyond the Zoom to Fit capabilities.)

Here are some screen shots comparing Mobile Safari running on an actual iPhone versus running in iPhoney. (This post was used for comparison.)

Fig. 1: Mobile Safari on iPhone (vertical)

Fig. 1: Mobile Safari on iPhone (vertical)

Fig. 2: Mobile Safari on iPhone (vertical)

Fig. 2: Mobile Safari on iPhone (horizontal)

Fig. 3: iPhoney (vertical)

Fig. 3: iPhoney (vertical)

Fig. 4: iPhoney (vertical)

Fig. 4: iPhoney (horizontal)

I’ve found iPhoney useful for basic testing. It obviously does not take the place of an actual iPhone for proper testing, but if you just want a quick overview of how a page might look, it’ll work just fine. Also, since it’s open source, you can feel free to use the code as you wish, and even improve it. (Under the terms of the GPL of course.)

Categories
Uncategorized

DrawCamp: Sketchnotes with Mike Rohde

DrawCamp was held June 12, 2010 at Bucketworks in Milwaukee, Wisconsin.

Mike Rohde Expert Sketchnoter from the Sketchnote Army was on hand to demonstrate his skills, and I managed to point a camera at him and record the event.

(The video is also available at Vimeo and blip.tv.)

Categories
Uncategorized

Firefox 4 is Fast

I’ve been running the Firefox 4 betas, and I’ve been trying to keep an eye on speed, as that seems to be one of the main reasons cited for switching to Google Chrome by Firefox users I talked to.

Firefox

Now, don’t get me wrong, Chrome is fast, that much is true, but I think what a lot of people forget about is the cruft. For many users, it could be a few years since they’ve done a fresh install of Firefox. I mean fresh as in “starting with a new profile” so that all your old preferences, add-ons, plug-ins, bookmarks, and other bits weren’t there.

Right now if you download Google Chrome for the first time, and launch it, there is no cruft. It launches fast. If you’ve been upgrading Firefox over the years and not starting fresh with a new profile… well, there’s cruft.

Here’s what I did, and you can try it at home. Create a new user account (if you’re running Mac OS X, just log into the “Guest Account” that wipes itself after every logout) and launch the Firefox 4 beta. For fun launch Google Chome as well. Both will be cruft-free as they won’t have any previous preferences/profile to worry about, and will be starting fresh.

In my tests, Firefox 4 launched pretty damn fast. If Chrome launches faster, it’s probably by such a small amount that most people could never tell.

Now jump back and forth between Firefox and Chrome and load various pages. Again, don’t use any magical timers, just experience it, and see if you think they are pretty close. They look pretty close to me.

As I’ve mentioned, speed isn’t everything, but it’s nice to see the Mozilla folks stepping up their game and realizing that speed is important to a lot of people. I’ve also read some comments about finding ways to “cleanse” old profile data, to help the folks who have been using the same Firefox profile for years and years, hoping for a bit better performance.

Disclaimer: This is not scientific! I did not run any benchmarks, I didn’t test Javascript engines, or anything too crazy or stressful, I just compared the experience of launching/browsing using completely fresh installs of (the latest beta of) Mozilla Firefox and Google Chrome. I’d love to hear some comments from a Chrome convert willing to do the same tests.

Categories
Uncategorized

Google Account Password Recovery

Google

I got the following screen when logging in to Google (to use a third-party service) and I was glad to see it. I can’t remember the last time I saw this, but I think it’s something Google should show more often.

If you want to deal with this information right now, you can log into Google, go to My Account, and then Personal Settings, and then click on Change password recovery options. Make sure you’ve got at least one recovery email listed there (more would be better) and if you trust Google with your phone number, provide that as well, for SMS recovery.

While you’re in there, why not look at the data Google is storing with your account, as well as any websites you’ve authorized to access your information. These are probably things people don’t check very often, but should. Also, take a look at your dashboard now to get an idea of how much of your data Google has…

See Also: The Ultimate Guide to Gmail Account Recovery for Password and Security Issues and Account recovery via SMS.

Categories
Uncategorized

Google Reader Subscription List backup shell script

If you’re interested in exporting (or backing up) your Google Reader Subscription List you can log into Google Reader, go to Manage Subscriptions, and then Import/Export and then export your subscription as an OPML file (which is basically an XML file.)

Google Reader - Export Subscription List OPML

If you want to automate this process, there are a few steps involved… I used curl, which is easy, but other tools can also work.

The first thing you need to do is get an Auth code:


curl -daccountType=GOOGLE -d Email=[USERNAME]@gmail.com -d Passwd=[PASSWORD] -d service=reader https://www.google.com/accounts/ClientLogin 

Substitute your own Google username for [USERNAME].

Substitute your own Google password[PASSWORD].

Once you do this, you’ll get 3 lines returned, that look something like this:


SID=HFDY49j4ljlkfgdg4tfh03fdkjgldkhfl945840598djglkjh40hi5h... 
LSID=HFDY49j9ljlkfh03fhgfh565dkjgldkhfl945840598djglkjhhi5h... 
Auth=HFDY49j7ljlkfh03fdkjgldkhfl945840598djglkjhjgh6640hi5h... 

Note: I’ve shortened these (and made them up) but it’s but it’s basically 3 keys SID, LSID, and Auth and their associated values. You’ll need the value for the one labeled Auth.

Now, use curl to request the following:


curl -H "Authorization:GoogleLogin auth=HFDY49j7ljlkfh03fdkjgldkhfl945840598djglkjhjgh6640hi5h..."  http://www.google.com/reader/subscriptions/export 

Again, I’ve shortened the Auth code (it’s really long!) You’re basically passing the authorization in the header of the request. It should go without saying that the SID, LSID, and Auth should be kept private. (Which is why I just made up a random string in the example above.)

OK, if it all worked, curl returned your subscription list as OPML. Hooray! Also, you just used OAuth, so Double Hooray!

And here’s our shell script, which will download/backup your subscription list as OPML file. (It’s similar to our mysql backup schell script.)


#!/bin/bash

DT=`date +"%Y%m%d"`

curl -s -o /home/backups/SubscriptionList-$DT.opml -H "Authorization:GoogleLogin auth=HFDY49j7ljlkfh03fdkjgldkhfl945840598djglkjhjgh6640hi5h..."  http://www.google.com/reader/subscriptions/export 

Each time you run it, it will get the date with the year, month, and day and use it in the name. So %Y%m%d would produce something like 20100816. This should work fine if you run just one backup per day. (And of course you can store it somewhere besides /home/backups/ if you like. cron is your friend here.)

I know that most people believe that Google will not lose their data, or if the day comes they want to export this data, they’ll just go to the site and export it, but this lets you prepare for the day you can’t get to the site and export your data… or the day Google loses it, or deletes it, or whatever.

By the way… I found most of this information in the Google Reader API wiki. It’s nice that Google is providing an API for things, I just wish some of the info was easier to find… as of this post, that’s the only damn page in that entire wiki!

This is all part of my renewed interest in putting my own data into my own hands, and I may be bugging Jason (@plural) a bit more in the future. ;)

Update: Jason reminded us of dataliberation.org, which I’ll discuss in another post. :)

And just for fun: This gem from 2007: Data Loss At Google Reader.