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.

There was very little productivity during this sprint due to minimal work assigned. To keep busy our team used the time to learn about angular and testing in angular. One method that helped me learn more about angular was to do the Tour-of-heroes tutorial on the site. After doing so I understood why angular was used and what components really were and how they responded and “talked” to each other.

The final day of the sprint, we were given assignments that included creating the GUI of some sort of web application. Our team sat down and decide which interface we wish to move forward with. Before doing so we actually looked into what programs we were going to use and watched some YouTube videos on the instructions.

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 the Sprint 2 Retrospective for team The IncreEdibles. We got assign to food pantry development, but we didn’t give any specific task. Big part of our team is design program and listen to the food pantry owner. There are two projects that we are working on, one is the make API that support other project where they can pull any information that they want. The other project is to work with Worcester State University food pantry.
As a group we decided to focus on WSU food pantry since we see more potential in this project. First, we want to know what the important features that costumers want. We learned that setup with costumers is not easy, not just to set the time and place for meeting. We have setup our communication on Slack, but most of the costumers are not in tech they don’t want to install complicate software. They want to have program where simple “plug and play”, so their energy can focus on what important to them. This is the problem that I think we always face with customers. We as developers before the meeting need to have set of question to ask, not all customers know what they want. We had meeting with Joanne, the professor who run the program. She wants to know who goes in and how much they take out the food, keeping track with the amount of food (by weight) is the main feature.
We took notes from the meeting and make email as direct communication that convenient for both parties. These features are important, but we must think of the design future features as program getting update. Features that they don’t think they need at this moment, that mean we must track data. These are sensitive data, we must be caution. The features seem not difficult as keep up with the weight of the food, but we want to have reliable program where it’s simple and easy to prepare/add feature.
There are few techs that our group need to know, OneCard swipe machine, we need to know that it is operative and how to implement to our program. How to export from the “sign up” Google Form. Export form that the costumer can export to submit to Worcester Food pantry. And most important is design our program where it is simple, clean and it do what it’s supposed to do.
Our next step is researching all the techs to make all priority feature work. Make a mock program, and present/sell it to the costumers. In this sprint we want to know how far we can get this program to work. There is other group in different section also look at this program, our problem is time difference and communication. If they have the same direction as us, we should find a way to divide the program into two parts that two group could work on. We find that the communication is one of the biggest problems even with members in the same group.

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.

This past sprint was, to me, significantly less eventful than the first, but still very important in the progress of our capstone project. Over the past couple of weeks, I spent a lot of time focusing more on preparing for this upcoming Sprint 3, familiarizing myself with the tools and technologies that we will be using for our AMPATH project. We just received word about the kind of specific development work that we will be doing for the project, so keep an eye out for my Sprint 3 Retrospective for more information on that!

As I mentioned, Sprint 2 ended up being less productive for me, for a few reasons. We had a couple of class sessions cancelled (snow and other outside circumstances). While this fortunately did not slow our progress (everyone on our team has the AMPATH project built and running successfully!), our team has been taking advantage of each period of class time to discuss our progress, help each other out with any issues what we may be having, and planning our next courses of action. So, missing a couple of the sessions definitely slowed down some of the work that I could’ve been doing.

Another reason why this sprint has been a bit quiet is that we have not heard much about development ideas from the AMPATH team until yesterday, the final day of Sprint 2 and the beginning of Sprint 3. I’m very excited to start coding more, now that we have more of a plan, which involves mobile app development!

Our team had 2 tasks to complete this sprint – reading about Angular testing, and building and running the AMPATH project. Because I completed the second task during the previous sprint, I only had to concern myself with Angular unit testing, along with working together with my teammates to make sure that everyone could run the AMPATH project.

At the beginning of the first sprint, we had been tasked to learn about Karma and Protractor, two popular Angular unit testing tools. I, like other classmates working on development for the AMPATH project, utilized documentation for each tool in order to better understand how they work. My resource to understand Karma is found here, and for Protractor I used this source. Angular automatically incorporates Karma testing when creating any new project, so I spent more time reading about that tool. Karma and Protractor are similar, though, in that both load up servers on one or more browsers (specified when configuring) and runs the developed source code with the written tests. Then, the developer is notified whether each test passes or fails, via command line or through the browser.

This sprint really made me appreciate the quality assurance testing course that I took last semester. Learning about Java unit testing and its basic framework made the comprehension of this newer concept a bit easier.

