Category Archives: Sprint 5

Sprint 5

Hello everyone and welcome back to another sprint blog post for CS 448. Today blog post is about what I did in Sprint 5. In sprint 5 I focus most of my time working on the presentation. I brain several ideas on what I was going to go over in the final presentation day. During this time, our team was working on a specific feature for the Ampath project. During the meetings we would discuss how we would improve the Application. We would help one another when needed and would advise each other on how to improve the in certain areas. During the project we came into a couple problems because in the beginning as I was creating the project I create it in Gitlab instead of GitHub so that a merging error which we eventually got the project to be converted, thanks to Tim who is a member of our group. I believe the merging and converting took a couple’s days, so we had to wait to push certain commits until the project conversion from Gitlab to GitHub. We are still working on merging our component to the group’s component because the problem that we came across was that the alignment wasn’t right. Also, during this sprint, we were looking into library type things in Angular. We also finished keeping an eye out for Zeplin shared folder – where designs will be. I would also like to say during this sprint we work well together as usual and everyone contribute equally. Mike was working on the drop-down box which he added many cool features. I also had many of the of the meetings on Tuesday and Friday done during this week’s sprint. All in all, I learned a lot from this week sprint 5 like that creating a project and GitLab and trying to paste it in GitHub creates major problems and time to fix. I also learned more about how Angular works by working on this Ampath project during this week. I am also improving on working as a group in scrum while working on this project during this week sprint 5. I think the plan for next week is to finish up on the presentation and have a working polished project to present. I believe that we will have those requirements by the end of the next sprint. To finish up this blog post I would like to go over the objectives for this week sprint 5. First, to get the presentation started and have a template of ideas. Second, we would also be close to finished with the application because we were approaching the end of the last sprint week. Finally, to learned more on Angular applications.

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

AMPATH-WSU Sprint 5 Retrospective

Hello my dear readers. Welcome back to my next sprint retrospective blog post for all of you who have been following me through my journey and welcome to all new readers (I would strongly suggest you to read all the sprint so you are familiar what I am talking about). Are you excited to know what we have been up to this past sprint?!

The other team working on this project was able to push their changed and the professor merged and deployed their changes. I got to say they did a very good job in the tool bar. Now it is our time to add our search bar. While doing that we were thinking that we wanted to work on some other stuff in the project to feel more productive. We started to look at the issues that were listed in the github repository but an idea crossed my mind.

I am taking this class in parallel with another software development concentration class: CS 348, Software Process Management. There were two classes were our professor wanted to teach us about CI/CD and Travis CI. Yeah I know most of you are like: “English please!” For all of you that are not familiar with the terms, CI means continues integration, CD means continues deployment and Travis CI is a software used to set up your project with CI/CD. But why is good to CI/CD?

First time I cam across with CI/CD  it was at work, when one of my teammates suggested to have CI/CD in one of our systems. After his idea was approved, he set up our system with CI/CD and it was seriously a life savior! At my work place we use two main branches: dev and master. Dev branch is for all developers to merge and test their changes in a live environment. Dev is not production. Master branch is the production branch where only managers can merge and deploy. Whenever a change is made, we merge our branch into the dev branch and that’s where CI/CD kicks in and makes everything easy. Before we had to wait for the managers to deploy our changes to dev and then we could test. Long story short, CI/CD made us more productive and efficient.

My idea was to set up the AMPATH project with the CI/CD via Travis CI. The good thing about using Travis is that differently from Jenkins you don’t need a server. We talked with our professor and we were very happy that the idea was welcomed and approved. While me and Kristi will be working on integration for the next sprint, the other team members will be picking up another issue.

This past sprint was mostly a reflection on what we have worked on and what else we should do. I am very excited for the next sprint though, as this is the last sprint and then we have to present our work. I am really looking forward to figuring out how to set up an angular project with Travis CI and make everyone’s job easier. Please don’t miss my last sprint for this capstone class..See ya next time ?

 

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

Sprint 5 Retrospective

This past sprint was not quite as productive as we would have liked, although we did manage to start making great progress towards the end. In the beginning we ran into a tremendous amount of roadblocks. Between angular versioning, formatting errors, and more, we were really struggling to get off the ground in terms of productivity. It seemed as though, once one person had the local environment running on their machine, it broke for someone else. It wasn’t just a couple of us having issues, either. Each person in the group seemed to encounter some error at some point in time.

