Category Archives: Coding

Discovering Design patterns

Hello Debug Ducker here again and have you ever thought about how your code is structured? I mean you probably have been doing simple code etiquette, but have you ever thought about how you could make it less say more manageable and neater to save yourself the trouble

Here is an example of a code design on UML from a programming assignment

The basic gist of this is that we are making ducks and applying qualities to them. As you can see there are different types of duck especially my favorite the rubber duck. But I am sure you can see a problem with this. Despite them being all ducks, not all the attributes of a duck can apply to certain ones as shown with decoy duck and rubber duck. Their quack and fly methods would be different, So we have to override them to do something else. This can get tedious especially if we were to add more ducks. Also makes the abstract class feel pointless because of this. So this is where Design Patterns are implemented

Instead of overriding the fly and quack methods in the different types of ducks, we add functions that can apply the behaviors themselves without needing to modify methods within ducks. The Relevant design pattern here is known as Strategy Pattern, and that’s when we get into the real meat of things. 

Design Patterns as the name suggests are designs that programmers can utilize to fix certain problems in their code, whether it’s readability, managing the code, or streamlining a process. Strategy Pattern is the design pattern that splits the specifics of a class into other methods, such as the example of the fly and quack behaviors which were originally a part of several other ducks with different qualities. This helps us whenever we want to add a duck with a different behavior, one of the behavior methods could be applied. There are several other design patterns out there such as factory design which creates objects through what called a factory method, for example, if the rubber duck method is made then an object with rubber duck qualities will be made

Here is code of an example of what a factory method would look like

There are a lot more patterns to choose from that can help you with all your coding problems. Geeksforgeeks has a great article explaining them and even more of the patterns to show

https://www.geeksforgeeks.org/software-design-patterns/

Design patterns can be useful for many coding problems, whether It’s to restructure your code to make working on it easier or refactor it to make the functionality better. I can see myself using theses whenever I would encounter a problem.

“Software Design Patterns Tutorial.” GeeksforGeeks, GeeksforGeeks, 15 Oct. 2024, http://www.geeksforgeeks.org/software-design-patterns/.

Guru, Refactoring. “Strategy.” Refactoring.Guru, refactoring.guru/design-patterns/strategy.

From the blog CS@Worcester – Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

Anti-Patterns

Source: https://www.freecodecamp.org/news/antipatterns-to-avoid-in-code/

This article is titled “Anti-patterns You Should Avoid in Your Code.” It specifically mentions six of them, being: Spaghetti Code, Golden Hammer, Boat Anchor, Dead Code, Proliferation of Code, and the God Object. An anti-pattern, in regards to software development, is an example of how not to solve a problem in a codebase. They are not a positive thing, they are examples of practices to avoid in the development process. Anti-patterns lead to technical debt, code that you have to eventually come back to and properly fix later. Spaghetti Code is the most common, it is code that doesn’t have much structure. It is called Spaghetti Code because everything is difficult to follow, files are located in random places, and when visualized in a diagram, it appears to be a jumbled mess, much like spaghetti. Golden Hammer references a scenario where you follow a certain process that doesn’t necessarily align perfectly with the project but still works well enough. This may not seem like a large issue, but is obviously not the best practice to follow because it’ll cause performance issues in the long run. You should always use a process that is the best fit for your project, even if you need to teach yourself or learn something new. Boat Anchor is when developers leave code in the codebase that isn’t actively being used in the hopes of it being needed later and thus not requiring much effort to implement when it is eventually needed. The main problem with this is when it comes to maintaining the code. It leads to the question of what code in the codebase is unused and what is being actively used. Trying to fix a bug in the system on code that isn’t even being used is a time waster. Dead code is code that doesn’t look like it’s really doing anything, but it is being called from many different places. This leads to problems when trying to modify the code because no one is unsure what is actually dead. Proliferation of Code is about objects that have the purpose of invoking a more important object, meaning it doesn’t really do anything on its own. The action of invoking the more important object should be set to the calling object. Lastly, the God Object is an example of an object that does too much. Objects should only be responsible for doing one thing, referencing the Single Responsibility principle in SOLID. 

