#216: Resolving our own git mess

This week we did what every developer swears they won’t do - we broke our own Git workflow.

Join us as we chat about what went wrong, what we learned, and where we’re heading next. This conversation is a reminder that even experienced developers get rusty without practice. If you can relate, or just simply enjoy Julian's git puns, leave a comment!

And while you're at it, check out our Pybites Books platform - https://pybitesbooks.com/ - Loads of new updates coming soon!

___

💡🧑‍💻 Want to become a more focused, motivated, and effective Python developer? The Pybites Developer Mindset (PDM) Program helps you build strong habits, deepen your skills, and make real progress in just six weeks. Join us for mentorship, accountability, and a supportive community that keeps you moving forward. Start your PDM journey now! 🌟✅ https://pybit.es/catalogue/the-pdm-program/

___

If you found this podcast helpful, please consider following us!
Start Here with Pybites: https://pybit.es

Transcript

Cold Open And Catch‑Up

Bob 0:00

This all started with the big C word, right? Like communication. Like had we just opination like this is the roadmap, this is the design. It kind of went through the board, right?

Julian 0:10

But you know what? That's that shows that even we get rusty, right? Because we're not used to working on too many code bases together, right? It's been a while since we did anything like this. And it just shows that if you don't do that actively, you can forget crucial steps. Hello and welcome to the Peter Bites podcast, where we talk about Python, career, and mindset. We're your hosts.

Bob 0:31

I'm Julian Saclera. And I am Bob Beldibox. If you're looking to improve your Python, your career, and learn the mindset for success, this is the podcast for you. Let's get started.

Julian 0:43

Alright, we're back. This is Julian. I'm here with my beloved co-host Bob. Bob, how are you?

Bob 0:48

Yeah, good, man. We were just chuckling about the intro versus our intro mismatches. And we can just turns out we can just dive straight in. Yeah. That's what we're gonna do.

unknown 1:00

Yeah.

Julian 1:01

We don't need to do the fluff. We could that that's what the intro music's for.

Bob 1:05

How are you, man? Yeah.

Julian 1:06

I I am good. I am good. It's um still hot over here, and I am actually it's cooled down tonight, but I was sweating this afternoon during some calls. Uh, but otherwise, good. It's been a busy week. We are doing so many cool things, building new stuff. Uh, actually, prior to this recording, we were just talking about a new uh initiative that we're kicking off soon, uh, that I'll be working on right after this. So that's very exciting. Uh, and yeah, other than that, family's good. My uh big, big win I'll share with our audience is my my little one, my youngest, my baby. She started kindergarten last week, and so this is the start of her second week out of the house at school every day, and she's going really well, man. She's she's smashing it. This morning she just walked away from me. It was it was beautiful. So all is good. What about you? I remember that. Time flies. Long time ago for you.

Bob 1:59

Yeah, yeah. No, good man. Like uh, yeah, busy is the default. Um, coding on five repos, right? But yeah, cool stuff coming, right? Like uh almost done with the relaunch of the Rust platform, 60 exercises. Um, we have a content creation tool, we're almost at the finish line. Uh yeah, ongoing Python platform changes. Um Rust cohort is going really well, so yeah, a lot going with the exciting times.

Julian 2:28

Yeah, man, it's amazing. The and I I didn't realize, you know, we're well, we're in Feb, but the AI cohort's coming up soon. Uh, that's in in April, right? We're that's less than two months away.

Work Hours And AI Reality

Bob 2:39

Ready to learn, yeah. Working with Django as well. Yeah, yeah. Over how many things are as well. The Snipster material is going to be five, ten times bigger, better. Yeah. It's exciting.

Julian 2:52

That is that's crazy. I mean, uh we we need to do an episode on on productivity and how we shape our days to get all of this stuff done. That's a lot of stuff that we're I'm not trying to this isn't trying to be ego, but you know, that there's a lot that we're doing. And so um, there's a lot of techniques we have to put in.

Bob 3:11

We do work long days, right? Like there's no secret in that.

Julian 3:14

Yeah. Yeah, there's there's a not so secret reality as we do put in 10 to 12 hour days, most days every week.

Bob 3:23

