The final sprint review of the semester was very successful with our component finally being completed. We ironed out some bugs before finally completing our form component. We worked on the dialogue box that needed to popup after the submit button was clicked. We imported a new module and created a new component for this solution. The module was called MatDialogBox and it was imported from the angular library, but we needed to create a new component to implement it correctly according to the documentation. We had multiple issues with formatting the popup box with buttons that said done and cancel because the default dialog box comes with a text field instead. Once finished, we pushed the changes and asked our instructor to finalize the merge. We realized that there were issues with multiple similar imports from various projects which lead to complications as I had mentioned in my previous sprint reviews. This stage was the stage that I worried about the most throughout the project and reflected on. The merging of our code with other teams’ components turned out to be much more complicated than I initially thought. We needed to remove any imports for angular modules that were repeated within every component that was made in the final project. We had to sift through various groups code to make sure there were the correct imports while also making sure it would compile correctly. We ran into issues very quickly when we ran the program since it wasn’t properly styled. The components that we made overlapped each other when we served it. This meant that the visual details in the html and css files needed to be further modified. We looked into moving the tab component around and the homepage to make sure our component was underneath which proved fruitful. However, formatting the entire project to be visually appealing turned into a nightmare. The branches that we initially pulled to piece the components together turned out to be a branch that held broken code. There was a different branch that held the compatible code with other components which led to confusion in the beginning when we tried to serv the project. We were suggested to leave this task to the integration team, but we still wanted to persevere and try to find some way to make things easier for them. Finally finishing the Q-Form component was a very interesting experience as was this entire project. We went from using real Ampath code to making our simple app that would run off pre-determined data that we would feed ourselves. It was a great learning experience as to how to communicate with a team and understanding a groups workflow to enhance communication between each other. This allowed us to debug together and solve issues much faster in person compared to over our communication channels. I realized that we really crunched through any questions or troubleshooting very efficiently when in person compared to online. 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. The final presentation really showed me how patience and teamwork can prove to be useful in the grand scheme of things.

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

At the very beginning of this sprint, on April 25, Mia was able to push the portion Dan worked on (“Tabs2”) so that we could all see it. Up until this point, the rest of us were not on the same page. We were looking at a previous one we had come up with. We were instructed by Mia to hang tight until she was able to push it.

Ryan and I were both unsure whether she would be able to, so we talked about doing it from scratch. That night, I started the process, but I didn’t get far before Mia let us all know that she was able to get it pushed. At that point, the majority of the component was done. I noticed that the button to create new slides was broken. It was a small fix, but I was able to fix the bug.

Most of this past week was preparing for the presentation. I feel somewhat that I was under utilized and that I could have done more. It is not that I did not want to do the work. I offered often to do more. Once I was able to see the component, most of it was done.

I suggested starting development for another component both before the first was completely complete and after. I was discouraged by my team from doing so. I feel like if we had, we could do at least one more component. I feel that even if we got a start and was unable to finish on another, it wouldn’t be much of a loss.

In the last retrospective, I felt different and that we should just focus on one thing and do it well. I did not realize how far along we were. (Again, I was not able to see it.) I feel that we could have easily done another component in this last sprint and a half. However, hindsight is 20-20, and I didn’t know then what I know now. This was the first time any of us had done something like this, so none of us knew what to expect.

Despite my regrets for not being able to do more, I feel this overall has been a positive experience for this entire capstone. I will be able to take what I have learned here and apply it to the next scrum team I work with. We have not been perfect in communicating, but we have done a pretty good job overall in keeping each other updated. I think we all have seen where we have fallen short, and I think we can use our failures as learning experiences.

Some of our problems came when one of us would run into a problem and the rest of us could not see what they were dealing with and, at the same time, be relying on that work. It would create a bottleneck. It was very frustrating for me to not be able to help in any way when it came to this. I am not the kind of person who likes to sit idly by when I feel I could be of some help.

What I can say about my team is that none of them are slackers. It isn’t often when I feel that I am not the one shouldering most of the work in a group project. This was a welcome change of pace, even if I wanted to contribute more. I found that in a group like this, I should have taken initiative sooner and more often. That lesson will be crucial to success in my next venture.

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

This was our last sprint for the semester and surprisingly enough there was a lot of work accomplished during this sprint. In the previous sprint we managed to all get on the same page with our component (functionality/styling), our goal for this sprint was to try to finish the form component and start a new one. We got as far as merging our branch with the master branch and pulling all of the commits from the other groups.

Our component consisted of multiple input fields, a back button, and a newly created submit button that triggered an event calling another component to load on screen. After merging our branch with the master and pulling all of the code in the project we were greeted with many errors; for what reasons we are not too sure. We tackled the conflicting errors one by one, first by removing some imports/adding some dependencies. Secondly we had to comment out all of the other components that were called on in the app.component to focus on ours since we wanted to move forward with creating a later stage of our component.

