This issue was to create a Backend Rest Api that could communicate with both our database and Front End UI.
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/11

This issue was done early in the sprint to see if MongoDb was a viable option to use for our project.
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/8

This issue was to create a definition of done for our issues so that the team had a better structure to follow when working.
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/23

In sprint two our team excelled in taking on the correct work load. Sprint one left us with too little work and we had to add things while we were working and even did some work without creating issues. However, in sprint two we proposed our work with proper weight classification and so we had just enough work. Our workload reflected our Sprint length well and we were able to split up the workload well between team members. This time around we took large tasks that had several parts and instead of weighting them higher we broke the issue down into several smaller issues. This way we were able to spread the workload out throughout the team and didn’t leave anyone working on one large portion of work for too long. I think this worked to our advantage because it was easier to formulate a plan and track our progress this way. As we completed more smaller issues we could see how far along we were with progress and dictate work to team members better. 

We didn’t have much of a problem at the beginning of the Sprint, although, towards the end when school was moved to online classes only we began to have some issues. It may not be within our power to control but the move to online classes was a detriment to our work ethic and communication as a team. Having a second week of spring break that otherwise would have been a week of working was a blow to motivation and the team’s communication was lacking. Now that we have returned to classes online we have gathered ourselves well and are ready to work. However, the removal from our work for twice as long as we had originally planned deemed to be a detriment to our momentum. We still completed the work load we had planned but we felt rather scattered.

Moving forward we need to work on our communication as a team. Before the national crisis we would meet in person as a group weekly and work for three or more hours together. This synchronous work ethic proved to be our most productive environment. Now that we cannot meet in person I think we could plan for synchronous online meetings to help aid our disconnect. Even if we are not collaborating on issues I believe it could help morale and productivity to know we are all working simultaneously.

As an individual I believe I just need to get back in the groove. Hopefully, with the help of my team we can create a schedule to add some structure to our workflow and get back into a forward momentum.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Here is what I worked on during this sprint:

• Created Epics for each project for organizational purposes
  • Gitlab Issue with discussion about Epics
• Set up CI/CD for both front ends:
  • Merge request for ApproveGuestWebUI
  • Merge request for isApprovedWebUI
• Designed Mock UI for ApproveGuestWebUI
  • Images in description of Issue
• Added Angular Material to ApproveGuestWebUI
  • Merge request for Material setup
• Started work on component to display guest info on ApproveGuestWebUI frontend
  • Work in progress branch for guest-info-component

Sprint Reflection:

It has been so long since the onset of this sprint that it is somewhat hard to remember how it even started. What I do remember is that coming into this sprint, my team and I were determined to get more work done than in the previous sprint. It looked like it would have been relatively easy since we had a longer sprint this time and our collaboration had improved greatly since the start of sprint 1. The start of the sprint proceeded smoothly and I took some intro to UI design courses to get the mock UI done within the first couple days of the sprint. We acknowledged that more work had been proposed for this sprint, but we had more time to get it done and I was confident that I would have the time over spring break to get both frontends completed. I think up to the point where all residents on campus had to move out because of the danger of COVID-19, I think my team’s communication between each other and planning was much better than the previous sprint. Issues on our board were much more granular and detailed and all of them were linked to the proper Epics and had the proper tags. I think all members of the team started to take the Scrum practices more seriously and it showed in our organization and communication.

This is when all of the uncontrollable variables of life hit us like a truck. All of the stress and changes in dealing with a worldwide pandemic definitely took a toll on my productivity. Rather than spend this whole retrospective talking about how COVID-19 ruined my plans for getting the frontends completed, I’ll talk about how we could have better prepared for this situation. Spring break was extended by two weeks and there was nearly a month without communication between our team. Over this time I felt uncomfortable asking for help or clarification about issues I was having with my team since I had no idea what anyone was going through. I decided it would be best to hold off on development until classes started up to give all members of the team time to adapt to the fully remote life that we are now living. While this is an extreme case, I think this is a good lesson in accurately weighing tasks as well as not adding too much work to a sprint. While creating issues I think my team and I fell victim to weighing everything using a “best-case scenario” approach. All of the weights created reflected the time it would take for us to complete a task if nearly nothing went wrong. As a software developer, I should have known that failure is expected and every task will almost always take longer than you think. Next time weights will reflect the reality that things go wrong so we can more accurately fill up our sprint with tasks. When determining what we would put in the sprint we were taking into account the time we’d have over spring break. This meant to get all of the work done for the sprint we’d have to put in a good amount of effort over the break. The misjudging of weights combined with this meant that an event as serious as coronavirus caused us to miss our sprint deadline for a lot of the frontend work.

Going Forward:

As an individual, I will be more responsible and truthful when weighing tasks. I will also communicate with my team and other teams as soon as problems arise so we can resolve any issues I am having as soon as possible. As a team, I think the place we could improve the most in is reviewing completed work. Allowing merge requests to pile up on GitLab causes development to slow down until those get merged. We decided to try and keep our “Needs Review” column to two issues at all times, but this was not enforced as much as it should be.

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

And the issues continue…

Hello dear readers, welcome to my second retrospective blog post. I don’t know why did I decide to switch to using MAC laptop on the last semester of school. As I mentioned on the first spring blog, I was able to fork and clone the code but was having issues in the terminal when trying to build the code. We figured out that the build environment was not fully set up and there was also something else wrong. To be honest I got pretty mad at MAC as I was having issues in another class for installing a virtual machine. I had an old windows laptop at home so I just started to install everything form beginning on that laptop. Sam, my other teammate which is also a MAC user had issues but different ones.

I would like to mention that I really like the way our team works. Kristi was able to help me and Sam with the issue of building the project locally. We always help each other and we don’t leave any of us behind. In my opinion this is a very important behavior to have in a team because that makes a team more productive and brings the teammates closer to each other. StackOverflow and Google helped a lot as well. Realized other people had had similar issues in the past as well. I would strongly suggest to research about the environments and tools you are going to use before you start installing them.

After we made sure that everyone was in the same page and each of us had everything set up we went and checked our to do tasks. I mentioned in the first sprint that that spring felt like a research sprint, I would say that this sprint wasn’t that different either. Actually I was not expecting  to start development right away as we were exposed to new tools. I would like to say that even though we haven’t started with development yet I am very happy about all the material that we are learning as its very useful and gives us a great experience.

Before the end of the second sprint we were notified that the developers in Kenya gave some additional information to our professor about what do they want the app to look like and what are some of their requirements. I also know that they send us videos of the wire-frames. This will allow  us to analyze the requirements and apply all the knowledge we are learning in the CS-448 (Software Process Management) class. We are all very excited to get started on watching the videos and start working on this project.

I would say that we did a lot of learning during this sprint and I would like to assume that the next sprint will be the same as we are going to study, analyze the requirements given, and separate out duties within the teams and within each other. I opened a few of the videos that Greg had posted for us and I am really excited about this. I can’t wait to let you guys know where’re we at by the end of next sprint.

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

Hello, again my dear readers! Another sprint has passed and as such, it is time for another sprint retrospective. These couple sprint weeks has left my group and me with a slightly lower than average workload. From the first two sprint weeks, not much has been added to the Trello sprint work board. The bulk of this sprint’s work was funneled into two major setup tasks.

The first of these major setup tasks was ensuring that each member of the team had the ng2-amrs software on our individual development environment. We also had to ensure that each person had it set up so that ng2-amrs could be built and run on each individual development environment. This proved to be a task that would throw more unexpected errors our way than I think any of us could have expected. Of the few in class meetings we did have, many were spent debugging and troubleshooting many of the varied npm errors that rose up to bother each and every one of us. My personal experience with installing ng2-amrs and getting it running was not the worst of all the ones in our group but it was not without its issues. I myself encountered three separate errors that stopped me in my tracks. However, thanks to the knowledge of my fellow peers both in and out of my group, they were solved. The rest of my fellow peers had similar troubles with the same bugs that I experienced and in addition, some new ones as well.

The second of the major setup tasks for ng2-amrs was for each team member to study and get familiar with Protractor and Karma. Protractor and Karma are both testing frameworks for Angular. Thankfully, there were easily accessible, available, and easily understood tutorials that were available right from the web sites of the two respective home pages of Karma and Protractor.

While not much happened these two sprint weeks, I can not say that it was spent lazing around or that it was quite unproductive or fruitless. Setting up the ng2-amrs was a good introduction back in to working with npm and was more than just learn the two basic commands of ng build and ng serve. In addition, I can now say that I am much more in tune when it comes to solving errors that might pop up when building an npm server. I have also learned what to search for on Google when a specific problem does crop up and wherein the error code to look to actually find the error that has actually occurred. Learning both Protractor and Karma was a nice change of pace as well. I remember learning how to test in my 443 class last semester and I remember that it was an interesting and enjoyable experience. Thus, this week two sprint retrospective comes to a close. Hopefully, in the next sprint, we will receive more messages from the project representative and be able to dive into something a little more relevant than just setup.

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.