Once again, I’m looking forward to posting more about progress that our team makes during this upcoming sprint! We have a lot of exciting ideas to discuss and potentially work with.

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.

For this week, I have finished up Sprint 2 and I would glad to be talking about it.

What I wish I could done throughout this sprint was to finding

Links:

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.

During our second sprint we were still focused on learning about the tools we will be using as we have not yet received actual work to do for AMPATH. There were two things that I focused on: testing with Karma and Protractor and the Angular Tour of Heroes tutorial.

Karma and Protractor are the two testing tools that we will be using for this project. Karma is used to write unit tests while Protractor is used for end-to-end testing. My teammate Ryan put together a very useful Google Doc that includes all of the basic information about these two tools including how they work, how to use them, and helpful links to learn more. This is the main resource I used because it includes pretty much everything I wanted to know about Karma and Protractor.

The following link provides a good overview of what Karma is and how it works: http://karma-runner.github.io/3.0/intro/how-it-works.html

Karma works by creating a web server that executes source code against test code. The test results are examined and displayed through the command line so the developer can see which tests and browsers passed or failed. Karma looks like it will be an incredibly useful tool for unit testing our code.

Protractor also uses a web server to run browsers that will test the code. It simulates user interaction with Angular applications in order to test system dependencies. The following link is a good tutorial that helped me get familiarized with Protractor and learn the basics of how it works:

http://www.protractortest.org/#/tutorial

Other than learning about these two testing tools, I also started doing the Angular Tour of Heroes tutorial in order to re-familiarize myself with Angular. I have previously done this tutorial in Software Construction, Design, and Architecture. However, I wanted to go through it again to make sure that I remembered the specifics of Angular and Typescript. Even though I haven’t gotten incredibly far in the tutorial, much of the information is coming back to me. I think the Tour of Heroes is one of the best coding tutorials I’ve ever used. Everything is explained clearly, there are links for more complex topics that come up, and all of the code you should have is displayed at the end. There are also summaries at the end of each section that review everything that was learned. I’m glad that I started doing this tutorial because I now feel more prepared and also eager to start actually coding.

Overall our second sprint was still all about preparation. While I do wish we could have started working on something during this sprint, it’s good that we have had plenty of time to learn about the tools we will be using so we aren’t caught off guard when we have to actually produce code. During this sprint I learned a lot about testing with Karma and Protractor and relearned information about Angular. I’m excited for the next sprint as it looks like AMPATH has finally sent us information on the work that we will be doing.

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

On our second sprint, Team FIG definitely got more of the ball rolling with our progress on the project. Following a meeting with a representative from the food pantry, we were able to discuss some of our stories and tasks and what each member was going to work on, and were able to begin in earnest. I felt a lot better going into this sprint as it seems our goals were becoming more clear and it felt like I knew what I could do to make progress.

My tasks was to begin work on a front-end system that the food pantry could use to keep track of the weight they are giving out and automate some of the process of filling out an intake form and determining the proper amount of food in weight. I referred a lot to my final project from CS-443 last semester, developing a sort of “back-end” that enabled me to test the functionality of my front-end. After that was squared away, I began developing the front end. Since exactly what the customer wants still doesn’t seem crystal clear to me, I thought it would make the most sense to take the provided intake form and try to implement it in an online application.

After I wrote all the functions to allow adding/changing of data in the back end, I developed the HTML part of the front-end, adding the input boxes and buttons for submission and making sure they used the right commands. Things I still need to add to the front-end are error messages for incorrect submissions (missing data, wrong input type, etc). It might also be prudent to add some way for authorized users to change customer information that has already been entered, in case of a mistake or changing information. I have also not began working with the CSS, as it has been low priority for me, and I have questions to ask about what sort of style we should be going for. I also have not done anything with keeping a running weight total or adding/removing from that total.

The current issue I am dealing with is a ‘fatal’ error preventing me from committing to GitHub that says the line endings need to be replaced with LF from CRLF, which seems to be an issue with the way Windows handles line endings. I decided this was a good place to stop anyways, as I was having trouble fixing the issue and had done a lot of work without being able to review it with my group. It is unfortunate that we have had three classes cancelled, as it definitely hurt my groups ability to meet up and their motivation to do so.

The biggest task our group has to work on now is creating a functional back-end that will be able to store the information. We have not determined exactly how this will be done yet, but it is something we will definitely discuss so we can begin work on it in Sprint 3.

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.