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.

During our last sprint we added some new features to our Tabs component. We were able to include buttons for adding and deleting tabs as well as a checkbox that selects a new tab when it is added. We also added some extra form fields within each tab. I think this was a very successful final sprint. We have a fully functioning tab component that follows the specifications that were outlined by AMPATH. Overall I’m satisfied with the progress we were able to make on this project.

During this sprint we added buttons for adding and deleting tabs. In our tabs.component.ts file we have an addTab() and removeTab() method. The addTab() method simply pushes a tab to the tab array. It also checks if the “select after adding” box is checked. If it is, the newly added tab is set as the selected tab. The removeTab() method calls the splice function on the given index in the tabs array. In our tabs.component.html file, we use the Angular Material mat-raised-button for the add and remove tab buttons. We also use the Angular Material mat-checkbox for the “select after adding” box.

Another thing that we accomplished during this sprint was adding extra form fields within each tab. We previously only had form fields for first name, last name, and address. This sprint we added fields for gender, birth date, and email. The field for gender uses mat-select, which allows the user to select a value from a set of options. For birth date we used MatDatepicker, which brings up a calendar and lets the user select a date. For the email we used Matinput and included an *ngIf statement to check if the email that was entered is invalid. We continued using the Angular Material documentation to help us get this part done.

Besides the add/remove tab buttons and extra form fields, we also started working on the final presentation during this sprint. My team was able to break up the work for the presentation well. I will be explaining most of the code that we have and will also talk about the changes that we made to it. In order to do this I have been reviewing the code that we have to make sure I understand how it all works. I’ve also been looking up information so that I can explain our code well. During this sprint we made a lot of progress towards being prepared for the final presentation.

Overall I think that our final sprint went very well. We were able to add the extra features to our code that we wanted to add. While there is still more that could potentially be added to our component, I’m pleased with what we were able to produce. We have a working tab component that follows the specifications that were given to us by AMPATH. I enjoyed working on this project with my team and learned a lot about Angular development. I would say that our final sprint, as well as this project in general, was very successful.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

Hello dear readers and welcome to my last blog post for the CS 448 class. This blog post will close the chapter of this amazing journey I have had with all the writing and experience with my capstone project.

Recap from last Sprint: we decided to work on the CI/CD of AMPATH project in order to provide productivity and efficiency for all the other teams working on this project. While we were aware of how to set up a regular Java project with Travis CI, the difference here was that here we were dealing with an Angluar project. To be honest I felt a bit discouraged when the professor showed uncertain on how this could be done. However, of course we didn’t give up. We actually (as always) had our best allay, Google to help and figure out how to work with angular projects.

Kristi was able to find a very useful and basic link that showed how to connect a simple angular project with Travis CI. Yayyy we found it. Well half of the job is done. We did our research, we learned the basics and it was time to work on our real project now. Kristi went ahead and tried to make the connected and he was able to, but as the project was added to the Travis account it was failing and not passing the tests. From the tutorial we saw it should be able to at least build the very first time.

I went ahead and tried to find what was missing in the configuration process. I was able to find out that somehow the travis file was not added in the format .travis.yml to the project which is weird as Kristi had added it as a .yml file. However I made the necessary changes and I am waiting at this moment for approval for my professor. I am also going to suggest to the professor the idea of having a dev branch for this project. The fact that there are multiple groups working on the same project at the same time, will probably create conflicts when trying to merge all these changes. Dev branch will have CI/CD and will be deployed within minutes. Efficient, right?

Today is the last day of our class and despite that the presentation of this project is not until May 15th. Therefor we will still be working on this the integration issue and also another part of the team will be working on the other issue we saw in github about figuring out how to store angular components in a library so they can be shared between multiple apps.

This coming week we will be meeting to practice out presentation and also talk about the line up and important points of the presentation.

I would want to say that working on this project was a good experience. However, I wish this is somehow better organized for the next capstone sections next year. What I especially mean by organized is the ability to reach out to the customer. I was aware of the time difference but as we are trying to help them on building their own system, more communication should be provided on their end. I am very happy for my team and what we have achieved and can’t wait to present all our work.

Until the next blog post… Take care you all!

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