Category Archives: CS-448

Blog #5

The pattern I read for this week was “Use Your Title”. It was about how to not let your job title at work affect how you work, and continue working as hard as you would if your title was something lower. I really enjoyed this pattern as I have never had this problem, but actually the opposite. I don’t let it get to my head because I always feel undeserving of what I get. I always feel like I can do better, and that I am no different from everyone else. It was interesting to read about how titles can have the opposite effect on people as well though.

This pattern taught me that titles do not matter, and whatever your title is, you should strive to be the very best that you can be. It has not changed the way I think as I never let a title get to my head, but it has caused me to think about others that I know this affects, and how this could really be of help to them. I think I should change the way I think that I am not deserving of what I get though, as I constantly work for what I get, and deserve everything that I have worked for. It isn’t like I am just doing nothing, and putting no work in at all. 

There was nothing that I particularly disagreed with in the pattern. In fact, I agreed with everything that was stated in it. Titles should never get to people’s heads, and they should not make you work any less hard. It is fine to be happy about your new title as you have worked hard for it, but you must know that I can change and go at any moment. To continue rising, you must continue putting in the work, and strive for even more. You should not get lazy and complacent of where you are right now. I think this pattern does not just apply to software craftsmanship, but everything. Everyone should read this pattern, as the issue of titles can be seen in every work area, and there will always be someone that lets it get to their head.

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

Blog #4

The pattern I read for this week was “Nurture Your Passion”. It was about how to keep your passion for software craftsmanship, while also letting it grow at the same time. It lists many ways to grow your passion from working on what you like to seeking out kindred spirits. I really enjoyed reading this pattern because passion for your job is something we all seek our entire lives. I went through all the pain and struggles all the way through college for a chance to get a job I am passionate about. Once you get the job though, you need to be able to keep that passion for your entire life, and even grow it into something more.

This pattern taught me many different ways to grow my passion for software craftsmanship. My favorite was studying the classics as I hadn’t really thought about it. That allowed me to change the way I think, and I am thinking about reading some books made by software developers of the past to learn from their passions. The way to a brighter future is by studying the past, so I should use the words of past software developers to help myself and improve myself. I thought the tip about seeking out kindred spirits is great too. You should try to find different people with similar passions as you, so you both can help each other grow, and keep what you are doing from getting boring. The more people that can help you grow your passions and help you learn, the better off you will be.

There was nothing that I particularly disagreed with in this pattern. I thought it did a good job giving different ways to grow your passions, and great reasons why it is important to do. Without growing your passions, it will soon leave you unpassionate, and lead to a decrease in your work. Passion that is ever growing for what you are going to be spending the rest of your life doing is extremely important, and it is necessary to have. I think everyone should read this pattern because it can be applied to everything, not just software craftsmanship.

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

Be the Worst

This apprenticeship pattern discusses the risk of finding yourself the strongest member within your team, and stunting your learning possibilities. To be the worst means to always surround yourself with developers who are stronger than you whenever possible. This can continue to encourage your learning growth, and make you realize you are capable of things you did not know you could achieve. While there are many positive to being the weakest member in a team, there are also many risks. A high performance team will most likely expect you to be able to keep up with them when they are working full blast, and if you do not have the knowledge or skills available to consistently keep up with their pace, you run the risk of getting fired or kicked off the team. There is also the risk of ruining your confidence level. For example, if you were the best developer in your old team or job, and suddenly get thrown into an environment to where you are simply not the best anymore, it can be damaging to your self confidence, which can then decrease motivation and the drive to learn and achieve new things. To accomplish “being the worst”, it is good to make a list of all the developing teams that you are aware of, and rank them based on their skill level. Then identify who is accepting new members who want to advance in their skill set. This process would require looking at different departments than the one you are currently in, as well as different companies. It is always wise to keep your mind open to new opportunities when compiling these lists. It would be a good benefit as well to join mailing lists or other services that will keep you updated on new positions available.

In my experience, I have always felt I was not the strongest developer in no matter what team I found myself in. I always felt that there was at least a single person who way beyond my performance. Instead of letting this drag me down however, I followed closely to what the stronger individual was doing and how they operated in order to learn more and increase my skill. I always did my best to learn on my own when I needed to so I would not drag the team down. I felt that I was not just merely a passenger on the team, and I was bringing valuable information and skills towards the projects we were completing. In some aspects, I actually was the most proficient in a certain task and I did not even realize it, and that could be contributed to having been surround by such strong developers in my past. It is important to keep advancing your learning so that you are able to perform and produce the best quality products for customers, and surrounding yourself with individuals who are a higher skill level than you will increase your chances of becoming the best in your group, restarting the cycle and starting back at looking to become the worst.

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

Sprint-3 Retrospective