First, one of our members was struggling to build the angular environment at all. A fresh install of angular was required, which seemed to have fixed the issue. After that, I was facing some issues with something called polyfill.js, which was interfering with my ability to get my angular server running at all. Stack overflow wasn’t of much help because most of the issues I found posted were suggesting that I alter package-lock.json files, etc. These were all things that my teammates didn’t have to do in order to get the server running, so I figured that the solution was simpler than that. I was correct in my assumption once I remembered that AMPATH recommends that we run ng serve with the –prod tag as well. Upon doing this, the issue with pollyfill.js resolved and I could run the server perfectly fine.

Not only this, but we seemed to have many issues with git branching for whatever reason. We had previously played around with another group’s branch in order to confirm that we could get styling running at all on our local machines (which is how we realized we needed to ng serve in order to see styling). This ended up being a bit of an issue for a few of our team members, because they were seemingly unable to git checkout back into our branch — git was declaring that they didn’t have permission to join the branch again. In order to fix this, those members decided it was easiest if they just deleted the repository locally and recloned the project. Upon all of these changes, we were finally all caught up and able to ng serve nice and cleanly, without any big red errors.

Once we had fixed angular environment issues, we moved on to development and actually got some design happening. A big issue we were trying to conquer was that our angular form component using the material design “mat-form-field” module wasn’t displaying correctly. It was a standard HTML text field as opposed to the correct Angular Material styled one. Last sprint we discovered that we were being a bit silly with this and that we needed the angular server running for the text boxes to display correctly, but even still, our field component wasn’t functioning how we had anticipated. After playing with some other components (material design checkboxes, etc.) I realized that we foolishly hadn’t important the library for the material input field, which was nested within the form field. Due to this, it was completely un-styling our entire form field. After importing this correctly, it was (and has been) development game time.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Sprint 5 Retrospective Blog

For this week’s sprint, I’ve spent most of the time looking into a way to automatically increment the version number (based on semantic versioning) every time we make changes. Currently there is a reference to the version number in 4 different places: The Procfile used by Heroku, the build.gradle file, the Java configuration file for Swagger, and the README Markdown file. To do this, I’ve been looking at different Gradle plugins that could do this automatically. There seem to be many different options available, but there doesn’t seem to be one that completely fits what I’m trying to do. I think that the fact that some of these files simply have the version number hard coded in is causing this issue. It would be simpler if the version number was located in one place (maybe a version.properties file) where all of the other files simply reference that file to do what they need to do with the version number.

While it’s not exactly an high priority task, given that there doesn’t seem to be many more changes needed to be made to the project at the time, it’s important to automate the version incrementation now in case the project needs to be updated in the future. It’s definitely not a good idea to keep it the way it is, as having the change the version number in multiple locations could potentially break something if one of them is forgotten. For example, we already ran into an issue where Heroku couldn’t find the jar file created because the version number hadn’t been updated in the gradle.build file but it had been in the Procfile. This caused the jar file that was created to have the wrong name, so Heroku couldn’t find it.

Also, another thing that I want to start looking into is to add unit tests using JUnit, as it’s something that I’ve neglected to do but definitely want to get done before the semester ends. That would include some basic unit tests for each class to make sure their methods are working properly but also some Spring Boot specific tests. For example, I should be able to create tests for each endpoint to confirm that they’re working properly, perhaps using some of the techniques learned from previous coursework such as mocks. Spring Boot appears to have a wide variety of auto-configured annotations that could potentially be useful for creating these tests. For example, the annotation “@RestClientTest” disables full automatic configuration and instead only applies the configuration that is relevant to REST client tests. This ensures that Jackson and GSON support is auto-configured.

In conclusion, I’m hoping to finish up with the automatic versioning as well as added necessary tests to the project by the end of the last sprint and before the presentation. I definitely don’t want to leave the project without adding any tests as that’s bad practice. In any future projects I’ll need to make sure not to neglect creating useful tests but I also want to avoid creating useless tests that were made just to have tests in the project.

Sources:
https://www.baeldung.com/spring-boot-testing
https://www.baeldung.com/restclienttest-in-spring-boot
https://github.com/davideas/GrabVer

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Sprint 5

