Category Archives: Blog

Code Can be Dirty?

Unfortunately, yes

The above code is positively awful to look at, read, try to understand, and generally poor practice. Recently, in this semesters Software Development class, we have moved away from project structures, and into clean code. What makes it clean, why is it important, and related topics.

Why clean?

Clean code provides an easy reading experience for anyone looking at it. This include people later working on something released years ago, as well as the person writing completely new code for the first time. Every example of code can benefit from being clean. Coding cleanly enables readers to understand what the code is doing, and makes it easy to follow mentally. As well as this, clean code can make better code, as spotting mistakes is made easier when you know where everything should be.

What makes code clean?

Clean code is code that is easy to read, understand, and modify because it expresses its intent clearly and avoids unnecessary complexity. It uses meaningful names, small and focused functions, and consistent structure so that another developer can quickly grasp what it does without confusion. Clean code avoids duplication, hides internal details, and keeps responsibilities separated so each block does one thing well. It favors simplicity over cleverness, documents why decisions were made, and is organized in a way that makes future changes safe, predictable, and maintainable.

In the wild

This video is a perfect example of how clean code, and specifically refraining from nesting your code too much, is a good habit to form. The video explains that multiple layers of if statements, loops, and conditional branches make code harder to read, maintain, test, and debug. The creator argues that nesting increases cognitive load because developers must track several scopes at once, and it often signals that a function is trying to do too many things. The video recommends techniques such as using early returns, inverting conditions, and extracting complex inner blocks into smaller, well-named functions so the main “happy path” remains flat and easy to follow. Overall, reducing nesting leads to cleaner, more understandable, and more maintainable code.

I chose this resource as it was a fun video that I found ‘in the wild’ while simply scrolling, and felt that it closely aligned with principles we have been learning in class.

In conjunction with in class learning, I have been swayed to become a ‘never-nester’. I would like to put into practice this behavior, and am excited to maintain clean, readable code in future projects.

This concludes my mandatory blog post of Quarter 3 for the semester.

— Will Crosby

From the blog CS@Worcester – ELITE Computer Science by William Crosby and used with permission of the author. All other rights reserved by the author.

Scrum On

Software Development Methods

Wow, look at us, huh? Almost a month later, another post appears! This month (I guess I’ve moved to monthly blogging… We’ll tighten it up, I promise) has been mostly about the different ways to go about developing something. Neat, huh?

So far, we’ve talked about waterfall, agile, and the latest, scrum!

SCRUM

Scrum builds upon each previous development methodology, and is a natural extension of Agile. It is not, however, ‘better’ than agile, but simply different. No one methodology is the best, but some perform better than other in certain circumstances. Scrum is the latest methodology that my class has been learning about, and as such I decided to take some time to further look into it.

Scrum in 20 minutes is a video I came upon while looking for examples. It explains the process of scrum, why it is used, and how it is different to other methodologies. As well as this, the video contains a few examples of how using scrum has been beneficial.

One of the reasons that I decided to watch this video was that it simply looked professional. It was well polished, and felt like a finished product. A lot of the times, when I go looking for academic supplemental material, I’m presented with a sea of the same animated characters, slideshows, and whiteboard-style videos, so this one was a VERY nice change of pace. More of these, please! (I have some words with whoever invented PowToon).

This video really helped me to see how Scrum is applied to a real life example. I also appreciated the refresher on the process as a whole, but having real-life examples of a full sprint, planning, and what each of the team members’ roles contribute was really helpful in better understanding Scrum as a whole.

Something that I realized while watching the video, was that Scrum does not have to be software development specific. I play a lot of optimization games, and something like scrum just feels extremely organized, and is something that I feel is worth applying, at least in terms of concept, to more of my life than just this one small facet. Organization and goal setting is important in almost everything we do, and Scrum is just one way to do that, but it has been refined over multiple years of trial and error.