I chose this particular source because I appreciated the way examples were clearly given along with the 6 examples of anti-patterns, and upon reviewing the syllabus the topic “anti-patterns” seemed interesting. When you’re learning computer science a lot of the time you’re learning about things that you should do and not about things that you shouldn’t do. I really enjoyed reading about these 6 examples of common mistakes that developers make in industry. It’s important to both recognize good and bad practices to ensure that your projects are properly optimized. I can definitely see myself referencing anti-patterns when designing code in the future so my code can easily be maintained. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Week 18A – Python Testing

For this week, I wanted to look at how different languages handle test cases, and I’ll begin with the one I’m the most familiar with, Python! I’ve worked with Python in small amounts in the past, and have an understanding a lot of it’s syntaxes are similar to java’s, albeit simpler. I feel like this is a good topic to discuss as knowing how other programming languages handle unit testing would be a great way to expand my knowledge when it comes to furthering my understanding of it within Java.

For this, I’ll be looking at the official page for unittest on Python’s website, here:

https://docs.python.org/3/library/unittest.html

Right off the bat, I’m really interested in the fact that unittest is actually based directly off of JUnit! Which means a lot of the syntax, formatting, and framework is quite similar, just modified to fit the mold of Python.

Looking at the snippet they gave as an example…

import unittest

class TestStringMethods(unittest.TestCase):

    def test_upper(self):
        self.assertEqual('foo'.upper(), 'FOO')

    def test_isupper(self):
        self.assertTrue('FOO'.isupper())
        self.assertFalse('Foo'.isupper())

    def test_split(self):
        s = 'hello world'
        self.assertEqual(s.split(), ['hello', 'world'])
        # check that s.split fails when the separator is not a string
        with self.assertRaises(TypeError):
            s.split(2)

if __name__ == '__main__':
    unittest.main()

In this, it seems the way you define test blocks is by having a class with (unittest.testcase) and then doing “def” to define each test case.

Even the assertions are the same and written near identically, as the first three use assertEqual, which is identical to javas assertEquals, minus the s, and assertTrue and assertFalse, which are also identical to their java counterparts. assertRaises, which is used in the third test, seems to be Python’s equivalent to assertThrows, however, it seems to be a bit different in comparison. assertRaises seems to identify a specific kind of exception being raised, whereas assertThrows would just identify any exception in general.

The last line also is a block of code that allows an easy way to run all the tests, so when you run unittest.main() in a command line, it will automatically run all the tests and display the results.

There also seems to be a whole bunch of different command line options to display results and modify the ways in which its run. As an example, theres “-v”, which stands for verbosity, much like the bash command, which shows the results of each individual test being run, like below:

test_isupper (__main__.TestStringMethods.test_isupper) ... ok
test_split (__main__.TestStringMethods.test_split) ... ok
test_upper (__main__.TestStringMethods.test_upper) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.001s

OK

It seems extremely interesting and makes me want to learn more Python, which would definitely help me in my career in all sorts of ways! Next blog we will be looking at how unit testing works in C. Until then!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Elevating Code Reviews: Practical Tips for better Collaboration

Code reviews are a vital part of the software development process, serving as a checkpoint to ensure quality, foster knowledge sharing, and mitigate future issues. Drawing on practical advice from a stack overflow blog article (found here) this post explores how to elevate the practice of code reviews, enhancing their effectiveness and the collaborative environment they create.

Summary

The article from stack Overflow provided insightful tips on improving code reviews, emphasizing the importance of constructive communication and efficient processes. It suggest setting clear goals for reviews, such as catching bugs, ensuring consistency, and mentoring junior developers. Techniques like keeping comments clear and actionable, prioritizing empathy and understanding, and maintaining a balance between criticism and praise are highlighted as crucial for productive reviews.

Reason for selection

I chose this article because effective code reviews are essential for any development team aiming to produce high-quality software. As our coursework often involves collaborative projects and peer reviews, applying these enhanced practices can significantly benefit our collective learning and project outcomes.

Adding to the reasons for selecting this article, another compelling aspect is its relevance to the ongoing discussions in our software development courses about maintaining high standards in coding practices. As someone who has been part of several projects and observed firsthand the impact of well-conducted code reviews, I recognize the value in learning and sharing effective review techniques. This article not only enhances our understanding of best practices but also equips us with the tools to implement them effectively in our work, making it an invaluable resource for any aspiring software developer eager to improve their craft and contribute positively to team projects.

