Category Archives: Development

5:49 am - February 21, 2015 - Reid Carlberg

npm install parenting

My young son and I (aka The Critter) talk about a lot of things, including the fairly abstract work I do. I wanted to make it more concrete for him, so, for fun, created a super simple node library which is now, shockingly, available via the esteemed npm and of course on github.

The gist? Well, you put a number of things you might say to your child in as prompts, and can then have the computer say them out loud. It comes with defaults, you can create your own, and it of course has auto mode where it just says one right after the other.

Useful phrase like, Reid, use your napkin. Reid, clean your room. Reid, stop doing that.

You get the idea!

It must have connected a little because here you can see him changing the configured name to be that of his sister!

Haven’t tested on a Windows machine.

Category: Development Tags: node.js, parenting

4:54 pm - February 20, 2015 - Reid Carlberg

Salesforce Lightning Component Newbie Notes

Like a lot of you, I recently started down the path of learning Lightning Components. These are my notes and code snippets based on a series of questions I asked as I went through the docs and tutorials. I hope you find them useful.

Salesforce Lightning Component Newbie Notes

This is the first time I’ve used Jekyll and markdown to create a relatively extended blog post. Pretty convenient!

Category: Development Tags: lightning components, salesforce

5:29 pm - December 22, 2014 - Reid Carlberg

LEGO Mindstorms: Solve Rubik’s Cube in 90 Seconds

If you’re looking for a last minute holiday gift for the burgeoning genius on your list, go get a LEGO Mindstorms EV3 set. Yes, they’re expensive, but they’re worth it.

Want proof? Watch this:

Yes, that’s from a single set, and it solves the infamous Rubik’s Cube in about 90 seconds. Amazing, right? Yes, it is. And my kid has been talking about it non-stop since I stayed up a little late to build it on Friday night.

I didn’t design this, I just followed the excellent instructions for Mindcub3r from David Gilday.

So totally worth it.

Category: Development Tags: Lego, mindstorms

12:36 pm - November 20, 2014 - Reid Carlberg

Simple Salesforce Lightning Connect Example (External Objects)

Lightning Connect includes External Data Sources and External Objects. You can try this in your free developer edition. There’s a nice blog that talks about setting up a more custom data service and covers a bit more about why this is super cool. Andy Mahood also blogged about this recently, including more details on related lists and Chatter.

Lightning Connect is the new service from Salesforce that lets you bring OData content into your Salesforce org. I was curious how to test it, so I thought I’d share what I found.

Step 1: Locate Sample Data

OData is a protocol for exchanging .. er … data, so it makes sense that you could probably find some sample data to connect to. A bit of the old Google led me to this sample data page where you can click on a tab to see “V2” sources.

When you click on the Northwind sample, you get a bunch of XML (hooray). You’ll want to copy the URL in your browser window at this point.

Step 2: Create a new External Data Source

Back in your free developer edition, navigate to Setup > Develop > External Data Sources, and fill in the form as shown in the image. In the Server URL, paste the .. er … server URL you just copied above.

Important: once you click “Save” you then need to click the button that says “Validate and Sync” before you can move on.

Once that’s complete, you will be able to select the specific object you’re interested in. For this example, select “Categories” and click on “Sync”.

After a moment, you will return to the external data source screen and your external objects related list will look like this — sweet!

Step 3: Create a Tab for the External Object

If you click on the “Categories” label in external objects related list, you’re going to see an object definition screen that looks shockingly familiar. Yes, it even includes a “Page Layout” section at the bottom.

Adding this to a tab is super easy. Navigate to Setup > Create > Tabs, and create a new tab for a custom object. That’s it! Now you can easily navigate to particular records, work with list views, etc — all of the stuff you can easily do with custom objects.

Step 4: Do a SOQL Query

If you’re like me, you are by now fairly curious about accessing the data in Apex and in a standard SOQL query. Head on over to Workbench. When you login, be sure to login using v32.0. Jump to SOQL queries, and select the “Categories__x” object.

