https://opensource.com/resources/what-open-source 

https://firefox-source-docs.mozilla.org/overview/gecko.html

https://opensource.com/article/19/8/everyday-tech-runs-linux

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Design Patterns

A design pattern is a general solution that can be used to solve commonly occurring problems in software design. A design pattern cannot be put directly into code, rather it is a template of how to solve a problem that can be used various situations.

Design patterns are helpful as they speed up the development process by providing proven examples to be used as a reference for common problems. When designing software, small subtle issues can build up leading to major problems that can only be seen during implementation. Using design patterns can help prevent these subtle issues from occurring which reduces the likelihood of major issues occurring.

Because design patterns are tested, proven, and commonly used, patterns also allows for better communication among developers by using well known and understood names for software interactions.

Types of Design Patterns

Creational

Creational design patterns cover class instantiation. These patterns can be further divided into two classifications, class-creation and object-creational patterns. Class creation uses inheritance in the instantiation process, while object creation uses delegation to create objects. Some creational design patterns are:

• Singleton
  • A class where only a single instance can exist
• Factory Method
  • Creates an instance of several derived classes
• Object Pool
  • Avoids expensive acquisition and release of resources by recycling objects that are no longer in use

Structural

Structural design patterns are about class and object composition. Like creational patterns, structural patterns can also be broken down into class creation and structural object patterns. Class creation patterns use inheritance to compose interfaces, while object patterns define ways to compose objects to obtain new functionality. Some structural patterns are:

• Adapter
  • Matches interfaces of different classes
• Private Class Data
  • Restricts accessor/mutator method access
• Decorator
  • Adds responsibility to objects dynamically

Behavior

Behavior design patterns are about how objects communicate with each other. Some examples of behavior design patterns are:

• Null Object
  • Used to act as a default value of an object
• Chain of Responsibility
  • A way of passing a request between a chain of objects
• State
  • Alter an object’s behavior when its state changes

Conclusion

This article was chosen because it clearly described what design patterns are, what they are used for, and gave examples of the different types of design patterns. As stated before, not only does the usage of design patterns help with preventing major issues, they also allow for better communication among developers which is essential to a team’s success which is why I chose to write about design patterns. As I continue to design software, effectively using design patterns will become more and more prevalent, so learning about them now will only be beneficial.

Resources:

https://sourcemaking.com/design_patterns

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

With the final blog post of the semester for Software Process Management, I wanted to review the process models we went over (waterfall and agile approaches), and perhaps take a look at some more models that we didn’t go over in class.

The waterfall approach as we went over it in the semester essentially that everything is planned at the start of the development process. This means that the plan is rigid during the course of the process. With the agile approach, the plan is highly flexible and able to change during the course of the process. Each increment of development, usually a few weeks, is followed by a plan for the following few weeks, and the cycles continues, with each aspect of the plan being adjustable as needed.

The agile approach is great for large projects and very versatile, but what other process models are there? In a blog post written by Omar Elgabry, he lays out two models that sort of make up the agile process model (incremental and iterative), as well as two other models, the spiral model and the prototype model.

Both the incremental and iterative models are based on increments of development, but the increment is the difference between them and the agile model. With the incremental approach, a complete feature is completed with each increment. With the iterative model, each increment is a small portion of all features. Compare with agile, in which each increment is a small functional portion of each feature.

The prototyping process isn’t a whole process by itself, it’s rather a tool in the form of a process to test the feasibility of a project. It’s in the name, a prototype is quickly built according to a customer’s requirements, and is helpful when the resource cost of a full project isn’t clear. The customer is usually in the loop for the development of the prototype. Once this prototyping phase is complete, the development team can opt for another process model to move forward.

The spiral model is used for cases where there is high risk associated with the project, typically large projects. The model is rarely used, but is good for testing feasibility. Essentially, each loop in a visual spiral is a phase of the project, and each phase is made up of an objective setting phase, a risk analysis phase, a development phase, and a planning phase where it is determined if the development should continue into another phase.

While I appreciate the spiral model for it’s uniqueness, I can definitely see why most teams use the agile model. It’s essentially a direct improvement from the incremental and iterative models in terms of versatility, and if you need a prototype, you can still build one using that process. Still, it’s interesting to know that we are still trying to find more ways to streamline our development to be more efficient, and I’m sure someday even agile will be taken over by another model.

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

  This last blog post I decided to revisit an important topic in class: Agile Project Management. This topic initially piqued my interest due to my lack of prior knowledge about how crucial project management can affect the product of a project. The blog post I chose highlights the Agile Manifesto and the twelve key principles to Agile. In addition, the post discusses the benefits of having a project management, for example, structured project management plans remove the fear of making a bad decision when a problem arises. Agile in particular helps improve collaboration and productivity between parties, in turn, producing a better/more refined final product.

  You might ask yourself, “These benefits sound great, but you haven’t told us how to implement Agile”, luckily this blog post dives into various tools that make project management easier. The first tool, Workast, provides features that let you create tasks for the team, set due dates, assign tasks to certain people, and even host meetings through Slack. Similar to lists in GitLab, Workast allows team members to group tasks into lists and move them according to its completion status. This tool is a great way to visualize project progression and productivity. The second tool mentioned is Trello, similarly, Trello allows teams to create to-do tasks and post them on a timeline. Lastly, we have a program called ClickUp which allows users to select a scrum workflow style. Managing sprints, tracking sprint progress, and creating daily scrum boards are just some of the features ClickUp offers.

  One thing that is the most important is having a place to manage your sprints. Having easy access to information like total estimation of the sprint and spillover tasks are crucial to analyzing project progression. After researching the three tools that the blog mentions, I believe ClickUp gears more towards an agile/scrum workflow.

  After reading the blog post, I’m curious to learn about other types of project management techniques and guides. It is no doubt that Agile is an effective approach to optimize project production, however, the Agile methodology does come with its disadvantages: poor long-term planning, dependency on the customer, greater demand on development team. Because the Agile methodology is flexible with its timelines, it’s difficult to predict when a project will be finished. Agile also utilizes feedback from the customer to ensure a product is beneficial to a customer. Team members are expected to meet daily at the same time, putting pressure on developers to stick to one schedule despite a having a duties that are constantly changing.

  Blog Post: https://www.workast.com/blog/guide-to-agile-project-management/

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.

AI has a polarizing reputation in many practices such as art, music, and coding, and seeing as you can make copies of works based on recorded patterns in less than half the time, it is understandable why people can dislike it. I like AI, it can generate funny images, make trivial tasks instant, and provide more input for someone trying to improve in a field. In coding, AI is a worrying topic that has the potential to replace many humans in the industry. However, AI is only as good as its user, a user that isn’t knowledgeable in the the product they are trying to generate cannot be as good as someone good at the field. 

In “Three Types of AI-assisted Programmers” by Isaac Lyman, the post covers the three types of people who can use AI in programming. Those three are someone with no coding knowledge, a junior engineer, and a senior engineer. The author covers the pros and cons of each person using AI to code and expresses the opinion that AI is a great addition to a team’s work, if they are attentive enough to the code generated. The pros and cons of the junior and senior engineer is what I want to highlight since AI could very well be integrated in future developer teams. The author mentions that junior developers should stray away from using AI in their work, as it may become a crutch. Rather than using AI to fulfill work tasks, junior developers should use AI to provide insight and examples to improve their skill set. A senior engineer, already having the fundamental code skills and knowledge, should just leverage the speed that AI can provide into streamlining basic code. By saving time from the menial code, senior engineers can put more time into delivering better features.

I thought this blog post contained valuable insight into the use of AI in coding and future development teams. The exploration of pros and cons for each category offers a valuable roadmap for future developer teams, emphasizing the need for a balanced and strategic integration of AI into the coding workflow. As AI continues to improve, it becomes clear that the use of AI, particularly for junior developers as a learning aid and senior engineers for time optimization, holds the key to coordinating between human expertise and artificial intelligence in the evolving landscape of coding.

Reference: https://stackoverflow.blog/2023/12/11/three-types-of-ai-assisted-programmers/

From the blog CS@WORCESTER – Leon's Blog by llai194 and used with permission of the author. All other rights reserved by the author.

In this blog, I will go over the code “smells” pertaining to the Javascript language. For this topic, I picked a specific blog post called “Javascript Code Smells: 7 to Watch out For” written by .NET software developer Carlos Schults. It delves into this topic with lots of general details that explain some bad coding practice that can lead to your code having many problems. One of the main points that the blog emphasized was that long code alone was not a bad thing rather, the difficulty of reading lines of code that became too complex to handle makes these coding “smells” important to look back on when writing code.

The reason why I picked this topic is because I have had trouble with Javascript that I had never experienced before with other programming languages such as Java or C. One of the biggest factors that made it harder to understanding Javascript was its different and more difficult use of syntax. One of the coding “smells” the blog goes over was the difference in using the equality operand in Javascript compared to Java. Since I have been more involved with other programming languages such as Java than Javascript, learning the different coding structures of Javascript was going to take a while for me to grasp, especially since coding software such as OpenAPI uses Javascript to define its data and endpoints.

My main takeaway after reading this blog was that I should continue to further explore Javascript, while also maintaining the knowledge that I currently have when it comes to organizing the code I write. Reading this article about Javascript coding “smells” was very reassuring since I may have to find a similar reference to keep my coding consistent even after learning Javascript and not let it worsen with more and more complex functions for future coding. Having already had lots of experience with other programming languages in the past, I can use what I have learned from this blog and make better use of Javascript moving forward. 

Reference: https://www.testim.io/blog/javascript-code-smells/

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

Before taking this class, I didn’t know of any guidelines for writing code. Clean code is a guideline with an objective to make code easier to understand, maintain, and read. By following its principles, a developer makes projects more likely to succeed in the long term. Learning this, I thought that I should try to implement this in all I code I make, and am still trying to make clean code practices common in my code. However, in a blog post: “Goodbye, Clean Code” by Dan Abramov, he says to “let clean code guide you, then let it go”. This was interesting, since wouldn’t having clean code all the time be nice to have for understanding the code you write? Dan during the time he recalls in the post thought so too.

In this post, Dan recalls a time when he was working on a project and checking his colleague’s code they had just turned in. The code had tons of repetitive code and math that would take a second to process. Bothered by this, he fixed it to look cleaner, removing the repetitiveness and making it so there could be changes in one spot rather than multiple methods. This resulted in a request that he reverts the changes he made from his boss, which he reluctantly agreed to do. Looking back at this event, the author says it took years to understand his boss was right. Calling clean code a phase of a coder’s life and explaining that chasing that guideline was forgetting about the human aspect of coding. Firstly, he changed his colleague’s code without discussion, which was a terrible decision when working in a team where they needed to collaborate. Secondly, he realized later that the changes he made would have impacted the project severely and added complications if he had kept them.

This blog post was not saying there was a problem with clean code itself, but how people treat clean code as an absolute guideline like the author did in the past. This post helped me understand chasing clean code is more of a detriment to yourself and others on your team and to not get too obsessed with it. Getting hung up on this aspect makes you lose sight of your project and team’s goals in mind. I think that people should keep writing clean code but not lose themselves to chasing a standard in a way that makes writing that code meaningless. While I haven’t experienced this, I can sort of understand it as how I was trying to implement these principles in my code after learning of them.

References: https://overreacted.io/goodbye-clean-code/

From the blog CS@WORCESTER – Leon's Blog by llai194 and used with permission of the author. All other rights reserved by the author.