Keir Bowden, one of the first Salesforce CTAs, joins to talk about Salesforce CLI.
Keir is also the author of the Visualforce Development Cookbook, five-time Salesforce Developer MVPs, and the CTO at BrightGen.
Sponsor
Proton Text is a complete SMS texting solution built for the Lightning Platform, and by one of our previous guests Pat McClellan.
Main Points on Salesforce CLI
- Discussion about Keir’s Visualforce book
- Introduction about Keir’s play-by-play on the same topic
- How did Keir learn Salesforce CLI?
- What was the developer experience preceding CLI?
- Can we use CLI with regular static orgs?
- Extending CLI with scripts and plugins
- Keir shares two typical challenges of using scratch org
- Keir’s Mentz program to help people learn better coding
- Discussion about how to create and distribute plugins
- How does VSCode Salesforce official plugin use CLI?
- What are the things that can still be improved?
- Keir’s DreamForce 19 talk – Testing UI with Selenium and NodeJs
Links
- Keir’s Linkedin
- Keir’s twitter
- Keir’s play-by-play videos on Salesforce CLI
- Keir’s famous Bob Buzzard blog
- Keir’s Medium blog
- Keir’s Mentz – developer mentoring program
Video Teaser
Outro Music
Tristram Village – Diablo I & II
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:00] Our sponsor today is Proton Text, a complete SMS texting solution built for the Lightning platform by one of our previous guests, Pat McLehlan. Here is reason number three that admins and users love this app. It comes with the Proton Blaster. It's true, Pat built a Proton Blaster. It's a Lightning Web Component that lets users plan and schedule SMS blasts to campaign members or to a blast list created from any list view or CSV file. Whether you're blasting to a hundred students or volunteers or to fifty thousand leads, setting up a blast is as easy as creating a calendar appointment. It's not magic, just good design. Learn more at protontext.com.
[01:06] Hello, everybody. This is Xi Xiao. This is yet another episode of Salesforce Way podcast. Today I'm sitting with Keir Bowden from the UK. Hello, Keir. How's she? How are you doing today? And good, and good. Really thrilled to talk to you. You know, the topic is one of my favorite topics, so I'm really excited to have you on the show. Cool. I'm really excited to be here. Yeah. So you know, I know a lot of information about you. I know you are one of the first certified technical architect, the so-called the CDA, right? Yes, indeed. And you're the CTO at Brightgen. That's the company you're currently working in. Yes, that's right. I've been working here for eleven years, and I'm the C. I've been the CTO for eight, I think now. Okay, that's cool. That's cool. And you got a book, the Visualforce Development Cookbook. Indeed, and I actually opened it and looked at something in it about two weeks ago. Oh really? Okay. Yeah, I don't. I don't do much Visualforce these days, and I seem to have forgotten most of it. You know, writing a book is um, it's really like a milestone. I I really admire people in the ecosystem who can really write a book, like a Dan Appelman had the Apex book. You have yeah. You know these things. Yeah, mine. So mine started because I was approached by Pact Publishing to review somebody else's book, and as I was going through it, I thought, How hard can this be?
[02:34] So they asked me to do one, and it turned out it's hard. It's not too hard, but it takes a lot of time and effort. But this is your first book. Yes. Ever? Oh, okay. I can see that. Okay. And definitely, my only book so far. I didn't have a chance to really look at your book because Visualforce. By the time I joined, the Lightning component is already there. You know, everybody moved to that direction. So I didn't have the chance to really read the book. Yeah, it's just for me. I I still go back to it because obviously we've got some customers who are still on Visual Force embedded in Lightning, and they ask us to change things, and I can't remember how you get multiple forms on a single page. You know, it's it's interesting to see that the author need to go back to its own book.
[03:22] Yeah, so Keir, I invited you here to mainly to talk about the Salesforce CLI, and you are really one of the experts who know the inside outside of the the tool. So today I'm having an arm, and definitely I know you have done a fantastic play-by-play with Don Robbins about the very same topic. Indeed, yeah, that was really interesting. Don had been asking me to do play by play for a little while, and we came up with the idea of the CLI. And I'm not much of a one for video learning; I prefer reading books. But actually, I really enjoyed making it. So it appears I don't mind videos as long as I'm on on this side of the camera. Yeah, that's cool. Because I watched the video, the whole series, and I give a five star, and I left my comments over there. So I really enjoy the content. So, do you have chance to really give everybody like a high level summary what you have done there on the video? So I've also put the link down below in our show notes. Cool. Yeah. So the the CLI. It's so the the play by play on the CLI. Play by play is a very conversational. So it's basically Don asking me questions about the CLI, what its purpose is, what where it adds value in the Salesforce development lifecycle, and then some of the key use cases. And we put together sort of I think five key use cases. Yeah. Getting started. Getting initialized.
[04:52] Creating scratch orgs. Migrating metadata to scratch orgs, migrating metadata to regular orgs, manipulating data, running tests, and extending the CLI. So they're kind of the sort of things that I do on almost on a daily basis. Apart from the plugin aspect. Ah, so your role is a CTA, and you still do a lot of hands on stuff nowadays. Yeah, I would say at the moment I do probably more around tooling than I do anything else because that's the best way that I can support my team. So I'm there offering advice and oversight, but I don't really want to be writing the code with them. But I want to figure out where they're struggling with things and add some tooling in that enables them to work more efficiently. I watched the the video you have made with Dan Robbins. The kind of feeling that I got is that the Salesforce CLI is really covering a lot of aspect for the developers. So, as you mentioned, like ah interact with the metadata, testing, manipulate the data, scripting, or even you mentioned in the video as well how to extend the CLI to create your own plugins as well. So, it's really a sophisticated tool, I would say. Yes, yeah, I agree. I think so. We originally started with the command line with Salesforce back when they launched the Force.com CLI. If anyone remembers that in Dreamforce 2013, so that was something put together by the developer evangelists. It was a really nice tool, but it wasn't anything like as full
[06:22] featured as the Salesforce CLI is. So we can do so much more than we used to be able to. Uh huh. So how did you learn the Salesforce CLI? Did you go to the online articles, or do you because you need those commands, and then you go search? So actually, it was probably slightly different for a lot of people because we were so embedded with the Force.com CLI, we built a load of tooling around it for our continuous integration, for our deployment to our various orgs. That mostly what I was looking at it was evaluating how it compared to the Force. com CLI and whether I could replace all aspects of my tooling. So we have our own command line tool which which wraps the Salesforce CLI and for a period of time it wrapped both the Salesforce CLI and the Force. com CLI and certain commands are only supported in one or the other until we achieved feature parity and then we could retire the older version. So it's an interesting time. Okay, yeah, that's interesting because um, I remember in the DevOps, the Salesforce DevOps, there were this Python tool as well that also wraps the Salesforce CLI, and the old tool, in the open source world. Yeah, I I started wrapping it in Bash because I know Bash, born again shell for those who who don't know Linux too well, and Bash gets really difficult to use when you're trying to parse JSON. So I went Node JS fairly quickly after that. Okay, I got it.
[07:52] So you mentioned a bit like a history here because I joined Salesforce not too long ago. By the time I joined, the Salesforce CLI is already launched, so I jumped right into the Salesforce CLI. But before that, what was kind of experience? What what did you do? So you're you're very lucky. So um. For a period of time, so I predate change sets. So for a period of time, we had really the Force.com migration tool, the ant wrapper around the metadata API, or an awful lot of deployments used to be done by selecting loads of things in Eclipse and choosing deploy to. To a particular server, so that was always entertaining. And the Ant migration tool was was was a fine piece of work, but it ran from inside Ant. And when you set up Ant, you use XML scripts, so it's quite difficult to do flow control. It's quite difficult to embed a lot of business logic in it. So we we did use that, but it was very much a case of we'd run a command to deploy everything, then we'd run another command to do something else. So CLI was a bit more difficult. So then Dreamforce two thousand and thirteen, the Force dot com CLI. So I come from a from a command line background. I've been doing this for thirty years. And that really spoke to me. That that seemed like a way that we could really gain control and add some business logic to it. Be able to script things. Be able to get some more complicated things going on. So I pretty much jumped straight in, rebuilt our tooling around that, and as I say, we didn't have
[09:23] a lot of automation because it wasn't very easy. So yeah, wrote a load of bash scripts. As I say, eventually bash allows you to get big quick, but it doesn't really allow you to do business logic very easily. You can do, but also it turned out that in the entire company, I was the only person who knew how to write bash scripts. So that wasn't very useful from a from a scaling point of view. So I rewrote them all in Node, and also wrote that we had loads of disparate scripts when I was using Bash. So we went. We decided that the command a single command line with subcommands like Git or like the Salesforce CLI, like the Force. dot com CLI, was the way to go. So we effectively built our own that delegates some things it delegates to Git, some things it delegated to the Force. dot com CLI. And that was really cool. It was an interesting period when it first came out because some things worked, some things didn't work, and it wasn't particularly wide. But it really became very useful over the next probably probably three years. We were using it for some three, four years, something around that. Because Dreamforce, I think, two thousand sixteen was when Salesforce DX was launched, and we got on the on the pilot of that. Yeah, so it was very much a faithful friend. Did have some limitations. Biggest one was that it basically had a single login session. So if you'd scripted three, four CLI commands and then halfway through that script running, you logged into another org. All of those commands then ran on your org, which was a lovely surprise if you weren't expecting it. Especially if you're doing some data manipulation. I remember that. I mean, for my command, just for safety, I always
[10:53] put this dash u at the end, just to make sure it goes to a specific org. It doesn't go any surprise at all. Yeah, absolutely. I heard one thing. I think it's mistake from a lot of developers that I'm talking to is that they always think when we talk about Salesforce CLI, they always link it to the unlocked package and the scratch work. They say, "Okay, we don't use in our project these new features, so we don't use Salesforce CLI." Yeah, I so I think there's there's a lot of not really understanding where it's used, and I guess there's an awful lot of Salesforce information shows it working against scratch orgs. Um, it certainly works as as well as a lot of other tools do against um regular orgs. Now you've got the Force Source Deploy and Force Source Retrieve. You can do everything from source format and still hit sandboxes and still hit production if you so desire. It's all generally available. I think the where it where it struggles the same as pretty much every other tool has struggled in the past is how you deploy deltas, how you deploy just the changes since your last release, and that's always been the case. The Ant Migration Tool basically deployed what you told it to, and the CLI will deploy what you tell it to. So you have to tell it the right things. That's difficult. There's a number of solutions out there. We've rolled our own custom solution that is company private, so it's not one I can share with the community. Unfortunately, I know people
[12:23] have worked on. There's an SFDX plugin that someone sorry, not an SFDX plugin, a VS Code. I think extension. They all bring their own level of baggage. Things like document folders and email folders are quite difficult to support, and also everybody struggles with supporting more than one operating system. So my stuff works on macOS, but it wouldn't work on anything else. And I know somebody else's stuff works on Windows and doesn't work on anything else. So be really nice if Salesforce solved that for us. But I guess if they ever move the the source tracking API, so what gives you the push and pull capability in scratch orgs? If they ever move that to other orgs, then that may solve that problem for us, which would be really cool. Yeah, I think definitely that's one of the things they should do, and in their roadmap, I guess, for the future. Yeah, the difficulty is, I guess, some of these orgs are going to have tens of thousands of components of artifacts in them because they've been around for so long. So, I guess it just may it may be unsupportable once the org gets over a certain size. I see. Well, a lot of challenges. When I started working Salesforce, the metadata was the first thing surprises me. So that's like the abstract middle layer, just to support everybody to to work on the Salesforce platform. But it also, you know, on the other side, it also introduces challenges for for us to to talk with the work and migrate the data between
[13:53] works. Yeah, and it's it's um it's not the easiest API to work with as well because you tend to have to package things up, send it off, receive an ID, then based on that ID, you check the situation. What's going on? So yeah, it's it's a bit chatty. There's a bit of to and fro. So you end up writing a bit of scripts in yourself to actually retrieve that and then manage the polling to see how things are going on. So I think that that's probably that's one of the biggest challenges I've always found with it. Is yeah, ideally there'd be a synchronous thing that would just come back and it would all be nice and easy. Good to know I'm not alone. So.
[14:36] And also, Keir, I understand that you have done some customization or kind of extension for the Salesforce Live, right? You need, for example, you mentioned that your company has your private tool. I understand that's also kind of extensions. So we got we kind of extend it in two ways. We we have scripts that will wrap the CLI, do some stuff before they then make the call to deploy. So that's that's that's the way we've extended it in order to be able to figure out the changes between two commit IDs, for example, or between the last time you deployed and what's in your local file system. But we also extend the other way, which is plugins. So this is typically where A good example: the last plugin that I created, or is it an existing plugin that I extended here? Basically, what that will do is that will do under the hood a metadata API deployment to disable parallel Apex unit testing, because we find in a continuous integration environment, because we have a lot of tests with quite a large system, we receive errors that we can't get exclusive access to the account table, for example. So we need to turn off that parallel unit testing. But we weren't able to do that very easily through automated tools, so it was always a manual step. Is this feature supported by the metadata API? It is. Yeah, Winter '20 they they changed it to the Apex setting. So as we're pretty much in Winter '20 now. So effectively, what what my plugin does is it generates in a temporary
[16:06] directory an Apex settings metadata file, deploys that to the org, which turns off or turns on depending on what you've asked it to do. Parallel Apex unit testing and then reports back how it got on, etc. So what this means is part of my continuous integration. Now I can deploy to a scratch org. Deploy all my code. Do any setup I need to do. I can then turn off parallel unit testing, and then I can run all my unit tests and be confident that I that everything's going to going to run to completion. That was probably for me in terms of continuous integration. That was the missing piece, being able to do that. You could do it before, but it was never documented, so I didn't know if it was really supported. So I didn't post anything about it until until it seemed like it was coming in Winter '20. So I understand. And what you're doing is you try to automate the manual steps. Yes. Right, yeah, but still, there's something that you basically cannot automate at all. Because I'm doing a project, there are a lot of manual steps written in the runbook. It's like hundred rows of manual work. I couldn't imagine. I haven't studied yet, but if I, for example, if one day I switch to a scratch org, I need to study all the lines. What things can be automated? What things cannot? I think that's the way I need to go. Yeah, it's difficult. I mean, scratch orgs are certainly getting more and more flexible. And we got org shape now, which is in pilot, which allows you to create a scratch org based on what another org looks like. You probably would be able to automate everything you
[17:36] needed to do if you used a tool like Selenium. Which I'll be talking about at Dreamforce. Okay. However, what that means is you'll have another bunch of code and another tool that you need to maintain. So whether you'll actually get any benefit out of that versus doing things manually, it's always a trade-off. I find that there, you know, I do things manually until it becomes a problem that I automate. You start off trying to automate everything from the beginning. Yeah, end up maintaining an awful lot of things with an awful lot of moving parts. Yeah. So for a small like a test project, the scratch org really works well. You don't have any manual steps. But once you have menu steps, then the benefit of like tear down and spin up a scratch org instantly for the developers kind of we lose that benefit because I I don't want to recreate and then do all the menu clicks anymore. Yeah, that I would say there's there's that, and the the other challenge with scratch orgs is getting appropriately indicative data. If you've got a complex data model. Then getting that all set up in such a way that developers can be immediately productive is still a bit of a challenge. The way I've gone about it is I've just written a bunch of Apex code that inserts all the objects that I need, and that's part of my setup. And then I execute that anonymously. Okay. Because I also heard some open source projects from the people in the ecosystem. They have created some, like a Python script or some some tools to do that. Yeah, there's a few things there, but when I looked, so
[19:06] there was something I saw from I think it was from Salesforce. Might have been from the Dev Evangelists or somewhere in Salesforce, and it did look really nice. But I was then having to do a bunch of configuration about that and a bunch of mappings to tie my. Data on disk to where it needed to go onto the, the org. It looked like I'd have to do maintenance around that, and I decided I can maintain Apex code just as easily as I can those mappings. There is no, there's no ideal world at the moment. Really importing those data. Yeah, that's still the challenge. I mean, they'll get there, but yeah, if you don't have good data, if you have to spend a lot of time setting data up, then you don't gain an awful lot by by using scratch orgs because you lose it all a few weeks later. Yeah, can't agree with you more on this.
[19:57] Hi, here's a quick note. Don't forget to check the show notes of this episode, where you can find short video teasers, the guest contact information, the important complementary materials, and my own learning points, among many other useful information. In addition, I have also started a YouTube channel to share important stuff I learned from my guest. If you are serious about your Salesforce developer journey, you should definitely consider subscribing to this channel. And obviously, the name of this YouTube channel is Salesforce Way. Now let's get back to the show, shall we?
[20:41] And I understand you also have a program called a Ment. Would you like to introduce that as well? Yes. Yes, my Mens prayer. So, so the idea of Mens was there's a lot of things out there that are bootcamping people to understand some Apex development. But what Mens is about is having programming challenges, the sort of things you'd see for any language. So they're tied to Apex, but they're not specifically Salesforcey. They might be about manipulating arrays or about sorting strings, things like that. So people can then create a solution to one of those challenges, and they can upload it into an org, and then they have experienced developers come back and tell them. Ways they could improve it, things that they're doing that maybe aren't the most efficient, or just that there are various ways they could have achieved that. Yeah, so we got a pretty stellar cast of mentors in there, a number of mentees. I'd say probably ninety percent of people sign up and don't do anything. So I think people are keen on doing Apex, but maybe including once they get down to it, it's a bit harder.
[21:45] Yeah. So, so I created a plugin for Ments. So it's a Salesforce CLI plugin. Am I right? Yes. So, so basically, to allow people to to check out of Git, because I didn't want people necessarily having to understand all that, they can run a they can install the Mintz SFDX plugin, and what that will do is it will show them they can enter a keyword. It will show them all the challenges that are available. They choose a challenge. It does the Git pull from GitHub, gets it into the right directory. They then go fill out the class that they've been instructed to fill out. Once they've done that, they then run another command line tool that uploads it to the appropriate chatter group as a code snippet. Notifies all the mentors that someone's completed a challenge. So it kind of automates everything behind the scenes so that someone can come in and provide them some mentoring. And again, it seemed like a really good way of not having to give people a list of like eleven commands they have to do and not have them understand them. Again, the the only issue I would say is that everybody's using different operating systems, so you end up spending a bit of time supporting all those. Okay, it's again coming back to the operation systems, because I have registered. You you definitely know you you accepted me that, and I I want to give it a try. I definitely want to give a try. I don't want to be the one of guys who signed but don't do anything. Do you have like a targeted people? Is it like um a junior developer or or people who don't know how to write code yet,
[23:15] or what's your targeted? It's mainly aimed, I would say, at people who have been through some basic Apex training and have an understanding of the syntax, have an understanding of how to write code, but they don't necessarily know, given a problem, the most efficient way to solve that. They haven't solved a lot of problems with Apex, so they'll probably be going with what they've learned. So yeah, so it's aimed at those, so that we can basically the mentors can go back and explain how things could be done differently. Better and I must admit, I read the mentor feedback as well, and there's some useful nuggets of information in there for everyone. I would say, okay, including me. I will definitely give it a try, and I will put your mentor program link in our show notes. Excellent, great. So you have created multiple plugins for Salesforce CLI. So I haven't had the chance to touch it, but I just want to get an overview, like how powerful this thing is. Can it really do, for example, some malicious actions in your computer? Is it allowed? Absolutely, absolutely. Yeah. All right. That's the dangerous signal, Jamie. So there's a there's a character on my blog called the evil coworker, and whenever I'm blogging about a piece of technology, I often say how the evil coworker may use this to undermine confidence in my abilities within the company. Yeah. So when you distribute a plugin, when someone installs it, it will say this is unsigned. It hasn't been through
[24:45] any review process. So you really are trusting people to the to to a degree. What I would say is that once you've installed it, because it's all node modules effectively, all the source is really there as long as you know where to go looking for it. So it's a bit like Chrome extensions. You know, the thing to do is to go and look at the source and just just confirm for yourself it's not doing anything nefarious. Okay, good to know. Yeah, I never paid that that much attention. I know this this warning for the certificates, but I anyway I need the tool, so I just accept it. I I give a yes. Yeah, but most of the things like in the past, in the 12 episode, I had the chance to talk with Shane McLaughlin's, and he created the Salesforce CLI plugins. Yeah, and I know Shane's plugin really well. And whenever I'm trying to figure out how to do something, I can normally find an example in his code because his code is published on GitHub. So if anyone's trying to learn, and I mentioned Shane in the play by play as well, if anyone's trying to learn, then Shane would be the first port of call. I would say. Okay, good to know. And how about the plugging distribution? I think you also have the experience on that. How do we distribute our plugins? Yeah, it's it's actually not too difficult. It's basically it's running some npm scripts. So you will need to register with npm.js, the Node Package Registry. You
[26:15] need an account on there. Once you have that, you can run. I think it might just be something like npm run publish. You have to be a little bit careful because that rewrites your read me and tries to auto-generate information from the plugin. So it's useful to to run that first and make sure it's correct. Because I've had a few go out that had the wrong information. Then. But once it's installed there, once it's available there, once it's published live, and if you look at mine, you know if you search for mints or for bbsfdx on npm, you'll see some examples there. You can just at the sfdx salesforce cli, you can just run sfdx plugins colon install, then the name of the package on node, and that will install. It'll give you a message to say that it's unsigned. In my case, because I don't bother signing any of it, because it's mostly for my use. Yeah, and then you can install it, and then it's good to go. So for distributing my plugins internally to the rest of the company, I've created an organization and I publish the plugin up there, and everybody just installs it. It's very cool. It's very simple. You don't really have to care about what's happening. So you can restrict the plugin availability to your internal people in the company. So you can. That would be a paid organization. I've just gone with an organization, and I push because there is nothing in there that's company sensitive. It's all just code that I've usually written myself as a community thing, and then I decided it would be useful within BrightGen, so I pull it in.
[27:46] I just put it. I put it into an organization just because it's easier for people to make sure they're installing the right thing because it means that all of my plugins are prefixed with that BrightGen, so it's very clear. I got it. Um, one more question. I still want to ask you: Is the Visual Studio Code? I don't know. Are you using Visual Studio Code or using Lumira Cloud? No, no, I'm I'm Visual Studio Code. I switched over as soon as I could, really. Okay, and the main reason I switched over is because it's driven by the Salesforce CLI. So all of the interactions with the the target org will all be delegated through to the Salesforce CLI, and then that will manage the the actual interaction. So once you've written a plugin, you can extend VS Code using a tasks.json file to execute your specific ones. Tie that to a To a keyboard shortcut, if you want, but the fact that VS Code is basically delegating everything to the Salesforce CLI, I think, is why the CLI continues to iterate and get more and more functionality because it effectively is what's underpinning all of the Salesforce developer tooling that they're making available. So, yeah, it's and that to me, that's I know that I know you had I think you had the Illuminated Cloud guy on one of your podcasts a little while ago, which I listened to. So I certainly know there's other tooling out there. My view is that I tend to use the Salesforce tooling because that's what most people are going to be using, and that's the one that I want to help improve if I can. Indeed, and also the the team who's making this
[29:16] official plugin in Visual Studio Code they did a fantastic job. They did keep keep pushing the the features out, and they ask opinions in Twitter. So I really love what they are doing. They also are running it kind of like an open source project. So if you hit problems, you can raise issues in GitHub, and they get onto them from there, which is a different experience, shall we say, from what is the case in Salesforce support. Yeah, you know that's exactly you mentioned. And in a good era, yeah, I joined just two years ago. Everything started happening here. Did you're very lucky? Yeah, on the right direction. But what does Visual Studio Code do for those UI-related commands? So they are just kind of wrapping the Salesforce CLI under the hood, right? For example, if I create a scratch work, there's a command in Visual Studio Code. I can just run. Absolutely. So they'll expose the Visual Studio command with a number of typically a number of parameters. So you'll have found that if you do create a new scratch org, then it'll ask you some questions, and your response to those will will. Change how it actually executes, and again, that's surprisingly easy to do using a task JSON file. We've got a script that creates a scratch org and then does more. It installs a load of data, it assigns some permission sets, it runs unit tests. So it needs some additional information. And through a just a simple tasks configuration
[30:47] file, as long as it knows where to find that script that wraps the plugin, we tell it what parameters we want to catch, and it then goes through that questioning process with the developer. So it's it's really cool, really cool. You can extend it and not just through SFDX plugins. But that's a Visual Studio Code feature rather than. Yeah. Okay. Absolutely. I got it. Very cool. Yeah. A lot of things I still need to learn. I mean, Visual Studio Code is a monster now. There's so many features. Yeah. Yeah. Yeah, it's. I went and looked at some of the source code on the Microsoft GitHub site, and well, yeah, there is a lot there. Yeah, it's multiple years. So, how about like the things that do you think can be improved still in Salesforce CLI? That do you expect it's coming maybe in the future to help you facilitate you as well?
[31:39] Yeah, so I think the the data aspect of things it would be, and I understand that how that's really difficult when you've got a complex tree of data. People are probably going to have to do something to indicate how they relate to each other. Otherwise, there is a huge amount of work going on the CLI team. I think it would be really nice is if there is a way for it to figure out what has changed between what's been what's in the org and what's on your local file system. So, it could be through the the source tracking API, the same as scratch orgs, where it keeps track of everything locally and remotely. The way I tend to do it is I just capture a timestamp of when I last deployed from that directory to the org. And I just figure out what files have changed in that time and build up my own package.xml based on that. I know there's various ways of doing it. It'd be quite nice, I think, if there was one that got standardised on that we all used rather than the fragmented approach that we currently have. Okay. Okay. But by the same and the other thing that I'd still really like is the which they have alluded to, and I know it's on the roadmap, is the ability to hook into their commands. So basically, to say with a deployment, I want to run this my plugin command before you do a deploy, and then I want to run this other plugin command depending on the outcome of that deploy. So I want to hook in. But not having to wrap it, not having to effectively run their deploy command and then run some additional commands myself. I'd like mine to go
[33:09] in there and be part of the same transaction. Kind of like a trigger framework here. Yeah, and and the Oakleaf CLI that it's based on does support that, but it's not fully exposed to us at the moment. And it's one of those things where I could start doing some stuff, but then I don't want to in case it all changes underneath me. I get it. All right, thanks, Keir. I think it's the time for us to round up our session. So, do you still have more stuff you still want to share with the listeners?
[33:40] Let me think for a moment. Let me just. First of all, you have the Dreamforce talk coming. I didn't know that. Yeah, yeah. So I do have a Dreamforce talk, and that was only confirmed yeah a week or two ago. So this is about testing your user interface with Selenium and Node.js. So I've always liked Selenium, but I always ended up having to write a lot of Java code, which meant I had to build the Java code, which meant I had to remember how Java worked. So I I used it less and less until I discovered the Node bindings and I'm using Node for all sorts of things. So that was really quite a nice thing to get involved in again. Yeah, so I'm giving a talk about that, which I wouldn't necessarily say is maybe the way you should do it, but it's certainly an option for doing simple user interface testing. It can get really complicated really quickly. But yeah, I have that. The other thing I'd say when people are thinking about Salesforce CLI plugins is it's it's very easy. To get caught in the view that this must interact with a Salesforce server in some way, shape, or form, it must be updating data, it must be deploying something. But actually, it's just a really nice way of deploying functionality to your user to your developers if they're all using the Salesforce CLI. It's a really nice way of dropping in something that they all need without having to worry too much about setup. So I've got some stuff that allows us to access documentation. I've got another one that can generate. A set of initial files for an offline mobile application.
[35:10] So nothing necessarily to do with Salesforce. It's just a really nice way without having to distribute scripts and get people to have other things set up. You know, if you can run as an SFDC plug and it will run on their machine. Okay. Good to hear. Good to hear. All right. Thanks a lot, Keir. It was great chatting with you today. Thank you, Shae. It's great to meet you. Be delighted here.
[35:42] Oh, oh, oh, oh, oh, oh, oh, oh, oh
[35:55] Oh, oh, oh, oh, oh, oh, oh, oh, oh