And in the .. er … category of least surprising thing ever, you can see it works!

But what about Apex you say? Yes, also just that easy, as you can demonstrate for yourself using Workbench’s Apex Execute utility.

Pretty Sweet!

Give it a shot and let me know what you think. @ReidCarlberg

Category: Development Tags: external data sources, external objects, lightning connect, odata, salesforce

3:37 pm - October 30, 2014 - Reid Carlberg

Five Enterprise Internet of Things (IoT) System Architecture Patterns

Updates based on feedback at the bottom.

I’ve said before that all Internet of Things (IoT) projects should start with a great use case that matters. In this post I want to discuss the next logical question: how to architect a system capable of handling the use case. I divide these use case centric IoT deployments into five architectural patterns, and I call them Anonymous, Direct, Buffered, Gateway and Cloudy. I’m going to first introduce a simple metaphor for how to think about IoT systems and then describe these core architectures, discuss their capabilities and limitations and review some interesting variations.

Note that I use Salesforce products here to represent key business systems, but each architecture could be adapted for use with other offerings (although you should really have Salesforce in the mix IMHO).

Also note that these architectures are more about generating actionable insights than they are about managing devices deployed in the field. Great Salesforce partners like Devicify and Cycle30 can help with these issues.

The Metaphor & Key Considerations

The easiest metaphor for a robust Internet of Things system is the nervous system. Signals come in from the extremities, they are processed in the brain, and muscles take action. In an IoT style solution, sensors send signals up the chain, those signals are aggregated and analyzed, and new signals are sent to actuators of some kind. Note that these actuators may be devices, other systems or people.

(You might enjoy reading about the nervous system over on Wikipedia, which is also where I found this great image.)

When you’re designing your system, you should consider:

Device Sophistication: What is the minimum viable device I can use to gather the signals I’m interested in?
Reporting Frequency: How often will that device need to report data in order for me to accurately analyze and understand the conditions I’m interested in?
Next Action: Once the information is aggregated and analyzed, what happens next and is it driven by a person or an automated system?
Distance: How many steps are there between understanding the need for action and the ability to take action?

A key difference between a standard animal nervous system and a robust IoT system is that the nervous system has private pathways for signals to flow. Most IoT systems will be running on the public Internet, and so will have significant concerns around signal encryption. That is the subject for a different article.

Anonymous

Anonymous implementations take advantage of APIs originally designed for use with basic websites. In the Salesforce world, these would be the Web2Case and Web2Lead APIs. These are incredibly easy to deploy by design, but, also by design, they lack many of the features considered standard in today’s business and IT climate, including authentication that clearly identifies the individual user or device reporting an issue. Example implementation: Create a case in Salesforce with the Staples Easy Button. Device sophistication: high. Reporting frequency: very low. Next action: human intervention. Distance: Low.

Direct

The first step above Anonymous is Direct, where the device knows how to authenticate and is powerful enough to communicate securely using standard REST APIs. Direct integrations require standard credentials embedded in each device, and so is generally appropriate for higher order systems and higher value add situations. This architecture isn’t well suited to high volumes of data or transactions, but works great for systems that report, for example, once per day. Example implementation: Control Philips Hue from Salesforce. Device sophistication: high. Reporting frequency: low. Next action: human intervention. Distance: low.

Buffered

The Buffered architecture enables systems to communicate at higher transaction volumes without requiring the destination system to be aware of the originating devices in a detailed way. Buffered architectures simplify IoT systems by allowing you to create a custom API and to define your own interaction models. On the Salesforce1 Platform, you can easily create a buffered architecture by combining Heroku services with Force.com services. Heroku would be responsible for device interaction and information aggregation. The system would then sync summarized information to Force.com using Heroku Connect or standard REST APIs. Device sophistication: medium-high. Reporting frequency: medium. Next action: automatic or human response. Distance: medium.

Gateway

