Causeworks with Jim Fisk

Episode Description

Jim Fisk returns to discuss Plenty, his Svelte-based Jamstack framework with a Git-backed CMS, his nonprofit-focused agency CauseWorks, and running meetups.

Episode Summary

Jim Fisk rejoins the show to share updates on Plenty, his Svelte-powered static site generator built with a Golang backend for fast build times. The conversation covers his company's rebrand from Janq'u to CauseWorks, a service arm focused on helping small nonprofits in the Boston area build affordable, secure, and maintainable web properties. Jim makes a strong case for the Jamstack approach, framing it as "build-time rendering" that simplifies architecture and lowers the barrier to entry for newer developers. The discussion gets technical as Jim explains Plenty's newly realized Git-backed CMS, which communicates directly with GitLab repositories using PKCE authentication, allowing content editors to make changes that feel real-time while a CI process rebuilds the static site in the background. He introduces the concept of a "discoverable CMS" that automatically infers editing interfaces from JSON content sources without requiring manual field configuration. The episode also touches on the value of beginner perspectives in tech communities, drawing from Jim's experience running Jamstack Boston and Anthony's observations about how streaming and content creation have become viable pathways into the industry.

Chapters

00:00:00 - Introductions and the CauseWorks Rebrand

Anthony welcomes Jim Fisk back to the show and sets the stage for a wide-ranging conversation covering Plenty, Jim's company, and a new subsidiary brand. Jim recaps what he's been working on since his last appearance, explaining how his various projects reinforce each other around a shared mission of serving nonprofits.

Jim introduces CauseWorks as a rebrand of his existing company Janq'u, motivated by the fact that clients consistently misspelled the original name. The two debate whether to capitalize the W in CauseWorks, drawing comparisons to conventions like TypeScript and DreamWorks. Anthony also mentions Chris's company Everfund, which handles donations for nonprofits, and Jim expresses interest in exploring that integration.

00:03:55 - CauseWorks and Nonprofits in Tech

Jim explains the geographic focus of CauseWorks, serving nonprofits in the Boston and MetroWest Massachusetts area through word-of-mouth referrals. The company aims to be a behind-the-scenes partner for mission-driven organizations, helping them strengthen their web presence, branding, and community reach regardless of their size or budget.

Anthony connects this to broader trends he's seeing in his network, including Redwood's climate-focused funding arm. Jim reflects on how newer web technologies are reaching nonprofits earlier than expected, rather than trickling down from startups and finance. He explains how his company transitioned from doing Drupal and WordPress work to seeking lighter solutions, since many small nonprofits struggle with the maintenance overhead, security updates, and hosting costs associated with traditional CMS platforms.

00:07:10 - Plenty as a Jamstack-First Svelte Framework

The conversation shifts to Plenty's positioning in the Svelte ecosystem alongside tools like SvelteKit and Astro. Jim describes Plenty as a Jamstack-first and Jamstack-only framework, pushing back against the trend of moving away from static architectures. He reframes the terminology, preferring "build-time rendering" over "static site generation" to better capture what the framework actually does.

Jim argues that the Jamstack offers more than just performance — it provides a simplified architecture accessible to developers who know HTML, CSS, and basic JavaScript. He contrasts this with server-rendered approaches that require managing runtimes, package management, and hosting infrastructure. Anthony draws comparisons to Hugo and Elder.js, noting that Plenty combines Hugo-like fast builds with Svelte's component model, and Jim confirms the CMS component has moved from a rough idea to a working reality.

00:12:54 - The Git-Backed CMS Explained

Jim breaks down the two main approaches to Jamstack CMS architecture: headless CMSs like Strapi that communicate via API, and Git-backed CMSs like Netlify CMS, Tina CMS, and Plenty that deploy a frontend editor communicating directly with a Git repository. He explains how Plenty's CMS writes changes back to GitLab, which triggers a CI rebuild and redeployment without any managed servers.

The discussion gets into deployment specifics, with Jim describing how GitLab Pages hosts the static output while a CI runner handles rebuilds on each commit. He explains the PKCE authentication flow that allows users to log in and edit their site through the GitLab API without running a backend server. Anthony asks about the CI layer, and Jim clarifies how GitLab's CI runners work similarly to GitHub Actions, noting that GitLab has historically been ahead on features like built-in authentication and Let's Encrypt SSL for custom domains.

00:17:58 - Authentication, PKCE, and GitHub Support

Jim clarifies that the CMS is largely independent of any specific CI platform — it only needs an authentication API and a commit API to function. The main barrier to GitHub support is that GitHub doesn't yet support PKCE for OAuth, which would require running an intermediary server. Jim explains how PKCE improves on the older implicit grant flow by using hashed random strings to prevent man-in-the-middle attacks.

Anthony acknowledges the depth of OAuth as a topic and connects it to Jim's security-minded questions at a previous Web3 presentation. Jim reassures listeners that end users don't need to understand any of this — they just need a GitLab account. The two discuss the importance of keeping authentication abstracted while maintaining open-source transparency so users can verify the code if they choose to.

00:22:29 - Flat-File JSON and the Discoverable CMS

Jim explains that Plenty uses flat-file JSON for all content, with completely freeform data structures rather than predefined keys like Hugo uses. He highlights how Plenty's CMS is tightly coupled to the framework, eliminating the duplicate work of mapping CMS fields to site fields separately. This tight integration also enables real-time previews and a seamless editing experience where changes appear instantly on the frontend while the Git commit and CI rebuild happen in the background.

Jim introduces the concept of a "discoverable CMS" that automatically analyzes JSON content sources and infers appropriate editing widgets — text fields, image uploaders, date pickers — without requiring manual configuration. This zero-configuration approach provides an immediate editing experience out of the box, with the option to override using custom schemas for more specific needs. The two also briefly discuss themes, styling philosophy, and how Plenty is designed for building small, maintainable sites from scratch with a minimal code footprint.

00:33:33 - Running Jamstack Boston Pre- and Post-Pandemic

Anthony asks Jim about his experience running the Jamstack Boston meetup through the transition from in-person to virtual events. Jim recalls the vibrant pre-pandemic meetups with 40-plus attendees, office sponsors, and a diverse mix of newcomers and experienced developers. The virtual format brought speakers from different locations but saw smaller attendance, likely due to Zoom fatigue.

Jim shares ideas for revitalizing the meetup with shorter, more frequent sessions rather than long multi-speaker events. He expresses particular enthusiasm for talks by newcomers to tech, arguing that beginners offer a perspective that experienced developers lose over time — the ability to explain foundational concepts that become taken for granted. Anthony agrees, suggesting that meetups could adopt a streaming model to reduce friction and maintain community presence.

