The Welkin Suite Team just recently got back from attending TrailheaDX-17 in San Francisco, this last weekend, and we really appreciated the opportunity to visit with our user base, but also we appreciate what we have gained from the great atmosphere that Salesforce installs into its events. There were many useful sessions for all attendees to attend, and as is always the case with Salesforce events, the many people who are working in and around Salesforce are excited to share their knowledge with anyone who is willing to listen.
We were blessed to be set up close to Summit Theater, so we had a great opportunity to hear some bits and pieces of what was going on as we worked our booth. There were a lot of talks about the rollout of the open Beta for DX, the power of Einstein and how to start to implement machine learning into Salesforce apps, the switching of apps over to lightning, community learning, and Debugging in Salesforce. Truly everyone that attended TrailheaDX-17 came away a winner, with new knowledge, skills, and tools that can be used to the betterment of themselves and the companies that they believe in.
New functionality is great, but never forget your core.
It was interesting to have the opportunity to listen to the Keynote Address at this event, as the event floor was closed so that all could attend or listen in on it. I am sure most of you remember Salesforce’s Co-Founder and CTO Parker Harris talking about how staying true to Salesforce's core values, which were started from the very start, have helped them to become one of the fastest growing software companies on the market, with over 8.4 Billion in revenue. He talked about how Trust, Growth, which for one he contributes to the great developers and admins who continue to innovate with the Salesforce platform, and Equality.
For me, I came away with a similar feeling, as I was talking with some of the Developers who have been with us from our start. As many know, The Welkin Suite Team has added a lot of new functionality over the last years dealing with debugging, declarative development, a Soql query builder, PMD support,and so on. However when we started, our goal was to be able to handle the most tedious tasks for the developers, those things that need to be done over and over and over again, so they could pay attention to the more important aspects of their work.
It was interesting to see that this is still today what our users are telling us they benefit the most from, such as being able to handle all the unit testing from the IDE, and being able to run the tests how they need them to be run. Rather that be by just running a single failed test, having the ability to manage their own Test Suites, or having a highly reliable build process that is fast and “always” works for them. And from this, I can see that our vision of bringing this core belief to the aid of those who are more focused on Declarative Development is the right way to go. I am sure everyone that attended this year's TrailheaDX, will agree with me, never forget your core, it is what will keep the wheels on the train, and keep it fueled for the future.
And really, I mean why should there be an escape, with all the power that today’s and tomorrow's Declarative Development possibilities in Salesforce can offer. I was walking by Eric Schultlz’s session on using Process Builder as a declarative automation tool for business users, and the power and speed that can be gained if declarative development is done right is incredible.
We were pretty proud to be able to show our new tools in The Welkin Suite for Declarative Development such as our sObjects Field-Level Security Editor, sObjects Layout and Fields Inspector, and a Permission Set and Assignments Editor. Oh, and not to forget the SOQL Query Builder that allows for a quick building to query business objects. For the most part any developer regardless of experience or seniority said that the FLS part was something that they could and surely should be using, as this will save them a lot of time. As one very experienced developer told me, this more declarative development is still development, and it will remain a part of the job.
It was also great to hear from another one of our users that this FLS editor saved him 4 hours of work just two days earlier. So we know we are on the right track here and that we are not “crazy” for adding “Admin” tools to an IDE. So we are full speed forward with our future plans to add a Validation Rules editor, Workflow editor, and debugging for Validation Rules with workflows. The key here is to take the labor intensive steps away, so a human error does not take away from the power of declarative development.
Need for a standard tool that is supported, and allows for innovation to take place.
How many times from the Keynote Address to the many sessions, did you hear the word innovation used? I know that I was hearing this continuously throughout the two days of the event. There is no doubt that innovation is being fueled in the Salesforce World by having a standardized platform to build from, and one that is supported and changing fast enough to meet today’s and tomorrow's needs.
I believe one the reasons that the Salesforce community is so strong is that everyone is speaking the same language “Salesforce”. This allows for an uninterrupted flow of communications and sharing of information across all individual, company, domain, and nationality cultures. That said, one thing that I find interesting is when you talk to developers, it is amazing how often development teams are struggling with the aspects of different team members using different development tools. Because of this they struggle to “speak the same language” and there is definitely a felt loss of unity across the team due to this.
How many times did I hear from team members and team leaders they would really benefit from of having a standard development tool for the whole team? Well to many to count, and it was fun to look at them and say well you just might have found it, and honestly it seems as they did. The package of having both Windows and Mac, Standard Development and Declarative Development tools all packaged under one roof, and a heavily supported tool, and all that you get with The Welkin Suite, had many running to their Managers and other Upper Management to show them the benefits.
Yes, it looks like the time has finally come, when Salesforce development can finally catch up to the rest of the development world in terms of ease in Continuous Integration. I know by having watched not only our Salesforce development team struggle with how to do this in the past, the many different schemes that were discussed on a model of “best practice”, the trial and error method of integrating a “proper” flow, but many other companies as well, that many companies are excited to jump into the beta flow for this.
I did not get the chance to listen in on Mike Miller’s and Jim Wunderlich’s session on Migrating to Salesforce DX, but I know I had a few developers cut their visit short to our booth as they were running to not miss it. The good news is they came back to ask us about how we were going to support DX, and they were informed that The Welkin Suite’s Development Team has already been working on this task and we plan on having a great UI for them and all of you to be able to support your Scratch Orgs.
Again we will be making this process as simple as possible for the developer, so they can stay on task and focus on the large picture. We are hoping to have this out in the next month or two.
I learned a long time ago that one should not avoid pain, discomfort, or embarrassment as it is through these that change takes place. In other words, without discomfort, pain, and embarrassment, there would be no stimulus for change.
So I guess we all should actually thank Salesforce for such great debug logs, and for turning us into Debug Log Ninjas. But in all seriousness, there is no need for the eye strain anymore, as there is good Debugging options out there. Many of you saw the session from Danny Chang and Vivek Chawla about Squashing Bugs With APEX Debugger. Life is so much simpler and more enjoyable when you can simply step through your code and see the changes taking place to your variables in a step by step process that is added by break points.
And as was discussed, some of your favorite IDE’s have the ability to support this live debugger from Salesforce. Yes, even The Welkin Suite will have this possibility in the future. On the other side of this our IDE already has its own debugger that allows you to step through the code, view the Stack Trace info, Local Variables, and Governor Limits. Yes it is not a Live Debugger, as it is using those awesome Salesforce debug logs, but it is giving a great simulated debugging session, and getting the job done without having to have any additional fees or licensing from Salesforce.
Many I talked to were quite surprised to see that there was another affordable solution for debugging out there that did not force someone to have to filter manually through endless logs.
It would be great to hear some highlights from some of you, as of your take on this year’s TrailheaDX, so if you have a few minutes, please feel free to say something in the comments. I would love to hear what your experience was like, and what you took away from the event. As for me, I am now focused on Dreamforce-17. So The Welkin Suite Team and myself will take what we have learned from TrailheaDX and apply that knowledge to our jump into Dreamforce. We have some great upcoming features to show at Dreamforce that will definitely compliment that strong core of comfort that we started out with almost 3 years ago.
