HubSpot Community Developer Show | Local Development Workflows with Mark Ryba and Doug Osborne

Foreign.

Hello, everyone. Welcome to another episode of the HubSpot Community Developer Show. I am your host, Dennis, and I am joined by a rowdy crew. Here we got Mark Riba, director of development for Smart Bug Media, also an avid Darks player. I believe you actually have a podcast, is that correct? Am I right on that?

Yes, I was producing it. I am no longer. But yes, I do also handle, or I did handle, production of a podcast for our online dart league. So if you're interested in that, that's fodart league.com, completely separate from the SmartBub media plugs I'm sure I'll have later. Yeah, it's a fun time. We stream webcam darts on Twitch and Yeah, there's about 50 of us throwing darts right now.

Awesome. Yeah, we'll, we'll definitely plug that later on. I think it'll probably be the highlight of the show. We also got a guy named Doug Osborne. I had never officially met Doug Doug until just a little under a month ago where I put out a question in our dev slack and he kindly responded. I got to meet him via the Zoom. I don't meet people in person anymore. It's all Zoomed. Doug is a creative engineer at Epsilon and purveyor of developer experience on the marketing website team. That sounds nice.

It's self proclaimed purveyor of developer experience, but that's what I love doing. Yeah.

Awesome. How are you doing?

I'm fantastic. And it's my first time meeting a couple of you in person, but I feel like we're old friends on the HubSpot Slack channel.

Yeah. Isn't that weird? I, I, I still just can't get over that sometimes. I, I've known Martha John for years. I mean years and years and years. It seems like, like my oldest friends. Now let's, I'm, I'm not that I'm a dork. I'm sorry I don't have any friends in real life. Lastly, I'm going to bring in John McLaren. You guys know him. Senior developer advocate at HubSpot, knower of all things, the encyclopedia of all Hubble tags. John. How are you doing, sir?

Good. Now I'm intimidated by the title of Nowhere of all Hubble Pigs.

Now there will be a pop quiz later. Yeah, right.

Yeah, yeah. I mean weather, by the way, we got two Midwesterners and we have two east coasts. Mark, you're in the D.C. area.

Yes, sir.

And how was the weather for you?

Crazy. It was crazy hot. And then, then we got a Crazy couple of Thunderstorms the last 24 hours. Saw everything from some hail, some pretty serious wind, but just happy to be back below 100 degrees again. I don't even know what it was with the humidity, but. Yeah, it's just that time of year where I just stay inside. I'm more of a winter person.

I know. Yeah. I look at my pedometer on my phone here and I am like below 2000 steps or something like that for the day, which is unusual for me also. Yeah, we have one of those weather systems in our yard and I didn't trust it because the heat ended up saying something like 137 or something crazy like that. It's like, no, no, no, no, no, no, no. This can't be right.

Yeah. No. D.C. in the summertime for, for any tourists, you know, it's like walking through Sue.

Yeah, right. Seriously, Doug, you. You and John are in the Midwest to Chicago and. Wait, wait, where are you? I always do this. John, you're in Milwaukee area.

Milwaukee area. Yep.

Yeah, yeah, yeah. Cool. And it's perfect for you guys. I was in Kansas just last week and I'm just gonna. I'm not gonna talk about HubSpot stuff at all. This is gonna be me going back to my, My. My farmer. I. I'll probably have to call this out because it's. Yeah. People say, why am I here? Darts and weather. I want.

I'll stop talking about it now.

All right, all right, let's get on to a few announcements. John, I'm gonna rely on you quite a bit on this one because it's. It's kind of heavy hitting here. We got styles field in beta. You. You wan. These announcements we have here.

