Google Glass Screen Sharing Made Easy (Not)

I needed a simple way to screencast from Glass to my MacBook Pro, and I found it (only after a few hours of searching and tinkering).

Here's the scoop:

1. Install Java for Mac OSX

2. Install the Android SDK
I downloaded both the SDK and the IDE, and ended up putting this in my user directory. I also renamed parent folder "Android" (because I found "adt-bundle-mac-x86_64-20130729" a bit unwieldy). Note that if you rename this parent folder, you'll have to update the SDK directory location in the settings when you launch Eclipse.

3. Update your path to include pointers to the Android Debug Bridge (ADB)
I actually had to create a new file in my user directory called ".bash_profile". (The assorted references I found while searching also talk about a file called ".profile" -- so I went ahead and created both.) Here's what that file / those file should contain:
export PATH="/Users/[YOUR_USER_NAME]/[YOUR_ANDROID_SDK_DIRECTORY]]/sdk/tools/":$PATH
export PATH="/Users/[YOUR_USER_NAME]/[YOUR_ANDROID_SDK_DIRECTORY]]/sdk/platform-tools/":$PATH

4. Turn on debugging on Android phone
Open up your device’s “Settings”,  scroll to the bottom and tap “About phone”, and then tap on the Build Number seven times. Seriously - seven times. Not six, not eight...seven. (All we're missing now is some arcane enchantment or mystic prunes.)
http://developer.android.com/tools/device.html

NOTE: If you don't have an Android device, you can go directly from Glass to the Mac...but that means having to tether yourself via a USB cable during a presentation. To do this, enable debug mode on Glass by going to Settings > Device Info > Turn on Debugging. (Thanks to Ryan Warner for this tip.)

5. Download Android Screencast
I also came across Android Screen Monitor, but I was unable to get that to work. Here's a link in case you, gentle reader, have more success.

6. Connect your phone to your computer
Just plug it into the USB port. You can check to make sure it's connected by running the following command in Terminal:
adb devices

7. Run Android Screencast
Right click on the androidscreencast.jnlp file and select Open With > Java Web Start.

8. Accept  the Security Warning
Yes, you have to take your very life in your hands and run a Java applet from an unknown publisher. Are you feeling lucky? (Or more importantly, have you backup up your machine lately?)

9. Run MyGlass app on Android phone and start screencast

And there you have it. Now where is my cocktail?

A "But" Too Far: Gearing Up to Become a Google Glass Explorer

Good news! I got an invite to join the Google Glass Explorers program.

But I have to pay $1,500 for the privilege. And I have to fly to New York to pick them up and get fitted at Google's Chelsea Market office. And to get full functionality, I need to tether my Glass with an Android phone.

This is already turning out to be a rather expensive endeavor, but I'm still excited and ready to give life on the bleeding edge a try. And I'm planning to blog about my Glass experiences regularly, so watch this space. (And I plan on writing off all Glass related expenses on next year's taxes anyway.)

Me being me, I agonized / thrashed all weekend about the best solution for tethering my Glass. There are three major options:

1. Use my current iPhone 4 (which I'm still quite happy with, and am invested in Apple ecosystem)
2. Upgrade to an Android phone (I loose Messages and all my apps, and get locked in to new 2 year contract)
3. Get a separate Android phone (best of both worlds, but also most expensive)

In the case of the first two options, I'll need to upgrade my AT&T account from the unlimited data plan to the DataPro 5Gb plan that supports tethering. That's an extra $20 bucks a month (for up 5Gb of data...which shouldn't be a problem for me).

But I'm too comfortable and happy with my iPhone to just walk away from iOS at this time (especially with the new goodies coming in iOS7), and I rely heavily on Messages to communicate with family members. But just to be open minded, I did a little analysis and came up with the following arguments / gross generalizations in favor of each platform:

Android

• Customizable - turn ringer back on after 3 hours, use volume rocker for paging, etc.
• Google Now - sounds creepy to some, but I'm intrigued
• Better information sharing between apps
• Multiple user accounts - I can safely hand off my device to the Geeklings in a pinch

iOS

• Battery life - not a huge deal, since I generally plug in my phone every night anyway
• Messenger - synched up between iPhone, iPad, and MacBook Pro
• Camera - Apple continues to outpace the competition here, but I'm no Ansel Adams
• Stability of platform / availability of updates
• Less malware / viruses - a big benefit of the "walled garden"
• More / better apps - although most successful apps come to Android
• Existing investment in ecosystem - our household has definitely drunk the Apple Kool-Aid
• No bloatware / crapware - can be avoided by going with a Nexus device

So I decided to go with option three - a new Android phone..."in for a penny, in for a pound". 

But we're not through yet.

I wanted to avoid carrier and manufacturer bloatware, so was leaning toward a Google Nexus phone. This will get me the latest and greatest Android bits directly from Google as they are released. But the current Nexus 4 -- while it has gotten great reviews -- is almost a year old, and doesn't have all the bells and whistles of the current crop of Android phone champs like the Samsung Galaxy S4 and the HTC One. Google announced the Google Play versions of both the S4 and One at their recent I/O conference, which gets you the hardware with stock Android. But not only am I balking at the price tag ($600 and $650 respectively) for a device that I'm only planning to use for development, they won't start shipping until July 9th.

We have reached our "but" too far.

And since my Glass pickup appointment is for this Saturday, July 6th my decision was finally made. My new Nexus 4 is due to arrive in a couple of days, and I'll post my initial thoughts here soon.

Stopwords to Live By

I'm doing some work with SQL Full-Text Search, and I'd forgotten how to display the list of "stopwords" that are currently being ignored when performing a search.

Below is a simple query to get the list of English stopwords on your database. Mine currently includes 154 items, including individual numbers and letters.

What's in your stopwords list?

 SELECT ssw.stopword, slg.name   
 FROM sys.fulltext_system_stopwords AS ssw  
   JOIN sys.fulltext_languages AS slg ON slg.lcid = ssw.language_id  
 WHERE name = 'English'  

RESTful Web.API Services Are So Primitive, Man!

A couple quick and dirty tips from the trenches on how to validate primitive types that map to enums of collections (specifically a list). This has come in handy as I develop a new RESTful Web.API .

First up, Enum.TryParse is now supported by the .NET Framework 4.5. So we can now easily validate a  string to make sure it correctly maps to an existing enum value.

 MyEnum matchingEnumValue;  
 if (!Enum.TryParse(enumValueAsString, true, out matchingEnumValue))  
   throw new ArgumentException(enumValueAsString + " is not a valid enum value.");  

Next up, we want to pass in a delimited string of integer values (e.g. "1|2|3"), and parse that into a collection.

 List<int> integerInList;  
 try  
 {  
   integerInList = integersInString.Split('|').Select(int.Parse).ToList();  
 }  
 catch (Exception ex)  
 {  
   throw new ArgumentException("Could not parse list of integers. " + ex.Message);  
 }  
 if (integerInList == null || integerInList.Count == 0)  
   throw new ArgumentException("Integer list is empty.");  

Easy as bullseye'ing womp rats in my T-16 back home. Share & Enjoy!