Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named Perpetual Learning. One particular apprenticeship pattern I found interesting was “Record What You Learn.” This pattern is about taking notes and keeping track of what you learn in your journey as an apprentice or a learner. The idea is that if you write things down, you can look back on them later and remember what you’ve learned. Plus, by sharing your notes with others, you can improve your communication skills and help others learn too. There can be several ways to record what you have learned throughout your journey, such as constantly updating a journal, personal wiki, or writing a blog, such as me writing these blog posts when I learn about the different apprenticeship patterns. Those listed have only writing involved. Other ways you could record down what you have learned include making a drawing or even making video recordings of yourself. No matter what way you choose to record what you have learned, it is important to keep a date on them. This way, your recorded notes will be organized and sorted in chronological order.

I should start following this apprenticeship pattern especially since I tend to forget things that I have learned such as a stack versus a queue in Java. Sure, I could just look up what the differences are online, but actually writing it down in my own style would help me remember it more easily. In addition, if I forget anything in the future, I could always just refer back to my old notes. When I start incorporating this apprenticeship pattern into my journey, the main way I would like to take notes would be to find something digital and write stuff down in it. I prefer writing stuff down with a stylus, like using an Apple Pencil on an iPad, since I tend to remember things more when writing notes down rather than typing them out. I hope to start using “Record What You Learn” because it will be highly beneficial to my computer science career.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named Perpetual Learning. One particular apprenticeship pattern I found interesting was “Record What You Learn.” This pattern is about taking notes and keeping track of what you learn in your journey as an apprentice or a learner. The idea is that if you write things down, you can look back on them later and remember what you’ve learned. Plus, by sharing your notes with others, you can improve your communication skills and help others learn too. There can be several ways to record what you have learned throughout your journey, such as constantly updating a journal, personal wiki, or writing a blog, such as me writing these blog posts when I learn about the different apprenticeship patterns. Those listed have only writing involved. Other ways you could record down what you have learned include making a drawing or even making video recordings of yourself. No matter what way you choose to record what you have learned, it is important to keep a date on them. This way, your recorded notes will be organized and sorted in chronological order.

I should start following this apprenticeship pattern especially since I tend to forget things that I have learned such as a stack versus a queue in Java. Sure, I could just look up what the differences are online, but actually writing it down in my own style would help me remember it more easily. In addition, if I forget anything in the future, I could always just refer back to my old notes. When I start incorporating this apprenticeship pattern into my journey, the main way I would like to take notes would be to find something digital and write stuff down in it. I prefer writing stuff down with a stylus, like using an Apple Pencil on an iPad, since I tend to remember things more when writing notes down rather than typing them out. I hope to start using “Record What You Learn” because it will be highly beneficial to my computer science career.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named Perpetual Learning. One particular apprenticeship pattern I found interesting was “Record What You Learn.” This pattern is about taking notes and keeping track of what you learn in your journey as an apprentice or a learner. The idea is that if you write things down, you can look back on them later and remember what you’ve learned. Plus, by sharing your notes with others, you can improve your communication skills and help others learn too. There can be several ways to record what you have learned throughout your journey, such as constantly updating a journal, personal wiki, or writing a blog, such as me writing these blog posts when I learn about the different apprenticeship patterns. Those listed have only writing involved. Other ways you could record down what you have learned include making a drawing or even making video recordings of yourself. No matter what way you choose to record what you have learned, it is important to keep a date on them. This way, your recorded notes will be organized and sorted in chronological order.

I should start following this apprenticeship pattern especially since I tend to forget things that I have learned such as a stack versus a queue in Java. Sure, I could just look up what the differences are online, but actually writing it down in my own style would help me remember it more easily. In addition, if I forget anything in the future, I could always just refer back to my old notes. When I start incorporating this apprenticeship pattern into my journey, the main way I would like to take notes would be to find something digital and write stuff down in it. I prefer writing stuff down with a stylus, like using an Apple Pencil on an iPad, since I tend to remember things more when writing notes down rather than typing them out. I hope to start using “Record What You Learn” because it will be highly beneficial to my computer science career.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named Perpetual Learning. One particular apprenticeship pattern I found interesting was “Record What You Learn.” This pattern is about taking notes and keeping track of what you learn in your journey as an apprentice or a learner. The idea is that if you write things down, you can look back on them later and remember what you’ve learned. Plus, by sharing your notes with others, you can improve your communication skills and help others learn too. There can be several ways to record what you have learned throughout your journey, such as constantly updating a journal, personal wiki, or writing a blog, such as me writing these blog posts when I learn about the different apprenticeship patterns. Those listed have only writing involved. Other ways you could record down what you have learned include making a drawing or even making video recordings of yourself. No matter what way you choose to record what you have learned, it is important to keep a date on them. This way, your recorded notes will be organized and sorted in chronological order.