Yeah, absolutely. So we just released style fields into beta and basic gist is that they are fields that you can add to the Styles tab in the page editor for marketers and content creators to use. Along with this, we also released some new fields that are only available as style fields, such as a gradient field. We are also happy to announce that we have a beta for the VS code extension where you can actually get the same Hubble Linting that you're used to in the Design Manager, but in VS code. Now, to enable that, it's really easy. You just open up the VS code extension settings for the humpstotic humpspot extension and toggle on the beta features. And then for Marketplace providers, a quick heads up, a redesigned Marketplace is coming and it's going to better highlight your assets. And on top of that, we are also adding some provider experience improvements, including a new CLI command that enables you to run automated validation on your theme to ensure that you're meeting the marketplace requirements. That command is not a replacement for the manual review that we do, but it'll at least prevent back and forth. That's unnecessary. So.

Go ahead. All these, all of these.

I was going to say all of these were announced in the developer change log. So if you want more detail, head on over the developer changelog@developers.HubSpot.com changelog Cool.

Yeah, I'm just going to ask like for the CLI one. I mean, is there a method to get into this beta or is it just pretty straightforward?

Yeah, so you actually need to use the beta version of the cli so you would install that. And we have instructions in the changelog announcement for that.

Beautiful. All right, let's talk about what we came here to talk about, folks. We are going to be talking about local web development and that, I know, is a pretty broad topic. I kind of want to talk about the history of it because I was just thinking about the other day about what local development was to me about 12 years ago, something like that. It was me working on HTML file, uploading it to a server with FileZilla and hitting refresh in my browser. Is this consistent with everyone?

Wait, you don't do that anymore?

Yeah, it's fail proof. Yeah. And now, I mean, you. There's classes taught basically on, you know, how to do local development. I mean, the progress has just been crazy. I mean, you need like a PhD sometimes to get through like a webpack configuration. Mark, I'm going to start with you. Can you just kind of like tell me about your evolution of. And this is HubSpot. This is Platform agnostic, you know, like how your evolution of, you know, local development.

Yeah, absolutely. So I first cut my teeth actually in college building my first websites of WordPress. And so, yeah, very used to the whole like cowboy coding kind of deal where you know, you, you have your, your local files and you're just kind of essentially, you know, essentially having really Filezilla, like almost watch a directory and then whenever you save something, have to go over and hit yes, every single file.

Yeah.

And then it would go up. Yeah. And you just prayed that you didn't have a PHP error missing a semicolon or something and just got a white screen of death. Right. And that was for developing sites. But then, you know, God forbid you actually need to maintain a site and push something new on a production one and then you run into some, some kind of error. Right. So definitely was very familiar with, with that kind of workflow. And then once I moved into my professional career, started working on HubSpot, I even remember the days very, very faintly. And I made a quick post in the slack this morning. I can't remember if it's. I don't know if this is nostalgia or just via PTSD, but very first version of the HubSpot CMS, you know, where you could really only change things with like one JavaScript embed in the top of the, in the top of the head and you had to essentially write all of your elements to get injected in on page load. I remember that. But really, you know, HubSpot development for the longest time for me, I've been on the platform for about seven years now, it really was centered. All your development was pretty much centered in the actual web app itself, right? So be version one of the CMS or when the cause rolled out, you know, I remember being in the room, I believe they announced it like the very first developer day when they announced FTP for cause, everyone's mind was blown, right? Like, oh my God, we can actually like do anything on our local machine and get it zipped up and then fast forward to today and we actually, you know, one of the first things that I did when I came into my role as director was, you know, actually get all of our development team used to working locally exclusively because we did have, you know, as a, as an agency our size, we had a lot of legacy code that was built in the Visual Builder, that kind of thing. So most of our team was used to working in the cloud dm, but now that we have all these improvements in the last two years around the developer experience, having the cli, having the opportunity to work outside of that Visual Builder framework and not have to go straight into just static HTML sites, because we were doing that for a long time too. It's really opened up the world for us both in terms of just the flexibility and the way that we're able to build and building more performance sites, as well as being able to take advantage of all the features that are available in a local dev workflow. Cool.

I'll throw the same question over to you, Doug. Tell me about you, your history.

