For this week’s blog post, I decided to discuss the article “Security Testing: Types, Tools, and Best Practices” by Oliver Moradov. I chose this article because it compliments the security testing topic in the syllabus. This article discusses the main goals of security testing and the key principles behind security testing, and several examples of security testing and testing tools. In this blog post I will be discussing the section on the main goals of security testing

The first section of this article discusses security testing. The article defines security testing as a series of tests determining if the software is vulnerable to cyber-attacks. “Security testing checks whether the software is vulnerable to cyber-attacks and tests the impact of malicious or unexpected inputs on its operations. Security testing provides evidence that systems and information are safe and reliable and that they do not accept unauthorized inputs.” The article also describes security testing as a non-functional form of testing, which means that security testing does not focus on the software’s functionality. Security testing fits more into the category of non-functionality testing, meaning that security testing tests whether or not the application is designed or configured correctly. “Security testing is a type of non-functional testing. Unlike functional testing, which focuses on whether the software’s functions are working properly (“what” the software does), non-functional testing focuses on whether the application is designed and configured correctly (“how” it does it). “

The main goals attributed to security testing mentioned in the article are: identify assets, identify threats and vulnerabilities, identify risk, and perform remediation. The article defines identify assets as: “things that need to be protected, such as software applications and computing infrastructure.” This is essentially what the name describes. It is about finding what needs to be protected. The article then defines identify threats and vulnerabilities as: “activities that can cause damage to an asset, or weaknesses in one or more assets that can be exploited by attackers.” Much like the prior goal mentioned, this one is also fairly self explanatory. It is about finding weaknesses within the software and possible threats that are present. The third main goal the article mentions, identify risk is defined as : “security testing aims to evaluate the risk that specific threats or vulnerabilities will cause a negative impact to the business. Risk is evaluated by identifying the severity of a threat or vulnerability, and the likelihood and impact of exploitation.” Unlike the prior main goals, which are more focused on finding specific instances of something, identify risk is about evaluating the risk being identified not finding it. The last main goal that the article discusses is perform remediation and it is defined as: “security testing is not just a passive evaluation of assets. It provides actionable guidance for remediating vulnerabilities discovered, and can verify that vulnerabilities were successfully fixed.” This main goal is also unique when compared to the prior goals because this goal is focused on finding a solution to a vulnerability.

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

The blog “Test Driven Development: The Best Thing That Has Happened to Software Design” explains the benefits of using Test Driven Development  in software development. It describes the focus on writing tests before writing the code, it emphasizes on how this approach will enhance software design, increase code quality, and allow for easier maintainability. The post highlights Test Driven Development’s ability to shift focus towards desired software behavior. I chose this blog post due to its relevance to the recently covered topics in class as well as how it can apply in writing better code. Test Driven Development is a topic that we just covered in class and I found it very interesting to see its uses and benefits.. Additionally, I am using this style of code in my CS-497 class which allowed me to further get hands-on experience with how Test Driven Development works.

After reading the blog post, I agreed with many of the points raised by the author of the blog. I found the idea of writing the tests first as a foundation of code construction seems like a great idea as when you are writing code you know how you want it to work which is how you will write the tests to make it pass. Once you have the tests you can write the code that will allow the tests that you have already created to pass. The idea of problem-solving to make the tests pass rather than troubleshooting seems like an efficient way of coding. The author highlighted an aspect of Test Driven Development that I found very beneficial as it can highly increase efficiency is how creating the tests first gives you better insight on how your code is not working properly. If you are getting the wrong output making your test fail you will know how to fix it better than without having that test in place.

This blog post allowed me to consider different aspects of solutions for coding because different styles have different benefits while developing  software. In addition, it reinforced the importance of writing clean, concise code and underscored the significance of thorough testing which are also key aspects of this class.Moving forward, I would like to and plan to incorporate the style of Test Driven Development more into my coding practices. By focusing first on test creation and then writing the code to make the tests pass, I can aim to enhance the efficiency and quality of my code. In conclusion, I believe that using Test Driven Development will increase my workflow and coding skills that will be beneficial not only in this class but potentially for the rest of my career.

https://www.thoughtworks.com/en-us/insights/blog/test-driven-development-best-thing-has-happened-software-design

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

Common Defects in Software Development

In the fast-paced world of software development, the creation of bug-free software remains a significant challenge. Despite advancements in technology and methodology, software defects or bugs continue to impede the smooth functioning of applications. Understanding the reasons behind these defects is crucial for developing more reliable and efficient software systems.

1. Human Error: A Prime Culprit

Human error remains one of the primary sources of software defects. This can range from simple typos in the code to more complex errors in logic or algorithm design. Programmers, regardless of their experience level, are susceptible to making mistakes, especially when working under pressure or tight deadlines. To mitigate this, implementing a robust review process, including peer reviews and pair programming, can help in identifying and rectifying errors early in the development cycle.

