Category Archives: Week 4

learning concurrency

I’ve heard these terms a lot, concurrency and multithreading, but I never really bothered looking into what they actually do. All I’ve really known about these terms was that they make things run faster. I mostly associated multithreading with hyperthreading, I’ve known that CPUs can use multiple cores for the same application to speed up runtime and make games perform better, but I was always sort of confused about how some games have issues with actually taking advantage of modern high-end CPUs. Usually, this is fixed by some sort of modification, if it’s been written already. That being said, my association between the two is only really surface level.

Hyperthreading is really just related to the physical hardware, which makes it different from multithreading in programming. Instead, multithreading is a form of concurrency in which a program has multiple threads that can run simultaneously, with each thread having its own operations and processes that it executes. What this ultimately means is that within a program, multiple operations can be executed at the same time.

This really fascinates me coming from the perspective of only writing straightforward code. While I sort of knew intuitively that programs can probably do multiple tasks at the same time, I’ve only experienced this on the end-user side of things, rather than the individual writing the program. After looking into how threads work in Java on a BairesDev post regarding Java concurrency, I can really see how powerful of a tool concurrency can be for runtime efficiency. This post essentially goes over what concurrency is and the ‘basics’ of utilizing built-in multithreading functions in Java, along with the advantages and disadvantages that this design comes with.

Of course, it does seem like it takes a careful approach to make sure that the implementation of such a tool is actually beneficial to the project. Even with this relatively simple tutorial, I did find myself a little confused at some points, particularly at the point where Locks are introduced. Though this could be the effect of the hour at which I decided to start writing this blog post, it still stands to reason that the complexity of writing a multithreaded program may result in a more difficult development process, especially in debugging.

Regardless, I was truly fascinated by the subject matter and I’m really excited to be going over concurrency in our course (CS-343). This seems like a tool I would really like to use as I enjoy toying with logistics in video games and the like.

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.

Code Documentation

For this week’s blog post, I chose the article “Code Documentation: How to Do It Right” by the editorial team of SkillReactor. I chose this article in particular because it aligns well with the code documentation section of the syllabus. This article goes into great depth about code documentation and its benefits, as well as how it is best implemented. In this blog post, I will specifically be going over the code documentation tools discussed in the article and how the article discusses overcoming documentation challenges. Prior to reading this article, I wasn’t very familiar with code documentation tools, but I learned much about their function and how some of the tools mentioned can be used with multiple programming languages.

The article mentions a few specific code documentation tools that are commonly used in software development. One of the tools mentioned that caught my attention is Doxygen. “Doxygen is a versatile tool that supports multiple programming languages and generates documentation in HTML, LaTeX, and RTF formats.” Doxygen is very interesting because of its benefit of functioning alongside multiple programming languages and creating documentation in HTML, which, in my experience, can be very difficult to navigate without some form of documentation guiding you. I also found Sphinx to be fascinating because the article mentions that it makes use of automated API documentation generation. “Sphinx, primarily used for Python codebases, offers automated API documentation generation and support for reStructuredText markup language.” This tool having the capability to generate documentation for your code automatically can be immensely helpful; it being automatically generated can also help with accidentally using jargon or slang that may not be understood by others reading through your code. Another essential aspect that the article discusses is overcoming some challenges associated with creating code documentation.

Writing documentation into your code comes with great benefits, but often, it can be difficult to implement into your project. One of these challenges being maintaining up to date documentation with a project. “Although code documentation offers numerous advantages, it comes with its own set of challenges. Managing updates to documentation can be a daunting task, particularly in large projects where multiple developers are working simultaneously.” Another challenge that comes along with creating documentation is avoiding redundancy. “Another challenge is avoiding redundancy in documentation. When multiple code sections use the same functions or variables, it can be tempting to copy and paste documentation, resulting in redundant documentation and confusing code.” However, these challenges can be overcome with enough diligence. “To overcome these challenges, it is essential to establish specific standards for documentation management and to incorporate documentation review processes into the development workflow.” As long as these standards can be maintained and code documentation is regularly reviewed, the documentation implemented with your projects should be of high quality and make understanding your projects much easier for your fellow developers.

Article: https://www.skillreactor.io/blog/the-importance-of-code-documentation-and-how-to-do-it-right/

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.

Minimizing Anti-Patterns

The article I chose for this week’s blog post is “What Is an Anti-Pattern?” by Andreas Schöngruber. I chose this article because it discusses what anti-patterns are, gives some examples of anti-patterns, and how to avoid them. I chose this article for this week’s blog because it fits well with the syllabus topic of anti-patterns. I found the section about recognizing and avoiding anti-patterns to be very helpful. This blog post will focus on the aforementioned section about recognizing and avoiding anti-patterns in your code.

I will first discuss the section of the article which discusses recognizing anti-patterns in your code. One method that the article mentions involves keeping an open mind and looking to others for feedback. “When identifying anti-patterns in our code or design, we must keep an open mind and question our assumptions. Sometimes, we may become attached to a solution that required a lot of time and effort, but there might be a better solution out there. To avoid this, it is helpful to seek feedback from others.” As this quote states, it is imperative not to be too attached to a process that you developed or are developing, especially if the time it takes to develop or implement this feature is more than the value that the feature is worth. Another important part of being able to mitigate the harm done by anti-patterns is knowing how to avoid them.

While being able to identify anti-patterns is incredibly important, it is also important that one knows how to prevent their occurrence in the first place. One method of doing so is by stepping back and looking at the greater picture of the project that you are working on. “When working on software projects, it is essential to be aware of common pitfalls that can lead to anti-patterns. One strategy to avoid these pitfalls is to take a step back and consider the larger context of the problem. Understanding the problem in its entirety will help in coming up with a good solution.” Instead of being hyper-focused on one part of a larger project, which could lead to anti-patterns arising in your code, its best to take a step back occasionally to make sure what you are working on is not falling into the traps of anti-patterns. Another method of preventing anti-patterns would be a divide-and-conquer approach to developing features. “Another strategy is to break down large problems into smaller pieces. Doing this can help avoid getting overwhelmed and make it easier to spot issues and inefficiencies.” Using this strategy can be very beneficial because it can allow you to see anti-patterns as they appear in your code.

Article: https://www.baeldung.com/cs/anti-patterns

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.

CS343 – Week 4

Through the duration of this class, we have worked a lot with different types of classes, abstract and concrete, as well as interfaces to better design the code. It was not a new concept to me, as I have learned some of the basics to these in prior classes. However, I never truly understood the benefits and the right time to incorporate each. The articles I found give a simple explanation on the distinctions between concrete classes, abstract classes, and interfaces, as well as the correct situations to use them in.

A concrete class, sometimes just referred to as a class, is used to specify any entity. It also can work as a blueprint for all entities with the same attributes. An abstract class and interfaces are similar and was often confusing for me to distinguish the two of them at first. An abstract class will have methods implemented inside the body, but abstract methods will not have the body of the method inside this class. For example, the duck class I was working with for Homework 2 has the abstract class Duck and the abstract method display(). The body of the method is not present in the abstract class because the different concrete classes implementing Duck uses display() to show different messages. An interface only has the method names included for classes to implement with the interface but does not have any body of the methods. This is what partially distinguishes abstract classes from interfaces, as abstract classes can have concrete methods defined in them while interfaces can only have the method names defined. Interfaces are handy when only needing to enforce a contract. Whoever implements this interface will provide an implementation of all the methods. Abstract classes are helpful when only needing partial implementation, which leaves the responsibility of implementing non-useful methods from the class.

The phrase “program to an interface, not an implementation” is new to me and I am starting to make more sense of it. Concrete classes are the actual implementation, interfaces are the contract, and abstract classes are a trade-off between both. Being able to fully program these three structures into the program helps with maintainability, extensibility, and testability. When programming to an interface, you are forced to split the program into subsystems, with each subsystem responsible for certain tasks and having the ability to communicate with each other to complete the whole task. The key to making the program more flexible is focusing the design on what the code is doing rather than how it does it.

I decided to pick this topic for my blog because I had always had a good idea of how to physically write programs to function correctly. However, something that I never focused on before was the structure of the code which can help when needing to develop the program further after initial creation. Most of our time spent in the class so far has been focusing on this concept and it is proving to be very important the more a program continues to develop.

Program to Interface, Not Implementation – Beginner’s Tutorial for Understanding Interface, Abstract Class and Concrete Class – CodeProject

Programming to an Interface – DZone

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

SW Design Strategy – Interfaces vs. Abstract Classes

An age-old discussion in the computer science and Object-Oriented Programming world is whether/when to implement interfaces or inherit through abstract classes. In these first few weeks of CS-343 we’ve been working on several activities discussing some of the strengths, weaknesses, and differences between interfaces and abstract classes. In the past I’ve worked on some mid-modest sized projects which include both and can think of a few great examples of using each, but I found that I still struggled to understand some of the basic conceptual differences. So while I had a solid grasp on some effective use cases, I didn’t have a very clear idea on how to choose one/the other when in design stages where a lot less may be known about the project and how it may take shape later on.

Interfaces or Abstract Classes is a blog post from 2017 that I came across through web searching which explains some of the key conceptual and strategic differences between abstract classes and interfaces. Author Suhas Chatekar begins by discussing some of the most common responses he has received when asking this question in interviews. Abstract classes are typically preferred if there are suspected to be changes/additions needed later on. Interfaces are considered best when there are likely to be many different definitions for the same inherited methods, or as a possible alternative or substitute in multiple-inheritance in languages which do not support it (like Java/C#). 

Often it’s difficult to verbalize these differences, but this pretty well summarized my understanding. However, these philosophies focus on using interfaces to get around a syntax/language obstacle rather than as a best-case tool and are what Chatekar dubs “futuristic”, in that they rely on a programmer to know how the program is going to turn out longer term at the beginning which is simply unrealistic on a large scale project. Instead, he suggests an approach of considering interfaces as establishing a “can-do” relationship versus abstract classes creating a “is-a” relationship.

In the past and in CS-343, I’ve heard these terms thrown around and attached sometimes, but this post helped me to better understand the value in this approach and line of thinking for project planning. Commonly project components and requirements shift over the course of a project as unexpected needs are identified and addressed which cannot necessarily be planned for, so a futuristic interface-versus-abstract decision process seems likely to fail or be significantly less effective than a simplified approach focused on anticipated “is-a” and “can-do” relationships. One of my first and favorite interface/inheritance example projects simulated a Chess game using Java with a ChessPiece abstract class as well as a PieceAction interface; Regardless of later complications, each piece “is-a” ChessPiece, and “can-do” all PieceAction’s. This approach helps plan for future project events and needs in a more present state of mind, especially in long term projects that may include both.

Source:

Interfaces or Abstract Classes?. I have been asking this question in… | by Suhas Chatekar | Medium

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

The Art of Crafting Web Systems: Unveiling the Front End, Back End, and Data Persistence Layer

In the exciting realm of web development, the successful implementation of web systems hinges on understanding the intricate dance between three core components: the front end, the back end, and the data persistence layer. This blog post aims to dissect these vital components, shedding light on how they collaborate harmoniously to bring web applications to life.

The Front-End Canvas

Imagine the front end as the artist’s canvas, the visual facade of your web application that users interact with directly. It encompasses everything you see and interact with on a website—buttons, forms, navigation menus, and the overall layout. The front end relies on a trio of essential technologies:

  1. HTML (Hypertext Markup Language): HTML acts as the foundation, structuring web pages by defining content and layout.
  2. CSS (Cascading Style Sheets): CSS is the stylistic wizard responsible for the visual appeal, ensuring that the web elements harmonize seamlessly.
  3. JavaScript: JavaScript adds interactivity to the canvas, bringing it to life by creating dynamic elements, managing user input, and facilitating communication with the back end.

The Back-End Engine

Behind the scenes, the back end serves as the powerhouse of your web application. It handles user requests, processes data, interacts with databases, and sends responses. Several technologies and frameworks excel in back-end development:

  1. Node.js: Node.js enables JavaScript to run on the server side, making full-stack development a breeze.
  2. Ruby on Rails: Rails offers a structured framework that simplifies the creation of robust web applications with concise code.

The Data Persistence Layer

No web system is complete without a reliable data persistence layer. This layer manages data storage, retrieval, and efficient data management. It’s home to various types of databases, including:

  1. MySQL: MySQL, a popular relational database, is known for its reliability and is widely used in web applications.

The Synchronized Symphony

These three layers—front end, back end, and data persistence—complement each other to deliver a seamless user experience. When a user interacts with the front end, JavaScript often sends HTTP requests to the back end. The back end processes these requests, interacts with the chosen database to retrieve or store data, and then sends a response back to the front end. JavaScript on the front end dynamically updates the user interface based on this response, creating a responsive and interactive web application.

In Closing

Understanding the synergy between the front end, back end, and data persistence layer is fundamental to web development. These layers work in harmony, much like the instruments in an orchestra, to create the symphony of a fully functional web system. As you embark on your web development journey, remember that mastery of these layers takes time, practice, and a touch of artistry. So, keep coding, keep building, and explore the boundless possibilities of web system implementation.

References:

From the blog CS-343 – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

Week of October 2, 2023

https://refactoring.guru/design-patterns/singleton

This week, I wanted to a find a source relating to software design and architectures. I’ve been curious about what I would need to know so I could write more robust and efficient code. One aspect of improving my code would be knowing how best to preserve available system memory and perform whatever tasks I need to within as few CPU cycles as I can. If my program is creating multiple instances of a class that are all doing the same thing, my code would be consuming more system resources than if I had one instance of a class that could be accessed by other parts of my code. The Singleton design pattern seeks to preserve memory consumption by utilizing a single static instance of a class that may be globally referenced from the rest of the program. To properly implement the Singleton, the constructor for your Singleton instance should be static and private. To get the instance, you would also need a public static creation method.

My homework for this week involves refactoring a class into the Singleton pattern, so I was especially interested in learning about it. I found this blog called The Refactoring Guru, and a post explaining the implementation of the Singleton, as well as the pros and cons from a design perspective. The Singleton design is useful when a program needs global access to a class, like when a program has a single attached database. The drawbacks of the Singleton approach, though, are that it does too many things at once in violation of the Single Responsibility Principle, and that it may compromise your program’s security because of a crucial class being accessed as a global variable.

The final paragraph of the blog post makes some comparisons between the Singleton design and two other software design patterns, Façade and Flyweight. Façade is a design pattern of constructing a simple user interface with a complicated backend. This design pattern offers a sort of “black box” functionality to users, having a simple frontend to interact with without the need to inform users about the inner implementations of the software. The practical example given for a Façade software design is a video encoding service that accepts video files from the user as input and returns the same file encoded in a new file format. The user would only need to interact with the function that accepts a file and a desired file type as parameters, without needing to access the methods within the program that perform operations on the input file.

This blog includes helpful illustrations and pseudocode to explain multiple different software design patterns. I’ve been needing more resources on broader software structure and design rather than individual blocks of code, and I’m happy that I found this website.

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

Cs-348, Cs @ Worcester Week 4

Software Development Methodologies

This week we have learned about software development methodology which is a series of processes used in projects. It is a codified communication tool which is a series of workflows between a group of people about how they are going to work, pass information, and communicate between each member in certain ways.

There are two methodologies that were introduced in our class. Waterfall software development methodology is one where each step is performed in order, a single time, and each step is not started until the previous step is completed. Agile methodology, one of the features of this software development methodology is that the cycle of steps is performed repeatedly, in short increments.

I found a blog that points out the common methodologies and they conclude with a comparison between them and also give out suggestions that might suit certain projects.

URL link: https://intersog.com/blog/top-software-development-methodologies/

  1. Waterfall
    This is the most straightforward approach to software development; however, it is relatively rigid as it consists of sequential phases that follow one another in order. All of these stages are performed in sequential order, the next step is started after the previous one is over.
    This method is essential to have clear objectives and stable project requirements. The main disadvantage is rather rigid and does not allow for any flexibility. Once the development stage is over, it is hard to come back to it and implement any changes. Another issue with this method is that it takes a long time.
  2. Agile
    Agile is an alternative development methodology that offers an entirely different experience from the Waterfall model. The idea is to break the development process down into bite-size pieces, increments, allowing the developers to make fast gradual changes to create a perfect end product.
    The agile method has the advantage of enabling developers to make incremental progress over a limited number of iterations. If any adjustments are required, they may always go back to a prior milestone. This method is appropriate for tasks when the final product’s appearance is uncertain. This approach, however, places an undue emphasis on team communication that may be difficult for remote teams to manage. Additionally, the project manager must have extensive experience in managing the entire project.
  3. Rapid Development
    The purpose of this method is to repeat the user design and construction phase as often as needed to satisfy the client’s requirements. This method could produce great results faster and at a lower cost. Being a popular alternative to agile in software development, it allows the developers to adjust to the changing requirements to meet the needs of a changing market.
    So, as much as agile, this approach suits dynamic projects in volatile markets and allows for rapid changes at a low cost. However, RAD method needs to ensure the developers’ expertise.
  4. Lean

This method cuts all the redundancies and inefficiencies to maximize performance. Maximizing the output of the project and the individual contributors. Professional software development teams already use a Lean approach, it is most effective when combined with another method, any project can be made Lean by reducing waste and emphasizing top-priority tasks. It needs a team of developers who can suit their approach to customer demands.

  1. Feature-Driven Development
    The large projects requiring months and months of backend coding, implementing the Feature-Driven Development (FDD) model might work for these projects. Usually, each feature takes a couple of weeks to finish its steps, and by the end of the development cycle, you get yourself a fully functional end product.
    This model is suitable for large projects, and remote teams as it requires fewer client and vendor meetings. The model requires a strong understanding of the project’s scope from every individual developer – all of them need to know what they are working towards.

To sum up, we must choose the one that suits your project. However, they prefer Agile as the most used approach that fits most projects and allows for greater flexibility, especially regarding long-term development cycles. This blog helped me to understand the process of each methodology and know the way to find a suitable method for the project in the future.

From the blog CS@Worcester – Hong Huynh-CS348-WSU by hhuynh3 and used with permission of the author. All other rights reserved by the author.

What is Git?

For the entirety of this course so far we have been working and getting familiar with the version control tool git. In this week’s blog I will be writing about a blog called “What is Git | Explore a Distributed Version Control Tool” by Reshma Ahmed. I have chosen this article in particular to see how it came to existence, the roles they play in companies, and to get a further understanding in addition to what we have learned in class.

From the article I have learned the different types of version control such as centralized version control system and distributed version control systems. Git was created in 2005 by Linus Torvalds designed to “handle small to large projects with efficiency”. Git is a distributive version control system which is a system that prevents corruption and crashes that were caused from having a server hosted in a single repository such as in centralized version control systems due to everyone having a copy on their machine of their local repository. When reflecting back to the course we have been practicing with pushing and pulling from repositories, branches, as well as removing and adding commits. The GitKit activities worked on in class shown us practical issues that one may face with git such as merging issues as well as issues involving different versions of commits.

The article describes some of the features of git which we have looked at in class such as being open source as well as being secure. Open source software encourages transparency, collaboration, and accessibility similar to the FOSS communities mentioned in the first GitKit activity done in class. The article reads “Git uses the SHA1 to name and identify objects within its repository”. This concept becomes apparent from seeing in the GitKit activities done in class when applying commands such as “git log” that shows a commits’ hash as well as the date a commit was made.

Git not only is used in the software development community but plays a detrimental role in companies with more and more companies using git as their go-to version control system. Some of these companies include tech giants such as “Facebook, Yahoo, Twitter, eBay, Salesforce, [and] Microsoft” which shows the significance of git.

When reflecting for my personal future use of git, practical applications of git in the field of machine learning and data science is using git to manage datasets to ensure reproducibility as well as data integrity. In addition, I plan on using git for my data mining course project when collaborating with other peers.

Links

https://www.edureka.co/blog/what-is-git/#companies_using_git

From the blog CS@Worcester – Anthony Duong CS Blog by anthony duong and used with permission of the author. All other rights reserved by the author.

osu!lazer

Osu! is a free rhythm game that I often play and keep up with. Developed by Dean “peppy” Herbert, it was released in 2007 and was heavily inspired by a 2005 Japanese rhythm game known as Osu! Tatakae! Ouendan. The game, even to today, is not very popular compared to what is considered the “mainstream” for video games; but the players and fans of it are truly dedicated and supporting. Since its release, peppy sought to improve, fix, and maintain the game but that became increasingly difficult with how old and jumbled the code for the game was; and thus, he decided to work from the ground up. In 2015, he began the development of an osu! 2.0 which soon became known as “osu!lazer.” 

I chose to cover this game because the development is public, its updates are being covered on their youtube channel, and I enjoy the game and its community. While watching this video (a bunch of lazer updates), I noticed that a well known player known as -GN made a pull request. It was at this point in which I realized that they’ve been working on GitHub and that what they do is basically what I’ve been learning but in a real-world application. 

I thought that now that I was a little more familiar with GitHub and the process of development, I could check out what was happening with osu!lazer. I went to their repository page (https://github.com/ppy/osu/releases) and simply looked around. The most notable things about the repo would be the number of issues and pull requests. 1,000 active issues is already quite the number but over 25,000 issues over the course of this project seems simply insane. This may just be due to my lack of knowledge and experience as this is a relatively small team and project but those numbers could be even bigger with much larger games and their possibly massive development teams. 

Exploring the repo made me realize how complicated software development, game development, or any other kind of development can be, at least with my current knowledge and experience. For example, there are lots of tags used for issues and pull requests, areas of the game, priority, and size are just some of the categories that the team has decided to divide the development into. I realized that how the game is developed, in the coding, more technical, and specific aspects is still quite foreign to me. Despite having taken computer science classes for many years and creating code in those classes, this level of programming seems so far away. I hope to be able to get to this level and possibly even contribute to osu!lazer, but I occasionally find myself questioning if I’ll really be able to code at this level. 

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