So that's weird, right? Like, uh, although AI can help you, uh it also uh creates more work, right? So uh there's no shortcut.

The Git Mix‑Up Begins

Julian 3:33

Yeah. Yeah, exactly. So let's dive into it. Let's dive into it. So this episode, everyone, we what we just want to share a quick story. Uh, I wanted to talk about this. I insisted we talk about this. I thought it's simplistic, but it's just a nice reminder of Git and Git workflows and working together on a distributed team. Now, Bob and I, you know, we we work on stuff together, but we are on other sides of the planet. We can't be on a call or a Slack chat or something at every second of every day to check on things and ask each other questions. And so when we are working on something like a GitHub repository, uh conflicts uh due to due to take place, and that's that's what happened on the weekend. So uh full disclosure, we we shouldn't have been working on the weekend. We were too too addicted to this.

Bob 4:26

We maybe that was the reason of the whole message.

Hidden PRs And Design Divergence

Julian 4:28

Yeah, maybe that's it. Hey, I'm I'm taking, I'm falling on the the sword for this, and this was all my fault. So um we're currently working on the Pywites Books repo. So if you remember, that's our book tracking website, our uh app that we built to deal with the blatant farming of uh what's it called? Goodreads, right? As much as Goodreads is a staple across the planet, uh they are farming your information, they're using you as a a product, and we don't like that. So we built our own version, which is um, yeah, there's there's room to be for improvement, and that's what we're doing, and that's what we were coding on the weekend. We're both very passionate about it, and it led to some uh merge conflicts and things and things like that. So I guess I wanted to share the story and poke Bob for some best practices here, uh, because I think it's worth sharing, because not often, unless you're in a developer role, you're not often working on a repo together with someone. And quite often, professionally, as you pointed out, Bob, when we spoke about this, is that when you are working on a repo professionally, you do tend to have like Jira tickets or um whatever to tell you, hey, you have to work on this, this, and this, and everyone organizes their work that way. But with things like um open source or just working on projects, you know, small projects with with your friends, and even on smaller development teams that don't have that kind of a setup, these things are going to happen. Uh so Bob, do you I mean, do you want to share what happened or do you want me to do this?

Bob 6:09

You do it, yeah.

Julian 6:11

Okay, all right. I just I'm talking too much, man. I'm aware. Okay, so so we're working on this. We're both working on the redesign, and that's probably our first mistake is that we're both working on the exact same piece of code and same feature, which meant in the Django app, we're both looking at the template, we're both looking at uh views and and URLs, right? Well, actually, not not so much URLs, but we're looking at views. And so what happened was I started coding and and working on that. Uh, and on my branch, I had pulled from the main line, assuming okay, in my head, I just thought, yeah, I'll just pull down the latest, latest code that's uh production. What I didn't think to check, and this was mistake number one, was did we have any open pull requests? And that was on me. Uh I just didn't even think about it. And to my discredit, uh, Bob had made a pull request and asked me to look at it three weeks before.

Reconciling Conflicts And CI Guardrails

Bob 7:08

It kind of shows how busy we are, right? Like because there was kind of a redesign thing going, but and you know, I showed it some time ago and it sat there on the branch, right? Because I still had to review it and write additional tests and whatnot. And then, you know, we got busy on other stuff, and yeah, we kind of completely forgot that there was a redesign going.

Julian 7:28

Yeah, and and that redesign that you did was huge, it wasn't just small. I mean, you changed a bunch of things in it, but you also put in this amazing statistics dashboard that lets you see all these stats on your reading, the community, all these different things, which is amazing. Uh, but that was a lot of code, and I didn't have that in my pool down because it wasn't production at the time. So I anyway, so I did all this work on my end. And when you woke up, and this is the whole distributed team thing, when you work with people across the globe, you they're asleep half of your day, and so you don't get a chance to to talk with them. So I'd been asking you questions or saying I'm working on stuff, but you couldn't reply because you were asleep, and so I just kept going. And so when I told you when you woke up, you said, hang on, there's a PR already open, and that's when I would that's when the extra work kicked in. So uh in the end, I made a second pull request, and we had them sitting side by side, and you saved the day by sitting there and actually checking to see what the conflicts were, and then work through them to merge both together so that my changes and your changes both took place without breaking the app, which was incredible.

