Syncing projects with Google Drive - Part 15 (Bug hunting)

Good morning, everyone. How is everyone doing? We're back in the DriveSinker project, as always, and we're going to build a couple new features. So yeah, let me just zoom in so you guys can see. Sometimes I just forget to do that. Now, in the previous video, we finished building the new tracker, the sync tracker, and the algorithm over here, right? And the last step was to delete the ghost files from Google Drive, right? So that's what we did in the previous video. In this video, I just want to fix a few bugs and make some small tweaks here and there. And in the upcoming videos, we're going to be implementing something even more amazing, but no spoilers for now. Let's start fixing some bugs. So one of the things I noticed when I was going through the project code later after a video was right here in the project exists function over here. You'll see that this function, project exists, is supposed to return a boolean, right? Whether the project exists or not. But if you look closely at the query over here, it doesn't actually check for the folder name, does it? It just checks whether the folder is in the parents, which is the, I guess, the programming folder, and it's not trashed, and its MIME type is folder. So basically, we're looking for literally any folder at all in the programming base folder. We're not even checking whether the folder name matches and all the other things match, right? So yeah, this is obviously the wrong query over here, and so we need to fix that. And luckily for us, this is a simple fix. All we need to do is say name and a string over here, and then AND MIME type, and the rest of the query. Now, this name is going to be t.folder.name right here, and with that, we fixed the first bug of this project. Now, the second thing I want to do is I want to clean up the logs a bit. So over here in the walk project tree function, this is going to output the entire project tree every single time it walks it, right? But this is really not useful anymore. The only reason we added these logs in the first place was when we were actually building this function, and we wanted to make sure that we were getting the correct output, that the function was doing the right stuff, right? But since we've confirmed that these logs are no longer necessary, and they're just polluting the entire, you know, the entire terminal, right? So we're just going to comment out all of these print statements, and that's going to be a much cleaner, much more easier-to-read log file, right? Now, that's really all I wanted to do for now. So let's do a quick test and see whether the Google Drive sync process is actually working. Let's just make sure that our program is working and we didn't break anything. Before I do that, let me empty out my base folder over here. You can see I uploaded a couple projects, but I'm gonna move that to trash and start fresh over here. Now, let's run this and see what happens. By the way, we can also, before we actually run this, we can also go into the config file over here. Where is it? There we go. And see which project we're actually uploading. So you can see I'm uploading the DriveSinker video project from my programming folder. Okay, so now that we've confirmed that, let's go ahead and run this and see what happens. It's going to upload this whole folder, right? And as you can see, it's uploading all of the folders and files in this project. It's skipping the stuff I don't want to upload, like the sensitive files like client and token.json, the Git folder, and so on and so forth. Everything's working perfectly fine. Cool. Awesome. Now let's try uploading the entire thing again. Just see what happens. Okay, the project already exists. It's walking the project tree. That makes sense. And it just skipped everything. Perfectly fine. Awesome. Alright, so this time I've re-enabled the progress bars and redirected all of our logs to the log file. You can do the same thing by uncommenting this line over here, render bars, in the sync.go.cmd file, and in the main.go file, you can uncomment these lines to configure the logger. This will send all of the logs to the log file, and we'll be able to see progress bars as soon as we uncomment this render bars function. Okay, and then let's see what happens if I run this again. Should render a progress bar, and we should see some upload progress over here. And you can see it tries to upload, but it just stops midway. And this is because it finds that the entire project has already been uploaded, and so it just stops right there, and it doesn't upload any further files after that. Now, this does work for now, but I can already see a potential issue occurring down the line, and that is what happens when we have zero total files to upload. And this can happen when we're basically just skipping all the files because they've already been uploaded. Now, this doesn't happen right now, but I can tell you in the near future we're going to be implementing, spoiler alert, we're going to be implementing our own Git ignore parser. Basically, our own implementation that will parse Git ignore files and all the complex patterns that you can have in a Git ignore file. And once we implement that over here, up here in the count total files function, this is going to return zero new files if you've already uploaded the entire project and there are no new files to be uploaded, right? And if that is the case, this function will return zero files. And so what happens if this progress bar is trying to render and there are zero total files to upload? And I can tell you what's going to happen if you go over to the progress bar function over here. You can see that we're trying to divide by the total number of files, right? If the total number of files is zero, what happens when you try to divide a number by zero? You get undefined, because division by zero is undefined. See, no matter what number I try to divide by zero, it's just going to be undefined because you cannot divide by zero. It's just mathematically impossible. So in this render progress bar function, we need to add a special case where if the total files is zero, then we need to handle that separately from all of this stuff over here, right? Again, this is not an issue right now. As you can see, we do see 18 files to be uploaded over here right now. But in the future, when we create our own custom Git ignore parser, this is going to be an issue. So let's just fix that ahead of time. Okay, so first of all, I just want to take this entire string over here, where we construct the actual bar string, and create a new function down here. I'll call this build bar, and it's going to return a string. There we go. Return, and then just paste that sprintf call over here. Up here, we can just call this function, and there we go. Now it's going to need some arguments over here, so let's fill them in. The progress is just going to be a pointer to models.UploadProgress. The filled and the empty are going to be integers, and the percent is going to be a float64. There we go. Now all we need to do is pass these in. So pass in the progress, the filled, the empty, and the percent. There we go, and this will make sure that we're building the bar properly. Now, the special case is going to be up here, where we say if progress.TotalFiles equals zero, then we're going to say return buildBar. We'll pass in the progress. For the filled, we'll just say zero because there are zero files to be uploaded, and so zero files will be uploaded. For the empty as well, we'll say zero. And then the percent will say 100 because since there are zero files to be uploaded, the upload has just finished by default, and then we can just say 100% progress has been reached, right? Just by default because there are no files to be uploaded. And that's pretty much all we need do for this video. Again, quick recap. We fixed, where is it? We fixed the projectExists function over here in tracker.go by making sure that we're checking the folder name as well. We also commented out all of the print statements in the walkProjectTree function just because they were polluting the entire terminal output, and we don't really need them anymore. And finally, in the renderProgressBar function, we refactored it a bit to also be able to handle the case when total files equals zero. And again, just as a reminder, the only reason we need to handle this is because we're going to be building our own gitignore parser in the very near future, probably starting in the next video or the video after that. And the reason we need that is because if you look at the gitignore file right here, it currently only supports file names, right? Our current gitignore parser only supports direct file names. If I try to add a complex pattern over here, like, say, I don't know, something like this: ignore all __pycache__ folders. If you used Python before, this will be familiar to you. Basically, what this pattern is saying is that we want to ignore all of the __pycache__ folders and all of the files inside them. But the current gitignore parser that we have in this application will not be able to parse this. It's going to treat it like a file name, like a literal file name, and that's just not going to work, right? So I want to be able to handle complex patterns like these. Patterns like, let's say we have a folder called bar, and then we ignore all of the folders inside it, and then we have another folder, subfolder called foo, and so on and so forth, right? I want to be able to handle complex patterns like this because real-world projects have real gitignore files that have complex patterns like these, right? And so, if we want our application to be complete, we want to be able to handle all of those, all of those different gitignore patterns. And that is why I wanted to build my own custom gitignore parser, and that is why we wanted to be able to handle the total files equals zero case. I actually have a little diagram I drew in Excalidraw over here to actually explain the entire gitignore process. This is just a sneak peek for now, guys. I'm going to explain this entire thing in the next video or the video after that, when we start actually building this new custom gitignore parser. And the reason I built this is because parsing a gitignore file had so many different rules and patterns that I needed to make sure that I'm handling, and it was just such a complex process that I just couldn't wrap my head around it. And so I thought it would be easier for me to build some sort of, draw some sort of a flowchart or something to explain my thought process, and then I can just follow that. And so this is what I drew up. It explains the entire flow, the entire algorithm we're going to follow and implement in the future videos, and it has all of the rules that I want to make sure I'm handling, all the patterns that I make, that I want to make sure I'm handling in the gitignore files. We're going to go through this entire thing in the next video when we start implementing the gitignore parser. For now, we're done with this video. Thank you for watching. I hope you're following along with the project. I hope you're learning new things just as I am. And yeah, stay tuned for the next episode. We're going to be building our own custom gitignore parser. If that's not exciting, then I don't know what is. Like, comment, subscribe. And if you're still here watching the video, let me just do a quick CTA. This is my personal website. I have my portfolio and stuff over here. I promote my YouTube channel over here. There's some testimonials from other business owners that I've helped and that I've worked with. And basically, what I do for work is I'm a freelance developer. I build websites, apps, software, and stuff like that. And so if you have a project like that and you want me to work with you, then just get in touch with me over here. I do a free intro call. You can find the link for that in the description, and we can work together and build your project. And remember, it never hurts to talk. The first call is free. You can book a call with me in the description, and we can talk about your project, and we can build it together. So if that's something you're interested in, if you want me to work on your project alongside you, then book a call with me and let's get it done. Other than that, thank you for watching the video, and I'll see you in the next one.