Project2 Retrospective - 220103JavaFS/standup-amplifire-mamba GitHub Wiki

Ivo: I did not do a great job with my Project 2, just like I did not with Project 1. Four days before the project delivery deadline I hadn't done any work on it. Then Bobby came up with the idea for a Quizz Master section. I started work on Saturday afternoon and lost 6 hours trying to figure out how to work with dynamic forms as I wanted to create a functionality for flexible number of participants. I failed in that and as time was slipping away I just wrote the simplest possible solution with a fixed number of participants. I am very sorry I didn't have the time to try and learn how to implement a functionality with multiple users, logged in and playing at the same time. Thus I never got the chance to experiment working with Spring in the backend (yet another gap on my record). My end product had a bug - the way I had written the code for the Observable, receiving data from the API resulted in variables being called before the result had been recieved in the Observable. The first request to the API always rpoduced an error and after that the app was running okay. Zach was able to figure this out literraly 5 minutes before we started our presentation. He just suggested moving the assignment of values from the JSON into the lambda function of the Observable. Tim, if you are reading this please give Zach some bonus points.

Bobby: Overall I think the project went very well and we worked pretty well together as a team. There were a few rocky moments in the beginning where we had some people unknowingly work on the same pieces of code, but this ended up being a good thing in the long run. It made us take a better look at how we set up our Kanban board and who was going to be responsible for which tasks, so it was a lesson well learned. In hindsight we probably could've done a better job at applying test driven development (most of our tests were written towards the end of development after business logic was applied already) but I think in the beginning we were so unsure about who should be doing what, that writing unit tests just weren't on our minds, and then we just needed to play catchup a little and testing fell towards the wayside a bit. I also think that overall, everyone in the group got better at using Git and Github. Towards the beginning of the project there wasn't a whole lot of pushing and pulling to the main repo (with people implementing features on their own branches) I think in part due to a fear of messing something up. As we got more comfortable though there was less fear about "messing up the repo" and commits and pushes became more frequent. Also, don't listen to Ivo up above, he did a fine job of implementing the Quiz Master component.

Mahad: Initially, trying to figure out where to begin the project was a challenge. Finding a FREE public REST API that was actually usable was also a challenge. Even the Jservice API that we had decided on had it's own flaws such as missing data in fields and not enough data in other fields. Although, figuring out how to manipulate the API was one of my biggest challenges for this project. I began to work with the API to grab data and hold it within variables, but there were just so many factors when pulling data from an unfinished API. Thereafter, I seen that Zach and Bobby had a better grasp on it, so they kindly broke it down for me. I then decided to take care of the "Register" and "Update-User" components. Structuring and routing them were no problem and I had looked back at previous exercises to implement the logic for the register component. Bobby had some good ideas about the register component such as user validation and field manipulation. As always, Bobby teaches me a great deal when I work with him and this component was no exception. Thereafter, I moved to the "Update-User" component which I had no issues with structuring. I actually had a better grasp on this component since Bobby had given me a major assist with the register component, but for some reason the html would return as a blank page with my current logic. This issue was killing me because I couldn't figure out the issue and I didn't want to refer to anyone, as I was trying to impress my group my completing everything on my own. This was my mistake and I had let my ego get the best of me. Thankfully, Bobby was kind enough to take a look at my code and he seen that I was just declaring my User model in the constructor when I was really supposed to be declaring it before the constructor and inside of the main class. Implementing the PUT method for this component in the back-end was pretty simple because the logic wasn't too off from the already implemented POST method. As always, I feel as though my understanding of Full stack Development has really improved and I have added some great tools into my arsenal. Spring MVC had really made the job easier by abstracting majority of the methods and functionalities and Hibernate was really something special and I appreciated the automation it took care of in our database, because that is a big part of Programming at this level. One thing I learned from this project was communication, and as much as it is very helpful to try to debug code on your own, it is just as important to know when to ask for help because the solution may just be under your nose the entire time.

