During our Software Construction, Design and Architecture class, we’ve gone over a multitude of different design techniques, patterns and tools to ensure that we write quality code. We’ve also touched on some design / code smells and the concept of technical debt. While design smells can give you an indication of something that might be wrong with your code, whether in a small section or in the overall design, anti-patterns represent a much more obvious, prevalent problem in your code.

Some of the most common examples of anti-patterns I’ve heard in conversations I’ve had with my friends, classmates and even teachers in a joking matter, like spaghetti code, and copying and pasting code snippets from random repos (which isn’t just bad practice for coding, it’d also be possible to infringe upon licenses or the lack thereof placed on that code). I think the reason why these are fairly common among the circles I’ve been in is just because everyone has done it before for a school assignment or something, and it’s just funny to joke about.

Some anti-patterns are a bit more involved with designing software in a meaningful sense, though. In a blog post from Lucidchart, some other anti-patterns found in software development and design are golden hammers, god objects, boat anchors and dead code. What’s interesting about these is that they actually are actual manifestations of design smells, in the most obvious ways.

For example, a boat anchor is a piece of code that isn’t being used yet but might be used in a future version, maybe. This results in needless complexity, an addition that isn’t necessary and makes it harder to read your code. Dead code is similar, code that gets executed but isn’t even used in the output of a program, causing immobility. Using a golden hammer means you are using the same tool for a bunch of different jobs, thinking that it is the best tool for all cases. This contributes to fragility, needless repetition and opacity depending on the implementation one goes about with a golden hammer. God objects are similar in a sense, as they’re objects that do too much and are responsible for too many functions. This violates encapsulation principles that are good practice in software design, while also resulting in immobility, viscosity and possibly even more. Dead code

This reinforces the idea of checking for code smells and refactoring code as needed, because otherwise you will build upon a foundation that was fundamentally problematic, and the rest of your code will reflect it no matter how much better it is. This all ties into technical debt, and brings all of the software design principles, concepts and ideas together into a picture that says: please maintain your code cleanly!

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

Best practices for REST API design: https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

In today’s digital landscape, REST APIs play a pivotal role in facilitating seamless communication between various clients and services. However, designing these APIs requires careful consideration of factors such as security, performance, and ease of use for consumers. In this blog post, we will delve into the key best practices for designing REST APIs that are not only easy to understand but also future-proof and secure.

Summary: The selected resource outlines essential guidelines for designing REST APIs. It covers crucial aspects like choosing the right data format (JSON), using nouns instead of verbs in endpoint paths, logical nesting for hierarchical objects, handling errors gracefully with standard error codes, and implementing features such as filtering, sorting, and pagination. The article also emphasizes the importance of maintaining good security practices, caching data for improved performance, and versioning APIs to manage changes effectively.

Reason for Selection: This resource was chosen because it directly aligns with the course material, providing a comprehensive guide to REST API design principles. The clarity of the content and its relevance to common challenges in API development makes it a valuable reference for anyone involved in creating robust APIs.

Comments on Content: The guidelines presented in the resource offer practical insights into building effective REST APIs. The emphasis on using JSON for data exchange aligns with industry standards, ensuring compatibility across various technologies. The recommendation to avoid verbs in endpoint paths simplifies API readability and adheres to the RESTful principles of using HTTP methods for actions. The article’s discussion on error handling and status codes enhances the overall robustness of API implementations.

Personal Reflection: As a developer, this resource reinforced the importance of consistency and adherence to best practices in API design. The concept of logical nesting for related resources provides a structured approach that can enhance both API usability and maintainability. Learning about caching strategies and the significance of versioning in API development has broadened my understanding of how to address performance and compatibility concerns in real-world scenarios.

Application in Future Practice: The insights gained from this resource will significantly influence my future API development projects. I plan to implement the recommended practices, especially in areas like error handling, security, and versioning. Additionally, the emphasis on caching strategies will be integrated to optimize data retrieval and enhance the overall performance of the APIs I develop.

In conclusion, the resource serves as a valuable guide for both beginners and experienced developers, offering practical tips for designing REST APIs that stand the test of time. By incorporating these best practices, developers can create APIs that not only meet current requirements but also adapt seamlessly to future changes in technology and user needs.

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

Software Frameworks

What is a framework?

A framework is a platform providing a foundation for creating software development projects. Frameworks can be thought of as a template of a working program where developers can modify the program by adding code. Because frameworks are essentially templates, there are shared resources that are bundled into one package. Some of these resources include libraries, image files, and reference documents. The package can be customized to match the needs of the project.

Different types of frameworks

Backend Web Frameworks