Yeah, well, I actually come from a design background. I've always kind of been developing on the side. But yeah, I was definitely around in the days of developing in Dreamweaver and using. I actually, I'm a fan of Transmit FTP, but yeah, Convoy Code Net. Yeah, I love Transmit. Yeah, I'm much newer to the HubSpot scene. I joined the Epson team a little over two years ago, but yeah, same, same kind of a deal where we were primarily developing in the browser. And I came in, I was hired on as about the fourth developer, essentially on the dedicated to the web development team. And so one of my goals, and I was possibly given the opportunity to help improve our developer experience. So the timing was perfect because as Mark said, it was right around the time where HubSpot started releasing a lot of tools in order to develop locally. So like when that CLI came out, that was like, that was night and day. Like we were able to do kind of everything we were dreaming about once that happened.

Yeah. I'm just curious both of you, like when the CLI was announced and I do want to talk about other things other than the HubSpot CLI, because I think it's such a big topic. But like, when, when it came out, where did your heads go? Like what, how, how did you start rethinking how you wanted to interface with, you know, web development? I mean, was it just like a, okay, we can do whatever we want now, or did you have a specific, like, okay, we'll just do the bare bones right now, figure it out. You know, Mark, Doug, either one of you, talk to me about that.

You know, we kind of already had an idea of, of what we wanted to do. And shortly before I started, we were also, our team was placed under eng. We were kind of being held to a higher standard of coding. So we kind of already had like an ideal of what we wanted to do. And we had experimented with some things with like the local server and FTP and we were able to do some cool stuff with FTP. But it wasn't really until the CLI came out that we were able to really get a nice local workflow going, didn't it?

Yeah, it was a really interesting kind of period for me because I had just gotten to SmartBug around the same time that the, the CLI originally came out. And actually where I was at my previous agency, we actually took this step and as I said before, we were coding everything as HTML layouts already previously. So I was very used to kind of doing that and building in my field directly because of that previous agency. We weren't really, we didn't build sites as one off projects. Right. Every one of the sites we built was part of an inbound retainer relationship. And so we had a little bit More control over the, over the design of the site. Right. With SmartBug, obviously we work on kind of a really big scale and so we try to follow things kind of as close to HubSpot's. I don't know what the right word is. I don't want to say HubSpot Bible or anything like that. The way that you guys prescribe to build sites and the way that they should be edited. So with that being said, we were building sites still on the visual builder because that's what users were used to and that's also what our marketers were used to using. So when the CLI first came out, it actually took us a little bit to kind of adopt it. We were trying to figure out exactly where it fit because we had such kind of a rigid process. Right. So now, you know, fast forward a few months. Where it really started opening up doors for us was in kind of bulk file management as well as when themes finally came out. That was kind of the, all right, we, we have to go in. Right. And it really made, you know, kind of migration of assets a lot easier. Being able to bulk bring down things and optimize them and watching them was huge.

Yeah.

So that definitely impacted it. But I still remember when it first came out, my mind immediately went to, you know, kind of even before the whole child themes thing was being talked about in HubSpot, like being able to maintain a code base, right. In a git repo, bring it down, deploy it, but still have it backed by version control in a tool that's actually built for it. So that was where my mind first went. And then since we have adopted it here at SmartBug, so all of our projects are backed by git.

That's. Yeah. I was thinking about when you're talking about how your evolution of local workflow and the filezilla and I think you're kind of speaking almost like you're a sole developer. Right. This is. With you're not working on a team because that's a whole other aspect that just complicates it to the nth degree. And that's where just. I think version control is probably the most important aspect of any of this.

Right.

I mean, in my opinion, I mean, I, I like being able to, to code locally. It's nice, it's really, it's, it's pleasant. But version control just, I think that's the game changer, in my opinion. I don't know. John, can you. Heck. Hi. Tell me about your evolution. I've not asked you this question yet, but yeah, your. Your evolution with local workflows, generally speaking.