Personal reflection

Reflecting on the article, I appreciated the emphasis on empathy and clarity in communication. In past group projects, I’ve seen how negative feedback can demotivate peers, whereas constructive and positive communication can enhance team dynamics and improve code quality. This article reinforced the idea that code reviews are not just about finding errors but also about building a supportive team culture.

Application in future practice

Armed with these enhanced practices, I plan to apply the article’s recommendations in upcoming projects, particularly those involving teamwork. Emphasizing clear, empathetic feedback and leveraging tools for automating mundane aspects of code review will allow me and my peers to focus on more complex issues, thus improving our efficiency and the quality of our work.

Conclusion

Effective code reviews are more than just a quality assurance step; they are a cornerstone of a collaborative and learning-focused development environment. The tips provided by the Stack Overflow article offer valuable guidance on making good code reviews even better, ensuring that they contribute positively to both project outcomes and team dynamics. As we continue to engage in more collaborative projects, these practices will be essential in shaping how we approach code reviews and interact as a development team.

resources

https://stackoverflow.blog/2019/09/30/how-to-make-good-code-reviews-better/

From the blog CS@Worcester – Josies Notes by josielrivas and used with permission of the author. All other rights reserved by the author.

Week 12

Considering that we have been working on the Mars rover for the past two weeks, I decided to find an article that correlated with this. I went straight to the source and found something about the actual Mars rover. I was able to find an article that piqued my interest. This article was specifically about the real rover and the people who worked on it. I chose this article to show the broad potential we all have inside the CS field that none of us even heard about. I hope to open your minds to all the possibilities you can do with code.

    The article begins by introducing the reader to Melody Ho a full-stack developer for the Nasa Mars website. She has a multitude of responsibilities she has to publish information about every mission and create data pipelines to be accessible to the public. Her journey began by working on a basic HTML book and playing computer games. She gives her reflection on her journey to inspire the next generation of women in space and technology. She most enjoys programming code that is efficient and adapting it to the best version of code possible. When she was growing up she was considering a career in computer games because she hadn’t yet seen the opportunities available for programming. She leaves the article by advising the next generation. She says to embrace new things and don’t be scared because these are opportunities that are needed to succeed. Technology is constantly changing don’t be discouraged if all doesn’t click it will take time.

   Reading this article gave me more of an introspective view of someone’s life in coding. This article doesn’t have much connection to the code we do in class but I think it’s very interesting to see the whole perspective of a coding journey. This article touches upon aspects that you may not think about every day but it gives much attention to what is important. Melody trying to inspire the next generation is very touching. She didn’t have to do this but she did. For me, it gave me a broader view of programming because sometimes you may have a tunnel vision of what you can do with your code but the possibilities are endless. There are a lot of connections that you may not see on an everyday basis. She mentioned how she double majored in business and I didn’t even see the correlation of coding in a management setting but it’s there. There are a lot of connections in programming with other skills there are some I haven’t thought about.

https://airandspace.si.edu/stories/editorial/coding-brings-mars-data-down-earth

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

Week 11

Deciding on a topic this week I decided to delve into Test Driven Development (TDD). I found an article with an engaging title “Test-Driven Development (TDD): A Time-Tested Recipe for Quality Software” by Ferdinando Santacroce. This would be very useful for me and the whole class because it’s fresh in our minds and we will continue to work with this concept. Getting a firmer grasp on this topic will help me with future assignments and homework. It’s always great to get an insider view with experience inside the field connecting it to what we learn in class.

This article begins with the history of TDD giving credit to Kent Beck one of the first “extreme programmers”. At the time nobody had ever reversed the idea of testing starting with a test instead of the actual code. The purpose of writing a test before the code would help programmers put them in the perspective of the maker making it easier to create the software. This would make more tunnel-focused code with much more simplicity because of just focusing on the test. Plus the codes get rapid feedback because all the tests have been made. TDD has the fastest feedback loop only surpassed by pair programing. Currently, TDD is widespread inside the field and several teams utilize it day to day. It’s hard to adapt to this type of coding scheme but with time it is proven to be a key to success. Minor grievances may also come up because this type of process can be too rigid or the lack of tools.  

After reading this article getting a glimpse into the history of how this came to be. It didn’t specifically specify when it started but I assume it was around the 90s because it mentions how common it is now. Understanding the benefits of doing this test answers my question why would you decide to do your coding process in reverse? What we have been learning is that it will be conventional to have code and then write the test connected to the already processed code. The benefits of cutting down time because of the faster feedback times and leading to less complicated code, I now understand its purpose. That is a recurring theme with code the simpler the better because you are never working alone. Maybe it is a self-contained project but your future self may not understand your complex code and updates to the code should be easy to do not a headache. 

https://semaphoreci.com/blog/test-driven-development

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Week 8 blog Post

For this week I found an article about writing code considering we have been writing classes for the past few classes. The article I found stuck out to me because of its title “Writing Code an Art Form”. People always use the analogy of code being like learning a new language but I never heard anyone consider it as art. From the countless articles I could have chosen without this title, I may have never chosen it to begin with.

This article first starts with a background of how the idea of this article came to be. The setup was that the author was working as a junior developer who had to get a recently hired senior developer with 10 years of experience acquainted with their program. I can only imagine how that interaction was set up and whoever was leading the group should have probably reconsidered who should help the new employee. Even though the senior developer had far advanced experience his code was not easily readable. The author was even taken aback because the senior developer commented how the author likes to write pretty code. The author goes into detail on how poor documentation must be taken into account because other flaws can arise from bad naming conventions for variables/functions, spacing, and having the mindset to problem-solve. Keep the code easy to maintain, read, and debug don’t write spaghetti code.

Now reading this article gave me insight into the inner workings of the tech field. I would have never assumed that a new employee would be getting trained by the second recently hired. I would have assumed that someone with more experience with the project would have filled in the new person but maybe it could be that there both coming from similar places. Both of them are the newest employees and could be easier to help another person adapt to the environment. Reading this article has also reinforced ideas that keep your code simple and clean. My main takeaway was whenever you write code don’t just write it for yourself to understand but for everyone. Let’s say you are working on a project on your own you might just get enclosed in how you understand code nobody but you will be able to update it. Even if you don’t care that someone else will update it in the future your code can be so unreadable that future you may have no idea what you created. In a way, code is like writing notes and there is an art to writing good notes.  

https://hinchman-amanda.mehttps://hinchman-amanda.medium.com/writing-code-an-art-form-e41e459bd2f6dium.com/writing-code-an-art-form-e41e459bd2f6

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

Week 14 – Token #1 – CS343

For this blog I’ll be using one of my tokens for this class so I can hit the 6 blog minimum before the semester is over.

In this blog post, I wanted to look more into JavaScript since I didn’t really know too much about it. I struggled with the backend homework we had because I never knew anything about the syntax or language at all. So, I want to learn a bit more about this language within this blog. For this, I consulted this website, and gave it a good hearty read:

https://developer.mozilla.org/en-US/docs/Web/JavaScript

This site gives an overview of JavaScript and the applications in which it is used in general, and what benefits and downsides it has compared to other languages.

What I found very interesting is that I originally knew that JavaScript was mainly used for website development and coding, but this site gave some examples of applications such as Node.js and Adobe Acrobat. I believe we’ve actually utilized Node.js before in our classes, but I can’t quite put my finger on what exactly we used it for, but I recgonize the name appearing in one or more of the repositories we’ve been working with.

It seems like JavaScript is much like Java in the sense that it can use object oriented code, but I think the similarities between the two end there. In the past, I always heard that JavaScript was a completely different beast from Java, and after look more into it, I see why. This site below describes the differences:

https://www.lighthouselabs.ca/en/blog/java-vs-javascript

JavaScript it object-orientedcode, whereas Java is object-based. That may sound the same as each other, but there is some very specific distinctions between them. Java relies on objects to function, whereas JavaScript has functionality for objects and suggests use of them with it’s language, it is not required. JavaScript is also a lot more fluid with it’s syntax, and has a lot more free-form and flexibility with it, which reminds me a lot of what I’ve heard about Python. Java is a lot more rigid, and requires specific pre-set uses of it’s syntax.

But back to JavaScript, it seems like its The language for web design, as a lot of it’s language is made with web design in mind. My future for this area of study is some form of design in technilogical areas, so it would be possible I go into Web Design. If I do, I’ll definitely have to teach myself more JavaScript. It seems like a really useful language to have on hand in that case.

I will be posting one other blog today, using another token, so stay tuned for another!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

Summary

In this sprint, I mainly did the following things:

What Worked Well

In this sprint, I had a lot of clear feedback from the prior sprint. This allowed me to very quickly knock out a lot of work in the first few days. It was very simple to go through and make all of the required changes.

What Didn’t Work Well

In hindsight, I should’ve made those “backend modification changes” one card. Instead I had four separate cards and four separate merge requests. It would’ve been cleaner and faster to have one card for it all.

Similarly, having finished those tasks so quickly left me at a loss of what to do for a while. I ended up helping some team mates out with a few things, but eventually I settled on working on the docker aspects of the system. I then ended up spending a lot of that time helping myself understand how it worked and wasn’t able to make as much progress as I otherwise would’ve liked.

I also think that simply due to the nature of the end of a semester, we didn’t really have the time to work outside of class on this. I personally had two projects I needed to create as well as a lot of studying to do. It was also hard to resist planning out my summer in my free time since I needed to buy thing and make plans for my summer of biking, tennis, and grass mowing.

What Changes Could be Made to Improve as a Team

Once again, we overall worked pretty well together. I’d say initially our team didn’t really do too much together. Everyone was working on their individual components and so we didn’t communicate as much as we might’ve been able to. That said, later in the sprint when we actually did need help on things, we all were able to come together and figure things out.

Supposing we were ever to work together as a team, I think we could improve by being more vocal and more unified. I think most of our problems though came from this being a course as well as us being mentally done with the semester. If this were a continuous job, things may have been naturally better.

What Changes Could be Made to Improve as an Individual

In this sprint, I didn’t do as much work I could’ve done. I could’ve asked if my teammates needed help on things and worked on the frontend, for example. I could’ve had a better attention span and self control near the end of semester.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Share What You Learn

The problem of this pattern is one of the final ones, as far as I can tell. It is framed around your near-completion as a developer. I mean this in the sense that you’re a rounded-out developer with a lot of useful skills, but not necessarily a significant amount of real-world experience. In order to truly become a journeyman, you need effective communication skills. It isn’t enough to be a good programmer.

In order to gain such skills, the proposed way is to share that which you have learned. One such way is via a blog such as the one you’re currently reading. I pretty much completely agree with this pattern. I think the best way to learn things is to explain them to someone else. Really, the reason that we are tasked to write large essays in high school and college, despite them being annoying, is because writing is thinking. If you are capable of reading these words, then you’re most likely literate. Modern people take literacy for granted. For millions of years, the vast majority of humans were illiterate and as such their brains developed in a different manner to ours.

According to a discussion with Psychologist Jordan Peterson (that I unfortunately cannot find to link here), illiterate people think differently than literate people. Illiterate people think more in images and experiences, similar to how animals think. (Don’t let your arrogance get the better of you; all humans are animals biologically.) Words themselves are abstractions and your brain has to handle abstractions differently. It has to convert from symbols and sounds to the word to the meaning of the word. I would say that tribes of people that rely heavily on the oral are similarly affected. Nonetheless, literacy has a profound effect on your brain and thus how you learn. Writing is a form of thinking. Literate people have the ability to write or type words without really planning it in their minds, similar to how people can speak without thinking. The words are the thinking. So, when you explain something, you need to find the words to describe it and that process is thinking.

That’s why written words can be so messy; we think through them as we write. Thoughts are messy. So, it is essential to be an effective communicator not only to benefit others. Ignoring the existence of other people, being an effective communicator means you are an effective thinker. This is specifically in terms of words, which I would argue programming requires. The concepts dealt with in programming require intense mental abstractions that most of us take for granted. There’s a reason the general population thinks coding is magic. It’s simply too abstract to fully grasp from a single viewing. This means words are the way we handle that abstraction. Thus, make yourself powerful with words in order to become powerful in your actions as a programmer.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.