2. The Complexity Conundrum

As software systems grow in complexity, the likelihood of defects increases exponentially. Complex systems require a deep understanding and meticulous handling to ensure all parts work seamlessly together. Breaking down the software into smaller, more manageable modules can aid in reducing complexity and making the system more understandable and less prone to errors.

3. The Testing Trap

A common pitfall in software development is insufficient testing. Skipping comprehensive testing phases or having inadequate test coverage can lead to defects slipping into the production environment. Adopting a continuous testing approach and utilizing automated testing tools can help ensure thorough examination and identification of potential issues before deployment.

4. Documentation Dilemmas

Inadequate or outdated documentation can significantly contribute to software defects. Proper documentation ensures that developers have a clear understanding of the software’s design and functionality, facilitating easier debugging and maintenance. Investing time in maintaining detailed and up-to-date documentation can save considerable time and effort in the long run.

5. Tool Troubles

The choice and use of software development tools can also impact the quality of the final product. Using outdated or unsuitable tools can introduce bugs into the system. It is essential to select the right tools that align with the project’s needs and ensure they are correctly integrated and used effectively.

Prevention is Better than Cure

Addressing these common causes of software defects begins with acknowledging their presence and potential impact. By taking proactive steps such as enhancing the development process, enforcing coding standards, conducting regular code reviews, and ensuring comprehensive testing, developers can significantly reduce the occurrence of defects.

Furthermore, fostering a culture that values quality and attention to detail can encourage developers to take the necessary time and care to produce higher-quality code. Investing in training and continuous learning can also equip developers with the skills and knowledge needed to avoid common pitfalls.

The link to the blog I chose : https://www.devstringx.com/why-bugs-or-defects-in-your-software

From the blog CS@Worcester – Coding by asejdi and used with permission of the author. All other rights reserved by the author.

Rest API and CS-343 are a duo that just sounds right. When trying to give to come up with a blog idea for such a class, I couldn’t picture a clearer GIF than our dear friend Patrick Star

I try my best to not compare but it is hard not to when I compare my blog process to CS-348 and made the sudden realization I have over a hundred ideas for that class.

However, in the short two-minute comparison, I realized that since my class was approaching MS-Billion-Gillion-Trillion in Micrroservice Activity, it would be a great time to take a deep dive into Rest API.

A lot of the articles I had a chance to come across I noticed to have lots of gaps in the information provided. Noticed in some there was missing clarification, simplified introductions, and Chat-GPT “Whats Rest API” money makers. REST API and API in a Nutshell. Deep Diving Into REST API by Krunal Chauhan offered the best of both worlds in offering me a crash course on Rest API and a challenging question started on the advanced side of such a topic.

Crash Course KNOWS:

1. Definition of API:
   • API stands for Application Programming Interface.
   • It acts as a software intermediary allowing communication between different applications or devices.
2. Need for API:
   • Necessary for communication with various devices and services.
   • Enables interaction with web browsers, mobile devices, and third-party software.
3. API Explanation (Metaphor):
   • Describes API as a mediator, like a waiter in a restaurant, facilitating communication between the client (user) and the backend (kitchen).
4. How API Works:
   • APIs communicate through rules/protocols.
   • Typically works over the internet via HTTP, built on top of the TCP/IP protocol.
   • Analogizes API communication to a customer (user) placing an order through a waiter (API) to the kitchen (backend).
5. REST API:
   • Represents a style of API architecture that uses HTTP and is user-friendly.
   • Introduced by Roy Fielding and is considered a standard protocol for web APIs.
   • Works with HTTP methods like GET, PUT, POST, and DELETE.

CRASH CROUSE DEEP DIVE:

1. Building Blocks of API:
   • API Interface Block: Defines specifications for the API, often using HTTP.
   • API Controller Block: Manages traffic, and handles authentication, and authorization.
   • API Runtime Block: Executes the business logic of the API.
   • API Data Bridge Block: Facilitates seamless access to shared data storage.
2. API Management:
   • Involves designing, publishing, documenting, and analyzing APIs in a secure environment.
   • Components include API design, API gateway, API store/developer portal, and API analytics/dashboard.
3. Types of API:
   • Open APIs (Public API): No restrictions on access.
   • Partner APIs: Requires specific rights or licenses.
   • Internal APIs (Private APIs): Used within a company for internal purposes.
4. REST API Architecture Components:
   • REST Client: Code or app accessing REST services.
   • REST Server: Offers API and resources.
   • REST API: Defines endpoints and methods.
   • Endpoint/URI: Specifies where to find a resource.
   • REST Request: Includes HTTP method, endpoint, headers, and body.
   • REST Response: The server sends a representation of the resource, often in XML or JSON.

