Photos Spare Cycles MythBusters

January 17, 2015

Filling up the Amazon Cloud Drive

I'm currently shoving all of my photos into Amazon Cloud Drive. It appears to be the solution that I've always wanted for backing up my photos:

  1. It supports RAW photos
  2. It's cheap: unlimited photo storage if you have an Amazon Prime account
  3. Both iOS and Android apps for auto-backup and browsing
  4. It's file/folder oriented, which is necessary for backing up

I still love Google Photos for online editing and building albums, but Amazon Cloud Drive is simpler and focused on my core problem: I have 1TB of photos that I want backed up in one place.

I've been using a hodge-podge of Google Drive, Amazon S3, and Amazon Glacier to archive my old photos (especially my cycling photos). Now I can do away with all that and finally have all my photos in one place.

Pricing comparison for 1TB of photos:

  • Google Drive: $120/year
  • Amazon (S3): $180/year
  • Amazon (Glacier): $60/year

By Amazon's own pricing for other storage services, it appears that they will be losing money on me, but I imagine that my usage is an outlier; SLRs are becoming less popular and and sensors aren't getting much bigger.

NOTE: Flickr is technically the cheapest (free for 1TB), but it doesn't support RAW formats, so it's not a backup solution. Also, I find the auto-upload functionality in the Flickr mobile apps (both iOS and Android) to be very unreliable.

May 31, 2012

ROSCon 2012: Lightning Talks

ROSCon 2012 was a blast! Thanks to everyone who attended. It was a bit mindblowing to me to see something I've worked on reach the '-Con' Achievement Unlock.

January 7, 2012

Man Hands: Galaxy Nexus vs. iPhone 4S


Any review of the Galaxy Nexus will note that it's huge. I like it. I'm 6'2" and this phone is great: it's much easier to type on and I can see much more content.

In the photo above I'm holding the Galaxy Nexus and my wife is holding her iPhone 4S. My phone is smaller relative to my hand, which leads me to conclude either:

a. The iPhone is too small for me
b. The iPhone is too big for her

She says (b), as she can't fully use the phone one-handed. I can use my Galaxy Nexus just fine, so it seems (a) and (b) are both true. Regardless, anyone who argues that the 3.5" is ideal must have ideal hands.

I was going to write a Galaxy Nexus review, but got distracted by the previous post. I fear that two posts in one month is all I can manage right now

Why Android is Better Off

I think this John Gruber quote on Siri explains why I use Android:

"...the whole thing still isn't up to Apple's usual level of fit and finish, not by a long shot. But I'm still glad it's there. I think the iPhone 4S is better off with Siri in its current state than it would be if Apple had waited until Siri was further along to release it."

If I had to distinguish between Google/Android and Apple/iOS, it's that each company decides differently whether or not a new feature is "ready" to put in.

Apple typically denies a new feature/product is necessary, secretly works on it for a very long time until it's polished, and then claims their solution is better than everything else out there. Sometimes this is very true (original iPhone), other times its marketing.

Google will see a need for a feature and put it in as soon as it is useful, even if it's not fully baked yet. They will then iterate on that feature again and again to make it right.

Google's approach means that people can take advantage of features sooner. It can be more difficult to discover these features because they can start so small and they get better and better in small and frequent chunks. On the downside, Google makes more missteps (Wave, Buzz, Google TV), and the ground shifts more rapidly (Android 3, 4).

Apple's approach means that new features are usually more polished and the additional fanfare helps users discover that they exist. But you have to wait a lot longer for them to arrive (notifications, Siri, cloud sync) and there are still mistakes (Apple TV, iTunes Ping, Spaces/Launchpad/Widgets/Expose mess).

It goes almost without saying that Google's approach is the web company style, and Apple's is the desktop software style: incremental, frequent updates versus major releases.

This is all just a spectrum, and Siri is one example of Apple straying a little more towards Google's side: releasing something when it is useful, but not fully polished.

So, I find Android has many more useful features *, and that's why I'm better off. YMMV.

* cloud syncing, turn-by-turn navigation, notification, desktop widgets, voice transcription, Face Unlock, Google Voice, customizable keyboards, Android Intents (apps plugging into other apps), NFC, etc...

May 13, 2011

Cloud Robotics

Video from a talk I gave with some Googlers at Google I/O 2011.

October 5, 2010

Hacks with ROS: rosproxy

I've resurrected rosproxy, which is a hack I wrote several months ago to enable access to services and topics within a protected network. It's written in Python, so it's not super efficient, but it's useful when interfacing your robot with an external website or the like.

For example,

Internal network:

rosrun test_ros & 
rosparam set proxy/topics [chatter]
rosparam set proxy/xmlrpc_port 11313
rosrun rosproxy

External network:

rosrun rosproxy pub /chatter std_msgs/String http://externalname:11313
rostopic echo chatter
data: hello world 1286321252.19

Another related hack I did awhile back is ronin, which is a "masterless node". This is useful if you need to keep a node attached to a graph that is going up and down, e.g. if you want to pull data from a robot whenever it is up.

Both of these are "experimental" and will likely never be fully stabilized, but they are fun starting points and show some of the hackability of ROS.

September 10, 2010

Python script for Hudson API

Update: please use python-jenkins instead, which is the new-and-improved version below (and available via PyPI and in Ubuntu Oneiric).

We use Hudson to do our continuous integration -- anything from building and tests to creating documentation. It's been a fairly versatile tool for us and I highly recommend it.

I was a bit surprised to find that there were no Python scripts on the web for using Hudson's programmatic API. I ended up writing one and I'm posting it here for others to use to save themselves time. As good as Hudson is, the programmatic API is not well-documented, and there are also some annoyances like non-HTTP-compliant authentication that require minor workarounds.

We're now using this script heavily to make Hudson even more versatile: programatically creating jobs, chaining jobs, etc... We're now able to test at a much finer grain, which has led to better testing.

All the code I do for work is BSD, so enjoy: