Category Archives: CS@Worcester

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Blog post 1

The first quarter of the semester has come to a close. In CM-348 we have gone through a number of Git and GitHub features. Learning about pushing and pulling data, as well as doing some data cleaning was a great learning opportunity. As I finish my last year of school, I am trying to look at these processes in an analytical sense because that’s what I want to do moving forward.

In my free time over the past few weeks I have watched a lot of Alex The Analyst videos on YouTube. He has provided free knowledge on what it takes to become a data analyst. From interviews, to Git, to data visualization he provides a lot on his channel for people who want to learn. This week I watched his “2 Hour Data Analyst Masterclass” video. In this video, Alex breaks down what a data analyst interview process looks like from start to finish. He discusses what kinds of technical questions to expect, the importance of storytelling with data, and how to demonstrate value through projects or case studies. He also covers common interview mistakes, like not being able to explain one’s own projects clearly or failing to connect technical skills to business outcomes. This video was very insightful, he showed his viewers what skills you really need to get into the field, and it personally showed me some things I might need to work on.

I chose this resource because it’s directly relevant to where I am in my career path, as well as in my learning. I’m starting to build my portfolio and think seriously about interviews and job readiness. Alex’s advice helped me see how important communication is in data roles, it is more than being technically skilled, also being able to explain how your work impacts decisions. This connects to CM-348 because version control, documentation, and communication are key parts of the Git workflow. I am doing a bit of projecting here, but I look forward to watching more of his videos.

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