In this episode, I’m talking with the CTO of BrightGen, Keir Bowden. We sit down and discuss the different tools you can use for automation and testing, including Keir’s own Salesforce CLI plugin. We also talk about the frequent role JavaScript plays in these tools.

Keir worked for a number of startups before finding his way to BrightGen. He first worked with them on a Java implementation and later got involved in their partnership with Salesforce. Tune in to hear his experiences and insight around Salesforce CLI, JavaScript, Selenium and more. 

Show Highlights:

• How Keir got into the Salesforce world.
• Suitable users for the Salesforce CLI.
• The main tasks he uses the CLI for.
• What compelled him to write the Electron UI and how he got it up and running.
• An elevator pitch for the plugin he wrote for the CLI.
• What the Heroku framework is.
• What kind of tests are run with Selenium.
• Tips for working with a more asynchronous user interface.

Links:

• Keir on Twitter: http://twitter.com/bob_buzzard
• Keir on LinkedIn: https://www.linkedin.com/in/keirbowden
• Keir on Github: github.com/keirbowden
• Keir’s Blog – http://bobbuzzard.blogspot.com/
• NPM – https://www.npmjs.com/~keirbowden
• Dedicated page on blog for Documentor Plug-in : https://bobbuzzard.blogspot.com/p/org-documentor.html

Episode Transcript

Keir Bowden:

We had to get a new developer set up. It used to be about four days because we had to create a developer edition. And then we had to ask support to enable a number of additional features. Then we had to do various deployments, and there always seemed to be something slightly different, slightly unusual that just made it a really painful process. And that’s including deploying, setting up sample data. It’s 15 minutes to the [inaudible 00:00:27].

Josh Birk:

That was Keir Bowden, CTO, BrightGen. I’m Josh Birk, a developer evangelist for Salesforce, and here on the Salesforce Developer Podcast, you’ll hear stories and insights from developers for developers. Today, we sit down and talk with Keir about a variety of tools that you can use for automation and testing, including the Salesforce CLI and Selenium, and the role JavaScript plays in those tools. But to begin, we talk about his early days with computing, which had a little bit to do with video games.

Keir Bowden:

I found this in my loft about a year ago, we bought between about three of us Basic Computer Games by David Ahl. There was a 32,000 line listing for a Star Trek game that me and a couple of my friends did over a week of the summer vacation. And it didn’t compile, obviously. It took us months to actually get the thing working.

Josh Birk:

Right. Exactly. Exactly. But I do like there’s this trend, and I’m trying to remember, I think it might’ve been [inaudible 00:01:20], but there’s a lot of people who got into software design because they could build their own game out of it.

Keir Bowden:

Absolutely.

Josh Birk:

I don’t think I really considered myself to be a halfway decent programmer until I started doing unreal engine bots. And that’s actually how I learned object oriented programming and how OO code actually really started to click for me. Okay, cool. So then how did you get into the Salesforce world?

Keir Bowden:

By fluke really. I worked for a number of startups over the years. I was involved in the original dot com boom and bust. And outside of that, I have quite a background in . So I’d kind of gone back to Fintech after the dot com bust, but not really wanting to. I was more interested in the whole kind of e-commerce business systems over the internet, et cetera. And I basically, well, weirdly, I left the Fintech job I was in and joined another startup, which was using a database that Michael Stonebraker, the guy that invented ingress and various other things, had come up with where the data was a stream rather than querying the record. You’d run a query and you would get real time updates as things came in. So very useful for distributing rates around the trading room floor.

Keir Bowden:

And so I went with them for a while. And again, a masterpiece of timing. We had a couple of big customers that would have put us in a very firm footing. And this was around the beginning of 2008. Then if you remember the financial crash of 2008, we time that beautifully. And then I was just looking, I just thought I don’t want to commute to London anymore. I just want a local job. And that’s all I was looking for. And I joined BrightGen doing service management on a Java, three tier Java implementation. But they were also Salesforce partner. And then, yeah, I just got involved in that because I looked at it and thought, well, this looks like fun. Looks like I can do things quicker.

Josh Birk:

You just sort of became the Salesforce guy.

Keir Bowden:

Absolutely.

Josh Birk:

Nice. And then describe your current job to me.

Keir Bowden:

My current job has a number of facets to it, I think like a lot of technical leaders. So my main responsibility is around development of IP. So we have a media product, Brand Media, which is used by a number of large publishers around the world. We’re also working on some event management type stuff at the moment. So that’s my kind of day-to-day. Those are the teams I run. But I also describe myself as a lender of last resort for any problems in Salesforce that people have. So eventually if no one else can solve it, it will make its way up to me, and suddenly it’s my problem, and I have to fix it.

Josh Birk:

So you carry the title of CTO, but you have obviously C-level work, but you’re also kind of the go-to solution architect.

Keir Bowden:

Exactly. Yeah.

Josh Birk:

Well, at least you still get to keep your hand dirty then.

Keir Bowden:

Yeah. That’s the key thing. I do like to remain hands on. I think I would do that anyway even if I had none of that in my job. I think I would still write programs. I would still build CLI plugins, and I would still publish those in some way, just not through my work.

Josh Birk:

I feel like once you have that bug, the thing that drives you to put machine code into a computer so that your paddle will move faster. You never really lose it. Like I had a boss, Chris Frye, twice over we was my boss, and he once he got to VP level, he would find any excuse to code something. We’d be around the coffee table, and somebody be like, you know what we need? We need a media server so that we can share music with everybody around the office. And three days later, Chris would have built it because that was an excuse to go build something.

Keir Bowden:

Well, some of my colleagues say the way to get me involved in something if they want me to help is to peak my curiosity. So don’t just make it obvious, just say, well, that’s a bit weird. That should never happen. And then I just can’t help myself at that point in time.

Josh Birk:

I love that. That’s not reverse psychology, but it’s lateral psychology to a certain extent.

Keir Bowden:

Exactly.

Josh Birk:

Nice.

Keir Bowden:

It works on me, anyway.

Josh Birk:

And you are a certified technical architect.

Keir Bowden:

I am indeed. Since, when was that, it was 2011. So I was on the beater of the multiple choice, but I couldn’t get on the beater of the review board because those are all taking place in San Francisco and they wanted people in person for those. So I did it shortly after it went generally available, but because I’ve been on the beater, I still got cut some slack on the fees. So that was quite important.

Josh Birk:

Have any advice for anybody going for their CTA?

Keir Bowden:

The piece of advice I always give people is get involved in pre-sales. That’s just great training for it. Preferably with someone that doesn’t really want Salesforce and is hostile and arguing with everything you’re saying because that’s-

Josh Birk:

Really?

Keir Bowden:

Yeah. That’s how it used to be. Back in 2010, 2011, you didn’t have the kind of welcoming IT teams that wanted Salesforce. It was still this is shadow it. This is going to take our jobs away. So you’d have to persuade them that it was a good thing. And then they would challenge everything you said. Well, how can you do that? And that’s really good practice for going in front of the review board and being asked explain this decision, back this decision up.

Josh Birk:

That’s fascinating. I was doing workshops around that time, and there was always that one person in the room, usually in the front row, usually staring me down every minute of everything I’m saying, and then he’d be the one asking, what’s your Oracle stack like. And you’re like, I get it, dude. You’re scared. This is a brave new world, but don’t worry about the database right now. And I could always find, back when we would get the survey results, and there’d be the one that was like, the way you described it actually it was pretty good. The description would be something like this is shadow IT. And I’d be like, no, that was a row one, C3. I know exactly what that guy was talking about.

Josh Birk:

Cool. Okay. First of two main topics I want to talk to you about is your work around the Salesforce CLI. What was some of the early stuff you did and why did the CLI click for you?

Keir Bowden:

So obviously I’ve been around the block for a while now, and I used to do an awful lot of stuff in the command line when I worked on Linux systems, because that was really all we had. We had VC 100 terminal emulators. We didn’t have much in the way of a GUI. So we would script things, and we’d run them in the background and then we would check on them. So kind of handing off work to another part of the system through a command line interface is something I was very familiar with. Hadn’t done much of it for a while. And really for me, it was when the full stop com CLI came out. That suddenly really helped in terms of being able to do things like automated deployments, et cetera. And I know you can do that Anne, but always with Anne I was having to write plugins and express things in XML. It was always a little bit clunky.

Keir Bowden:

Force.com CLI, suddenly I could put them into bash scripts. So I did that. I wrote a lot of bash scripts and found out that I was the only person in the company that knew bash. So I’d created a nice bottle neck with my new DevOps. And I think what flipped me away from bash is when I needed to process adjacent file. Probably could have done it. And bash isn’t great at functional decomposition, and it’s not great at putting complex business logic in. So I just started looking around for how other people were doing it, and lots of people were doing it in node.js. So I thought that’s useful. It’s JavaScript, all is coming along. So it looks like JavaScript is going to be the future. I can learn some stuff about it. Never really looked back and then built a whole ton of stuff on the force.com CLI.

Keir Bowden:

And then Salesforce said, “Hey, we’ve got this Salesforce CLI.” So rebuilt a whole ton of stuff and had to support both because we had some things that were impossible in the Salesforce CLI when it first came out. Gradually migrated across. But yeah, the reproducibility of how people were deploying making that. Everybody would do it the same way ad infinitum really appealed to me.

Josh Birk:

Yeah. I mean, I think there’s a couple parts there. Part of it, I’m also an old school bash scripter, and I’m seeing the code that you’re talking about. It’s the really ugly string wrangling in the middle of your bash script that you just scroll past because you’re just trying to get to the end result kind of thing. And I did the same thing. I started moving to node for any of the command line stuff I was doing, partially just because node’s taking over the world, right? If you want to get something done, there’s usually something easy to do in node. And so I think I had a very similar transition. Now, I want to talk specifically about some of the plugins that you have written, but kind of as a side note, based on your experiences with both Salesforce and the CLI, who do you think are suitable users for the Salesforce CLI?

Keir Bowden:

So I think your kind of core demographic is likely to be developers. People who are deploying things, people who want to apply the same changes across a multitude of environments. But I personally think admins should be able to get to grips with this as well. Admins can write formulas. People always want shortcuts. They always want repeatable ways of doing things. And one of the things I always go back to is if you give a user a sequence of keys they can press to create a new opportunity rather than clicking through three or four buttons, they’ll probably do that sequence of keys. So people like shortcuts. They don’t have to necessarily understand exactly what’s going on under the hood. But if you can build things for admins, et cetera, then you certainly should, because it will make their lives easier as well.

Josh Birk:

Yeah. I mean, I think that’s interesting because we come in from it from a functional programming point of view that’s very similar to the CLI, and it’s come up a couple of times on the pod where we talk about declarative and we talked about no code, but there’s an aspect to it where it’s almost visual coding or functional coding through a wizzy wig kind of thing. There’s still logic, there’s still variables and there’s still an outcome. And that’s stuff that can be translatable if you’re trying to get some stuff done with the Salesforce CLI.

Josh Birk:

And I’ll also say, I think the Salesforce CLI has made me a better admin because I’m using permission sets correctly now. I don’t think I ever did before until it was just very easy to scratch org user perm set, go kind of stuff.

Keir Bowden:

Yeah. Yeah. I mean, we used to, when we first started the media project, which was a number of years ago now, we had to get a new developer set up. Used to be about four days because we had to create a developer edition. And then we had to ask support to enable a number of additional features. Then we had to do various deployments, and there always seemed to be something slightly different, slightly unusual that just made it a really painful process. And now it’s including deploying, setting up sample data. It’s 15 minutes for the scratch org. It’s changed things beyond recognition.

Josh Birk:

Right. And then sticking with the vanilla CLI, what are some of the other main tasks that you use the CLI for on the regular?

Keir Bowden:

Opening orgs. I’ve got a lot that I do within the community. So I’ve got a load of developer additions that have got various bits and pieces in them. I’ve got the BrightGen orgs, and sometimes I’m going into other orgs. I’ve got demo orgs for the media product, et cetera. So just being able to open those from a single place without having to maintain a list of passwords somewhere that I have to remember which org it is I want to log into. Being able to supply nice alias. I use that enormously. I use it to run tests, deployments quite a bit, scratch orgs and packaging.

Josh Birk:

And how are you finding some of the new packaging? I honestly, at this point, I think we’re still calling it next gen packaging or unlocked packages, I guess, is the latest term.

Keir Bowden:

Yes, I’ve used all of them now I think. I’ve used the org dependent packages in beta, which I’m really excited about the idea of being able to package up code that doesn’t have to be logically complete in its own right, but can rely on something being there when it’s installed is really helpful to me in a few situations. So that’s very cool. I’m really enjoying that. unlocked packages I’m already using. We’ve got that in a couple of places in our media system as a way of deploying something. Here’s the standard. But if you do feel you need to customize it, then you can take ownership and you can take control. I’ve also used the second gen managed packages for a couple of things, one of which is on the app exchange. That’s in our media lightening bolt.

Keir Bowden:

And the other one is our event management lightning bolt, which is currently going through security review. And again, I have to say, I find it so much easier because I’m doing it all from the command line. I’ve got my commands. I know exactly … Well, actually, I’ve built myself a little GUI on top of it using electron. So I just press some buttons, type in a bit of information and then it goes away and does all the packaging for me, gets it ready to be listed on the app exchange. And it’s all boiler plate staff. So having to log in, remember which org to log into, et cetera, it’s so much nicer doing it through the command line.

Josh Birk:

Okay. So I want to get into your plugin, but I actually did have a question down the road for that. So we’ll just go ahead and skip to that. So first of all, what compelled you to write that electron on UI? And second of all, how complex was that to get that up and running?

Keir Bowden:

So I played around with another GUI front end onto one of our bash scripts that did deployment when I first created that with the force.com CLI, just because it took 15 minutes and I didn’t want to sit there and monitoring something. So I just had something that I could press a button, it remembered all the parameters. That was very clunky, and I wasn’t really very interested in it apart from getting it to happen. But I kept reading about electron, and I kept having a little dabble in electron thing. And this looks like real fun. I couldn’t think of anything to do with it. And then I thought, you know what? I do a lot of the same CLI commands, just opening an org. So what I’d really like to do … and I’m logged into like a hundred different developer additions and scratch orgs, et cetera.

Keir Bowden:

What I’d quite like to do is just show me the list, I can click on the list of orgs, type in some information, it finds the org for me, press a button to open it. And that’s where it started. And electron is just such fun to work with. It really is. Everything just seems really easy, really straightforward. I would recommend anybody, if they want to get better at JavaScript and node, electron’s a really good place to start because it is just so enjoyable.

Josh Birk:

Well, for the uninitiated, what is electron?

Keir Bowden:

So electron is basically Chrome and node combined. I think I’m right in saying it came out of Git Hub. I think it was one of their developers who put it together.

Josh Birk:

That sounds right.

Keir Bowden:

So effectively, you can build desktop applications using web technologies. So it’s got an embedded Google Chrome, so as long as you can do web pages, they will just display. You write all your business logic in node. And you kind of treat it like a browser. You’ve got these pages. But unlike a browser, you can communicate between those pages and with the operating system, et cetera, because you are on the desktop.

Josh Birk:

So it’s like an encapsulated HTML5 client to server app.

Keir Bowden:

Absolutely. And VS code is built in electron for example. So it’s got quite a good pedigree as well.

Josh Birk:

VS code is built, really?

Keir Bowden:

Yeah.

Josh Birk:

See, now my mind is a little bit blown because I went from the whole VS code is this cool desktop app code builder, is an emulated version of a desktop app, and that makes it so much more cool because it’s not an HTML5 app, but now I’ve learned it actually kind of is.

Keir Bowden:

Yeah, I guess that makes it relatively … I mean, there’s obviously still going to be issues, but I guess the fact that it is all built using web technologies probably makes it easier to take it to the web.

Josh Birk:

Nice. Okay. So then back to your CLI, or to the CLI, but when did you first think I should write a plugin for this?

Keir Bowden:

A long time before plugins were generally available, sadly. But to be fair, plugins were always on the roadmap because it’s all built on the Heroku Oclif under the hood, so they support plugins. So when I was looking at that, I thought this is going to be brilliant. I can do away with all my scripts basically. And I can put in custom commands. It doesn’t have to be doing anything with a Salesforce instance, even it can just be doing something on the user’s desktop through node.

Keir Bowden:

And that struck me as a really, really useful thing to distribute my bash scripts, et cetera. There was just some scaffolding that had to be put in place. And when you’re trying to get functionals to do that, it’s a bit more tricky because they’re not familiar with necessarily installing things through NPM, et cetera, and no package manager. Whereas with the plugin, everybody’s got SFDX installed on their machine because we use it for a number of things outside of just regular programming work. So I just run this command from your command line and you’ll have my plugin. It’s distributed at that point in time. So that’s a game changer again for me.

Josh Birk:

Yeah. And what would you say is the elevator pitch for your plugin?

Keir Bowden:

For the org document? I mean, basically, it’s a way of extracting information from your source code. You don’t have to go anywhere near a Salesforce instance. Basically, if you just want some information that’s human readable, this will give you some of that.

Josh Birk:

Like give me an example.

Keir Bowden:

So originally started off wanting a data dictionary. So I got fed up with people documenting things out of Salesforce into word documents or Google docs that then were out of date almost instantly. So then I kept saying, we’ve got the metadata. There must be a way of doing this. And in the end I thought, well, there must be, so I’m going to do it. And I did that originally just as a node script, which wasn’t even wrapped around the force.com CLI, but you could use the force.com CLI to pull the metadata back.

Keir Bowden:

So just walk the metadata. And I guess where it probably may not work for for a production instance, for example, is it won’t bring in all the package metadata that you’ve got there. It’s purely your version controlled source, which for me in a product environment is perfect because that’s what I care about. So I just wrote some code. And there were some interesting problems to solve because it’s all in XML. So that’s not very helpful when you’re in JavaScript. So turning XML into JavaScripts and at the time there was only asynchronous ways of doing it, and there’s nice synchronous ways of doing it now. And then producing the HTML. That was an interesting challenge as well. But that’s really where it came from was just like, I can’t keep doing this manually. There has to be a better way.

Josh Birk:

And what kind of color does the plugin provide onto the documentation? Does it give any kind of opinion about the data that it’s creating into the dictionary?

Keir Bowden:

Yeah. So one of the things that I was originally trying to draw out was the fact that sometimes new fields are going in without any description, and this is a really bad thing. But a data model is like 180 objects and there’s an awful lot fields underneath that. So there is an awful lot to sift through, especially through the Salesforce app page. So it was difficult to spot whether that happened. Whereas now you can look at the HTML page and if there’s a missing description, it’ll flag up in bright red, and if there’s a to-do in there, then it will flag up in yellow because you still have to do that, or you should remove the to-do because you shouldn’t leave it in there for it to end up on customer sites.

Josh Birk:

Got it. So it’s almost like, I don’t want to say static code. It’s like static data analysis to a certain extent.

Keir Bowden:

It’s trying to enrich a little bit. It will still pull rather than just referencing say a value set, for example, it will go and pull that value set and put the details of what the value set are for a pick list. So you don’t have to go and manually pull those things across, but it just does a few little bits and pieces like that. Mostly it was initially done because there was something that would make my life interesting. So it might make my life better. But also it was really interesting. So it was interesting challenges. And that’s often what keeps me going on these more community driven projects.

Josh Birk:

Well, I think that’s core to the developer philosophy of you would rather spend 20 hours putting together a project that’s going to save you five minutes the next day.

Keir Bowden:

Absolutely.

Josh Birk:

So on a scale of one to five, how complex would you describe writing the plugin?

Keir Bowden:

I don’t think it actually is enormously complex once you know what you’re doing. So I think the first iteration was really hard because I had no real idea of how to … I mean, when I was doing it, I hadn’t been doing the original version. I hadn’t been doing Java script for very long. So I had no real idea of how you could iterate across the properties of an object in a sensible fashion without picking up all the kind of prototype stuff that you don’t care about. And I had no idea really about an awful lot of the functionality that was in there in node. When I go back to it now and look at it, yeah, it’s like … And I’ve re-factored a few things as well as time’s gone on and things have gotten easier.

Keir Bowden:

There isn’t a huge amount of complexity there. It’s really, I guess the only little bit of complexity is the fact that you can break up the custom objects, for example, you can bucket them. So in our media, when we have booking objects and our pricing objects, so there’s a slightly deep JavaScript structure that’s built up based on here’s my type, which is custom object, because it also supports triggers and a few other bits and pieces. Here’s my type, here’s the groups. And inside those groups, here are a bunch of objects. And inside those objects, here are a bunch of fields, and these fields may have additional attributes on them, et cetera. So building up with that is a little bit more tricky. And when that was all generated asynchronously, that did get a bit complex because of keeping track of where things are going. Whereas now there are things like fast XML parser, which would do it synchronously for you and spit you out some JSON. That simplified things enormously.

