Category Archives: Blog

Project Management

Source: https://monday.com/blog/project-management/guide-to-project-management/

The title of this blog is “What is Project Management? The Complete Guide [2024].” As seen from the title, this blog obviously describes the ins-and-outs of project management. The idea of project management is to manage projects by ensuring that they are delivered on time, within a set budget, and satisfy the needs of the stakeholders. Project management involves setting goals, scheduling, managing, monitoring, and collaboration. This is accomplished through various methodologies such as Agile, Kanban, or Scrum. This is an important field, and topic, because teams of individuals are the ones who provide the greatest projects and products to the market, and without effective leadership and problem solving, they would never come into fruition. Many different organizations employ project managers, ranging from small businesses to Fortune 500 companies. Project management is not exclusive to software engineering though, it can be seen in other sectors such as construction or marketing. “The Project Management Body of Knowledge (PMBOK Guide) defines ten key project management knowledge areas” them being: scope management, schedule management, procurement management, stakeholder management, risk management, communications management, resource management, quality management, cost management, and integration management. These are all self-explanatory from their names but are very important for being an efficient and effective project manager. There are many different tools used in this field, such as Gantt charts (used for scheduling and tracking tasks in a visual timeline), tasks lists, Kanban boards, calendars, budget trackers, mobile apps, and many others. One might ask if a project is completed and another one is about to be started, is everything created from scratch? The answer is no. Project managers use templates to fill in instructions from prior work to save time when initiating a new project. There are quite a few roles in project management, one being the project manager themself, the project sponsor, the team members, the stakeholders, the customer, the office, and the steering committee (who provides oversight). All of these individuals make the creation of projects operate smoothly.

I chose this particular post about project management because it appeared to be all-encompassing of the topic, and I was correct. After learning about Agile and Scrum methodologies in class, I was interested in learning about the importance of having a project manager in various sized companies. I can appreciate the fact that they have to communicate with stakeholders, engineers, and management in order to ensure smooth operation. Overall this material was very interesting to me because I’ve had an interest in this field for my future career. If I end up pursuing project management, this information would definitely be beneficial for performing my job appropriately. If I don’t, knowing the role of a project manager would be beneficial regardless because I’m bound to work with one regardless. Having an understanding of your coworkers’ roles at your company is important for collaboration. 

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.

GRASP

Source: https://www.youtube.com/watch?v=GcqTrlL_Htw

This video from YouTube is titled “Design Patterns GRASP // Object Oriented Analysis and Design (ICS).” As stated in the title, it goes over the design patterns of GRASP, or General Responsibility Assignment Software Patterns. GRASP is a set of 9 principles that relate to object-oriented design that help developers/engineers assign certain responsibilities to certain variables, classes, objects, etc. in software. The overall purpose of GRASP isn’t to create “fancy” code, but rather to create maintainable and reusable code/software. The 9 principles are information expert, creator, controller, low coupling, high cohesion, polymorphism, pure fabrication, indirection, and protected variations. “Information expert” places responsibility on classes that have the required information to complete it, wanted behaviors and data are put together. “Creator” places responsibility for the creation of instances of classes to classes that would use it. “Controller” places responsibility for handling system events to a class that describes the event, known as the controller. “Low coupling” states that classes should be as independent as they can be from other classes. “High cohesion” states that classes should have clear purposes with responsibilities that relate to it. “Polymorphism” is implemented so new behaviors can be added without changing preexisting code. “Pure fabrication” states that new classes should be created if there isn’t an already existing one that fulfills a desired requirement. “Indirection” states that dependencies among classes should be minimized so changes can be made without having an impact on other parts of the system. Lastly, “protected variations” encourages developers to design the system in a way that variations in behaviors are negated through encapsulation. 

I chose this particular source because we haven’t covered this topic in class yet and it seemed interesting, I found the topic from the syllabus. This video had a low amount of views and I wanted to give it a chance. After watching the video, I appreciated the fact that the information was presented in a straightforward manner and offered visual examples for each of the 9 principles of GRASP. After learning about Agile methodologies, it was interesting to learn about GRASP, because in my opinion it seems as though instead of being a set of principles of workplace improvement, GRASP seems to be a set of principles for actual work improvement. Overall, the material impacted me in a positive way because I appreciate the idea of everything in a system/software having a certain responsibility, and can definitely see how this will benefit me in the future when I work on more projects related to software development. I will certainly keep GRASP in mind for these future projects. 

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.

CS-348

This is my first post for CS-348 Software Process Management.

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.

CS-343

This is my first post for CS-343 Software Construction Design & Architecture.

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.

“NICE” Sprint 3 Retrospective

During our third and final sprint, we had a clear idea about what we wanted to achieve with our application. The first two splits helped create a foundation that allowed for us to propel much faster and efficiently compared to before. After spending the last sprint working on the docker container for our group, I wanted to contribute in a way that would be helpful to the react team. I ended up creating issues for myself that were more in line with the front end side of things that the react team had not really touched upon. I first decided to clean up a lot of the code from the react team, there were a lot of styles that were repetitively used by the team so I managed to implement a style page where certain style could be called upon instead of written out when being applied to something. The next thing I tried to tackle was an interactive page for users to select which kind of test they wanted to practice. This was implemented with a side scroll feature that was imported from the react-native-gesture-handler where I was learning the design parts of how things would look based on the style I would give it. I was also able to take images and icons as well to apply to the home page and menu screen which gave it a much better appearance to the eyes of the user.

As a team I felt as if this sprint all of the puzzle pieces finally came together. The react team was working cohesively together where as the others who did not work with them originally were able to go back and forth with them to push an pull code without being out of sync. The team cohesiveness really brought out the best in one another as were we able to divide issues into more manageable ones and we could really see the final product coming together.

With the docker team finally being able to assist the react team with the application as a whole, we were constantly running the application and testing it, and that led to a lot of discussion of things that needed to be fixed or added to the app. This would lead to us effectively being able to help one another spot mishaps and expedite the results we so eagerly wanted. Although we were not able to produce a functioning writing portion, we were able to create a placeholder for it that was substituted with a input on the they keyboard from the user.

Individually, I felt as though this sprint was one were I pushed myself the most. Maybe it was because the semester was coming to the end or that the application was seeing growth, but although I was lacking in basic knowledge of react native, I wanted to be sure I contributed more to the application and pushed myself to learn more. The only issue that I had with the sprint was that I wish I was able to be part of the react native team prior to this because I know I could have contributed more than what I already have. Seeing how fast I was able to grasp things, maybe I should have stepped up before and take on that challenge because I had a lot of fun during this sprint.

Links: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/57

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/66\

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/58

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/49

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/23

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/52

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/25

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Sprint Review #3

This sprint was the worst one for me. The team did great job, it’s just I, who did not did much job in this sprint. This sprint/weeks of this semester was a roller roaster for me. So many projects to do, presentations, assignments, essays. Every professor was pushing their assignments. I learned a valuable lesson this past weeks and it was a “stick with one capstone my friend”. I took two capstones as I liked both software developing and data analysis. It is not that, I liked one capstone and dislike another one, it is because of the amount of work. I think it is okay to take two capstones if you are taking only 2-3 classes so that you can only focus on capstone classes but a semester with 5 classes, 4 of them are CS courses and each classes having final projects was a hell for me.

As for the sprint, I did not do much work than just cleaning up some code. You can find the commit here. In the console of the browser, there was an warning saying the request to HTTP request may not success every time. So I simply added a try catch to get rid of that annoying warning. So now if we make a bad request to HTTP then the code will console log an error. Another reason I added try catch is that, suppose we were to use this program in real life or real POS or anywhere where this application will be running and if there is a bad request then the application will crash. And nobody would want to restart the application every time. With try catch, the application will console log the error and keep running. That is all I did for the sprint. I did not put much work to the team and I wanted to do more but with tight schedules, I wasn’t able to do much. There was able another error with my device, the docker image kept failing for my MAC while it worked for the other devices of my team mates who had windows. I had that issue until my scrum master told me to add a timeout in the docker file which did fix the issue but then it was pretty late. It was my fault for not talking about it in meeting or in discord group chat. I was responsible for getting in touch with another group about key-cloak but I never had time to.

Final thoughts: Front-end wouldn’t have been success without Michale Friederich. He did all the integration between back-end and front-end. If I were to do that then it would take me longer. So hats off to him. Everyone in the group did an amazing job throughout the semester. I have read everyone’s sprint review blog and they are putting in the work more than me. If it were to be different team mates then I don’t think we would have finish this much of work at the end of the semester as everything was new to us. Everyone in my group had a great vision of what the project should look like at the end and we delivered it about 95% of finished application. The next group who will take over after us will just have to clean up the code, connect with key-cloak etc but it will not be as messy as it was when we first received the application as we had to reformat everything. Overall, I was paired with talented developers and I am glad I paired with them. Happy Coding!

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

The Long Road Pattern

For this week’s apprenticeship pattern, I did a reading on “The Long Road”. The Long Road pattern is about your future. In this pattern it talks about trying to imagine yourself 10 years, 20 years, or even 40 years from now. They want you to think about that and possibly write down a summary of your profession. By doing this, it will enable you to think how you would want your professional path to be like and allows you to plan how things could go. The problem in this pattern is that you want to become an expert in what you want to do however, things may get in the way like that such as promotions and just always picking the highest paying job and by doing this, it takes away the goal you had originally which is to do something that you enjoy doing but instead doing jobs that in reality sucks.

My initial reaction to this, is that it is an interesting pattern to read about. It is interesting because I never thought to look past 5 years into the future and just thinking about the future and where I want to be in general. Obviously, everyone wants to make six figures, but the main goal is to make that much by doing something you love or enjoy doing. After reading this pattern I did take a moment to think about where I would like to be down the road and it made me realize what I really wanted to do with my future. Of course things happen, and the future isn’t exactly set, but it gives me a good idea of what I need to do and what I have to do to accomplish it.

The pattern has changed the way I view my profession because I never thought about needing to take a step back and think about the distance future of where I would like to be. Do I still want to be programming all my life or would I like to do something different by the age of 40? It was an eye opener to me because it really allowed me to set goals that I want to achieve by a certain age. Sure, programming is fun and all but there’s much more to life than sitting around a desk and creating programs and such. I want to create memories that will last a lifetime and explore the world.  If I can find a career that would enable me to do that then that would be the ideal job.

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

Third Sprint Retrospective

Reflection on what worked well and didn’t work well

After meeting for the Sprint Retrospective with my team as a whole, I can say that the project is progressing well. The flow of group work has improved more since everyone works together much more effectively. The front-end and back-end development teams have made significant progress towards the project. The backend is pretty much complete at this point and the frontend is pretty much there besides a few minor things. We don’t have any major programming problems coming off of our last sprint, just a few potential bug fixes and cleaning up to do. Finally, after looking back at what we did, we made it easier to run the servers, since in the last spring we had to run things one at a time, however now it will run all at once, making it more efficient. During this spring we also cleaned up a lot of the coding and did some minor bug fixes. The backend is pretty much completed now besides testing. We just didn’t have enough time for it, it would have been something we would have done if we had another sprint left in the semester.

Reflection on what changes could be made to improve as a team

The team worked great. We still have everyone on their original development team. The ones at the back end remain at the back end and those who worked on the frontend stayed on the frontend team. Both teams for this spring, started to run out of things to do since everything was either completed or almost completed at this point, or there wouldn’t be enough time to work on a new issue. From the way the meeting went, everyone was able to communicate all the problems they had with each other, and no one was afraid to ask if they needed help. For our last sprint, I would say that there was such an improvement comparing to the beginning of the semester. Everyone was comfortable with talking out loud, helping one another, and overall, just great teamwork.

Reflection on what changes could be made to improve as an individual

From my point of view, the sprint was very good. Since we were running out of things to work on the backend, there wasn’t much to do. I worked on changing the port numbers for the backend to be between 10350 to 10399. Help change the datatype for household members. As well as combining docker-compose for the backend. I worked with colleagues Jared and Vien on these issues and other issues that we had on the backend since there wasn’t much left to do for the backend. Same as the Sprint, we were able to continue to learn more from each other. In this final sprint, I would like to say that overall, I became a better programmer/ developer, and this was a great experience to be able to work on large project in a scrum environment. I was able to become more confident in my skills and also became better with communicating with team members.

Combine docker-compose Backend
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/34

Update Household Members Datatype
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/api/-/issues/12

Update Backend Ports
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/36

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

Retreat into Competence Pattern

For this week’s apprenticeship pattern, I did a reading on “Retreat into Competence”. Retreat into Competence pattern about feeling overwhelmed, realizing how little you know about or taking on a big project and things may not be working so well for you. In this pattern it talks about how you should “pull back and then launch forward like a stone from a catapult”. What this means it to retreat to a zone where you’re comfortable with and once you feel ready, you’ll be able to launch yourself even further than before you might have felt ‘stuck’. An example I found from this pattern is pick something that can be self-contained that you know really well and stick with it, by doing this, opportunities will emerge, and it will allow you to capitalize on those opportunities and you will end with great gains.

Unlike my other blog posts, my initial reaction is not quite the same since I have yet to experience this. The closest time I ever felt overwhelmed is just the pressure of trying to find a job by graduation. Its not exactly related to what this pattern talks about but the same concept. For me, it was a matter of constantly getting rejection emails from companies, so I took a step back to look at what I may be missing. Once I was able to go over my resume and qualifications, I started to reapply and now I am starting to receive multiple invitations to take coding assessments and scheduling interview dates. This pattern goes hand to hand with ‘Expose Your Ignorance’ and ‘Confront Your Ignorance’.

The pattern has changed the way I view my profession because I never thought about needing to take a step back in programming. Maybe because I never ran into a situation where I needed to? However, after reading about this pattern I started to reflect on the things I’ve done so far and what else could I do to improve my programming skills and knowledge. I am also trying to figure out what I am really good at so I can focus a little bit more on that skill and work around it so when the time comes and an opportunity presents itself, I will be able to capitalize on it.

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

Apprenticeship Pattern “Retreat Into Competence”

This apprenticeship pattern describes how we should approach difficulties that we encounter along our way of being an apprentice. There will be times when we are working on projects and are faced with difficult challenges that we don’t know if we can overcome, and there are ways to get around this. In the future we will try and expose our ignorance to learn new things, but in doing so we might take on more than we can handle. In doing so, it is okay to take a step and work on something else. Sometimes taking some time away from what you’re struggling on will help you in the long term. It is important that once you take that step back that you then take two steps forward and use that momentum to better yourself. Taking a step back might feel as though you are retreating into failure, but when you work on something you’re comfortable it also adds to your expertise in that area. This then leads to needing to grow as a software engineer and having to learn new things. What we must also remember is to seek support from our mentors and use them to help us become better equipped with handling these situations.

What I’ve taken from this pattern is that taking a step back from what we’re uncomfortable with okay. Sometimes it is okay to go backwards in order for us look back at what we’ve preciously done, then use that to our advantage of progressing forward with our skills. Growth can be looked at from many different views and that’s what we can take from this apprenticeship pattern. There is nothing wrong with facing failure head on, but it’s about how we bounce back that will make us better software engineers.

This pattern has reminded me of experiences I have had in my life. There have been times where I have been put into situations at work where I was required to do work I was unfamiliar with. In doing so, I reverted back to completing work I knew I could do, and once that was done I was then forced to work the things I was not too sure about. In this situation, I then reached out to engineers and other people who could assist me in my work. This then helped me to better understand how to approach this new situation and helped me gain knowledge and experience in completing it later on without the assistance of others.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.