Reid Carlberg

Connected Devices, & Other Adventures

Me, Myself and Dreamforce ’14


Last year I attempted to chronicle Every Internet of Things Thing at Dreamforce 2013.  It took me one post (albeit a long one) and I think I caught every session.


This year, I ignored everything but my little portion — the DF14 DevZone Internet of Things area — and it still took me three pretty long posts and almost 3000 words.  What a difference a year makes!

So yes, 48 hands on IoT workshops.

28 great IoT partners (yes, we had one join since I wrote the post — Automatic).

12 picture worthy things you can checkout and probably — estimating here — 25 plastic shoe boxes of components you can build stuff with.

And a lot of demos.  Something new every single day of Dreamforce.

Devices, Wearables and Robots — my oh my.  See you there!

Safecast: my experience building bGeigie Nano #2333


At ThingMonk last year, I was very intrigued to hear about Safecast and their project mapping radiation levels in Japan and around the world in near real time. So, when this year’s Dreamforce DevZone Internet of Things area was coming together, I made a point to buy a kit for the zone so I could tell a bit about this truly inspirational story to our attendees.

First, I should point out that the bGeigie Nano is relatively easy to build. There are great instructions, and the design of the kit is targeted at amateurs and pretty well tested. If you haven’t done a DIY soldering kit in a while, let me assure you that very few are designed this well.

Step 1 was getting all of the small parts soldered to the main board. These are the resistors, the capacitors, switches, etc. Now I’m far from the world’s greatest solderer, and this board was the first thing I’ve soldered in a few months. However, it still came together just fine.


Next, the system comes with s number of component boards. These add functionality like GPS, data logging and a small screen. The most challenging thing here is holding the headers in place while you solder then to the back of the main board. Times like this, I generally use a little piece of paper, folded up to just the right height, to prop the headers up. Works like a charm!


Now it was time to test the unit, and this is where I ran into my first challenge. I plugged in the USB power cable, and ……….. nothing happened. Using my trusty multimeter, I verified the solder joints and power flow and it seemed like everything was right. I came to the mistaken conclusion that my unit shipped without firmware. So I ordered an FTDI cable to handle that. When the FTDI cable arrived, I plugged everything in and voila! It worked. However, I hadn’t pushed any firmware so I didn’t know why it worked.


The explanation turns out to be relatively simple. The USB connector is designed to charge the battery not operate the board. The system turns on when the battery or the FTDI cable is attached.


The rest of the build went smoothly and today I have a fully functioning radiation logger. Yes, I’ll definitely bring it to Dreamforce.

See you there!


Moov is the AI coach my dogs have been waiting for


I pre-ordered Moov a few months ago. It arrived Saturday and I tried it out this morning.


IMG_4278If, like me, you haven’t used an artificially intelligent coach before I suspect you’ll be pleasantly surprised by the Moov. You select a walking or running program, and it does the rest. I chose a brisk walk program, set some levels and we were off and running — er — walking I guess. The screenshot above is the outcome. I started on Level 1 and pushed to Level 7. Level 7 was 122 steps per minute with 2 minute intervals. The coach would tell you you’re on pace, the speed up, to avoid tending up, etc.


My dogs loved it – it was definitely faster than our usual morning walk.

The Moov is very interesting. The device itself comes with a couple of bands that it pops into and it pairs with your phone via Bluetooth. It’s very light and you put it around your ankle. The computerized voice tells you things like “You crushed it!” just like that $100 an hour personal trainer. Moving the levels on the app is a little unwieldy when you lock your phone but that probably gets easier when you use it more and know your levels. Also charging it is a little difficult due to the small charging leads, but should be manageable if you pay a little more attention that I usually do the first time I plug a new toy in.

Overall, $40 well spent.

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!



Get every new post delivered to your Inbox.

Join 4,918 other followers

%d bloggers like this: