Thomas Dvornik is a principal member of the technical staff here at Salesforce. He has always known that he wanted to work with computers in some way, but had a hard time choosing between computer graphics and computer science. Ultimately, he came to choose the math side of things, which brought him to Salesforce.

In the episode, Thomas and I talk about his long career working on developer tooling at Salesforce. He has seen the Developer Console morph into its current form and talks about how it and the Tooling API influenced each other.  We also talk about the role of the upcoming Code Builder and how the layering with the Salesforce CLI works. Tune in to learn all about the Salesforce hierarchy of tools has been built out for Salesforce DX.

 

Show Highlights:

  • How the old school developer console worked as a reference application for the tooling API.
  • How the tooling API works, including how containers function.
  • The shift that started with the Salesforce DX initiative.
  • How the CLI interacts when it comes to the tooling vs. metadata API.
  • The functionality and power that plugins can bring.
  • How the concept of going open source plays into the overall strategy for the CLI.
  • Some of the challenges that come with moving the CLI into open source.
  • What’s next on the Salesforce roadmap.

Links

 

Shout Outs:

Episode Transcript

Thomas Dvornik:

I was an avid gamer, so I always wanted to do something with computers. I wasn’t really entirely sure what. And so, I actually tried to go between two career paths. One was computer graphics and animation and computer science. And I think what ultimately won was, I’m just a little bit better on math than I am on that creative side.

Josh Birk:

That is Thomas Dvornik, a principal member of technical staff here at Salesforce. I’m Josh Birk, developer evangelist for Salesforce, and here on the Salesforce Developer podcast, you’ll hear stories and insights from developers for developers.

Josh Birk:

Today, we sit down and talk with Thomas about his long career working on developer tooling here at Salesforce, and to kick things off. We’re going to talk about that old school Developer Console and how it worked as a reference application for the tooling API.

Thomas Dvornik:

We really tried to keep it very much in line. There is, if anyone has ever inspected the Dev Console, will see that there’s a reference to what we call the Apex CSI API, which is really a reference to that page that it originally started out as.

Josh Birk:

Gotcha.

Thomas Dvornik:

And there was a lot of things that we couldn’t… Because every time you release an API, it’s supported and you have to support it in Salesforce terms pretty much forever. We do deprecate APIs but it’s pretty rare.

Josh Birk:

Yeah.

Thomas Dvornik:

And we wanted to move a little bit faster with giving us room to get things wrong. And so, by putting those into the API, we really had to get it right, right away. And so, the Apex CSI API was the way for us to do that, get things out there quicker and use them, and try to play around with it before we necessarily baked it into the tooling API.

Thomas Dvornik:

And so, that API still exists today, and when I say API, it’s really just an internal servlet that a Dev Console uses. And so if people really wanted to inspect it, they can technically use it. But basically, it could change at any point in time because the only thing that used it was the Dev Console.

Josh Birk:

Gotcha.

Thomas Dvornik:

So if we wanted to remove methods or change the way data was laid out, we could do that a whim. And so, that’s still being used today. There are still some things that the Dev Console does that are in that API, but in general it was essentially a reference implementation for the tooling API.

Josh Birk:

Got it. So the CSI API was never really designed for any level of support. It was really just there as a proto version of the tooling API.

Thomas Dvornik:

Exactly. Yeah.

Josh Birk:

And how does the tooling API itself work, for instance, how do containers function?

Thomas Dvornik:

Oh, that’s a deep question, and I guess I’ll preference it too with I haven’t worked on the tooling API in six years, so things change and all that.

Josh Birk:

Right.

Thomas Dvornik:

But when we first were working on the tooling API, the biggest thing we needed to do to support a browser-based editing experience was, if you think about the way the metadata API works, we’re taking metadata and we’re deploying it to the org. And at that point in time it becomes alive.

Thomas Dvornik:

And so, if you’re making a change and you save it in the Dev Console that becomes live immediately in the org, but what happens if you kill your browser or something like that, and you lost all your changes in progress? And so, we wanted a way to have this in flight status where we’re still saving stuff to Salesforce, but it may not be the version that is actually live within the org.

Josh Birk:

Got it.

Thomas Dvornik:

And this also would help us support a save all operation. And so, how the containers worked is as you worked, we were saving stuff to the container and you could have multiple of these containers open. So if you were modifying five Apex classes. We have five of these containers that are saved in the org that are ready to be deployed at a moment’s notice.

Thomas Dvornik:

And then, as soon as you did a container async request, which is to deploy that to the org, all that metadata would already live in the org and we could just take that and try to do the deployment then. And so, it was a way for us to get rid of the zip file and a way to have this in progress state, where you’re working on some stuff, and then now I’m at a place where I want to save it to the org.

Josh Birk:

And how much of that being browser-based was a complication?

Thomas Dvornik:

Actually it worked out really, really well for being browser-based. Some of the limitations with that are with doing it browser-based you’re really focusing on a bunch of small edits.

Josh Birk:

Yeah.

Thomas Dvornik:

So you’re really only going to be modifying a handful of stuff at a particular time. If you look at a lot of the more complicated scenarios with customers deploying 10,000 classes, doing that through the tooling API would be a lot because you have to do a request for each container.

Josh Birk:

Right.

Thomas Dvornik:

And for one, you’re not going to want to modify 10,000 things in the browser, not necessarily, unless they’re doing something with the new tooling, which we may get into, but-

Josh Birk:

Yeah.

Thomas Dvornik:

… but so with the small base edits in the browser, it actually didn’t introduce a lot of complications. It actually worked pretty well for that use case. But when, again, when you’re doing these large scale deployments it did cause a lot of problems on the client. And so, the tooling API was never meant to replace the metadata API.

Josh Birk:

Right.

Thomas Dvornik:

It was never meant to replace how people deploy code to production and all of that. The tooling API was more of, how do you do developmental things? Which is quite different than how you would do larger CD processes.

Josh Birk:

Gotcha.

Thomas Dvornik:

And so, the tooling API with the containers was really meant for this quicker, in flight saves to an org to help get around some of those slower or more file-based things like zip files. And SOAP operations and things like that.

Josh Birk:

So if I’m just doing an Apex class in a visual force page and doing that one scope of just application editing, it handles that really well. But I think you’re starting to answer this question a little bit. When did the shift towards the CLI again?

Thomas Dvornik:

Yeah. And the shift started with a Salesforce DX initiative, and I’ve actually done a couple of Dreamforce talks and Chillhead talks on this that I think there are a lot of misconceptions on what people call SFDX. And really all it is is that our commitment to improve the developer experience.

Josh Birk:

Yeah.

Thomas Dvornik:

So when you talk about a product or a feature or anything like that, you should never refer to it as Salesforce DX, you should never say, “Oh, I can’t move over to Salesforce DX because of X, Y, Z.”, right? It’s always a group of features, and you can usually use one tool versus another, or you can maybe start to slowly integrate a feature into your pipeline. It’s not an all or nothing catchphrase. It’s really just, we want to improve the developer experience.

Josh Birk:

Right.

Thomas Dvornik:

And so, with that initiative brought up a lot of things that we talked about internally, in terms of, how can developers have quicker [inaudible 00:07:04] environments like scratch orgs, where I can quickly spin one up and throw it away later if something goes wrong and it’s not more permanent like a sandbox? How can we have a little bit more modern tooling, like a well supported CLI or something other than Eclipse?

Thomas Dvornik:

And so, a lot of these things were questions that we were starting to ask ourselves. And really, even though we got a lot more funding at that point in time, we wanted to support the tooling in a way that would enable us to move fast and not have a huge collection of tools that we had to maintain and support.

Thomas Dvornik:

And so, that started with the CLI and doing what we call… It originally started as source-driven development, but really it’s what we call the source format, which is allowing customers to organize their metadata in different ways that the meta API doesn’t necessarily support. And so, in order to do that, that was the first initial version of the CLI.

Josh Birk:

Gotcha.

Thomas Dvornik:

And that’s what got the CLI going and being able to use that as a base bone for all the other tooling that we do.

Josh Birk:

Got it. So it turns into a one stop shop.

Thomas Dvornik:

Yeah. Essentially. So if you think about it in horizontal layers, you have the API, and then right on top of that, you have the CLI, and then on top of that, you have the VS code extensions, but now any other tool, so VS code is basically our reference implementation, if you will, for doing CLI operations or doing language server stuff. And so, the goal of this is to support these lower level tools that then can be used by the community in whatever way they want.

Josh Birk:

Gotcha. And going back to that, Salesforce DS is an umbrella term. We’re talking about CLI, we’re talking about VS code a little bit, but then there’s also important aspects like next gen packaging. Right?

Thomas Dvornik:

Yup.

Josh Birk:

And so, how does the CLI itself interact when it comes to the tooling API versus the metadata API?

Thomas Dvornik:

Yeah. And so, I think right now we have about 120 commands or maybe more and it’s growing, and more and more teams are contributing to it. We’re getting more and more external plugins and internal plugins to the CLI to build out the full capabilities of it.

Josh Birk:

Yeah.

Thomas Dvornik:

And so, the amount of commands that the CLI team owns is pretty small. The metadata commands, for example, are owned by the metadata team, the packaging commands are run by the packaging team.

Josh Birk:

Gotcha.

Thomas Dvornik:

And so, all of these, the tool has really become the Salesforce CLI for all of Salesforce and all of the development that you will do. So that’s why I like to refrain from calling it an SFDS product, because really, you can do anything with it, even things that are not, or that you may not consider part of that process, and even in terms of assigning permission sets or running queries, you can do all of that in the CLI.

Thomas Dvornik:

And so, a lot of those commands will use different parts of the API. Some of them using tooling and some of them using metadata. The metadata commands will still do metadata deploys and retrieves. And right now the source command, so source deploy retrieve, and source push and pull are built on top of the metadata API libraries that they wrote for their commands.

Josh Birk:

Gotcha.

Thomas Dvornik:

We know performance is a huge issue and we’re constantly trying to improve performance. And one of those is that sometimes deploys can be slow even for a single file. And so I talked about how the tooling API is a little bit faster in some situations than the metadata API.

Josh Birk:

Yeah.

Thomas Dvornik:

And so, we are going to be making, eventually, make changes in there where we can hopefully do smarter things where if you’re doing one Apex class to maybe do a tooling API to pull instead of a metadata API deploy, and choose which one we’re using behind the scenes to make things faster without you necessarily knowing about it.

Josh Birk:

Gotcha. And just as a side question on that, because I just did pick up on you can do things like adjusting permission sets and things like that. Previous episode with Chris Benziger, he was talking about the power of plugins basically. So is there some interesting functionality that the plugins can bring in that people might not be aware of?

Thomas Dvornik:

I would say a lot of, including some evangelists, have built some really great plugins out there. And so, there’s a lot of things missing from the CLI that customers would want in their day-to-day workflows, and so people actually went out and built it, which is awesome. Shane McMacklin who, I forget his role, if he’s dev evangelist or dev training, or-

Josh Birk:

I think he’s over in training. Shawn’s one of those, I know the name and, in fact, this is the second shout out. I think Chris gave him one too, or Kirsten gave him one too, because he’s got the plugin library, right?

Thomas Dvornik:

Yup.

Josh Birk:

Yeah.

Thomas Dvornik:

Yeah. And his plugin library is pretty big and offers a lot of additional capabilities that aren’t offered in the CLI. I can’t think of any, particularly off the top of my head, but even one. So one thing we don’t really let you do is set passwords in the CLI. We do have a user password generate command, which would generate a new password for scratch orgs.