This week wraps up sprint number five. This was our second to last sprint which is kind of crazy to think about. It feels like we just started! Unfortunately we also believe this means we are not going to be able to finish all of the product that we had hoped to. We were not necessarily expecting to finish an entire project form scratch at the begining but we had been making some extraordinary progress over the past two or three sprints. As it stands now we have a (mostly) complete intake form for the food pantry owners to use. It is missing a few fields that they would like to see, however the base version of the sheet is  complete. The base version is the current intake form that they gave to us to translate from paper to application. What we are working on now (and calling “incomplete”) is the extra features or new fields that the food pantry owners wanted added to their base version of their current existing intake sheet. For this sprint we got our repository fixed. It had some underlying issues with the way that it was set up that prevented us form achieving progress to the fullest extent (see sprint 4 blog for more information on our wacky repository). Once we got into our new and restructured repository we started back up on work. For this sprint I took out the task of implementing a zip code feature to add to the intake form. To do this, I created a new branch separate from master on our repository and called it zipCodeFeature (git checkout -b zipCodeFeature). The next thing I had to do  before working on this feature was to create an empty pull request on our parent repository in order to track my progress and commit history. In github I went to our parent repository and created a pull request from my new branch. Once I have finished my work and am ready for it to go onto the permanent repository I can ping a member of that repository with write access to review my pull request and implement my feature. What I did from there was begin working. Creating the zip code field on the form was rather easy. Since we have a bunch of other similar fields on the intake form I was able to reuse the HTML for it, leaving me to only have to change the ng.model and variable names. For this one I used the “studentID” field and changed all the studentID references to the new zipCode references. Next I had to go into our customer.ts file and add zipCode to the list of instance variables for our Customer object. After this I had to go to the customer-form-spec.ts file (this is where the customer object is constructed and there also is another customer object that we are using as a test subject in that file) and add the zipCode fields to both of those constructors. Going back to the main HTML page for the form I had to add a method at the bottom which relates to the second page of the intake form and saves the information. Again, I was able to reuse some methods that were already existing in the file. I then proceeded to test the zipCode feature and it worked! There was a catch though. The pantry owners wanted a feature within zipCode where if the student chose resident as their housing then the zip code would default to the campus zip code. I spent a good week or two trying to figure this out with *ngif() and other angular statements. Since the sprint ended and it is getting very close to our final class I decided to scrap that task and push my commit with a working base version of the zip code feature. All it is missing now is the auto-fill functionality. My plan is to take out a pull request within our repository to merge my branch to the master branch and hope that someone else may have a solution for me as to why this auto-fill feature is not working while they are reviewing my pull request.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Sprint 5 Retrospective

Since the last sprint retrospective blog post, our team has struggled to get the component we have been working on to show up correctly. It has been determined that the formatting code will not be applied to the component if it is just opened by itself in a browser. It is necessary for the amrs server to be running first, and then the component will show up at localhost:4200. We made progress once another group had us make a copy of their component and try to get theirs working for us, since they already had it working for them. I ran the commands cd amrs-simple-app, cd ampath-simple-app, git, checkout Tabs, git pull origin Tabs to make a copy of their component. Then I tried ng serve, and that errored, so I googled the error and found the solution and entered the command npm install –save-dev @angular-devkit/build-angular, npm audit fix, ng serve –prod, and then it worked. I waited for it to say “Compiled successfully” and opened localhost:4200 and the component showed up, correctly formatted.

Since that is out of the way now, we should be able to actually finish the one component we have been trying to get working for the last month. We should probably be able to do a second component, too, since the thing that has been holding us back the whole time has been solved. Now we can go back to our component, apply the solution that worked to display the other team’s component, and finish getting it to work and move on with the project.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Sprint 5 Retrospective (Capstone)

It is a shame that we are so close to the end of the semester. We were gaining so much momentum. It took us a while for us to get off the ground, but once we did, we never stopped gaining speed. I feel we will be able to keep this up through this last sprint.

My hopes at the beginning of the semester for what we could accomplish were unrealistically high, but I am not disappointed with what we accomplished. We have not completed a full working component quite yet, but we are very close.

I think our efforts are best spent finishing the one we are currently working on and doing it right. If we divided our efforts into starting something new, we run the risk of not fully completing anything. In the sage words of Ron Swanson, “Never half-ass two things. Whole-ass one thing.” If we are able to get the tabs working beautifully, I will be happy with our effort.

I have felt that our group has done a phenomenal job this sprint and every sprint before with our communication. We have a few venues of communication, using the most appropriate for what we need. Most days, we have been back and forth in a group chat. Whenever we find resources, we add it to a Google Drive document.

The days of our classes have been incredibly productive for the most part. I am surprised what we can get done in a little over an hour. When I play around with parts of it on my own, I find I hit walls more easily. It is great to have the shared pool of resources to help each other out.

We have largely been working from the official Angular guide to how to work with tab components. We found this very early on, but it has been our primary guide to everything we have done so far. The great thing about is that we have a few different ideas of what we want the final product to look like, and there are examples with all the code we need to do what we pick.

