Design patterns are essential concepts in software engineering, providing time-tested solutions to common problems. As an apprentice in computer science, understanding design patterns can significantly boost your coding efficiency and software design skills. During my learning journey, I found an insightful article, Java Design Patterns from GeeksforGeeks, that provided me with a solid foundation on design patterns. Here’s a summary of the article and my reflections on how it has shaped my learning experience.

Summary of the Selected Article

The GeeksforGeeks article Java Design Patterns covers the key design patterns used in Java programming. It introduces three main types of design patterns—Creational, Structural, and Behavioral. Each category is explored with practical examples and explanations that break down the complexities of design patterns into digestible information. The article also touches on popular patterns like Singleton, Factory, Decorator, and Observer, providing clear definitions and illustrating their use cases in real-world Java applications. It serves as an excellent resource for beginners to grasp how design patterns can improve code readability, reusability, and maintainability.

Reason for Choosing this Resource

I chose this article because GeeksforGeeks is known for delivering educational content tailored to both novices and experienced developers. I needed a source that could present design patterns clearly and practically, specifically for Java programming, which I am currently studying. The website’s step-by-step approach to explaining concepts, accompanied by code snippets, resonated with my learning style. As a beginner, I was looking for a resource that could demystify design patterns without overwhelming me with technical jargon, and this article did exactly that.

Personal Reflection and Key Takeaways

The material was enlightening, especially in how it framed design patterns as reusable solutions to software design issues. Before reading the article, my understanding of patterns like Singleton or Factory was limited to theoretical concepts, but the examples provided helped me visualize their practical applications. One major lesson I took from this article is the importance of the Singleton pattern, which ensures that a class has only one instance and provides a global point of access to that instance. This concept is essential in areas like database connections, where having multiple instances could lead to conflicts.

Additionally, learning about the Factory pattern—a creational pattern that allows for the creation of objects without specifying the exact class—opened my eyes to how flexibility and scalability are achievable in code. This pattern is especially helpful when dealing with large projects where new object types might frequently need to be added.

The article not only strengthened my grasp of object-oriented principles but also inspired me to think more critically about how I structure my code. It shifted my perspective from merely getting the code to work, to considering how to design it efficiently for future use and maintenance. I now see design patterns as a roadmap to writing better, more scalable code.

Future Application of Design Patterns

Moving forward, I plan to incorporate these design patterns into my coding work practices, particularly in my Java projects. The Singleton pattern will be useful in managing system-wide resources, while the Factory pattern will aid in developing modular code that can easily evolve. Understanding these patterns equips me to write code that is not only functional but also adaptable, which is crucial as I delve into larger, more complex projects.

In conclusion, design patterns are invaluable tools for every software developer. Thanks to resources like the GeeksforGeeks article, I now have a clearer understanding of how to implement these patterns in Java, and I look forward to applying them in my future projects.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

For my first real blog entry, I would like to talk about Code Review. I chose this topic because we are doing in-person activities based on clean code, in my Software Process Management class. When discussing how to make code cleaner and more readable, I looked more into the topic for more information. Code Review is a process performed by a person or more to examine and improve the code. I found this blog titled “How to Review Code – Tips and Best Practices” by ‘AK DevCraft’ and noticed that some of the points and practices are the same as we learned in class.

The blog highlights three important tips to be aware of when reviewing code, the first tip being Intention. This tip explained what the dos and don’ts are when reviewing code. When you review someone’s work, it’s pivotal to be positive and respectable. Giving constructive criticism, and explaining precisely what changes need to be made to improve the code. The blog also made sure to emphasize not to leave comments where you didn’t need one. Adding multiple comments to code is unnecessary and makes the code harder to read. The summary of the first tip was to be respectful to the ones who wrote the code and make it a collaboration when reviewing the code.

The second tip the author said was important was Standards. When reviewing code, making the code easy to read while making it easy to understand is what coding is all about. This can be done by sticking to a consistent format, which can be having meaningful whitespace, removing unnecessary gaps, or breaking larger functions into smaller ones. Understanding the standards of variables by creating clear and concise names for every variable. By knowing to avoid abbreviations and add values to variables such as “gallon” or “mL” to make the variable clear on what unit it is. A good practice we learned in class is to avoid duplication, duplication of code can lead to unnecessary code or more confusing messes like bugs or error messages.

The last tip the author highlighted was to review. When finishing the code review, keeping the big picture in mind can verify if your changes were necessary. GitHub is a platform we are using in class for our in-class discussions the platform has a review system to look over the source code and can help you double-check the code.

The blog shined a light on tips I believe are important when reviewing code, when my group did discussions on reviewing code, we used the same tips listed in this blog in our discussion. The blog gave me information on taking reviewing code to the next level, informing me of the GitHub feature to review the source code and always keeping a strict format in mind when reviewing code. I would recommend this blog to someone who is new to reviewing code or just wants a different approach when reviewing code with another person.

Source: https://dev.to/akdevcraft/how-to-review-code-2gam

From the blog Mike's Byte-sized by mclark141cbd9e67b5 and used with permission of the author. All other rights reserved by the author.

This week, I am going to provide some insights/opinions regarding the practicality of some clean code principles, along with an example of when over-optimization for the sake of readability might actually be counterproductive. The resource I will be referencing this week can be found here. This article documents many of the same clean-code principles we discussed in class, plus or minus a few. For each principle, it provides an explanation as well as a coded example to demonstrate the principle and/or the difference between good and bad code according to the principle. I chose this article because I felt it was comprehensive enough to cover the key points for clean coding, and because I tend to use many of the principles outlined in the article in my own code.

I am currently involved in a project where the Single Responsibility Principle (SRP) might actually be counterproductive to my primary objective. In general, I tend to agree with this principle, and I understand its benefits well. It makes code far easier to read and follow, and, as we discussed in class, modern compilers can optimize functions to where there is almost no difference in execution time by offloading logic into its own function.

My program runs an ultra-fast search on a set of numbers (speaking very loosely), and needs to update numbers around 250 times per second. Thus, my time to find what I am searching for and act on it is ~4ms before all the data is useless (think: cracking Enigma in The Imitation Game). Now, factor in that I need the majority of the ~4ms to actually execute based on my search result, and one arrives at the conclusion that the search needs to take <1ms (or as little time as possible). Now to my point: sometimes, to accomplish this, I found that I had to violate the SRP. This means that I call search(), and search() immediately calls execute() if it finds what it’s looking for, eliminating the time it would have taken to return the value to main() and then pass the value back to execute(). This is obviously a miniscule difference, but in my testing and gathering data, I found that when multiplied out to larger and larger numbers, this little hack shaved off a noticeable amount of time.
This might all be more related to Command-Query Separation or the “No Side Effects Principle” than it is to the SRP, but my points still stand. What I am getting at in the big picture is that these principles, while applicable and preferable a massive portion of the time, are not always the right way to go. Sometimes, you have to sacrifice one or more in pursuit of your primary objective. All this said, my largest takeaway going forward is that I should remember and implement clean code principles whenever/wherever possible, but I will always try to remember that they are not law, and sometimes variance is necessary.

From the blog CS@Worcester – Mr. Lancer 987&#039;s Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

This week, I am going to be chatting about the benefits of Humanitarian Free and Open-Source Software (HFOSS). Prior to class this week, I was familiar with open-source software, as I have previously integrated some open-source projects into personal projects, but I had never heard of HFOSS specifically, and had not given thought to the potential benefits of popularizing HFOSS development in an educational environment. Instead of referencing a blog this week, I am going to look at an actual HFOSS project that can be found here.

Crisis Cleanup is a platform designed to connect volunteers with individuals affected by disasters, particularly during and after events like hurricanes. This project is a perfect example of HFOSS, demonstrating how collaborative, community-driven software can make a meaningful and real impact.

One of the coolest parts of this HFOSS project is its emphasis on community engagement. Crisis Cleanup operates on the principle that local volunteers can provide the most relevant and timely assistance to those in need. By facilitating connections between volunteers and those affected, the platform enables random people to help in ways they probably otherwise couldn’t. Combine this with the fact that anybody can contribute, and now there is a unique opportunity to create a learning environment for students. Contributors can gain practical experience in software development, project management, and user interface design while working on real-world challenges. Students can also witness the immediate impact of their contributions, reinforcing the idea that their work can lead to tangible change. As we discussed in class, this seems to raise interest/appeal in computer science in groups that are otherwise generally less interested in it, which is an awesome way to get more people involved in the field.