Gateway architectures allow you to include much lower power devices in your IoT system. These low power devices communicate with a more sophisticated gateway device that is powerful enough to connect with either a custom API built on Heroku or a standard Force.com API. Although I’ve used Bluetooth to represent the low power device, it is not limited to bluetooth. Gateway architectures open your system to a much greater variety of participating devices since the gateway can serve as a broadly capable adapter class. Device sophistication: low for the device, high for the gateway. Reporting frequency: high. Next action: automatic or human response. Distance: high to medium.

Cloudy

Cloudy architectures are interesting because they essentially roll-up functionality starting with the device end of the typical IoT value stream. The core model is to combine a core piece of hardware with Internet connectivity. The connectivity ends in a cloud service, and the cloud service becomes the end point for talking to business systems. This pattern requires a higher level device in the field along with rich connectivity between that device and cloud system. The integration is then cloud to cloud. This is a great way to get started, but, like any tightly coupled design, your ability to change and modify the system is bound to the strengths and limitations of your supplier’s platform. Device sophistication: high. Reporting frequency: indeterminate. Next action: automatic or human response. Distance: low to medium.

Variation #1: Direct (Augmented)

Sometimes you’ll want to interact with Salesforce APIs directly, but you’ll want to augment that interaction with computing resources located on another system, e.g. an app running on Heroku. This is useful when you need processing not typically handled on the Force.com platform, such as image analysis. In that case, you can easily upload data to Force.com, trigger a Heroku process based on that data, and then complete the interaction by putting the actionable results back in Force.com. Device sophistication: high. Reporting frequency: low. Next action: human response. Distance: medium.

Variation #2: Buffered by Partners

The Salesforce ecosystem has a rich variety of partners, including several focused on building end-to-end solutions for our customers. One way of deploying a system is to use a partner solution as your aggregation layer, looking something like the picture below. Note that the device below could be replaced by a collection of lower powered devices connecting to a more powerful gateway. Example implementation: Get Started with the Internet of Things in 10 Minutes. Device sophistication: medium-high. Reporting frequency: medium. Next action: automatic or human response. Distance: medium.

Variation #3: Double Buffered

It’s also possible to create a double buffered system that puts a partner solution in front of a custom API deployed to Heroku, which then connects to Force.com. This creates a more complicated system, but might be justified by your business case. Device sophistication: medium-high. Reporting frequency: medium. Next action: automatic or human response. Distance: far to medium.

Next Steps

I hope this discussion is useful for you. I’m going to be doing a longer version of this at ThingsExpo in Santa Clara this week (November 6), which also includes some background, use cases and predictions.

If you have comments, I’d love to hear them. If you’re working on an IoT deployment, I’d love to hear about that too.

Follow @reidcarlberg

Updates & Feedback

@MJFreshyFresh put together a scatter plot of patterns AND sketched some ideas about how actuators and sensors might have different pathways. Pretty sweet!

@AliNajefi points out that examples would be helpful, so I’ve added links where I’ve created examples. Great feedback!

Category: Development Tags: architecture, IoT

8:16 am - October 6, 2014 - Reid Carlberg

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!

Category: Development

7:50 am - September 29, 2014 - Reid Carlberg

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.

If, 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.

Category: Development

3:00 pm - September 8, 2014 - 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) – Apple.com
09/07/2014 – Intel / Fossil Smartwatch (UI) – Gizmodo
09/05/2014 – Moto 360 – Watch, Pulse, Steps (UI) – Motorola.com
09/05/2014 – Daqri Smart Helmet (UI) – Daqri.com
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) – SpaceGlasses.com
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) – GigaBryte.com
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) – FitSense.com
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.

Categories: Development, Tech Life Tags: abacus, IoT, wearables

9:40 am - August 25, 2014 - Reid Carlberg

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.

I 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.

Category: Development Tags: 3D design, 3D Printing, RC Trucks

2:03 pm - August 20, 2014 - Reid Carlberg

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.

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 Force.com 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.

Categories: Development, Tech Life Tags: DF14, Dreamforce, history

Category Archives: Development

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this: