Once again, this week marks the end of another sprint, with even more progress taking place for our team’s component of the AMPATH mobile app, the left navigation bar. As I described during the previous sprint retrospective, our team was able to complete a minimum viable product (MVP), meaning that any consumers utilizing this app would have a minimally functioning navigation bar! This sprint was focused mostly on adding and polishing new features that could make this navigation bar better.

During our preparation for the upcoming sprint, we came up with a list of additions that would benefit our navigation bar component, not only in terms of aesthetic but also in terms of functionality. For styling changes, we decided that we wanted to make edits which promoted easier readability. Other changes that we wanted to make included adding a home button on the navigation bar so that users could redirect back to the main home page, creating a dropdown menu for some of our buttons in case a sub-menu was required, and fixing the navigation bar such that once a button was clicked, the menu would collapse, rather than staying open when switching to a new page.

My overarching task for this sprint was to focus on the styling changes that we wished to make to the navigation bar. This included making the text size for the navigation buttons larger, increasing the spacing between each button to make navigation between each tab easier, center-aligning the button text (rather than left-justified text) because our whole team preferred the center alignment, and changing the color of the whole app to a darker mode so that it makes it even easier for users to look at the app. Adjusting the font size of the button text required a quick edit in the CSS file, app.component.css, where the font-size attribute related to the container with our navigation bar buttons was increased. I used the following site to make this change. Likewise, switching the alignment of the button text was specified in this CSS file, in the same section which described the formatting of the same aforementioned container. I used the following site to verify which attribute to change and how to modify it properly.

In order to increase the spacing between the buttons, I simply added 2 line breaks between each button, modified in the HTML code for the app (saved in the app.component.html file provided by the Angular framework). Finally, to change the color scheme of the app, I used the following site in the Angular Material documentation to learn more about the different themes that are pre-built into Angular Material, as well as how to go about creating my own custom theme. I initially considered creating a custom theme, but I wanted to check out each of the pre-built themes beforehand in case I liked any of those instead. As part of the Angular Material Themes, each theme has a primary palette (which are colors most often used on the app), an accent palette (for interactive elements on the app or any floating screens or dialogs), and a warning palette (for any error messages or notifications). I did a trial and error of each of these 3 palettes, for each pre-built theme provided by Angular Material, listed on the Angular Material site, and I found that I, and the rest of the team, preferred the accent palette of the pink-bluegrey.css theme, which resulted in a “dark mode” of the app. In order to incorporate this theme into our app, I navigated to our global stylesheet, styles.css in the top level of our src folder, and added the following line: “@import ‘@angular/material/prebuilt-themes/pink-bluegrey.css’;” Then, in our HTML code, whenever a color attribute in our button tag came up, I specified that the accent palette would be used, which looked like: “color = accent”.

This was a very productive sprint, and I’m very glad that our team has the flexibility to add more features without having to be concerned about the basic functionality of the navigation bar being affected. For our final sprint, we are going to be focused on finishing most, if not all, of the rest of our additional features. We will also be wrapping everything up for the semester (holy moly it’s the end of the semester already?). Stay tuned for my last sprint retrospective, and thanks for reading!

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

Good day to you again, my fellow readers! Well, the time has marched on and I have once again found myself at the end of another sprint and you know what that means; time for another sprint retrospective.

This sprint has been a bit slower than the previous sprint was. With the trials and tribulations of relearning or learning angular (in the case of some of our group members) behind us, many members of the group were able to excel and start knocking items off the backlog. With each item off the backlog, my teammates were even able to add on extra features and improvements. Content for the left navigational bar was established and each was given an appropriate button. We then added submenu buttons, for items that belong under a certain category and not on their own. A home button was added to take the user back to the main screen, return from the left navigational bar and close it. Many aesthetic changes were made as well. Buttons were moved, spaced out more, colors were changed to make it more aesthetically appealing and less harsh on the eyes, the font size was increased for better readability, and the text that confirmed a button press was moved to be centered on the page. The latter was simply for testing purposes so that button presses could be confirmed that a button press would actually register and change to the appropriate page.

On the last day of the sprint, our manager/professor informed us that another team working on the search bar function for the AMPATH application wanted to push their work to the Github repository and we needed to push our work as well because we had made a base application in addition to making the left navigational bar.  As one could expect, there was a problem. The issue was that our group had made a repository and were not working off of the branch we had created. Now, this may not seem like a problem however, the repository we made was not on Github, but in Gitlab! Remembering the Git lessons I had just had earlier in the day, I suggested simply setting a remote upstream to the branch in the main Github repository from our Gitlab repository. We could then simply push from out Gitlab repository to the Github repository and all would be well. With approval from the professor, I made sure to pull all changes from my team members, set the remote and attempted the push. Error. Of course, things can’t be easy. The error was a permissions error that would not allow the push if I remember correctly. After conferring with the professor again, he determined that the best course forward would be to simply copy over the needed files and make changes where needed to other files and push those changes to the branch. Then request a merge with the master branch to make the changes available to the teams that needed them. This was not terribly fun as while some files could be copy-pasted in, there were many files that I had to manually edit and add in lines that we had added. Before attempting a push, I made sure that the application actually ran, which it did after installing npm. After pulling all changes and completing the manual edits, I attempted to push the changes. Error.  I was missing files from the master branch. I pulled from master and tried again; same error. I wasn’t sure what was going on as I had just pulled and there were no updates. I pulled again to receive a no changes message. This had stumped me. This left me with only one option, sleep on it. After waking up, I came back to the issue and had a random thought to pull from the branch, and it worked. When I went and attempted the push, I had one more error, but that was because I forgot to check the master for updates. One final pull from master and I had done it. I was able to successfully push to the branch. To end this saga, I made a pull request to merge our branch into the master branch. That saga was great practice with Git and solving its many errors.

That’s it, readers. Another sprint comes to a close. We have only about one or two more sprints left so the time we have left is quickly coming to a close.  Until next time readers!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

A reflection on what I learned from this week’s sprint is
that establishing a working line of communication between multiple groups
working on a singular product plays a large role on the work flow. The “Theas-Pantry”
repository is currently utilized between two different sections of the same
class. As each section is either in a separate time slot or day of the week,
there is no physical communication between both groups.

In order to solve this communication problem, it is
presented to us to use a communication program called Slack. Within this program,
there is an established group that allows communication between the following
groups: all class sections, professors, and owners of the food pantry. However,
a second line of communication can also be established on the repository in the
form of discussions found on independent issues posted within the repository.

The theorized result of the primary communication program,
Slack, is that all related groups will be periodically or frequently
communicate with each other. If this is the behavior that exhibits through the
limited development time, which is the length of a single semester then there should
be significant productivity between both groups.

However, this was not the behavior that was observed during
the development time. The slack group made available to the students is under-utilized
in two ways. This first way is surprising, which is between the members of the
same group. I suspect that this is the result of being students and having
other priorities where the project is second to completing course work for
other classes. In the second way, which is not surprising, is communication
across multiple groups.

The core lesson of communication comes from the in-existence of communication between multiple groups. One major example of an issues that arose from this lack of communication is within the process of establishing and managing the project within GitHub. There were task duplications, wrongful closure of tasks, mismanagement of branches and many more. It was only until the middle of April where a successful link of communication was established to rectify the situation. If both teams took the communication aspect of group work seriously, the problems found should have been minimal or solved relatively quickly.

Although many of the issues have been solved as of today,
only one on-going mystery remains. There is a possibility that both groups do
not have a clear idea of what the other group is doing. We hope to sort this
out, as both groups seem to deem the other as the one at fault for any issues
that arise. This is the not ideal work environment in any situation and is
likely a product of poor communication.

During this sprint, I focused my efforts on solving the communications problem as described earlier in the blog. This includes updating descriptions of GitHub issues that lacked a meaningful description, removing duplicate or irrelevant issues created, or removing older Git branches. Other things that I worked on would be creation of newer tasks as indicated by our recent meeting with a representative from the University’s food pantry. Finally, the last significant thing I worked on would be finalizing the initial creation of the back-end, where it currently only serves a purpose at redirecting data from the intake form app to a server. I can only hope the last sprint finishes strong so that a working product can be presented.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

This is sprint retrospective blog post number 5 for the IncreEdibles team. After we moved to Github as our main issues board, we list all the features/tasks in one place. In out front-end we have the website interface. This is what our customer sees on their computer, after customers come to the food pantry office, they will give OneCard ID number to the front desk. We are trying to implement the scan swipe into out program. It will automatically fill in to the ID box. There are three sections for our customers, first section is sign up “Intake form” for the first timer. They need to fill out the form with information such as zip code, household’s situation, number of people in household, etc.. We can to make this easy and clear as much as possible. We created each features of this form on Github, then each of us will pick one to work on. To work on these issues, we create its own branch with the name relate to these issues. By this way we can work and review each other work without create conflict to the master branch. I picked issue number 39 “Intake Form: Ages of Household Members”, 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.

The second section is the form for return customer, they will input ID number as usual. The front desk operator will input how much food they take. We will keep record the time and date, and how much food they take. By this way we can keep track on how much food we have left in the food bank. The third section is the weight form, this is for Theas Food Pantry operator, they can input how much food in come in. They can track how much food is come in and come out, and what is left in the food bank. We also need backend which are the database and webhost for our website. We go though these progress to create food monthly report to the Worcester County Food Bank. It is convenient our operator to print out report.

This is the most productive sprint we have yet. I feel really good about this sprint. Although I feel like we could get this going earlier. But design and planning is big part of software developer. Hopefully we will have decent program when the end of semester.

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.