A more advanced stage of our component was a cross between the tabs component and our form component. We added some code to create multiple tabs while having the same form fields and it successfully worked. Overall this was a very successful sprint.

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

This is sprint retrospective blog post number 6 for the IncreEdibles team. This is our final sprint blog, and we got the website to work. Which was our goal, there are a lot more we could improve, but this is good start. We got mostly front-end to operate, the form and report. The other jobs left are setup server and database.

As I mentioned last blog, my task is creating Ages of Household Members feature on the form. this feature take input on what are the age range of people in household. There are 4 age groups: from 0-4, 5-17, 18-64, 65 and up. I created these group to variable name ageGroup1, ageGroup2 …user will can options of drop-down menu from 1 to 10. We will have record of how many people in the household and their age range. I ran into issue where the list from drop-down is register as a string. That’s mean I can’t compare to the Number of Household Members; I must change input to integer. So, I changed user input to simple typing number. By compare input integer with Number of Household Member component, I can have warning sign to lets user know if they have same number of Members. The warning sign will disappear when they are same number. It was interesting. I learned a lot specially how to work with other.

There are few points I took from it, the way we fill the form is top to bottom. It is important that we create components based on how we fill it. A lot of components are standalone, also components are connect with other component. That may create conflict if we have separative developer create different things. Developer need communicate with each other to make component effective. One other thing would make the job easier is good design before implement. This way we know which component is important and is priority.

For final presentation, we will have meeting and create represent what we did and learned. I think the most important is to have system for the future class. We should have tips and system for the next team better production. We have issue with beginning, because we were the first to try out this system. This is the step can easily avoid by having a system. We did learn a lot from these roadblocks, how to communicate with product owner and customers, also with teammates. As this is the final sprint retrospective blog, good luck to you all with future career.

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

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.

For this last sprint, our team made several steps to continue tackling additional features for our left navigation bar. As I described in the previous sprint retrospective, we had made a list of other tasks that would make sense to be added to this minimum viable product. Last sprint, I focused primarily on the CSS styling of the navigation bar. This sprint, I spent more time refactoring our code so that it would be more easily modifiable and versatile for upcoming semesters. We also looked at integration of other components into the main app.

Towards the beginning and throughout the sprint, our team had been starting to discuss how our code would work with other components that other teams were making. Instead of putting all of our navigation bar code into the app.component.html file of the Angular project (the main app’s HTML), we were directed to make a new component, called “left-nav-bar,” which would store all of the code that we had already written. The file structure of this component is the same as the “app” component, so that our code was easily transferrable, moving the contents of the app.component.html file to the left-nav-bar.component.html file, as well as updating the left-nav-bar’s CSS file in a similar manner. To generate this new component through the terminal, I used the command, “ng generate component left-nav-bar” (reference found here). Then, once all of the files of the left-nav-bar component had been updated, the app.component.html file was modified such that it referenced left-nav-bar. This utilized the left-nav-bar selector tag, found in the left-nav-bar.component.ts file. The following line is the only one in the app.component.html file: <app-left-nav-bar></app-left-nav-bar>. With this left-nav-bar component, rather than having all of the code in the app component, any other component could utilize the left-nav-bar code. It becomes easier for the left-nav-bar to be used elsewhere through referencing it, whether in the main app or within another component.

Another significant addition to the navigation bar was a home button, so that the user could navigate to a primary home page at any time. This home page would also be the default page when initially launching the main application. In order to go about this task, I once again used the above mentioned command to generate a new component: “ng generate component home-page”. This created the home-page component in the “app” folder. Fortunately, I did not have to change anything that was created from this command. However, my component was missing a routing module, which implements the Router service provided by Angular to display certain components or component views, based on the definition of a given URL (reference found here). In order to successfully create this module file, I created a file with a name (home-page-routing.module.ts) that matched other components’ router module names (patient-search-routing.module.ts, for example). Then, I copied the code from the latter file into the former, and changed the names presented in the home-page-routing file accordingly such that they reflected that component and not the patient-search component. For example, I changed the name of the router module class name from PatientSearchRoutingModule to HomePageRoutingModule. The following line was also added to the home-page-module.ts file such that the importing of this routing module into the application was recognized: import { HomePageRoutingModule } from ‘./home-page-routing.module’;. I also updated the app-routing.module.ts file (more specifically, its list of possible Routes) to add a new path to this home page component, as such: path:’home-page’,. Finally, I added the following code to the end of this list so that upon starting the app, the home page component view would be immediately shown – path: ”, redirectTo: ‘/home-page’, pathMatch: ‘full’. The redirectTo section allowed me to specify that component.

After these were added to the app, we set to start merging our app with other teams’ components. However, this encountered further issues, as these other components were overlaying our navigation bar while the application was running and caused them to not work properly at the same time. While we did not have much time to fix this issue, we discussed that continuous integration with other teams should have been a top priority from earlier sprints, and unfortunately this was not considered until the last minute. Hopefully during future semesters, other classes can ensure that this process is started earlier so that we could end up with a working app with multiple components.