I should start following this apprenticeship pattern especially since I tend to forget things that I have learned such as a stack versus a queue in Java. Sure, I could just look up what the differences are online, but actually writing it down in my own style would help me remember it more easily. In addition, if I forget anything in the future, I could always just refer back to my old notes. When I start incorporating this apprenticeship pattern into my journey, the main way I would like to take notes would be to find something digital and write stuff down in it. I prefer writing stuff down with a stylus, like using an Apple Pencil on an iPad, since I tend to remember things more when writing notes down rather than typing them out. I hope to start using “Record What You Learn” because it will be highly beneficial to my computer science career.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

This week I read the Apprenticeship Pattern Learn How You Fail. The context of this pattern is that failure is inevitable. It happens to everyone eventually. If someone has never failed then they have either avoided pushing boundaries or learned to overlook mistakes. The problem given with this context is that your learning skills have enhanced your successes, but your failures and weaknesses remain.

The solution given for this pattern is to identify the ways in which you tend to fail and try to fix them. This pattern is not about self-pity or trying to make things perfect. It is about gaining self-knowledge about the habits and behaviors that lead you to failure. Once you become aware of the things that trip you up you will have the choice to either fixe these problems or cut your losses. You will need to accept that there are things you’re not good at or that would require a great deal of time and effort invested to fix the problem.

The action plan to help solve this issue is to use your choice of a programming language and a simple text editor to write an implementation of binary search in a single sitting. Then write all the tests you think you will need to confirm the code is correct. Before running the test and compiling the code go back and try to fix the mistakes you have discovered so far. After that run the code and see what errors are still there. Think about what you learned and how the errors could have happened when you thought the code was perfect.

I chose this pattern because as this pattern said, failure is inevitable. I have had failures in my software projects and I will certainly have more failures in the future. I want to be able to fix these failures by correcting my weakness and bad habits. Following the action plan given in this pattern will help me understand where I might have blindspots for errors. I also need to think about my past failures and figure out the common cause that leads to them. I think taking the time to do these will be a great learning experience for me and it will help me in my future career.

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

Anti-patterns are on the opposite side of the design pattern and are undesirable according to the blog “Anti-Patterns in Software Development That You Should Avoid”. Another term to describe Anti-patterns are called Design Smells.

The blog goes over the concept of the Golden Hammer anti pattern which occurs when using a familiar solution to attack an unfamiliar problem. Sometime it might work out, but most of the time it’s an inefficient way to solve problems.

The Golden Hammer anti-pattern is a concept that can shared in every aspect of life. Like for example, as mentioned in the blog some people tend to have their solution ready before understanding the problem like a doctor prescribing while the patient is still telling about the symptoms.

In software development, each design pattern is basically suited for its targeted problem. But it’s really easy to use the same framework, the same programming language, and the same design pattern for almost every problem. Like similar to the doctors example, some doctors might prescribe Ibuprofen to help a certain health but it might not completely relieve or heal that issue completely.

And so the Golden hammer could lead to; Poorly performing code, Overly complicated code, Redundant code. To avoid this anti-pattern it is best to find all potential solutions for one problem and benchmark them. List down all PROS and CONS for each solution then choose the better one.

Another anti-pattern is the God Class which for the most part controls many other classes, takes many responsibilities as well as lots of dependencies. An application could be well designed at the beginning so that there aren’t God classes but eventually dominant, very well specified classes will turn into God classes at some point.

The big ball of mud is a very common anti-pattern that happens when the solutions/application lacks a perceivable, flexible, suitable architecture as defined in the blog. A ball of mud will have, haphazardly and sloppy structure without coding comments, contains many God classes with more than 6000 lines of code, static variables/functions everywhere, methods being overloaded several times, and code duplications.

This anti-pattern is dangerous because it could happen while writing the application. Once we can’t refactor the code anymore, then we have to rewrite the entire thing. There are many reason why this anti-pattern could be brought up. It could be due to the frequent changes and requirements that the application might need, the deadline is near and the project is rushed, new developer are being brought in, or being too narrow minded about the design architecture that was initially brought in.

There are many more anti-patterns when it comes to the software development process, these are just the most common ones to date.

Link to blog: https://medium.com/geekculture/anti-patterns-in-software-development-that-you-should-avoid-780841ce4f1d

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Unified Modeling Language is a standardized language to
visually represent software construction, design, and architecture. UML designs
are process independent, and often omit irrelevant, or insignificant
relationships and attributes in favor of simplicity. UML diagrams can be used
to represent a variety of things in several ways. UML diagram can be classified
into two main categories: Structure Diagram, and Behavioral Diagram.

Structure diagrams show the structure of objects and the
relationship/interaction between those objects. Structure diagrams are to be
considered descriptive and behave like a blueprint for the code, i.e., it can
be used to inform the design of written code. Class diagrams are one of the
most frequently used Structure diagrams in software development. It shows each
of the classes in a system with their attributes, class methods or operations,
the scope of every attribute and method within a class, and the relationship
between two or more classes. A class diagram has three parts: Class Name, Attributes,
and Methods. The name of the class is always at the top, while any attribute
like a variable is in the middle. A note can be added pointing to the attribute
to show any individual specification or requirement. The methods are listed at
the bottom and can similarly have notes pointing to the method to show any
individual specification or requirement. Arrows are used to describe the
relationship between two or more classes. Depending on the arrow the specific
relationships can be identified. The various relationships are Association, Dependency,
Implementation, and Inheritance.

Behavioral diagrams show the intended function of the system
and any objects it contains. They describe how those objects should interact
with each other to make the system functional. Behavioral diagrams are
considered prescriptive, i.e., they show how the written code should work in
the system.

As a CS student, I found this
blog post on UML diagrams to be highly relevant and useful. Homework 1 and
Homework 2 provided a great opportunity to delve into the complexities of these
diagrams and gain a deeper understanding of their various properties and concepts,
especially for Class Diagrams. It will very likely be useful in future classes
as UML diagrams allow you to be able to communicate your design ideas effectively
to other members of your group, ensuring that everyone is on the same page and
working towards the same goal. They can also be a valuable resource for
documenting and maintaining software systems, making it easier to understand
and modify the system as needed. For example, the visibility of attributes and
the connections between classes, as represented by arrows, are crucial elements
that contribute to the overall coherence and functionality of UML diagrams.
Additionally, the provided examples helped to clarify and illustrate these
concepts in a clear and concise manner.

Source:

https://creately.com/blog/diagrams/uml-diagram-types-examples/

https://www.uml-diagrams.org/

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

Unified Modeling Language is a standardized language to
visually represent software construction, design, and architecture. UML designs
are process independent, and often omit irrelevant, or insignificant
relationships and attributes in favor of simplicity. UML diagrams can be used
to represent a variety of things in several ways. UML diagram can be classified
into two main categories: Structure Diagram, and Behavioral Diagram.

Structure diagrams show the structure of objects and the
relationship/interaction between those objects. Structure diagrams are to be
considered descriptive and behave like a blueprint for the code, i.e., it can
be used to inform the design of written code. Class diagrams are one of the
most frequently used Structure diagrams in software development. It shows each
of the classes in a system with their attributes, class methods or operations,
the scope of every attribute and method within a class, and the relationship
between two or more classes. A class diagram has three parts: Class Name, Attributes,
and Methods. The name of the class is always at the top, while any attribute
like a variable is in the middle. A note can be added pointing to the attribute
to show any individual specification or requirement. The methods are listed at
the bottom and can similarly have notes pointing to the method to show any
individual specification or requirement. Arrows are used to describe the
relationship between two or more classes. Depending on the arrow the specific
relationships can be identified. The various relationships are Association, Dependency,
Implementation, and Inheritance.

Behavioral diagrams show the intended function of the system
and any objects it contains. They describe how those objects should interact
with each other to make the system functional. Behavioral diagrams are
considered prescriptive, i.e., they show how the written code should work in
the system.

As a CS student, I found this
blog post on UML diagrams to be highly relevant and useful. Homework 1 and
Homework 2 provided a great opportunity to delve into the complexities of these
diagrams and gain a deeper understanding of their various properties and concepts,
especially for Class Diagrams. It will very likely be useful in future classes
as UML diagrams allow you to be able to communicate your design ideas effectively
to other members of your group, ensuring that everyone is on the same page and
working towards the same goal. They can also be a valuable resource for
documenting and maintaining software systems, making it easier to understand
and modify the system as needed. For example, the visibility of attributes and
the connections between classes, as represented by arrows, are crucial elements
that contribute to the overall coherence and functionality of UML diagrams.
Additionally, the provided examples helped to clarify and illustrate these
concepts in a clear and concise manner.

Source:

https://creately.com/blog/diagrams/uml-diagram-types-examples/

https://www.uml-diagrams.org/

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