Our fifth and final sprint, we focused a lot on opening and rectifying communication with the other food pantry group and clarifying some of the issues that were posted on GitHub. We have not been keeping up with our issues, which has been a real weakness between the two groups. Both groups were relatively unaware of what the other was doing, and there was a lot of redundant work being done between the two of us. Nathan also organized another meeting with Serena so we could discuss our work and some of the changes the food pantry might like to see.

The difficulty we were having with issues were numerous. The first was that we were not claiming the issues we were working on. Both groups were therefore unaware of the progress of the other group and what was available to be worked on. There was redundant work being done and a lot of general confusion. After a discussion, we agreed to be more proactive about claiming or issues, and also did more cleaning up on some of the tasks and stories we had on the repository and discussed what is important, what is redundant, what can go, etc. We cleared up our tasks and stories, assigned ourselves to what we were working on, and moved on to our next tasks.

We also had the pleasure of a meeting with Serena, who was able to look at our progress on the intake form and give us some feedback and new information. We were able to discover a few more questions/fields to plan to add to the form, and got some helpful and illuminating information about the weight system in the food pantry, and what could be done by us to make weighing everything easier for them. We deliberating what information was important to be captured by the form, for the purposes of the Worcester Food Bank and the campus’s needs. We discussed the privacy of the data we are storing as well, and how much information we should be asking for as well as what information should be optional versus the data that was essential.

It is incredibly challenging to work with people whom you do not meet with nor can you deeply discuss the changes and work you are doing on the project. We have spent a lot of time trying to streamline communication between the two groups, make sure we all have access to the same resources, and being able to work effectively on a project at the same time. Although we have come a long way, there is still room to improve, as I feel rather uninformed about the efforts of the other group, and would like to know more.

This sprint was pretty tame, and I definitely learned a lot of different ideas and strategies related to organizational operations and effective ways to communicate and share your work with your cohorts/peers. Hopefully the lessons learned here will help me avoid fumbling in my career as I have in this project.

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

During Sprint #5 my team continued development of the Tabs branch in the AMPATH project. During our last sprint, I pushed a simple tabs component to Github. This sprint, we refactored the code to add a forms component for each tab. Overall, this was a very productive sprint.

The tabs component that I had originally pushed to Github included a list of patients, with a tab for each patient containing general information. However, the tab system that we need to create will be for forms, with various input fields for each tab. To do this, we used the Angular Material Design form fields. The following link was extremely helpful in learning how to implement the form fields: https://material.angular.io/components/form-field/overview

Adding the form fields required making some changes to our main html file. Originally, it used *ngFor to go through the hard-coded list of patients and generate a tab for each one. Since we are getting rid of the patients, we no longer have something to loop through to generate the tabs. To solve this we will have to implement an add/delete tab button. This will be our main focus for the next sprint. As of right now, we just have hard-coded tabs with the form fields within. The form fields are all the same basic types, as we don’t know which ones AMPATH will actually need. The three types of form fields that we have are input, which allows you to enter a line of text; textarea, which allows you to enter an expanding block of text; and option, which lets you pick an option from a drop down menu.

We did not run into too many challenges implementing the form fields. The main challenge was figuring out how to reorganize the html as the entire patient portion is now obsolete. Other than that, the only errors we ran into were pretty basic, such as missing a required import. I have enjoyed working with Angular Material Design as it works very well and looks good without having to make many adjustments. I’m glad we chose to work with it for this project because our other options seem like they would have been much more complicated.

After this sprint we are much closer to having the completed component that we are shooting for. We now have a working tab system with form fields located inside of them. We still have some work to do to get it finished, as we need buttons to add and delete tabs. However, I’m confident that we will be able to get that working during our last sprint. I feel that everybody on my team has a good understanding of the code that we have and we are all on the same page in terms of what we want to accomplish. I think that we are making very good progress and I am learning a lot about Angular and html. Overall, this was productive and satisfying sprint. We are making a lot of progress and have a clear and reasonable goal for our final sprint.

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

This was one of our most successful sprints yet. We are definitely on the right track to completing this first component and moving forward with our next. Towards the beginning of this sprint some of the issues we encountered were similar to the previous sprint. We had to remove/re-install our angular material dev-kit multiple times to get it working. I recall Matt and I having to delete and reinstall a few times for whatever reason to get it working and to be more organized. To be more organized we created an initial branch called “Questionnaire-Form” but then we ended up trashing that branch to create another called “Q-Form” which became our main branch that we worked on.

The component that we were supposed to build is a simple form. We worked our code around an angular material component taken right off of the angular documentations. Again there was a styling issue with our component. The HTML was working correctly but it was not looking the way it was supposed to. I tried using a different angular built-in material and imported all of the necessities. It worked perfectly. We then figured out that it was an import statement that we were missing somewhere. This fixed the issue and we were able to create the component correctly. We hope to finish this component by the end of next sprint as well as a few more components.

Onto the last 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.