Thanks for reading! It’s been a productive semester, and I hope to have more posts soon about my experience as a new software engineer.

From the blog CS@Worcester – Hi, I&#039;m Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

This Sprint started with us adding more tasks to the issue board, and taking on some of them. However, for the most part, we spent a lot of this sprint wrapping up our work and making preparations for our presentation to the class. We were able to reflect on our work throughout the semester and look at what we’d accomplished. From there, we reflected on things we did wrong, things we did right, and things that could be improved on the project in the future.

Personally, I think if the project was given more thought and setup ahead of time, it would have gone a lot smoother. In hindsight, having the repositories for the project set up, organizing the task- and product-backlog, and streamlining communication between the groups is something that NEEDS to happen. Making these things into assignments and writing up worksheets for them like in CS-343 and -443 would work a lot better, I think. This way, everyone in the group is getting an equal understanding of what is happening and how the project is organized. Also, having a set place to communicating between the groups from the start of the project would be helpful in ensuring no communication is being lost and everybody is being heard.

While I like the idea of being able to work on a big project with a group, it is very inefficient when there is no proper authority. Although the University obviously doesn’t have the resources, things certainly would have gone smoother if there was a project manager who actually knew what they were doing and could steer us in the right direction. The professor’s attention was unfortunately divided between so much this semester that there wasn’t a lot of time for useful reflection from a mentor.

Things I think we did right is that we worked hard and produced a product that functions. We did everything we could and made the shell of something I truly think will be useful for the University in time. Far from complete, there is a lot of unfinished work that future groups will hopefully pick up. Many of these tasks we didn’t get to are listed in the backlog. And there are even more ambitious features that we’ve thought of that haven’t made there way there. We competed the most essential features first, and got to as many of the others as we could. If we had more time, it would have been interesting to work on how to organize a backlog and rank products by level of importance.

Ultimately, despite the setbacks and difficulties this semester, I have still learned a lot about project organization, workflow, cross-team communication, and many other lesser thought-of parts of the workplace. Therefore, I still think the Capstone was ultimately useful and served its purpose. There is a lot of complexity in simply setting up a shared place to work on a project and communicate changes. All of which must be done before work even begins on a project. In the future, I intend to be more prepared and approach big tasks more proactively.

From the blog CS@Worcester – Let&#039;s Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

During this sprint we actually accomplished more than any of the previous sprints. Together as a group we added in different pieces to the intake form and submitted a pull request with our completed tasks. I personally added the primary household income field as well as worked with Tic to make adjustments to my previous task, household size. Everyone else more or less completed their tasks as well. This sprint showed that given the foundational pieces that took us most of the semester to acquire, we could complete some notable work in a sprint.

In terms of how we divided the work, we simply each took a task on a volunteer basis until everyone had one task. After this point there was still one remaining task that was purdenant to what we expected to get done in this sprint I took on the household size task at the end of the last sprint and then took on the primary income source task as an additional piece of work. This worked out nicely as there was no forced level of responsibility but allowed everyone to work on tasks that varied in difficulty for everyone’s individual level of understanding of the tools being used. If there was anything I would change with this way of working is that I think in a perfect world our tasks wouldn’t all be making changes to the same two files. In a perfect world, we would have had a couple people working on those tasks while we had other people developing another aspect of the final product. Unfortunately, there simply wasn’t enough work established for everyone to have something to do if we wanted to have a clear understanding of what we were developing.

For my personal work, I had to relearn how to do ng-if’s and the basics of angular. I remembered most of the html syntax but there were little things that I forgot but almost all of angular seemed to leave my brain since CS-343. The most difficult part of searching for information on Angular is that while incredibly outdated, many of the top results when searching are for AngularJS instead of Angular 2+. If not properly inspecting the tutorial, it could be relatively easy to miss this important detail. When completing my task regarding the household size, I had to come up with a way to make sure that if a person was a commuter, they were properly entering “1” as the value. I had trouble making this persist upon submission and originally decided on a hard overwrite that would default to 1 regardless of what a person entered for that field. The problem with this method is that a person could still consistently enter non-1 values and never learn that this is not expected. Tic came up with a great idea when developing his task to create a very much visible warning message near the box for the field that needs correction. I “stole” this idea and adjusted it to my field accordingly. When developing my other task for primary income source, it was much easier than the other task as there was no real logic to work into the html other than making sure the data was passed on submission to the model. The only other real logic was that a person could only have one primary income source, but that was fairly simple.

Overall I feel that we are in a good space heading into our final presentation. We had struggles early on and throughout most of the semester, but we finished strong. We finished with by far, our best sprint of the semester and I’m happy with what we got done during this final sprint.

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.