Reid Carlberg

Connected Devices, & Other Adventures

About Reid Carlberg

40 Wearables in 400 Years (or iWatch, smiWatch)


Whether we finally see an iWatch tomorrow or not, all of this frenzy around wearables made me curious what the timeline on the architectural approach looks like. So I did a little research and came up with the following table.  This is incomplete for sure, but I found a few things that surprised and entertained me, so here it is for your enjoyment.  Comments, additions, criticisms all welcome on @ReidCarlberg.


Format: Earliest Date Seen or Announced – Name (Category) – Link for More Information

  • 09/09/2014 – Apple iWatch Maybe (Unknown) –
  • 09/07/2014 – Intel / Fossil Smartwatch (UI) – Gizmodo
  • 09/05/2014 – Moto 360 – Watch, Pulse, Steps (UI) –
  • 09/05/2014 – Daqri Smart Helmet (UI) –
  • 09/02/2014 – Samsung Galaxy VR (VR) – Samsung
  • 09/01/2014 – Garmin VivoSmart – Fitness & Notifications (UI) – $170 – Garmin
  • 07/15/2014 – Moov (Performance) – $80 – Moov
  • 07/08/2014 – Pebble Steel Smart Watch (UI) – $230 – Pebble
  • 05/24/2014 – Interaxon Muse Headband (Biometrics ) – Venture Beat
  • 05/08/2014 – Samsung Galaxy Gear 2 Smartwatch (UI) – Samsung
  • 03/31/2014 – Bragi Dash Hearables (UI) – Kickstarter
  • 02/25/2014 – Meta Glasses (UI) –
  • 01/06/2014 – Garmin Vivofit (Fitness) – $130 – Garmin
  • 12/15/2013 – Misfit Shine (Fitness) – $100 – Misfit
  • 12/07/2013 – Jawbone Up 24 (Fitness) – $120 – Jawbone
  • 12/01/2013 – Thalmic Labs Myo (UI) – $150 – Thalmic Labs
  • 10/16/2013 – Samsung Galaxy Gear Smartwatch (UI) – Samsung
  • 10/10/2013 – Fitbit Force (Fitness) – Wikipedia
  • 09/15/2013 – Emotiv INSIGHT (Biometrics ) – Kickstarter
  • 07/25/2013 – Vuzix M100 (UI) – Vuzix
  • 06/01/2013 – Google Glass (UI) – $1500 – #ifIhadglass
  • 05/09/2013 – Epson Moverio (UI) – Epson
  • 05/07/2013 – BioNym Nymi (Biometrics ) – $80 – GetNymi
  • 05/01/2013 – Fitbit Flex (Fitness) – Wikipedia
  • 11/26/2012 – Jawbone Up (Fitness) – $129 – Amazon
  • 09/17/2012 – Fitbit One (Fitness) – Wikipedia
  • 09/17/2012 – Fitbit Zip (Fitness) – Wikipedia
  • 08/03/2012 – GigaBryte (TinkerTags) (Education) –
  • 08/01/2012 – Oculus Rift VR (VR) – OculusRiftVR
  • 07/21/2012 – Emotiv EPOCH (Biometrics ) – Emotive
  • 04/11/2012 – Pebble Watch (Fitness) – $150 – Kickstarter
  • 01/19/2012 – Nike FuelBand (Fitness) – Nike
  • 10/03/2011 – Fitbit Ultra (Fitness) – Wikipedia
  • 09/09/2008 – Fitbit Classic (Fitness) – Wikipedia
  • 01/01/2003 – Garmin Forerunner (Fitness) – Garmin
  • 01/01/2003 – Fossil Wrist PDA (PDA) – $250 – Wikipedia
  • 01/01/1999 – FitSense (Fitness) –
  • 01/01/1983 – Casio Databank CD-40 (PDA) – Wikipedia
  • 01/01/1982 – Pulsar Calculator / Data Watch (PDA) – Wikipedia
  • 01/01/1600 – Abacus On a Ring (Math) – Wikipedia

Note: when a month or date wasn’t readily available, I simply assumed the first of the month or the first of the year.

Thanks Etherios for the great picture of our Dan Harrison.

Minor Adventures in 3D Design & 3D Printing: Traxxas Stampede 25C Battery Box


You might remember that I have a Traxxas Stampede VXL 4×4 RC truck.  (Then again, you might not.) It’s a pretty fun toy I bought a couple of years ago, and the other day I decided on impulse that it was time for a more powerful battery.  I was a little too impulsive as it turns out.  The additional batteries I bought were WAY to big.  Like ~17mm longer than the battery space.  Rather than do the smart thing — return them for the right size — I decided to take this as a challenge: could I 3D print an adapter that would let me use these too large batteries in my truck?


Well, it turns out the answer is mostly yes, but getting from never having done an original 3D design to the point where something worked was a interesting process, which is why I’m blogging about it.

I decided I would use Tinkercad.  It’s an easy online CAD program that lets you do some pretty sophisticated designs.  You start off with a blank slate, add shapes and letters which you can then resize and move around in 3D space, and then you can download it.  It turns out your can download for 3D printing or for Minecraft, and this Minecraft capability has created a whole new series of questions for my son and I to answer at a later date.