I am excited to apply scrum to future projects, and look forward to the increased organization that a solid planning methodology will bring to the table.

This concludes my mandatory blog post of Quarter 2 for the semester.

— Will Crosby

From the blog CS@Worcester – ELITE Computer Science by William Crosby and used with permission of the author. All other rights reserved by the author.

Using Github Codespaces in Class

Github in the classroom

While I have used github before in previous projects, this semester I have begun to dig deeper into it’s uses. Codespaces is one such use, and is an important tool to learn and use properly. While we have gone over github codespaces and git command line use in class, sometimes looking around online can help streamline the experience. Github themselves post their own blogs relating to their site’s recourses, and codespaces is no exception.

10 things you didn’t know you could do with GitHub Codespaces

This github blog details all of the various uses of their codespaces, and offers good suggestions, background, and description of both what it is, and why you should be using it. Mostly, this blog details the features that are both useful but not often utilized, as well as details why these features are helpful tools.

I chose to talk about this blog post (with my blog post, haha) because this is a tool that I personally have used, but didn’t really know too much about. I was told to use it in class for x y and z, but never really thought about how valuable it actually is. I only have experience with VS code and other Microsoft IDEs, but it’s cool to know that codespaces supports much more than just that one IDE. as well as this, I think it is extremely convenient to have access to a workspace without setting up everything locally, and am excited to try to learn how it better utilize this feature, as I realized that this feature has directly impacted my class experience; The professor only needed to give us a repository, and we were ready to work on our assignment, with no setup or install hassle!

Another feature of that I am now excited to try is live sharing. Live sharing allows you and other people to work in the same code file at the same time, similar to having multiple people in one google doc. It even shows where their cursor is and everything! I think this feature could significantly improve the group project experience, as previous years I’ve been frustrated with how annoying it is to work on the same code together with my group.

Lastly, codespaces allows you to easily manage all of your working areas, and makes file management easier to, well, manage! In my previous classes, I’ve found the most difficulty in the storage and file layout of my projects, which impacts how/if it runs at all on my local device. Being able to manage this and keep everything more separated with codespaces should, in my opinion, help with these troubles.

This concludes my mandatory blog post of Quarter 1 for the semester.

Till the next one,

— Will Crosby

From the blog CS@Worcester – ELITE Computer Science by William Crosby and used with permission of the author. All other rights reserved by the author.

Welcome to the ELITE CS student Experience!

Please enjoy a congratulatory firework display to celebrate (shot by yours truly).

So, what are we about?

Welcome to my blog! My name is Will, and plan to document my experiences as a CS student, starting with this post! As the semester kicks off, not too much is happening in my academic world at the moment, but I doubt things will stay as calm as they are…

While this blog was requested as documentation for one particular class that I am enrolled in this semester, I figure I could use it for all of my classes… why waste a blog, ya know?

In terms of tone, I intend to keep it light and fun. While a strictly ‘professional’ blog would probably be better for the impending job search (I say impending like it hasn’t already started), I would rather not feel like slogging through a chore every time I sit down to write for this, so fun it is (sorry future me…)!

In case you wanted to know more about me, (I know you want to), I’m currently a Junior is WSU’s Computer Science program. I enjoy the subject material, and am always interested in electronics and software design. As well as this, I’m a photography hobbyist, read a hefty amount of fantasy and sci-fi literature (Hobb is the goat), enjoy model kit building, and have an unseemly fountain pen collection (to the average person… I’m nowhere close to those actual collection freaks). Lastly, my current music fix is Laufey — (It’s currently playing as I write this).

Anyway… at the current moment, I’ve not much to say, but soon I’m sure once syllabus week is concluded, there will be more to come. Also, do please excuse my excessive use of parenthesis, I was having fun.

Once again, welcome to the ELITE CS student experience.

– Will

From the blog CS@Worcester – ELITE Computer Science by William Crosby and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

Gitlab Activity:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/addinventoryfrontend/-/merge_requests/42

This merge request was made to update the design of AddInventoryFrontend to match the design of CheckInventoryFrontend that Anthony Cao implemented. This was done to maintain consistency and use on-brand color schemes for Worcester State University and Thea’s Pantry. A navigation bar was also added to redirect to the home page, but functionality for this can be added by teams in the future.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/addinventoryfrontend/-/merge_requests/43

This merge request was made to implement a drop-down menu in AddInventoryFrontend. Instead of entering WSUID for submission, users select an option from a drop-down menu characterizing themselves; if ‘Other’ is selected, a comment is required prior to submission.

This was the last sprint of the semester so there wasn’t much that didn’t work well. The team communicated well as usual, consistent merge requests were being made across the InventorySystem – WeightBased and things progressed smoothly. As an individual, I had no issues implementing the drop-down feature in AddInventoryFrontend that the client suggested but I personally struggled with finding work towards the end of the sprint. My teammates also seemed to struggle with this. There was work to be done, but the end of the semester offered an awkward phase of trying to still get things done while not taking on a task too large that would surpass the remainder of the time in the semester. AddInventoryFrontend seemed to be at a stage where significant changes would have to be done at a later date, so I ended up assisting Guilherme Salazar Almeida Nazareth with writing tests using Mocha and Chai for InventoryBackend. He was able to wrap this up in time for our sprint demo. No changes were needed during this semester to work effectively as a team, we mostly just had to focus on finishing up strong.

The pattern I choose from “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye” to describe Sprint 3 is “The Deep End.” This references the fear of taking too much on at once due to not feeling comfortable/ready to do so. The want to grow your skills or portfolio while feeling a sense of imposter syndrome is a very common thing. I think this accurately describes the end of the semester for my team because although everyone still had work to do, we feared taking on too large a task for fear of not finishing it in time. But reflecting on this, it might have been better to start a large task and give future teams a template to work with instead of not trying to develop anything larger at all. If I read this pattern at the beginning of the sprint, I probably would have put my Scrum Master title to use and encourage myself and my teammates to take on larger tasks and assure them that with proper documentation and descriptions on Gitlab, we’d actually be helping future teams with their work. 

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.

Sprint 2

During this sprint, I switched up the work I did compared to the last sprint instead of working on the backend I was given the task to oversee the front end. First going into the front end blindly I didn’t know exactly how far the front end was already and had to accommodate myself to the code. First opening the frontend I noticed it was missing several files that would hold great importance in starting the frontend. One of my first fixes was the docker-compose file left by the other group was the backend file the same so I created a new file that would hold both servers of the front end and the backend. I updated some of the documentation that had been outdated compared to what we were working on currently. I created a new way to start the frontend server because it was missing that and added an up.sh, down.sh, and rebuild.sh for the front end. I also updated the outdated docker file. After I had a basis for what was needed I decided to go in and organize it better to read the new files in an organized manner to see what files were missing. Had to add new assets and components including new pictures of Libre food pantry and any other ones that were needed. 

During this sprint, I worked well working alone but I should have checked more often with my teammates because of the issue that would later fall upon me. I was making progress every week but I hadn’t yet seen the biggest fault was the backend would crash on me. Next time I should check in with my teammates sooner instead of making progress on my own. I just didn’t want to slow down my teammates with my work. That is a fault in itself I shouldn’t be scared for help because the team will fail if I do this. 

This time around the apprenticeship pattern that resonated with me the most was breakable toys because it is the basis of each sprint. You must create a small project where you can make mistakes in order to learn and be better. During this spring I was learning the ins and outs of the front end on something someone else created that I had to update and fix. This pattern could have made me more confident in messing up because it’s now wrong to mess up. Failing would help with issues that would come up that would show me what to do in other scenarios. Another pattern I would choose is to learn how you fail. I had many times during this sprint where I was head scratching to find an answer or come to an understanding of something but picking up on the patterns of how I failed I could change for the next issue that would come up. This issue opens my mind to being more intentional with my work and picking up on my common mistakes even if sometimes simple mistakes are the biggest headaches. Errors can be preventable by understanding why you do something and adapting to catch them next time. During this sprint, I learned a great deal about my project and I hope in the next sprint I will be able to learn more.

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

