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.
Category: Uncategorized
Categories
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.
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
Google Account Password Recovery
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.
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.)
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.
Categories
Calendaring with CalDAV & DAViCal
Managing my calendar is a problem I’ve been trying to solve for years. And no, I’m not willing to farm it out to a third party provider. If I was, this problem would have been solved long ago.
(For some background, see Calendar Woes, Calendar Woes (Part 2), Calendaring: Still not there…, and Events To Go. Or you could skip all that and just read this post.)
Just a bit of background, I’ve been hosting my own calendar on my home server for over 4 years, and it’s mostly worked. I used Lightning to make edits from any computer, since iCal didn’t have the ability to write to calendars stored using WebDAV. Like I said, it mostly worked. iCal (and iSync) was still needed to do the actual syncing to my phone. It was a pain, but it mostly worked.
When I moved to the iPhone, I thought my calendaring problems would be over since iTunes dealt with syncing all the calendar bits I needed. But I still had to actually sync my iPhone to my computer, using a cable, which seemed silly. I had sort of given up on having what I wanted, and thought this is how it should work… until I had a very brief discussion with Kevin where he wondered why I just didn’t use Google Calendar. After I rambled on like a madman for a few minutes, I was off to find a solution.
I found my solution… and it’s called DAViCal.
It just so happened that I got a new Ubuntu server up and running at the same time (courtesy of Kernel Design) and I figured giving DAViCal a try was worth a bit of effort, and a bit was all it took. I was quickly up and running with my own calendar, and able to add it to iCal, my iPhone, and Lightning, all with read/write privileges. The HOLY GRAIL of calendaring!
Now, DAViCal still has a way to go, but it’s GPL’d, and it works better than any other solution I tried, and it took minimal effort to get installed and configured. (I even got PostgreSQL up and running, which I never really used before.)
If you don’t like DAViCal, you could try Calendar and Contacts Server, which is also open source, and come from the Apple side of the world. It looks promising.
I know it’s dead simple to use Google Calendar or some other hosted service, but I’m one of those few people who like to have control over my data, and the backup of that data. My calendar is a personal thing, and I don’t really feel like handing that data over to someone else to take care of, and really, why should I? I know it’s the easy way out, but I’m not a fan of the easy way out, I’m a fan of freedom. The Internet is supposed to be this peer-to-peer thing with many choices, not rely on a few huge providers for everything.
Whew, what would a blog post be without a rant, eh? If you’re interested in calendaring, I recommend checking in with Calendar Swamp, which is all about the interop of the calendaring world.