Category Archives: Week-14

Waterfall 2.0

 

When looking
around the internet, I found that there was waterfall 2.0 version of the
waterfall software development methodology that we learned at start of class. After
I saw the article, I found out that even the most established practices can
transform to meet the demands of new era. Therefore, I chose this article as it
provides basic summarization of waterfall 2.0 and the difference between
traditional waterfall model. As we talked about why waterfall method was being
replaced by agile and scrum, I thought there will be some people who will try
to improve and use the old working method so using this article showed me how
waterfall transformed to adopt need of current workflow. Therefore, I decided
to look into it as a background for finding out about the improved version as
it revives the dying method into a new form.

             This
article uses baking as an example to illustrate the principles of waterfall 2.0.
It describes the steps on planning, mixing, baking, decorating and enjoying trying
to explain how they work. For example, for planning, allowing adjustments to the
cake showing adaptability, mixing; showing collaboration with others, baking;
showing continuous monitoring, making sure the cake does not burn or become too
dry etc. This shows how the 2.0 fixed many problems of waterfall. In the end,
these changes try to solve the problem of traditional waterfall model that was
not able to adopt to constantly changing environment and unexpected changes to
the requirements and need of the program.

             Reading
this article reminded me why the waterfall model is being replaced by agile or
scrum, not able to meet the industry’s demand in changing environment. Using
cake to explain the new waterfall made the concept more understandable and memorable.
The example clearly showed what the 2.0 version tries to do in order to survive.
The concept of Waterfall 2.0 was particularly impactful because it demonstrated
that no methodology is entirely outdated. If they have the right adjustments,
even traditional approaches can remain relevant in the changing world. In the
future, I thought I might use waterfall methodology in a short and brief project
that what I had to do was very clear. However, finding out waterfall 2.0 I can
try to use it for future project. For example, it could be useful in projects
with fixed deadlines and regulatory requirements, where a hybrid approach
ensures adaptability and flexibility.

Link https://de.celoxis.com/article/waterfall-is-dead-long-live-waterfall-2-0

 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

Waterfall 2.0

 

When looking
around the internet, I found that there was waterfall 2.0 version of the
waterfall software development methodology that we learned at start of class. After
I saw the article, I found out that even the most established practices can
transform to meet the demands of new era. Therefore, I chose this article as it
provides basic summarization of waterfall 2.0 and the difference between
traditional waterfall model. As we talked about why waterfall method was being
replaced by agile and scrum, I thought there will be some people who will try
to improve and use the old working method so using this article showed me how
waterfall transformed to adopt need of current workflow. Therefore, I decided
to look into it as a background for finding out about the improved version as
it revives the dying method into a new form.

             This
article uses baking as an example to illustrate the principles of waterfall 2.0.
It describes the steps on planning, mixing, baking, decorating and enjoying trying
to explain how they work. For example, for planning, allowing adjustments to the
cake showing adaptability, mixing; showing collaboration with others, baking;
showing continuous monitoring, making sure the cake does not burn or become too
dry etc. This shows how the 2.0 fixed many problems of waterfall. In the end,
these changes try to solve the problem of traditional waterfall model that was
not able to adopt to constantly changing environment and unexpected changes to
the requirements and need of the program.

             Reading
this article reminded me why the waterfall model is being replaced by agile or
scrum, not able to meet the industry’s demand in changing environment. Using
cake to explain the new waterfall made the concept more understandable and memorable.
The example clearly showed what the 2.0 version tries to do in order to survive.
The concept of Waterfall 2.0 was particularly impactful because it demonstrated
that no methodology is entirely outdated. If they have the right adjustments,
even traditional approaches can remain relevant in the changing world. In the
future, I thought I might use waterfall methodology in a short and brief project
that what I had to do was very clear. However, finding out waterfall 2.0 I can
try to use it for future project. For example, it could be useful in projects
with fixed deadlines and regulatory requirements, where a hybrid approach
ensures adaptability and flexibility.

Link https://de.celoxis.com/article/waterfall-is-dead-long-live-waterfall-2-0

 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

Waterfall 2.0

 

When looking
around the internet, I found that there was waterfall 2.0 version of the
waterfall software development methodology that we learned at start of class. After
I saw the article, I found out that even the most established practices can
transform to meet the demands of new era. Therefore, I chose this article as it
provides basic summarization of waterfall 2.0 and the difference between
traditional waterfall model. As we talked about why waterfall method was being
replaced by agile and scrum, I thought there will be some people who will try
to improve and use the old working method so using this article showed me how
waterfall transformed to adopt need of current workflow. Therefore, I decided
to look into it as a background for finding out about the improved version as
it revives the dying method into a new form.

             This
article uses baking as an example to illustrate the principles of waterfall 2.0.
It describes the steps on planning, mixing, baking, decorating and enjoying trying
to explain how they work. For example, for planning, allowing adjustments to the
cake showing adaptability, mixing; showing collaboration with others, baking;
showing continuous monitoring, making sure the cake does not burn or become too
dry etc. This shows how the 2.0 fixed many problems of waterfall. In the end,
these changes try to solve the problem of traditional waterfall model that was
not able to adopt to constantly changing environment and unexpected changes to
the requirements and need of the program.

             Reading
this article reminded me why the waterfall model is being replaced by agile or
scrum, not able to meet the industry’s demand in changing environment. Using
cake to explain the new waterfall made the concept more understandable and memorable.
The example clearly showed what the 2.0 version tries to do in order to survive.
The concept of Waterfall 2.0 was particularly impactful because it demonstrated
that no methodology is entirely outdated. If they have the right adjustments,
even traditional approaches can remain relevant in the changing world. In the
future, I thought I might use waterfall methodology in a short and brief project
that what I had to do was very clear. However, finding out waterfall 2.0 I can
try to use it for future project. For example, it could be useful in projects
with fixed deadlines and regulatory requirements, where a hybrid approach
ensures adaptability and flexibility.

Link https://de.celoxis.com/article/waterfall-is-dead-long-live-waterfall-2-0

 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

Waterfall 2.0

 

When looking
around the internet, I found that there was waterfall 2.0 version of the
waterfall software development methodology that we learned at start of class. After
I saw the article, I found out that even the most established practices can
transform to meet the demands of new era. Therefore, I chose this article as it
provides basic summarization of waterfall 2.0 and the difference between
traditional waterfall model. As we talked about why waterfall method was being
replaced by agile and scrum, I thought there will be some people who will try
to improve and use the old working method so using this article showed me how
waterfall transformed to adopt need of current workflow. Therefore, I decided
to look into it as a background for finding out about the improved version as
it revives the dying method into a new form.

             This
article uses baking as an example to illustrate the principles of waterfall 2.0.
It describes the steps on planning, mixing, baking, decorating and enjoying trying
to explain how they work. For example, for planning, allowing adjustments to the
cake showing adaptability, mixing; showing collaboration with others, baking;
showing continuous monitoring, making sure the cake does not burn or become too
dry etc. This shows how the 2.0 fixed many problems of waterfall. In the end,
these changes try to solve the problem of traditional waterfall model that was
not able to adopt to constantly changing environment and unexpected changes to
the requirements and need of the program.

             Reading
this article reminded me why the waterfall model is being replaced by agile or
scrum, not able to meet the industry’s demand in changing environment. Using
cake to explain the new waterfall made the concept more understandable and memorable.
The example clearly showed what the 2.0 version tries to do in order to survive.
The concept of Waterfall 2.0 was particularly impactful because it demonstrated
that no methodology is entirely outdated. If they have the right adjustments,
even traditional approaches can remain relevant in the changing world. In the
future, I thought I might use waterfall methodology in a short and brief project
that what I had to do was very clear. However, finding out waterfall 2.0 I can
try to use it for future project. For example, it could be useful in projects
with fixed deadlines and regulatory requirements, where a hybrid approach
ensures adaptability and flexibility.

Link https://de.celoxis.com/article/waterfall-is-dead-long-live-waterfall-2-0

 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

Whats that smell

Writing good clean code is a work of art that takes a lot of practice and understanding. One of the first practices you should use is what’s called design smells. Design smells are indicators of possible poor design principles that will eventually impact the quality of your project.

