What is SCRUM?

Scrum is an agile project management and product development framework that provides a flexible way to manage and deliver complex projects. It is widely used in the software development industry but has also been applied to other fields. Scrum emphasizes collaboration, adaptability, and iterative progress.

SCRUM Values:

1. Commitment:
   • Team members commit to achieving their goals and delivering value.
   • Commitment involves dedication to the team’s objectives and a willingness to do whatever it takes to achieve them.
2. Courage:
   • Team members have the courage to question the status quo and make improvements.
   • Courage also means being honest about work progress and challenges, even when it’s difficult.
3. Focus:
   • The team concentrates on delivering a small set of high-priority items at a time.
   • Focus helps prevent distractions and ensures that the team delivers incremental value consistently.
4. Openness:
   • Team members and stakeholders are open about their work, challenges, and progress.
   • Openness promotes transparency, collaboration, and the ability to adapt to changing circumstances.
5. Respect:
   • Team members respect each other’s expertise and perspectives.
   • Respect fosters a positive and collaborative team environment, where individuals feel valued and supported.

These principles guide the Scrum Team in their interactions and behaviors, contributing to the framework’s effectiveness in delivering valuable products and managing projects in a dynamic and adaptive manner.

Why Scrum?

1. Simultaneous Development: Scrum promotes concurrent rather than sequential development, allowing programmers to code dynamically without waiting for all details to be clear.
2. Adaptability: Scrum supports ongoing project adjustments, with a variable scope while maintaining constant time and cost, contrasting traditional approaches.
3. Prioritization: Tasks are prioritized by importance, releasing completed segments in sprints, leading to faster market availability compared to traditional end-of-project releases.
4. Team Collaboration: Scrum emphasizes a close-knit development team (usually 5-9 members) with a collective responsibility for completing prioritized work. Pair programming enhances coding efficiency and quality.

Thoughts on Scrum

Despite having limited time to engage with the Scrum process, it swiftly emerged as a vital tool for me. As a self-professed procrastinator, I’ve discovered that I thrive under specific conditions. Collaborative teamwork improves my productivity, planning provides structure and deadlines, and visualizing goals, such as addressing issues, implementing fixes, and managing to-do lists, keeps me consistently focused. The daily stand-ups in Scrum are particularly noteworthy; they serve as an valuable asset for connecting with my team, offering support and advice, and seeking guidance when needed.

Sources:

https://www.atlassian.com/agile/project-management/scrum-values#:~:text=Scrum%20is%20a%20set%20of,solving%20and%20reducing%20project%20timelines.

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.

Take 2

Well here we are, back again talking about clean code. I thought it would only be fair to introduce you to its evil counter part. Now that I really think about it, I really must be goo at these blogs because I am giving away the secret recipe to the perfect code. If you know how to write clean code BUT also know how to avoid bad patterns thats the ulntimate duo, nothing should stop you!

What is Anti-Pattern

it is how NOT to solve recurring problems in your code. Anti-patterns are considered bad software design practices, and they are typically ineffective or obscure fixes. They can lead to issues such as technical debt, where suboptimal code must be addressed and corrected later.

1. Spaghetti Code:
   • Description: Code with little to no structure, making it difficult to follow.
   • Issues: Maintenance nightmare, challenging to add new functionality, and prone to breaking existing code.
2. Golden Hammer:
   • Description: Overreliance on a specific architectural pattern or tool.
   • Issues: May lead to performance issues, difficulty adapting to different problems or languages, and inhibits learning and exploration.
3. Boat Anchor:
   • Description: Leaving unnecessary or obsolete code in the codebase with the assumption that it might be needed later.
   • Issues: Causes confusion for developers, longer build times, and the risk of inadvertently activating obsolete code in production.

Why we might use it still

1. Prototyping or Rapid Development:

• In the early stages of prototyping or rapid development, the primary focus might be on quickly testing ideas or demonstrating concepts. In such cases, developers might use shortcuts that resemble anti-patterns to expedite the process. However, it’s crucial to revisit and refactor the code for production use.

Anti-pattern is a practice or solution that may seem like a good idea at first but, in reality, is counterproductive and can result in negative consequences for the software development process. It’s a term used to caution against common pitfalls and encourage developers to adopt best practices for creating maintainable, efficient, and effective code.

While there may be rare instances where the use of anti-patterns is justified, such as in prototyping, rapid development, or within legacy systems, it’s essential to recognize that intentional use of anti-patterns comes with inherent risks. These include technical debt, reduced code quality, and challenges in maintaining and scaling the software. I still encourage developers to prioritize clean code above all else.

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.

Tommorow, Not Today

As with many classes, topics, and projects I have been a part of for the last few years, I see a consistent pattern. The unwavering focus on what’s going on in the present and never connecting the dots on how something might benefit me in the future.