This week finishes up sprint 2 of our senior software development capstone project. In this sprint we accomplished quite a bit. The most important advancement that we made in this sprint is getting specifications from our product owner as to what we need to do for them. At the begining of this sprint cycle we were able to meet with a representative from the food pantry, Serena. Serena was able to tell us more about the food pantry and what they are doing as well as what they would like to see as a product from us. One of the biggest takeaways from this meeting was to realize that the main objective for us is to assist the food pantry in their quest to transfer all their business and business operations from paper to digital. One of the largest problems we realized off the bat is that the food pantry does everything from data storage to daily operation by paper. We know as software developers that this physical paper way of doing things is very inefficient and can be vulnerable to human error (totaling numbers in wrong columns, incorrect data input, etc). Our thought was to help them by making software to help them transfer to digital and also do some automation for them so that they can avoid any possible human error. However, we as the software development team are not here to tell the food pantry owners what they should be asking for. There is a fine line that a software developer working with a product owner where you should suggest what you think you should develop for them that may be helpful while also staying within their guidelines. The biggest issue here is that the food pantry representatives do not have a definitive set of product guidelines and rather are open to any ideas we may have for them, as they currently are 100% paper and are looking for any help to go digital in a way that is useful to them. I enjoyed this part of the sprint because I got to interact with the people on the other end where we can talk about what we need to do and what we would like to do. After our meeting with the product owners we were able to start on our project. One of the group members started working on back-end development and was able to deploy a gitlab project for it. I started working on a front end HTML mockup of our worker client screen. Another member of the group worked on finding out how to parse a json file using gson. After our most recent sprint meeting we decided on tasks that we’ll start doing for the new sprint. More front end development will be done this sprint. This will be taken on by myself and another few team members. I specifically will be working on CSS stylesheets for our project. The other members will begin writing a Java program to connect our project to a database. In sprint 2 I learned a lot about project management and working with product owners.

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.

Although we have not been given anything to work on from AMPATH, save yesterday’s meeting, I have made the most of my time to learn as much as I could about Angular. I haven’t gotten all the way through the tutorial, but I want to emphasize learning it throughly over rushing it.

The first time I was going through the tutorial, I was well over halfway done when I realized I was missing one of the steps to get it to work. This happened early on in the tutorial as well, and I resorted to blindly copying and pasting every step again to get it to work. It turned out to be a very minor fix. I was much further in this time, and I was about to do the same thing, but I realized I would be wasting my time if I did that. If I didn’t understand the code enough to diagnose these simple fixes, I am not getting much out of the tutorial doing it this way.

I was talking to members of my team about it, and we came to the conclusion that even if we individually only got through the first few sections of the tutorial, our time would be better spent if we understood what we were doing thoroughly over completing all the sections without as good of an understanding of the concepts.

Even though we have not been doing a lot of work together as a team for the clinic, it is really nice being able to bounce ideas off members of our team. It is great  to have the ability to share resources with people I am working towards the same goal.

It feels like I am living out some of the apprenticeship patterns that are laid out in the textbook for this course. I am challenging myself to learn new concepts, even without a looming test or set deadline. I have gotten better and better into the habit of carving out a small chunk of my time to learning a new concept here and there. I hope this continues as this course develops, and I hope to continue this trait for the rest of my life.

Yesterday, our group liked the idea of working on the projects described in the videos in part 2a and 2b. I liked everything that I saw, and would be more than happy to work on this. It’s not certain if we will be the ones who get to work on this, but we will coordinate that with the other groups. I am very happy to get started. This is what I’ve dreamed about doing since I decided to major in computer science. It is really exciting making that happen.

I also read a part of Edward R. Tufte’s book Visual Explanations, where he has a page giving an example of what an effectively-laid out medical chart might look like (p. 111). Although this might be the only example I could find on something for medical use, I think this book might prove to be a good resource for displaying the data. I’m sure there is a lot to be learned even from the examples that are not specific to medicine.

The most useful tutorial I have found comes from Angular itself. It is a really easy-to-follow step by step guide that holds your hand through the entire thing: https://angular.io/docs

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

            Our second sprint had little coding action and more of a personal learning aspect that we decided to focus on. I found that the team benefited from individual learning in a similar fashion to an independent study when trying to learn about important concepts like Mockito testing and Angular formats. We then compiled our individual learning resources into our slack channel to help each other find resources that others may have missed. This allowed an easier flow of understanding while also being able to bring us all onto the same mindset of where we were in terms of starting the project. I will proceed to understand the AMPATH format for their angular code and translate that knowledge to the requirement we will need to meet in the future. AMPATH members have recently posted videos and presentations of how they want their new interface to look with explanations for user interactivity. We want to continue to understand how we should edit and evolve the code already given to us and turn it into the final product that they want. We will have to communicate not only with our team member but the other teams as well to go over which functions should be divided up and worked on. This will create a better organization system for how we should communicate with other teams as well to understand any implementations that they will do which might affect our portion of the project. We learned about how the AMPATH project works through the videos which explained everything from selection tabs to navigation elements. It seems that this design concept may be similar to that of a mobile app from the setup of the mockup files which makes our approach much easier to narrow down. The most important aspect of this design seems to be simplicity with functionality for the patients and their doctors. The ability to create a smooth design is going to be complicated with different teams working on separate functions that are supposed to come together to create this app. It will require concise and mutual communications from several fronts that we will need to perfect over time. I predict that in the beginning it will be difficult to explain our coding schemas and ideas properly to each other but once everyone gets a taste of each other’s coding styles, it can be done with minor hiccups. We also need to decide whether we will stick with the idea of using a Mockito style for our testing or setup a server on campus to continue working with fake data. We have communicated with multiple teams about this idea and think that we should at least try to see if setting up a server is viable with as few hiccups as possible otherwise, we will have to look further into testing. I believe that setting up the server could work out well for every group, but it could cause issues with connecting and internal errors that we wouldn’t be able to figure out properly. It is definitely worth a try as it would be an interesting experience to understand and make it easier to test if we should be able to get fake data.

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

            A reflection