We’ve all had that point when we first started learning how to write code where we wrote some pretty ugly “spaghetti”  code. To start, the names of these smells are rigidity, fragility, immobility, viscosity, needless complexity, needless repetition and opacity. Most of these tend to go hand in hand or could stand alone. 

It’s good to know their meanings before talking about their importance.

Rigidity: when your software is difficult to change in even the simplest ways. 

Fragility: having a tendency for your program to break in other places when you make a change.

Immobility: having useful code that could be used in other systems, but can’t be integrated very easily

Viscosity: when it’s not easy to make only one change.

Needless complexity: containing things that don’t really have any use yet.

Needless repetition: repeated code that could be abstracted instead or written over and over.

Opacity: not visually clear.

While the use of being able to identify these design smells may be obvious to some. We will start with some examples before ending with why identifying these smells will be helpful in the long run.

When first starting a project sometimes it’s hard to know where to really start. That is why developers have tools such as class diagrams, but that is for another blog. Starting off with no real design in mind it’s easy to have needless repetition pop up. Once you’ve identified you can break certain things off and turn them into their own methods, you may also realize it has caused rigidity and fragility. Moving those lines might be much harder than you think. Those problems also lead into viscosity if you end up with a big enough mess (speaking from experience).

Next is the problem of needless complexity. Without having a class diagram you might find yourself jumping ahead to try and fix a problem or do something you don’t have a need for yet. The problem is exacerbated if you don’t end up needing it at all. No one likes useless code. This can lead to opacity when your code is making the goals and intents of your work unclear.

With the previously discussed class diagrams (see previous blog) to guide you. Along with an understanding of poor design principles it’s easy to see how being able to identify these smells can keep your work in much better shape for yourself and others. We have stuck with the design process for now, a future blog topic will cover how to make the code itself “cleaner”.

From the blog Mikes CS 343 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

Is weak copyleft the strongest? (part 2)

In part 1 we covered the different types of software licensing and how they work. Now we will be looking at why you should pick a license, how you should pick a license and which license you should pick from the plethora of options.

We will start with why you should license your software. In reality there are many reasons why you would want to put a copyright and license on your software. It is something that you created after all. It is your intellectual property and hard work. You wouldn’t want someone to steal it and use it for their own gain with no credits or regards to you. You also wouldn’t want to be found liable if someone uses what you wrote and it causes something bad to happen whether it be system breaking or cause a security breach.

As for how you license your software. There is a massive amount of licenses to choose from and you don’t need to make one from scratch. In fact it is very much recommended to use one of the many that have already been created and are easy enough to add on to what you’re working on. Leave it to the legal professionals and save yourself the time and effort.

Which license is best for you depends on your own beliefs and what you would want others to be able to do with your work. As stated in part one a closed-source project is likely something you’re doing in a commercial setting so unless you’re the business owner it won’t be your decision.

If you’re starting your own project and aiming for it to be open source and don’t care too much if its modified and has the license changed or is incorporated into an existing project under a closed-source project a permissive license will be fine. You’re still the owner and your own code is still open source. An MIT license would work for you

If you’re like me and don’t want your work to be used in a setting you don’t have insight to or the ability to decide which license is used, you may look to copyleft. A GNU General Public License would be good in this case.  

There is somewhat of a middle ground however.

Mozilla is a special case and has their own license called Mozilla Public License (MPL). It is considered a weaker copy left since it does allow developers to use their software inside of a project with a different license . Though  still requiring the portions used under their license remain under their license and be open source instead of the whole project. In my opinion, it seems to be a great blend for the future of FOSS and would be my choice.

From the blog Mikes CS 348 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

Is weak copyleft the strongest? (part 1)

Software licensing has quickly become one of my favorite topics to research. When I was first introduced to the topic I sarcastically thought and said “yay” imagining the legal nonsense that i thought was coming. My professor told me he actually found it very interesting and it shouldn’t really shock me that he was right.

There are different categories for the different kinds of licenses that serve different purposes. 

You have the closed-source license which everyone is familiar with. This would include things like operating systems, Microsoft windows or Apples ios. Unless you’re a maniac using Linux on your personal computer. It also extends to a lot of smaller more commercial products like zoom, adobe products and a good amount of video games.

On the other hand you have open-source software that is steadily becoming more and more popular. You have my preferred web browser (Mozilla Firefox), the previously mentioned Linux and WordPress (where this blog is being written).

While closed-source software has a very strong and sometimes important foothold in the world we live in. There are many developers who strongly believe in the continued growth of free open source software (FOSS). For personal reasons my independent research and guided learning have pushed me towards those beliefs as well.

Inside of open-source software there are different types of licensing which can be categorized as copyleft and permissive. Both of them are great if you believe in FOSS but they do have some interesting aspects that make them different.

To start, a permissive license does exactly what you would imagine for open source software. It lets users use, modify and distribute it with minor restrictions. An example of this would be an MIT license which is used by jQuery and node, which are libraries and runtime environments for JavaScript. The minor restrictions of an MIT license are fairly basic. There’s no warranties, no liability, you must retain the copyright notices and accept liability for any issues caused by using the software.

In contrast, a copyleft (or restrictive) license has all of these restrictions but it gets to be interesting when you also restrict changing the licenses down the road. Basically with a copyleft license it forces anyone who uses, modifies and distributes the software to use the same license. This removes the ability of a user to lock up and sell their version of the software. The one drawback is you cannot use a copyleft licensed work inside of a project that uses a different license. An example of copyleft licensed software is the Mozilla Firefox web browser.

you may be thinking how do i pick a license? which license is best? which license is for me?

These questions will be answered as we explore more in part 2!

From the blog Mikes CS 348 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

API Endpoints, just so you know.

If you’re studying or working with Rest APIs, the chances of you running into endpoints are extremely high. I struggled a bit to wrap my head around them, so here’s a casual breakdown. It’s not as scary as it sounds.

What Are API Endpoints?

Let’s start with the basics. An API (Application Programming Interface) is like a menu at a restaurant(HOW MANY TIMES MUST I SAY THIS?). It tells you what’s available (services or data) and how to ask for it (requests). Endpoints are specific URLs on that menu where you go to get what you need.

Imagine you’re at a pizza place. You want to order a pizza with extra cheese and pepperoni. The endpoint is like the part of the menu that says, “Build Your Own Pizza.” It’s where your request (extra cheese, pepperoni) is processed and sent to the kitchen (server), and then your pizza (data) comes back to you.

In tech terms, an endpoint is a specific location on a server where an app interacts with the API to get or send information. For example:

https://api.pizzaplace.com/orders

Here, /orders is the endpoint where you place or check your pizza order.

How Do They Work?

Endpoints use URLs and HTTP methods to define what action you’re taking. These methods are the “verbs” of APIs:

  • GET: Asking, “What’s on the menu?” You’re retrieving information.
  • POST: Placing your pizza order. You’re creating something new.
  • PUT or PATCH: Updating your order, like adding mushrooms.
  • DELETE: Canceling your order. Sad day.

When your request hits the endpoint, the server processes it and sends back a response, often in JSON (an easy-to-read data format).

Why Do They Matter?

Endpoints make modern apps and websites possible. For instance, when you check Instagram, there’s an API endpoint fetching your posts. When you order on Amazon, there’s an endpoint processing your purchase. They’re everywhere!

Endpoints keep things organized. Instead of exposing a server’s entire functionality, APIs provide specific endpoints for specific actions. It’s like keeping the kitchen off-limits in a restaurant—you just see the front counter.

Real-World Example

Let’s say you’re building a library app. You might have API endpoints like these:

  • GET /books: Retrieve a list of all books.
  • GET /books/42: Get details about book #42.
  • POST /books: Add a new book.
  • DELETE /books/42: Remove book #42.

Each endpoint serves a purpose, and together they make the app functional.

Wrapping It Up

API endpoints are the way apps and servers talk to each other. They’re like doorways leading to the data and services you need. Understanding endpoints is crucial because they’re the foundation of so much of what we build. Whether you’re connecting a frontend to a backend or building your own API, endpoints are the unsung heroes of the digital world.

Next time someone mentions an “endpoint,” you’ll know it’s just a fancy name for a digital doorway.

References
https://www.geeksforgeeks.org/what-is-an-api-endpoint/
https://www.ibm.com/topics/api-endpoint

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

Creating a Sprint Goal and Backlog

