Pages

Saturday, 28 November 2020

Salesforce and Slack - the End of the Beginning


The big news this week (last week of November 2020) is that Salesforce are in "advanced talks" about acquiring Slack. While I wasn't expecting this particular deal, I was expecting something of this nature, but I thought it would be in the realm of video rather than chat and they would try to buy Zoom.

I expected something because of the uptake that Microsoft Teams has seen since the pandemic started - from a disputed 20 million daily active users in November 2019,  to 75 million in May and then jumping to 115 million by November. The combination of file sharing, chat, collaboration, and video clearly has a lot of appeal, even though Microsoft referred to it as "digital translation of an open office space" which I'd imagine would put a lot of people off using it! Given that we'll be almost exclusively be using technology to communicate and collaborate for the foreseeable future, Salesforce had to be regarding the way Teams was embedding itself into the enterprise with envious eyes.

Slack hasn't seen the same explosion of usage and its share price has recently dropped, making it vulnerable to a takeover bid. From the Salesforce perspective, this is an opportunity to get across the entire enterprise rather than being constrained by the org - something the Chatter Free license attempted a number of years ago, but in my view foundered because it just wasn't a great collaboration tool when outside the context of Salesforce data. There was also the Company Community attempt to replace the intranet and more, but that was wildly expensive for a large organisation where most employees weren't Salesforce users.

While an acquisition will widen the Salesforce footprint, and no doubt bring deeper integration between the two tools, there will still be the need for Yet Another License for videoconference software. Meetings moves some of the experience inside Salesforce, but it's still someone else's application.

There's also Google Workspace to compete with - Meet and Chat have come on a lot in the last year, and complement docs, mail, calendar and co. very well. Again, it's one G-Suite license and all of those tools are bundled.

So in my view, buying Slack makes sense, but it's not the end - rather it needs to be part of a larger program to provide all the tools needed for enterprise collaboration in a single offering. That's what Microsoft and Google are doing and Salesforce is playing catch up. To paraphrase Winston Churchill, this needs to be the end of the beginning, not the beginning of the end.

Follow @bob_buzzard



Sunday, 1 November 2020

Giving the CLI Scanner the GUI Treatment

Introduction

As I've written about in recent posts, I'm using the Salesforce CLI Scanner to perform static code analysis on a number of my projects. As it's clearly part of my day to day use of the Salesforce CLI, I decided to add it to my CLI GUI.  

TL;DR, pull the latest code from the Github repository, or clone it and follow the instructions to carry out the initial setup. When it starts up you'll have the Scanner command group.

Commands

I added the scanner as a new command group, with a couple of commands - listing the rules and running the scanner.

Listing Rules

Listing the rules is fairly straightforward as I used existing parameter types to capture the categories and language, should the user wish to provide them:



and only needed to include a function to process the return JSON to extract the rule details and dump them to the log panel:


Running the Scanner


Running the scanner was a little more complex. First, I usually want to pick the categories but I don't want to have to remember the exact names, so I needed a mechanism to allow me to select from list of options. I've got a good start for this around allowing the user to choose which log file to retrieve from the Debugging command group. Under the hood I run the scanner:rule:list command, process the output to extract the unique category names, then build a select element using the categories as options. As I can choose multiple options I set the multiple attribute and give it a size of 7.  I don't always want to choose though, so I didn't want to have to wait every time for the command to run, so I gave myself a button to click:



I also typically want to open the file that the output is sent to, so I added this capability too:




Aside from this, most of my effort went into figuring out how to pass enquoted parameters to the scanner:run command (to define the targets, for example) on MacOS and Windows 10. I learned, for example, that Node's execFileSync will not spawn a shell to run the command thus any spaces I provide will be assumed to be different arguments to be passed to the command, regardless of any quotes that I might add in a futile attempt to influence it. execSync, on the other hand, will spawn a shell which will know that an enquoted string is a single parameter, allowing the command to succeed. I wouldn't be surprised if there is still the odd issue around this in there, so if you find one let me know by raising an issue at the Github repo.