For anyone who codes a  program, it is important to not just have a working program, but to have  a  program  that is   easy to understand, whether you publish your program onto github, or you want to  review  your program after finishing it. Clean code is a term that was first introduced by Robert Cecil Martin, also known as Uncle Bob. He wrote a book that gives best practices and tips for writing understandable and working code. 

When creating formulas for writing code, instead of including numbers in a formula, which could lead to confusion for  a number’s purpose in   a calculation. Creating   a variable that explains it’s purpose in a code makes calculation clear. Comments can explain the meaning of a statement in a  code,  and while comments can  attempt to clear up any confusion for anyone viewing code, it should not be used to explain a obvious statement, but to explain certain actions  in code. For constructing functions, it’s best to have a function perform one action, and if a function is very lengthy, a function should be broken down into multiple functions. 

When writing code with multiple nested if else conditions,  to  make a program easier to understand,  if else conditions should be split  into descriptive functions. As someone who has worked with different programming languages, I would want to use the practices of clean code, to write a working program that I can review and understand if i revisit my work.

What Is Clean Code? A Guide to Principles and Best Practices

From the blog CS@Worcester – jonathan's computer journey by Jonathan Mujjumbi and used with permission of the author. All other rights reserved by the author.

Introduction

Version control is important for modern software development, enabling teams to collaborate effectively, manage changes, and maintain code quality. The blog post “Version Control Best Practices” by Tobias Günther offers 10 tips on how to use version control systems (VCS) like Git more efficiently.

Summary

The blog outlines essential best practices for working with version control systems, focusing on enhancing productivity and reducing errors. There were ten points but here are the top 5 most important in my opinion:

1. Use Branches: Branches allow developers to isolate changes, experiment, and test without impacting the main codebase.
2. Commit Often: Regularly committing small changes ensures incremental progress and simplifies debugging.
3. Write Good Commit Messages: Clear, detailed commit messages help team members understand the context and purpose of changes.
4. Go Beyond the Basics: Developers should invest time in learning advanced Git features like interactive rebases and cherry-picking to enhance their workflows.
5. Don’t Commit Half-Done Work: Each commit should represent a complete, functional unit to maintain repository stability and clarity.

Why I Chose This Blog

I chose this blog because version control is a fundamental skill for software development, yet its nuances are often overlooked in coursework. While I’ve used Git for assignments, I realized that my approach lacked the deeper understanding laid out in this blog.

Reflection

There was a big emphasis on commits, which makes sense as commits are an integral part of version control and most of the tips talked about in the blog are practices that I do regularly, such as writing good commit messages. I don’t think it’s particularly hard to understand these standards for version control, and once you know them it’s just the norm to follow them.

Branching was something that I hadn’t known about prior to learning about it in class, but it makes sense to separate each new feature into its own area to work on instead of putting everything in main. This “tip” is really just a necessary way to stay organized and keep the repository and its pull requests in order.

Going beyond the basic features of git like committing and pushing is also a great tip, because although you could navigate git with only the basics, learning the more advanced features like rebasing can help greatly in certain situation where you’d be happy you know how to do it.

Future Application

There were some takeaways from this blog that I could incorporate into my own workflow. I think that I should commit more often than I do. I tend to forget to commit and only do so when I stop working but by then there could be a few features that are all crammed into one big commit. 

Citation

Version Control Best Practices by Tobias Günther

https://www.git-tower.com/blog/version-control-best-practices/#8-agree-on-a-workflow

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

Intro

Frameworks play a pivotal role in streamlining software workflow. The blog post “Top 50+ Software Development Frameworks“ by Trung Tran provides an insightful overview of the purpose, types, and benefits of frameworks, making it an excellent resource for anyone involved in the software development world.

Summary of Source

The blog explains the concept of software development frameworks as pre-built tools and libraries that provide a structure for developing applications. It highlights the following key points:

1. What is a Software Development Framework: A framework is a pre-designed structure of reusable components and tools that streamlines the software development process.
2. Advantages of Using a Software Framework: Frameworks enhance efficiency, improve code quality, simplify maintenance, and enable faster development cycles.
3. Disadvantages of Using a Software Framework: Potential drawbacks include steep learning curves, limited customization, and dependency on the framework’s updates and support.
4. How to Choose a Suitable Development Framework: Developers should consider project requirements, scalability, compatibility, and their team’s expertise when selecting a framework.
5. 50+ Popular Software Development Frameworks: The blog lists widely used frameworks like Angular, React, Django, Spring, and Flutter, categorizing them based on application types.

Reason For Choosing This Source

As someone learning to build efficient and maintainable software, understanding frameworks is fundamental. This resource breaks down everything needed to know about frameworks before jumping into using them, even listing the top 50 is really useful to see for any project anyone may do.

Reflection

Prior to this blog I didn’t really have a strong understanding of what a framework for software development was. I had heard of popular ones like ruby on rails or spring for java, but I wasn’t sure what it really meant. Reading through this blog, I now feel I have a solid grasp on what they are, and how to choose one. On the topic of choosing one, there aren’t any that are one size fits all that will always be the perfect one to use, and it more depends on the project being worked on and the team behind it. I know frameworks are popular so I hadn’t considered some the disadvantages listed in the blog like the limited customization, where it might feel like you have less control of what your program does because you’re using this outline and can’t mold it as much as you may want to. A lot of times those disadvantages are overshadowed by the positives which is why they’re so often used.

Future Application

I’ve learned that frameworks are a really powerful tool that save a lot of time and help create efficient work, so I’ll make sure to study which framework is best for me to use in the future when working on projects. This blog post also helped me understand the limitations of them so I also know what to look out for in terms of drawbacks for whichever framework I might use.

Citation

Top 50+ Software Development Frameworks by Trung Tran https://www.orientsoftware.com/blog/software-development-frameworks/

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

For my final blog post for the semester, I wanted to pick a topic that was different from project management, since I had already written about that a few times. Since our most recent topic in class revolved around GitHub and git commands, I wanted to explore a blog post that aligned with that topic. I came across a blogpost by GitHub staff engineer Sarah Vessels, from the github.blog page, about code review.

In this article, code reviewer Sarah Vessels discusses some practices to help improve code reviewing and make it more useful and efficient for everyone involved. She advises constantly checking your GitHub notifications inbox, anytime you have a spare moment. She also recommends using GitHub Slack Integration. Certain queries can help filter a slack group for finding outstanding pull requests that need review. We used Discord for our class instead of Slack, but as I understand it, Slack is more common in the professional world. I believe Discord has equivalent queries that can be used, anyway. The next piece of advice she gives is to use reviewer teams to manage notifications. While catch-all code owner teams can be okay as a fallback, it’s better to keep the number of code owner teams your own small, so that anything you get pinged for or anything that shows up in your inbox feels relevant to you, and not just something to ignore.

The next part she discusses, which I feel is the most important advice, revolves around giving good, constructive code review that doesn’t across as lazy. Good code review focuses on specifically saying,” I have a problem with this, maybe you should try xyz instead” instead of saying “I don’t like this” or “This won’t work” and leaving it at that. It’s good to ask questions, because the person who authored a pull request has more context for their changes, and gives them a space to explain and justify their reasonings. Personal preferences are fine, but approval should be about the overall integrity of the code. If the changes won’t break anything or affect production, leave the feedback with a comment but still approve the pull request anyway to keep the process moving. This is something I personally appreciate from the author, because while I don’t mind receiving feedback and improving my part of the process, I hate the feeling of holding back the overall process. This allows opportunities to open discussion without causing a holdup.

She has a few other suggestions in her blogpost, like being gracious and using draft pull requests, but I believe the most important things are her advice about the giving good feedback and managing notifications so you feel compelled to give every notification your full attention. I don’t know how much code I’ll be reviewing in the near future, but if I’m ever in this situation, on either side, this is good advice for me to keep in mind and remember.

Link: https://github.blog/developer-skills/github/how-to-review-code-effectively-a-github-staff-engineers-philosophy/

From the blog CS@Worcester – Justin Lam’s Portfolio by CS@Worcester – Justin Lam’s Portfolio and used with permission of the author. All other rights reserved by the author.

Scrum is a framework that teams use to organize themselves in a project to reach a common goal. The values that members of a scrum team value are commitment, courage, focus, openness, respect. Scrum team is open to new ideas and opportunities, respecting each other, and have patience for the scrum process, and focusing on time-consumed tasks, and finding space for improvement. 

Scrum deliver a product for customer in a time period called a sprint. Product Backlog is the to-do list for a team which contains the requirements for a project. Product owner, which is one of the scrum roles, is responsible for maintaining and adding updates for the list, removing and adding new requests from customers. Sprint backlog is lists of items from the product backlog that is worked on during the current sprint. Increment is the end product of a sprint. 

The product owner guides the team on the next steps in the scrum process and ensures that the team understands the requirements that a business or client wants. The Scrum leader is responsible for making sure the scrum team works effectively. When working in a scrum team, there are different types of events that the scrum team is involved in.  Sprint planning is when teams estimate how much work needs to be done in a sprint. Daily Scrum is a short meeting where team members plan for the day, and provide updates on challenges experienced, and what work has been done. Sprint Review is the period at the end of the sprint, where the team reviews the work that has been completed, and presents it to stakeholders. Sprint Retrospective is when a team comes together to discuss the sprint result and make adjustments for future scrums. 

This semester in  CS 348, I had learned about scrum. With learning scrum, I was able to see how software team deliver products for clients. 

What is Scrum? – Scrum Methodology Explained – AWS

From the blog CS@Worcester – jonathan's computer journey by Jonathan Mujjumbi and used with permission of the author. All other rights reserved by the author.

This article is a beginning-to-end write up of the Agile methodology by Miriam Posner, an Assistant Professor at UCLA. She starts with a pov of someone watching an agile team in action, complete with all the user stories, story points, stand ups, a whiteboard, post-it notes, and sprints. For those who have not been introduced to this software development process, ‘stories’ are descriptions of features with ‘points’ showing the difficulty of implementing said features. ‘Stand ups’ are start-of-the-day meetings done standing up for quickness, the whiteboard is to organize each story point, represented by post-it notes, into the stages of ‘in-progress’, ‘done’, ‘backlog’, etc. ‘Sprints are just quick two week long work periods that help to break down the project into digestible chunks.

While this might seem rather much from to some people, others might have an opinion closer to Miriam, who found it to be efficient and intriguing. As such she researched the origins of Agile and learned the complicated history of managers and software developers. I will try to keep this summary brief while hitting all the major points.

Miriam starts with the buildup to Agile. It started in the 50’s and 60’s, most ‘experts’ said building the computer was the hard part and programming it would be trivial. The sheer enormity of their incorrectness led to a push in the field to adopt the name (and stricter processes) of engineering, leading to the coining of the term ‘software engineering’. The idea was that by following engineering techniques the experts would “transform the arcane and error-prone craft of computer programming to meet the highest standards of the engineering profession.” The next people to step in were the businesses who looked to hire these new ‘software engineers’. They created a framework of control where one person defines the project and breaks it up into steps, which are in turn handed to engineers to build and test before moving on to the next step. This was derogatorily called the “waterfall” method, so of course upper management took the name and method and ran with it. This method started to fail due again to people who were not programmers believing they knew what programming entailed. The main problem was that whenever any issue came up in the code, every step needed to be redone which meant the timeline would be increasingly muddled.

Next came Agile, created by “17 middle-aged white guys dressed in khakis and dad jeans” in the Agile Manifesto. In their words:
“We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.“

I would like to continue this dive but I am out of words.

Have a good day.

Link:
https://logicmag.io/clouds/agile-and-the-long-crisis-of-software/

From the blog CS@Worcester – Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

Hello Debug Ducker here, and this one is going to be a lot less focus. As I near the end of my college fall semester, I come to realize that I am nearing completion of college, and will hopefully come out with a bachelors degree in Computer Science. With this in mind I did some reflecting about my choice in the field and how have my classes helped me.

For this semester, I did a CS course called Software Construction, Design and Architecture. To best describe it, its like applying the fundamentals of computer science, while understanding new techniques to build better software . I remember at the beginning we review some CS concepts such as Polymorphism, Abstraction Inheritance, and Encapsulation, and when studying it I was surprise to see I was still familiar with the subjects. Even funny that I recently applied for an internship with a company that had me do a test involving those subjects It made me feel more confident with my abilities. Also with the way the class was setup I was a lot more engage with the subjects.

I also learn some new things that involve CS such as UML class diagrams that basically meant to outline the program class structure. Here is an example that I did for class assignment

This was meant for some appointment application, I just did a diagram of it. I can see this being helpful in the field to help people understand what exactly going on with classes if they are new to a project.

I also learn about API work and I am not exactly clear on how it all works but I say I understood a little. I relearn the HTTP methods during that time, which I needed cause it has been a while since I had experience with them. Funny, that one of the HTTP method names is just GET, which just gets you information from a database. Anyway I hope to return trying API so I can get a better grasp on it.

That is a review on the class work but about my efforts. I say I did quite well despite some difficulties. Some unexpected hurdles came but I was able to jump over them to the other side and learn some new skill as a result. Though time waits for nobody and I may have missed some things but hopefully that could be mended.

Now that I am typing these I would like to use to blog for other purposes in the future but we’ll see. Have a nice a holiday and thank you for your time.

From the blog Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

Hello everyone

For my last blog for the semester, the topic would be about Software Licenses and their importance in the computer science field. This was one of the most underrated things I learnt during the semester, so that’s why I wanna talk about it. Even though now it seems obvious, it never crossed my mind that I should always put a license on my project. This blog makes an amazing explanation on why you should always put a license on your work and also which one to choose from.

The blog begins by explaining the different types of software licenses, starting with:        Permissive Licenses – which impose minimal restrictions on what you can do like modification and distribution of it. Some of the most popular permissive licenses are the MIT and the Apache license. They are highly popular because they typically only require attribution, which is that you have to give credit to the original author.                                            Then the blog talks about:                                                                           Copyleft Licenses – anyone could modify and distribute the code, but they had to share their changes with the community under the same license. Some of the most popular Copyleft Licenses are the GNU Lesser General Public License (LGPL), which allow linking to open-source libraries with limited obligations but impose stricter requirements if the library is modified. There is also the GNU General Public License (GPL). They are a bit more restrictive, requiring that any derivative works be distributed under the same license and with access to the source code.                                                               

At the end of the blog, it addresses unlicensed code. Emphasizing that code without a clear license is not automatically free to use and may lead to copyright infringement. If the code does not have a license then it is considered to be under the default  copyright laws. This means that only the original author has the right to use, distribute or modify it. If someone was to happen to use it even if it is publicly available, it raises legal issues.          This blog to me was incredibly helpful and useful as it not only explained the various types of software licenses but also gave examples of them. It showed and highlighted the types of works and where would you wanna use these licenses and what works the best for you. One thing that I learnt while reading this blog was understanding what is an SBOM which stands for Software Bill of Materials. It is a detailed list of all the components in the code and their respective licenses. It is important to understand what licenses works the best for you so you can get the most out of it. The computer science field is an amazing work space that everyone can work together to build each other up and licenses help us do just that!

https://www.blackduck.com/blog/5-types-of-software-licenses-you-need-to-understand.html

From the blog CS@Worcester – Elio's Blog by Elio Ngjelo and used with permission of the author. All other rights reserved by the author.