00:38:26 - Beginner Content Creation as a Career Path

Anthony shares the story of a friend who started streaming her coding journey from near-zero experience, bringing on high-profile guests to teach her on stream. Within six to seven weeks, she landed a part-time DevRel job, validating the approach Anthony had encouraged. Both Anthony and Jim reflect on how the post-pandemic shift to digital created new demand for people who can run streams and produce content, even if their coding skills are still developing.

Jim connects this to his own experience transitioning from a data storage company to tech through nighttime online courses. The conversation highlights how content creation skills paired with learning in public can accelerate career entry into tech. Jim closes by inviting listeners to find him on Twitter, LinkedIn, and YouTube, check out Plenty's open-source project, and reach out to speak at Jamstack Boston, especially encouraging beginners to share their perspectives.

Transcript

00:00:00 - short recording interjection

All right.

00:00:11 - Anthony Campolo

Jim Fisk, welcome back to the show.

00:00:13 - Jim Fisk

Thanks for having me back. I'm excited to be here.

00:00:15 - Anthony Campolo

Great to have you. You were on quite a while ago. You would've been somewhere in, I think, the 20s of the episodes, talking about Plenty, which is a Svelte framework. We'll talk a little bit about that. You also have your own company, Janq'u, and a new subsidiary company based off that company, or some sort of nonprofit thing that we're going to talk about. So a lot of cool topics to get into here.

So why don't you let us know what you've been up to since we last talked to you, and then give your who-you-are for people who didn't listen to that episode as well.

00:00:44 - Jim Fisk

Sure. Thanks for the intro. Yeah, I've been busy doing a lot of the things that I've been working on since we talked last time, so building out Plenty as a static site generator framework for Svelte. My organization and the sub-brand that we're coming out with, CauseWorks, have been reinforcing some of the work I'm doing on Plenty, and we're moving in that direction more for some of our small nonprofit sites to allow them to have better performance, better security, and just an easier maintenance overhead overall for their web properties.

There are a lot of moving parts for a small company, but they all kind of reinforce each other, and they're all building toward the same mission. So I think as Plenty gets stronger and better, so does our service arm, which is now CauseWorks. Essentially, the thinking behind Janq'u was that it was hard for people to spell and say, and we have clients that have been working with us for about seven years now that still misspell our name on checks. Luckily, the bank cashes it, so it's not a big problem, but we wanted something that was just a little easier for folks to digest and that kind of speaks more to the mission of our service arm, of what we're doing.

00:01:41 - Jim Fisk

So that's why CauseWorks is coming out.

00:01:43 - Anthony Campolo

My first question would be, then, is the W in CauseWorks capitalized?

00:01:48 - Jim Fisk

This is a great question. So if you go to CauseWorks.com, which is a work in progress, it's like a half-finished website right now. You can find cases of both on there. I think I'm going to go with not capitalizing it, but it's a little inconsistent right now because I think I've had that same debate in my head. Which way should I go, Anthony?

00:02:04 - Anthony Campolo

Well, for me, I kind of find that most of the time now it'll be capitalized, even if they're not distinct words, like TypeScript or GitHub. Those are technically two words, but they still are kind of combining into a single word. So I find that CauseWorks, if I do that same kind of mapping, I would capitalize the W. I just find that it also helps people see there's kind of two words there versus it kind of blending into a single word. We were talking about this and how people pronounce Janq'u. Sometimes they just look at it and they don't break it apart into two pieces.

00:02:38 - Jim Fisk

Yeah. No, that's good to know. I'm trying to think what, like, DreamWorks does. I think they capitalize both, right?

00:02:43 - Anthony Campolo

Yeah, DreamWorks capitalizes both.

00:02:45 - Jim Fisk

All right. Well, that's good advice. I'll take that into consideration.

00:02:48 - Anthony Campolo

Yeah. And it's funny. So Chris is actually on vacation right now. He's going to Orlando with his partner. And now that I'm realizing you have this new company based around nonprofits, I'm like, oh, you need to talk to Chris, because Everfund is for donations for nonprofits. I'll play the Chris surrogate here. Do you need payments for your website?

00:03:06 - Jim Fisk

Well, we do a lot of payment stuff. So when I was actually looking at Everfund right before the call, I was looking at what people have been up to. And yeah, I saw that, and I didn't realize that was his company. So that's really cool. I definitely am going to dive a little more into that. Are they released yet? It looked like it was maybe a beta.

00:03:19 - Anthony Campolo

So Everfund has itself been in operation now for two years. There's a new SDK, and then they have, like, a script tag you can add to your site now, so you can build Everfund into your website as a developer. So it was previously a platform with a dashboard, and still is. You still use that. And now they're building dev tools to actually integrate into your website. So that would probably be a thing that you would be looking at. And what you're thinking of is kind of beta, but Everfund has been a thing and they've had customers for at least two years now.

00:03:49 - Jim Fisk

Yeah. No, that's super cool. It looks really polished from an offering standpoint, so definitely something I'm excited to dive into.

00:03:55 - Anthony Campolo

Cool. So why don't we talk about CauseWorks? What kind of nonprofits are you targeting, and what is the area and use case that you're looking to fill here?

00:04:05 - Jim Fisk

Mainly it's a geographic kind of niche right now. So, you know, I'm in Framingham, Massachusetts. Most of our clients are in Boston or the MetroWest area of Massachusetts. It's just kind of been like a word-of-mouth marketing strategy from our standpoint. The initial name, Janq'u, is actually [unclear]. The whole thinking behind starting that company was that we wanted to be kind of like the silent partner to people who are doing mission-driven work, and we didn't want the focus to be on our own marketing or our own branding. We really wanted to just be sitting in the background and helping them focus on their marketing, their branding, and their web properties.

We tried that for a while. I think CauseWorks maybe will work a little better just to make things easier for folks, but essentially, yeah, we want to help people who are doing all sorts of good in the community from a variety of organizations, from mentorship to connecting people with grants and funding, nonprofits, social justice-type nonprofits, and a variety of other small, community-based nonprofits as well.

00:04:51 - Jim Fisk

We basically want to make them stronger, have better web, connect with people, and get their names out there. Some of them are small and just starting up, so we want to make sure that they get out there and they get their brand known in the community.

00:05:01 - Anthony Campolo

Yeah. That's great. If you also felt so inclined to get into, like, climate research and things like that and those types of nonprofits, there's a whole climate-focused arm of Redwood now. Tom is funding startups, and he's funding startups that are building with Redwood. And now he's funding startups that are building with Redwood who are building climate tech specifically. So it's already this nonprofit part that we're starting to integrate with Redwood. So I see a lot of this in terms of social good and just general, how do we use tech for real-world concerns? And I see it in a lot of places within my network more and more these days.

