Oh, right... content. Okay. I'm posting from the new Blogger Android app. I was going to link the blog announcement, but I don't see a way to add a link here. Oops.
This is a picture of a door, taken while I am writing this. Wait, where is the picture going to appear in the post? I can't tell! So... this app needs work. Oh, well.
Update: Back at the desktop, here's the link to the new Blogger Android app. And it appears that pictures show up at the end of the post. Enjoy the door.
Over the weekend I read a few articles on why Google's Chrome OS will be (or even already is!) a "failure." The common thread running through these supposedly fatal flaws was a misconception of the fundamental reasons for Chrome OS. It doesn't do everything because it doesn't need to do everything.
I have been using a Chrome OS Cr-48 netbook as my primary computer since I turned it on Thursday evening. I spend most of my personal computer time on the web. At a guess, I can probably meet 98% of my computing needs in the cloud so adjusting to the web-focused OS has been easy. I check email, catch up on the news, keep my calendar, grab a weather forecast, listen to music, and even place phone calls online. If you spend most of your computer time playing the latest first-person shooters, then Chrome OS is probably not a good choice for your primary computer.
The Cr-48 has no hard disk or DVD drive, which I've seen decried as a critical deficiency. This is only reference hardware, of course, but I have no reason to believe that a commercial product running Chrome OS would need to have them either. There is a small solid-state drive that web apps can use for local/offline storage. There's also an SD card slot that users can fill to store downloads. I could see a user possibly wanting to pop in a DVD with home videos or photos to upload or watch, and that may be supported eventually with a USB DVD drive. Cutting out these non-essential drives will make Chrome OS products smaller and less expensive, which seem like obvious wins to me.
The fact that Google is backing two separate, yet in some ways similar, operating systems seems to confuse some people. This is in part because the two overlap: Android typically runs on phones and tablets; Chrome OS is designed to run on anything from desktop PCs to tablets.
I've had an Android phone for a few months. Before the Cr-48 came along, I would check email, Google Reader, Facebook, and run the occasional Google search on my phone. The Cr-48 running Chrome OS has certainly stolen much of that activity. It's easy to have the netbook sitting next to me while I work, and I can keep it within reach on the coffee table if I'm watching TV or playing video games. Each device (and OS) has its place and I appreciate having the choice of which to use when their features ovarlap.
What I would love to see is more interaction between Android and Chrome OS devices. Chrome to Phone is a great start. But imagine if you could sit down at any Chrome OS computer anywhere in the world - say, a friend's netbook or a kiosk in a public library - and connect your phone to the USB port. The phone would prompt you to authorize the connection, and then start acting as a proxy for Chrome OS. The computer would treat you as a guest, preventing anything you do from leaving a mark on the computer after you log off and your phone, which has already authenticated your Google account, is handling all the sensitive transactions and keeping your passwords safe. If the two devices were programmed to work together properly, things like OAuth attempts could be intercepted on the phone. Instead of typing a password on the computer you're using as a guest, you would type it on your trusted Android device. Any information you access, such as a private email, would of course still reach the computer and be vulnerable if the computer has been compromised. Or if someone is standing behind you. But that seems a lot safer, to me, than typing your password into a shared or public computer.
Let's take that idea into the business world. Now, instead of you not trusting the computer it's the computer that doesn't trust you. If you could use your Android phone (or other device) as an access card, then any computer in the office could be your computer. No more suits walking the halls carrying laptops! Your IT department installs security software on the company's Android devices and Chrome OS workstations so that you can plug into any computer in the office and pick up working on that proposal document where you left off at your desk. When you unplug your phone, the computer locks up again and forgets about you before you've turned around. Your document, instead of being on the phone or on a hard disk in your cubicle, is tucked away safely in your company's private cloud.
But back to reality, here are a few more things I've been doing with Chrome OS:
I found the secret switch in the battery compartment. I flipped it to see what would happen, but I haven't gone all the way to turning on developer mode yet. I'm still enjoying seeing what it can do right out of the box.
I installed a few apps from the Chrome Web Store, which is how you add features to your Chrome OS experience (short of developer mode; see above).
I've found Scratchpad to be useful - I have been using it to keep notes on what I want to try on the Cr-48 and what I want to write about here.
Streaming HD radio with the NPR App produced mixed results. The app is slow to respond to clicks and it takes too many clicks to do simple things, like start playing my local NPR station even after I'd added it to my "favorites." It also doesn't handle having the lid closed while live streaming. When I open up again, it starts playing for a while (clearing the buffer, I assume) and then it just stops. I have to refresh the page to get it started again. On a positive note, streaming audio didn't seem to interfere with other activities, like checking email and editing documents. Chrome OS handled multitasking well.
I'm sure it says something about how much I like using the Cr-48 that I've written more blog posts on it in the last week than I usually write in a month. It isn't just having something to write about; the Cr-48 is easy and convenient to write with.
I'm still hoping to find a screen reader that works on Chrome OS, and I need to try video chat. Any other suggestions?
At the end of my post on how to Setup GoogleCL on WinXP I joked about running GoogleCL, Google's new command line tool for accessing Google service, on the Android OS. Trying to make that joke a reality, I found the Android Scripting Environment project which allows running Python scripts on Android - step one: accomplished.
Warning: this is not for the faint of heart. The instructions that follow will require you to not only install software on your Android device, but also to download and modify Python source code. I will assume that you are capable of using SVN to get source code from code.google.com and applying a .patch file. And you'll probably end up having to type on a really tiny keyboard at some point. Don't say I didn't warn you.
The easiest way to install ASE is to open up the ASE home page on your PC and scan the barcode.
Now grab the source code for GoogleCL (see here).
I needed to apply a small patch to get my setup to work with the 0.9.7 release.
Index: src/googlecl/__init__.py
===================================================================
--- src/googlecl/__init__.py (revision 299)
+++ src/googlecl/__init__.py (working copy)
@@ -156,7 +156,7 @@
import pickle
token_path = os.path.join(GOOGLE_CL_DIR, TOKENS_FILENAME_FORMAT % user)
if os.path.exists(token_path):
- with open(token_path, 'r') as token_file:
+ with open(token_path, 'rb') as token_file:
token_dict = pickle.load(token_file)
try:
token = token_dict[service.lower()]
@@ -184,7 +184,7 @@
token_path = os.path.join(GOOGLE_CL_DIR, TOKENS_FILENAME_FORMAT % user)
success = False
if os.path.exists(token_path):
- with open(token_path, 'r+') as token_file:
+ with open(token_path, 'rb+') as token_file:
token_dict = pickle.load(token_file)
try:
del token_dict[service.lower()]
@@ -236,12 +236,12 @@
import stat
token_path = os.path.join(GOOGLE_CL_DIR, TOKENS_FILENAME_FORMAT % user)
if os.path.exists(token_path):
- with open(token_path, 'r') as token_file:
+ with open(token_path, 'rb') as token_file:
token_dict = pickle.load(token_file)
else:
token_dict = {}
token_dict[service] = token
- with open(token_path, 'w') as token_file:
+ with open(token_path, 'wb') as token_file:
# Ensure only the owner of the file has read/write permission
os.chmod(token_path, stat.S_IRUSR | stat.S_IWUSR)
pickle.dump(token_dict, token_file)
I made it small on purpose because it's hard to read anyway. Hopefully, this way you'll be able to select it all and copy it easily. Apply the patch to your GoogleCL code.
The patch makes GoogleCL open the auth token file in binary mode. I needed this because later I'll be copying a token file from my desktop to my phone. Without the patch, the phone rejected token the file.
Now you need to copy your GoogleCL source onto the phone. Your Android phone may vary. On mine, I just connect to my desktop computer via USB and select "Disk Drive" as the USB connection type. This mounts the phone's storage as two removable disks. You can also remove the SD card from your phone and put it in a reader connected to your computer, since it's the card we're putting files on.
Find ase/extras/python/ on your SD card. This directory should contain a number of Python modules already, such as gdata and xml. Copy your googlecl/src/googlecl in next to them. Also copy googlecl/src/google to ase/scripts/google.py. You'll use this later when you write your talking calendar scripts.
This script changes your HOME dir to /sdcard so that GoogleCL can write your .googlecl configuration file. I wasn't able to figure out how to let GoogleCL write to the default HOME location. The other settings are what ASE uses when it runs Python scripts. I don't know how many of them are required to actually make this work, and I haven't felt like fiddling with it too much since it's working.
Replace [USERNAME] with your Google account username and save it as ase/scripts/calendar_today.sh.
#!/bin/bash
export HOME=/sdcard
export TEMP="/sdcard/ase/extras/pythontmp"
export PYTHONHOME="/data/data/com.google.ase/python"
export PYTHONPATH="/sdcard/ase/extras/python:/sdcard/ase/scripts/"
/data/data/com.google.ase/python/bin/python /sdcard/ase/scripts/google.py
--user [USERNAME] calendar list --date `date +%Y-%m-%d`
I love this part because it's so easy with Android. This script calls the one above and passes the output to the phone's text-to-speech service. Save it as ase/scripts/say_calendar.py.
import android
import subprocess
p = subprocess.Popen(
['/system/bin/sh', '/sdcard/ase/scripts/calendar_today.sh'],
stdout=subprocess.PIPE,
stderr=subprocess.PIPE)
output, errors = p.communicate()
print errors
print output
droid = android.Android()
droid.ttsSpeak(output)
Important Note for Windows Users: be sure to convert any files written on Windows to UNIX line endings before copying them to your phone. If you need to, you can also open up the files on your phone and remove the extra line end characters there. ASE has a file editor built in and I use ASTRO for editing other files.
I couldn't get the GoogleCL OAuth process to work on my phone. When I returned to ASE from completing the auth process in the browser the script had already stopped running, interrupting the authentication. I got around that by preparing a auth token file on my desktop and copying it to the phone.
Using your modified copy of GoogleCL on the desktop, authenticate to each of the services you want to use from your phone. Then take the access_tok_[username] file from the .googlecl directory under your home directory and put that file in /sdcard/.googlecl/ on your phone.
Dismount your phone's drives from your desktop, or reinstall the SD card in your phone.
Now, assuming you've followed my instructions exactly and I haven't left out anything important, you should be able to:
You should see a number of scripts listed, including the ones you just wrote. Select say_calendar.py. Your calendar entries for today should be displayed and the phone should speak them soon after. Now, it may not sound the way you expect - the TTS isn't perfect. But I think that's pretty good for a few minutes setting up some free scripting tools.
I would like to extend a very big thank you to Jason Holt and Tom Miller. Their encouragement and advice made this possible. Thanks, guys.
I must admit, I kinda want a Nook. I was never too keen on the Kindle, but this new offering from B&N appeals to me on a number of levels.
I'm rarely an impulsive gadget buyer, but if I get through the holidays without receiving one of these then the first after-Christmas sale just might tip the scales for me.
Google has announced Google I/O 2009, Developer Conference. I attended last year's event and I hope to go again this year. There will be sessions on App Engine, Android, Chrome, GWT, and other topics.
At I/O '08 I had the great pleasure of meeting members of the GWT team including Bruce Johnson, Sumit Chandel, and Miguel Mendez, as well as fellow GWT application developers. That was the first time I'd attended a developer conference and I found it completely worth the time and effort (I had to fly across the country to attend).