I think the most important thing we do when we plan this last sprint is to finalize what we want the end product to look like. There is an idea of having a button to add a new tab, but we don’t have a clear idea what the content of that tab will be if we decide to go that route. It is key to plan it out fully before diving in so we don’t waste any of the little time we have left.

A part of me wishes we could have two more sprints after this, because once we finish this component, I would like to continue to try to create another after this. Perhaps, in a way I can. Even if I do not continue working for this project in particular, I can use all the skillsets that I have picked up to continue to work on project just like this independently.

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

Sprint 5 Retrospective

This sprint posed a few challenges which I am not confident we will be able to solve by the end of the semester. While I am and I am willing to bet my team members would agree with me that we all have made good progress through the semester, however two major snags hit our project that will be difficult to solve given the time we had left.

At the beginning of the sprint, we were collaborating with the team who was working on the server, and they hit a significant issue when we found out that they weren’t able to make calls to the main server. For some reason, when they tried to access the server URL’s, they weren’t getting any data back from the server, but just a never ending stream of URL text return values. Without an ability to connect to their server, we won’t be able to integrate our component with the rest of the class.

While this snag would not directly impede our group in the progress of developing our component, we also hit another wall which I don’t have the faintest idea about the cause. When myself and my other teammates have our project forked onto our computers, and we run the application, we see exactly the component the way that we made it. However, when we tried to have a different team clone our component and run it, the output they saw was completely different. At the moment, I am not sure if that is an issue with dependencies on our end, or if the other team had a problem with forking our repository. This hindrance is by far the more significant problem because it affects the integrity of our component.

By the end of the sprint, our team decided that the best course of action was to improve as best as we can the usability errors, and to create a minimum viable product which we can use for our presentation. Given the multiple unexpected set backs, I will be happy creating a prototype component that is clear enough to understand so that we can pass it off to future students working on our component who will be able to focus solely on the integration with other teams’ components.

Although this sprint was definitely an exercise in patience and a refresher course in Murphy’s law, we definitely are continuing our march of progress regardless. As far as our component goes, we only have to throw on a few more bells and whistles to have a product which I can say for myself and with some degree of confidence for the rest of my team that we are happy with. I definitely expect set backs like this to be a common part of the job description. After all, nothing happens in a vacuum, and for every perfect plan there is a perfect failure.

At this point we are preparing for our final sprint, and getting ready for our final presentation. I’m sure that during our next sprint planning meeting tomorrow we will be beginning the process of wrapping up.

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

Sprint Review Blog # 5

            Our fifth sprint really allowed us to sink our teeth into the project and build our first component. We continued to have bugs and issues with git and node modules that we had debugged earlier in our third and fourth sprint. These bugs have come and gone randomly among our team members which made working in synchronization much harder because not everyone had a stable version running at all times. We debugged the issue through various methods using multiple pulls from other branches in git to solve the issue. The first error started with the CSS formatting that had been troubling us for a long time. We had originally solved the issue, but it came back once again when we pulled a fresh copy of the project from our branch repository. We decided to pull another version of the project from another groups branch and debug their files to see if the problem was with our local machines. It seems that the issue was with our file structure for our git branch because the other groups branch was running just fine. We decided to look further into the file structure of our project and reorganize the node modules to see if we could solve the issue. After further reinstallation of the node modules through the npm install command, we were able to get an interface up again. The CSS now works fine with the HTML and other application files. The integration of the Q-Form component with the app files within the code is our next real goal. We want to easily connect the component to the app files so that we can finally see if the function is up to our visual standards. We also have to decide if we want to select subgroups to finish this component while another set of people begin working on the next component. We will have to discuss this as a group during our next sprint, but I believe we are on the right track for this development cycle. We have solved many issues and are almost done making our first component. There has been talk about communication with an integration team that will be handling the total integration of various components into a demo file for the application. It could be possible that we have to mock some information as well for data instead of a server. It would be easier for time constraints to make random data rather than set up a server so that is definitely an option. The option of multiple people debugging a problem is comforting and it allows a fresh look onto an engaging topic as well. I personally enjoy group debugging because it makes the learning experience much more enjoyable. This sprint really taught me to understand other people’s point of view when debugging. I learned to be patient and try to understand another mindset even if it takes me longer than necessary. This proved to be vital when communicating with team members and allows a feeling of inclusion as well as mutual understanding.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Sprint 5 Retrospective

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.