Sprint #3 Retrospective

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/58

The card I created for adding rabbitmq to docker compose

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/backend/-/issues/8

The card I created for adding message sending to the backend

This sprint not much worked well for me, mostly because of outside forces unrelated to the class. I simply was not able to put as much time and effort in as I wanted to. Most of the sprint was spent working on figuring out the messaging system. I was able to send and receive messages locally. What I was not able to do was send messages to other computers. I am pretty sure if I kept working on it I would have gotten it eventually; I found many solutions online that I did not get to try yet. 

That does not mean everything went poorly though. Something that did work well was transitioning between the two teams. This sprint I worked more with the event system so I had to meet with Derin and Rainiery more often. It was really easy to get the team together because discord is made to do that. If we were using zoom for class meetings it would have been a lot more difficult. 

I think my team did well this sprint. Marcos and Tim were able to do a lot of work on the front end and while it did not get where we wanted it to be we still got far. This sprint I think David was able to do a lot really fast and because of that he was able to start working on the integration portions. Cam was a lot like me in that he did a lot of work outside of our system with the IAM team. 

Even though this was our last sprint, there are a lot of things I can do to improve. The improvements may not be for the next sprint (there isn’t one), but they will be things for me to carry into my career. Time management is a huge thing I need to work on. Expecting to be able to do a ton of things all in one day just does not make sense. This sprint and this class really taught me that I can only be productive for a few hours at a time. Anything after that is probably wasted. It’s better to let a bunch of short work sessions add up. I also need to make sure I do a little bit every day. It is more efficient and I forget less if I minimize time in between work sessions. 

As a team, if we were to work together again I would want us to communicate more. I think David and Tim both were looking for more work to do during the sprint. I should have asked them for help with rabbitmq. We could have sent mock messages to each other and probably would have figured out the messaging system a lot faster. When I got stuck I also could have taken a step back and helped out with some other parts of the system, maybe doing something like helping test out the front end. That would have helped me clear my mind but it also would have helped make sure the front end worked for when we demoed it.  

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

Links:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/77

This was about filtering the data for the report.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/74

We were able to get sample data from the other teams as a JSON object and used fake data to download report as csv.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/62

Created a docker container registry and implemented it on gitlab.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/75

Edited backend code so it takes a date and retrieves data based on that date.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/72

Created the backend endpoints to receive the start and end dates from frontend.

The thing that worked well was that we got the system to actually run and get messages from rabbit mq which gets saved in the database to be used to pull the report. We were also able to connect it to the frontend and get a wsu style theme for the website. I think there was a lot that worked well considering this was our last sprint and we could not rely on another sprint add more work.

Some things that did not work well in this sprint was that we did not have as good of time management because there was so many projects for each class so we had to find chunks of the day to work when we can. However, I think our group gets a lot done under pressure and is able to complete a lot more in a few hours nearing the deadline as opposed to those same hours with free time. If we had more time to space things and did not have to worry about many other cs classes, then it would be much easier to focus on making the website as efficient as possible.

A few changes that we could make for future sprints as a team was to keep our eyes on the main goals of the sprint and not on small details. I feel like we were stressing on small aspects of the project when the big important features would have been just better to work on. We were struggling taking so much time to work with docker and get some of its aspects to work, and this took a way from upgrading and making the backend and frontend more efficient. I think next time we would spent as much time from the beginning to get the website up and running and having all the functions work properly for a user, then focus on the small details that won’ t take as much time to figure out in comparison to the bigger parts.

A few changes I could make as an individual is to find a balance with working on my team and working on my own. I feel that I was either working with the team too much or my own most of the time. I think in future it would be a lot more clear what our goals were and what to work on as the sprint went, but for this a lot of the task were things we could work on together and help each other out. I think even with all the factors we were still able to produce efficient work.

Overall, I think this sprint went very well and we got a lot accomplished. In the last week of the sprint we were panicking because of how much other projects we had to from 4 other cs classes and 5 including this class. However, we put our focus 100% on accomplishing everything and looking back we got more than enough done. It was very helpful to work in a team where we would help each other out and make brainstorming and planning a lot more easier. I think this sprint and this class in general will help us out in our future endeavors especially in the work field. A lot of the planning is what helped us out and our website was able to run which was very helpful for us to know that we did it. I’ll appreciate everything that I learned these past 4 years and from every professor and good luck to everyone on their future goals.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

 Links to evidence of activity on GitLab.

This is my frontend user interface for the report team

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend

I updated my frontend from sprint 2 in my local service which I used the sample frontend example from the professor. I have changed the background and move the start date and end date in the middle same as the common website let the user input the login information. 

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

Austin and I connected the backend API to my frontend API, which can let customers download the report for the inventory. It got succeed download the report for the inventory when we connect the API together.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/35

My frontend design idea is based on the Worcester State University style of design. For the background picture and the color use, I followed the handbook of WSU style of design.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/67

I implemented FrontEnd for reporting with the most recent version.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/55

We Made some OpenAPI.yaml files for our FrontEnd and BackEnd.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/66

We looked over TheasPantryReport.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/71

We looked at the new architecture and plan accordingly.

Reflection on what worked well?

In Sprint 3, in terms of what worked well, the second phase was more efficient when team members worked together than ever before in completing the project plan. After a semester of teamwork, we have a deeper understanding of our ultimate goal and become more accustomed to each other’s habits. There will be a relaxed working atmosphere, and the team chemistry will encourage each other to push the project forward. The project progressed more smoothly, and the ZOOM meetings of the team were relatively frequent.

Reflection on what didn’t work well?

As for why it didn’t work out, there is a longer-term vision of the end product and the project’s future goals. Unfortunately, we failed to get the data of other groups. We made test data to run our report program. In addition, the team members were busy with other courses at the end of the semester, so there were some deficiencies in the adjustment of time in the later period. We had some confusion in the front end and back end docking. Through learning external materials and teamwork, we successfully solved the docking problem. Fortunately, we made timely adjustments and promoted the project objectives, and completed the group project.

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

As a team with cooperation, smooth communication, and tacit understanding among team members are the basis and key to improving our team’s cooperation level. We would discuss the project after class and give some constructive suggestions about each other’s tasks. Good communication makes our team have chemistry. Through communication and cooperation, we have a thorough understanding of the team members’ tasks. Each knew the other’s project progress would be conducive to the overall advancement of the project. When a team member encounters a bottleneck in a task, we will appropriately slow down the overall progress and communicate with him to buffer his time to complete and push forward the overall task progress.

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

As an individual, I have watched and learned a lot about front-end production after class. It improves my front-end understanding and production skills, which helps my team better connect the front-end to the back-end. In this project, I learned and improved some problems encountered in team cooperation and realized the power of the team in finding and solving problems. In a team, the mutual understanding and tacit understanding among team members is the basic condition for the smooth operation of a team. It was a great honor for me to meet every team member in my last year of university, and I learned a lot of valuable experience from them in ZOOM meetings. At the same time, I am also very grateful to the professor for giving us an opportunity for a big team project, which benefited me greatly. I believe that I will bring my learning experience to my team in future team cooperation projects. Finally, I’d like to thank Worcester State University. It’s my great honor to be a member of the computer major.

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem

Here is the Link to the repositories that contains everything we worked on Sprint-3. Backend, Frontend, Event system, and Keycloak.

Connect RabbitMQ receive file to DB: Connected the MongoDB database on the received file.

Implement Event System components: Implemented RabbitMq components for Event System.

Meet with other Event System Teams.: Met with other teams to finalize everything about messages.

New TheasPantryReport: The new Theas Pantry Report

Create two channels for both teams: Created two channels for both teams on the send and receive files.

 

For this Sprint, I worked mainly with Austin on the backend components such as implanting the rabbbitMQ, making API, and trying to get out system working.

What worked well / did not work well

For this sprint, what worked best was that we got our reporting system functioning. We have a system where the Rabbitmq receives the message from the queue and saves it in a database. From there the backend takes the data and converts it into a CSV so when the Frontend requests for a report the backend can send that CSV file to the user. One of the key things that I noticed that our group works well under pressure. We are always calm and composed. I don’t think there is something that did not work well, however, we should have managed our time wisely since the end of the semester was filled with many assignments.

What changes could be made to improve as a team?

As a team, this was our final sprint for the semester. In the future, if we work on this, I think it Is important to use the time wisely as we were up on zoom every night to make little progress towards the project. Also, whenever we had a question, we should have posted more on the issue board or could have asked the professor for more help but as a team, I’m so proud and happy with the way everything turned out towards the end.

 What changes could be made to improve as an Individual?

As an Individual, I should be communicating with my team more rather than just doing the issues that are assigned to me. I should try to manage my time wisely too. The end of the semester was a struggle since there were exams and projects from every class. I believe that we could have made our system more efficient and functional, but it turns out to be what I imagined from the starting. Working together as a team doing one task at a time was efficient for me and as a group.

Overall, this was a great learning experience. I will never forget this class or the reporting team. It was a pleasure working with amazing teammates who pushed me to move forward whenever I was struggling on an issue. I hope that the experience I got from the capstone will be a highlight for my future career in the field of technology. I wish all of you the best of luck and congrats on your graduation. Hopefully one day we can look back and enjoy these moments.  

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog – Retreat into Competence

For the last and final blog post in my capstone class, I focused on the apprenticeship pattern of “Retreat into Competence” from chapter two of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section talked about perhaps how you are overwhelmed or beginning to realize how little you know, or perhaps you have taken on a new challenge and things are not working out so well. However, getting back into something you are good at is a nice way of regaining your composure. I completely agree with this statement, sometimes all we need a just a pullback to launch forward towards the goal. The quote provided at the beginning of the section is what stood out to me the most. It states that “You look at where you’re going and where you are and it never makes sense, but then you look back at where you’ve been, and a pattern seems to emerge. And if you project forward from that pattern, then sometimes you can come up with something.” This got me thinking very deeply about the past four years of college and my CS Journey. I have no idea what the future hold, but one day I will look back to see where I have been and possibly see a pattern emerge.

The author also mentioned how apprenticeship is a roller-coaster ride, you will experience the thrill of new technologies, but you will also experience struggles as just how little you know compared to the craftsmen and experts you meet along the way. It is important that Sometimes you need to take one step back to take two steps forward. But it is essential to move forwards as quickly as possible because the forward momentum is revealed in your possession of more knowledge and greater skill than you had yesterday. Another important aspect the author mentioned is how to seek support from your mentors, with their support and boost you can be on the right track again and display competence. In this way, you will be more equipped for future challenges. The patterns displayed a lot of insights towards my career and on a personal level. I will certainly be reading more patterns from this book even though this is my last and final blog post for the CS-448 class.

 

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

Like the second sprint, our team focused on developing the frontends, backend, and keycloak of the inventory system for the third sprint. I mostly continued work on the backend API and the Event System components. For the Event System, I specified what data has to be sent to the Reporting System. When adding inventory, the weight and the ID, which are integer and string values respectively, have to be sent. When removing inventory, the weight and the donor’s name, which are also integer and string values respectively, have to be sent. I also added a subsystem folder to the backend and inserted a basic JavaScript file called “send.js”. I’m pretty sure that Matt even added the code for one of the backend functions into the subsystem directory. I needed to edit “send.js” so that it could send the correct information but I ran out of time. For the API, I feel that I did all that I could considering I wasn’t able to test it with docker, either locally or with the docker-compose.yaml file. I was able to add Weight, ID, and Donor to the schema and finish the API code for the getInventory, removeInventory, and addInventory methods. I also added an unauthorized 401 response for each of the three methods for token authorization. However, I wasn’t able to fully implement token authorization to the API since Mike wasn’t able to finish work on the tokens.

This sprint, I feel, was messier than the last two since our team was mainly trying to finish up what we had leftover form sprint two and do whatever we could before the end of the semester. It feels like that lack of direction was one of the factors that affected the rate at which I performed my tasks. I already mentioned what I did during the sprint which I think isn’t really nearly enough of what I wanted to do. I wanted to finish up what I had leftover from last sprint in a week or two and completely focus on the event system and maybe help out on the backend functions. What ate up most of my time was trying to test the API with docker which I wasn’t even able to do in the end. And I couldn’t even take advantage of the extended deadline since most of my finals were on the week following the new due date. I was only able to make the subdirectory and the basic send.js file during that time span. What I’d want to improve on as a team is to set a clear goal since I feel that was one of the factors on why I think I wasn’t able to do as much as I wanted to similar to what I said last retrospective. As an individual, I really need to brush up on docker since I couldn’t test the backend correctly even though I based it on the stoney-manage-items example on GitLab. I couldn’t even get the example itself to run on docker either, neither locally or with the docker-compose.yaml file.

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

Use the Source Luke – Apprenticeship Pattern

In this post I will be discussing the apprenticeship pattern, “Use the Source” written by Adewale Oshineye and Dave Hoover in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, 2009. This pattern is for people who have not developed in environments that have stressed the importance of the ability to read source code. Developers often spend much more time reading source code than actually writing it. Often times developers cannot understand the code and have to rewrite it themselves. As stated in the book, Bill Gates once said, “one of the finest tests of programming ability is to hand the programmer about 30 pages of code and see how quickly he can read through it and understand it”. People who can absorb design patterns, algorithms and data structures through real code become great programmers because they are learning from every good programmer each line at a time.

The authors suggest picking an algorithmically sophisticated open source project and take note of the algorithms, data structures, and design decisions made in the code that are new to you. Then, write a blog post for each new idea you learned. While doing this, download the lates version of the project and try to work out why the developers made certain decisions in the design and architecture and try to work out ways you would have done it. Figure out if your way wouldn’t work or would actually be a better solution. This will cause you to think deeper about the reason the project is coded the way it is.

I found this design pattern very interesting because I would agree that the ability to read code is very important and my lack of experience doing so has caused me lots of problems in the past. Often times I have had to rewrite code I was not able to understand or attempt multiple times to understand a piece of source code before finally getting it. I would say that I have improved, but there is still lots of room for improvement in the future. I like the idea of examining open source projects and I think I will do so very soon.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Be The Worst

The section “Be The Worst”, found in chapter four in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye focuses on situations where you aren’t able to learn much from your environment. Being on a strong team has its benefits, other members can cover areas where you are weak on and catch you before making mistakes among other things. Ideally, a team member should be able to take a step back from their team to accurately assess their skill and knowledge. In the case where the gap in skill or knowledge between yourself and other team members in vastly in your favor, then it’s likely that you won’t be able to grow much as a software developer. Because of this, it’s best to start out as the weakest member of a team, hence “Be The Worst”, in order to have room to learn and grow. Emphasis on “start out”; the weaker members of a team should work more to catch up to the rest of their teams. If they don’t bother, then the “Be The Worst” pattern kind of loses its whole point.

Fortunately, or unfortunately depending on how you look at it, I’ve never felt that I was the strongest in a team skill wise. Some of the people I’ve worked with on a team do things super quickly so I had to adapt by starting tasks early and refamiliarizing myself with certain concepts. I guess you could consider that a method of catching up with other team members. In a team setting, I don’t actively try to “Be The Worst” but I at the very least understand why it’s a pattern. If people aren’t challenged, then they’re tempted to stagnate and it becomes all too easy to end up as a big fish in a small pond. When someone better inevitably comes along, then those who’ve done nothing to improve are thrown for a loop and can’t easily adapt to that change. Though, people could also be motivated to do the opposite; work catch up or even surpass their peers in order to not be seen as the weak link.

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

The Deep End – Apprenticeship Pattern

In this post, I will be writing about “The Deep End” apprenticeship pattern from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover, 2009. This apprenticeship pattern is for software craftsmen who feel that they need more experience and need to be challenged by complex problems and bigger projects. This pattern suggests that these people jump in at the deep end and just go for these challenges.

Waiting until you’re ready for too long can turn into never taking that next step and therefor never moving ahead. Rather than a plateau where you are consolidating your skills, you can end up in a rut where your lack of growth turns into mediocrity. This book suggests when offered a high-profile role, difficult problem, or large project, accept these offers. Even if you don’t feel ready, there is a reason these opportunities are available to you and you should take these opportunities and hold on tight. As the authors stated, “risks are opportunities seen through half shut eyes of fear”. Growth can only happen when you take on scary, challenging jobs. This does not mean lying to get a job you cannot do or not prepared for as you will definitely be in over your head. It means taking the opportunities as they are presented to you.

An action suggested by the authors to help you get started with this pattern is to think about your biggest most challenging projects. Write down the complexities of these projects as a reference for your new projects. Answer questions such as “what is the biggest codebase you have ever built on your own?” and “what is the biggest, most successful project you have ever worked on?” in terms of number of developers and size of the project. Find a certain way to use these questions on all of your past projects to use them as a metric or index and write it down. This will help you gauge where your next projects fall compared to you past ones. Using this chart or diagram will help you figure out which way your career is going and whether you are growing as a developer.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Breakable Toys – Apprenticeship Pattern

The “Breakable Toys” apprenticeship pattern, written by Adewale Oshineye and Dave Hoover in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, 2009, is about creating projects on your own in order to learn from them. Experience is more often built through failure than success.

Sometimes, in the workplace, it is not acceptable to fail when people are depending on you. This places a pause on your learning. As the book explained, 3-ball jugglers will not be able to step up to juggling 5-balls without trying and failing first. Only the jugglers who keep trying and failing will be able to move up to juggling 5. This is the same with software development and why the authors recommend you make “breakable toys”. This means creating your own projects on your own time that are fun to work on. During the development of these projects you can fail and not hurt or let anyone down. This allows you to grow and improve your skills.

The authors recommend building a wiki as it helps you “record what you learn” (see my other post) and also teaches you a deeper understanding of web development such as HTTP, REST, data migration and concurrency. This is a great way to learn about web environments. It recommends starting small with just an interface, then as your skills improve you can experiment with things such as tagging and ranking algorithms. Another recommendation is to build a new game every time you learn a new language. These are simple games such as tic-tac-to, Tetris, or Snake. This will help solidify your knowledge of the new language. These projects are meant to be low risk to allow room for failure, and also to be fun. If it is not fun, another project will gain your attention and the one you are currently working on is going to gain dust.

The main point of this pattern is to create opportunities to venture outside your boundaries. If you are stuck only doing what you know then you wont learn anything new. When learning something new, often times you will fail. It is the best/only way to really learn.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.