00:05:35 - Jim Fisk

Yeah, and it's super interesting because I always felt like maybe some of this newer edge technology would kind of trickle its way down to nonprofits later. Like, start with a lot of startups and finance and that kind of stuff, and then eventually the technology would trickle down. But it seems like there's a lot of people doing great work focusing on nonprofits from the start, which is really cool. So Redwood obviously is very innovative. We're trying to be innovative with Plenty as well. I'm trying to fill the gaps that we had with some of the traditional kind of CMS technology.

So when my company started in 2015, we were doing primarily Drupal and WordPress work. We still do a lot of that, and I think those frameworks are great for certain large nonprofits with lots of resources, but there's a lot of smaller nonprofits that just can't maintain the upkeep of that because there's weekly security updates. There's caching that you need on the front end, like a reverse proxy to have fast websites. And then there's expensive hosting and all sorts of things that go along with it. So we're trying to find a solution for people that works for them and where they are in terms of their budget and their goals. Hopefully Plenty can fill some of those gaps. I think Redwood and other things can do it as well.

00:06:32 - Anthony Campolo

Yeah. This is what I love about your perspective, because there are people who are kind of like me where I had done a tiny bit of WordPress, but I kind of came to the Jamstack as a blank slate and was just like, this is a way to make websites. This is really cool. I'm going to keep making websites this way. Whereas other people who had been doing this more monolithic CMS-type work, they understand what the Jamstack is a reaction against, and specifically why that architecture is really interesting and is unique to kind of push as a counter to this old-world paradigm.

I think there's still a lot of value in doing the monolithic CMS. And there's plenty of reasons why you'd want to set up a WordPress site. But you're someone who is trying to take the benefits you can get from an old-school CMS with this newer front end technology and component libraries and things like that.

So let's get into Plenty. And Plenty is a Svelte framework. And since we last talked, there are now things like SvelteKit and Astro. You can run Svelte there. So there's a lot of good ways to run Svelte. How do you position Plenty against these other ways to use Svelte today?

00:07:32 - Jim Fisk

Yeah, that's a great question. So basically I think the way that Plenty differs, there's a lot and I have a lot I'd love to get into, but it's kind of a Jamstack-first and Jamstack-only framework. And the funny thing is I've noticed there's kind of a trend of moving away from Jamstack. And actually, I was listening to the Remix episode that you had with Kent.

00:07:49 - Anthony Campolo

As you said that, I was like, so it sounds like the anti-Remix.

00:07:52 - Jim Fisk

Well, yeah, because I remember he said that he's bearish on Jamstack, and a lot of the folks over there are. I totally understand some of the challenges with Jamstack, but I'm actually really bullish on Jamstack. I think that there's a lot of things that you can get with that kind of architecture that you can't really get with others. And I think the focus on that episode, I'm paraphrasing a little bit, was there are ways to get performance out of SSR applications and other ways to do these types of things.

But for me, the Jamstack is more than just that fast output that you're getting. It's also a simplified architecture that allows folks to use the lessons they learned through HTML, CSS, and simple JavaScript. So someone kind of breaking into the industry, I want them to be able to be productive in a full-scale application, handoff type of way. And I think the Jamstack offers a path toward that, that maybe some of these other things where you have to get into server hosting, managing runtimes with different versions, package management, transpiling, compiling, build steps, that kind of thing.

I think there might be an easier way for people to dip their toes in and have a full experience, and I'm hoping that Plenty is kind of pushing the Jamstack forward in that way to make that a viable solution.

00:08:49 - Anthony Campolo

I absolutely agree. I think that the performance benefits you get from Jamstack are, like, a single dimension among, like, six different dimensions of potential trade-offs that come with the Jamstack. And for me, the general paradigm of having an immutable site, because it's like this thing you're putting somewhere and it's not just running, like it's something that is going to be produced the same way every time. That, to me, is what I find is a really interesting idea, what you just can't get from a server because the server is always changing and it's not reproducible in the same way.

But I'd be curious to get a little more fine-grained into Plenty. So is there a router? Are there data-fetching components? What are the conventions that are actually in this framework that make it a framework?

00:09:33 - Jim Fisk

So this kind of goes back to definitions, right? So I'm trying to think about how people have been marketing these concepts for a long time. First of all, I've heard some other episodes that you've had as well. And Jamstack is kind of an interesting term because there's a lot of things that are JavaScript, APIs, and markup, right, but they're not Jamstack. And then static site generation, on the other hand, makes something seem like it's a lot more simple and flat and less dynamic than it actually can be in reality.

So I'm trying to move toward talking about this in terms of build-time rendering versus on-demand rendering. So I think of Plenty as a build-time rendering framework, or a framework engine. And the idea being we're going to compile everything, all your front-end assets, at build time, and then we're going to deploy those. It doesn't mean that you can't have really dynamic experiences on the front end in terms of interactivity, but also, as long as you have a good ecosystem behind you, you can actually have a full-stack experience in terms of databases, user authentication, and that kind of thing.

And I think there are great projects, like Netlify has a lot of tools in that system, things like Supabase and PocketBase. And those things are coming out that help with that as well. So I'm thinking the way we're doing things can have a full ecosystem around that.

As long as you have a good starting point, and that's where it gets into, like, what is Plenty, right? So Plenty is a set of tools. You can think of it as like a Hugo or a Jekyll or Gatsby-type project, where you're doing things like: there's a router that's automatically in there, so you can do page routing. It sets up your HTML fallbacks on the back end, but actually hydrates everything in the app to a single-page application, so you get really fast client-side routing and interactivity. So you can do transitions and things like that between pages if you wanted.

Also, there's a lot of implications for doing that for the CMS. And I definitely think that's the big thing that's changed Plenty since the last time we spoke, is the CMS was just a dream at that point, with some rough sketches and some rough ideation, but now it's a real thing that can be used.

And that was kind of the initial vision of Plenty from the inception, right? So the idea was I wanted a reactive front end and a fast build time. So that's why the back end is Golang, to do a fast build, and then Svelte on the front end to create a very interactive interface. And we've put those things together. You can actually do some interesting things with the CMS. So I definitely would love to talk about how that's integrated and why I think it's a little bit different than some of the other solutions out there.

00:11:31 - Anthony Campolo

Yeah, I would love to get into the CMS stuff, because I remember you talking about this at meetups where I saw you presenting Plenty, like, a year and a half ago and saying, like, yeah, we're going to have a CMS one day. And I'm like, good luck with that. So it's great to hear that that actually exists now.

