TrailheaDX - Is This Dreamforce For Developers?
The last week of June saw around 6,000 Salesforce professionals descend on San Francisco for the second annual TrailheaDX. The conference took place on the upper floors of Moscone West, rather than sprawling all over the SOMA and Union Square areas of Salesforce’s home town, as Dreamforce does. But the space still had a familiar feel, with Salesforce product booths, partner product booths, several theater areas for sessions, and lots of Trailhead swag to be earned.
Exciting Announcements
The conference bills itself as the “must-attend developer conference of the year,” but in doing so is using Salesforce’s expansive definition of “developer,” from skilled admins who take advantage of the declarative tools the platform provides to serious coders. Within the coder group, there are those with experience writing Apex, Visualforce, and Lightning Components, as well as those who are new to the platform and have experience in other development environments.
There were several product announcements during the keynote, with follow-up sessions that were very coder-focused. The first was three new APIs that give developers access to parts of the Einstein AI platform. The biggest “wow”-factor was the Einstein Object Detection API, which builds on the image recognition of the Einstein Vision API that’s been available for a little while. This facilitates identification of individual objects within an image. Einstein Vision itself is very cool - there’s a Trailhead Project that walks you through using it to identify breeds of cats from images.
I was more interested in the Einstein Sentiment and Intent API announcements, which start to bring natural-language analysis and interpretation to the platform. The Sentiment API classifies text strings (think Chatter posts, Case comments, or even Tweets) as positive, negative or neutral. This could be used to escalate the cases of very angry users, or to find good customers to reference from their positive feedback. The keynote provided the least information on the Intent API, but I’m looking forward to exploring more; we’re working on a project now that could really benefit from some natural-language processing to help community users find the content they’re looking for.
For coders, the way that we work and the tools we use are sometimes almost as important as the platform, languages, and their features. The announcement of the public beta of Salesforce DX (Developer eXperience) was directly targeted at coders and development teams. It has three main components:
- A new command line tool that works with tools developers are already using to manage and deploy their source code to different Salesforce environments.
- A new way, using this command line tool, to quickly create and use “scratch orgs,” short-lived Salesforce orgs with different configuration parameters to which you can deploy and test your code.
- A new version of the Force.com IDE that takes advantage of both of the above features.
Managing multiple developers working on different functionality for the same production org has been a challenge, and these features seek to make this a lot smoother. There are also some potentially interesting applications for tech-savvy, command-line friendly admins, to foreshadow a future blog post.
As I selected my breakout sessions, I was mostly focussed on Lightning Component development and Salesforce DX in my selection. In some cases, that broad range of attendees at a “developer” conference made it difficult for presenters, especially in the 30-minute theater sessions, to really provide the deep dives I was hoping for. A session on “Data Access Control for Apex, Visualforce, and Lightning” spent way too long for my tastes covering the basics of object CRUD, field-level security, and sharing, leaving too little time to cover how the different platform languages treat the data access definitions.
On the flip side, a session about becoming a “command-line ninja” with Salesforce DX skipped right over all the standard use cases for the command lines tool and covered writing your own custom plugins to the command line tool using NodeJS. It is an interesting topic for the right audience but wasn’t what I was hoping and expecting to learn.
I did learn a ton about developing with Lightning Components and was especially grateful for a roadmap session that spelled out (with lots of Forward Looking Statements) how Lightning development is going to be improving over the next several releases.
Does this replace Dreamforce for developers?
This was a question that a number of people I spoke with had in mind. After all, two trips to San Francisco a year is an expensive endeavour, and we all want to get the best advantage for our time and money.
The smaller size of the conference and the greater availability of some key Salesforce staff, like product managers and engineering team leads, is a big plus for TrailheaDX. On the flip side, the speakers were nearly all Salesforce staff, with a few partner product sessions, and less than a handful of community-presented sessions. The opportunity to learn from my professional colleagues, in a session setting rather than hallway conversations, was the thing I missed most in comparison to Dreamforce.
The overall amount of content available, at the level I sought, is actually about equal between the two events. It’s nice to be able to focus exclusively on developer content at TrailheaDX, but I think most of what I attended will be similarly presented at Dreamforce. At the end of the day, I was extremely grateful to be there, and it left me very much looking forward to Dreamforce in just a few more months.
Were you at TrailheaDX? Did you love it? Agree or disagree with my characterization? Share your stories and questions with me on the Arkus Facebook page, in the comments below, in the Success Community, or to me directly via Twitter at @tet3.