Bob 8:45

So I think we said, Okay, stop right there, we're gonna have to merge everything in and we can solve and then and then we can do a new branch. Yeah.

Julian 8:55

Exactly. So before I move on, the the question here was how challenging was that? Was there was there a lot that broke?

Branch Hygiene And Cherry‑Picking

Bob 9:02

I mean, some of it was new. Basically, you brought back the Goodreads import, which was unrelated, so that folded in quite perfectly. Um although I had to backtrace the docs as well to say it's not premium anymore. Um but uh yeah, the real conflict, of course, was that my branch and your branch had been working on the design, so there was a cut I mean the dashboard uh that folded in because that was clearly on my end, but we both had done like CSS changes, like the color scheme, right? So that had to be reconciled. And I think even to the very last moment there was still a bug there, like when you were logged out, right? It was the old terrible color scheme, but you know, that was quickly to to fix and and spot. Um yeah, but you know, it's kind of a reality, right? Deal with merge conflicts and look at the version that that you want to have and just reconcile it. Um, but yeah, I think that was a good call, right? To get it all into main, stable, test passing. And I really like as well. By the way, we now have a CI that if coverage goes under 80%, I mean it could be higher, but you know, you have to just draw a line somewhere. Uh CI fails, right? So um, but anyway, um clean slate, new branch. But yeah, this all started with the big C word, right? Like communication. Like had we just talked to Nature, like this is the roadmap, this is the design. We kind of went cowboy, right? Doing our own design changes in Brad Line. That's that's not good.

Julian 10:34

But you know what? That's that shows that even we get rusty, right? Like, well, I get rusty as well, because we're not used to working on too many code bases together, right? It's been a while since we did anything like this. So uh, and certainly not as active as this, right? It it those things that we used to do would be days apart, right? Where it'd be like, okay, you do this this day, I do that the next day. Uh and so this this was a nice reminder that, yeah, crap, we can we make mistakes or I make mistakes as well. Um and it just shows that if you don't do that actively, you can forget crucial steps, like for example, like I said, checking whether any active pull requests that might already fix these problems or whatever.

Bob 11:16

And normally we also slipped with the issues because normally you have an issue for everything, you know? This time we were making changes without issues, right? So red flag.

Team Scale, Flow, And Release Discipline

Julian 11:26

We just got too excited at building, you're right. And or the issue was just a generic big one of just redesign. That's it, as opposed to very specific chunks of issues. Yeah, exactly. Fix this menu, change the color of the nav bar, whatever. Um so the but then the next thing that actually happened was I went to sleep, or vice versa, something happened, and this time I pulled down the full code. And the best practice, which was a really good point that you called out, was okay, don't keep committing code to the same branch that you were already using, the the UI overhaul branch that I created. Um, and you really you reminded me of the whole thing of like stale branches. There was so much that has happened since that branch, just create a brand new one, right?

Bob 12:16

Right, because your changes were at that point already in main, right? So there was no exactly merged. Yeah.

Urgent Bug Fixes And Isolation

Julian 12:21

Yeah. And it reminded me of that that practice, right? Like once your uh branch has been merged, once the changes on your branch have been merged to main, that's it. Leave it, create a new one, right? Um, and that's just easily forgotten when you're not actively working with someone and uh you know, and all of that. So and you're still working on the same kind of feature, right? I'm still working on that UI. So in my head on the weekend, it was just just keep working on that branch, right? Um, but yeah, then the next conflict happened because, as you said, you caught some bugs, and I'd already started coding on a brand new branch for whatever changes I wanted to make after that to the book reading list page, right? So when you look at your reading list, I'm changing some of that. And so while I was working on that, you fixed some bugs and pushed that to main. So then I had to pull down those bugs as well, and I thought, oh no, is it going to be a merge issue on my end? I didn't want to do the whole thing again. So I thought, let me just bring your changes in and and fix whatever conflicts I have locally. But there were none because you'd worked on bug fixes that had nothing to do with just the the template that I was fixing. So it worked out really well. And but I really I really enjoyed this because I got to do things like um I got to stash my changes, move them to a branch. Um, I even cherry-picked a specific historical change uh or commit that I'd made. So I got to use, you know, get cherry pick, which I hadn't used in Git Ninja now. Yeah, I it's good, man. I was I was so happy. I was like, oh yeah, shit. You stash the changes, move to here, create a new branch, put them on there. Uh, which you know, I actually I think after I stashed it, then I was able to go to my commit history. And anyway, I can't remember the exact order because this was Sunday and I was tired, but uh it was just it was fun. I was like, this is awesome. So yeah.

Bob 14:13

Also, I mean for this repo, you know, it's it's or product, it's not that much use, right? So we can be a bit looser with main and stuff. But it's pretty common if you have different branches and you're working on two different branches as two developers, and developer A makes changes, right? And developer B needs those changes, and then you have to just merge forward your branch with those changes, and that's exactly what happened, with the difference that my branch was just main, because we can, right? Um, but yeah, that's that's pretty common flow, right? Like we're working on different branches and we need to pull in the changes from each other. Um that's that that sounds complex, but it's also what allows so many different developers to work on the same code base, right? Um, that's actually a brilliant concept.

Julian 15:00

Yeah, it it made me think, is uh, and this is why I wanted to talk about it today, was it it really made me remember like wow, if you're on a distributed team of 12 developers, maybe more, there are so many people working on that same code base. And it was just a reminder, these are things that you take for granted or forget in a way if you haven't worked on one of those teams in quite a while, right? I was lucky when I was doing this stuff. There were only two of us doing Python at the time. The others were doing Pearl and other things, so they were all doing different things um at AWS. And with you, you know, it's been-I mean, you do this all the time now still, but um you you're on a large team back then. But to to your point, when you were on that team at Oracle, you were working on specific issues, right? And like Jira tickets or whatever they had.

Local Setup, Docs, And Tooling

Bob 15:52

Right. It's kind of the same principle, it's just a bit more granular, right? Like the your branches might be better named with feature and bug fix. Um, also, you're not pushing to main uh ever, right? So there will be a develop branch in between, right? So you have that extra layer of of uh filtering. Um you have builders, right? That that reconcile all this because it gets complex, right? Um, so that's why this was even simpler because um it's our repo, we can reconcile on main, we don't have to have the development. The open source variant we we have is still out there, we had that system, but for for this we we found it a bit too much. Um so yeah, it's it's kind of similar, just that's yeah, it's a bit more granular, and they're actually dedicated people that pull this all together for a release, you know. Just a quick break from the episode. Stuck at the beginner or intermediate level and wondering what it actually takes to become a senior developer. It's not just more years of experience, it's owning projects end-to-end, making solid design decisions, writing clean tested code, and communicating like a pro. That's exactly what we help people with inside the Pybytes developer mindset program. You build real-world apps, get weekly code reviews, and sharpen your developer mindset that will lead to promotions. If you're serious about stepping up to a senior dev, check out the link in the description and apply right there. Now back to the episode.

Julian 17:21

And it is a solid reminder as well that with more production applications that have high stakes and everything like, for example, the Pybytes platform, we would never have this issue, right?

Bob 17:31

That is This would not have happened there, yeah.

Books Quick Hit And PybitesBooks Plug

Julian 17:34

This is that is max production, right? But this is just this started as a hobby project for us just to give ourselves our own goodreads, right? Uh, but to that end, you know, it it does remind me, yeah, there are features in production uh code bases with CI C D and having multiple stages of deployment. So it'll never reach production because it'll hit that first dev test, uh then number two, number three, uh, as you increase load and and spread it around the world. So um, yeah, through that pipeline. So yeah, there's there are reminders that these there are systems in place and more production uh code bases to actually help uh mitigate these simpler issues. Yeah.

unknown 18:16

Yeah.

Julian 18:16

Yeah. Anyway, so that was that was fun. It was it was a good good reminder and a good refresher on working with people. Um and I'm not talking about, you know, if you're just not just, but if you're reviewing someone else's code on a on an existing thing. But when you're actually both coding deeply into that same project, it is a reminder. Yeah, you've got to be conscious of the other people and remember that they'll be doing stuff. And that was a good reminder for me because it's been a while since I coded together with multiple people on a database that's active, you know.

Closing, Puns, And Community Invite

Bob 18:48

It's also very hard to pick up from books, right? As we always say. Um, this was like a nice real-world scenario where you know this really happened and we had to kind of iterate, and now this sticks much better, right?

Julian 19:02

For you, exactly. Yeah, I remember to check everything, just pull from every git pull everywhere.

Bob 19:09

But the thing is also like I had like two or three pull requests, right? So I had a branch and a branch of a branch, uh, because I'm working on different things, right? And I was not I was not ready to merge it in yet, right? So ideally it would already have merged, or at least we would have ended up with one branch, right? But yeah, like because I was working on testing, on redesign. The docs, yeah. Docs, like, and I made like different branches, right? But that also increases the complexity, yeah. Yeah, although it's pretty common that for every feature or fix you have a branch, and that just happens in parallel, right? Because different things get worked on.

Julian 19:49

Well, okay, so that's that's a question, right? For people out there working on say open source and uh maybe not open source, large projects that would obviously be exactly what you're talking about, but even smaller projects like this one, uh, would you say the best practice would be to maybe focus on one feature at a time and get that in before you create a new branch? I mean, there's nothing wrong with having 20 branches open for all these different things you want to build, but at some point, doesn't something become stale or uh as long as but I guess on those other branches, as long as you're constantly pulling whatever does get merged to main, uh is what what would you say? What would you recommend for people?

Bob 20:26

So I have to talk about open source projects, right? Because they come in so many flavors. And I would always, you know, recommend to go look at the contributor guide because that that explains a lot of this. Um but yeah, it also depends for a regular project like this, right? Um, what's the release schedule like, right? Like for books we can just release very fast, right, and and constantly almost. Um, but that's not always the case for products, right? They have quarterly or monthly, whatever, right? Yeah, yeah. If you still want to do development, then inevitably you're going to have different feature branches open, right? Um, but then a bug fix comes along and and that probably takes priority, right? So then you make a bug fix branch off of main, not off of the branch, but off of main. And that needs to go in first because that's a problem in production, right? So it kind of that depends answer. Um yeah, obviously branch per feature, branch per bug fix, and clear communication on the issues, right? Because that's where or or whatever tool you have for the project management, because that's ultimately where you need to align with people, which again comes back to the communication. No, absolutely. Okay.

Julian 21:38

No, that's that's good, it's a good point. Did I avoid the answer? No, no. I I mean, right sometimes. It's a nuanced answer, right? It depends. That's the perfect answer. It just depends. And it depends on your style. As you said, the that's something I I forgot about, like the release schedule and the um contributors guide. Uh some repo owners may be very, very strict. With this stuff. Like, no, no, we we're only working on these, the other stain issues, right? Or whatever. Uh, you never know. So I think no, I think that's a it's a perspective thing, and I think it's it it depends, is a is the perfect answer, right? So cool, man. Well, I I really enjoyed that, and uh you know, just running through that was was pretty fun because that was an eventful weekend. Now, also disclaimer, we didn't break anything in production, right? It it this was all done in the no, yeah, knock on wood, knock on wood. This this was all just on our back end, right? It was we're working on branches, right? So this wasn't um well, funny enough, right?

Bob 22:37

Like, in spite of all this, um it did break, you know, a few days before, but that was because we we needed a higher rate limit on the Google API. Oh, we were using it without an API key. It's a good example, right? We we we had these branches open. Your branch maybe not yet, but my I have my had my two, three branches open. Yeah, and one of our coaches said, like, hey, by the book stop working, like I cannot find titles, and like, what the heck? And uh the autocomplete start stopped working, and turned out that there was some sort of I'm not even sure if it was rate limiting, but um the only fix was really to start using Google Books API with an API key, which we probably should have done like years ago. Um so got that in. Um, so that's a good example, right? That was a bug fix branch, had to go before, right? So um imagine you do all this stuff on main, right? Yeah, and now this bug fix thing comes up, and now you have no choice of pushing the whole thing where you had changes in which you were not happy about yet. So the fact that I had all this work on branches and I could do a separate branch and fold that into main quickly to fix that urgent issue, again, really shows how how this matters, you know.

Julian 23:49

Yeah, but it it also shows you and forgive me, I don't know who who came up with git, right? I off the top of my head, but the fact that git stash exists. Was it the Linux? Oh okay. I didn't know that. But anyway, so but it just goes to show, right? Like Git stash, if you were if you happen to fall into that situation of putting everything on main and never using a branch, and then you had to make an emergency fix, you could just stash all of those commits, right?

Bob 24:18

And or just put it on a on a branch quickly, you know.

Julian 24:21

Well then yeah, create the branch.

Bob 24:22

So it's almost like zero cost, right? Like it's always it's always good to do a branch, right? You can do the code review, obviously, on GitHub. And then it just goes back to software engineering, right? It's always better to isolate, you know.

Julian 24:35

No, absolutely. I think it's it's nice, it gives it this whole layer of comfort as well to be able to mess around in a branch and not worry about main.

Bob 24:45

Yeah, like like the global state in Python, right? Go have a function, change variables outside scope, waiting for problems. You know, keep it all encapsulated, you know.

Julian 24:57

Yeah, yeah, no, no, that's that's good. I I yeah, no, no, I I appreciate that. And um something you you when you mentioned about the uh you collaborate the main namespace. No, no, when when you mentioned the the emergency fix the other day, uh you reminded me of something, but it it's not important. I'll um have to get commit that to memory for later. I stashed that idea away because I kind of reverted it.

SPEAKER_02 25:29

Yeah, yeah.

Julian 25:31

Terrible. Um but it's hey, so here's a here's a call to action for everyone listening, right? This is this is an important, important concept in in software engineering and in in Python, right? As you're developing, you should really learn these things. If you haven't started using Git for your projects, if you're the so I know when you spin up a Python project at home, a lot of people will just create a folder, write a script, and throw in a virtual environment, right? But oh, and this is what I was gonna say. Um, but when you start doing things like initializing that into a GitHub repository and then you know, doing that whole sync between GitHub and your PC, right, or your laptop, whatever, uh you have to learn the whole SSH key setup. You have to learn um requirements, you have to learn about um uh uh what is it, the gitignore file to make sure that your valuables like your environment variables, your keys, everything, don't push to production. These are super valuable skills as you move out there into the outside world and code with other people. And on the other side of that, Bob, one thing that you do well is you really document how these tools work in the README file and how to replicate that repo and use it yourself. So, you know, kudos to you. When I was pulling this repo down to my computer, you know, you had a whole thing there on, hey, here are the environment variables you're gonna need, right? Um, and the only reason I looked is because when I went to launch it, it kept crashing, going, you're missing this. And I'm like, oh crap, there's a whole suite of things I at least need to put dummy.

Bob 27:06

I did did I do the hard fill on the missing Google API key.

Julian 27:10

Yeah, oh no, no, the Google API key, no. No, that one wasn't the issue. It was more the Django environment variables that were required, right? So, but the you know, the um the Google keys were fine, just not having them meant it just didn't work, right? Um, which was fine. But it was more that you know, because you said what was necessary to at least launch it and run it, I didn't have to sit there and go through failure after failure.

Bob 27:34

Oh, and because you also need a Redis and Salary, right? To test these Goodreads imports. So I thought, like, hey, you probably don't have these tools or you have not used them, so let me just quickly add to the README, you know. Yeah, because yeah, you end up having to have three terminals, right? Run server for Django, salary, and then Redis, right? And and then you can test the the Google Books, uh, sorry, the Goodreads import. Yeah. Exactly.

Julian 27:56

Yeah. But you know, the these this is the kind of level up in running a project locally and being able to run it completely. So now I have a complete standalone instance of this app running on my computer, but there's nothing populating the database like the production. You could have Dockerized it as well.

Bob 28:15

Make it easier than just have your Docker compose and exactly running a brand.

Julian 28:24

That's just for us.

Bob 28:25

Oh, open issue for you.

unknown 28:26

Yeah.

Julian 28:28

All right. Look, we've we've um we've we better get out of here.

