Category Archives: CS@Worcester

Unleash Your Enthusiasm

For this week’s blog, I decided to discuss the pattern from Chapter 2 called “Unleash Your Enthusiasm”. This pattern discusses the enthusiasm for learning that many software engineering apprentices experience and how you should show it because, at this point in your career, you can provide unique qualities. This section discusses the situation where you may find yourself holding back because you may find that you have more enthusiasm than your colleagues. This is because there may be pressure to conform to the norm whenever you work on a team. In addition to this, many teams mainly focus on delivering the next product or improving on the aspects of the development life cycle. It also explains the risk of exposing your enthusiasm to an established team. In this situation, the text explains if the morale of the team is low or if they are not very welcoming to newcomers, you might make a poor impression. In this case, the text mentions that the advice in the section should not be applied blindly because you need to consider team dynamics.

The reason that I decided to pick this pattern is that I have never thought of concealing or holding back my enthusiasm for my craft. Every team that I have gotten the pleasure of joining in some way really valued my enthusiasm and the skills that they could learn from me. I have always been on a team where we all encouraged each other to learn from someone else on the team. Needless to say, I have never thought about the possibility of making a bad impression because of my enthusiasm for the task. In hindsight, I can see how exposing your ignorance of a topic can upset a team that values competence over enthusiasm for learning. I do think this quote from the text holds truth to it because of my own experience: “it is actually healthier for a team to consist of people with varying levels of experience”. Tech is a fast-paced industry so everyone is forced to keep up with new trends. A team that has a diverse set of skills at different levels is bound to create a healthy environment. With that being said, I can’t say that I disagree with anything from this section but I will be more aware of unleashing my enthusiasm on certain teams.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

Workstations: The best setup for CS Students

Here’s the thing, having the right workstation isn’t just about keeping up with the cool kids anymore, it’s about finding the right blend of power, ergonomics, and style to run through coding marathons, debug sessions, and endless project nights. Let me guide you through what, in my opinion, is the best (somewhat cheap?) setup you could have as a CS student.

First off, the centerpiece of your digital dominion: the Laptop. You know that for CS students the laptop is not just some tool you use, it’s your best friend, your main weapon, your Excalibur and as such It needs to be powerful enough to compile the code faster than you can say “runtime error”. Try to find a laptop that has:

  • Powerful CPU: Intel Core i7 or i9, or AMD Ryzen 7 or 9. If you’re into Macs, Apple’s Silicon chips have proven their efficiency these past years so if you can afford it, go for it.
  • Plenty of RAM: 16GB should be your starting point. If you’re into machine learning or running multiple Virtual Machines, 32GB should be your sweet spot.
  • SSD Storage: Waiting for your IDE to load is so, 2010’s. Most laptops now come with 256GB SSD, if you juggle multiple projects you can upgrade to 1TB.
  • Graphics Card: Look into a graphics card that is affordable but also new, It will be useful not only for GPU programming and A.I. work but also for winding down by running some of your favorite AAA studio games.

Some people might be content with only a laptop as their workstation and I can’t say they are wrong as some of you living in dorms might not have the space for your workstation, but trust me when I say that setting up peripherals is a game changer.

  • Hi-Res Monitors: A single 27-inch, 4K monitor can drastically change your coding experience by reducing eye strain and improving readability. It works great for having your code on one screen and your reference material on your laptop. I’m running a 34-inch ultra-wide + 15.6-inch laptop on the side. Maximum real estate.
  • Mechanical Keyboard: Once you go clack, you never go back. The tactile feedback is not only satisfying but also reduces typing fatigue. Plus, it makes you feel like a hacker from a 90s movie.
  • Ergonomic Mouse: Your wrist will thank you if you get a mouse that is fit for your hand, try to find something that feels right for you.
  • Quality Headphones with Noise Cancellation: For when you need to zone out and focus, or just vibe to some tunes while debugging.

Don’t be afraid to express yourselves whether it’s with LED lights, action figures, or posters of your favorite GitHub repos, make it yours. You’ll be spending a lot of time here, so make sure it’s a place that inspires you.

By now you should have what is essentially a perfect workstation. You have your laptop around campus, your station to hook it up and unleash its potential.

This is my personal working space,I hope it inspires you. Till next time,

Ano out.

References

https://www.techradar.com/pro/best-laptops-for-computer-science-students

https://simpleprogrammer.com/best-laptops-for-computer-science-students/

https://medium.com/technonerds/desk-setup-2020-peek-into-the-gear-i-use-daily-as-a-student-f88ea8be16f5

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

Understanding Integration Testing and System Testing.

When it comes to software development, ensuring that the final product meets the desired standards is crucial. This is where testing comes into play, and two significant types of testing are Integration Testing and System Testing. Let’s delve into what these testing methods entail and how they contribute to the quality of software products.

Integration Testing

Integration Testing focuses on testing the integration or interaction between different components or modules of a software system. In simpler terms, it examines how well individual units work together as a whole. This testing phase occurs after unit testing, where individual units of code are tested in isolation.

During Integration Testing, developers verify the interfaces between the units to ensure that they communicate correctly and exchange data appropriately. The main goal is to detect any defects or inconsistencies that arise when integrating these units. Integration Testing helps in identifying issues such as communication failures, data corruption, or incompatible interfaces early in the development process.

There are several approaches to Integration Testing, including top-down integration, bottom-up integration, and incremental integration. Each approach has its advantages and is chosen based on the software architecture and project requirements.

For more in-depth information on Integration Testing, you can refer to this link.

System Testing

System Testing takes a broader perspective by testing the entire software system as a whole. Unlike Integration Testing, which focuses on unit interactions, System Testing evaluates the system’s behavior and performance concerning the specified requirements.

In System Testing, testers validate various aspects of the software, including functionality, usability, reliability, and performance. This phase involves executing the software in an environment that closely resembles the production environment to simulate real-world usage scenarios. The goal is to ensure that the software meets the stakeholders’ expectations and functions correctly in different scenarios.

System Testing encompasses different types of testing, such as functional testing, usability testing, performance testing, and security testing. Each type of testing addresses specific aspects of the software to ensure its overall quality and reliability.

To learn more about System Testing and its types, you can visit this link.

In conclusion, Integration Testing and System Testing are integral parts of the software development lifecycle that help ensure the quality and reliability of the final product. While Integration Testing focuses on the interaction between individual units, System Testing evaluates the system as a whole. By conducting thorough testing at each stage of development, developers can identify and address issues early, leading to a more robust and reliable software product.

By understanding the concepts of Integration Testing and System Testing, developers and testers can effectively ensure the quality and reliability of their software products, ultimately enhancing user satisfaction and trust.

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

Decision Table Testing

The blog post, “Decision Table Testing: Everything You Need to Know”, discusses the concept of decision table testing in the software quality assurance field. Decision table testing is a systematic technique used to test the behavior of software systems against various input conditions. The blog post provided a comprehensive overview of decision tables, their components, advantages, and how they can be effectively utilized in software testing processes. In addition, the blog post offered practical insights into creating decision tables and implementing them effectively in test creation. It discussed the best practices for defining conditions, actions, and rules within decision tables, emphasizing the importance of clarity and consistency. Additionally, it provided tips for managing decision tables in a structured manner, facilitating easier maintenance and updates as the software evolves.

I chose this blog post because we have covered this topic extensively as well as incorporating a homework assignment on the topic. Due to this, I wanted to have further instruction on how this method of testing can be put to use and gain further knowledge on the method of testing. After reading the blog, I was able to gain a clearer understanding of decision table testing and its significance within software testing. Decision table testing is a very important testing method that will be a very useful tool to know and understand in use when testing for software quality assurance.