But let's put a pin in that for a second, because as you were describing all of that, the thing that I'm getting is that the way to think about it is that it's almost most similar to Hugo, because it's giving you really, really fast build time and a static site generator. But the difference is that it's Hugo, and then you also have that component framework already built in. It's like Hugo, but you also have Svelte at the same time.

So here's a bit of a curveball. Do you know anything about Elder.js?

00:12:12 - Jim Fisk

I'm definitely familiar with the project. Nick Reese, right? The stuff that he's done that I've seen is amazing in terms of an SEO-focused framework and the speeds of his builds. I haven't built any production apps in Elder, so I'm not an expert by any means, but I'm definitely familiar.

00:12:24 - Anthony Campolo

Yeah, that one is, now that I'm thinking of it, sounds the most similar to me because it's giving you that really fast build time with the Svelte stuff built in. And Elder was cool. I went pretty deep into it for a while and started building my site out with it, and then gave up on the entire idea of building my own blog, period, and stuck with, like, Dev.to and Hashnode. So that wasn't Elder's fault. That was me not wanting to run my own blog. Elder was really, really great.

So let's get into the CMS stuff. When you say Plenty has a CMS, what does that mean?

00:12:54 - Jim Fisk

Yeah, that's a great question. There's two kind of concepts. If you're looking at Netlify's definition of these things, they have a website, I think Jamstack.org, where they explain there's kind of two main routes you can go for Jamstack-style CMS.

There's the headless CMS, which is like a Strapi, or you can even use Drupal or WordPress in that way if you wanted to, where you have a full-stack application that is hosting content and defining content structure. And then you have an API between that and your front end app. So when it builds, it actually pulls from that back end and builds that into a front end experience. And that's the headless CMS approach.

The other approach is the Git-backed CMS approach, which is actually deploying a front end app with your static site. So you'd have something like a Netlify CMS or Tina CMS or Plenty, and that front end ships with your site. And then what it does is it communicates directly back to a backend Git server. So that could be something like GitHub or GitLab.

So you can make edits on your front end site and it saves to a Git repository, which then usually you'd have something like a CI process looking for changes. And when a change comes into the right branch, it would rebuild your site and then it could even redeploy it. So that way you get this full application lifecycle in a static site that doesn't have any servers managed anywhere.

00:13:58 - Anthony Campolo

How would you host it or deploy it? Where would you put it?

00:14:03 - Jim Fisk

So I think the simplest example, and I'll speak of Plenty specifically, is we have a GitLab backend right now. So what you would do essentially is you could push your sites to GitLab. And then there are, I don't know if you're familiar with GitHub Pages or GitLab Pages. GitLab is a very similar concept where they have static site hosting built into their platform.

What you can do is basically say, okay, I'm going to have a CI runner in my repository as well. And so when I push things to that runner, it's going to rebuild the site. And essentially what happens is on GitLab Pages, so on your remote URL, you can log in, and we do authentication through something called PKCE, or Proof Key for Code Exchange. And that's a way that you can actually log in using the GitLab API. And then that will give you a token on the front end of your website that allows you to start editing your website. And then you can do saves from there. And without a server, it can write directly back to GitLab, which saves to that repository.

Typically, it's your main branch that'll kick off CI, and then it'll send the changes back to you. So you feel like you're editing a WordPress site without a server managed anywhere.

00:14:58 - Anthony Campolo

Okay, that's really interesting. And the CI stuff is where this is a little foreign to me because I don't use a ton of CI kind of platforms. I've done very rudimentary stuff with GitHub Actions, and I've heard people talk about Buddy. There's this Buddy platform that I think does kind of CI type stuff like that. I don't know if you've heard of that. Could you get more into the CI layer? Because I haven't used GitLab very much. So is this something that is analogous to GitHub Actions?

00:15:27 - Jim Fisk

Exactly. It's very similar to GitHub Actions. There's a couple reasons why I decided to build out the GitLab backend. First, eventually we'd like to have a GitHub backend and some other platforms as well. But GitLab has really been on the forefront of some of these tools from the very beginning. I think in terms of their CI runners, their environment, way before GitHub Actions had a really fleshed-out CI runner environment. They had a lot of tools like authentication for your GitLab Pages, which I don't know if GitHub has now. They probably do. And they had a lot of other things like Let's Encrypt SSL certs for custom domains and all these things that GitHub has been slowly catching up on. But GitLab has been, you know, a year or two ahead of them on that. So we decided that it was a better back-end platform for the project to begin with, just because the tools are more fleshed out now in terms of what CI is.

So continuous integration, CI, CD, you hear sometimes continuous integration, continuous delivery. The idea is basically on some event you're spinning up a Docker container to run something, to do some work. And in terms of Jamstack-style sites or build-time rendered sites, what you're essentially doing is you're saying, okay, there's some change happening to my code repository. Usually that's like the code repository is slightly different than the output that gets delivered to the user. The output is really static HTML and some interactivity with some JavaScript, but your back end can be a little more complicated. So what it does is it spins up a Docker container when a change comes in, and it compiles all that into a front end website, and then potentially it deploys it to maybe a Netlify or CDN or just GitLab Pages or something like that.

So as long as that CI file is sitting there, so it's a configuration file on GitLab, it's like called GitLab CI YAML or something like that, a small YAML file. As long as you have that in there, GitLab knows to look for changes that you specify and will rebuild and redeploy your site.

And so what that does is it allows you to cut out the server entirely, right? So your back end becomes basically a Docker container that spins up only when it's needed to recompile changes, then spins down and you don't think about it again. And it allows you to have essentially a freely hosted site that is pretty fast, pretty secure, and something that you can hand off to a client tomorrow, and they could edit without any technical experience.

00:17:16 - Anthony Campolo

Yeah, that makes a ton of sense. And as you describe it, it's very, very similar to GitHub Actions. And I know that GitLab is something that historically has been much easier for people to self-host themselves. I'm not sure if it's really even feasible to self-host your own instance of GitHub, but I know that's something that people do with GitLab quite frequently. So yeah, it makes sense. That would be the thing to build on.

And I'll be curious to know, once you've kind of gone through the process of porting that to GitHub Actions, what that looks like. So I bet that's going to be a very interesting experiment. I have a friend, Brian Douglas. You may know him, Bdougie, who was kind of like the GitHub Actions advocate for many, many years, and it's an incredible platform. So I've barely even scratched the surface of what it can actually do.

00:17:58 - Jim Fisk

One of the interesting things is GitHub Actions and the GitLab CI are almost completely independent of the CMS project. So what the CMS needs to work is really an API to authenticate, and then basically a commit API to write changes back to the repository. So the CI, you could do the full thing that I talked about without GitLab CI. You could introduce, like, Travis CI or Drone or Woodpecker or one of those other CI environments. And so the CMS does not depend on GitLab CI in any sort of way.

