Today on Day Two Cloud we talk with developer Herman Martinus about his open-source blogging platform Bear. We talk about how a developer views infrastructure and operations, and how he went about building his platform.
We discuss:
- Why Herman wanted to build a blog site
- Dealing with scope creep and feature requests
- How he looks at infrastructure
- Bear Blog’s architecture, including Python, Django, and Heroku
- Supporting users as an open source project
- What developers would like ops and infrastructure folks to know
- More
Show Links:
herman.bearblog.dev – Herman’s blog
Herman and Jason Spin The Yarn Podcast
Transcript:
[00:00:10.490] – EthanWelcome to day two. Cloud. And today we’re talking with a developer. That’s right, a developer. We’re talking to someone who actually makes product and then hosts it on infrastructure. We’re talking to Herman. Herman is the developer creator of Bear Blog. It’s a minimalist blogging platform. Ned. Right. [00:00:30.410] – Ned
That’s right. We found him. We tracked him down. We bagged him. We’re going to tag them. We’ll release them back into the wild when we’re done. But first, we got a lot of interesting perspective on how a developer views infrastructure and also how he went about building this sort of minimalist blogging platform. I found it, frankly, fascinating. [00:00:49.550] – Ethan
Yeah, it really was a wonderful bridge between the world of developer and operations. So if you’re on the op side of the house and think those developers are just awful people, I think you’ll have a different opinion when you’re done listening to the show. So enjoy our discussion with Herman Martinis. Herman Martinez. I think I said that right. Right, Herman? [00:01:09.180] – Herman
Okay, maybe I was close enough. [00:01:11.320] – Ethan
Welcome to day two, cloud man. It’s great to have you on and tell the nice people listening who you are and what you do. [00:01:17.370] – Herman
Yeah, great to be on. I’m Herman Martinez, and I am the creator of Bear Blog, which is an open source minimal blogging platform, and I work on that alongside a bunch of my other projects, but that’s where I’m spending most of my time right now. [00:01:36.190] – Ethan
And Bear Blog is going to be the focus of our discussion today. But before we get into that, I think I noticed, doing my research that you have your own podcast, right? [00:01:44.770] – Herman
Yeah, it’s a good friend of mine who works at AWS. So for you infrastructure people and we actually don’t talk shop that much on our podcast. It’s mostly just looking about at things that are interesting and having a nice chat once every two weeks. The main reason is he moved to the UK, and we just wanted a good excuse to have a chat every now and then. [00:02:12.650] – Ethan
Yes. Okay. That sounds like fun. I should tune in and check out what you guys are talking about. Spy on you. Well, the focus of our conversation today, Herman, is Bear Blog. We do want to talk about your pet product here, so would you tell everyone, give us a summary of what it is at a high level? We’re going to get into the technical stuff as we go. But just for now, what is Bear Blog? How do you price it, that kind of thing. [00:02:35.490] – Herman
Cool. So Bear Blog is, in the purest sense of blogging platform. You can use it as a blog, and that’s pretty much where it ends. We don’t extend it in the way that we would say extend WordPress. It is your words on the Internet, and it is currently free if you’re happy with a bearblog dev domain. And then if you want to swing a couple of dollars my way for beer. Then you can get your custom domain as well as media management because as you know, hosting image files can be quite resource intensive and I don’t want to offer that to everyone for free. I don’t have VC money. [00:03:23.970] – Ethan
Not yet. [00:03:24.530] – Herman
Right. [00:03:25.810] – Ethan
Who knows who’s listening to this podcast right now? Herman? Yeah, I appreciate bear blog for exactly that. I’ve been a WordPress user for many years, going back to at least 2007, if not before. So I’ve seen WordPress grow and change over the last 1516 years that I’ve been using it. It’s become such a bloated behemoth. It’s a content management system, it’s a plug in architecture, it’s a million things. And it really kind of hit me within the last year when I went back into the PHP to customize something that it’s like I’m lost now. I actually can’t do this anymore. I used to be able to do this and it’s so convoluted and so complex, trying to figure out through the rat’s nest of PHP what’s going where, that I’m over my head and if I did make a change, I wouldn’t want to have to maintain it. And I began looking around for other things and bear blog came up. It’s like I just want to write and as you put it, my words on the web. That’s all I’m looking for. I get to write and markdown, publish, and it’s good. And I am throwing the monthly beer money your way so I could get my custom domain and upload the occasional image and all of that. [00:04:31.430] – Ethan
And I love how fast it is, how quickly a page loads with bear blog, something that, having spent an awful lot of time with WordPress, trying to optimize page loading time and dealing with caching and dealing with image optimization and all the rest of that stuff, it’s an endless rabbit hole. You go down trying to optimize that stuff, it’s like they’re just words. Then you look at the HTML payload of what all got delivered and it’s like, wow, that’s just crazy what WordPress has become. Anyway, I think I’m singing your praises, herman, for what bear pockets and appreciated and thank you that you came on the show to share with us what’s going on in the back end. [00:05:11.410] – Herman
Well, I’m I’m straight down with you. I come from the trenches of WordPress as well, and I had my own blog in WordPress. I used to work tangentially with WordPress when the need arose, but when I went to refresh my personal blog a couple of years ago, I went through a whole host of different things. I tried out jackal for a little static site generator, I played around with hugo, I even went as far as literally writing pure HTML files and then popping them on the internet. And that actually worked fairly well, but I wanted a little bit more to it. So I initially actually built Bear blog for me, and then I actually built the first iteration over a weekend. And I wrote a little bit about it on Hacker News, and I came back to my computer and everything. Was on fire because I had the hacker news hug of death just bearing down on what was, at the time, A-4-A month heroku. Dyno. [00:06:24.250] – Ned
When you initially created Bear Blog over that weekend, were you think of it simply as a platform for just you to use or did you already have ambitions of letting other people leverage the platform as well? [00:06:37.790] – Herman
So this is the way that I tend to develop tools is I develop with the implicit assumption that if I really want it, someone else will probably want it. So as an example, today I spent my whole day working on a telegram bot that tells you the load shedding schedule depending on where you are. And for those who don’t know what load shedding is, I’m in South Africa and the electrical utilities company can’t keep up with demand. So we have planned outages and I just wanted a telegram bot to tell me when’s my outage and so I bought that and sent it off to a bunch of people and now they all use it as well because I knew it was useful to me. And so Bear was that same philosophy. I really wanted a simple blogging platform. There’d also been a lot of talk on Hacker News and related communities at the time about the good old web. We like our HTML files and CSS and JavaScript is going to kill us all. One of my little design constraints is I’m like, okay, we’re not going to have any JavaScript on Bear and I’ve pretty much stuck to that except for a couple of Asynchronous button clicks every now and then and I’m very happy with the result. [00:07:57.590] – Ned
That was actually the next question I wanted to ask you was about sort of scope creep on a platform because I think a lot of platforms or tools have started out with that very simple philosophy. We just want to render words on the Internet real easy and then people will start asking for features, oh, could you add content management? Or I’d really like a shopping cart, or can I just run my entire enterprise business on your little platform? So what do you have in mind to stave off the scope creep? And what do you think is within scope for what Bear Blog should be able to do? [00:08:35.290] – Herman
Well, I’ve gotten really good at saying no and so I actually come from a background of video game development. I worked as a video game developer for about three years and then made games on the side. And the thing about video games is that they’re so big and complicated and you can always add significantly more and this applies to software tools as well. But video games are just a whole other behemoth and so if you actually want to get anything done. You want to ship anything, you have to mercilessly cut features. There’s a video game from the early 2000s called Eco, and they have this interesting design philosophy called Design by Subtraction, and that’s where they essentially bolt out what the system would look like, and then they just removed everything that didn’t emphasize that core mechanic. So they removed the whole you can have different weapons and you can have your different suits of armor, and they just gave you a stick, and you don’t even have a Hulk bar. What you do is the point of it is it’s a fetch quest. You’re escorting this person and lol demons come and try and take her away, and you whack them with your stick. [00:09:55.880] – Herman
And that emphasizes the core mechanic of the fetch quest and the relationship that gets built between these two characters. And so with my other tools and with Bear, I like to set a very narrow scope of work and then just solve that in the best way possible. I don’t want to faff around with anything else. I certainly don’t want to become the next WordPress. And so if you go into Bear Blogs GitHub issues list, you’ll see a whole bunch of people requesting things like support for this and that, and wouldn’t it be cool if we could do this? And I’m like, yeah, but no, I. [00:10:37.280] – Ned
Appreciate that very much because I looked at the platform a bit, and I’m very curious about it, and I don’t want it to get bloated out like WordPress eventually did, because that’s the nightmare I’m currently dealing with. I’d like to get off it. [00:10:54.530] – Ethan
So, Herman, you’re primarily a developer, it sounds like. So do you like dealing with the infrastructure that you inevitably have to deal with? [00:11:02.870] – Herman
So I’m not a big fan of dealing with infrastructure that I inevitably have to deal with. I do it like I eat green things. I know that it’s the healthy thing to do, and I have to try and force myself to do it regularly and in the correct quantity, but it doesn’t come naturally to me. I used to spend a lot more time doing it than I currently do, and we’ll talk about some of the design choices for Bear a bit later. But what I wanted when it came to infrastructure is something that was super simple and that solved the problems fairly well without me having to spend too much time in them. So it’s kind of like a set it and forget it system, which is the holy grail of infrastructure. [00:11:56.710] – Ned
So many times in the marketing materials that are foisted on infrastructure people, we’re always told that developers want what you’re talking about, but it’s nice to actually hear it from a developer and not a marketing professional. [00:12:10.970] – Herman
Well, so at one of the companies that I used to work at Is, we had a dedicated Ops person, and he used to spend a decent amount of time playing video games during the workday. And my thinking at the time was like, this guy is actually a pretty decent Ops dude because everything’s working and he can go and he can play video games. [00:12:40.130] – Ned
Yeah, if he’s running around putting out fires, that’s not always the Ops person’s fault. But sometimes it can be an indication that they’re not taking an automated or hands off approach on things. [00:12:55.190] – Ethan
When you look at infrastructure then, Herman, as a developer, what are the things that are most important to you? Is it cost? Is it performance? Is it just ease of consumption like a good API? [00:13:05.850] – Herman
So cost and performance are important things to me. And with Bear, performance is definitely way up there. I did play around with a bunch of other bits of infrastructure and interestingly enough, Heroku seemed to be a very good fit for it. And I know that is actually running, running on top of AWS. So what’s actually happening over there is AWS is pretty performant, as should be the case. Cost is less of a is less of a roadblock for me based purely on the fact that I hope that when something becomes too expensive to maintain, I also have enough people giving me money that I can pay for that and it’s sort of like solve the cost problem a little bit later. As far as API goes, I do want a really good ease of development. So that is a very high priority to me. High priority to me. Preferably I’d be able to just push to a GitHub repository and then automated things magic happens in the background and I’d like to kind of know what’s going on over there just in case anything goes wrong, but preferably my changes go live. There’s a very easy rollback mechanism and there’s not too much hair off the top of my head. [00:14:30.150] – Ethan
This is very interesting to hear your perspective. We tend to talk to more infrastructure professionals than developers on this show and I’ve been wanting to cross pollinate more, have more developer conversations to get your perspective. You really do want that decoupled experience between your code and the platform that it runs on. You don’t want to have to care about it that much. It sounds like Herman. [00:14:52.590] – Herman
So I recently went and ported Bear to run on some of my own infrastructure, a little Linux box, and I did all the things, I wrote the Bash scripts, I got the virtual machines, I did the dockers and in the end it ran beautifully. But I felt that if something went terribly wrong, I would have a much harder time dealing with it. Whereas what I like about the decoupled experience is that I’m kind of offloading that responsibility onto someone else. And in this case it’s salesforce, which is misplaced trust, I think, especially considering what is actually happening with Heroku right now. But I do really want to focus on building the product. I’m definitely more in the product design and development side than the actual nuts and bolts. If I could have an Ops person sit in the back of the office and just make sure that everything runs seamlessly, I’d probably do that. But as a second best option, I’ll use a service. [00:16:09.590] – Ned
Yeah, maybe one day the beer money will become Ops money, and then you can have that back playing video games because everything’s working fine. [00:16:17.790] – Herman
Exactly. I really want to pay Ops people to play video games. [00:16:25.130] – Ned
All right, well, I like video games, so we might have a good side hustle going there. Let’s get into the nuts and bolts of what’s running Bear blog. So from a development perspective, what is the architecture for Bear Blog look like? [00:16:41.110] – Herman
So Bear blog’s architecture is actually similar to its design philosophy is that it’s super, super simple. I went with the Django Python framework and then that’s hosted on Heroku, which, as we mentioned before, is rarely just abstraction on AWS. And there’s a very good reason for this, is that I know Django very well. I’ve used it in multiple projects, and I can pretty much get anything to run fairly well on Django. [00:17:16.570] – Ethan
It’s not just, you know, it herman. I mean, a lot of people know it very popular. [00:17:20.210] – Herman
Yeah, exactly. So if I need someone else to pick up some of the slack, I can very easily find a Django developer. And more importantly, and I’ve played around with cloudflare workers and a whole bunch of these, the new stuff from Gcp, like firebase functions and everything. And the issue that I have with those is that there’s a lot more unknown. Unknowns. Right. We know how Django works, we know how it fails. And I’ve got a reasonable certainty that if I run into any issues with it, someone in the community has already answered that question and I can get up and running in no time. Whereas with some of these newfangled frameworks, there’s a good chance that you’re going to run into an error that no one has ever dealt with before. And especially if you’re using, say, Azure or Gcp, you’re probably not going to find anyone to talk to about it. AWS is great in that respect. You can get in touch with a support engineer in no time, but I don’t really want to have to rely on getting in touch with these companies to make things work. [00:18:38.950] – Ethan
And Python, as a coding choice with Django, I mean, performance wouldn’t be the first worry for Bear. Is that fair to say? [00:18:49.130] – Herman
So I went and I did run some very simple benchmarks. And yes, you can get a lot of more performance out of using something a bit lower level, like, let’s say, for instance, you ran it in Rust. You could theoretically squeeze out a bit more performance. However, I’m super familiar with Django and it runs reasonably well on the infrastructure that we can give it. So it was the conscious trade off between like, how long do I want to spend learning a new programming language and framework, getting that up and running on some infrastructure, and then keeping in mind that I would have to maintain that theoretically indefinitely. And so I really wanted to go with something that I knew worked very well and had a bunch of community knowledge around it and that I could reasonably support going forward. [00:19:51.850] – Ethan
Yeah, I have no idea what your user load is on the back end, but I can say from my experience using it. I’ve been using it every day for about a month now. My experience has been everything’s instantaneous or nearly instantaneous, whether I’m doing a preview, uploading an image, just writing and then publishing it’s all right there and it just happens immediately. There’s never any waiting delay, beach balling or any of the rest of it. It’s a very snappy experience. [00:20:17.830] – Herman
I’m glad that you’re having a good experience with it. I’m also having the same experience, and of course this comes down to having a very simple design, but also because there isn’t any JavaScript that loads into the page. The pages are tiny. They are 2.5 to 5 pop kilobytes. [00:20:40.770] – Ethan
Did you hear that, audience? 2.5 to 5 KB, not megabytes. [00:20:44.580] – Herman
Yeah, teeny, teeny, teeny, teeny pages. It turns out that text doesn’t actually take much space, and then if you do have an image that’s loaded from it’s, provided by a CDN that I don’t have to run. So that’s all it was on cloud front, maybe. [00:21:04.200] – Ethan
Yeah. [00:21:07.750] – Herman
It’S actually through DigitalOcean’s own image CDN. And also because we don’t have one of these JavaScript frameworks that’s essentially running everything on the front end and then making asynchronous requests to the back end, there’s a lot fewer things to go wrong and also a lot less feeling of slowness. So when you have asynchronous requests, you press a button and the page loads. And the thing is that everyone who uses the Internet is familiar with that flow. You click on a link and it takes you to a new web page. And for some reason over the last five years AWS, we’ve decided that actually users really don’t want that. What they want is they want a custom loading spinner and it’s doing exactly the same thing, it’s just more prone to error. [00:22:07.050] – Ned
I’m curious because I have started building some static sites. For instance, for another podcast of mine called Chaos Lever. We use a static site generator, it’s using Hugo and then it’s just hosted on Azure’s static web apps because it’s free for under a certain number of requests. So free is always nice. How would you compare what Bear Blog is doing with Django to one of those static site generators? Is it similar in the sense that you’re pre rendering the pages to just vanilla HTML? [00:22:40.210] – Herman
So, interestingly enough, we’re not actually pre rendering the pages on Bear and it is something that I am looking into doing but generally the CDN handles that fairly well and so I’m not getting a lot of load on the actual server itself. As far as the comparisons between static site generators and Bear goes is just the experience of reading is it? Everything else is completely different considering Bear’s got its dedicated back end for going and writing posts and editing styles and whereas Jekyll or Hugo for that matter, you actually have to go and change the physical files, regenerate and upload them. And don’t misunderstand, I love static site generators. And there is also a Bear Hugo theme if you’re keen to use the Bear blogs theme. It was ported by one of my users. He’s just like, hey listen, I’m really into static sites and I’d really like to use your theme. And I’m like, hey, we’re open source, you can do what you want. [00:23:59.370] – Ned
So let me just walk you through what my understanding would be. Then. When a request comes in for a page that’s rendered on the Fly by Bear blog, and then it’s probably going through a CDN, so the CDN will cache that version of the page, and as long as that page doesn’t change and the cache is still valid, that’s where you’re actually going to be getting any subsequent refreshes of that page or additional. [00:24:22.830] – Herman
Yeah, exactly. [00:24:25.250] – Ned
So it’s just that initial first render to get it loaded into the Cdns and then you’re good to go for. [00:24:30.490] – Herman
A while and the CDN will periodically go and re grab it. But it does mean that my server load is actually fairly small. Is that the Hacker News hug of death that I had right when I started Bear is I’m actually not on much larger infrastructure than that currently. I just happen to have a CDN up and running and it handles most of the brunt and we have articles up on Hacker News very regularly and we’re handling them perfectly fine and I think it’s pretty difficult to get that level of traffic anywhere else on the internet. So I’m hoping that that’s a pretty good stress test for the platform. [00:25:20.810] – Ethan
Yeah so I’ve noticed when I do an edit to a page because we were just talking about caching and refreshes here, that change is reflected immediately. So does Bear Blog, notify the CDN, hey, it’s time to refresh this or repopulate the cache or delete what happens there. [00:25:37.950] – Herman
So to be entirely honest, some CDN magic happens and Cloudflare scratches its beard and says like let’s update this. To be completely honest, I’m not entirely sure but it updates pretty much in real time. So once you publish that the next person who requests your page does get the updated version of it. So what my assumption over there is that the request is made to Cloudflare. Cloudflare kind of does a little comparison and that feels like it would be slower than it actually is. So the correct answer is I’m not entirely sure. [00:26:19.610] – Ethan
Okay, fair enough. Fair enough. Now, you mentioned pretty small infrastructure that you’ve got out there. Do you have a sense of the number of users that Bareblock could support? [00:26:27.390] – Herman
Yeah, so we’re currently running about 15,000 blogs, and depending on if anyone gets to the top of hacker news, we’ll have hundreds of thousands or up to say, a million requests in a day. Most of the time it chills more around the tens of thousands, maybe hundreds of thousands of page views per day. Theoretically, we should be able to increase that by an order of magnitude just based on my server load. And I’m not even on that big of a server, so I could just bump up that infrastructure and hopefully everything works out well. There’s also really nice Heroku tools to just handle all of that for me. I’m not sure if I’ve mentioned that there’s this great sort of decoupling between my experience and the infrastructural experience. [00:27:36.690] – Ethan
You’re leaning into Heroku in part. Like if you’ve got a bunch more users, like, say, because of this podcast, all of a sudden you’ve got a million bear blogs that you’re hosting, not mere 15,000, and things went up. You think Heroku, you could just lean into Heroku tools to scale up. [00:27:56.570] – Herman
I feel like I could. I reckon I could at least get to about 20 times the current number of users without having to do anything particularly intense. And if this podcast does get me another, let’s say a million users, then based on conversion rates, what that means is that I have Ops Money. [00:28:26.930] – Ethan
Yeah. More beer money. Ops money. Yeah. Well, talk to me about multitenancy, Herman. You got these 15,000 users. How do you keep me out of other people’s blogs or other people out of my blog? [00:28:41.110] – Herman
Right, so it’s not exactly a multi tenant system. Bear blog is actually built as a monolith. So it’s just one big old thing that’s running all of these blogs. And how I handle the different blog instances is just through Django’s normal user profile. So essentially, when you go and you register, you create a blog object and then I just assign your user to that blog object and only you have access to the dashboard of that. And that’s all guardrails within Django itself and then also within the code that I write. So it’s not, let’s say, like a service that spins up WordPress instances for you where you go and you sign up and they’ll actually create an entirely new instance for you. This is actually you’re just part of the giant machine that is their blog. [00:29:46.630] – Ethan
The giant machine, yeah, I get it. So the security is handled then by Django. That’s a mature framework. So you’re just leaning into that to get all of that separation done. Makes perfect sense, but it is an important architectural distinction. As you said, you’re not spinning up Ethan’s unique bear blog instance and then off I go, all in my own little world. I’m part of the machine and it’s just Django that keeps me separated from everybody else’s blog and everybody else’s from mine. That’s pretty straightforward. [00:30:16.010] – Herman
Yeah, exactly. I’m pretty happy to lean into Django over there and I do make sure to keep the versions up to date and all that stuff. Because if there is an exploit in Django, there are bigger problems than your blogging platform and hopefully we’ll be able to patch that up pretty soon. But Django security doesn’t keep me up at night. I think it’s very robust, very mature, and I actually trust it a lot more than something more custom made. [00:30:55.710] – Ned
Now, Mike, the experience that I saw, I watched a little demo video of how to use Bear Blog. Everything seems like it’s all marked down, which I love. I’m very excited about this. I discovered Markdown a few years ago when I was writing some technical documentation and they’re like, we use Markdown. And I was like, what’s that? Oh, this is awesome. It’s so much better than Word. And if you’re coming from rich text editing and Word, you’ll understand. Did you have to do a lot in terms of coding to facilitate the rendering of Markdown to the pages that Django is going to present? And did you customize Markdown at all to support special features that people might request? [00:31:43.090] – Herman
Yeah, so I started off with a Python Markdown engine called Mistune, and it provides some pretty good basic Markdown functionality. But I did have to extend it quite a bit. And it was actually fairly surprising to me that there were so many different Python libraries for rendering Markdown, yet none of them were as feature rich. AWS, say something that’s built on Node. And I think the reason for that is that people tend to use Node or JavaScript in general for the client facing applications. And actually doing Markdown rendering on the back end isn’t as popular, so there just weren’t as many options. This tune is great, but I did have to add a bunch of additional rendering things myself. I got really good at regex and so it is pretty feature rich. There are a couple more bits and pieces that I do want to add in there, but they’re super niche. As long as it’s got up to the level of footnotes, people are pretty happy. And I’m pretty happy. [00:32:59.770] – Ethan
Did you upstream your changes to Mistune? [00:33:03.700] – Herman
So I didn’t actually modify mistune itself. I do a render through Mistune and then I do a bunch of custom stuff because there are a few things that are specific to just Bear. So let’s take for instance, if you want to add your email subscriber form in line, that’s a custom thing that is getting rendered into the page. [00:33:25.330] – Ethan
Yeah, got you. Well, speaking of customization, Bear Blog gives people the opportunity to customize their theme with their own CSS. And as I. Was thinking about this. From a developer perspective, that feels like a minefield. If you’re giving people the opportunity to add code like that, is it a big deal or not really. Did you add, like, special guardrails to keep people in bounds? [00:33:45.770] – Herman
Well, so I do have some rendering guardrails in place to make sure that people aren’t doing anything malicious. And I very regularly get people tinkering about and trying to exploit the system, and everything’s fairly tight. I once even reached out to one of them and I’m like, hey, can you please stop doing this? It’s really annoying. And he sent back, and I just assume he’s rush and he’s like, I am enjoying this bear and mouse game. But overall with the CSS and actually just people’s content in general, the main things that I’m doing is just making sure that they’re not injecting malicious stuff into the page. And that’s fairly straightforward because, again, Django’s Templating system can handle a lot of that themselves. And because you’re abstracted away from the database with an Orm, it already has all your basic injection exploits kind of covered. The biggest problem that I have with CSS is protecting people from themselves. So they’ll go and just write absolutely terrible CSS. And then I’ll receive a support email like, hey, I can’t see my content. I’m like, that’s because you’ve got a black background and black text. [00:35:14.690] – Ethan
I don’t think I’m any CSS expert, but I don’t think I’d make that mistake. Yeah. [00:35:21.110] – Herman
With that particular case, and yes, it did happen is the default theme has a dark mode and a light mode where it just uses CSS queries to check what the user’s system preferences are. And it will change the background to it’ll change the text and the background that essentially invert them. And someone went and explicitly set their text color to this. And then they obviously open their computer at night and they’re like, I can’t see anything. [00:35:49.390] – Ned
They just highlighted the page. They would have seen all the text there. [00:35:52.900] – Herman
Exactly. [00:35:55.090] – Ned
That’s something that I would have done. [00:35:59.650] – Herman
I actually have so much patience for bear users because they are generally technical people and they’re always very polite. So I run another tool called Just Sketch Me, which is a 3D modeling tool that runs in your browser. And a lot of those users are very young and very few of them are technical. And so I’ll just get the worst customer support emails from them. Like, I have one feature and just being angry. And then with Barrow, I’ll always get one like, hey, man, I love the platform. I love what you’re doing. Can you please help me out with this? And I’m like, yes, sir, I will help you out with this. [00:36:48.290] – Ned
Yeah. The difference in tone certainly makes a big difference in how you’ll respond. And I’ve had similar experiences with some technical people. I’m always amazed when I get a really rude person. I’m like, where’s your empathy, man, we’re both dealing with this kind of stuff. You’d think you’d be like, oh, I know how terrible it is when people come to me like this, but not everybody is like us, I guess. You mentioned a few times that Bear Blog is an open source platform. Can I self host it? Is that something that I can do, that you would recommend doing if I wanted to spin up my own instance in Heroku? [00:37:27.470] – Herman
So you can absolutely go and spin up your own instance in Heroku. However, you would then be hosting the monolith that is bare. You wouldn’t be hosting an individual blog. And so I guess the reason that it’s open source is well, it’s multifold is that the first one is it keeps me honest is I really like software where people sort of see what’s going on behind the scenes. And especially in the age of the attention economy, I think that people have become disenfranchised with platforms and tech in general. And having it be open sources, people can actually go and qualify the things that I say. And further than that, it’s actually pretty good publicity is I can then say this is an open source blogging platform and people like open source. That’s a good word. And it also on top of that allows people to open pull requests if they really want to. If they’ve got like a feature that they’re burning with desire to have, they can open up a pull request and then I can scratch my bearded for a little bit and decide if it fits within my this is my opinionated idea of what Bear should be. [00:38:49.180] – Herman
But overall it’s been really good. It’s been possibly one of the best decisions for Bear. [00:38:58.170] – Ned
Are you currently looking for folks to help out with the open source project? You’re looking for developers or someone to help with documentation or anything like that? Or are you content to keep it just you? For the moment? [00:39:09.650] – Herman
I’m actually very content to keep it just me based purely on the fact that this is a it’s kind of like in its maintenance phase. Yes, I am doing some development on Bear but it’s generally like improving features and then adding the very begrudgingly adding new features is that I don’t actually need a full time, I don’t actually need that much assistance with it. It’s a fairly constrained scope project and it’s gotten to the point where it is and people appreciate it for its simplicity and it doesn’t actually need that much more done to it. So I’m perfectly happy to run it myself. But I do also have, and not to get too morbid, but I do have someone else who understands the system and who can take over the reins from me if something tragic happens. So that is one of the important things that I have had to think about because a lot of people are hosting something that’s fairly important to them. And so it’s my responsibility to make sure that it does outlast me. I mean, I’m only 30 right now and I plan to hit at least triple digits. [00:40:27.750] – Ethan
You raise a valid concern that I think has come up before. It was in one of your blog posts. How do any of us know the Bear blog as a SaaS offering? How do we know that’s going to be around permanently? [00:40:38.970] – Herman
Yeah, so that’s actually a very good question and it is a question that I have gotten quite a bit recently and it’s the main reason that I did write the post. It’s titled Software That’s Built to Last Forever. Or Building Software to Last Forever. And in that I pretty much explain the reason that I use the infrastructure and the services that I do. And actually to circle back to another reason why Django and Python Python were such a good choice, is that let’s say, for instance, salesforce acts in bad faith and they decide to completely mix Heroku. I can very easily move the entirety of Bear over to a different platform and I have actually done that in a few tests just to make sure that it is very easily possible. So making sure that it is platform independent was a big reason for me. And then on top of that, and I made the joke earlier about not having VC funding, but that’s also an explicit decision, is that when I first launched Baron, it was starting to get a lot of traction on Hacker news. I actually had a handful of people reach out to talk about potentially offering me money. [00:42:01.350] – Herman
And firstly, it’s really exciting when someone’s like, hey, do you want some money? Terribly exciting. But I actually explicitly avoided taking that on for multiple reasons. But the main one being that I really want to make my own decisions when it comes to this platform. When you take on funding, you’re beholden to someone else to build that new feature or push for monetization. And we’ve seen this with platforms like Substac and Medium, both of which I respect, and they are arguably good platforms. The problem that I see is that they have a very strict incentive towards monetization because they have to for higher monetization. I mean, in the United States, it’s pretty much the law you got to maximize shareholder value. I can ensure that Bear isn’t going to it’s not a grow or die company. And that’s one of the main problems with VC currently and we are seeing alternatives to that with your microfounder or sorry, your micro VC firms that essentially do a profit sharing system or something like that, where you kind of try and align your incentives a bit better. But believe it or not, with just beer money is I’m actually making more than I was at my day job as a developer. [00:43:41.360] – Herman
So I guess it’s not really just beer money and it is actually a sustainable career, and that’s on a minimalist blogging platform. It also just allows me to do that thing where I go and play video games if I’m happy with the software as it is. And currently I am, I’m working on a few minor things at the moment, but I’m very happy with where the software is. I can guilt free go and play the new Last of US game, which is great, by the way. And I’m not really beholden to anyone else to push out features or butts and seeds. [00:44:28.790] – Ned
Very good. [00:44:30.390] – Ethan
Well, Herman, this has been a great conversation about Bear. I have a parting question for you that’s kind of apart from Bear blog itself. You’re a developer. You’re talking to a lot of infrastructure people. So if you can impart some wisdom for us here, tell us something that folks on the Ops infrastructure side of the house would help them understand developers needs better. [00:44:52.270] – Herman
So I think that this one is very opinionated, and it’s something that’s discussed a lot, but I think that premature optimization is, in a lot of cases, kind of detrimental. And again, this is just my personal opinion, but for a period of time, I was mentoring startups in West Africa, in Ghana, and they would let’s take, for instance, build their website. And their website would just be it could be a static site, it could even be a Wix site, right? But they would have kubernetes orchestrating all types of weird and wonderful things, which I’m sure that they had a great time setting up, but it was way too much for what they needed at the time, and it would be complete whole for anyone else to maintain. And I know it’s a fairly boring parting wisdom, like, don’t over optimize, especially in the beginning, but it’s one of the main issues that I’ve seen, especially new entrepreneurs and new developers just kind of bumped into again and again. [00:46:07.650] – Ethan
Very good. Keep it simple. If you can keep it simple. Keep it simple. Yeah, that’s 100%. And those of us that have been building systems for a long time, I think would very much share your opinion in that. So you say you’re opinionated, but I’m definitely of the same opinion. It’s like, why did we bring in this massively complex thing to deliver this one service? Why are we doing yeah. Keep it simple. If you can keep it simple. Well, Herman, how can people follow you, Bear, any of the rest of those things on the web? Where would you send them? [00:46:37.630] – Herman
So you can find my personal blog at Herman Bearblog Dev, and I’m also not on social media, so that’s pretty much it, herman Bearblog Dev and I. [00:46:50.150] – Ethan
Figured out how to get a hold of you through that. So I guess that’s good enough. Very good, Herman. Thank you for joining us. And thanks to those of you that are listening. Virtual high fives to you for tuning in. If you made it all the way to the end. You are an awesome, awesome human. If you have suggestions for future shows, ned and I would love to hear them hit either of us up on Twitter at day two cloud Show. Because unlike Herman, we are on social media. [00:47:11.930] – Ned
But maybe you’re not. [00:47:13.130] – Ethan
Maybe you’re like Herman and you’d rather not use the Twitter. Fine. There’s a request form on daytoolcloud IO. You can fill that out. We’ll get your show idea, and we’ll see if we can make it happen. And if you like engineering oriented shows like this one, we know you do. Visit PacketPushers. Net subscribe. All of our podcasts, newsletters and websites are there. All nerdy content designed for your professional career development. And until then, just remember, cloud is what happens while it is making other plans.
Podcast: Play in new window | Download