I enjoyed reading these types of articles when the reading flow is smooth and coherent to the subject. If you can believe it or even if you check the article yourself, the summary above is my notes for the article and about how 99% of the article flowed.

A good chunk of the reading was a good reminder of things I already learned but there was also a few sections that required me to go back as we have not had the chance to talk in-depth about them.

Specifically, the Rest API Management as this was the first time I ever heard these terms before and was not a section we were able to cover just yet. Out of the article I was able to break down the Rest API Management into 4 sections.

1. API Design:
   • This block enables users, including developers and partners, to design, publish, and deploy APIs. It includes recording documentation, security policies, descriptions, usage limits, runtime capabilities, and other relevant information.
2. API Gateway:
   • The API Gateway acts as a gatekeeper for all APIs. It handles tasks such as routing requests, composition, and protocol translation. It enforces relevant API security policies, ensures authorization, and guarantees the security of requests.
3. API Store / Developer Portal:
   • This component provides a place to keep APIs in a store or catalog, exposing them to internal and/or external stakeholders. The API store serves as a marketplace where users can subscribe to APIs, obtain support from the community, and access other relevant information.
4. API Analytics/Dashboard:
   • API management solutions offer analytics and dashboards that allow users to monitor API usage, load, transaction logs, historical data, and other metrics. This information helps in understanding the status and success of the available APIs, facilitating data-driven decision-making.

Now I’m not sure why I found this part so interesting and why I found myself watching a 30-minute YouTube video on how API dashboards work and operate, but hey whos going to judge? This is a section I believe we are going to cover/hope we do as it’s been a great experience learning how to build and read complicated APIs. I feel like I am ready to take another step and properly learn how I would manage one of these APIs that I created.

PS: “Advantages of API vs ******** ” (Stay Tuned)

Until Next Time

Source: https://medium.com/@krunalchauhan_/article-worth-reading-on-what-is-an-api-what-is-a-rest-api-and-deep-diving-into-rest-api-fea074dacaed

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

As a student navigating the intricate world of software development, stumbling upon Andreas Schöngruber’s insightful article on anti-patterns was like discovering a treasure map through the labyrinth of coding pitfalls. Titled “What Is an Anti-pattern?”, the article serves as a comprehensive guide to understanding, identifying, and avoiding anti-patterns in the software development lifecycle.
Schöngruber’s article begins by defining anti-patterns as deceptive solutions that appear effective but ultimately create more problems than they solve. These pitfalls manifest in various aspects of software development, from programming practices to methodological and testing phases. The article covers programming anti-patterns like Spaghetti Code, Lava Flow, Accidental Complexity, God Object, Hard Code, and Magic Numbers. It further explores methodological anti-patterns such as Premature Optimization, Reinventing the Wheel, and Copy and Paste Programming. The discussion extends to software testing anti-patterns like the Wrong Kind of Test, Testing Internal Implementation, and the Happy Path.

Why I Chose This Resource:

In the ever-evolving landscape of software development, understanding what to avoid is as crucial as knowing best practices. The article’s clarity in categorizing and explaining various anti-patterns appealed to me as a student eager to enhance my coding skills. It provides a roadmap to steer clear of common pitfalls and promotes a proactive approach to creating efficient and maintainable code.

Reflection on the Content:

As I delved into the programming anti-patterns, the concept of Spaghetti Code resonated with me. Schöngruber’s emphasis on modularity and readability struck a chord, prompting me to reflect on past coding practices. The discussion on Hard Code also resonated, making me rethink my approach to configuration management. The article prompted a realization that simplicity, adhering to the “Keep it simple, stupid” (KISS) principle, is not just a preference but a necessity.

Moving into methodological anti-patterns, the notion of Reinventing the Wheel made me reconsider some instances where I may have overlooked existing solutions. The discussion on Premature Optimization underscored the importance of balancing performance improvements with actual needs, a valuable insight for optimizing code efficiently.

Application in Future Practice:

Armed with the knowledge gained from this article, I envision a more discerning and proactive approach to my future coding endeavors. Recognizing anti-patterns will not only enhance the quality of my code but also contribute to a more efficient development process. I plan to integrate the principles discussed, such as modularity, simplicity, and avoiding unnecessary optimizations, into my coding practices. Additionally, the insights on testing anti-patterns will guide me towards more effective quality assurance strategies.

For those eager to navigate the labyrinth of software development with fewer missteps, I highly recommend reading Schöngruber’s article. It’s a valuable addition to any student’s toolkit, providing insights that transcend textbooks and delve into the practical nuances of writing robust and maintainable code. You can access the article with the link below.

https://www.baeldung.com/cs/anti-patterns#:~:text=Anti%2Dpatterns%20are%20the%20opposite,project%20management%2C%20and%20organizational%20behavior.

From the blog CS-343 – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