Going into Sprint 3, we completed a majority of the issues that we wanted to get out of the way except for backend testing. We had already put in a lot of time and effort trying to get the test-runner to work but it was still facing some issues. 

It was having some issues running on other computers and sometimes the test would fail because it would start too early for the backend server thus we had to implement a way to delay the test-runner container so that the backend server could finish processing.

Despite the goal of the sprint is to clean up any loose ends, it was still important for us to finish any issues started and close off any issues that we couldn’t get to. Stepping back from backend testing I decided that it was best for me to finish the “Set up GuestInfoIntegration” Epic this meant I had to:

After getting those finished it was time for me to get back to working on some testing. The test-runner was still having issues, and it was difficult for me to find a solution so that the test-runner script wouldn’t start too early while the backed server was loading, but eventually, the team thought it was best for both docker-compose files to be put together. Doing this, I can insert a health check on the test-runner container so that it can check if the backend or the Mongodb was completed before running. Before we had inserted a “sleep” right between the docker-compose running the backend server and the docker-compose running the test-runner container. This was in the test. sh. I decided to work on some tests as well, In the test-runner remote branch that we merged in the main, I made sure that the test will return the right status code and error messages. It’s worth noting that the test was implemented when working on the issue “Add HTTP request testing using npm test script”. But have been revised in the test-runner branch to better fit our designs list on the issues below:

The listed issues also have been designed so that when the next group picks up the project then they will be able to see what we as a team were planning when looking at our test.

The test-runner merge is also modified to work with the pipeline and the test stage will react if something is wrong with the test. 

When it comes to clean-up we went ahead and finished up all the issues that were working and closed off any other issues that weren’t going to get into. Any branches that were left over have been deleted and merged and all the finished epics are closed off while the unfinished ones have been moved to open.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Retrospective Blog #3

The third sprint was the shortest, but I feel like it led to some of our best work. I only worked on one issue this sprint, as we had less weight than the others. The issue was to create the test.sh file, which was being continued from the last sprint. The issue got completed with the help of Scott and Moses to clean up the queue, and the link can be found below. This blog will go over my retrospective thoughts now that the final sprint is complete.

There were many things that went well throughout the final sprint. One thing that went well was our communication. Our team has had this positive throughout all of the sprints, and it continued here. We talked to each other all the time whether on Discord or by call. Another positive for our group was how we never deterred from the goal, and from the very beginning, we were determined to finish this sprint strong. This sprint more than the others, I feel like we knew what to do and immediately got to work. The experience surely helped with that.

There were also some other aspects of the sprint that I think we can still get better at in the future. One thing that I think we can still improve on is our weights as a lot of these issues we worked on were carry-ons from the last sprint. We can still improve on that, but I think we got better throughout the semester. Another aspect that I think we can still improve on is our experience. We did not have experience with short sprints like this one, and so I feel like that put a lot of stress on us that would go away with more short sprints. The more experience we get with shorter sprints will only make us better.

There were also some things that I feel that I personally can improve on. One thing was that I was sick for most of the sprint, so I was not able to put in the work that I wanted at times. I know that being sick is uncontrollable, but I wish I would have helped more than I did. That is the great part about a group though, as everyone helped me through that time. Another thing that I could improve on is my knowledge of software development. I do not think that I had zero knowledge, but I feel like I can always get better. The more I can learn, and the more experience I get, the better I will get at this in the future.

With this third sprint over, all the sprints have finished. I really enjoyed working through all three sprints, and I am thankful for the experience this has given me. In the beginning, I was really worried about how this would all go, and I can safely say that I do not regret a single day throughout all three sprints. I love the group that I was assigned to, and I think we did a great job teaching each other aspects of the work we did not know. I feel like we all made each other better, and that is all you can ask for.

Issue Links

  1. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/48

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

Sprint 3 Retrospective

Greetings readers, and a warm welcome to final sprint blog! As we find ourselves drawing near to the end of this semester, it is an opportune moment to embark on a thoughtful reflection of the path we have done throughout the three sprints and revel in the remarkable accomplishments of our team. Through tireless collaboration and concerted efforts, we have truly excelled, leaving an indelible mark on this semester. It fills me with great pride to acknowledge the incredible work we have accomplished together, making this academic period truly exceptional.

Sprint 1 served as a foundation for us to understand how things work and familiarize ourselves with the project. We spent time getting to know the intricacies of the task at hand, gathering information, and learning the necessary skills to tackle the challenges ahead. Building upon our initial knowledge, we dove into sprint 2 with enthusiasm and determination. This sprint allowed us to make significant progress, and we were able to complete most of the assigned work. It was a time of productivity and accomplishment, as we applied our newly acquired skills and worked seamlessly as a team. However, sprint 3 presented us with a different set of circumstances. Although we didn’t have as much work to do, the time allotted for this sprint was relatively short. Nonetheless, we utilized this time effectively by focusing on specific tasks. Our primary objectives during this sprint were to fix pipelines, implement automated testing, and tidy up any loose ends from the previous work completed throughout the semester. We dedicated our efforts to ensuring that issues were resolved promptly and documented carefully. We paid close attention to detail, understanding the importance of thorough documentation. Additionally, we took the opportunity to refine our unit tests and incorporate any necessary conditions or improvements during the final sprint.

As we approach the end of the semester, I am currently working on the final presentation. As this sprint was relatively shorter than the last two, we were mostly able to just clean up the codes mostly and get this organized. Looking back as a whole, I am genuinely impressed and satisfied with how much we have accomplished as a team. Our collaborative spirit, combined with our hard work, has brought us this far, and I am confident that our final presentation will reflect the excellence we have demonstrated throughout the semester. Let’s take a moment to acknowledge the growth we have experienced individually and as a team. We have not only expanded our technical knowledge but also honed our communication and teamwork skills. I am proud to be a part of this incredible group, and I look forward to showcasing our accomplishments during the final presentation. As we conclude this semester, let’s celebrate the milestones we have achieved and the lessons we have learned. I am grateful for the opportunity to work alongside such talented individuals, and I am confident that our future endeavors will be equally successful. Together, we have proven that teamwork, dedication, and a shared vision can lead to remarkable outcomes.

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

Sprint 3 Retrospective

 Hello and welcome to my last sprint retrospective blog post for CS-448, my capstone class. 

This sprint was a lot less shorter and was more focused on sprint cleanup. Luckily, our team cleaned up pretty well at the end of each sprint so there was not much cleanup left. Instead, we decided to keep working on creating tests for the backend and get the test-runner branch working. Instead of branching out and having everyone writing separate tests, we decided to come together and figure out how to write one test which was a great decision. In the end with some help from Team 1, we ended up getting 2 tests working in the end.

Links to issues:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/60. 

For this issue, we fixed a bug where GET inventory was returning an id value instead of a number.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/52. 

For this issue, we created the manual addInventory test for the addInventory endpoint.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/59. 

For this issue, we created the addInventory test in chai.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/53. 

For this issue, we created both the manual test and the chai test for the getAPIVersion endpoint.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventoryapi/-/issues/8. 

For this issue, we reviewed the current API as well as checked and made sure if everything was correct.

For what worked well, our cross-team communication worked really well this sprint. We would ask Team 1 questions and they were more than happy to answer any questions and help us with our tests. Our scrum master worked together with Team 1 to create a working test-runner branch. Communication between team members has improved a lot. We were all viewing the code together expressing ideas on what to add to make the tests work. We also made sure any guesses on what may be the problem were checked to hopefully get the tests running. In the end, the test runner branch and 2 tests were working.

For what did not work well this sprint, I cannot think of anything that did not work well since we all communicated well. I also cannot think of anything that the team could do to improve since we worked together more this sprint. I guess one thing I could have done better was to work on it more at home like how committed Team 1 worked on their issues.

For any improvements I could have done as an individual, the first thing I could improve on would be to read up on more of the Chai plugins. A plugin that I have not read up on may have made writing the tests easier and more efficient. It was also near the end of the semester and I was juggling a bunch of other assignments, so it was difficult to have enough time to complete issues at home. So a second thing to improve on would be my time management skills.

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

Sprint 3 Retrospective

 Hello and welcome to my last sprint retrospective blog post for CS-448, my capstone class. 

This sprint was a lot less shorter and was more focused on sprint cleanup. Luckily, our team cleaned up pretty well at the end of each sprint so there was not much cleanup left. Instead, we decided to keep working on creating tests for the backend and get the test-runner branch working. Instead of branching out and having everyone writing separate tests, we decided to come together and figure out how to write one test which was a great decision. In the end with some help from Team 1, we ended up getting 2 tests working in the end.

Links to issues:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/60. 

For this issue, we fixed a bug where GET inventory was returning an id value instead of a number.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/52. 

For this issue, we created the manual addInventory test for the addInventory endpoint.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/59. 

For this issue, we created the addInventory test in chai.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/53. 

For this issue, we created both the manual test and the chai test for the getAPIVersion endpoint.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventoryapi/-/issues/8. 

For this issue, we reviewed the current API as well as checked and made sure if everything was correct.

For what worked well, our cross-team communication worked really well this sprint. We would ask Team 1 questions and they were more than happy to answer any questions and help us with our tests. Our scrum master worked together with Team 1 to create a working test-runner branch. Communication between team members has improved a lot. We were all viewing the code together expressing ideas on what to add to make the tests work. We also made sure any guesses on what may be the problem were checked to hopefully get the tests running. In the end, the test runner branch and 2 tests were working.

For what did not work well this sprint, I cannot think of anything that did not work well since we all communicated well. I also cannot think of anything that the team could do to improve since we worked together more this sprint. I guess one thing I could have done better was to work on it more at home like how committed Team 1 worked on their issues.

For any improvements I could have done as an individual, the first thing I could improve on would be to read up on more of the Chai plugins. A plugin that I have not read up on may have made writing the tests easier and more efficient. It was also near the end of the semester and I was juggling a bunch of other assignments, so it was difficult to have enough time to complete issues at home. So a second thing to improve on would be my time management skills.

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

Sprint 3 Retrospective

 Hello and welcome to my last sprint retrospective blog post for CS-448, my capstone class. 

This sprint was a lot less shorter and was more focused on sprint cleanup. Luckily, our team cleaned up pretty well at the end of each sprint so there was not much cleanup left. Instead, we decided to keep working on creating tests for the backend and get the test-runner branch working. Instead of branching out and having everyone writing separate tests, we decided to come together and figure out how to write one test which was a great decision. In the end with some help from Team 1, we ended up getting 2 tests working in the end.

Links to issues:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/60. 

For this issue, we fixed a bug where GET inventory was returning an id value instead of a number.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/52. 

For this issue, we created the manual addInventory test for the addInventory endpoint.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/59. 

For this issue, we created the addInventory test in chai.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/53. 

For this issue, we created both the manual test and the chai test for the getAPIVersion endpoint.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventoryapi/-/issues/8. 

For this issue, we reviewed the current API as well as checked and made sure if everything was correct.

For what worked well, our cross-team communication worked really well this sprint. We would ask Team 1 questions and they were more than happy to answer any questions and help us with our tests. Our scrum master worked together with Team 1 to create a working test-runner branch. Communication between team members has improved a lot. We were all viewing the code together expressing ideas on what to add to make the tests work. We also made sure any guesses on what may be the problem were checked to hopefully get the tests running. In the end, the test runner branch and 2 tests were working.

For what did not work well this sprint, I cannot think of anything that did not work well since we all communicated well. I also cannot think of anything that the team could do to improve since we worked together more this sprint. I guess one thing I could have done better was to work on it more at home like how committed Team 1 worked on their issues.

For any improvements I could have done as an individual, the first thing I could improve on would be to read up on more of the Chai plugins. A plugin that I have not read up on may have made writing the tests easier and more efficient. It was also near the end of the semester and I was juggling a bunch of other assignments, so it was difficult to have enough time to complete issues at home. So a second thing to improve on would be my time management skills.

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

Sprint 3 Retrospective

 Hello and welcome to my last sprint retrospective blog post for CS-448, my capstone class. 

This sprint was a lot less shorter and was more focused on sprint cleanup. Luckily, our team cleaned up pretty well at the end of each sprint so there was not much cleanup left. Instead, we decided to keep working on creating tests for the backend and get the test-runner branch working. Instead of branching out and having everyone writing separate tests, we decided to come together and figure out how to write one test which was a great decision. In the end with some help from Team 1, we ended up getting 2 tests working in the end.

Links to issues:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/60. 

For this issue, we fixed a bug where GET inventory was returning an id value instead of a number.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/52. 

For this issue, we created the manual addInventory test for the addInventory endpoint.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/59. 

For this issue, we created the addInventory test in chai.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/53. 

For this issue, we created both the manual test and the chai test for the getAPIVersion endpoint.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventoryapi/-/issues/8. 

For this issue, we reviewed the current API as well as checked and made sure if everything was correct.

For what worked well, our cross-team communication worked really well this sprint. We would ask Team 1 questions and they were more than happy to answer any questions and help us with our tests. Our scrum master worked together with Team 1 to create a working test-runner branch. Communication between team members has improved a lot. We were all viewing the code together expressing ideas on what to add to make the tests work. We also made sure any guesses on what may be the problem were checked to hopefully get the tests running. In the end, the test runner branch and 2 tests were working.

For what did not work well this sprint, I cannot think of anything that did not work well since we all communicated well. I also cannot think of anything that the team could do to improve since we worked together more this sprint. I guess one thing I could have done better was to work on it more at home like how committed Team 1 worked on their issues.

For any improvements I could have done as an individual, the first thing I could improve on would be to read up on more of the Chai plugins. A plugin that I have not read up on may have made writing the tests easier and more efficient. It was also near the end of the semester and I was juggling a bunch of other assignments, so it was difficult to have enough time to complete issues at home. So a second thing to improve on would be my time management skills.

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