Zach: The team worked well together. I’m sure it was at least partially due to us becoming familiar with each other since the beginning of training. It was easy to talk about the project, propose ideas and ask for help when it was needed. Sending and receiving requests was relatively simple and intuitive. Also, Spring was very intuitive and easy to implement in the backend. Creating the databases in the backend was simple, as was handling HTTP requests sent by the frontend.

For the frontend, I initially had issues with Observables and methods running before they resolved. Without a readily available “await” keyword like with promises, it was difficult to prevent method calls until after the Observable resolves. I think everyone came up with a different solution; mine was to put all the method reliant on the Observable inside the subscribe method.

Had trouble implementing an HttpInterceptor to implement unit tests for the front end services. and since we only started implementing testing toward the end of the project, I wasn’t able to include them by the time we presented. This means I didn’t have unit tests for many of the methods that sent Put or Post HTTP requests, and could change the data stored in the database. Ultimately, this caused our frontend of the project to have low test coverage.

Finally, since this was the everyone’s first “real” attempt at using a Kanban Board, we had trouble writing the right, descriptive cards. We also had problems with scope and only working on what we were supposed to. This led to people editing the same code in the same files at times, which resulted in merge conflicts when we pushed our changes to the repository.

If I were to do anything differently for next time, I would implement tests earlier and use test driven development. This time we only implemented testing at the end of the project after we had already verified the functionality. I feel like using tests early and consistently would have made development a smoother. It also would have afforded me more time to get tests that I was having trouble with to work.

Ian - For me the project went in 2 stages; first we build the backend and second we build the frontend. The back end was rough, my computer was running slow so I was not able to pilot. After we had shut down zoom and my computer didn't have to balance so much, I decided to make the tests for the service class and the Login and out functionality. So that was an easy win.

the second half where we built the frontend was a lot of work, but I'm so glad that I put that work in. I decided to make the component for the main game, so there was a lot of work to do. The component had to look like the jeopardy; questions had to be called, and displayed one at a time as they were clicked on; answers had to saved so that they could be compared to the questions and scored. This required data binding, HTTP calls, and storage objects to be created and manipulated.

the complexity of the project left me unsure of how to proceed, so I ended up having the delete large portions of my code 3 times.

• the first was when I thought that I should save my Questions and Answers Store in a model of it own, conceptually taking the place of a DAO layer. This turned out to be more cumbersome than useful, and as I made the HTTP requests and wrote the code moving the questions into model and then into an array I realized that there was no need and I deleted the model and saved the arrays as variables in the component itself.
• The second was when I tried to create a second component to display the questions. I thought that having a component inside a component would be a neat solution to having to iterate through questions and have them present on the page (a little like a nav bar but all directing to the same component and only changing the values inside of the component's ts file). Jumping up and down components, pulling questions from the main game and presenting them on the "questionPrompt" and pulling the answers from the "PromptComponent" and storing them in the main game proved to be an impossible feat, and I ended up scrapping that design as well, and consolidating it into the single main game component.

There were a few other design decisions that had to made, which turned into learning opportunities.

• for storing the answers I wondered if I should add a "givenAnswer" field to the "Question" model. I was tempted at first but then I realized that the whole team is using those models so I had best not mess around with them. Instead I created an "Answers" model which held the values I needed.
• There was also some juggling that I had to do to make my Observables cleanly populate the variables I needed them to. In my original design I had all of my observables collect the data they needed to, and then I ran a function that populated all of those variables at once. Of course the function was run before all of the variables had come back. So instead I had to break that one large function into 5 smaller ones, and run them in the "subscribe()" methods of the HTTP calls.

Besides developing a deeper understanding of the structure of Angular Projects I feel like I also learned a lot about the syntax, and how to call the values that you want, I had a problem for about a half hour where I didn't know how to or that I had to instantiate "new" variables for them to be useful. Then I realized that I was programming in an OOP language. Came out of this project much more confident that before and I'm really proud of the project and the work I did, as well as all of the work everyone else did.