Yeah, I would say I followed a very similar path to Mark, especially when it came to. I guess when I first started out with development and everything, I actually sort of went in a weird path because I first built my first website when I was 8 years old. So weird fun fact, but it went terrible by the way, but. And had font takes galore and everything, so don't worry, I've gotten a little bit better at that time. The interesting part is it started out web based and then I worked again. I learned FTP right after that and started actually producing client stuff from that. So then got started with HubSpot. Same experience as Mark overall was fully in the design manager. I was also doing WordPress projects too, and I was using FTP for creating most of those. And I did like the ability to have version control with the WordPress projects and was trying to emulate that with HubSpot projects and they did until FTP became a thing on HubSpot. And then now the COI. It was a lot harder to do version control that way, but now with the coi, it's pretty fast and easy.

I'm curious, you manage a lot of portals as well when you're in the agency life, how did you transition when it came to the cli? Because I remember my experience, it was kind of confusing. I didn't know what to do, honestly. It's like this is going to. There's a lot of upfront work to get this all set up. And I'm just curious, John, how did you go about it?

So when CLI first came out, one of the hurdles that there was for me at first was that you had to use an API key for everything. But we changed that by releasing the personal access keys. And so at first there was that kind of like initial. Like every time you need to work on a new account, it's going to take you like five minutes to get set up. Once personal access keys became a thing and the COI commands got much more fluid and better where you. You just literally go HS auth. And then all of a sudden it goes, all right, hit one button to open the browser window to, to set your permissions for your access token, that was a game changer. And very quickly I was able to get set up with a lot of different accounts at once. So initially I was probably using it for just the biggest projects that I had. And then now everything I do is with the cli.

Cool. Doug, what's all involved. Can you just walk us through what your local workflow looks like? No secret sauce if you want to put that in there, but whatever you can. Detail.

No.

All good.

So it was kind of an evolution. Like I said, the CLI enabled us to do whatever we wanted. Before I was at Epsilon, I was agency side, so we had all sorts of different builds. So I had a pretty good idea of what I wanted to do with the HubSpot build. And then once CLI came out, we started. Initially it was a Gulp build. So the kind of the structure that HubSpot requires for your module files, I thought Gulp really lended itself nicely to kind of maintaining that, but giving us the power to use SAS and Babel and pretty much any kind of transpiling or image optimization or et cetera, et cetera that we needed. So we started small with that and then we eventually kept building on top.

Of that.

With the cli. It made all that a lot easier. We were kind of able to do some stuff with FTP, but. But not exactly. So once that came out, it was, like I said, perfect timing for me because we were really starting to ramp up all of our local capabilities. So now fast forward to a few months ago. We just lost a. Or we just launched a redesign, which we did completely with React components. So we actually have. Our build is still based in Gulp, because we still have Gulp controlling our main module template file structure. But then we have webpack layered on top of that, handling all of our REACT components and piping those through, and we follow a structure that's similar to the REACT boilerplate that Huntspot has out there. And we've just continued to layer on features on top of that based on what we need. So, yeah, I mean, it's been a great experience having the opportunity to continue to evolve this and looking forward to what else HubSpot has in store for us in the future.

Yeah, I'm curious. You and you guys have two different. Mark, you're an agency. Doug, you work for a company, so it seems. I mean, I imagine your strategies are totally different here. I'm curious to like Doug, I guess you get to iterate, right? You just keep on building on top of that. Mark, you gotta be fast, you gotta be agile. Your project changes day to day, right? So work with that.

Tell me everything.

Mark, I'm sure you have words to say.