unknown 28:32

Yeah.

Bob 28:32

There's fine. I guess we don't really get to do this type of call-up, right? So this this was yeah, we could collaborate on ten other things, but not really on these code bases. So this yeah, this was cool.

Julian 28:45

But I think nice to for us both to talk something technical for once as well. That's that's good. It's been too long. It's been too long. So but i I noticed you ignored all of my git puns. I had lots of puns in that. So here or on the no, here, right now. I said we better get out of here. Yeah, yeah, yeah.

Bob 29:07

I got that. I'm too used to it, you know. Like it doesn't raise an eyebrow anymore, you know.

Julian 29:12

That's true. So if if you are still listening and haven't just thrown your phone out the window because of these puns, um we appreciate you listening. Oh wait, actually, Bob, uh, should we do books quickly? Uh sure.

Bob 29:25

Yeah. Do you have anything new? Uh don't panic. Yeah. Uh reading that. Yeah.

unknown 29:34

Cool.

Julian 29:35

Nice. I I do not have anything new. Not since uh my last podcast episode, which was last week. So I can't read that quick. I got too many things. But I did pick up um I just bought a new book the other day, but I can't remember what it is. I'm a bit of a hoarder like that. But anyway, we'll get to it. Uh for now, just uh here's here's the link in the show notes for me. Just go to pybytesbooks.com. Yep. Now with dashboard. Exactly. Just remember, folks, this is a privacy first app, right? And a color theme that's that came through after a lot of merge conflicts. Blood, sweat, and tears went into that current version.

Bob 30:12

So uh and if you do check it out, the statistics if you don't like it, you can subscribe and and change the theme. There you go.

Julian 30:21

Yeah. Nice. Yeah, if you subscribe to it, so the the reason their subscription on this tool is to just literally pay for the hosting, right? To um make it self-sustaining. So yeah, exactly. Just uh like a buy me a coffee type thing. But if you do subscribe, you get the ability to change the theme to what you want. So um, as as garish as it might be, if you want to blind yourself with some fluid color. And you get a nice frown on your yeah, you do get a premium user little tag, so it is it is enticing. I'm sure we'll have other things uh, you know, as we flesh this out and build it out more. But um, yeah, please check it out. To to me, I'm very proud of this app because it is privacy first, right? We do not want your information. Well, it endorses reading. That's endorses reading, yeah. It's game of gamified, you know? Absolutely. Um add your books, yeah. Yeah, go back, import your good read stuff, get off that uh toxic platform of um Amazon scraping all your reading habits and making millions off of that, and book recommendations that are paid for you to see. Let's get rid of those. And um, you'll just the book recommendations you see on the home page of this one is uh just whatever the community's reading. So you're seeing what actually actually what other people are reading, not what you can follow people and get weekly digests. That's another feature we added.

Bob 31:44

So it's actually a lot going on in this thing.

Julian 31:47

Yeah, it's getting better. And and for the users who are using it, thank you. And we uh take all your feedback and implement it very quickly. So there you go. All right. Well, that's it. Thank you everyone for listening. As always, uh, make sure you like the episode, leave a review, subscribe, all those things. Uh Bob, thank you for joining us. Joining us. Thanks for joining me and for the chat. I get go write some code. Oh, okay. You should have said get get out of here and write some.

Bob 32:16

I'm tired of you, Puns guy.

Julian 32:17

Am I am I get pushing it now? To pushy. Yeah. All right. Take it easy, man. We'll chat later. So thanks everyone. We'll catch you next week. Bye. Hey everyone, thanks for tuning into the Pie Blights Podcast. I really hope you enjoyed it. A quick message from me and Bob before you go to get the most out of your experience with Pie Blights, including learning more Python, engaging with other developers, learning about our guests, discussing these podcast episodes, and much, much more. Please join our community at pyvites.circle.so. The link is on the screen if you're watching this on YouTube, and it's in the show notes for everyone else. When you join, make sure you introduce yourself, engage with myself and Bob, and the many other developers in the community. It's one of the greatest things you can do to expand your knowledge and reach and network as a Python developer. We'll see you in the next episode, and we will see you in the community.