Sprint 2 Retrospective

Gitlab activity:

The most important thing that worked well during this sprint, as addressed in all of the Team Project Effectiveness Reports, was communication. Our team communicates really well in person, and online after class. We use discord as our primary source of communication and everyone is really prompt in responding, whether it be in regard to simple questions or chronic issues that one of the systems is causing a team member. The use of the issue board in Gitlab improved during Sprint 2, which allowed the team to keep better track of what was happening, and more importantly, getting completed during the sprint. This allowed us to easily showcase our work during the Sprint Review because we were able to just look back at the issue board. 

The primary thing that didn’t work well this sprint was a clear idea of the work that should actually be getting done. Plenty of work was completed, but it was done on a basis that should have been pre-defined. Doing work as we find issues or come up with ideas is not the most efficient way to make beneficial changes to the “InventorySystem – Weight Based” and we need to work on this. 

Establishing stricter goals for the sprints will allow us to complete more meaningful work. This is the biggest change I think that needs to be made as a team. Personally, I think my best traits are ensuring that everyone’s voices are heard, and I’ve gotten positive feedback in this regard, and that my teammates are always informed of the work I’m doing. The team has decided that I should remain scrum master, and to fulfill my role, I will encourage us to define the stricter work goals that I previously mentioned.

Relevant Apprenticeship Pattern:

The pattern I have chosen to describe Sprint 2 is “Rubbing Elbows.” This pattern states that the act of collaboration can be referred to as “rubbing elbows” and if you reach a plateau in your individual abilities, collaborating with others may help you continue making progress. It is obvious that collaboration is taking place as this is a group project, but sometimes it is apparent that team members, myself included, struggle with our own work. I chose this pattern because I noticed the prevalence of it today actually. I was working on updating the design elements of AddInventoryFrontend and couldn’t figure out why my changes weren’t being made in the browser. I would’ve pondered over this issue for more minutes than I’d like to admit, but I “rubbed elbows” with Guilherme and was able to notice that merely a single line of code needed to be changed. Being more aware of this pattern during Sprint 2 probably would have encouraged more pair-programming, the use of the TV, or rubbing of elbows to navigate issues. The work doesn’t have to entirely be done alone. Overall, if stricter goals are defined for work that needs to be done, and we emphasize a greater sense of collaboration in class, Sprint 3 will hopefully reap the most benefits in terms of code contributions compared to Sprints 1 and 2.

Source of pattern: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch04.html?_gl=1*1gf7b0t*_ga*MTQzNTk4ODQ5OC4xNzQ0NzQxNTgz*_ga_092EL089CH*MTc0NDc0MTU4Mi4xLjEuMTc0NDc0MTcyNC40MS4wLjA.#rubbing_elbows

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.

Code Reviews

Source: https://about.gitlab.com/topics/version-control/what-is-code-review/

A code review is code that is peer-reviewed, which helps developers validate the code’s quality before it is merged and shipped to production. Code reviews are done to identify bugs, increase the overall quality of the code, and to ensure that the developers of the product understand the source code. Code reviews allow for a “second opinion” on the functionality of code before it is actually implemented in the systems. This prevents non-functional code from being implemented in the product and potentially causing issues or bottlenecks in performance. Ensuring that code is always being reviewed before merging encourages the developers to think more critically of their own code, and allows reviewers to gain more domain knowledge regarding the systems of the product. Code reviews prevent unstable code from being used by customers, which would lead to poor credibility and overall act as a detriment on the business. The benefits of code reviews are as follows: knowledge is shared among developers, bugs are discovered earlier, establishment of a shared development style/environment, enhanced security, increased collaboration, and most importantly, improved code quality. As with everything, there still are disadvantages. Code reviews lead to longer shipping times, pull focus/manpower from other aspects of the process,and large code reviewers equal longer review times. But the benefits far outweigh these disadvantages.

Code reviews can be implemented in multiple ways, through pair programming, over-the-shoulder reviews, tool-assisted reviews, or even email pass-around. Gitlab offers an interesting feature where developers can require approval from reviewers before their code can be merged. I chose this article because I use this feature frequently in my capstone class. My teammates and I review each other’s changes in the codebase through this Gitlab feature and, if needed, go over these changes in class whether it be through pair programming or over-the-shoulder reviews.

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.

Behavioral Testing

Source: https://keploy.io/blog/community/understanding-different-types-of-behavioral-unit-tests

Behavioral unit tests validate how code units operate under certain conditions, allowing developers to ensure that the software/application is working as it should be. Behavioral unit tests focus on specific pieces of code. They help developers find bugs early and work based on real scenarios. They lead to improved code quality because this unit testing ensures that the software is up to the expectations of the user, and allows for easier refactoring. The key types of behavioral unit tests include happy path tests, negative tests, boundary tests, error handling tests, state transition tests, performance driven tests, and integration-friendly tests. The one that caught my attention was the performance-driven test. These tests validate performance under specified constraints, such as handling 10,000 queries. The test is run to ensure that performance remains acceptable under various loads. This test caught my attention because in my cloud computing class, I was loading files with millions of data entries, and the performance suffered, which highlights the importance of unit testing under conditions such as these.

The difference between functional and behavioral unit tests is that functional tests validate the system’s function overall, whereas behavioral tests focus on specific pieces of code to make sure that they behave as expected under various conditions. Behavioral unit tests should be run every time code is built to make sure changes in the code don’t cause problems. Tools that can be used for this kind of testing include JUnit/Mockito for Java, pytest for Python, and Jest for JavaScript. I chose this article because we use JUnit/Mockito in class and thought it’d be wise to expand my knowledge on other unit tests. It’s good to get reassurance that unit testing is important from all of the sources I’ve been learning from, because it is very apparent that many different scenarios can cause many different problems in regard to the production of code/software/applications.

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.

Data Flow Testing

Source: https://www.testbytes.net/blog/data-flow-testing/

Data Flow Testing, viewed as a nuanced approach in software testing, is the process of examining data variables and their values through the use of the control flow graph. Data Flow Testing is an example of white box and structural testing. By targeting gaps that become prevalent within path and branch testing, data flow testing aims to locate bugs from the misuse of data variables/values. 

Data flow testing is used on both static and dynamic levels. In static levels, data flow testing involves the analysis of source code without actually running the application. The control flow graph in this instance represents execution paths of the code from the application. Errors that can be found on the static level include, definition-use anomalies (a variable is defined but is never used), redundant definitions (variable is defined multiple times before it’s used), and uninitialized use (a variable is used before a value has been assigned). 

On the dynamic level, the application is executed, and the flow of data values/variables is analyzed. Issues that can be found on this level include, data corruption (value of a variable is modified in an unexpected way, leading to undesirable behaviors), memory leaks (unnecessary memory allocations, memory consumption becomes uncontrolled), and invalid data manipulation (data is manipulation in an unpredicted way, causing many outputs).

The steps of data flow testing include identifying the variables, constructing a control flow graph, analyzing the flow of data, identifying anomalies in the data, dynamic testing, designing test cases and executing them, resolving anomalies, and documentation. I decided to read about data flow testing because I thought it’d be valuable to learn about how this type of testing allows for early bug detection and overall improved code quality and maintainability. The obvious downsides however are that not every possible anomaly can be caught, the process can be time consuming, and other testing techniques should also be used.

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.