I have many words to give you, Dennis. Yeah, no, we have. So it really depends. And I know that we, you know, I know we're going to talk about kind of different different tools for different projects, right. And for us, it's a really interesting situation because we launch three to four websites a month, right? So we're building sites at a pretty quick rate. We're working with a team of. We have 10 people on our team right now. Two of those are our QA specialists. And then beyond that too, you know, we. We try to make ourselves as as much of a, or as close of a partner to HubSpot as we can. So when it comes to what we're committing to get, and really just kind of how we approach our website projects right now, we try and keep it to the book as much as possible. And we do that because, number one, it's more scalable for us when we bring on new developers, right? So if they had to come in and learn a whole build system and get onboarded with getting their environment set up, all that kind of thing, that introduces its own little bit of friction. But then even beyond that, when it comes to maintaining a website over time, we also don't want to necessarily lock any of our clients in to some kind of build tool or something else that requires a local machine to run. So that being said, it's a very kind of unique situation where we allow each of our developers to kind of figure out their own individual build system, but then what actually gets committed to code is already compiled. And we do that for the reasons I just mentioned, mostly partially readability as well, to make sure that anyone, if they do have to be onboarded or maintain a project down the line, that everything is kind of in a predictable place. But also, again, just making sure that once we do hand off this website, be it to our marketing team, if our inbound marketers are assisting an organization with their, their growth efforts, or if we're just handing it over to the client and their content team, we want to make sure that we are. We aren't gatekeepers in any way. Right? So we're really putting the marketer first in that, in that regard. That being said, for our actual, for our actual process, some of us, it really kind of runs the gamut. I've had a very extensive gulp file before, probably similar to, to others out there, but we also didn't want to get into a situation where we're spending more time on our, on our build file than we are actually developing, right? So some of our developers have one that they've used for, for a long time. Some of us just kind of use. And I've honestly in recent months been falling more into this camp where I just use a lot of VS code plugins to kind of handle my compilation directly in the software and again, just making sure that I can commit compiled clean code already back. So I'll use everything from. I'm a big PUG fan, so I write a lot of my. My code in PUG or. Or Emmet SCSS Babel as mentioned. But that being said also, if we do build anything with Reactor Vue, we're using that boilerplate and we're using some additional webpack plugins as well. I'm a big fan of Post CSS personally. Handle a lot of those kind of things, convert pixel values to RAM automatically, things like that. So yeah, it kind of depends on the project, but yeah, we can kind of run the game.

Yeah.

How much are you investing in terms of just keeping up with technologies? Just, I mean you can. I put this in notes here like it's a rabbit hole.

Right.

I mean you can, you can spend years and as you do it, something else comes out. Right. You know, it's how much time are.

You spending doing that? Yeah, so it really, it kind of rolls my. The, the guiding principle that I've used to this point is looking at kind of where the market is. So for example, I take a lot of inspiration personally from Gatsby just working in that on kind of side projects. I love the developer experience in that kind of workflow. And so we try to make that as similar as natural on our end, both in terms of performance that we ultimately get out of it, but also just the time it takes from, you know, start, git, pull or whatever. It's actually pushing it into production. So I keep my eye on tools like that. I'm a big fan in general of kind of the jamstack headless serverless space. So a lot of the tools that I end up kind of experimenting with come from there, but again, always making sure that it fits into a HubSpot first workflow. So yeah, we'll experiment with grunt, we'll experiment with Gulp Post css. As I mentioned, a lot of image optimization tools. That's probably the number one thing that we do in terms of kind of local compute power is automating our optimization of images. But yeah, other than that, it's just kind of keeping an eye on the industry, seeing what tools we can pick up and integrate. For example, I saw you guys posted something on GitHub Copilot this morning, so I'm already thinking about how can we integrate that little things like that. But primarily that's all built Kind of into R and D time before we can really kind of make a case and incorporate it into our standard processes.

John, what about you?

How do you focus?

How do you not go down the various rabbit holes? I think you have, you know, you're better at this. You're, you're more disciplined than I am.

So I think my job position makes this a little unique in that my, my, my job is no longer in like Mark's shoes where I, I previously was. And now I am focused a lot on what is happening like months to years down the road and thinking about where tooling and everything is going to be at the same time. The projects that I do actually work on, on the cms, you, you, you would find that my approach is very kind of conservative when it comes to Dell tools right now. So the reason for it is because anything I create, I want someone else to be able to pick up.

Yeah.

Right away and know exactly how things work. There's nothing wrong at all with using different tools. I, I think you should always pick the right tools and the right amount of tools for the project that you are working on.