Code documentation is just one of the many examples I could come up with to further my point. Up until now, all my work has followed the motto of “me, myself, and I,” failing to see that in the future that won’t be the case. Eventually, everyone will find themselves a part of a team, and there is nothing worse than an amateur teammate. Let’s take a deeper look into code documentation and why it will eventually be an asset to not just you but also your future teammates.

Type of Code Documentation

Internal Code Documentation: Intended for developers inside the organization.

• Process Documentation: Provides high-level information like product requirements, roadmaps, notes, and reports.
• Developer Documentation: Provides detailed instructions for developers and staff for building, testing, deploying, or maintaining the software.

External Code Documentation: Intended for developers outside the organization who integrate with the product or need to understand its code.

• External Developer Documentation: Provides essential instructions for using source code, integrating with a product, and leveraging developer interfaces like APIs and CLIs.
• Enterprise Documentation: Furnishes information for IT staff involved in software deployment, covering hardware requirements, sizing, operational needs, and maintenance guidelines.
• Usage Documentation: Guides non-developer users on product utilization without relying on programmatic interfaces. Describes main functionalities within the product’s UI.
• Just-in-Time Documentation: Supports developers as needed, often in the form of knowledge base articles, FAQ pages, or blog posts, added in response to new features or requirements.

Low-Level or Inline Documentation: Resides within the source code and explains details of specific code parts in isolation, such as the purpose of certain functions and arguments.

High-Level Documentation: Describes the architecture, design principles, implementation guidelines, or other broader concerns.

Walkthrough Documentation: Describes flows, patterns, and other important parts of the codebase, especially for developers who need to contribute to the code.

Food for Thought

Documentation might seem straightforward, but there are some issues that must be considered whenever starting a new document.

• Knowing Your Audience: Depending on why/who you are writing your documentation for, you must consider their level of understanding when it comes to your subject.
• Updating Documentation: It is very easy to push changes to your software and forget to also push changes to documentation. This starts a cycle with co-workers where the documentation falls behind and becomes uncomprehensible.

Tommorow

Embracing comprehensive code documentation is not just a practice for today but an investment in our collective future. As we transition from individual contributors to collaborative team members, the value of clear, well-maintained documentation becomes vital to future projects.

Source – https://swimm.io/learn/code-documentation/code-documentation-benefits-challenges-and-tips-for-success

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.

Now I know what everyone is thinking, ‘You lied in your last blog.’ Yes, I did, and guess what? This is my blog, so that’s okay. You see, I could not pass up on this beautiful opportunity to kill two birds with one stone. As you may remember from my last blog, I complained about how hard it was to come up with topic ideas for CS-343. Well, well, if by some miracle I read that if topics intertwine between your two classes (343/348), we could count one blog for both classes (shoutout Prof Wurst :)).

Enough yapping, clean code time. I believe it was only a year ago when I first started taking coding seriously, and I can recall how awful my code looked. It worked… but if you wanted to debug, you had to pray before opening it. We are talking about one-function programs, with no formatting and variable names that would drive any professor mad. I quickly realized how important clean code was after watching some YouTube videos and seeing how much easier debugging was if your code had a good flow and was properly formatted. This is where I stopped when it came to clean code, unknowing that there were 100+ other factors that all combine to make clean code.

While exploring LinkedIn, I came across this article by Oleabhiele Donald titled ‘Benefits of Clean Code In Your Application Development.’ I gave this a full read and was really surprised about all the little ways I could make my code even better than it already was. Now I 1000% recommend giving it a full read, but I’m going to talk about some of the techniques that were mentioned that I didn’t know at the time or found most beneficial to me.

Use comments sparingly:

• Limit the use of comments to when necessary, ensuring clarity and conciseness. Overusing comments can clutter the code, making it harder to read. Aim for clear and concise comments that add value.

Write small, focused methods:

• Break down larger methods into smaller, focused ones, each with a single responsibility. This approach improves code understanding and facilitates easier modification.

Use unit testing:

• Incorporate unit testing practices to verify code functionality and prevent the introduction of errors. Well-designed unit tests contribute to clean and reliable code.

Avoid duplication:

• Identify and eliminate code duplication by utilizing methods, classes, and inheritance. Reducing duplication enhances code maintainability and modifiability.

These techniques stood out to me mostly because they were things I just didn’t think about. I love to keep a list on my desktop notepad that always reminds me of some of the key steps to clean code.

Why Clean Code? This a very simple answer thanks to the article, clean code is important enhances readability, making it easier for developers to understand, maintain, and collaborate on software projects. It also improves efficiency, scalability, and reduces the likelihood of introducing bugs, ultimately leading to more reliable software and a happier programmer.

Source: https://www.linkedin.com/pulse/benefits-clean-code-your-application-development-daniel-donald/

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.

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.