Right now, that's just one way of building your site. So once we port over to GitHub, you could use GitHub Actions, but you could also use Travis or whatever you want at that point. The thing that's holding us back right now with GitHub is that they don't support PKCE. So in order to authenticate to GitHub, you actually need to run an intermediary server, which is fine. That's something we could spin up and we could offer as a solution, either open source or something that we host.

But I really like the idea of making Plenty as complete a solution as it is by itself in its truest, most open-source, individual way. So you don't need anything that I'm doing to use it and host it. You can set it up on your own infrastructure and it works. And I feel like not having GitHub support PKCE right now is kind of a barrier to that that I would like to see fixed. I opened an issue with them to add that.

00:19:08 - Anthony Campolo

Could you explain, actually, what PKCE is? I don't know what that is, so I can say I probably don't know what that is.

00:19:12 - Jim Fisk

So it's just a method of granting an OAuth workflow, right? Previously there was something called implicit grant. If you've ever done any OAuth before, for people who aren't familiar with OAuth, it's like you want to authenticate an application, for instance, your Plenty website, but you want to use it with the authentication provided by a different service. So in this case, GitLab, right? So you create a user and a password on GitLab and you have an account, and then that account has repositories and things that it has access to, right? And what we're doing is we're essentially using that authentication that's created. They have a database and they have a bunch of stuff actually going on. We're just using that to give us a token on our other app that says, hey, that authorization workflow went through, that worked, and we can now use it to dictate what we can do on our application over here. So OAuth provides that.

And there was a way of doing that before called implicit grant. But implicit grant had dangers of vulnerabilities like man-in-the-middle attacks and things that could potentially take your token and pretend to be you and do things that you don't want, right? So PKCE is a way of doing this in a more secure fashion. So essentially what we're doing is we're creating a random string, then we're hashing that. We're doing, like, I think SHA-256, or I can't remember exactly which hashing algorithm we're using at this point, but we're essentially setting it up in a way that only the server and us know exactly how to exchange these keys. And then it has a way of giving us the token based on that information, which makes those attacks a lot harder. So it's a more secure way of doing the authentication without having to have a back-end server running in between.

And that was kind of the sticking point why GitHub didn't do implicit auth in the past, but I don't really see a reason why they shouldn't do PKCE auth, since that is a newer concept that should get around some of those things. So I'm hoping that they'll reconsider that at some point. And there's a lot of support on that ticket so far. I think that's a lot for a small project. I think there's like 11 or 12 people who've thumbed it up, so I'm hoping that at some point they'll look into that, but it might need a couple more.

00:20:51 - Anthony Campolo

Yeah, well, drop lots of links and resources to all those things that were just said. For anyone who's listening and thinking, I don't know what any of these things are, but this is stuff where people who have gone into OAuth, they'll learn OAuth. You could get a job as an OAuth expert at this point. It's such a deep, deep thing. But everyone deals with authentication, whether they deal with OAuth or not. So you need to know enough of it to have some idea of the surface area so you know how it's going to interact with your own code.

And this is making me realize now, when I was at Jamstack Boston, I did a Web3 presentation. You had a lot of really good questions about security and about crypto wallets and stuff like that. And I understand now why, because you're very deep into this authentication flow.

00:21:30 - Jim Fisk

Yeah. And just to clarify, I hope that this is stuff for folks who are interested in the back end of the project, but you don't have to even understand OAuth or any of this really to build a Plenty site, deploy it, and use it. You really just need to have a GitLab account and then deploy it, and then just put your repository information in the right place, and then it should just work. And you shouldn't really have to know what PKCE or any of that stuff is. That's just more of the project maintainers. And I know obviously you like to know the back-end stuff, but I'm hoping that people who are typically using this application aren't going to need any of that.

00:21:59 - Anthony Campolo

Yeah, no, that makes a lot of sense. And I think keeping authentication abstracted away, but in a way where you can dig in if you want to, that's, I think, the right balance because you don't want it to be totally proprietary. Because then people ultimately will never feel like they're actually safe. If they can't verify the code themselves, they can never know truly what is being done with their data. So having it be open source, having it be verifiable, you can make it a hidden implementation detail, but it's still important to have it there for the people who actually want to look at it, if they are so inclined.

00:22:28 - Jim Fisk

Yeah, exactly.

00:22:29 - Anthony Campolo

Something that I wanted to get into, another thing to kind of step back a bit when we're talking about this being a CMS, and this is something that I think we've touched on very briefly in the last episode. The back end is like a repo, right? There's not a database. You've got JSON objects that are kind of representing the data.

00:22:47 - Jim Fisk

Exactly. So it's flat files, it's all JSON, and that's exactly what's representing the data. And there's a couple of things that are different about the way we're doing things versus some other folks, right? So a project like Hugo, for instance, it has defined keys, right? There's certain ways of doing things. It has, and again, it's been a while since I've done some Hugo, but like, you know, it's like title is a specific key. It means a specific thing there. And then if you want to put things in general content, your own freeform stuff, again, I think this is more in the front-end template, you have to pull it out of something called params. And there's a very specific API structure to how you define your fields.

Plenty is not like that at all. So Plenty is completely freeform in terms of how you want your JSON, which makes it really nice if you want to pull from an external API and you're just pulling down JSON that maybe you don't have any control over the structure of it. We allow you to define whatever content structure you want.

And then what I think makes our CMS a little different than some of the other Git CMSs that are out there is that, first of all, we're really tightly coupled to the framework. This has an advantage of avoiding a lot of duplication of work. So a lot of CMSs, when you're building out your site, you're building out your field structures, you're building out your display. And then when you want to build your CMS, you actually have to map the CMS. You have to rebuild it and then map it to the fields that you defined in the site that you created. Plenty is just one application. That CMS is so tightly coupled to the experience that you're only building it one time. So when you're building out your fields, your CMS should already be tightly coupled to that. So it already knows about those fields. You don't have to rebuild it again and map it.

The other thing that's different, when you're tightly coupled like that, it makes things like previews really easy. So I think one of the challenges with a headless CMS is you don't really get previews, right? You have this back end where you're filling out a form, and then maybe you're doing a deployment process. Then you're kind of seeing what it looks like on the front end. With something like Plenty, since it's tightly in there, you have an editing interface and you can see exactly what those changes are doing on the front end, whether you're swapping images out or you're changing titles or whatever you're doing, adding new components. You can see it directly on the front end happening in real time.

Another thing that I think is a little different is we're doing this in such an interesting way where we have this full single-page application, right? Essentially, your whole application is hydrated. So what we're able to do with the CMS is we're able to employ a little bit of magic where you can edit the site and it looks like you're getting real-time edits like you would in a WordPress site. So you can change pages, you can add new pages, you can upload new images and put them on a page.

And now, you know, in reality, because you're a developer who's familiar with Jamstack, this has to go back to a Git repository somewhere, kick off a CI process rebuild, and that whole process happens and that can take some time. But the user on the front end should feel like that's all happening in real time. So they're changing things, they're updating things, and they're getting their updated site immediately because it's happening on the spot. But in the background, the process is kicking off. So the next time they do a hard refresh or they come back to their site or an external person sees it, they get to see those changes as well. But it should make that whole process feel seamless. At least that's the hope.

00:25:18 - Anthony Campolo

What about something like styling? Are there going to be built-in styles for this as well? Because that's something that's common in Hugo and some other Jamstack or static site generator-type ecosystems.

00:25:28 - Jim Fisk

So in terms of styling, do you mean the CMS interface or the front end website? Or can you elaborate a little bit?

00:25:34 - Anthony Campolo

Like, I guess when you're using Plenty, how much are you building out yourself versus what is the dashboard?

00:25:41 - Jim Fisk

Mm-hm. Okay. I think of it more as an almost completely from-scratch framework. Although it doesn't mean you can't use other people's styles. So, for instance, there is a concept of themes in Plenty, and on our website there are some themes.

00:25:53 - Anthony Campolo

That's what I was getting at. Yeah. The themes idea.

00:25:55 - Jim Fisk

Yeah. And you know, there's all sorts of things like component libraries and other things, so you're not reinventing the wheel. I feel like one of the methodologies that I have is I like to build from scratch as much as possible. And I know that's probably the anti-developer mantra, but I feel like a lot of times what happens when you start adding lots of other competing frameworks, like you put Bootstrap in there and next thing you know you're using like 10% of the underlying library, but you're carrying around 90% of the cruft. And for me, it can make life a little more difficult.

So I actually think Plenty is really geared really well toward building small, maintainable sites from scratch. And then hopefully all the annoying things that you have to do are taken care of by the actual generation itself, like the routing and that kind of stuff. So you don't have to think about that too much.

00:26:31 - Anthony Campolo

Yeah, I think that makes a lot of sense, and I think that is where it's going for a lot of developers. It sounds like, I don't know if you use Tailwind at all, but with Tailwind, you're given conventions to style very quickly and easily, but you're not being given styles unless you're using Tailwind UI. You're being given these utility classes, and it's like you build your own thing and it's going to let you style it however you want. It's just going to give you some kind of guardrails around CSS, and I'll be getting more into that recently. I'm starting to really dig it.

00:26:58 - Jim Fisk

Yeah, it's like Plenty probably does fewer guardrails than that. So we're really kind of like, here's a base toolkit unless you want to use a theme or something that's already been created.

00:27:05 - Anthony Campolo

Yeah, with Plenty, you probably wouldn't need it to handle that because Tailwind already is solving this problem. So you would just use Tailwind with Plenty if you wanted to do that.

00:27:13 - Jim Fisk

Exactly. And so I think people have their own methodologies for some of this stuff. So there's probably opportunity in the future to grow and maybe make that process of pulling in other people's stuff easier. But for now it's like it's really just a small build-from-scratch framework, because I think folks that like to do that, it makes it so you have a really small footprint for your end application, right? By the time you're deploying it, you can have like a 50-page website that's pretty interactive that has very small code attached to it.

And obviously, I think Svelte does so many things right in terms of scoping styles and having single-file components and all that. And I think it really just makes the maintainability of applications really nice. I've built a couple apps that I'm in the process of building, and I think they're somewhat large scale. They have some back end stuff as well, but the footprint of the code is really small and maintainable. Of course, the person who writes that code always thinks that, right? And maybe the next person who comes along and looks at it won't think the same thing. But I really am enjoying that smaller code footprint in my own dev.

00:28:03 - Anthony Campolo

Is there anything else you want to hit on in terms of either Plenty or the CMS?

00:28:08 - Jim Fisk

Yeah, there's a couple concepts I want to talk about. So we have this other thing that we're trying to do in terms of the CMS. I'm calling it the discoverable CMS. And the idea there is that what it's doing is it's doing some analysis on your content source, and it's trying to figure out what kind of editing experience can be assumed based on that content source.

So what we're doing is you don't actually have to set up any field types to start, right? So you can basically add a content source. So maybe you're like, okay, I have a homepage, I want a title, hero image, this and that, and you just write some JSON, right? The CMS will automatically try to pick up on that and give you an editing experience out of that. So what it does is it tries to say, okay, this is probably a standard text field. This is an image that can be swapped out with our media library, because there's a whole media interface in there for managing images and documents and things like that.

It spins that up automatically. So you have a zero-configuration editing experience out of the box. And that's kind of the default of what we have set up. In the future, this is something that I'm working on right now, building out more schema-based things. So if you want to override and have a very specific experience where you're like, okay, this is a checkbox field, this is a specific widget here, then you can set up your own CMS experience exactly how you want it. But out of the box, it should just give you something that makes editing kind of sane out of the box. Does that make sense? Have you seen anything trying to do anything similar? I haven't really come across too many examples like that.

00:29:22 - Anthony Campolo

No, it's hard to have a fully integrated experience like that. So I think that sounds pretty great, and I couldn't think of anything off the top of my head that is kind of like that.

00:29:31 - Jim Fisk

I think if we left it at that, it would be challenging because, you know, we try to assume certain things. We have regex on the back that will look at a certain field and be like, this looks like a date field, and we'll try to give you a date widget out of that. And so obviously sometimes you might not want that to be a date field, or you might not want it to be a boolean or something like that. There are times where you might want to override that experience, but we just want to make it as easy as possible to get something spun up without having to think about it.

00:29:53 - Anthony Campolo

Do you have other things that have influenced how you've designed this, like other editors that you're pulling bits and pieces from to create this kind of thing?

00:30:00 - Jim Fisk

Definitely, like the concept of doing this was influenced by Netlify CMS. Netlify CMS probably wouldn't have been on my radar so soon. This whole concept, like, okay, maybe you don't need a back end, you can just have a Git-backed experience. Netlify CMS was early to that. Tina CMS is doing it now. We're doing it.

So there's a lot of folks in that space doing this general concept of doing CMS. So that's hugely influential in terms of the actual nuts and bolts of building out field widgets and how we're doing the mapping of the CMS features to the website features.

It's really coming out of just a lot of daydreaming, trial and error. I have this certain developer-type experience that I want users to have, but I'm working backwards from the experience, right? So I'm like, I want this to happen, and I'm trying to shoehorn the actual technology into something that actually fits that experience. And it's pretty challenging. It's taking a lot of trial and error, and sometimes there are things I want to do that I have no idea technically how to do until I start doing them and iterating on them.

So it's been a lot of a learning experience. I really haven't found too many concepts of the discoverable-type CMS yet, so I would love to see if other folks are doing that kind of thing anywhere. Yeah, a lot of conversations with folks and just kind of thinking on it, honestly.

00:31:03 - Anthony Campolo

That's really interesting. And I have not used Netlify CMS and I have not used Tina CMS. I've heard of both of them. I remember the first time I heard the term Git-backed CMS. I thought it just meant like you had a GitHub repo, like some markdown files. That's just regular Jamstack. You're talking about a whole different thing here. And so it took me a while to be like, what are people actually talking about when they're talking about these Git-backed CMSs?

But it's really interesting because it's leaning more into something that's kind of like a Drupal or WordPress, where you actually have something where you can edit content, because that's what you don't actually have with traditional Jamstack.

00:31:36 - Jim Fisk

Yep. And this kind of goes back to I have this theory, and I know a lot of people disagree with me on this, but division of labor between developers and editors. I know you're not from the Drupal world, but Drupal by default will ship an editing experience that has site-builder functionality built into it, right? So they have things where you can edit images and change text and create new pages, delete pages, content-editor-type things. They also have site-builder-type things in there. So you can functionally change how the website works. You can install new modules, you can change the filtering, you can change SQL queries because they have this concept called views where you actually build lists of things. You can do that all through the editor interface, which is pretty amazing that they've built this low-code way of doing things. And it's really helpful for people who are, you know, when they're trying to bootstrap their own site and they're building their own site and they're not really technical, they're trying to figure things out.

So it's really great. But what most people are doing in this industry is like they're agencies, like my agency, and they're trying to build a product for someone and then they're handing it off. And what you're forcing developers to do is carry around a lot of baggage from a low-code experience. It actually makes your job harder because you have this code side of things. You have this user interface side of things. You have to sync those things up and you have to kind of carry them around. And then from the editor side of things, there's a lot of extra confusion there, because there's all sorts of tools that are not meant for them. There are things devoted to the actual maintenance of the website that they don't want to see. They just want to edit the website. And so there are ways you can pare those things back and pull them out, but it creates extra work for everybody to kind of get on the same page there.

So I was of the mind that I want to have the developers doing developer things in the tools that are comfortable to them. So that's something like VS Code and Git and those kind of things, and they're just doing that directly in a way that's comfortable to them. And then the editors, they don't have to think about any of that either. They're just doing the editing things of the website and then merging those things together. I think the Git-backed CMS really allows that to happen. So everybody's speaking the same language. Everybody's speaking Git. A developer can debug something that some content editor did because it's tied to their name and their commit, and you can see exactly when it happened and how it was introduced. And so all those things are kind of like a merging of those technologies. Everyone can speak a common language, even though they're coming from very different perspectives. That was really appealing to me. And that's kind of why I really wanted to see this project through specifically.

00:33:33 - Anthony Campolo

Yeah, it sounds really cool, and I definitely encourage listeners to check it out. We'll have links for Plenty and all the stuff we've been talking about in the show notes. And one other thing I would be curious just to get into a little bit is you also lead Jamstack Boston, which was a local, now virtual, maybe local again meetup. I'd be curious, what's it been like running a meetup both pre- and post-pandemic and all that?

00:33:56 - Jim Fisk

Yeah, it's very different. I miss a lot of the in-person interactivity of the meetup. So we had awesome sponsors. We had people putting us up for office space. We had food sponsors. Oftentimes, the office would provide drinks, and we had other people coming in trying to market services. So we had a great ecosystem of folks trying to help the meetup. And that was really awesome.

And then we had tons of people coming through. So some nights, a big night for us would be like 40, 45 people. I mean, it was really nice to meet people, a lot of new folks getting into web development for the first time. There were some other people who had been in it for decades and had a lot of different perspectives. And everyone's there for the same thing, to learn and meet people and that kind of thing. So that was great, and I really miss that.

The virtual has been cool in another way because we're getting speakers from all over, different time zones, different locations. Honestly, it's easier to run because there's less moving parts in terms of sponsorships and place and that kind of stuff. So it's way easier to run. But the numbers are way smaller, at least for me. I don't know if everyone experienced this during COVID, but I think people were getting burnt out of being online on Zoom calls all day long. And then when it came to, like, 6 p.m., did you want to get on another two-hour meetup? And I think a lot of folks were just a little burnt out. That's at least what I'm assuming.

We've been playing with a couple of different ideas. We really haven't been as active as we'd like to be normally, but I like the idea of kind of shorter mini segments, like having someone come on and talk for 30 minutes or whatever, and then do them more often, like every other week or something like that, versus having these big multi-speaker nights that go for two hours when everybody's tired at the end of the day, like once a month or once every other month.

So we might try to do some more rapid-fire things like that, because I know there's a ton of people, and they're creating some small project that they want to share. Or, you know, maybe they work at a company and they're trying to do some developer application that way. So there's all sorts of people that have interesting things to say.

I actually really love, also, when there's new folks to tech who are just learning something and they really are just dipping their toes in the water for the first time, but they're sharing their experience. I think that's really great for people. And also I think it makes the whole thing more inclusive to people because we get tons of new folks coming from boot camps or whatever that are just learning for the first time. So I love when we get those kind of talks, but it's hard to find people who are willing to venture out on the ledge like that when they feel inexperienced.

00:35:57 - Anthony Campolo

Yeah, I mean, that was exactly what I did. I started doing meetup talks about Redwood far before I had my first job, and that was one of the ways that I kind of started to get experience, speaking about tech and getting out and just doing it. And I really love having meetups like this available for that kind of reason. I feel like it would have been a lot harder for me to have built that credibility if I wasn't able to go out and speak at these meetups.

And the physical-to-virtual transition is really hard, and you have to really lean into the strengths you do get from it. And I think what you said about most places taking a big hit in numbers, that's definitely true. And I think it was even worse in that a lot of them just stopped entirely. Making that transition at all requires an entirely different skill set and knowledge set, and it's tough. But it also means that for the ones that have stuck around, I think there's still a lot of value from it.

And I would look towards thinking of it more like how streamers look at it, where you can go live and start streaming to an audience, and the audience can interact back, even if just through a chat. And they can do that very quickly and easily without a lot of friction. I think that's where meetups should go, because then they can continue to get out there and be in the community and be a presence and bring on other speakers, but do it in a way where you're not having to put in a ton of time and energy and scheduling and people RSVPing, like this whole process around meetups, that doesn't necessarily translate from the real world to the virtual.

00:37:19 - Jim Fisk

Yeah, totally. There's a lot of space to do some new stuff, and I feel like I wish I had more time to do it. I think something you said was really interesting: when you were just beginning on that journey, you actually went out there and spoke. And I think that this is a misconception for new folks. So it's great that you did that, because I think a lot of new folks, they look at someone who's senior and they say, okay, that person knows so many concepts that they can not only do the deep concepts, but they can also do what I'm doing, so why do it? And the truth is, you actually lose that perspective over time.

So if you've been in a framework for ten years, you actually lose the ability to communicate those beginning steps to someone who's new because they're so taken for granted that you forget what you take for granted. So I was doing some work with someone recently, just pairing on some terminal stuff and doing some server things, and there are just things that I forget people don't know. Like, I'll be like, oh, just grep that real quick, and they'll say, Grep? And, oh, it's a search utility. You have to explain these things. And it's just like things you take for granted. You lose the ability to do it. So I feel like I would love to see more new people doing it because they have a perspective that will fade. And it's just like you want to capture that while it's there, because it will be gone.

And it's sad that we lose that beginner content because people are too scared that it's not useful. So I don't know. I'm glad that you did that. That's awesome. I hope more people do it.

00:38:26 - Anthony Campolo

Yeah, for sure. And to what you're saying, I have a friend, Jen Jannard, and she reached out to some people trying to get into DevRel and was talking to me and a couple others. And both myself and someone else convinced her to basically create a stream. And she does this four days a week, brings on guests and has them teach her stuff. And she had been working at an API company, not doing coding stuff. So she was working with tech and not fully getting it and has decided now to really learn it and start coding, and basically went from zero when she started the stream.

And she's had, like, Misko, the creator of Angular, on to teach her Qwik and stuff like that. So it's been really cool. And I think that's been a really great example of just how you start with very, very little experience. Like by the time I started speaking, I'd already been kind of learning to code in the shadows for like two years. And that's why I hadn't had a job, because I'd been learning this stuff. But there was no way to kind of show that, to have that kind of social proof of what I had learned until I kind of went out and started speaking. And so even there, there was a certain gap in terms of I'd already gone a little bit beyond the boot camp kids.

But now if someone is starting at the beginning of their boot camp streaming, it is a whole different thing, because then you can get content that someone can kind of follow along with when they're starting from zero, which I think is really cool.

00:39:43 - Jim Fisk

That's such an interesting perspective because coding is so weird. It's like there's this tipping point, right? Because there are all these concepts, and you need to know 50 concepts before you can do a simple thing, right? It is so challenging to do. And I remember I used to go to meetups and it was basically like cracking a fire hydrant and just sticking your face there and having it blast you in the face, because I would just smile along, not understanding almost every word that was said.

And then I would hear the concept, you know, I'd go to five meetups, hear the same concept five times, and say, okay, this is starting to make sense to me. And I at least had a pillar that I could start building on. But that beginning process is so hard, and I think I totally understand why people don't want to put themselves out there. That's great that your friend is doing that. It's such an interesting idea, and it sounds like it's working really well for her, so that's awesome.

00:40:20 - Anthony Campolo

Yeah. After she had been doing it for about six to seven weeks, she got offered a part-time DevRel job that is not the most blingy, most awesome job out there. But I was telling her that it took me over two years, I'd say between two and three years, to get my first job. And when she first started telling me that she was going to do this, I'm like, this is what you should do. If you do this, you do it consistently and you do it right, you will have a job within a couple months. And that is what ended up happening.

So I throw down that gauntlet to anyone trying to get into tech. There is a path, and you can see someone do it in real time now, and I feel very confident about that.

00:40:57 - Jim Fisk

Yeah. That's awesome. She needs to write an e-book or something because I did something similar to what you did. I was working at a data storage company and I was taking these online classes at night to learn some programming, but I did that for probably a year, learning some SQL stuff, before I could even try to think about a job. But yeah, that's pretty fast how she did it. So that should definitely be an e-book or something.

00:41:16 - Anthony Campolo

Yeah, part of it's just the DevRel angle. And this is, I think, a big post-COVID thing where, because everything went digital and everything went online, and you needed people who could just run a stream, that set of skills all of a sudden became much more valuable. Even if you can barely code, like you can barely use the terminal, it's like if you can run a stream, that means something and it's not simple. And so it's not something to look down on, like, oh, we're just bringing in someone to run the streams. It's like, no, actually, that's a hard thing to do. And that's a real skill set to hire for now.

And you can leverage those kind of abilities. If you're trying to get into tech and you have some content creation abilities, you can pair that with the learning you're doing and show real value on day one.

00:41:56 - Jim Fisk

Yeah. And anyone who thinks just running a simple stream or YouTube channel is easy, just make a video. I was trying to make a tech video yesterday, just helping fix this VS Code bug. And I was on my partner's computer, and we had to fix the resolution and the audio inputs and all this, and it just took forever and was so frustrating. So if people think that's easy, just try to record something and see how easy that is. It's a whole process. And there's other things besides the technical aspect to it as well, obviously.

00:42:18 - Anthony Campolo

Awesome. Well, thank you so much, Jim, for being here. This was a great talk. Let our listeners know where they can find you and where they can find what you're working on.

00:42:27 - Jim Fisk

I'm Jim Fisk on, like, most things. So Twitter or LinkedIn, probably. So yeah, Jimmy Fisk. You can find me on YouTube as well. We have a YouTube channel that has a Plenty devlog on it. So our channel is the company name, Janq'u. So, Janq'u, because I know people aren't going to be able to spell that. There's a ton of other stuff on there, just open-source things like learning how to use OBS Studio and those types of things. There's a lot of videos in that realm as well.

Yeah, check us out there, and Plenty, that's Plenty with an L, that's the website. If you're interested in the project, fully open source, we'd love to have contributors, people testing, what have you. So yeah.

00:43:02 - Anthony Campolo

If you check out Jamstack Boston, you can find the meetup as well. So that's one more for you.

00:43:06 - Jim Fisk

Thank you. Yeah. Check out Jamstack Boston if you want to speak at it. All you beginners out there, hit me up. There's contact information on there. I would love to have some more folks coming in and talking.

00:43:17 - Anthony Campolo

Yeah, definitely. I've spoken there twice and it was a great time. So I highly recommend people reach out and look forward to having you on in another year or two to see how things are going.

00:43:26 - Jim Fisk

Yeah, thanks so much for having me back. This was great talking with you again.

00:44:00 - short split/interjection

And cut.