John, I think you give that answer every podcast. I end with you.

Turning into a cliche.

Doug, how do, how do we set people for successive? Like, let's say you are hit by a bus, God forbid. How is, you know, Joe Schmo gonna come in there and take over your, your build process?

Well, we tried to maintain a wiki with instructions on how everything's architected and how to use everything as clearly as possible and as detailed as possible. And whenever we add on a feature, we tried to do it in a way where it's easy to pick up. So as long as you're using the build, basically we have a gulp task for that. So anything you need to do, we're building in a way that it's easy to use. Because on my team there's only one or two developers that actually work on kind of the build part of it. The others are using the build to focus more on the web development part of it. So is really important for us to document and do the wikis, do the readmes, so that somebody else can just jump in and interchangeably take my job.

Yeah, yeah. Mark, have you ever just taken our project that has some sort of, you know, it's using grunt back there or something like that, and do you, do you keep it as is or would you re engineer it to go into a more modern workflow that you would prefer? I mean, what's, I guess what's the time benefit?

Yeah, it can really, you know, it can run the gamut. I will say we have not inherited a site yet that actually was backed by version control where it's kind of obvious that there is an actual build system that you can run it through. More often than not, we're getting a site that's already, like I mentioned, already run through a compiler and all that we're working with is pre minified and pre optimized code that's really hard to iterate on. Right. So usually what we'll do is we'll service it as much as we can, usually writing just net new code. We don't try to go back in and maintain something that's already been minified and kind of abstracted beyond the ability for us to really read it and figure out what's going on. And yeah, usually what we'll do is honestly we'll just kind of, we'll maintain it as much as we can and eventually we reach a point where it's just like, you know, guys, we need to kind of start from scratch because. Yeah, and that's kind of, again, that's kind of why we've guided ourselves to this point where we allow our developers to use build tools where they make sense. But yeah, we don't want to handicap anyone down the road and that's traditionally been our experience.

Great. And then John, to your point earlier about using like the basically the simplest thing possible. So what are your thoughts on like, you know, you know, modern JavaScript, ES6 or more like, you know, SCSS, SASS files, things like that that have to be compiled and I mean, you know, CSS is making such headways in terms of what it does. It's almost the relevancy of SaaS is in my opinion questionable at this point. I think it's still there, still useful in some places, but slow, quickly. I think CS is taking over. But I digress.

Yeah. When it comes to like writing ES6, JavaScript and beyond and everything right now browsers, browser support is pretty good. Um, and we just announced. Actually I'm going to scrap that. I don't know if we did.

We did. We did. We did.

Okay, good. Yes, we announced that we are sunsetting support for Internet Explorer HubSpot wide. Uh, so the.

I'm going to, I'm going to verify that we actually announced this and there might be a cut at this point. I'm pretty sure it was announced. It would be news to me but.

We stopped supporting it last year so.

Well, I Will talk as if I didn't say it then, but depending on if you need to support Internet Explorer, that's the main concern with using modern JavaScript. Most of the new browsers, auto update and most of them all support support the majority of the functionality. I think the only JavaScript features that modern JavaScript features that are not fully supported are imports and exports of JavaScript modules. So the good news there is you may not need something like Babel. There may be perks to using some of the tools for other purposes like just like for example, like Sass. I enjoy writing Sass personally, mostly just for the nesting functionality.

Yeah, yeah.

But when it comes to. Yeah, but when it comes to variables and when it comes to a lot of the other functionality, you either can reproduce that with modern CSS now using custom properties, for example, or Hubble has baked in functionality that's equivalent. So yeah, I lend myself towards keeping things lighter if I can so that later on down the road if I need to re pick up a project or where I have to pass a project off to somebody, they're not going, oh man, like I'm inheriting a project that's on version 1.2 whatever of this tool and 1.2 of this tool and having to go through that scary situation of can I even update all of these things without something breaking?

