A reflection on what I learned from this week’s sprint is
that when proper systems have been setup and the team synergy has reached proficient
levels, the completion rate of tasks increase during the sprint and
communication within the group is significantly better.

On the topic of proper systems, this includes repository
management, branch management, issue tracking, and issue discussions. These
five systems are currently being utilized between the two groups assigned to
this project. It took several months of trial and error to effectively plan out
guidelines and familiarize ourselves with them. This effectively allowed the
groups to communicate clear intentions towards a certain issue, reduce
duplications of tasks, and complete significantly more tasks this sprint than
all previous sprints.

Furthermore, improvements towards team synergy allowed us to
communicate more frequently during our sprint planning. This resulted in less
confusing discussions as we can express our concerns towards specific tasks or directly
question certain decisions without fear.

Our main focus for this week’s sprint was to finish the remaining
tasks that would be carried over to this week’s sprint, clean up any mess made
during the development cycle and create an appropriate presentation detailing
our experience working on the project. Finishing up the remaining assigned tasks
will allow us to close up loose ends. This will also create an opportunity to remove
all active and past branches on git before another group takes on the project.

The remaining tasks consisted of several input fields for
the intake form. We chose to continue these tasks because they are relatively
simple to implement. Other tasks that were too large of a job were postponed
indefinitely and were not considered. An example of this would be designing a
database schema for the backend. The reason for abandoning this task for this
sprint is that there would not be enough time between discussing and creating
new iterations of the schema to clear up problems. Time invested towards
designing the database where the implementation will probably be done by a
future group would deem efforts wasted. The effort redistributed towards
working on the presentation was deemed more useful.

Our group contained five members, of which four worked on
the Food Pantry Web Application and one was dedicated to the FoodKeeper API. For
our presentation, we each contributed as much information about what was done throughout
this project’s development process. In the end, it is clearly divided into a
section for the Thea’s Food Pantry Web Application and FoodKeeper API.

What I worked on during this week’s sprint is providing
appropriate code snippets for the backend. This also includes providing any
missing content based on the requirements provided for the presentation.
Lastly, I made an effort to ensure a smooth delivery of the presentation by suggesting
a system for delivery. The system is quite simple as we marked down exactly
which slides, we would like to cover, exchange ideas on how the information
will be presented, and made sure that if changes needed to be made, the group
will be notified. As our chapter for this project comes to a close, the
experiences thus far was impactful and I enjoyed working with my team for the
past month on this project as a whole.

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.

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.

            A reflection
on what I learned from this week’s sprint is that a poorly managed repository
will create problems for your team and slow down the progress. After translating
the work done in Java to Angular during our restart from last sprint. The initial
IDE used was an online IDE called StackBlitz however this was abandoned for
WebStorm a week later. This is because we weren’t able to successfully connect
it to any repository so that other members could make changes. At this point,
we downloaded a copy and started to transition into WebStorm.

            During this
transition, we decided to get a working copy into the GitHub so that everyone
from both groups can work on it. 
However, we did not make note that a properly structured repository is
important. In this iteration of the repository, the root folder did not include
all the necessary files needed to function correctly. The necessary files were
not exactly missing from the upload but rather located in the only other
subfolder. This subfolder was generated since we downloaded a copy from StackBlitz.
By placing this subfolder into the original root folder, we had plenty of
workarounds to make the project work normally.

            At this
point in time, instead of importing the root folder to start working on the
project, we imported the subfolder. This was a workaround since it treated the
subfolder like the root, so it functioned normally. In this folder, it also
contained a git ignore file that could not be used since it was located in
there. This meant that the node modules folder was also included to be committed
back into the repository. In the majority of cases, it is not recommended to commit
that folder, but little did we know what was happening.

           In the end, the Professor and another member managed to get a working copy sorted and uploaded to the master. Now it is structured with all the necessary files in the root and two other subfolders, one for backend and one for frontend. It is neat and easy to navigate, which meant that we would be able to easily pinpoint where new services and components can go. At this point, we don’t have to worry that making changes would risk breaking the builds that other members spent time working on. In the future, I will not let this situation happen again and will be more careful when structuring a project!

            During this sprint, I focused my efforts on creating a submission service. Currently, the intake form includes a submit button that only returns what the user has inputted in the form into a new page. I started using an Expressjs server, which has allowed me to get use simpler features to connect the main form with a local server. Eventually, the default url address should be directed to an actual server. In this current iteration of the intake form, it sends the array to the localhost at port 3000. By running both the server and the intake form in WebStorm and submitting a completed form. We can see that the array of data is now retrievable on the server, which can be seen in WebStorm’s terminal for the server. If everything goes smoothly we can most likely store the data into some form of non-volatile memory later on.

References:
https://expressjs.com/

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.

A reflection on what I learned from
this week’s activities is that sometimes it’s best to restart. Our initial two
sprints brought us up to a point where the current delivery is usable but could
not be built upon. We had trouble trying to incorporate features from each of
our own work loads that was divided in Trello. The main issue from the scrapped
delivery is that it is written in Java and missing fundamental components that
would make it difficult to create a webpage with. As such, the problem resolved
after deciding to focus our efforts on Angular and using it’s features to make
our lives easier.

Another lesson learned from this week’s
activities is that having more than one repository between two GitHub and GitLab
is a nightmare. It was a mix between each of the members uploading to our own
repositories to share mockups of things we have created during the sprint. This
choice is backed by us not feeling up to upload mockups directly to the repository
made by the professor since we weren’t “feeling ready” yet.  Then there is the issue with having two different
food pantry repositories which further confused everyone. However, this issue was
eventually resolved when the professor and some students came up with another idea
for handling the repositories. The new system creates a fork from the main
project to the class repository. There are a couple other things mentioned
about incorporating “stories” using this setup that I have yet to fully
understand.

The third lesson learned from this
week’s activities, is that it is very easy to get lost and sidetrack from the
main goal. This lesson is mainly for myself as I was working on the database
but took me an entire sprint to realize that I was working on the wrong portion
of the project that was unneeded at the moment. Focusing unnecessary resources towards
a feature that should be left for later. The other members were focused on the
intake form and had created the front-end of it but needed a place to store the
information later on. This is the area I should have tackled, in which our
members would have been working in unison.

During this sprint, I focused my efforts on mainly establishing a connection to the SQLite database created from the previous sprint with the current project. Using JAVA and the available JDBC library found on the web, I was able to successfully connect to the database. However, when it came to transfer what I learned into the main project we were working on gave plenty of errors. There were missing libraries and many unused and preplanned files that needed deletion. Although this was a problem, the next problem is mentioned earlier in the blog. We needed a clean slate to work with since the project was in an unworkable state. After we got back to the point where we were in JAVA, now in Angular, I had to find a new way to get the SQLite database to work in Angular. Now that we are back on track, I can see where the project is likely headed!

References:

http://www.sqlitetutorial.net/sqlite-java/sqlite-jdbc-driver/

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.

            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.