Backend Web, or also known as simply Web Frameworks, are the most commonly used. These frameworks help developers create web applications and dynamic websites. The use of web frameworks has streamlined the process of web development by automating common tasks of web developers such as database access and session management. Rather than using HTML, JavaScript and CSS, backend frameworks use programming languages to access a database, hosted on a server. A common backend framework is Django.

Frontend

Unlike backend where frameworks are loaded server-side, frontend frameworks are executed in the user’s browser. Frontend frameworks allow developers to customize and design the way the web application looks to the user. Popular frontend frameworks are Angular JS and React.

Mobile Development

Nowadays mobile applications are extremely common resulting in mobile development frameworks. Similarly to desktop frameworks, these give developers a foundation to build their mobile applications while allowing full customizability. There are two types of mobile frameworks, native and cross-platform. Native frameworks are for applications that are built specifically for a particular operating system (iOS or Android). Alternatively cross-platform frameworks are for apps that are built to be compatible with any phone. A commonly used mobile framework is Flutter.

What makes a good framework?

A good framework should be simple to understand and easy to implement. It should also follow design principles such as:

• Being extendable, adding new functionality by adding code rather than modifying
  • Framework cannot be modified at all, but only extended
• Allows developers to create components that can be reused
• Should have a default behavior and be useful. No redundant code that is unnecessary

Why use a framework?

Frameworks greatly reduces the time spent on developing. When starting a new project, there are steps that need to be done regardless the project. Using frameworks helps streamline that process by already providing those details. This allows developers to focus their time on extending the functionality specific to their application’s needs.

Reflection

This article was chosen because it broke down the different parts of a framework such as what it is, the different types, and why one might use a framework. Prior to reading this blog, I had a somewhat unclear understanding of what frameworks are. Now I understand that they are useful tools that speeds up the development process by providing essentially a template of a working program. What was learned will be applied to future, larger projects that could benefit from a framework.

Resources:

https://codeinstitute.net/global/blog/what-is-a-framework/

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

There is currently nothing that reigns truer than the “Learn How You Fail” pattern in the Apprenticeship Patterns. Essentially this chapter identifies the role in which failure plays in your career development. I have often heard that failure is not something to be feared but instead embraced and this chapter mirrors that same sentiment. It offers the idea that if someone has not failed then they have actually “avoided pushing the boundaries of their abilities”.

I think this idea heavily resonates with me. I’ve learned that I need to look upon what I am doing with a realistic lens and to be able to recognize the truth in my actions and decisions. The more objectively I can view things the greater the ceiling for growth and further expand the boundaries of my abilities. The chapter puts it as “the goal is to gain self-knowledge about the patterns, conditions, habits, and behaviors that lead you to failure”.

I think that one of the major things that is hampering my success is procrastination.

For a long time, I have been “wallowing in self-pity” from the consequences of my procrastination. There has been a bit of a perspective change as of late that allows me to recognize my strengths through an accurate self-assessment all in an effort to remove the focus on the self-pity and shift it to self-improvement.

I find that from my procrastination I’ve learned how to handle my own self sabotaging self. I have seen that it is something I can improve on as I find myself having instances of being proactive, so I know that it is something that I am capable of overcoming. With consistent effort I can see myself overcoming this barrier to achieve whatever it is I want to achieve. From all my criticization of the education system it wouldn’t be without this system that has allowed me to recognize my strengths and abilities and has enabled me to look upon my weaknesses not as an impossible barrier but as something that I can overcome and climb. On the other hand, even though I can recognize this pattern within myself I learned that nothing is going to be accomplished without a disproportionate amount of time, so that is why it’s going to take consistent effort and not all be accomplished within a day. This kind of self-assessment seems very valuable and is something I actively believe I can improve on and may even somehow adopt as a core value.

From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

With the breakable toys pattern, the learner conducts experiments and observes the work of others to improve their own understanding of how to build complex systems. Apprenticeship Patterns suggests a few ways to go about this. You might build a simplification of an existing problem that you’re already facing. By reducing uncontrollable variables or emulating a single possible case, you can come to understand one key interaction, tool, or data flow at a time until you become capable of composing a solution to a broader problem.

Another possibility is building your own projects that are not focused on understanding one specific issue you are already facing. Doing so can build a familiarity with your tools, and can lead to unexpected creativity or interest in learning how others achieved problems you might never have otherwise encountered.

The third variant of this pattern is the analysis of external source code. The abundance of open-source projects provides an effectively infinite learning resource for studying how others design systems and resolve issues.

I think that this pattern is a very important part of long-term learning. It can be easy to build habits when programming: you can usually come to a desirable result either by brute-force trial and error from the bottom up, or by drawn-out requirements planning that gets done before any prototype is built. But I’ve found myself spending far more time invested in one of these two methods than I should have, when remaining flexible and incorporating aspects of the other would have led me to a better solution faster.

In general, I think it’s a shame how often the daily work of software development can feel detached from the playful curiosity of the scientific method. Much of the most rewarding learning happens as a result of developing a question and finding a finding out how you can reach a confident answer to it. Considering we’re working in the one field where rapid iteration and near-zero cost to entry makes the scientific method universally accessible, I’d like to hope I’d take advantage of that by putting myself in many situations that generate spontaneous curiosity.

That’s what I like about making a breakable toy. It’s usually more fun to play with than the projects that we have real responsibility for, and that fun makes us want to understand everything about the toy and how the toy could grow into something else.

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.

Greetings! I recently stumbled upon an intriguing concept called “Expose Your Ignorance,” which originates from the book “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This pattern advocates for individuals to openly acknowledge and address their knowledge gaps by seeking assistance from mentors, peers, or experts. Personally, I found this pattern to be quite relevant and valuable, as I frequently encounter scenarios where I need to acquire new knowledge. I appreciated how this pattern emphasized the importance of seeking feedback and assistance to cultivate both personal and professional development.

What I found intriguing about this pattern is its emphasis on recognizing the strength in admitting ignorance or not knowing something. In the past, I have been guilty of feigning knowledge to avoid appearing foolish or incompetent. However, this pattern advocates for the opposite approach, highlighting the benefits of being forthright about one’s limitations. By doing so, individuals can receive constructive feedback and foster personal growth. Furthermore, this pattern places significant importance on seeking guidance from others, which can be a daunting task, particularly for those who are just starting out. Nevertheless, reaching out for help is a crucial step towards expediting the learning process and avoiding potential mistakes. The pattern emphasizes that seeking assistance should not be viewed as a weakness, but rather as a strength. By doing so, individuals demonstrate their eagerness to learn and advance. I believe that the Expose Your Ignorance pattern offers significant advantages for personal and professional development. It encourages individuals to be transparent about their knowledge gaps and seek assistance, leading to more rapid growth and learning. This pattern has significantly impacted my outlook on my profession, as it has taught me to embrace my limitations and seek help when necessary. I believe that anyone looking to enhance their skills would benefit from adopting this pattern.

In summary, I strongly suggest reading the book “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” and implementing the Expose Your Ignorance pattern. This approach can help expedite your progress and advancement, whether you’re a software developer or working in any other field. By acknowledging your limitations and seeking help, you can foster personal and professional growth.

From the blog CS@Worcester – Mausam Mishra's Blog by mousammishra21 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 2 of the book Apprenticeship Patterns by Dave Hoover named “Emptying The Cup” and took interest in the apprenticeship pattern called “The Deep End.” This pattern is about pushing yourself out of your comfort zone and taking on challenging tasks that are outside of your current skill set. The best way to learn is by doing, and that taking on tasks that are beyond your current abilities can help you grow and develop new skills. The pattern advises that when you are in the “deep end,” it’s important to ask questions and seek help from more experienced colleagues. It’s also important to break down your tasks into smaller, more manageable pieces and to focus on making small incremental progress over time. The benefits of taking on tasks in the “deep end” include accelerated learning, increased confidence, and the opportunity to demonstrate your abilities and potential to your colleagues and mentors.

As a computer science apprentice, it can be scary to go into the “deep end” since you may think you would be a totally lost person working with experienced people. But I have experienced the deep end myself many times in my everyday hobby, video games. This seems to happen the most especially in competitive video games, when you play with people who are more skilled than you, you start to pick up on the many small helpful habits highly skilled players tend to do. The skilled players don’t need to think about the small habits because they have already mastered them and do them out of muscle memory. The same can be said for computer science apprentices. For a scenario, think about working on a difficult project with more experienced people in the field. You may look like a small fry with not that much experience compared to the others, but this is actually a fantastic opportunity to observe your team members and pay attention to small things and habits like their thought process for example. As you focus on the small habits, you also start to copy those habits and incorporate them into your work as well. This would also be a great opportunity to ask questions if you are confused about anything. I will for sure start diving into the deep end if I find any opportunities to since it will strengthen my skills as a computer science major.

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 2 of the book Apprenticeship Patterns by Dave Hoover named “Emptying The Cup” and took interest in the apprenticeship pattern called “The Deep End.” This pattern is about pushing yourself out of your comfort zone and taking on challenging tasks that are outside of your current skill set. The best way to learn is by doing, and that taking on tasks that are beyond your current abilities can help you grow and develop new skills. The pattern advises that when you are in the “deep end,” it’s important to ask questions and seek help from more experienced colleagues. It’s also important to break down your tasks into smaller, more manageable pieces and to focus on making small incremental progress over time. The benefits of taking on tasks in the “deep end” include accelerated learning, increased confidence, and the opportunity to demonstrate your abilities and potential to your colleagues and mentors.

As a computer science apprentice, it can be scary to go into the “deep end” since you may think you would be a totally lost person working with experienced people. But I have experienced the deep end myself many times in my everyday hobby, video games. This seems to happen the most especially in competitive video games, when you play with people who are more skilled than you, you start to pick up on the many small helpful habits highly skilled players tend to do. The skilled players don’t need to think about the small habits because they have already mastered them and do them out of muscle memory. The same can be said for computer science apprentices. For a scenario, think about working on a difficult project with more experienced people in the field. You may look like a small fry with not that much experience compared to the others, but this is actually a fantastic opportunity to observe your team members and pay attention to small things and habits like their thought process for example. As you focus on the small habits, you also start to copy those habits and incorporate them into your work as well. This would also be a great opportunity to ask questions if you are confused about anything. I will for sure start diving into the deep end if I find any opportunities to since it will strengthen my skills as a computer science major.

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 2 of the book Apprenticeship Patterns by Dave Hoover named “Emptying The Cup” and took interest in the apprenticeship pattern called “The Deep End.” This pattern is about pushing yourself out of your comfort zone and taking on challenging tasks that are outside of your current skill set. The best way to learn is by doing, and that taking on tasks that are beyond your current abilities can help you grow and develop new skills. The pattern advises that when you are in the “deep end,” it’s important to ask questions and seek help from more experienced colleagues. It’s also important to break down your tasks into smaller, more manageable pieces and to focus on making small incremental progress over time. The benefits of taking on tasks in the “deep end” include accelerated learning, increased confidence, and the opportunity to demonstrate your abilities and potential to your colleagues and mentors.

As a computer science apprentice, it can be scary to go into the “deep end” since you may think you would be a totally lost person working with experienced people. But I have experienced the deep end myself many times in my everyday hobby, video games. This seems to happen the most especially in competitive video games, when you play with people who are more skilled than you, you start to pick up on the many small helpful habits highly skilled players tend to do. The skilled players don’t need to think about the small habits because they have already mastered them and do them out of muscle memory. The same can be said for computer science apprentices. For a scenario, think about working on a difficult project with more experienced people in the field. You may look like a small fry with not that much experience compared to the others, but this is actually a fantastic opportunity to observe your team members and pay attention to small things and habits like their thought process for example. As you focus on the small habits, you also start to copy those habits and incorporate them into your work as well. This would also be a great opportunity to ask questions if you are confused about anything. I will for sure start diving into the deep end if I find any opportunities to since it will strengthen my skills as a computer science major.

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 2 of the book Apprenticeship Patterns by Dave Hoover named “Emptying The Cup” and took interest in the apprenticeship pattern called “The Deep End.” This pattern is about pushing yourself out of your comfort zone and taking on challenging tasks that are outside of your current skill set. The best way to learn is by doing, and that taking on tasks that are beyond your current abilities can help you grow and develop new skills. The pattern advises that when you are in the “deep end,” it’s important to ask questions and seek help from more experienced colleagues. It’s also important to break down your tasks into smaller, more manageable pieces and to focus on making small incremental progress over time. The benefits of taking on tasks in the “deep end” include accelerated learning, increased confidence, and the opportunity to demonstrate your abilities and potential to your colleagues and mentors.

As a computer science apprentice, it can be scary to go into the “deep end” since you may think you would be a totally lost person working with experienced people. But I have experienced the deep end myself many times in my everyday hobby, video games. This seems to happen the most especially in competitive video games, when you play with people who are more skilled than you, you start to pick up on the many small helpful habits highly skilled players tend to do. The skilled players don’t need to think about the small habits because they have already mastered them and do them out of muscle memory. The same can be said for computer science apprentices. For a scenario, think about working on a difficult project with more experienced people in the field. You may look like a small fry with not that much experience compared to the others, but this is actually a fantastic opportunity to observe your team members and pay attention to small things and habits like their thought process for example. As you focus on the small habits, you also start to copy those habits and incorporate them into your work as well. This would also be a great opportunity to ask questions if you are confused about anything. I will for sure start diving into the deep end if I find any opportunities to since it will strengthen my skills as a computer science major.

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