Right, right. Definitely. How do you guys handle reloading? I think someone at Slack axe this question asked. I said axed asked this question. Do you guys have methods of just doing some sort of live reload with your with your files?

Live reload. So we use. Part of our Gulp build is after the files compile and the upload's complete, it triggers a live reload. So there's a Chrome extension that works in conjunction with that. So you turn that on. The Gulp build triggers anything with that extension active to reload. So it's almost as good as just a hot reload.

Cool. And honestly we use the built in HubSpot 1 right now, so we'll watch a page or a module file using the live reload one. But again it's. Yeah, we're kind of leaving it up to the developer's discretion. I honestly like hitting command or Commander Control R is, you know, that big a deal for me. So I usually do that and honestly like I find that it, it encourages me to work on, you know, as many styles or bugs, whatever it is in my code once and then preview it. So yeah it really, when we're working on a team, you know, kind of like ours we try to empower our developers as much as we can to kind of be able to create the workflow they want to use. No one on our team for HubSpot at least has done. Has done live reload. We will sometimes with with WordPress depending on our situation, what sort of theme we're using. But yeah, right now if you want to do that then we typically use a built in HubSpot tool or honestly a lot of the time I'll jump to codepen and do that if I'm doing just a module development project. Right. So I just have a starter built in there to allow me to use PUG Babel scss. If I need a framework I'll load that into. But yeah, if I just need to kind of crank out something really quick and visual, I'll do that and then just hit the the button to view the compile code for each one, copy it over to my HubSpot project and then upload from there.

That seems like similar method to you in the path, John. Correct. I mean you were a get it.

Yeah.

Put it together.

That's exactly what I was doing.

Yeah.

I also did when, when I would create a new module like when I was first fleshing it out, I liked using CodePen to get to use all the build tools without any of the setup and then just jump into it. Yeah. Then be able to just drop all of my finished code in and then the advantage is anyone inheriting my project too also again not to just keep bringing it back to that but then they're not sitting there setting up any tools, they just have the. The raw code.

Yeah.

I was talking to Tim Joyce earlier today and he's got a setup where he brings it into a PHP file and he has a live reload setup to that. It's Tim for you though. He over engineers anything. He also is. He's happening with the VS code extension as well, which is interesting.

Nice.

Yeah. Yeah. This is something I personally am a fan of is GUI systems. I'm just curious to know what you guys think. We talked about filezilla Transmit earlier. Do you. Everything we've talked about so far after that has been pretty much in a file, right? Do you guys prefer to work that way through the CLI terminal and through a JSON pack, whatever it might be, or do you guys like to turn to. For me I personally like Tower to do all my git work. I don't mind doing it from the command line, but I feel better more confident with something like Tower. Doug, what's What? How are you handling things like that?

Yeah, we're in a BitBucket so we actually use Source tree when I'm personally I'm a big fan of just doing most everything in Terminal, but whenever it comes to something complicated like looking at commit history or anything like that, I love the more visual approach of looking at source trees so I can better wrap my head around like a history behind something.

Yeah, I just personally like I may. I'm just getting old, I don't have time to memorize all the damn things out there that I need to do all the commands, you know, there's so many of them. And HubSpot for example, keeps on coming up with these new ones. I gotta memorize here and there. Mark, what about you?

Yeah, so we, we kind of use a combo. So we in our documentation, technically we only document everything out for our, for our process using GitHub Desktop as a way to pull down and manage your projects that way. However, increasingly we're also using a plugin for VS code that I believe is just called like GitHub issues or something like that that actually connects with you, authenticate with GitHub, it'll go up and it'll bring down your active issues as well as let you create new ones and then by clicking on the issue, it'll automatically create the new branch. So that's actually been really helpful for us to kind of do that directly in the code editor. So it's kind of a hybrid where like, you know, it's not quite a full gui, it's still within the code editor, but it kind of puts everything into one place. And frankly, I know it probably isn't great practice going forward, but VS code seems to be stable enough that as many, you know, kind of plugins or efficiencies I can find within my code environment, I try and put it in bsc.

