My chosen article for this blog post is this article from the National Institutes of Health.
https://pmc.ncbi.nlm.nih.gov/articles/PMC4945047/
While at face value an article from the NIH might seem completely off topic from our class and what we’re learning currently, this article is actually all about Github. The article is centered around the Bioinformatics industry, and how a big problem with it has always been sorting, storing and accessing biological data and information credibly and easily. The introduction of the article gives a solid run down of what Github is and its relation to Git, while the meat of the article surrounds 10 “rules” to follow while using Github.
I chose this article for my first blog post of the semester because it seemed ironically fitting for the current topic of Git in our class for being an article published by the NIH. But I also chose it because it heavily relates to our sort of beginners guided usage of Git and Github that we’ve been doing. The rules given by the article all seem like really helpful guidelines for anyone new to Github like I am. I’ve always wanted to use it for personal projects and such but it’s always seemed like a daunting platform. Granted our class has torn down a large portion of the wall getting in my way from using Github personally but I do also really like these guidelines given by the article. For example, their rule 1, using Github to track your projects progress and changes make to the project, that taking advantage of its own system for doing so is a massive help from tracking progress on ones own, especially when working with a whole team of people on one project.
Out of all these rules though, I really do think rule 5 and 7 are the ones I reflect on most, I’ll admit I’m sometimes lazy and sometimes forgetful. Sometimes I do skip a test on a project. But that’s where I realize I can use that to my advantage with rule 5 of this article. It talks about using Github’s web hooks to test your code, find bugs and detect logic errors every time you push your code. Personally I don’t think it’s advantage I would pass up and don’t want to pass up in the future of using Github for class and myself.
As for rule 7, I know it seems silly but I don’t really like to discuss or bring up problems or issues I have with my projects that I’m working on. It’s always seemed like such a hassle, and whenever I did discuss the issues I’m having, its usually over discord to multiple people at once making responses to each person a mess of trying to keep up and take everything into consideration. So genuinely I do think the issues section of a project will become a very powerful tool for me. It didn’t really hit me in class because actively trying to use it as someone identifying and fixing problems for a project that wasn’t my own felt discouraging, not sure why, but I didn’t really think about from the project lead perspective. I do think a tab dedicated to finding, analyzing and fixing issues will be extremely helpful to me.
From the blog CS@Worcester – Splaine CS Blog by Brady Splaine and used with permission of the author. All other rights reserved by the author.