As a one-man Scrum team, a lot of the framework provided with Scrum and Agile can be hard to apply. For example, how do I define a sprint goal for my team when I am the team, or how do I determine how much work the team is capable of when again, I’m the team.

Shouldn’t being a single person scrum team make these easier to accomplish? I mean it would stand to reason yes as I don’t have to confer with others on a sprint goal and who better to know my own capabilities than myself. The issues arise in a few places.

The most important being, as someone who is new to scrum how will I know I’m setting a realistic or achievable sprint goal. How will I know I’ve chosen the right goal for that given part of development?

Another given issue is with being the one who sets the goal and the timeframe who’s going to keep my honest and working as hard as I can without burning out? I can push myself incredibly hard and burn out after one sprint or I could accomplish almost nothing because I just didn’t feel like it and didn’t have to answer to anyone.

Thankfully, the first issue can be solved by researching sprint planning. In “Creating a Sprint Backlog: Your Guide To Scrum Project Management” by Dana Brown, she details how to create a sprint goal, how to create a sprint backlog, and how to prioritize tasks.

She highlights the first two steps of sprint planning as setting a sprint goal and identifying important product backlog items. Thankfully this is where my first issue is solved. As someone inexperienced to scrum, I would start at step two which is identifying the important product backlog items and using those to create a sprint goal. This way my sprint goal is relevant and knocks off the items highest on the priority list.

From there I can breakdown my product backlog items into smaller tasks and add them to the spring backlog. Finally organizing these tasks based of their priority and prerequisite tasks.

So, my first issue has been resolved, I now have a method of creating a sprint goal relevant to what’s highest priority. As for my second issue, unfortunately I don’t think I’m going to find an answer to that one online. It’s going to be trial and error as well as being completely honest with myself on whether the workload is too much or too little. Ultimately, it’s going to come down to how disciplined I can be.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.

TPM Podcast With Arjun Subramanian: Burnout

I chose to write about this Podcast episode in a blog because it’s a topic that resonates with me personally. This episode speaks specifically about the effect COVID had, and how burnout relates to that, which is something that affected me heavily during the COVID year. This isn’t really a topic we discussed directly in class, but Arjun Subramanian is discussing this with Mario Gerard within a technical project management context, which I feel relates to the general theme of what we’ve been discussing thus far in class.

Something Gerard and Subramanian talk about is establishing a boundary between work life and home life. This comes naturally when you’re clocking in to work from 9-5, and forgetting all about work as you come home, but when working from home it becomes harder to mentally separate the two. Working from home in the tech industry has its undeniable benefits, and there’s a reason so many people in the field prefer it, but with increased productivity also goes hand in hand with increased effort, or at least prolonged effort. It becomes harder to create a boundary between work and life when there’s no physical separation between the two. This is something that impacted me heavily, because prior to this I always kept strict separation of my school life and family life. I never invited school friends over, I only did schoolwork in my room privately, or I would set aside time at school to do it, I never talked about school at home or talked about family at school. And while I was at UMass in 2019, I had a taste of freedom for the first time. School life and social life was blending together in a way that I had never allowed it to back home. Coming home from UMass due to COVID was a huge detriment to that, and having to manage my online courses with my tense familial struggles was something that wore me thin.

The podcast also discusses how toxic environments can contribute to burnout, and the necessity of having the agency to manage and create your boundaries. You can speak up, and you work as hard as you can within your specific timeframe, and you put your heart into it, and once that time is up you come back to earth and you don’t allow work to cross that boundary into personal life.

As far as toxic situations go, that doesn’t necessarily mean a difficult one. As Subramanian talks about, you can have a difficult situation that’s right, and you need to show “grit and tenacity”. But a toxic situation is one you need to walk away from, for your own sake. There may not be a clear way to identify a toxic situation from just a difficult one, but there are signs, and while they talk about some of the signs on the podcast, the bottom line is that you need to have your own well-being in mind as you work.

The discussion about boundaries and toxic situations is one that I feel are a major contributor to the way I was affected by burnout over the COVID years, and something I’m aware I need to look out for, now and in the future.

Podcast Link: https://www.mariogerard.com/tpm-podcast-with-arjun-subramanian-project-manager-burnout/

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.