Yeah, I'm curious just in terms of like tips here, what extensions do you guys recommend? Generally speaking, I know what John's going to. John, what do you recommend for VS.

Code extension, the HubSpot language extension.

Mark, what do you got?

Yeah, bringing it up now. I also will say for any HubSpot developers on Windows, WSL for Windows is crucial for our process. So that essentially lets you install a Linux distro on top of Windows so you, you don't have to like learn the command prompt stuff versus the standard Unix terminal. So all of my HubSpot development on Windows is actually technically in Ubuntu, but it still functions like a regular app that Kind of thing. In terms of my extensions, looks like I have a beautify one. I have the HubSpot extension obviously. I do also have the Jinja extension which is still in version 008 but has 2.3 million installs. So probably safe to be using in production. Use some remote SSH ones. Twig as well. We need to use twig in our in our WordPress projects to make it as similar to HubSpot as possible. And then some some extra stuff for. I have a docker one for kind of side projects and messing around with docker as well as syntax highlighting for Vue and React.

Cool.

Doug, what do you got?

Tell us everything.

A lot of the same. I use Prettier for my code formatter and we do. We've got a commit handle so that everyone is on like the exact same formatting, which is nice because that was kind of a big issue for us up front. And one that no one has mentioned yet is the JIRA plugin, which is kind of nice because you can right in your NVS code create tickets and kind of comments in line where that applicable ticket needs to get action on.

Nice. And just out of curiosity, your terminals, are you oh my zshing it or do you guys have a different flavor that you use? And if you are using Omizsh, I want everyone's theme. I need screenshots of your themes right now. No, it's okay.

I'm not big on the whole customized terminal thing, so I actually just use like I said, Ubuntu bash directly in VS code. Sorry, but it works.

Doug, you're a designer. You have to have a little flash going on.

Yeah, we got a little my Zish going on. Nothing too fancy, just a little bit of a colored prompt with the like the git branching and stuff like that.

One of my favorite things on Ham on there is I have this. Just a quote, a random quote that comes up every time I launch. Watch it. Which I enjoy.

That's cool.

I'm going to steal all of these things. I'm going to put in the show notes for everyone to steal. We will not take a screenshot of Mark's terminal because it's boring. If you were to recommend to people who might have gotten this far into our podcast, what are the minimum. What's the mvp? Minimum viable product for a workflow right now, Local workflow. I will start with John.

I'm going to suggest the. Possibly the most minimal you can go. But. But cli. I recommend VSCode and I would generally recommend Git in general, doesn't matter if you're using it with a, with a GUI or any other method.

Okay, Doug, I would 100% agree with that. I think the by far the most important thing is to have version control. So whatever you're doing, make sure it uses that. And I think beyond that, it's really up to your team and your needs. So like, having a front end library for us was kind of a big thing because it's, it's really helped our design consistency. I definitely wouldn't say that's a bare minimum, but if that's the direction your team needs to go, go for it.

Yeah, yeah. And Mark?

Yeah. Similar deal. So personally for me, some kind of UNIX shell or just a way to, you know, write, write your commands in a UNIX friendly way. Be that Mac or Linux node. Obviously everyone needs node these days. HubSpot CLI VS Code I think is really the only way to go. I was a big Atom user for the longest time. It just got way too freaking slow. And yeah, the plugins that I mentioned, the HubSpot, honestly, the VS code extension for me from HubSpot is a game changer. I don't know that I would be able to do local dev anymore without that just having all those snippets in there. And like, you know, I've said it a few times, like writing DND syntax kind of still puts my brain at a pretzel. So having that having the autocomplete there is absolutely crucial. And yeah, the GitHub stuff, having Git installed, that's really kind of the final piece of the puzzle. But yeah.

Cool. All right, guys, I think this has been a success. I think the last three people watching this will enjoy it. And you guys have a great rest of your.

Hi mom.

Thanks back at you guys. Thanks for having me.