on what I learned from this week’s activities is that when the working mindset
begins it goes quite smoothly. Once everyone settles in and breaks the ice, we
are able to communicate clearly and effectively what our intentions are and how
we are to go about it. When a certain task is finished, other members are notified,
and opinions are needed before we go any further with the task or beginning a
new one. When we get proper feedback, we are able to safely continue down the
path or create a new one to account for changes.

            Another
lesson learned from this week’s activities is that members will tend to focus
on tasks that they are comfortable with first. In my case, since no one was
comfortable picking up the role on working with databases, I felt confident and
comfortable enough to pick up the task. As for the other group members, they
also went off in the direction that would prove most beneficial to the group.
This way, the group will spend less time learning material that other members
are clearly proficient enough to get started. After that, we are able to
converse and teach our knowledge with the rest of the group members which is
quite efficient.

            In light of
this lesson learned, the next time there is a situation where the group is
clearly new to each other, and a project is being newly developed. It should be
safe to assume that everyone is not comfortable with each other yet and needs
time to adjust to the new environment and mindset. In this case, there is no
need to be anxious about the project over the course of several weeks as the
working process will natural come.

            During this
sprint, my task was mainly focused on creating a design for the database. This involved
reviewing materials provided by the client and any requirements or constraints that
are to be noted. The chosen route when creating a database to account for Database
Management System (DBMS), as such an E-R Model is required. The chosen platform
for the database is SQLite, we noted the importance of being able to export the
database file as a CSV file and vice-versa. Being able to obtain a CSV file is
important for the client as it’s their preferred filetype for distributing
information.

            Starting
off, I noted for four entities, staff, client, inventory, and items. In the
staff entity, it contained the attribute OneCard_ID
and a composite attribute Name which
accounted for First, Middle, and Last Name of the staff member. For the
client, it contains all of the attributes of the staff entity but introduces a
third attribute called Last Visit Date,
to account for information regarding the last time the client visited the food
pantry. Then you have the inventory entity which only contains the attribute Total Weight, since the pantry uses weight
to keep track of how much food is in stock. Lastly, the items entity contains
five attributes, Item ID, Item Name, Item
Weight, and Item Stored Date. However, to account for a concern from the client
about confidentiality of information the names of staff and clients are later
crossed off from the E-R Model. In conclusion, after consulting the group, the
next step is to create and connect the database with the project in order to
fully utilize its intended function.

            Starting off, I noted for four entities, staff, client, inventory, and items. In the staff entity, it contained the attribute OneCard_ID and a composite attribute Name which accounted for First, Middle, and Last Name of the staff member. For the client, it contains all of the attributes of the staff entity but introduces a third attribute called Last Visit Date, to account for information regarding the last time the client visited the food pantry. Then you have the inventory entity which only contains the attribute Total Weight, since the pantry uses weight to keep track of how much food is in stock. Lastly, the items entity contains five attributes, Item ID, Item Name, Item Weight, and Item Stored Date. However, to account for a concern from the client about confidentiality of information the names of staff and clients are later crossed off from the E-R Model. In conclusion, after consulting the group, the next step is to create and connect the database with the project in order to fully utilize its intended function.

            Starting off, I noted for four entities, staff, client, inventory, and items. In the staff entity, it contained the attribute OneCard_ID and a composite attribute Name which accounted for First, Middle, and Last Name of the staff member. For the client, it contains all of the attributes of the staff entity but introduces a third attribute called Last Visit Date, to account for information regarding the last time the client visited the food pantry. Then you have the inventory entity which only contains the attribute Total Weight, since the pantry uses weight to keep track of how much food is in stock. Lastly, the items entity contains five attributes, Item ID, Item Name, Item Weight, and Item Stored Date. However, to account for a concern from the client about confidentiality of information the names of staff and clients are later crossed off from the E-R Model. In conclusion, after consulting the group, the next step is to create and connect the database with the project in order to fully utilize its intended function.

What I produced this sprint:

References:

https://www.geeksforgeeks.org/database-management-system-er-model/

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.