In today's episode, I interview designer and developer David Hemphill. Today's episode is sponsored by Digital Ocean! Use the code "DeveloperTea" at checkout to get one month of a 1GB droplet, completely free!
In today's episode, I interview designer and developer David Hemphill.
Today's episode is sponsored by Digital Ocean! Use the code DeveloperTea at checkout to get one month of a 1GB droplet, completely free!
Please take a moment and subscribe and review the show! Click here to review Developer Tea in iTunes.
Hey, everyone, and welcome to Developer Tea. My name is Jonathan Cottrell. And in today's episode, I continue my discussion with David Hemphill. David is a developer. He has built a bunch of products on his own, and he's also part of Rebel, which we actually talk about in just a few moments. We also discuss Atomic CSS in today's episode, so make sure you stick around. Today's episode is sponsored by the fastest growing cloud infrastructure provider that is DigitalOcean. If you are looking for an SSD server that you can spin up in less than a minute, DigitalOcean is the answer to that problem. So we'll talk more about what DigitalOcean has to offer to Developer Tea listeners later on in today's episode, but I want to jump straight in to the rest of the interview with David Hemphill. I know that that's a great intro to talk about your Atomic CSS, beard.css. Yep. Beard is my... I call that, what is it? I don't even remember. Now I have to look at it. I call it an extremely pragmatic and utility-focused CSS framework. Yeah, so it's definitely in the same family of all of the Atomic CSS sort of libraries and strategies out there that you'll see. I think it has a leg up on a few of them, though. Well, first, let's say that you actually ask everyone not to call it. The extremely pragmatic and utility-focused CSS framework. You said, actually, don't call it that on GitHub. So I'm not going to call it that. I'm just going to call it beard. No, so here's the thing. Atomic CSS, for those of you who are unfamiliar with what this concept is, is creating CSS rules, or rather classes, that only... Only apply one rule and never allowing a rule to override another one. And David, you can refine that definition as it relates to beard further, if it's different in beard. That's pretty much it. It might cover a couple of rules, depending on what it is. But for the most part, it's a single class that does one thing. It has a single responsibility, and you kind of string all of these single responsibility classes. You can't just put them together to get the structure and the aesthetic that you would like. And so there's parts of this that I definitely agree with. I like the idea of immutable. Immutable classes that if you add this, for sure, it's going to work. And that's probably the most valid argument for atomic CSS, in my opinion. Yeah, that's even with... Object-oriented CSS, which is, I guess it would be the grandfather of atomic CSS. Yeah, that's the same kind of deal that you focus on the class as the unit instead of, I don't know, like deeply nesting selectors, or using the element selectors, or anything like that. You would just focus on using classes only. I want you to convince me that I should use beard. And here's... Here's my question for you. Let's say that I'm writing some markup. And I know that pretty markup is something that beard is not concerned about. Typically, beards are not concerned with being pretty in the first place. Pretty markup is not necessarily a concern. So, but what I do want to be able to do is relatively easily change the way that something looks in the future. So, would I use beard along with more CSS, for example? Maybe use beard as... I don't know, mixins, for example. Or would I need to go in and change all of those immutable classes in the future if I wanted to change a particular... So, let's just say I have a widget that appears on five different pages. And that widget has a selection of immutable classes that get applied to it. And let's say I wanted to change that widget on all five pages. How would I go about doing that? Would I need to go and change it in all five locations? Or would I add kind of a parent class and extend from those immutable atomic classes? How would that work? Well, definitely in today's sort of development ecosystem, it's not just like there's five HTML pages that you need to edit this widget on and where you have this five different... In five different places. You know, in the modern kind of CSS workflow, you would... Or if you're using something like React or a component-based system, you would... You have it in one place and you're using it in the multiple times. And so, if you would edit it in the template for that widget, you would... Those changes would be represented in all five of those places. That's the most common case that I see. And Beard's kind of written for people that are working on apps and not necessarily just marketing sites. But even though it's good for that and I've used it for that. So, if you had a widget on five pages... For me, personally, I find that when I'm authoring things, I'm not going to be able to I'm using some sort of include like that. If it's like a heading, a lot of times, if I'm using the same class again, I will abstract it out into a more domain-specific sort of class. I might say heading one or heading two. But in general, I'm not doing that. Most of the time, I know what heading I want. I know how to get it quickly because Beard is kind of inspired by VIMS. By VIMS. It's like composable classes or something like Emmet, where a class name, if you're just looking at it from the outside, might not make sense to you. But inside, if you know the system, it makes a lot of sense. So, you might have a BGB that stands for background black. Or a text color white would be represented by TCW. And that kind of, once you learn the system and kind of follow it for a while, it becomes really easy to write those classes. Over and over. Without having to look it up. So, what I'm taking away from this here is essentially that Atomic CSS is particularly most useful when those widget types are kind of secluded into an includable file. Right? So, in Rails, for example, that's a partial. In PHP, you just do like a require once. And I don't know what it is for other things. But for the most part, those classes... Classes are only going to get written once. And so, changing that particular thing only happens in one location. That, to me, is the most important part because the semantics are in the file name at that point rather than in the class name. Yeah, I think that's a Noel Gallagher quote. Because a lot of people are concerned about the class names. They're basically, they look like gibberish if you're just looking at them without understanding what they are. People are used to button. And button dark. And this sort of thing. And even other Atomic type frameworks, like Solid, you know, the BuzzFeed thing. They have like fill red, fill blue. And those are really kind of descriptive of what's happening. But in Beard, it's shorter because we want you to type less. We want you to write less. And get on with what you're doing. Because in the tagline, it says a CSS framework for people with better things to do. Personally, I wrote this because... Because while I enjoy design, I like building things. When I'm building products like PushSilver, I need to do a lot of things really quickly. And so it's kind of tailored towards that mentality. In Beard, there's this concept of like the scales. And so the type is on a scale. You'll have FT1 will be the first value in the scale. FT2 will be the second value in the scale. And then likewise, there's like border colors that are... You're using the first value in the scale. And that will be one color. It can be your... And it's usually your branding color that we have you specify earlier in the configuration. And it kind of gives you this... I don't know. It's almost a built-in style guide sort of thing that you can use too. For me, it helps organize some of this stuff. Sure. And that makes sense to me actually. Especially the idea that Beard and similar... Similar atomic frameworks. These are made for doing rapid prototyping. So you're putting a view up really fast. And typically, from what I've learned, particularly with these small short classes, these short CSS classes, a lot of that information about what that class is either is directly available in the CSS or it needs to be documented. Right? So let's say you run a large organization with 20 or... 30 people. Atomic CSS in this format is probably going to be harder for the new guy, right? Or the new girl to onboard with because they're going to have to learn all of this kind of domain-specific or platform-specific stuff. And if they don't have a guide or... Well, even if they have a guide, but it's a large guide, that's going to take them longer to digest, right? But if you are building a product, especially if you and a small team, like a restricted-size team, if you're building a product rapidly, then this is a great idea, right? It kind of has this interesting dichotomy of value for different-size teams, particularly because of the documentation problem. If you have this common pattern of naming classes, for example. So you have something like BEM, for example. BEM. BEM has this structural aspect. And if you can understand what the underscores mean and what the dashes mean, then you can kind of get an idea of what the rest of BEM actually is. So you kind of fill in the blanks. Whereas with something like an atomic set of classes, those blanks, if they are somewhat obscure, so text color white being TCW, you have to learn what... TCW means, right? And that's one thing. And then padding top being PT or something like that. PT2 or F... What was the F class that you mentioned? There's FT1 and then there's FW1. So font size one and font weight. Oh, okay. Yeah. So while that is certainly simple and shorter, for... Let's say you're... Onboarding like five new people a month, which is pretty fast, to be fair. But that level of documentation and training is significantly more than if you said, okay, underscores means that it's a nested element and dashes means that it's a modified element. Go forth, right? Those are two different conceptual things. My stance on this is that atomic is incredibly valuable, especially if you have a team that is smaller and is kind of restricted in size. In other words, it's not growing at a rate that is faster than, say, one person every month or two months. Yeah, I could see that. But you could say that about Bootstrap. Every project like that has its own sort of nomenclature and built-in niceties that you kind of have to learn about. But definitely if you're having classes like ours that are basically... I don't know, they're not acronyms, but they're just shortened versions of the actual attributes that you would write in CSS, then, yeah, I could see how that would be difficult. Personally, I've found with the people at Musicbed, which is where Beard kind of came out of... Previously, we had this project called Kombucha that was sort of like Beard beta. They seemed to take it on really quick. They seemed to take it on really quick. And like it, because it sort of made a lot of decisions for them. So if you're designing something, a lot of times it's hard to decide what space you should use between elements. And this kind of limited your choices to anything one through ten. If you needed something bigger than that, you could definitely write your own class, but kind of following the convention, you would be rewarded for that. And it lended consistency to the interface. I find things like Beard, and BIM, not to be... They're not like competing philosophies, but I think they can actually be complementary. Because you could write a widget that has five or seven classes on it, and then this widget is actually used in a place where it needs to be positioned absolutely. And Beard doesn't have... It does have some absolute positioning classes, but if it's, you know, just a value that's not inside of Beard, I could see you definitely writing it. You know, a specific class just for that instance of that widget that would be different from, you know, somewhere else where you might use it. Does that make sense? Yeah, that's a great point. I think that this is all underlying a bigger point here, which is actually that CSS is difficult, number one. And number two, it's very broad, right? Like, you can do CSS in a lot of different ways. And so what you shouldn't do is try to pigeonhole yourself into only one way of thinking, right? So you shouldn't just think that BIM is the only way and you're never going to do it any other way. You shouldn't think that Beard is the only way, right? You shouldn't think that Atomic or, I don't know, Smacks. You shouldn't think that those are the only ways to do things because that closes you off to new ways of doing things. And just as you're saying, David, you can have this Atomic concept be totally living alongside BIM. And because CSS allows for it, that can be a very useful practice. In fact, quite honestly, that's basically how we work at Whiteboard. We use something similar to Atomic. So we have grid classes that are Atomic in nature. They mean... They mean one thing. They do one thing. We have padding classes that are Atomic in nature. We have some text classes that are Atomic in nature. In fact, a lot of what Bootstrap has in it, like you said, is Atomic in nature. You know, sometimes it'll have two or three actual rules built in, but ultimately it does one, maybe two things. And then alongside that, we layer our more semantic classes, right? So the things that are named. And that has actually worked super well. And so I guess I come at this from two perspectives. One, practically seeing it work really well, right? So from that perspective, David, you've totally won the argument. In a practical sense, Atomic makes total sense. From a software design perspective, that's where it seems like it shouldn't. But this underlines another point that's important for every software developer to be open to, which is, I don't know how better to say it than don't knock it until you try it. There are so many things that you learn in practical software development that theoretically seem wrong. Theoretically, you shouldn't do it, you know, this way or that way. But when you actually get into the work, you realize, hey, wait a second, that actually isn't all that bad. Yeah, that totally makes sense. Before Beard, I was using BIM kind of across the board and basically forced myself to do that. And there was a lot of pain in that because when you're using BIM, and you're using something like Sass, a lot of times you're doing extends inside of Sass or what's the other thing, includes. I haven't used those features so long since I've been using Beard. But you'll be doing that. And so you'll kind of have these attributes or these objects, classes, kind of obscured away in these really kind of domain-specific things for no reason. And I think that if you like couple BIM, kind of naming with something like OOCSS or Beard, you know, Atomic Framework, those classes that are domain-specific are really actually domain-specific and not describing something that is used in many, many different places inside your project. And so like display or the font sizing, all of those things can be global level things. Because, you know, CSS is really, it's global anyway. That's the main problem with it right now. Or, you know, some people will debate whether that's a problem or not. But I personally am on the team hate the cascade. But, and until we get some sort of CSS module system that makes all of this not useful anymore, then I think something like BIM and Atomic classes can live together in peace and make the development experience much better. You know, a lot of people will say with something like Atomic or even OOCSS that, well, that's no better than just using inline styles. You know, that's kind of... That's kind of like the first thing I hear from people that don't really understand it. I avoided saying that because I know that that's probably ignorant. Well, one, single classes are very non-specific and inline styles are the most specific you can write CSS. So that's... Yeah, that's the most important thing probably. Yeah, and... No pun intended. Yeah, I like that. And so, yeah, a lot of people will think that it's basically... muddying up the markup, you know, and that they're used to handcrafting their markup and they don't want a machine, you know, to spit out their CSS form kind of thing. But basically, markup is for machines. It's for machines to read the markup and to spit it out and format it. And so I don't necessarily reject a programming concept just because it's kind of ugly. You know, everything has to be weighed on its own merit. And aesthetics is one of those merits. But also, if... something being more visually appealing comes at the cost of being less maintainable, slower to work on, more costly, you know, that kind of thing, then, you know, aesthetics might have to go out the window for there. You know, the fact that we can argue over this kind of thing shows a few things. One, CSS still has a lot of room to grow before we figure it out. Right. But perhaps more profoundly, development or programming is still something that requires opinion. And it's still something that requires experience to determine, you know, what is a good way for this particular scenario. And that changes. It's not the same for every scenario. It's not the same for every person. It's not the same for every team. These things are not set in stone. They aren't concrete. And what works for... for David or for me or for you, if you're listening to this show, if it works for you, if you love coding in Perl, I don't personally enjoy Perl, but if you enjoy Perl, then don't let other people tell you that you shouldn't enjoy Perl. Right? Like, if you enjoy a particular framework or if you found something that makes you productive, then go for it. There's not really a specific science to what should be done. There's not really a specific science to what should and shouldn't happen. Sometimes there are ways of measuring that and saying, well, maybe I should try something different. But if you experience something new, if you experience that, you know, I don't like Jonathan's way of doing CSS. I like David's way of doing CSS. Go for it. There are plenty of reasons why this is still a huge matter of opinion more than a science. Definitely. You can't use something like Atomic in everywhere. Even so. I can think of one case where, you know, a CMS might output markdown and you don't have the ability to touch any of the elements inside of that output. You can't, you know, apply classes to that the way you want. So, I mean, you're going to have to use something else. Like, maybe wrap the whole content div in a dot markdown and style, you know, something more traditional CSS-like. Mm-hmm. You know, so you're going to have to mix and match any of these approaches anyway to become, you know, a CSS. Come to a solution that's going to solve the problem you're trying to solve. And if you're like most people, the stuff that you're making on the web is temporary, number one. And number two, it's a living document. So, as you find new ways of doing things, just change it. It's live. That's one of the beauty, beautiful things about the web is that you can change it anytime. There's no reason why you can't experiment with new things, change things around. That's particularly more valuable for smaller teams and smaller companies. But as you find new ways of doing things, the web is not a book. It's not something that goes through a printing press and then it's done and you have to release new editions. That's not the way the internet works. The internet is constantly delivered. Brand new pages every single day. You know, dynamic delivery. It's an incredible process and you should take advantage of that and allow your learning to evolve with the things that you're making. This is not the space shuttle. It doesn't have to be perfect the first time. Exactly. It's not a piece of healthcare equipment that's going to keep someone's grandpa alive. Yeah. Well, thank God. Yeah. Because I don't know how many poor grandpas there would be if I was in charge of that. Definitely. If it's not rocket science. Not on purpose. Not on purpose. No. Let me clarify. Good intentions. Yeah. Yeah. David, tell me about Rebel. We've beat this CSS horse into the ground. So just for anyone who is wondering, I was playing the devil's advocate position there. I am not against davidsbeard.css. I want you to try it out. I want you to go to, there's going to be a link in the show notes. Go and check out this, would you call it a framework, David? I wouldn't call it that. I don't know what I would call it. You'd call it a beard. Just another tool in the belt. Go and check out beard.css, which is on David's GitHub account. Correct? That is your GitHub account, correct? I am. I believe it's under monarchy. Okay. Yes, it is. That link will be in the show notes at spec.fm. But now I want to switch and talk about Rebel. But first I want to talk about today's sponsor, DigitalOcean. DigitalOcean is the fastest growing cloud infrastructure provider because it is laser focused on its mission to create simple and elegant solutions for developers and teams. And that's not just a sponsor read. That is true. DigitalOcean has an incredible backend for developers. It's easy. It's easy to deploy. You can spin up a droplet that is pre-configured with pretty much any popular open source framework. It is built to scale. They have an API and floating IPs. So you can scale it as you grow. And you can create team accounts so that you can manage it with your team, not just on your own. You can select data centers from around the world. Or you can deploy across regions for redundancy. And probably the most important part is that they have straightforward pricing. You only pay for the redundancy. You only pay for the resources that you actually use by the hour. And there's no setup fee and no minimum spend. That means you can try out a server for just a few minutes and you're only going to pay for those few minutes. A couple of cents to try out a server. So you have almost nothing to lose but to put the icing on the cake, DigitalOcean has provided a special code for you to use at checkout to get a one gigabyte droplet for free for an entire month. That is not their lowest here. That's actually their second lowest. So you can get a one tier droplet and you get an entire free month by using the code DEVELOPERT at checkout. Of course, a link to DigitalOcean as well as that code will be available in the show notes at spec.fm. Thank you again to DigitalOcean for sponsoring today's episode of Developer T. Now let's jump back in and talk about Rebel with David. David, tell me about Rebel. Rebel is a company that has four partners and I'm one of those partners. We have Elias Reyes and Travis Gates and Ishmael Bersiaga. And we all play different roles but we're basically working on right now DonorGive, which is a giving platform for nonprofits. Very cool. So what made you see a need for a giving platform for nonprofits? Well, our partner Elias, he works with nonprofits and there's quite a few solutions that are out but they're... It's very, very dated. They don't have nice looking user interfaces. Some of the code's clunky. The reporting's not good. And so we set out to kind of solve that problem for a certain market of these nonprofit people. At Whiteboard, we work with a lot of nonprofits as well and there is a very much so a lack of support in this area for nonprofits. You'd be surprised, actually, because there's a lot of money in this particular business. And unfortunately, the platforms that exist, I won't name names, but they don't solve the problem very well. And so I'm really interested to see what Rebel ends up creating. Yeah, we're working on it. It's coming close to its beta, the first beta with our first customer. And I think we're getting somewhere good with it. It's been a long process. I've been... I've been... I've been... I've been working on it since, I think, July. And just to now get a beta out is a pretty long cycle. One of the longest projects I've worked on so far. Just for, you know, the needs of a nonprofit in this area is just, they're great because you need to have reporting, you need to have exporting, user management, donor management, and those are different. And, you know, funds and managing recurring, putting all of that on a schedule. And, you know, we're working on it. So, yeah, it's been a big project. It's been a big project. It's been a big project. It's been a big project. It's been a big project. It's been a big project. It's been a big project. Integrating with Gateways, all of that sort of thing. Security, multi-tenant application. Yeah, it's been a big project, which is maybe why there's not a lot of competitors in the space. Sure. A good job, at least. Or a lot of the solutions are installable software products and not web-based. Yeah, absolutely. Well, this is one of those classic kind of it looks easy from the outside kind of problems. Right? You think, oh, yeah, I could make a better version of that. And then you start working on it and you realize this is far more complex than I ever would have imagined looking from the outside in. For sure. For sure. Yeah. There's a lot of things that you don't see when you're getting to the beginning of the project until you get in there and realize that there's just a lot of video secrecies to all of these. And coming up with a solution that's generic enough and for multiple organizations to use is a tough cookie to crack, too. Yeah, definitely. Because everybody has their own way of figuring out payroll or how they pay out their, if they're a missions organization, how they pay out to them or that sort of thing or how they even count the revenue. It can vary from organization to organization. And most of these nonprofit organizations, they don't have a lot of energy to be able to change the way they do things. Yeah. A lot of it, they have a lot of legacy systems, then that's just how they've done it. Yeah. And they need to be able to import a lot of those contacts from those old legacy systems as well. And even importing old transactions so that they don't have a weird year where there's like kind of two reports if they switch over, you know. Yeah. There's all sorts of little things you get into. Yeah. And it's particularly, at least in the United States, I'm not sure how nonprofit stuff works outside of the US, but there's a lot of legal ramifications of what these reports are generating, right? This stuff ends up in the hands of, you know, the people who care about that 503C designation. So you can't get it wrong. That's right. It's incredibly important that the data is accurate and that you're not over or under reporting, that there's not any rounding errors in your stuff. Yeah. That's all big problems. They're kind of, you gotta have a good test suite to make sure all of that works correctly. Sure. Yeah. Yeah. And you're, so again, you're writing this in Laravel, correct? Yep. Using Laravel on the backend, using Vue.js for the dynamic parts. And of course, Beard has snuck itself in there. And it's working well, I assume. It is. It's playing more of a secondary role for... For like building out interfaces before he is able to get to it. And so sometimes I'll scaffold out the basic interface and he'll come in and sweeten it up. Well, David, this has been very enjoyable and super relaxed. I've enjoyed having you on Developer Tea this evening. Thank you for having me. I've had a good time. So I have a couple of questions that I like to ask everyone who comes on the show. All right. The first one is, if you could give every developer 30 seconds worth of advice, what would you tell them? I would tell them to always focus on the people they're building products for and not to be married to the tools that they're using because tools will eventually rust and break down at some point. But always to be pragmatic and build with the outcome that you want to have in mind. Not necessarily be married to dogma of what the current industry is doing, or what the current industry expects of you, or what they say is best practices, but to kind of weigh each situation with the data that you have and the expertise that you have and weigh that against the goals that you have. I love that visual of the tool rusting. You know, we don't think of digital stuff as expiring or as expendable. It seems like it could live on forever. And when it comes to that, it's like, oh, I'm going to have to do this. And when it comes to that, it's like, oh, I'm going to have to do this. And when it comes to that, it's like, oh, I'm going to have to do this. And when the computer starts to act kind of strange or when things slow down, we say that it's probably a virus. Very few times do we think, wait a second, maybe this thing is just getting old, right? Perhaps it is out of date. And I love this visual of the tool rusting because that's such an important reminder that the things that we build are not permanent. The people that interact with them, those interactions are the thing that we're building. We aren't building a building, right? We aren't creating a physical thing. We're creating something for people to interact with. And if we don't get that part right, then it doesn't matter. That's right. For the most part, this is not art. There are creative aspects to it, but it's problem solving and solution building. And so anytime you treat it as art, it really becomes more about yourself and not the people that you're building for. So the second question I like to ask everyone who comes on the show is what do you wish more people would ask you about? What topic do you wish more people would ask you about? I wish more people would ask me about getting products done with as little as possible, using as little as possible to get it done. Yeah. What way? Well, I mean, CSS is fun to talk about, right? It's fun to debate. And there's really not a situation you can arrive at that where there's like with a one true way. And back-end programming is just as subjective a lot of ways and different approaches you can do it. But there's something about getting the resolve to build a project, to build a product and market it and put it out there that I think is going to be a big part of the process. For me, that's been the most interesting thing doing. I like using technology and I wouldn't want to do any other job, but I really enjoy building products more than I do like any of those single aspects of it. Sure. Yeah. So that would be... That's great. So kind of the bootstrapping mentality. Yes. How to get from idea to shipped product as quick as possible. Yeah, that's... That's... That's... I mean, that's one of the most important pieces of understanding, you know, what it takes to be an entrepreneur. If you can ship early... When I started this podcast, for example, I had the idea and I shipped my first episode within a week. Now, that's not to brag, but instead to say that, you know, I move quickly. I intentionally decided that the idea and the implementation of that idea, there's an energy that kind of follows that idea that requires some level of action, right? And if you allow an idea to percolate long enough, if you don't act on that, then ultimately it takes more energy to think about it than it would have taken to just try it out. Yeah, that definitely resonates with me. And this new podcast that I've done, Dads in Development, is exactly the same way. I think we thought about it on Monday and we were going to meet to talk about the first episode and I said, let's just do one. He's like, well, my mic's not good. He had already bought one on Monday to do it. And I said, we'll just ship it anyways. We'll apologize in the show notes and we'll do it. And we launched it. We launched it the next Monday. And now you have a story to tell about the mic, right? Like there's always a way to look at these things with a different light. You don't have to look at it like, well, the quality of the audio is bad. You can look at it like, you remember that one episode where the quality of the mic was bad? Those are two different perspectives. One is kind of a memory and a story. And for those who listen to your podcast into the future, that'll be a moment in time for them that they can recall. And perhaps appreciate. Yes. There's no such thing as perfect. There's only good enough. And you have to decide when is good enough. And I prefer to say that earlier on. I prefer to ship it early. And because it's the web or it's something like a podcast that is serial in nature, you can just keep improving. Yeah, absolutely. Great advice, David. Thank you so much for sharing that and for coming on to Developer Tea. Thank you so much for having me. Thank you so much for listening to Developer Tea. I hope you've enjoyed the second part of the interview with David Hemphill. Of course, if you missed the first part, you can find it at spec.fm. If you don't want to miss out on any of the future episodes of Developer Tea, make sure you subscribe in whatever podcasting app you use. This does two things. Number one, it helps you be alerted in the future whenever we put out a new episode, which actually happens three times a week. And the second thing that it does is it actually helps you other people find Developer Tea because for every subscription, this actually helps Developer Tea get more exposure in places like iTunes. If you want to reach out to me, you can email me at developertea at gmail.com. Of course, you can join the spec Slack community by going to spec.fm slash Slack. That is free now and it will always be free to Developer Tea listeners. Of course, you can follow me at Developer Tea on Twitter. And in fact, every single day, we tweet out the latest episodes, so that's a good place to keep up with the show as well. Thank you once again to DigitalOcean for sponsoring today's episode. DigitalOcean is the fastest growing cloud infrastructure provider, and that's for a very good reason. They have some of the most user-friendly ways of spinning up a server that I've seen. Go and check it out, especially if you are looking for a cloud hosting provider, digitalocean.com. And of course, you can use that special code to get the one gigabyte droplet, for free for one month. Thank you again to DigitalOcean for providing that for Developer Tea listeners and for sponsoring the show. And thank you once again for listening. Until next time, enjoy your tea.