Thursday, June 19, 2014

An Open Letter to Disney Imagineer Asa Kalama


Shay - Imagineering Videos
This is an open letter to Asa Kalama, a Disney Imagineer, host of a fabulous video series, and one of my son's personal heroes. (He's right up there with Bill Nye the Science Guy, Neil deGrasse Tyson, and Mythbusters.) We would love to get the chance to meet him in person, so I'm turning to the Inter-tubes to try to catch his ear.

If you happen to have Mr. Kalama in your LinkedIn or Facebook contacts, or know of some other circuitous way to contact him, please forward him this blog post. We would be very grateful.

Sincerely, 

The hopeful father of a future Disney Imagineer



Dear Mr. Kalama,

When we first told my 9 year old son Shay that we were taking a road trip to Disneyland this July, the first thing he asked was "Can we meet Asa?”

Not Mickey, not Buzz, not Mater.

Asa.

He then sat down and wrote you a letter (see below -- along with a "translation”) telling you how much he loves your The Science of Disney Imagineering videos, and how much he has learned from them. (In fact, they’re a hit with the whole family.) 

I suppose this reaction shouldn't have been such a surprise, because whenever Shay is asked “What do you want to be when you grow up?" he immediately replies “A Disney Imagineer!” This started when he first saw your videos at the age of 6, and he is now 9 years old...his answer has never wavered.

Shay is on the Autism Spectrum, and it would make this once-in-a-lifetime trip even better if we could take you to lunch, ask you lots of science questions, and maybe get some pictures and an autograph.

Thanks for making science fun and engaging, and for inspiring my son. We wish you every success!



Dear Asa Kalama,

I want to be an Imagineer of Disney Parks because I saw you on the Science of Disney Imagineering about gravity, electricity, energy, and more.

See you at Disneyland!

Love your friend and Imagineer Wanna Be, Shay

P.S. Dream it, do it.

Tuesday, April 15, 2014

HeartBleed - The Least You Need To Know

I've gotten several questions about the HeartBleed bug, so here's the least you need to know:
  1. This is a serious security breach.
  2. It is unlikely that your personal information will actually be exploited.
  3. You should change all your passwords over the next week or so.


If you're still reading, here are a few more details:
  1. While this security breach is serious (it affect 2/3 of all servers on the internet), it appears to not be as bad as initially thought. (Bruce Schneier, a leading security expert,  called it an “11 out of 10”, but has since dialed it back a bit.)
  2. The bug has been in the wild for over 2 years, but there is no evidence of exploitation. And any hacker that utilized it would end up getting somewhat random data that may or may not contain unencrypted passwords and other user information. So the likelihood of your personal information getting both exposed AND exploited are fairly small.
  3. This is a perfect excuse to switch over to a password keeper (I use LastPass), and use that to generate new strong, random passwords for all the web sites you use the next time you visit them. LastPass is great, because it will synch up across devices - you only need to create and remember one strong master password.

If you're STILL reading  and want to learn more, here are some helpful links to learn more about HeartBleed (ranging from basic to highly technical):


And here are some of the leading password keepers services / apps:


Finally, if you any of the major ecosystems, you should really consider turning on 2 factor verification:
I hope you found this information helpful - please leave a comment if you have further questions. Share & Enjoy!



Friday, January 10, 2014

Learning How to Code by Not Coding

I recently had the delightful opportunity to lead my daughter's 6th grade STEM class through a Technovation "Hack Day". This was not an advanced / accelerated / honors class...just an assorted group 24 sixth graders, ages 11-12 from the western suburbs of Minneapolis.

And all girls.

We spent the entire school day (9am - 4pm) developing apps with AppInventor (more on that below), and it was a rousing success. The kids stayed focussed, on task, engaged, and excited about coding. They went from knowing nothing about the platform (not even having a user account) to having apps on their (emulated) phones that displayed images and playing sounds downloaded from the web, accepted input from the accelerometer, took pictures, and even spoke to them.

Now, there was no actual coding per se. There was very little in the way of actual typing: mostly dragging and dropping UI elements and programmatic "puzzle piece" code blocks. But there was also no frustration due to typos or syntax or compilation errors. They got a great introduction to object-oriented programming -- including such core concepts as objects, events, procedures, encapsulation, and separation of concerns.

AppInventor is an offspring of Scratch, developed by MIT to allow users to create programs without programming. Previous iterations of AppInventor were unstable and a bit buggy, but I found the new 2.0 version (released this month) to be stable, polished, and (mostly) user friendly.

The special sauce that makes AppInventor extra cool include the following:
  1. It's totally web based. Kids can start a project at school, finish at home, and present it at school the next day.
  2. It's totally free!
  3. You can run your apps right on your Android device via USB or wifi, or on your computer in the Android phone emulator (which was slow and a bit tweaky).
  4. It creates Android apps that you can share with friends that will run on any Android device - phone or tablet.
  5. You have access to a most of the device's hardware capabilities:
    • Camera (still and video)
    • Audio Player / Recorder
    • Speech Recognition / Text to Speech
    • Accelerometer / Orientation
    • Barcode Scanner
    • Location Awareness
    • NFC
    • Contacts
    • Communication via Phone, Email, Texting
    • Social Sharing with Twitter
    • Local and Cloud DB Storage
    • Bluetooth (Client and Server)
  6. It integrates with LEGO Mindstorms for cool robotic projects (although I haven't gotten to try this yet).
  7. Did I mention it's totally free?
While it's reported that any Android device can be used with AppInventor (e.g. Kindle Fire, Samsung Galaxy phones), you may end up having to either sideload your apps (not too hard) or root your device (if you're ambitious and don't mind voiding your warranty). I think you'll have the most success if you use a Google Nexus device, which will sport the "pure" Android experience with the latest updates and patches (and no extra software from the manufacturer or carrier which might cause problems). I have a Nexus 4 (that I purchased to use for my Google Glass R&D), and it has worked flawlessly. The Nexus 7 tablet is currently going for $229, and the Nexus 5 phone goes for $349 (both 16Gb) on the Google Play store.

So for a couple hundred bucks, you can be up and running with some great tools for rapid prototyping or experimenting on mobile apps. I recommend you check out AppInventor, and walk through the Hack Day curriculum with your Geekling.

NOTE: Being a bit of an Apple fanboy, I’m disappointed that there’s nothing similar (that I’m aware of) for the iPad and iOS. The closest thing I've found so far is an app called Codea that utilizes Lua script. Watch this space for a review of this app sometime soon.

Monday, September 16, 2013

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?



Monday, July 1, 2013

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.

Wednesday, February 20, 2013

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'  


Friday, February 8, 2013

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!