Josh Birk:

Right.

Thomas Dvornik:

But just because security didn’t really want that because we don’t want people to get in the habit of setting passwords in the CLI.

Josh Birk:

Right.

Thomas Dvornik:

Especially then those show up in your terminal logs. And there’s just a lot of concerns around doing that functionality, but it’s still technically possible because it’s an API.

Josh Birk:

Yeah.

Thomas Dvornik:

So if it’s an API, the CLI can call that API and do it, and it’s by far a big request of people wanting to do that. But it’s just one of those things that we probably will never do by default. We’re probably never going to bundle that. And so, I think Shane’s plugin, or one of the other plugins will let you set passwords. There’s a command to set a password.

Thomas Dvornik:

And so, those will be examples where there’s going to be some things that we just will not really ever do and other things that we just don’t have the time to do that people are building some really great plugins to support.

Josh Birk:

Well, and so, I think this plays into the next question. How does the concept of going open source play into the overall strategy for the CLI?

Thomas Dvornik:

Yeah. And this is, I think, part of the overall strategy for tooling in general.

Josh Birk:

Okay.

Thomas Dvornik:

So open source is becoming more and more of a supported thing within Salesforce. And now, we have a whole open source team and people are encouraged to do it. And when we first started the CLI, it was partially a resource thing and partially because it wasn’t a big priority at that point in time, but now under some of the new leadership and Wade, and [inaudible 00:13:42], they’re really pushing open source really hard. And the goal is to have all of tooling be open source.

Thomas Dvornik:

So it’s taken us a little bit of time, but we’ve recently done a blog post on it, on how we can get the Salesforce CLI completely open sourced. And I think that will also really help with that ecosystem because I think for the things that we don’t have time for, for example, even the commands that live in Shane’s plugin, maybe those are eventually ported it over to one of the bundled plugins by a community member, and then they’re shipped with the CLI.

Thomas Dvornik:

And so, we’re definitely not trying to push off the work to the community, but I think it gives the community a sense of power and ownership that they can, if they want to, go in and fix a bug or go in and implemented a command that is eventually bundled with the core version of the CLI.

Josh Birk:

Well, and I guess it legitimizes people are going to put that effort in. At least this way, there’s a path that it could become part of the official product.

Thomas Dvornik:

Definitely. Yep. And we’re also working on, so right now, when you install a plugin, you may have noticed, if you have ever installed a third party plugin, you’ll get a prompt saying that it hasn’t been signed by Salesforce.

Josh Birk:

Right.

Thomas Dvornik:

And one of the main reasons why we did that is because when they’re executing commands at the user level, that process on your machine has full access to that user.

Josh Birk:

Right.

Thomas Dvornik:

And there’s nothing we can do to prevent that.

Josh Birk:

Right.

Thomas Dvornik:

So with all the security things we’ve done in the CLI of encrypting values, and so all of your tokens and all that stuff are encrypted on your local machine, if there’s a process running as the user, they have full access to all that information and there’s not much we can do to stop it.

Josh Birk:

Right. So I can say safely that even when I was doing tools and utilities as a developer evangelist, I always gave it with the asterisk of, “I offer no support and I am not to blame for anything I break.”

Thomas Dvornik:

Exactly. Right? And so, I think the challenge is with plugins especially, is anyone can write a plugin and if they write SFDS plug install, it almost feels like it’s being installed by Salesforce-

Josh Birk:

By Salesforce,

Thomas Dvornik:

… that it’s owned by Salesforce, and we want to make it very clear that this is not something we have looked at. It’s not something that we own, but we still want to support the community to build up the ecosystem.

Josh Birk:

Yeah.

Thomas Dvornik:

And so, we are going to be offering signed, third party signed, plugins. So if someone has invested a lot of time in their CLI, or maybe we have an ISV partner who has a package on AppExchange, who also wants to have a CLI for their package, they will be able to build that, have it reviewed. We still don’t know what the review process would look like. Hopefully, easier than the AppExchange process, but probably still within that lines where we look to make sure that it’s not doing anything malicious or you’re not using any packages that we know to be security vulnerable, then we can sign that.

Thomas Dvornik:

And that way, when customers install it, they won’t get the warning. And even more than that, we want to offer plugin discoverability. So if you’re in the CLI, “Man, I really need to do more stuff with the bulk API.”, where you can look at a list of plugins that give you more enhanced capabilities that are signed and supported.

Josh Birk:

Gotcha. Nice. So starting to look a little bit more like an AppExchange offering itself.

Thomas Dvornik:

A little bit.

Josh Birk:

Yeah.

Thomas Dvornik:

Yeah.

Josh Birk:

So talk to me a little bit about that blog post. What are some challenges when it comes to moving something like the CLI into open source?

Thomas Dvornik:

I would say the biggest challenges are process, both the development processes with your engineers, but also with your CI and CD processes. And so, there’s some code that are checked into these repos that reference internal environments that we don’t necessarily want the DNS or the IPs of those environments to be out public.

Josh Birk:

Gotcha.

Thomas Dvornik:

And so, cleaning up the repos is a relatively quick thing, but it’s still time. And then, when we do that, then we’ve got to move it publicly and change all of our stuff to now use that public repo rather than our internal Git enterprise account. And then, we have to point over all of our jobs. And most of our jobs right now are hosted on an internal Jenkins environment that has no access to outside world and the outside world can’t call in.

Josh Birk:

Right.

Thomas Dvornik:

And so, when we move it over publicly, now we’ve got to basically change our builds over to circle CI or some other framework, which we actually want to do. But again, it’s still a time thing that you have to invest engineering effort into doing.

Josh Birk:

Got it. Okay. So moving on to the next great thing, we announced Code Builder at TDX. Compared to Developer Console, this is extremely different technology. Can you describe a little bit what Microsoft is doing here?

Thomas Dvornik:

Yeah. I can’t speak to Microsoft, what their strategy or their-

Josh Birk:

Right.

Thomas Dvornik:

Per se, but-

Josh Birk:

We can barely talk about our own roadmap. We certainly can’t talk about theirs.

Thomas Dvornik:

Right? Yeah. But I think Microsoft has done an amazing job with VS Code. I think it’s a great product and they have come out with more and more features, I think, to help support some of their internal use cases, in terms of connecting to a different environment so that you can still use the VS Code, even though you’re not actually using it, the file’s IO and all that stuff is not on your local machine. And it’s what they call their remote development, if you will.

Thomas Dvornik:

And you can look that up. I think they have blog posts about it as well. So you can technically connect to a Docker image, for example, or connect to some other computer or some other environment and you use VS Code like you normally would, even though you’re not using your own hard drive.

Thomas Dvornik:

And so, that was a great segue for them to support VS Code in the browser, which is essentially what they’re calling code spaces. And there’s a code space pilot for a GitHub right now where, it’s pretty cool, you can just, on a repo, you can click, because the editing capabilities on GitHub right now are pretty limited, very similar to what I would almost compare to Dev Console where, or the setup pages.

Thomas Dvornik:

And so, they want a way for people to make quick changes in the browser without necessarily having to clone the repo and do all this stuff locally and push that back up. So you can just open up the code space, make all the changes, save it and close it down. And you can do all of that in the browser and all that on your own.

Thomas Dvornik:

And so, that’s some of the things that Microsoft is doing to move it forward. And we decided early on that our investment was going to be with VS Code. So I said how we can’t support all the different tools, we really have to work on building once and to leveraging that across it. So starting with the APIs, then going to some libraries and the language servers, going to the CLI, and then VS Code is our end game in terms of the tools that we’re going to write and support.

Thomas Dvornik:

And so, really when we talked about web experience, because eventually the goal is we still have to support Dev Console and it takes time and resources, so what would our next version of a web experience be? Really, what we want to do is we want to use the things that we’ve already built, but just use it in the browser. And that is what VS Code is and that’s what Code Builder is, is the way to use all the tooling that you can use locally, but also be able to use that in a browser.

Josh Birk:

And I guess we should put an asterisk that so VS Code is our best foot forward, it’s what we’re staking our resources into. But since it’s leveraging the Salesforce CLI to do all of its magic, if there’s another IDE out there, as long as they can leverage the Salesforce CLI there’s no reason why it wouldn’t be compatible.

Thomas Dvornik:

Definitely.

Josh Birk:

Nice.

Thomas Dvornik:

And technically, because of VS, and there’s some other technologies out there too that can do online IDEs, if you will, that will actually support some VS Code extensions, and so that was another path we looked for. But yeah, I think with the code space that Microsoft is doing, it really provides everything we’re doing in tooling being able to be used the browser and it makes it very powerful to be able to, let’s say, instead of opening up development console, you just open up Code Builder, you can make all your changes right there, and it’s the same experience that you would expect on the client side.

Josh Birk:

Right. And that was my a-ha moment because I think when I had heard that we had an internal initiative and it was going to be web-based and all of this stuff, I kept thinking of, I want to say it’s Apollo or something, but they’re just very, very fancy HTML5 editors. And then, I think it was when I was interviewing Claire and she’s like, “It’s a VM.” I’m like, “Oh, that’s a much different beast than what we’re actually used to.”

Thomas Dvornik:

Yeah. And for people who may not be familiar either, since this is a VM that’s running VS Code, you have full access to the terminal. You can run Salesforce CLI commands yourself without going through the VS Code interface. So it really creates a lot of flexibility to empower people to do the things they want to do in the browser.

Thomas Dvornik:

I think with that said, one challenge that we’re having is Dev Console is used by a lot of admins and a lot of other people that may not necessarily know, or want to know, the full suite of tooling that we have. And sometimes when you jump into VS Code, it can be a little intimidating.

Josh Birk:

Right.

Thomas Dvornik:

And so, some of the things that we want to do are to make that a little bit easier, where we’ll focus you in on pieces that you want to focus on. And I think another good example of this hierarchy of tooling that I’m talking about is, one of the big things we need to support, in order to have competition with Dev Console or Workbench is the Query Editor. The Query Editor is by far one of the mostly used pieces in both Workbench and Dev Console.

Josh Birk:

Right.

Thomas Dvornik:

And so, right now we’re building that for Code Builder, so that we can have that query experience in the browser like you would with any one of the other two tools. And because we’re doing that, that’s also going to be automatically available in VS Code locally. So that means now even locally you can have a really great UI query editing experience, the same you would expect in the browser. And so, it’s great that we can build it once and use it in different places without having to worry about where it lives.

Josh Birk:

Yeah, because pretty much, we can build it for the desktop, and then if people need it in the web, they can skip to that.

Thomas Dvornik:

Totally. And I’ve mentioned language servers of it too, and that’s an open standard on a protocol to do things like debugging, code navigation,, auto-completion. And so when you support this protocol, any tool that supports that protocol will basically get the language support for free, essentially.

Josh Birk:

Got it.

Thomas Dvornik:

And so, because we invested in that for Apex and LWC and whatever else, those are the two big ones.

Josh Birk:

Well, I think we’re looking at it even for SOQL, right?

Thomas Dvornik:

So that’s actually what I was going to bring up is now, because we’re doing this Query Builder and we’re doing it in a VS Code extension, we need to be able to examine these queries and break them down and validate them. And so, there’s SOQL essentially language server built into Apex because SOQL was built into Apex, but that’s been extracted into its own grammar, into its own language server that we’re going to be leveraging for some of these new capabilities.

Thomas Dvornik:

And so, really anyone who wanted to build features off of the grammar or off a language server to do different kinds of query validation or whatever they want to do for their tool, that stuff is available. And so, it’s really trying to create these layered pieces that will benefit everyone, not just Salesforce.

Josh Birk:

Nice. Is there anything else on the roadmap that you want to give a shout out to? I know it’s always a dangerous question.

Thomas Dvornik:

That is. I feel like one we needed ahead of time for a little bit of thought. No, so I guess I will say, one thing that I would like to shout out is we recently did a CLI release for multiple package directories.

Josh Birk:

Okay.

Thomas Dvornik:

One thing that is, I know it’s not on the roadmap because we technically just released a big portion of it, but-

Josh Birk:

It’s on the roadmap behind us.

Thomas Dvornik:

It’s on the roadmap before us. But obviously, packaging is such a big, important story for Salesforce.

Josh Birk:

Yeah.

Thomas Dvornik:

And you already mentioned next generation packaging, or TGP, or there’s a lot of different names that you may hear floating around at different Dreamforces and whatnot. But the goal was to solve a lot of painful parts of packaging, the old way of doing it. And so, part of that, the newer way to do it, is to help have multiple packages within the same name space. And so, it’s a lot easier to build multiple packages and have packages depend on other packages that you build.

Thomas Dvornik:

And when you have that, you also need to have that easily supported for development as well, where you can easily move files around between different packages and develop on those different pieces. And that was never very well-supported in the CLI because before, what we were doing is we were munging up all of the packages into one deploy to the scratch org.

Thomas Dvornik:

So if you had, let’s say, some custom fields on an object in one package, and also in another package, they would get muddled up than that single deploy. And so, we did a lot of work to help support that better. There’s going to be a lot more work coming out to help support that flow even further. So if you have a lot of source, either in your existing org or in a package, I think now we’re at a point where there’s enough stable features out there to help you start to break up your source into smaller, isolated pieces of code into modules or packages, if you will.

Thomas Dvornik:

So even if you’re not going to be using the packaging technology, even breaking them out into these packaged directories will help you save development time, and CI and CD time, and merge conflicts and all of that stuff.

Josh Birk:

Yeah. And this plays nicely into a conversation I had with John Daniel. I don’t know if the episode will have aired or will be airing after this, but the nice thing about all that tech is that it helps beat back what they like to call the happy soup.

Thomas Dvornik:

Exactly. Yep. And so, that’s one of our goals and even some of the things that other teams have put out there, like the dependency API or whatever it may be, all of this is trying to help customers get away from the happy soup and do what you would expect when you’re developing a more modern application in another language like Java or something, where you can actually break up pieces into modules and features and more isolated components.

Josh Birk:

Right. And that’s our show. Now, before we go, I did ask Thomas about his favorite nontechnical hobby and turns out it’s not just beer, but making beer, and he was going after a very specific kind of beer that I know some listeners of this podcast are probably familiar with.

Thomas Dvornik:

I’m a hophead. So I’ve mainly brewed IPA’s or pale ales. I grew up in Santa Rosa and there’s a pretty famous brewery there called Russian River, and they produce a beer called Pliny, both Pliny the Elder and Pliny the Younger. Yeah, it’s a pretty well-known beer. And so, my favorite beer, I think we’ve ever brewed was a Pliny the Elder clone.

Josh Birk:

Nice.

Thomas Dvornik:

And it actually turned out really, really well. We were super proud of that one.

Josh Birk:

Thanks to Thomas for the great conversation. Of course, as always, my thanks to you for listening. Now, if you want to learn more about this podcast, head on over to developer.salesforce.com/podcast, where you could hear old episodes, see in the show notes, and have links to your favorite podcast service. I’ll talk to you next week.

 

Subscribe To Our Newsletter

Subscribe To Our Newsletter

Join our mailing list to receive the latest news and updates from our team.

You have Successfully Subscribed!