The blog highlighted the benefits of decision table testing, such as its ability to identify redundant test cases and minimize duplication efforts which are great to learn as it will help increase functionality of my tests as well as efficiency. From the blog post I was able to gain a greater understanding of Decision table testing and with that deeper understanding of decision table testing, I hope to be able to have real world scenarios that I would be able to apply the theory to. In conclusion, the resource not only expanded my knowledge of decision table testing but also equipped me with practical insights that I hope to be able to apply in my academic as well as my professional career in the future. As I continue to write and develop code for class and hopefully for career opportunities the more knowledge I have when it comes to software testing the better as it will help improve my level of design. Understanding one of the fundamental testing methods is just a step in the right direction for my career.

https://testsigma.com/blog/decision-table-testing

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

Reading List

As the title of this section suggests, it is solely focused on creating a reading list. On the surface, this section has to be the most straightforward in the book, and yet the one I practice/experience the least. With the ever-growing importance of broadening my learning through reading, I wanted to focus on this section as it feels like the obvious place to start.

Section Summary:

The idea of creating a reading list seems simple, yet so open-ended that it may also feel impossible. The section focuses on ways you can expand your reading list without feeling so overwhelmed with the endless knowledge that is available. When it comes to learning what books are important and useful enough to add to your list, it makes sense to ask mentors. Other online sources can offer reading lists from other people which may give a good insight of which books should be added to your list. The third way of finding useful sources was to pay attention to which sources are commonly referenced and cited in other readings. Seeing the same book cited multiple times can be a great indicator that it is an important book to add to your list. 

Reflection:

Having a list of which books to read next is a great way to stay organized however, having a reading list will also keep track of what books you have read. One of the points the reading made was that this list is also a reflection of your past reading habits. My list right now would reflect awful reading habits, and I must change that. When I first started to read through the patterns at the start of the semester I saw the entire chapter dedicated to reading and how important it was to broaden my education and craft with the use of reading. Starting a reading list from scratch felt like it was going to be an impossible task, with zero clue where to start or what books would be worth my time. With simple solutions provided by the reading, such as looking for likeminded lists from other people, asking mentors, and paying attention to the cited sources, I now feel way more comfortable with being able to develop my reading list.

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

Unit Testing

The blog written by Krishna Teja Dinavahi, “Unit Testing – Is it Really Helpful?” (https://engineering.zoominfo.com/unit-testing-is-it-really-helpful) does a great job explaining the importance of writing unit testable code. What is also mentioned is how unit testing and integration testing are two different forms of testing that are both equally important. I specifically enjoyed this blog because of the great examples of code that was not unit testable along with the steps taken to refactor the code. 

What is Unit Testing and How is it Helpful?

As it’s mentioned in the blog, looking up unit testing online will give you the textbook definition, “Unit tests help you test individual parts of your application in isolation.” This is the same thing that was described to me in class, but I had the same general reaction to unit testing as Dinavahi describes. Unit testing can sometimes feel tedious and redundant. However, the real importance of unit testing is clear when you explore code that is not unit testable. Unit testing can not be done on code that is written poorly. This was the biggest eye opener for me as I read this blog, especially with the great examples provided. Notably, the one where having the external dependencies in its own function allows for easy bug fixing if anything was to change in the eternal API.

What Makes Code Unit Testable?

As I recently began refactoring old code with some of the new techniques and agile methods, I noticed the largest hurdle for me is being able to create “pure functions.” These are functions that are limited to doing one task and are very clear what that task is. From my experiences, having pure functions and good naming conventions are the two most important aspects to readable and scalable code. Approaching the code with unit testing in mind, the should automatically be written in a way that you will create pure functions. 

Conclusion

As someone who strives to write clean, readable code, I feel like I share the motivation Dinavahi expresses in the blog when it comes to learning unit testing. Each time I have refactored my code, I have always felt like it was just not finished. However, using unit testing I will be able to identify which parts of my code are not written properly and need to be refactored again. This time, with the knowledge of the steps I can take to get to unit testable code. 

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

Knowing Test-Driven Development (TDD)

Hello everyone,

Today I want to talk about test-driven development (TDD), which plays an important role in software development and testing, and improves the reliability and quality of software products. Through my recent exploration of software testing knowledge, I learned the importance of TDD. So I recommend this blog. This blog provides an in-depth discussion of understanding TDD, its impact on software development, and how I foresee integrating this approach into my future practice.

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

By Ferdinando Santacroce

This blog explains the three-step cycle of TDD (write tests that fail, write minimal code to pass the test, and refactor) and the benefits associated with this approach. It illustrates how TDD promotes improved code quality, faster development cycles, and better software design, all of which resonate with what I learned in the course.

My personal code writing habit is to write the functional part first, and then write the corresponding test function to test its completeness. But TDD gave me a new choice, which is to write the test part first and then write the functional part. This gave me new inspiration. Maybe the TDD model will be more conducive to our work.

The author also wrote several interesting examples to help us understand how TDD works. He also reiterated that “TDD is a code technique, not a testing technique.” My personal understanding is that TDD can not only be used in the field of testing, but also can be used to think about any code-related issues, not just Just used for testing functionality.

Overall, TDD is not just about testing. it is also a mindset that prioritizes testing and quality from the outset of the development process. By adopting TDD, developers can build software with greater confidence, knowing that it has been thoroughly tested and meets the specified requirements.

From the blog CS@Worcester – Ty-Blog by Tianyuan Wang 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.

CS-448 Sprint 2 Retrospective

Merge branch ‘verify-pipeline-tests’ into ‘main’ (490e4d29) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / General · GitLab

Last sprint teams were focused on changing the pipeline tests and extensions for certain repositories and so this sprint teams were assigned to verify the correct linters and extensions were added as well as running the correct tests when committing the changes to Gitlab. ReportingSystem General does not build a Docker image nor does it have release number. For this repository, we only need to run the linter pipeline tests and ensure that they all passed with no errors.

Merge branch ‘verifying-that-reportingsystem-10’ into ‘main’ (e7755051) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / Documentation · GitLab

Like ReportingSystem General, the Documentation repository did not need to run through all the pipeline tests in Gitlab such as the build, test, or release stages. This means that we only had the linter tests run through the pipeline when committing any changes to this repository.

Merge branch ‘jlee1999/verifying-that-generatewcfbreportfrontend-38’ into ‘main’ (6e5d198e) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / GenerateWCFBReportFrontend · GitLab

GenerateWCFBReportFrontend is different than the other two repositories that I worked on as it does require pipeline tests such as build, test, and release. Originally, the tests were passed with a warning, which was okay at the time, but our goal was to ensure all the tests passed with no warnings.

Files · jlee1999/research-functionality-122 · LibreFoodPantry / Client Solutions / Theas Pantry / GuestInfoSystem / GuestInfoBackend · GitLab

Once I completed the verification related issues in our sprint backlog, I shifted focus on the first steps of hot reloading GuestInfoBackend servers for development mode. First, I researched what the command “nodemon” is and how I can properly integrate it into the code. This command allows for the server to restart after any changes are made in the folders specified prior. I created a separate folder in this branch called “express-example” with a simple JavaScript file as well as the package.json file and any other required files needed. This allowed me to mess around with the functionality of the command without completely rearranging the main branch.

feat: merge branch ‘jlee1999/edit-scripts-to-allow-123’ into ‘main’ (f145cdc1) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / GuestInfoSystem / GuestInfoBackend · GitLab

After messing around with nodemon in the sample branch, I was ready to implement it to the main branch of GuestInfoBackend. I was having trouble making sure the nodemon command works while also ensuring the pipeline tests passed. If I was able to get the pipeline tests to pass then the functionality of nodemon was not working, and if nodemon was working then the pipeline tests would fail. I was struggling trying to figure out why this issue kept occurring, but after a while I was able to get both the functionality to work along with the pipeline tests to pass simultaneously. The cause of this problem was because the repository was using both npm and yarn when building the pipeline tests which caused problems. I decided to stick with strictly npm for the repository which then fixed the issue.

Files · update-checkinventory-29 · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / CheckInventoryFrontend · GitLab

I did not get to work too much on CheckInventoryFrontend this sprint but was able to get a general idea of some issues that could be arising. I noticed that this repository also has both npm and yarn together which has caused some issues with the pipeline tests. Hopefully the next sprint my team and I can solve this issue and provide a simple and working frontend for the InventorySystem.

This was the second sprint for the team, and I believe that it went better this time around compared to the first sprint. I felt more comfortable with the whole set-up of our sprints and the team was able to get the work done we needed to. Around half of the issues this sprint revolved around verifying pipeline tests and extensions in repositories that will help in the future to allow people to focus on bigger parts of the project with more ease. While I worked on 3 of the issues around verifying pipeline tests, our team had 5 overall which made it easy for us to communicate what worked for the other issues. The continued work in Gitpod/Gitlab has gotten me even more comfortable committing changes along with merging branches. There was only one issue that I messed up the commit message when squashing the commits for GuestInfoBackend, but it did not affect the overall functionality of the repository and the pipeline tests were still able to pass.

While I would like to say everything worked out perfectly during this sprint, it would be a lie. There were some small hiccups in progression through this sprint, but I would say it was less severe than the issues holding us back last sprint. I believe the higher level of comfort in the progress helped allow the team to get passed any hiccups. The biggest issue I was running into was during the GuestInfoBackend issue about hot reloading the servers. I touched on it earlier, but the combination of npm and yarn in the repository was causing me the most issues during this sprint, but I was able to solve it before the end of the sprint which was the goal.

Overall, I believe the team can still improve on communications in some respects, but I would say we were all on the same page more often this sprint compared to last. I would make sure I would notify the team in Discord about any issues I was running into or if I needed a review on a merge request, and the team would be able to see it and help continue the progress of the sprint. I did a better job this sprint focusing on one issue at a time rather than trying to work on multiple issues at once.

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.

sprint 2 retrospective

During the course of this sprint, I spent most of my time looking at the ReportingBackend repository to figure out what was going wrong with the testing suite. I also had assigned myself to configuring the pipeline specifically in ReportingAPI with the linters, but unfortunately was unable to complete this issue because the team responsible for actually adding the linters to the repository was not able to push their changes before the sprint ended. I continued to act as the scrum master for the team, taking an active approach to making sure everyone is doing work, getting credit for their work, and setting up meetings when necessary. I had to help out a bit with other team member’s issues as well, providing some guidance.

Verify the Testing Suite works: Investigate the testing suite and see if I can get it to work, or at least figure out the magnitude of the problem. I applied a couple of fixes (one of which was in the build.sh script that I had a separate 0 weight issue created for, as I had already found the bug and fix prior to the sprint starting.), but it seems like the issue transcends the testing suite and is moreso an issue with the build process with the server.

This sprint was pretty rough, if I’m being honest. For what we did well, our communication overall improved, and the team was better able to utilize GitLab for their work. I think that everything on GitLab was better organized and most of the issues had better descriptions on them than what we had last sprint, and the weight assigned to issues seemed fairly accurate all things considered, aside from the testing issue (which I did spend a lot of time on). We also did work with each other more than we did on the last sprint.

Most of the issues that were assigned to our team were rushed together during the last week of the sprint (from my perspective at least, there may have been some confusion with pushing to GitLab). As such, we weren’t able to get to all of the issues, and only got 14 weight out of the 24 weight assigned to our team fully merged in. I was offering support during the whole sprint, but it seemed like team members were not able to coordinate into a meeting at the same time for most of the sprint. I don’t really have a great reasoning for this, it seems like things weren’t being done until the time was very short to were we couldn’t get everything done, taking all of our other schoolwork into account.

Ultimately, I think for next sprint our team really just needs to work on spreading work out during the entire sprint rather than getting things done last minute. We should also work on coordination and being more present, as when anyone asked if we wanted to do a meeting, the team would all say they were available and no one would take the initiative to actually begin the meeting. Part of that is on me as scrum master, but ultimately we should be willing to meet without having everyone on board if we are working on specific issues.

I was able to spread out my work fairly well as an individual, but I can’t say the same for other team members, and so as scrum master I should be more active in making sure everyone is doing their work not just so the project moves forward, but so everyone gets the credit they need for the course.

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.