Josh Birk:

Yeah, because I put together, it wasn’t a plugin, it was just a node, CLI app. But it was basically something that found all of your visual force pages and then ran them against the linter to warn you if it goes, oop, wasn’t going to be LWC compatible kind of thing. It was a VS scanner, I think it was called, but it actually got pulled into the readiness project. They actually told me to take down my Git Hub project because they’re like, basically, we’re making your code official and I think better might’ve been the way they put it. But I ran to that in asynchronous problem because it’s like, every time I’m pinging for what does this visual force page have in it, then I don’t know when it’s coming back. And you have to, I think I had a counter, it was just like, okay, I sent out 232 pings, so I am just going to sit here until I get 232 responses, and then I will give you your report back.

Josh Birk:

So it’s weird because asynchronous is always kind of preferred, but then yes, there’s always these situations where it actually, might be a little slower sometimes, or I guess in processing or something like that, but sometimes it’s just so much simpler from a logic point of view.

Keir Bowden:

Absolutely, especially when you’re writing command line type things, where going sequentially doesn’t really matter to most users.

Josh Birk:

Right now. You mentioned Heroku Oclif. Could you describe that to people who aren’t familiar?

Keir Bowden:

So I wouldn’t say I’m enormously familiar myself, but as I understand it, that’s the Heroku framework for building command line interface tools. So a lot of the things like plugin support and hook support provided by that framework. And then they just have to be exposed through the Salesforce CLI. So it was nice to be able to go and look at that from time to time if something wasn’t working, go and look at how Heroku actually does it. And then think, I don’t know anything about JavaScript, it turns out. I cannot read a single line of this. Yeah. But it’s an interesting thing to go and look at it because the Salesforce CLI effectively is built through plugins to a CLI, which is a bit of a [crosstalk 00:23:51] .

Josh Birk:

Just all the plugins that you get for free when you actually install the the Salesforce CLI, yeah. And it also provides that nice, there’s that strict syntax to it. So when I download your plugin and I’ve used the plugin that like Dave Carroll wrote, then the overall way that I interact with that plugin is relatively the same.

Keir Bowden:

Yeah. So it’s typically a lot of the ones that I look at, Shane McLaughlin’s, he’s got a plugin that does absolutely massive things. I look at that from time to time to see how he’s done certain things. And I find that reading someone else’s plugin code is actually relatively straightforward.

Josh Birk:

Nice. Now people can install it directly from the command line, but you also have a repo up in case anybody wants to go tinker with it, correct?

Keir Bowden:

Absolutely. Yeah. So I think a couple of people have cloned it, which is nice. We have got one extension, or somebody has extended it to put in some data model diagrams, but unfortunately we can’t get that working on the Mac at the moment. So you’re working on Linux. So that’s my co-leader of the London, Salesforce developers, Todd Halpenny, that’s done that.

Josh Birk:

Nice. Very nice. Okay. So second of two main topics, UI automation with Selenium and node.

Keir Bowden:

Yes. Again, node crops up again.

Josh Birk:

Again, node. JavaScript’s taking over the world, right? You can’t get away from it. There was somebody online who was like do I have to learn JavaScript to be a full stack developer? And I’m like, well, it’s on the client, it’s on the server and you can do an entire database, data model, and data format with it. So maybe you might want to. Okay. So first let’s level set, maybe some people aren’t familiar with Selenium. What kind of tests are these? What kind of things are you testing for?

Keir Bowden:

So, well, I mean, just to just take a step back from that, Selenium’s job is it automates browsers. That’s all it does. It gives you an interface that from a programming language, you can make the browser do some things. And then you can look at what happened. Probably 90% of Selenium use is tests. I mean, I also use it for just some automation that I need to go and hit some websites and do some certain things on a regular basis. So I got that running out of AWS as well.

Keir Bowden:

But the kind of tests I was doing. I mean, in all honesty, you can get so much value from something very simple in terms of your testing. Like, can I log into Salesforce? And I would say, if you were an admin and you got a bunch of users and some of those users struggled to log in and they tell you that Salesforce is down, if you set up something that happens while you’re driving to work or whatever that checks that you can log into Salesforce, you’ll be pretty comfortable that Salesforce isn’t down and that’s all been intimated and you just get a notification. You don’t really have to do much work to achieve that. I mean, there’s obviously relatively limited value, but it can help.

Keir Bowden:

The sort of things I was doing was, there’s the standard Salesforce stuff, which is around obviously I was creating opportunities, et cetera, and kind of going through the various field types, look ups, pick lists can introduce some challenges in terms of interacting with the browser. But I’ve also got some really heavily customized pages. So they do present a bit more of a challenge in terms of they’re extremely reactive, so large chunks of the page will change or disappear or move elsewhere. So that’s quite useful to be able to test with Selenium as well. And quite hard to test with Selenium, I should say.

Josh Birk:

Okay. So a couple of things on that. First of all, that’s an interesting way that you described it because you kind of actually put in a spectrum of tasks there. Some of it is testing. Like positive tests, yes, my page is doing something I expect, like has a login button that can be used. But then also a bit of automation, almost like a dev ops style. I can go through the opportunity flow or I can go through a wizard flow. That’s interesting that you can use it for quality of life tasks that’s first a red flag, green flag kind of thing. But also getting this task done a lot easier.

Keir Bowden:

Yeah. I certainly used to, not so much now, I think because the CLI has exposed so much and scratch orgs have exposed so much that I used to have to do manually. But Selenium is a good way of doing setup, reproducible set up. If you want everyone to do the same thing, you can give them a Selenium script written in node that will fire up a headless Chrome, do what it needs to do to their Salesforce instance. You just get into interesting things, like if you’re coming from an IP address it doesn’t recognize and it wants you to send a verification code, which is a bit hard in headless Chrome, a few things like that. So you can use it for set up. You can use it for testing. Or you can use it if there’s just things that need to happen. If you want to just create some data that something else is then going to pick up and deal with at a later date.

Josh Birk:

And I think you started touching into this a little bit, but how does node.js itself play into Selenium?

Keir Bowden:

Yeah, so Selenium has a bunch of language bindings that allow you to control a browser through an API. Really you just run commands. You just say open this page, look for this element on the page and wait up to 60 seconds for it to appear, for example. So Java has been around for years and that’s what I used to do it in, and I found it a bit clunky. And then when I came across bindings, again, I was in there because I know node quite well. It’s an interesting one, the node bindings, because I don’t know if this is the case now, but when I started using it a couple of years ago, they used a promise manager to handle the asynchronicity, which introduces some additional challenges because all of your code looks synchronous, but actually it isn’t. You’re just basically listing out some commands that will all be run at a later time. So that did make life interesting when you want to look at what’s happened and maybe interact with it a bit more.

Josh Birk:

Right. And I guess kind of a follow-up question there, a lot of the modern framework stuff that we’ve been working with, lightning web components and the such, they are components that are being loaded asynchronously onto a page. So how does Selenium work with that? And are there any tips and tricks to working with a more asynchronous user interface?

Keir Bowden:

So Selenium, I must say I haven’t looked at the Selenium for a couple of months now. Selenium wasn’t handling the shadow dom for you. That was one of the problems. You didn’t have to do a lot. You just had to write a couple of lines. Effectively, you had to inject some JavaScript into the page and then run it, and that would allow you to access the shadow dom route and then go and look at the components that were in the shadow dom.

Keir Bowden:

A big challenge with Salesforce around lightning web components is the sheer churn of the pages. So you’ve got lots of things that used to be aura that are now becoming lightning web components. So their interface has changed the elements, the HTML elements that you’re looking for have changed. And also, the web component framework in general is moving on. Salesforce is adhering to it. So again, things change. It’s one of the things they always say about automated UI testing. It’s one of the best things for checking all of your moving parts are working well together. And it’s one of the hardest things to maintain because everything changes all the time.

Josh Birk:

Right. Yeah. You’re basing something off of a CSS style or class, or that was a div, now it’s a span. And obviously you’re working within a structure which is largely not in your control since most of the user interface is actually being done by us.

Keir Bowden:

Absolutely.

Josh Birk:

How are you finding lightning web components themselves?

Keir Bowden:

I really like lightning web components. Again, I think it’s the JavaScript aspect of it. It feels a lot more like I’m writing proper JavaScript now. I didn’t dislike aura components, though I think they suffer a little bit by comparison to lightning web components. But if you go back to that, we had visual force and JavaScript remoting, so aura was definitely an advantage compared to that. But with lightning web components, it feels like when I write some code, I’m writing small snippets of really useful code rather than lots of boilerplate code or lots of markup to wire things together. It feels like a lot of that’s been taken away. And I’m loving the wire service as well. The fact that I don’t have to try and orchestrate this initialization of data from Salesforce. I just basically say, this is what I’m looking, this is the method that I want to call when something changes, and here’s what I want to put the results. And then away you go, Salesforce platform, handle that for me.

Josh Birk:

Right. Yeah. I completely agree. I mean, I think there’s a little bit more cleanliness on the client’s side, but a lot of the component structure there is actually pretty similar. It’s really when you start looking at the service side classes. I think you put it well. They’re cleaner and they’re leaner. And I feel like I can read them a little bit more easily, even though as an old school JavaScript guy, I still kind of have to force myself to put Epic script, what are we on five now at this point? I’m like, this looks a little bit too much like Java to me. And then another side question, are you looking forward to code builder?

Keir Bowden:

Oh, yeah. No, I was very excited about code builder, and I did try and twist all the arms I could find to try and get on the pilot, but that didn’t happen. Typically I find that if it’s one that where you have to go through your account executive, we just don’t have the license count required to get in front of anybody. So that’s always a bit of a struggle.

Keir Bowden:

But then I went in and looked at a bit more about what it was built on, so Microsoft code spaces and thought, well, what is actually going on under the hood? I mean, obviously Salesforce is going to take a lot of the pain away of setting it up, but perhaps I could go through that pain myself. So for our TrailheadX Global Gathering, because I couldn’t show people code builder, I could show them the same thing being done through code spaces. So I signed up for an Azure account, spun up a virtual machine and had a Microsoft code spaces running, installed the Salesforce CLI and my plugin, and then kind of had two machines a bit like Rick Wakeman, two keyboards. I did something in one machine, and then I think the thing that people didn’t realize was it is a virtual machine in the cloud as well. So I could show a command running on one machine, and then I can see the output on the other machine. It’s all as is. It’s the same session.

Josh Birk:

It’s some crazy black magic. The more I hear about I’m like, this is actually really, really cool tech.

Keir Bowden:

Oh, I think it’s fantastic because you don’t even need to be on the same machine. You used to be able to code from anywhere as long as you had your laptop with you. Now, you don’t even need your laptop.

Josh Birk:

Yeah. Yeah, exactly.

Keir Bowden:

I actually deployed from my phone as part of that testing as well. I wouldn’t recommend it, but I did make it happen.

Josh Birk:

That is awesome. And that’s our show now. Now, before we go, I did ask Keir for his favorite non-technical hobby, and I got to tell you people there’s a trend going on here, and I got to just get outside more often

Keir Bowden:

Cycling. I like cycling or exercise bike cycling, but I’ve kind of got more and more into it over the last five or so years. And it’s been invaluable during the lockdown period that we had here for getting out and getting some fresh air.

Josh Birk:

Okay. So true story. That is the exact same answer that Michael Smith will have said because he will be airing … In the magic of podcasting time travel, he’ll be airing next week as we know it, but he will be about three or four weeks by the time people have heard this. And I’m just getting so jealous because I live in Chicago and just walking around the neighborhood is a little bit stressful. Cycling, actually, I should get back into because you can go into Lake Front and kind of zoom past people basically and kind of feel safe, but I’m guessing you have kind of a nice … Do you have a nice rural countryside in order to [crosstalk 00:35:13]

Keir Bowden:

I mean, I live in a small-ish village, and if I go half a mile in a number of direction, it’s mostly lanes and fields. You do get tractors and big trucks from time to time that you have to watch out for, but a lot of the time I won’t see much in the way of traffic apart from right around my house. So yeah, it’s nothing like cycling in London.

Josh Birk:

I want to thank Keir for the great conversation and information. Of course, I want to thank you for listening. Now, if you want to learn more about this podcast, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes, and have links to your favorite podcast service. Thanks again. And I’ll talk to you next week.