Crisis Cleanup also highlights the importance of adaptability in software development. During a disaster, the needs of affected individuals can change rapidly. HFOSS allows for quick iterations and updates based on feedback from users and volunteers on the ground. This agile approach to software development ensures that the platform remains relevant and effective, which is crucial for a disaster relief program in particular. I think another really cool thing about this HFOSS project (and HFOSS in general) is that the Agile methodology is generally used. It makes sense; Agile is not exclusive to professional software development teams, but to see it used or even suggested for an open-source project is not what I would have guessed at first.

Personally, I have always had an interest in Computer Science, regardless of my awareness (or lack thereof) of HFOSS. I have not yet contributed to any projects of that nature. Moving forward, maybe I will find one to contribute to on my own, now that I know how much they can help people. Overall, I think they are an excellent way to learn/enter the field of Computer Science, and I would love to see more educational environments centered around HFOSS development and projects like the Crisis Cleanup project.

From the blog CS@Worcester – Mr. Lancer 987&#039;s Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

The part of the “Apprenticeship Patterns” textbook by David H. Hoover and Adewale Oshineye that I find myself flipping back and forth through the most is the fifth chapter, titled Perpetual Learning. I’m planning to depend on my skills in software craftsmanship to establish a stable career and earn enough money to finance my other pursuits in life, and consequently I need to think seriously about nurturing my foundational skills and refining my learning process.

I’m taking a course this semester that has me relearning C++, a language that I haven’t used in several years. I had been programming almost entirely in Java since beginning Worcester State University’s Computer Science program, and the material of this course is requiring me to jump right back into the deep end of C++. I find myself unsure whether my approaches to certain challenges are correct or not, as well as feeling more concerned with whether my code will compile instead of whether I am learning the tools of the C++ language effectively.

When I want to truly absorb some kind of knowledge, I’ve realized that I learn something best when I receive positive feedback when I demonstrate my skills properly and correctly. When I wanted to learn how to play the guitar when I was younger, the first thing I tried to learn was the start of “Breaking The Law” by Judas Priest. The positive feedback I got from learning that part was hearing sounds from the guitar that I was playing that sounded a lot like actual music! After that, I couldn’t stop myself from learning how to be a better guitar player because of how much I wanted to keep myself in that positive feedback loop. I kept learning, I sounded better, and the feedback loop has been growing more rewarding as time goes on. I’m confident that lots of other people can relate to this experience, even if the thing that they were trying to learn wasn’t music or playing an instrument. Being able to gauge your own progress through positive feedback benefits the learning process dramatically.

This pattern is concerned with creating that same kind of positive feedback loop within the context of software craftsmanship. Seeing the quality of your output increase in proportion to your effort in learning can be the fuel that keeps a programmer engaged in refining their craft. The pattern is introduced with a quote from Jerry Weinberg’s “Project Retrospectives”:

“We in the software industry are working with a more or less invisible product, yet this very invisibility only heightens our need for feedback.”

It feels difficult for me to decide “where I am” as a programmer without comparing myself to the people around me. That approach takes my focus away from my own growth however, and I want to avoid it. So instead, the solutions proposed by this development pattern include researching test-driven development and using interactive interpreters that can let the programmer catch errors and see outputs as they write code. The programmer also has the option to intentionally reach out and seek feedback on their coding process from peers and mentors, or by participating in pair programming. A given example of applying this pattern in the real world is asking the interviewer for a position that you were not accepted for why the company didn’t want to bring you on board. This is a more positive framing of what could be a rather upsetting situation, and an outside perspective can also give you insight into aspects of your work and yourself you hadn’t paid attention to.

The key to collecting all this data is to construct useful and actionable feedback for yourself. The pattern defines “useful feedback” as feedback that you can do something in response to that informs you whether to do more or less of a certain behavior. The textbook challenges the reader to put this pattern into action by identifying a metric in their working environment that they have the capacity to change and measure. Then, use the measurements of that metric to try and understand how your actions have changed your “working environment”.

Reflecting on this pattern has made me realize that I have rarely, if ever, sought out external feedback for projects that I’ve worked on outside of school. I’ll write code, compile it, and push it to my Github, but I’ve never made the effort to construct testing suites or seek external criticism from other programmers. These habits have enabled a feeling of doubt to sprout within me about whether my code could be adapted to perform a useful task, or whether I’m actually making any progress in my learning. I’ve started thinking about the advice proposed by this development pattern, and I’m going to take the time to read “Test-Driven Development: By Example” by Kent Beck, the reading material sourced in this pattern. I’m also going to research the features of Visual Studio, my preferred text editor, to see if there are any extensions that allow for the features offered by interactive interpreters.

I’m not sure that I understand the pattern’s advice about “gathering metrics to understand the effects of your changes to your working environment”, but the practical advice of using software tools to provide feedback as you work as well as inviting constructive criticism from others makes perfect sense to me. The pattern also urges the learner to put themselves in situations conducive to building these feedback loops. I think that some of the strongest fuel for those feedback loops are the relationships we create with others along our learning journey, and in the online realm of software development, I don’t think it would be hard to find a community of developers eager to forge and fully energize those feedback loops.

From the blog CS@Worcester – Michael&#039;s Programming Blog by mikesprogrammingblog and used with permission of the author. All other rights reserved by the author.

Summary:

The pattern “Nurture Your Passion” addresses the struggle faced by software developers whose passion for their craft is hindered by the work environment. Often kept to “simple” tasks or faced with demoralizing conditions like corporate hierarchies or project death marches, developers find it difficult to maintain their enthusiasm. However, the pattern suggests several strategies to protect and grow this passion.

Reaction:

The pattern could be related to deeply with many software developers who have found themselves in similar situations. It highlights the importance of preserving one’s love for the craft amongst challenging circumstances. What’s really interesting is the acknowledgment that not everyone has the privilege to earn a living through their passion, making it important to safeguard and nurture it.

What’s Interesting and Useful:

The emphasis on working on tasks that align with personal interests stands out as a practical approach. By dedicating time to activities that spark joy, developers can reignite their passion and find fulfillment in their work. Additionally, the idea of seeking out like-minded individuals and immersing yourself in the classics of the field serves as a reminder of the rich heritage and community support available in software development.

Impact on Professional Outlook:

The pattern encourages a reevaluation of how someone approaches their career in software development. It makes individuals prioritize environments that support their growth and passion, even if it means diverging from conventional career paths. Setting clear boundaries and maintaining a sense of wonder about programming, as said by Paul Graham, becomes essential for long-term satisfaction and success in the field.

Disagreements and Reflections:

While the pattern offers valuable insights, some may find it challenging to implement certain suggestions, especially in highly demanding work environments. Setting boundaries and steering conversations towards positive topics require courage and confidence, which may not always be feasible depending on organizational culture and power dynamics. However, the underlying message about the importance of preserving one’s passion remains relevant.

In conclusion, “Nurture Your Passion” serves as a reminder that maintaining enthusiasm for software development is a deliberate effort, especially in the face of adversity. By embracing strategies outlined in the pattern and staying true to their passion, developers can navigate challenges and thrive in their careers.

From the blog CS@Worcester – Site Title by rkaranja1002 and used with permission of the author. All other rights reserved by the author.

In this week’s blog post, I will be discussing the “Long Road” pattern discussed in chapter 3 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This week, I chose this topic for my blog post because I often worry about not being able to learn or grow more in my field, becoming stagnant because there is nothing else I can learn. Thankfully, this pattern dissuaded those fears of mine and inspired great confidence in my future endeavors.

The quote that this pattern opens with immediately puts much of my concerns about the limits of what I would be able to learn to rest. “‘How long will it take to master aikido?’ a prospective student asks. ‘How long do you expect to live?’ is the only respectable response.” In comparing computer science to Aikido, it implies that no one can possibly learn all that there is to know in computer science. Another quote from this section that makes me even more excited to be a part of this field mentions that for every step you make, the finish line is two steps further away. “For every step you take toward mastery, your destination moves two steps further away. Embrace mastery as a lifelong endeavor. Learn to love the journey.” While this may seem like a disappointing aspect of our field for many, the limitless opportunity for me to grow is why I love this field of knowledge.