Since I was new to the software and to 3D design, I decided to start by answering a very simple question: could I build an adapter that would fit over the too large battery and stock battery holder at the same time.  I used the published measurements, and built the simplest thing I thought might possibly work:


Which when wrapped around a battery and connected to the stock battery holder looks like this:


So on the plus side it fit around the battery and my idea of connecting the battery holder through a narrow slot worked as I suspected.  On the downside, the battery still slid around, so this wouldn’t work for a car in motion.

Attempt 2 was really just a longer version of this sleeve, but with a solid end.  This also worked, since it’s basically just a stretched out version of Attempt 1, but in the end the battery would still slide around.

Pasted_Image_8_25_14_9_03_AMI started from scratch for Attempt 3 and did two designs, one for each end of the battery box.  I reused the public measurements, and then created a 5mm overlap designed to close the box up.  The walls are 3mm thick, so one side of the overlap was 2mm and the other was 1mm. A couple of things I learned here. First, apparently I made a math mistake when I created Attempt 1, because the published depth of this battery — 25mm — isn’t quite right.  It’s more like 27.5mm.  So my battery didn’t fit in the new box. Second, in order for the stock battery holder to work, I needed to leave more space to account for the larger battery’s need to hang over the place where the battery holder clips in to the truck body. Third, the 2mm + 1mm registration on the 5mm overlap was too tight for a 3d printed box.  It took quite a bit of force to get the two pieces together.  Finally, I need to be more careful about printing straight lines that span 45mm and start 20mm in the air.  The printer did remarkably well, but that’s not a recipe for success.


Attempt 4 addressed all of these issues and I’m pleased to say it worked fairly well.  The lipo battery pushed the truck into high gear and my in-the-dark truck vs. fire hydrant accident wasn’t fatal (although that’s probably not because of the battery box).  The 3D model for the back half of the box now looks like this:



This version also wasn’t perfect, for example the sides of the battery holder sleeve cracked at some point. I’m guessing that the strain of a relatively heavy battery on top and crashing at speed was a bit too much. My next iteration will have two main design changes. First, the battery holder sleeve will need to be on both sides of the box. This will help to keep it together. Second, the 5mm overlap will be changed to 1.5mm and 1mm to eliminate some of the slack where the box comes together.


Overall, I’d call my first 3D Design Experiment a success.  The design process doesn’t take that long, and printing it out gave me a huge amount of feedback very quickly.  Once I’ve had a chance to do these, I’ll share the designs.  As a side note, the adapter does raise the center of gravity for the truck, which means my already dangerous driving is now even more subject to flips, but that’s a subject for another post.


Dreamforce: My Own Personal History


I’m in the thick of Dreamforce prep.  This will be my 8th Dreamforce, and I find myself reflecting on what it’s meant to me over the years.

2007 — The band was INXS, and I was a brand new Salesforce consultant.  The company I was with at the time — Model Metrics — won an “Appy” award for something we did.  Pictures from that time show me wearing — gasp — a suit.  My first time at Dreamforce spoiled me for other conferences.  Even then, Dreamforce was a very happy place.  Everyone was high energy, the partners were awesome and I felt like I was part of something much bigger than me.  By the end, I was completely exhausted, and when someone stuck a camera in my face and asked, What was your favorite part of Dreamforce? I said, “The cheese plates.”  Really.  Hint: you should probably have a better answer.  For example, I should have said, “Talking to all the Salesforce customers who came by our booth.”  I love love love staffing a booth.  Call me crazy, but it’s true.

Dreamforce 2007

2008 — I don’t remember the band, but thankfully @eliz_beth does — it was The Foo Fighters.  I don’t think I went, and I regret this.  This Dreamforce stands out for me because it was the first one I spoke at.  I co-presented at a session on Salesforce and GCal integration.  Yes, I was wearing a suit.  Now, this was also the first year Salesforce offered the Certified Developer credential and I was very excited to be part of the first 500 group.  If you attended the Model Metrics party at Foley’s that year, you probably also remember the dueling pianos in the basement.  It was hot and crowded and a great time.  The great thing for me about 2008 was getting to know people in the community better.  Where DF07 was brand new, DF08 was more like a homecoming.

2009 — This was a big year for me.  I had written and iterated on an app called Cloud Converter and had completed a big project working with the Salesforce partner team, and I was speaking about both.  I had a great time preparing for these presentations, and got great feedback.  After one of the, a friend came to me and said, “You were born to speak like this.” I was very humbled and surprised to hear that. Public speaking is something I’ve always wanted to be good at, but I hadn’t found many opportunities to exercise that muscle. Also in 2009, Jeff Grosse, Miriam Melo and I started “The Octies,” the only canned-seafood themed community recognition award in enterprise software (still!).  Yes, the prize was a can of Octopus.  Incidentally, I was still wearing a suit.

