Timeline, Schmimeline: Outreachy Blog Post #4

(Or, in which Maria recognizes the supreme irony of being 4 weeks late for a blog post about schedules and timelines.)

Just like the last blog post, I’m … super late on this one–although in this case, I do have a bit of an excuse: I was having a lot of trouble trying to figure out a way to make my current project really fit with the post requirements. Ultimately, I decided to kind of use it as a jumping-off point and kind of do my own thing, because perfect is the enemy of good, and I needed to get something written down.

(I’ve also made the executive decision that all .gifs will include Nick Miller from New Girl today, consider yourself warned.)

Nick Miller from New Girl, getting up from the computer after saying "I got nothing."
Me the last 10 times I tried to write this post.

So, Outreachy Blog Post #4’s theme is supposed to “Modifying Expectations”–specifically talking about how project goals need to be modified due to things like delays in a kind of progress report.

I am … not having that problem. In fact, I’m kind of having the opposite problem–progress on the initial goals happened a faster than my mentor or I thought it would, and so the project scope has just grown a lot, and now I’m having to think around new features and make sure everything plays nicely with what I already managed to hammer out.

I’d love to toot my own here, but I think it’s really just a testament to the power of Django. Once you get the hang of the different views and their possibilities, especially when looking at layers of abstraction (more on formset factories later, lol) the next time you have to implement a view using those features, it’s often faster by orders of magnitude. As a result, we’ve been able to retool our goals to include additional features–like folding in another project, the Gitlab Lobby, into this project.

Nick Miller with shaving cream on his face, saying "I started from the bottom and now I'm here."
Me when I read the coverage report and realize how many freaking lines of code there are–two months ago, that number was ZERO!

I was also very lucky, in that I did have some experience previous to this with front-end work–specifically tooling CSS for WordPress websites–and that TorProject has a pretty complete set of boostrap css files in their Style Guide. As a result, a lot of time-consuming decisions (e.g., what color scheme will I use? What will buttons look like?) were already made for me–and given that I’m trying to mirror the Gitlab instance, there was a clear and logical direction to go in with other decisions in terms of where various pieces of data should be displayed.

Nick Miller from New Girl, saying "This feels like a trap."
Me when a new CBV with custom get_context_data, a custom Mixin, a user auth decorator, and some fancy templating works at getting the right info displayed from the Gitlab API on the very first try.

As a result, we’re right on schedule, even with the different hiccups we’ve experienced (let me tell you, I just about broke myself getting a full picture on class based views + custom formsets + formset factories and making that play nice with non-user based authentication AND user based authentication at the same time–but I got it eventually!)

At current, we’ve deployed the MVP out to some beta testers, with more to be added soon once I fix some of the issues that have, of course, already been revealed by the deploy. Once we get some feedback, we’ll be able to move out to the larger Tor community, as well as work on adding in some security features like rate-limiting and eventually making the site an onion site.

Nick Miller dancing while singing, "It's miserable and magical. Oh yeah."
My feelings immediately after MVP deployment

So … yeah! Knock on wood, but things seem to be going … good-ish? My mentor seems happy? Nobody is mad at me, and I’m able to sleep eight hours every night?

This is … real, right?

(P.S. I think the most fun part, has been discovering that yeah, this thing I built works–and it actually works pretty well! Because it’s a ticket reporting system–and because my project is one of the projects you can put tickets in on–I’ve actually switched to using my own project as the exclusive method by which I report issues and notes to myself (as opposed to doing it all inside of Gitlab.) It’s fast and lean, and I don’t need the other GitLab specific features … so why not?)

Leave a Reply

Your email address will not be published.