I did not think it was possible, but further reading in this section made me even more excited and proud to be in computer science. “Close your eyes and imagine the strangest possible role you could be playing in 10 years’ time. Have fun thinking of the wackiest possible future for yourself. Then think about 20, 30, and 40 years from now. What kinds of experiences do you want to have tried? Imagine that 40 years from now, you are asked to write a short description of your professional history and the biggest influences on your path. Use the output from that thought experiment to help you plan your future career choices.” This quote had me thinking about incredible and outlandish possibilities in this field, which made me even more eager and excited to be in this field than I thought possible.

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

As my journey to becoming a full stack developer continues, I have begun to encounter the need for front-end testing. When finding an article, I realized that I did not have very much knowledge on what front-end testing entailed or how to implement it into my coding. I found the blog “Front End Testing: A Comprehensive Overview” by Kiruthika Devaraj (https://testsigma.com/blog/front-end-testing/) on my search for information on this topic.

The blog starts off by explaining that front-end testing is focused on the user’s experience. While past experiences have taught me that back-end testing specifically tests the functionality of the code, front-end, also known as the user-facing end of a website, testing has a higher focus on the user’s interactions. The author also delves into eight different types of front-end testing and the elements that make up these different types:

• Unit Testing is the analysis and testing of the individual components to ensure they each work as intended. 
• Acceptance Testing involves testing to ensure permissions, such as account accesses, are working properly. 
• Visual Regression Testing tests for visual changes in the front-end by comparing a reference picture to a baseline image. This can typically create brittle tests that can fail due to the slightest changes in an element’s location on a page.
• Performance Testing measures an applications stability and responsiveness under different levels of simulated stress and traffic.
• Accessibility Testing ensures that individuals with visual impairments or other additional needs can still use and access the application to the fullest of their capabilities.
• End-to-End (E2E) Testing involves testing the application from start to finish while testing all components and systems for how they work together.
• Integration Testing is when each individual module is tested to ensure it has been implemented correctly.
• Cross-Browser Testing tests that the application works correctly across multiple browsers and confirms compatibility.

Devarj also provides tips for better front-end testing, the first tip is to always use a testing framework. These frameworks, also called front-end tools, are what actually run the tests. Although countless front-end tools exist, the blog provides information to 3 popular options; Testsigma, Selenium, and Ranorex. Testsigma and Selenium are both open-source front-end testing frameworks that may be worth investigating further, while Ranorexis a commercial framework that may be more than what I am currently looking for. 

Front-End Testing Moving Forward

As I move to implement automated front-end testing into my projects, it is important to remember that the front-end testing is focused on ensuring the project is user-friendly, responsive, and visually appealing by testing the layout, design, and functionality across multiple browsers. Doing so will provide users with the best possible experience.

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

The ‘sustainable motivations’ pattern is all about development in the real world and how it can be very challenging as an apprentice to get used to the reality of software development. Development of your own technical skills is very important as you gain more experience working with customers and with a different variety of products. As it is described you may have a different reason which motivates you to continue in your programming job whether it be that you are motivated for the money, motivated to build reputation or motivated by your own enjoyment of programming. THis pattern is a part of the “long road” chapter which is characterized as being a part of the “long road” from apprentice to journeyman to master within the software development field.

The solution to this proposed problem is to not get “trapped by your motivations” and a way to do that is to write down things you are motivated by and be able to separate the things that motivate you from the things that are what others see or think. Motivation is something that is important in any career but software development requires a lot of motivation as times when developing is strenuous or when you have a long project ahead of you.

I find this pattern to be important as I feel that a lot of people struggle to maintain motivation in all careers worldwide, not just software development. So having a strategy to combat low levels of motivation and also try not to burn yourself out by being too motivated is very important. Many situations will present you with long projects where you need to be able to ‘sustain motivation’ this is especially important to software development as many times you will be faced with longer projects which will need your full attention throughout. Reading about this pattern makes me realize that it is ok to not always be fully motivated whether that is because of the length of a project or if it is due to your working environment, you shouldn’t expect to always be fully motivated but you need to be willing to persevere even when a project takes a lot out of you as it will further you within your craft.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.