Creating the Bug Tracker Project
I’ll give you the story of how I developed my bug tracker project. As a Python enthusiast, I needed some way to show “I can do big boy things with a coding language!” beyond coding yet another card game with ASCII art for the command line.
Choosing the Project
As I started learning to code (Udemy courses, programming books, etc.), I came to detest all the games. Games, games, games! I don’t want a clone of Space Invaders! I want to do real coding stuff! I’d type my way through coding exercises but set aside the lines of code because they were worthless to me.
As I passed the halfway point in the Backend, SQL, and DevOps with Python boot camp through Nucamp, I realized I would need to figure out the portfolio project on my own. The boot camp did have a portfolio creation assignment, but life got crazy and I had to set it aside. This YouTube video (I’ll call it the “One Project Video”) by another boot camp gave me the path forward: a bug tracker app. Also this blog post.
From the beginning, I had to adapt the recommendations in the One Project Video to fit my own case. I was already learning Python, so there was no way I was going to learn .NET and C#—no way, nuh uh, no how. So I had to find a technology that would let me build a full-stack application while mostly remaining within Python. That meant Flask or Django. I chose Django because Flask seemed to be shorts when I needed trousers.
Getting into Django
Although my boot camp did have me doing some things with Django, I had to learn it on my own. I previously attempted a Udemy course that taught full-stack development, but I nearly lost my mind trying to choose a framework for the UI design. With Django, it was one more thing to learn, but I got to focus on what I actually like to do: build tools to do things. It was quite the learning curveball but it was juuuuuust enough within reach for me to get it.
“Lightbulb moments” ultimately kept me going forward. I had to wrestle with, negotiate with, acidly bicker with, fist bitingly contend with, and ultimately sit with tutorials, guides, and documentation until that darn light came on and—IN A FLASH—it all lit up for me. In another post I suppose I could try a dramatic rendition of some of the desperate moments of earnest, deadly combat with error messages deriving from one needlessly duplicated line of code giving the settings for the app database.
Navigating Online Resources
I have a love-hate relationship with online question-asking resources. I have my question NOW, yes there are people online who help you sort it out, but what is a desperate question for me NOW is taken off Stack Overflow IMMEDIATELY, and I figure it out on my own anyway.
Resources have to kind of come together to produce that lightbulb moment for the project at hand. Some resources are helpful but leave out how to secure the project. Other resources show how to secure the project but don’t quite explain what it is. More often than not, the problem is between keyboard and chair and I just don’t understand the tech lingo yet. However, now that I’ve dragged myself across the finish line to deploy a minimum viable product version of a Django project, I can see the lights coming on in the dark house I stubbed my toes, banged my shins, whacked my funny bone, and hit my head all the way through.
Reaching “Minimum Viable Product”
As I went along, I shed certain things were I could. In the first version of my bug tracker app, there are no images. Not critical to the absolute core function of the app. I left off the “open/in process/closed” status setting for tickets submitted. Would be helpful but I’ll have to come back to it later. Forget creating a custom user class and user profile pages—I need to get a very very basic app out the door so I can start applying for jobs.
One of the recommendations in the One Project Video that I’d like to come back to is implementing a third-party authentication system. Integrations are critical for maximizing the app or tool that you’re building. At the moment, however, the focus has been on getting this whole app launched rather than implementing a specific part. Django has a workable authentication system, so I’ll use that for now.
One point that threw me for a loop was the fact that I couldn’t just go with the Django=provided SQLite database. It was good enough for my purposes. However, the host I used, Heroku, doesn’t use SQLite. I don’t know whether the “throw it out if it’s too complicated” approach caught me up, but now I know to START with a full PostgreSQL database. If it’s going to have to come along later ANYWAY, might as well start out with it.
Looking Ahead
My code is still not quite in all the right Django standard places, but for the moment the app works and it’s deployed. I can move developing this thing to a 2-3 times a week thing to keep practicing big picture software development skills while shifting more general study of Python, job hunting, and preparing for interviews.
Pushing out a minimum viable product is a great way to practice different parts of the software development process: I am the intern who writes spaghetti code AND the senior developer who has to put a plate under it. I am the project manager AND the developer. I am the security guy AND the developer who needs to up his cybersecurity game.
I focused so much on this one app because I wanted to have something concrete I could point to, not just play Twenty Questions about software and coding with an interviewer. Yes, look, I did this, I can do it again—any questions? Now I have to actually go back and do some of the silly little games that other coding practice books have. I need to keep working on my Python in general, and not just plug-and-play different code formats for one particular framework.
For the moment, I’ll sign off.