2010 — This was my first year at Dreamforce as a Salesforce employee, and attending Dreamforce as a Salesforce employee is a little like being part of a giant wedding.  There’s always 100 more things to do, but Dreamforce is going to happen as advertised no matter what, ready or not.  So you work and you plan and you hope and you rehearse, and then you do all of that some more.  When I showed up in San Francisco, I remember very clearly thinking to myself, “WOW all of the work has totally been worth it.” My focus in 2010 was Salesforce1 Labs — or Labs as we called it at the time — as well as many of the “Introduction to X” sessions.  Introduction to Data Modeling.  Introduction to Visualforce. Introduction to Apex.  Intro sessions are always my favorite because you can see the lightbulbs going off over the heads of the people in the front rows. It’s very rewarding. Also, this time I was wearing regulation long sleeve t-shirts, which I still occasionally wear today.

2011 — My second year as a Salesforce employee, I was privileged to lead The Open Source Garage. Leading any section at Dreamforce is a challenge, the Open Source Garage was no exception.  I helped recruit partners, organize sessions and conversations, and I spent a good deal of time in the garage learning a lot right along with the rest of the attendees.  I also caught a cold.  Let me tell you what, the one thing you don’t want at Dreamforce is a cold.  I was definitely not at my best when the event started. Fortunately, if memory serves me correctly, I had at least one session with the inimitable Jeff Douglas on a panel, and that’s always a good thing. By the last day, I was feeling a bit better, but was a little anxious about my final session.  It was the last possible spot, late in the day Thursday, which no speaker I’ve ever talked to has been excited about.  It was on open source in the Salesforce community and it was packed. The audience was just as engaged on Day 4 as they had been on Day 1. I loved it.

2012 — Most of my time during 2012 was spent working with developers who wanted to launch businesses on the AppExchange.  I focused on something called AppExchange Checkout and my Dreamforce was all about the different ways partners could sell apps.  It was very interesting for me to work with so many of our great partners.  Up until 2012, my AppExchange experience was limited to free apps, and “free” is a very interesting question when you’re dealing with enterprise software.  Consumers pretty much demand free to start.  Enterprises are much more interested in the total value proposition. In fact, “free” can turn out to be very expensive, so finding the right balance is challenging. It was a huge learning opportunity for me. I should point out that the 2012 concert was my favorite of all time: the Red Hot Chili Peppers at the Civic Center.  It was crazy cool, and they put on a fantastic show.


2013 — Last year was a breakthrough experience for me because it was the debut of the Connected Device Lab.  I was originally nominated to lead the lab based on some work I had done in 2011 connecting my model trains to Salesforce and there’s no way I could have pulled it off without my experience running The Open Source Garage. Now, I wasn’t sure how the Lab was going to be received–nobody was.  No one had really done anything like it before. I arrived at Moscone on Saturday and started the setup process. While I was working, many of the tradespeople building the DevZone stopped by to watch and ask questions. On Sunday, the same thing happened with Salesforce employees. And I started thinking, Uh oh.  Monday, all hell broke loose and I have to say I loved absolutely every minute of it, including losing my voice. This tweet and the response chain summarizes the whole thing for me.  The experience was breakthrough for a few reasons. First and foremost was the response of our attendees. People were curious, engaged, and asked great questions. Second, it sparked fantastic conversations with a lot of people I really respect: Parker Harris, Peter Coffee, Charlie Isaacs at Salesforce and many, many other customers and partners. Lastly, it kicked off a great year of really interesting activity — ThingMonk, ThingsExpo, IoT World, M2M Evolution in both Miami and Las Vegas, #IoT Chicago and several really rewarding customer specific engagements. 10 out of 10 — would work hard for months, talk for 14 hours straight 4 days in a row and lose my voice for two solid weeks all over again.

So that’s my personal Dreamforce history.  Dreamforce is unlike any other event I’ve ever been to, and I love every minute of it, before, during and after.  It’s a time to connect with old friends, a place where I get to share what I’ve been working on and a unique opportunity to meet customers and learn about their needs.  DF14 is shaping up to be great in a whole new way.  See you there.


AngularJS & Remote Actions: The Simplest Possible Visualforce Page


The other day, spurred on by Mr. Ward’s Building Salesforce1 Mobile Apps with Visualforce, AngularJS, and Bootstrap, I became curious about whether or not I could mix Remote Actions in with his code, and it turns out I can.  And more than that — it turns out to be pretty sweet!

I’ve included a video demo at the bottom of the post and you can install these pages into your developer edition from this unmanaged package.  Note that once you install these into your org, you’ll want to add them to your Mobile Navigation in order to see the Salesforce1 #awesomesauce.  Code is also on github.

The foundations of Remote Actions are simple.  You create an Apex class that performs the operation you want, and then use a @RemoteAction annotation to expose a particular method to the JavaScript Remoting framework.