Unified Modeling Language is a standardized language to
visually represent software construction, design, and architecture. UML designs
are process independent, and often omit irrelevant, or insignificant
relationships and attributes in favor of simplicity. UML diagrams can be used
to represent a variety of things in several ways. UML diagram can be classified
into two main categories: Structure Diagram, and Behavioral Diagram.

Structure diagrams show the structure of objects and the
relationship/interaction between those objects. Structure diagrams are to be
considered descriptive and behave like a blueprint for the code, i.e., it can
be used to inform the design of written code. Class diagrams are one of the
most frequently used Structure diagrams in software development. It shows each
of the classes in a system with their attributes, class methods or operations,
the scope of every attribute and method within a class, and the relationship
between two or more classes. A class diagram has three parts: Class Name, Attributes,
and Methods. The name of the class is always at the top, while any attribute
like a variable is in the middle. A note can be added pointing to the attribute
to show any individual specification or requirement. The methods are listed at
the bottom and can similarly have notes pointing to the method to show any
individual specification or requirement. Arrows are used to describe the
relationship between two or more classes. Depending on the arrow the specific
relationships can be identified. The various relationships are Association, Dependency,
Implementation, and Inheritance.

Behavioral diagrams show the intended function of the system
and any objects it contains. They describe how those objects should interact
with each other to make the system functional. Behavioral diagrams are
considered prescriptive, i.e., they show how the written code should work in
the system.

As a CS student, I found this
blog post on UML diagrams to be highly relevant and useful. Homework 1 and
Homework 2 provided a great opportunity to delve into the complexities of these
diagrams and gain a deeper understanding of their various properties and concepts,
especially for Class Diagrams. It will very likely be useful in future classes
as UML diagrams allow you to be able to communicate your design ideas effectively
to other members of your group, ensuring that everyone is on the same page and
working towards the same goal. They can also be a valuable resource for
documenting and maintaining software systems, making it easier to understand
and modify the system as needed. For example, the visibility of attributes and
the connections between classes, as represented by arrows, are crucial elements
that contribute to the overall coherence and functionality of UML diagrams.
Additionally, the provided examples helped to clarify and illustrate these
concepts in a clear and concise manner.

Source:

https://creately.com/blog/diagrams/uml-diagram-types-examples/

https://www.uml-diagrams.org/

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

Unified Modeling Language is a standardized language to
visually represent software construction, design, and architecture. UML designs
are process independent, and often omit irrelevant, or insignificant
relationships and attributes in favor of simplicity. UML diagrams can be used
to represent a variety of things in several ways. UML diagram can be classified
into two main categories: Structure Diagram, and Behavioral Diagram.

Structure diagrams show the structure of objects and the
relationship/interaction between those objects. Structure diagrams are to be
considered descriptive and behave like a blueprint for the code, i.e., it can
be used to inform the design of written code. Class diagrams are one of the
most frequently used Structure diagrams in software development. It shows each
of the classes in a system with their attributes, class methods or operations,
the scope of every attribute and method within a class, and the relationship
between two or more classes. A class diagram has three parts: Class Name, Attributes,
and Methods. The name of the class is always at the top, while any attribute
like a variable is in the middle. A note can be added pointing to the attribute
to show any individual specification or requirement. The methods are listed at
the bottom and can similarly have notes pointing to the method to show any
individual specification or requirement. Arrows are used to describe the
relationship between two or more classes. Depending on the arrow the specific
relationships can be identified. The various relationships are Association, Dependency,
Implementation, and Inheritance.

Behavioral diagrams show the intended function of the system
and any objects it contains. They describe how those objects should interact
with each other to make the system functional. Behavioral diagrams are
considered prescriptive, i.e., they show how the written code should work in
the system.

As a CS student, I found this
blog post on UML diagrams to be highly relevant and useful. Homework 1 and
Homework 2 provided a great opportunity to delve into the complexities of these
diagrams and gain a deeper understanding of their various properties and concepts,
especially for Class Diagrams. It will very likely be useful in future classes
as UML diagrams allow you to be able to communicate your design ideas effectively
to other members of your group, ensuring that everyone is on the same page and
working towards the same goal. They can also be a valuable resource for
documenting and maintaining software systems, making it easier to understand
and modify the system as needed. For example, the visibility of attributes and
the connections between classes, as represented by arrows, are crucial elements
that contribute to the overall coherence and functionality of UML diagrams.
Additionally, the provided examples helped to clarify and illustrate these
concepts in a clear and concise manner.

Source:

https://creately.com/blog/diagrams/uml-diagram-types-examples/

https://www.uml-diagrams.org/

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