This week’s topic I decided to choose a blog post about the writing of clean code to correlate with what we’ve been learning in class. The blog post, published by Jacob On Software, details how the writer has been reading Clean Code by Robert Martin. This handbook identifies the significance of writing clean code, as well as, how to properly write readable and professional code. Jacob On Software takes a unique and effective approach to teach readers; refactoring one of his old projects. Jacob states in his blog post that during this project, he was forced to learn how to create a full stack web application in just three weeks, resulting in him rushing and writing not so clean code. The blog post highlights that other contributors working on his project will have strenuous time trying to decipher his messy code, hindering the development process and evolution of the software.

Looking at an image of the his code, we can see that the name of his functions are descriptive of what they accomplish, however the functions themselves have too many lines of code, which is a crucial aspect detailed in the Clean Code book. Having functions that are thousands of lines long makes it a nightmare to understand what the function is doing. Clean Code emphasizes that functions should be small and straight to the point. Jacob fixes his code by splitting up the function into smaller functions. Additionally, Martin’s Clean Code stresses that a function should do one thing. Previously, Jacob’s function was performing multiple operations like holding data and updating it. These operations were split up into their own functions, allowing others to instantly understand the purpose of these functions.

Further into the blog, Jacob talks about the formatting of his code. The more lines a file has, the harder it is to understand. Users only have a limited amount code that will fit on their screen at once. If the developer has to constantly scroll up and down through hundreds of lines just to understand your code, you are not writing clean code. The same can be said horizontally, lines in your code should not be extending off to the right of the screen.

I chose this topic because after looking at the examples of bad code and good code in class, I admit that most of my code that I’ve written in other classes would be considered bad code. Non-descriptive variable/function names and multiple operations in functions have definitely been a weakness in my code. It’s crucial to write clean code as software developer working in a team so other team members can easily understand your code. I plan to use this information as a guideline on how to write more descriptive and readable code in the future.

Blog Post: https://medium.com/codex/reading-clean-code-week-2-643641e4dc28

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.

During our classes we discussed the definition, theory, values, team makeup, events, and artifacts of Scrum. I decided to focus on one of the events of Scrum within the Sprint called the Daily Scrum. The Daily Scrum was briefly described and we discussed how the Daily Scrum allows the team to inspect progress toward the Sprint Goal and to adapt the workload as necessary. What we didn’t do was discuss the best way to go about that. I wanted to understand the best practices for proper communication with team members in accordance with Scrum values. The blog “Ten Tips for More Effective Daily Scrums” by Mike Cohn helped with this by giving 10 helpful tips for how to conduct a Daily Scrum. Cohn specializes in agile processes and techniques and makes a living by helping companies build high performance teams.

After reading the tips, I could see that most of the points were prioritizing focus, one of the main values of Scrum. Most of the tips give solutions or show problems that arise that stop the Daily Scrum from focusing on the Sprint Goal. The problems it shows are what I assume to be problems that happen repeatedly for people new to Daily Scrums. They don’t talk about the current Sprint, talk about work done unrelated to the Sprint Goal, focus on unrelated details, and ramble. I liked how the author handled the issues. He pushes the idea that you should set ground rules or guidelines that everyone understands before conducting the Scrum. Having words or phrases that let the team know you might be rambling or for letting a person quickly explain that non-Sprint Goal work was done seemed like a very good way to professionally conduct a meeting. I would think it’s hard to tell someone that they are rambling more than they need to. To have a buzzer or code word established must help communication without hard feelings and allows everyone to be on the same page.

 I also appreciated prioritizing the use of certain words. Saying “impediments” instead of “blockers” or asking about what a person “accomplished” instead of what they “did”. I wouldn’t normally think to prioritize certain words while conducting a meeting, but his explanation on how it changes the team’s perspective on the work during the Sprint was enlightening.

This blog showed me that when communicating with your group, whether in a daily Scrum or not, there are simple ways to optimize communication. The tips given weren’t groundbreaking, but I can see various ways this could be used when communicating with others. Going forward, I plan on setting an outline of ground rules that the team agrees on so we can effectively communicate.

Link to “Ten Tips for More Effective Daily Scrums” by Mike Cohn – https://www.mountaingoatsoftware.com/blog/ten-tips-for-more-effective-daily-scrums#author

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

https://socpub.com/articles/how-can-cloud-computing-enable-remote-teams-work-more-productively-17895

https://aws.amazon.com/application-hosting/benefits/

https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-azure

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

https://socpub.com/articles/how-can-cloud-computing-enable-remote-teams-work-more-productively-17895

https://aws.amazon.com/application-hosting/benefits/

https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-azure

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

https://socpub.com/articles/how-can-cloud-computing-enable-remote-teams-work-more-productively-17895

https://aws.amazon.com/application-hosting/benefits/

https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-azure

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