global class SampleRemoteActionPageController {
    global static List myContacts() {
        return [select id, name, email from Contact Order By LastModifiedDate DESC LIMIT 200];

You then create a simple page that calls that remote action.

<apex:page controller="SampleRemoteActionPageController" docType="html-5.0">
 <apex:stylesheet value="//"/>
 <apex:includeScript value="//"/>
 var app = angular.module("ngApp", []); 
 app.controller("ContactCtrl", ["$scope", function($scope) {
   $scope.contacts = [];
   $scope.getContacts = function() {
     function(result, event) {
       $scope.contacts = result;
 <div class="bootstrap" ng-app="ngApp" ng-controller="ContactCtrl" >
 <h1 align="center">Click The Button</h1>
 <button ng-click="getContacts()" class="btn btn-lg btn-default btn-block">Get Contacts</button> 
 <li id="{{current.Id}}" ng-repeat="current in contacts" ng-class-even="'rowEven'">{{current.Name}}</li>

I love the simplicity and flexibility I’m seeing here.

Just for fun, I also created a demo using the new Remote Objects functionality that’s still in developer preview.  It also works well in both the desktop browser and Salesforce1 mobile app.  Checkout the video below!


Chicago Elevate: Here Are the Links I Promised


I had a great day working with new Salesforce1 Platform developers yesterday in my home town. It was definitely a super smart crew and I really enjoyed the event.

Here are the links I mentioned:

Extra Credits

littleBits cloudBit Module Review & Salesforce1 Platform Example


littleBits makes it easy for people to experiment and play with a variety of DIY electrical components. It’s fun and easy, and yesterday they made it even better by introducing the littleBits cloudBit.

The cloudBit is a unique and powerful way anyone can create fun Internet of Things style solutions for whatever is important to them.  Today, I’m going to create a fun alert that fires when new Leads are added to Salesforce.

Let’s take a look at the bit itself.  It has the same basic architecture as other bits — magnetic connectors on both sides with a direction indicator — and then a USB wifi connector on the front and a 4GB micro SD card on the back containing Linux.

Yes, that’s right, Linux. In fact, as the description notes, “The cloudBit is a single board computer running Linux.”  Later they also note, “We’ve left pads on the bottom of the board so that you can connect to the cloudBit’s serial console using 3.3V UART (8-N-1, 115,200 baud) and poke around.”  OK, that’s now on my //TODO list.






Configuring the WiFi is pretty easy. When you first power on your cloudBit, it creates a new hotspot. You connect to that hotspot, and then configure it to connect to whatever your local setup is. This is a familiar pattern for a lot of new connected devices, so you’ll probably find it easy.  Once you’ve configured it, the basic operation is pretty simple, as I demonstrate in the video below.

Ok those are the basics. So, you might be asking, what can you do with it?

Quite a bit as it turns out.  I like to create fun things in Salesforce, so I decided to create a real world alert that tells me when a new Lead is added to the system.  I did this using a cloudBit, Twilio and LEGO. Check out this video for a demo and an explanation.

There you have it.  There’s really no meaningful code required, it’s mostly done with a few clicks.  If you’d like to try it yourself, you can get a littleBits cloudBit for $59 and try out the Twilio Salesforce integration for free.



Tessel Review & Salesforce REST API Example (with a smidge of OAuth2)


Update November 20, 2014: Mild update to code — moved the https include to the top in order to eliminate a non-responsive camera module.

TL;DR – I wrote a script on my new Tessel that posts images to Salesforce Chatter and learned a lot along the way. You can find the full Tessel Image Capture script over on Github and you can ask me about it on Twitter @ReidCarlberg. The screen cap above is an automatically captured picture of a 3D printed T-Rex Skull on Salesforce1.

Hello Tessel

The Tessel is a brand new hardware prototyping board that lets you code in Javascript rather than C. I first ran into it during their crowd funding campaign last year, and received my first unit last week. Since then I’ve had a chance to create my first simple app on the device, so today I’m going to share what I’ve learned so far. Tessel Review, Camera, ClimateTessel Review

If you’re already used to working with hardware prototyping boards, there’s a lot you’re going to like. There are plenty of analog, digital, I2C, SPI and serial ports to go around. You can use these ports to connect any old hardware you already know how to connect, or you can use one of their preconfigured modules. Pretty easy.

One thing that confused me since I first spied the prototype is the positioning of the interface ports. They’re bent at 90 degrees and so rather than facing up, they face out. (Note: in the picture above you can see that my C port is at a weird angle. Bent it somehow.) This design helps a board with a number of modules attached stay flat, which is particularly useful with something like the servo module where you’re going to connect a number of wires in. The GPIO port faces up as you would expect.

Basic interaction is super simple. You access all of the ports via standard Javascript syntax. For example, the blink app (“Hello World”, but for hardware), is just a few lines:

// Import the interface to Tessel hardware
var tessel = require('tessel');

// Set the led pins as outputs with initial states
// Truthy initial state sets the pin high
// Falsy sets it low.
var led1 = tessel.led[1].output(1);
var led2 = tessel.led[1].output(0);

setInterval(function () {
    console.log("I'm blinking! (Press CTRL + C to stop)");
    // Toggle the led states
}, 100);

You can run scripts from the CLI using the command “tessel run myScript.js”.  Here’s what running the blink.js example looks like.

$ tessel run blink.js
TESSEL! Connected to TM-00-04-f000da30-006a473e-34b02586.
WARN No package.json or node_modules found. Deploying just this file.
INFO Bundling directory /Users/reid.carlberg/Projects/tessel-blink (~428 bytes)
INFO Deploying bundle (4.50 KB)...
INFO Running script...
I'm blinking! (Press CTRL + C to stop)
I'm blinking! (Press CTRL + C to stop)

And if you want the script to run headless, you simply use “tessel push myScript.js” and you’re good to go.  The script will start automatically as soon as it has power.

The modules are pretty easy to use, and they all come with node libraries and sample code. When you want to use a module, you simply insert it into one of the ports, grab the library via NPM and get to work. Installing the camera module, for example, is as simple as typing “npm install camera-vc0706”. T-Rex-Salesforce1 My Tessel Sample App

My sample use case is pretty simple: when something is close enough to the Tessel, snap a picture and upload it to Salesforce. In this example, I connected my own proximity detector and used Tessel camera and climate modules. tessel-camera-2 The first thing I wanted to do was connect to the Salesforce platform the way I usually do, with the excellent nforce library. Now, I’ve used it quite a bit, and have watched the npm install routine probably 100 times without really wondering about all of the components it requires. However, I couldn’t take that same laissez faire attitude when working on the Tessel. Although it is designed to be Node.js compatible, it’s still a limited device and larger, complex modules like nforce are too much for it to handle. This is not that big of a deal. In fact, it was a great excuse for me to get more familiar with some Node.js basics I’d managed to ignore until now, such as the HTTPS request object. Incidentally, before rolling my own OAuth2 and REST interactions, I also attempted to use the excellent request and restler libraries.  No luck!

The good news here is that rolling your own autonomous client / username & password flow OAuth2 is pretty easy. Setup your connected app in Salesforce (example), send a few parameters to the endpoint and voila! you have an authorization token.

function handleOauth() {
  var body = 'grant_type=password&client_id='+clientid+'&client_secret='+clientsecret+
  var options = buildRequestOptions('/services/oauth2/token', body, 'application/x-www-form-urlencoded');
  options.hostname = '';
  handleHttpsRequest(options, body, handleOauthCallback);

You can see I’ve built a few small routines to make this easier, but the main job is done in four lines of code. Add a callback to interpret the results, and I’m off.

Sending an Image to Chatter

The next step is capturing an image and sending it to Chatter. The good people at Tessel have made taking the picture extremely easy. The basic code looks something like:

var camera = require('camera-vc0706').use(tessel.port['A'], { resolution: 'qvga' }); 
camera.takePicture(function(err, image) {
if (err) {
   log('error taking image', err);
} else {
   //do something with the image
   base64content = image.toString('base64');

On the Chatter side of the fence, if you can send an octet-stream directly to the Chatter API, you can use a single call and post a message and the picture at the same time.  In theory, the image buffer should work in here, but I couldn’t get it to work on either the Tessel or my MBP.  I ended up taking a note from @Metadaddy and an example from @CCoenraets, and did a 3 step process after base64 encoding the buffer object. Step 1, insert a ContentVersion object. Step 2, lookup the ContentVersion and get the ContentDocumentId. Step 3, insert a FeedItem that references the ContentDocumentId.  The final Chatter code looks like this:

  var body =  {
      attachment: {
          attachmentType: "ExistingContent",
          contentDocumentId: contentVersion.ContentDocumentId
      body: {
          messageSegments: [{
                type: 'Text',
                text: 'Here is a current picture. \nClimate: '  + currentClimateText
  body = JSON.stringify(body);
  var chatterOptions = buildRequestOptions('/services/data/v30.0/chatter/feeds/record/me/feed-items', body, 'application/json');
  handleHttpsRequest(chatterOptions, body, handleChatterCallback);  

The other option for inserting the picture is to create a custom ApexREST web service. This is a good option if you want to minimize API calls, but it adds the extra complexity of creating that bit of Apex. Fortunately, that bit of Apex is easy to create.  In fact, I had created something similar for the Share Wonder project I did a while back.  Share Wonder, however, inserted the data into an Attachment object rather than a ContentVersion object. Before I wrote the ContentVersion code myself, I search a bit and it turns out that Maxim Fesenko over at Cloud Catamaran had written a blog called File Upload to Chatter Using the ConnectAPI just a few days ago.

My slightly modified version of the code from that blog post looks like this:

 * Totally copied from 

global class PostHelper{
    global static ConnectApi.FeedItem post(String text, String imageName, String imageBase64) {
        ConnectApi.MessageBodyInput v_messageInput = new ConnectApi.MessageBodyInput();
        v_messageInput.messageSegments = new List();
        ConnectApi.TextSegmentInput v_textSegment = new ConnectApi.TextSegmentInput();
        v_textSegment.text = text;
        ConnectApi.FeedItemInput v_input = new ConnectApi.FeedItemInput();
        v_input.body = v_messageInput;

        ConnectApi.NewFileAttachmentInput v_fileIn = new ConnectApi.NewFileAttachmentInput();
        v_fileIn.title = 'title of file';
        v_fileIn.description = 'description of file';
        v_input.attachment = v_fileIn;
        ConnectApi.BinaryInput v_feedBinary = new ConnectApi.BinaryInput(EncodingUtil.base64Decode(imageBase64), 'image/jpg', imageName);
        System.debug('***Just about to insert');
        ConnectApi.FeedItem v_feedItem = ConnectApi.ChatterFeeds.postFeedItem(null, ConnectApi.FeedType.Record, 'me', v_input, v_feedBinary);
        return v_feedItem;

And if you’d like to install it in your org, here’s an unmanaged package which yes of course includes full test coverage.

Tessel Lessons Learned

I learned a lot going through this sample app.  Some of my key takeaways.

* Base64 encoding takes quite a while. A qqvga image (160 x 120) encodes in about 20 seconds. A larger qvga (320 x 240) takes about 2 minutes. A vga image (640 x 480) takes more like 20 minutes.

* System intensive actions like base64 encoding will block other actions you have setup on an interval.  Once the encoding is done, all of the blocked actions will fire.

* Yes, the Tessel uses Javascript, but it’s still a constrained device. You should expect complex, memory intensive operations to be tricky. Every platform has constraints. The Arduino, for example, doesn’t handle JSON parsing well. Just because you can use Javascript on the Tessel, you shouldn’t assume you can use Javascript exactly as you might on more powerful platforms.

* The wifi is a bit tricky. Setup is dead easy — “tessel wifi -n MyNetwork -p MyPassword” — but the Tessel doesn’t have a huge antenna, and reception isn’t the greatest. I found areas of my house that work great for a larger device but not for the Tessel. They actually have a tutorial on how to add an antenna.

Finally, I would like to point out that the crew over at Technical Humans have been super responsive and helpful.

In the End…

In the end, I think the Tessel is a super interesting iteration on the hardware prototyping platform. Coding hardware using Javascript – even if it’s a little different than other places you use Javascript –  is very interesting. I hope a lot of people buy one of these boards, because I definitely want to see what the future holds for this extremely interesting team.

Internet of Things: Six Requirements for Your First Project


The Internet of Things, the Internet of Everything, the Industrial Internet — whatever you call it, connected devices are a fantastic gift to any business that wants to get closer to their customers. The pattern captures people’s imaginations and many of the predictions feel like magic, but IoT solutions are hard to get right. If you’re trying to decide on your first project, you probably have a lot of questions. Here are six critical things to keep in mind as you move forward.

#1 Pick a Great Use Case

There are a lot of fun IoT use cases around the Internet. Many of them don’t matter. In the interest of keeping good relations with the rest of the world, I’m going to call out something I did as a fantastic example of a trivial exercise: the Coffee Copter, detailed in the video below. As you pour a cup of coffee, a quadcopter takes off. As you empty the cup, the quadcopter lands.

Now, as fun as that was, it was an execise in can you do something, and these days can is the wrong question. You need to be asking yourself should questions. Should I connect a coffee urn and a quadcopter? No.

But there are lot of areas where the answer is yes.

Should you make healthcare equipment more reliable? Should you make it easier to monitor radiation in a nuclear accident zone? Should you help people save money on energy by helping them monitor and manage their use?

The answer to all of these is a clear yes.

One of my favorite examples in this department is New England BioLabs. NEB sells supplies to medical researchers. As part of their sales process, they stock these supplies in a freezer at their customer’s location. Now, it used to be that they had a hard time knowing the right supplies to stock, validating that supplies were kept at the right temperature, and tracking the researchers that used a specific item. NEB solved this by transforming their freezers into connected devices and now they know the researchers, they know the supplies and they know the temperature history for each item.

I’m sure we can all agree that medical research is a worthy cause. But not everyone is a healthcare researcher, so you have to find a similar problem in your business. You need to start by identifying the target outcomes your customers are looking for, and then come up with ways to help them achieve those outcomes more reliably. When you do this, you deliver additional value and build better relationships.

These outcome oriented use cases are what matter, and you should start with them.

#2 Create a Great User Experience

Once you decide on the right use case, you have to create a user experience that delights your customers.

Internet of things demands great User Experience

(source & thanks @RossBelmont).

User experience, UX, determines how people engage with your solution, and there’s no one UX for every product. Your UX goal should be two fold. First, if possible, your new solution should fit into what customers already know how to do. Second, it should reduce the friction of what they have to do to realize the value it delivers. Great UX not only disappears into the environment, it makes the environment better.


The current generation of fitness wearables is interesting example of good UX. Fitbit, for example, has no buttons. All you have to do is put it on and the technology does everything else in the background. Now, on the down side, the user also has to tap the device from time to time. It’s easy to get the hang of, but I wouldn’t call it natural, and it still requires a local gateway rather than being able to magically talk directly to the cloud. There’s no great way around that right now, it’s a constraint that the technology hasn’t eliminated yet. But the first wearable that includes some sort of background connectivity will have a tremendous advantage.

#3 Community & Collaboration

I’m not talking about the network of connected toasters or refrigerators complaining to each other about being out of milk. I’m talking about actual people. People value interacting with other people in context of things they care about. In fact, they value it so much, if you don’t create a destination for the community that pops up around your product, your customers will probably create one on their own.

There are three main types of communities to be thinking about.

photo-8The first is a data-centric community. Runkeeper has created an excellent example of a data-centric community. Data-centric communities take the output of the device and interact around it. In Runkeeper’s case, this is a leader board comparing the number of activities between you and your friends (yes, that’s me at the bottom). Most fitness wearables have data-centric communities as a core part of the product.

The second type of community is product-centric. Product-centric communities are more about how to use things, news from the company, tips and tricks, etc. PrintrBot has an excellent product-centric community. Interestingly, it’s not operated by the company itself. Customers created their own informal community. Today the company has an official one as well, but the original continues to thrive.


The third type is transaction-centric. Say you manufacture MRI machines, and you connect those MRI machines to an enterprise backend like When the MRI machines have actionable data, that data gets posted to Chatter, and all of the people who have a legitimate interest in it can collaborate around that particular post. MRI techs, doctors, hospital staff, biomed technicians, and external contractors can create a short lived, ad hoc community around that transaction.  (The screenshot above is from this video, a couple of minutes in.)

#4 Developer Experience

Open Source has shown time and again that remix is often more valuable than the original. And although I won’t presume to say you should open source your core IP behind whatever connected solution you land on, I think its critical you have an easy to understand, well documented and powerful API that developers can harness.


A great example of a good out of the box Developer Experience (DX) is Automatic, the car tracking company. With Automatic, you pair an OBD-II device with your phone and track driving patterns. Automatic launched with an API out of the box, and they exposed their API using a number of standards. For example, it has a REST API and handles authentication via OAuth2. This definitely sets them up for developer success, and people are doing great things.  (Note that Automatic’s API is still in beta.  That’s fine.)

Like the community, the funny thing is that if you don’t deliver an API out of the box, chances are good someone else will attempt to. Take the example of Kickstarter success LiFX. It took a year for them create and ship bulbs to their backers, and they did so without an official API. However, an unofficial API showed up on Github in days. Now the challenge here is that an unofficial one is OK, but people don’t have a lot of confidence in it. Meanwhile the Philips Hue, their competitor, has had a reasonably good API for quite a while.

This all begs the question of Nest.  Nest doesn’t have a public API yet which probably makes you wonder if you really need one.  My opinion is that most of the time yes you will need one.  Nest has proven to be a successful exception.  There may be more exceptions, but I suspect not many.

#5 The Right Amount of Data

In order to succeed, your IoT solution needs to gather enough data to create accurate, actionable insights for your users. Is this Big Data? Yes, but your users don’t want and can’t handle big data. They want the processed results.

How do you handle big data if you don’t already understand it? The right thing to do is partner with a company who already has the expertise, of which there are an increasing number. Companies like Etherios, 2lementry and Axeda, just to name a few. Can you develop it yourself? Sure, but see the above discussion about can versus should.

Processed data is where the action is. A typical IoT value chain has a number of components, all of which are easy to get lost in, but processed data, that someone can act on, will drive the success or failure of your product. User experience plays a critical role here as well, although it’s a different set of users: internal users. If your use case involves helping customers achieve better outcomes from their purchase, and it should, then the processed data needs to sit very close to the customer data so people can take quick action on it.

Learning what data is valuable will take some trial and error, and the data that’s valuable today will be different that the data which matters tomorrow.  You need to figure this out for your customers.

#6 Non-Technical Integration

Connected devices open up new and interesting future possibilities, but they have to play well in the current world with all of it’s existing requirements. A good case in point is government regulation.

Brivo Labs is a great example of a company that understands the impact of regulatory requirements on IoT solutions. Brivo Labs is an access management company that’s a spin off of a well established commercial security access control company with a deep understanding of regional building codes. This kind of knowledge is absolutely key to working effectively with existing markets, and they’ve used this to create a number of interesting products, including an iBeacon enabled app that works with Salesforce Identity called Rändivoo.

Nest experienced an interesting result of regulatory requirements when they found a problem with their smoke detectors. They started to fix it and then received a demand for a recall from the Consumer Product Safety Commission – six weeks after their own disclosure and initial action. This kind of interaction can be very distracting for a business, especially when it’s not planned for, but the reality is that even the most leading edge companies are still subject to it.


Source. Note that as of this writing, Nest Protects were not available on the Nest website.  This letter from Nest CEO describes the situation.

Now is the Time to Jump In!

I hope this list is helpful.  The Internet of Things is an architectural style that will drive really interesting innovation in the coming years.  There’s a lot of detail around creating an IoT solution, but you shouldn’t let that stop you from jumping in. Now is a great time.  Companies are increasingly turning to connected customer experiences as a way of delivering what all customers really want: better outcomes.

If you’re looking for more ideas and inspiration, you should take a look at the ever growing list of artifacts created by some of the leading thinkers in the space.  I recommend the videos from ThingMonk, ThingsCon and SolidCon as a great place to start.

I’d love your feedback on this or any other article.

Code Coverage, 3D Printers vs. Quadcopters & Apex4Admins


The excellent Code Coverage podcast features me today.  I was really honored when Matt and Steven invited me and am really excited to hear who they’ve got lined up next.

During the show, Matt & Steven asked me to pick a favorite connected device hack.  I talked about the quadcopter hack, which I indeed loved. This episode was recorded a few weeks ago, when I hadn’t yet had the chance to control 3D printers with Salesforce1.  I would now say this is my favorite project, surpassing even the quadcopters.

The thing I hope people get out of this, especially people who are new to Salesforce1 and development in general, is how good of time this is to kickstart your career.  As I was listening to our conversation, I found myself reflecting on the amount of money I’ve spent on developer tooling over the years, and how valuable the free developer edition really is.  Literally anyone can get one, get started, and build an extremely lucrative career, for free.  It’s a matter of putting in the effort.

If you’re brand new and want to go down this path but don’t know where to start, you should check out the excellent Apex4Admins. They’ll get you started right.  I’ve included the first of three Apex4Admins episodes here because I think it’s so good.

Thanks again Matt & Steven.  Keep up the great work!


Internet of Things: 5 Easy Steps to Understanding Our I Dream of Jeannie Future


The Internet of Things — IoT for short — is the new black, but most people still can’t explain what it is or why the average person, developer or CEO should care.  Let me break it down in 5 easy to understand steps.

#1 Nobody Wants Your Product

I want to start off by setting the stage with a very simple fact: nobody wants your product. I don’t care if you make smart phones, cars, houses, bathroom scales, pens, pencils or chairs.  A priori no one wants your product.

This is confusing.  We often conflate the effects of marketing and advertising with inherent desire and generally that inherent desire just isn’t there.  Now, if your products are food staples, or maybe art, I’d open that up for discussion but once you get beyond those basics – once you get into the very specific realm of, for example, prepared sandwich cookies, desire isn’t natural, it’s manufactured.

#2 People Want Outcomes

People want outcomes.  Smart phones provide connectedness. Cars provide safe transit from point A to B. Houses help us feel safe.

Products and outcomes are different.  Sometimes it’s difficult to remember that they’re different while caught up in the day to day world of making things and selling them, but that’s why people buy products.

They want outcomes.

It’s always important to ask, what are people getting out of this product? Why are they buying it.  It’s the why that matters.

#3 Technology Enables Better Outcomes

I’ve been in technology most of my career.  The reason I like technology is simple: technology enables better outcomes.  The has been true for a long time, since long before we called it “technology” (a term that joined us in the 17th century) and long before there was a tech industry (coined in the 20th century).

Think about Gutenberg’s printing press (from the 15th century). Gutenberg’s printing press was the quad-copter drone of it’s day. It made “printing” a thing. Before Gutenberg, creating new books meant copying by hand.  For centuries, control of the printing presses conferred a huge amount of power.

Computing power is the same. It started with mainframes, went to PCs, then the Internet and now everyone carries a wildly connected supercomputer in their pocket that fundamentally creates better outcomes for them every day.

Importantly, these better outcomes still require a device, an intermediary, something that separates the user from the computing power.

#4 IoT Breaks Computing Power’s Fourth Wall

The fourth wall is a metaphor describing the relationship between the performers and the audience in a theater. The fourth wall keeps the actors on the stage, safely separated from the audience in their seats. Breaking the fourth wall, a concept that started in the 19th century, is all about engaging observers in the performance.

IoT, as a technical architecture, is fundamentally about eliminating computing power’s fourth wall. IoT embeds computing power among the diverse devices a user might rely on to improve outcomes and reduces the intentionality required for a user to engage it.

IoT is a great marketing term right now as well, which means it’s sometimes used out of context. That’s OK. Marketing terms, even those lacking precision, can be useful organizing principals that help people talk about similar ideas in a similar way.

#5 All Estimates of IoT’s Impact are Too Small

You’ve probably heard 75 billion devices and $14 trillion in revenue opportunities. These are huge numbers — mind boggling — which is great — but kind of insignificant when you switch your default mindset to assume every thing you come into contact with every day will soon have incredibly rich computing and communication capabilities.

Think a decade out, or two decades out, when the standards are agreed on and the technology stack is mature.  Suddenly, I Dream of Jeannie is the new normal.  But instead of Barbara Eden crossing her arms and nodding her head, it will be you, conducting the technology embedded everywhere around you, without thinking about it.

Sensors, robotics and technology we’re not even talking about yet will turn I Dream of Jeannie into brilliant speculative fiction instead of a quality sitcom.

IoT is the organizing metaphor that will help us get there.

…And We’re Just Getting Started

I hope this paints a clearer picture of IoT.  This architectural style is just getting started and people are thinking about it in many different ways.  It doesn’t matter that we don’t agree on all of it yet, or that we don’t have all of the technology worked out.  That will happen.

And it’s going to be a lot of fun!

%d bloggers like this: