Category Archives: CS@Worcester

Quarter 1 Blog Post for CS-348

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.

Behavioral Design Patterns

Design patterns provide many benefits when it comes to coding and software development. They are essentially blueprints to help guide and solve problems through the process of designing software. While there are three types of design patterns, the one I will be focusing on here is behavioral patterns. Behavioral design patterns mostly focus on the assignment of responsibilities between objects and help with communications between those objects.

There are many different types of behavioral design patterns. Some of these patterns include:

Chain pf Responsibility
Command
Interpreter
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor

All of these of different uses along with different pros and cons. For example, command patterns turns request into stand-alone objects called a command. This pattern allows you to capture each component of a request allowing the undo and redo of operations. However, this may cause overcomplications of code because of the layer between senders and receivers. Design patterns are easily customizable to help you approach any problem and provide solutions to many problems you may be having within development.

We’ve begun to touch on design patterns within class using UML diagrams and showing different ways to solve problems. We used the example of a duck class and different types of ducks. More duck types were added that were unusual types of ducks that had different behavior types. We used a couple different methods to help make the program work including overriding, interfaces, and behavior types. Each of these solutions had different pros and cons depending on what the user wanted out of the program.

All-in-all, each different type of design pattern has their own uses and downfalls. When working with design patterns, understand what a client or users want out of a program is key to really determining what design pattern to actually use.

From the blog CS@Worcester – Works for Me by Seth Boudreau and used with permission of the author. All other rights reserved by the author.

The Uml digram

The blog
post, UML Diagrams – Everything You Need to Know to Improve Team Collaboration,
provides a clear explanation of Unified Modeling Language(UML) Diagram, its
usage and types ending with how it helps to visualize the project. Starting
off, the blog covers the usage of UML diagrams, continuing with its key uses,
forward design, modeling before coding to plan a system, and backward design, modeling
after coding to document a finished system. Also, it covers the thirteen UML diagram
types and what each type shows and describes what each type represents and how
it contributes to visualizing processes effectively.

I chose this
article as it summarizes clearly what the UML diagram, its usage, how the UML
diagram can be used to collaborate with other teammates. First was that since
the class, I felt that I needed to understand UML diagrams better as I still
did not get what use does it has. The fact that it emphasizes UML diagram as
white board for building and analyzing the system the team gave me some reason
for understanding more about UML diagram. Not only that, but the article also
clearly goes in-depth about the UML diagram that goes way in depth compared to
the course of behavioral and structural diagrams and how they can fit together
in real-world workflows. Overall, this blog clarified how UML diagrams support
collaboration as a visual tools to help team members to see and discuss system
structures and behaviors. It made me view UML not just as an academic
requirement but as a practical communication tool that can strengthen teamwork
in future software projects.

After
looking at the article and learning more about UML diagram, I felt like even
though it might not be perfect, that I might have to use it for future use. When
coding I have something on my mind to create, but when trying to explain it or comment
on the structure of the code. Sometimes others don’t understand or sometimes I cannot
remember why I did that later. Not only that, but the rough draft of the
structure can also be used when talking with other teammates because I cannot
do everything by myself and we need to see the same picture, and I think UML diagram
will be the virtual whiteboard for it.

https://www.bluescape.com/resource-library/uml-diagrams-everything-you-need-to-know-to-improve-team-collaboration