A reflection on what I learned form this week’s activities is that everything is easier said then done. We are given a sprint board and should strive to meet the objectives by the end of the sprint. However, it is not surprising there is issues to be accounted for during the first sprint. As expected, the amount of communication outside of class is lacking than when we are interacting with one another during class. In regard to this, the solution is to make sure that everyone is fully aware that our only source of communication, Slack, is important to check every day. As it also affects our course grade due to our attendance with the sprint standups. This is solution is also applicable to any problems regarding communication in the future as it’s simple to address but execution requires effort.

At the start of the sprint, our
backlog started with two items to complete. The first item is summarized to
speaking with other university professors about what information is valuable.
The steps taken to ensure we have contact with the other professor was to join
the appropriate slack channel. In this case, I joined the LibreFoodPantry slack
channel with my respective group members and under the “food-saver” channel.
Our group got information indirectly from another team’s question regarding the
REST API addressed to the other university’s professor. In response, we learned
that they would like to know how long an item can be eaten opposed to its
actual expiration date, and possibly a way of filtering by food categories.
This is the first step but there is a roadblock, even if we know what is needed
from the client, if we don’t have a place to begin then it seems pointless to
know what they need.

            The road
block is what leads to our second item in the sprint backlog, which is to
develop the REST API interface to manipulate a JSON file. From the Department
of Agriculture’s Food Safety and Inspection Service, we are provided a public
JSON file to work with.

The first step is to figure out
where to start, and my approach was to tackle a small issue that was mentioned
beforehand, which is a place to store, and pull the JSON file from. In which, I
spent about an hour looking up information about DigitalOcean and there was a
way of getting 12 months of access to DigitalOcean for free from GitHubs
Student Developer Pack. However, I put this information on the back of my mind
since another member was looking into Heraku.

In response, I chose to get started
on researching about REST API. The first site visited is restfulapi.net which
introduced the concepts of REST. Next, since the group unanimously decided to
work with JAVA as the preferred language, I decided to revisit my favorite java
IDE, IntelliJ IDEA. On the JetBrains site, it provided a tutorial to REST API
web services which I read and got introduced to the JAX RS library. Lastly,
after completing that tutorial, I learned that it was not the place to begin
this journey and found the “Building a RESTful Web Service” with spring
tutorial. In conclusion, I’m still working on the spring tutorial and that is
where this sprint ended for me.

What I produced this sprint:

https://gitlab.com/irresoluteduck/spring-boot-tutorial-example

References:

https://catalog.data.gov/dataset/fsis-foodkeeper-data

https://www.digitalocean.com/

https://education.github.com/pack

https://restfulapi.net/

https://www.jetbrains.com/help/idea/restful-webservices.html

https://jersey.github.io/

https://spring.io/guides/gs/rest-service/

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.

My software development class is structured to feel more like a real work environment. In this way, we practice completing tasks on schedule in a “sprint” format. This means each student is assigned a development group and communication is emphasized heavily. We began the semester by signing up and downloading the required tools.

We made sure everybody joined the same slack channel, so we could share information and update each other as we continue the project. On this slack channel, we are required to periodically enter what we have done, what we are doing, and any roadblocks we encounter in order to keep the rest of the team informed on our progress. Various slack channels are also set up so that we can ask questions to other groups who may have similar obstacles. Interestingly, we found that collaborating through the other channels was the most effective way to solve our recent issues.

We also used a website named trello.com to organize our project and condense it into workable tasks. This includes a product backlog for general goals, a sprint backlog for tasks and stories we aim to finish before the end of the sprint, a “doing” column for tasks that are currently underway, and finally a “done” column for completed tasks. We spent some time making sure the organization was set up correctly and that everybody was joined in on it. In class today, we prepared new objectives for the next sprint and archived old completed tasks.

In the first few days of this sprint, we also made a repository following the project we will be contributing to this semester, AMPATH/ng2-amrs. Everybody in our group cloned the project from the repository, so we each have the ability to view a local copy. Looking further into the README file, we gained an understanding of how to build, test, and access the server associated with the project.

Next we had to make sure we had a proper development environment to run the project. This included getting everybody the latest version of NPM, Gradle, Insomnia, open MRS, and an IDE of choice that runs typescript, for that I chose Jetbrains Webstorm with a student license. This task took us the most time and still is not finished, only one group member so far is able to run the project successfully. Some of the software we installed, namely Gradle and Insomnia, we may not end up using, so ultimately I think we can get better at limiting redundancies by further defining what is required to complete a task.

By the time our next sprint is over, we aim to have every member able to run the project, then we can start contributing to it. It seems that each group member has their own issues with starting the project, which will slow us down since we may have to work through new problems for each member. We also have sprint backlogs set up to become familiar with the programs Karma and Protractor to help us test the new angular code.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

Up until this point, it has felt like we have mostly been trying to simply get our project to run.
I am not sure if the other teammates have felt this way, but I am anxious to contribute. It would be nice to have something to show for our efforts. It has been slightly frustrating, but I should have expected this slight speed bump.

In light of this, I have not been able to do some of the less important tasks that I wanted to get done. I wanted to research about testing in angular. In addition, I have been wanting to complete a tutorial to refresh my knowledge on Angular. I feel that this is one area that I would really like to round out my knowledge on because I feel it is somewhat lacking.

The bright side is that I was able to get my code to build and run without as much trouble that many of my teammates and other teams have experienced. Also, by the end of yesterday (2/19/19), with some input from me and some of the other teams, it looked like all of us got it to build and run.

A takeaway from this is that I should dedicate at least a sliver of my time everyday to dedicate to this class and project. In the apprenticeship patterns textbook, there was a quote by CS Lewis that I particularly enjoyed, which said “The only people who achieve much are those who want knowledge so badly that they seek it while the conditions are still unfavourable.”

I should apply this to learning this information. Even dedicating half an hour a day is better than nothing. I’m going to be a realist and say that on some days this class might be put on the back burner because of looming deadlines and exams from other classes, but I should never let that interfere with doing even a small amount every day.

In class yesterday, the code did not build and run right away, so I decided to go through step by step the commands that I got it to run the first time. You can imagine how nervous I felt when it did not start right away. I thought that since it had already been built, I could just run the last command to start it. It turns out that I had to go through them in order to get it to run the second time around.

The following is a list of commands that I used to get it to run, in this order:

(1) ng serve
(2) ng build —prod
(3) npm start

Note that this is run from the command line in the top layer of the directory that you have designated for the project. After these commands are prompted, go to your web browser, and type the following:

http://localhost:3000/#/login

For node or module problems, I found the solution was to do the following command:

npm rebuild

I experienced this when I was trying to rebuild it yesterday. I breathed a sigh of relief when it was such an easy fix.

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

I think the most important lesson I learned this past week was that front end development can be extremely annoyi– ahem. Particular. Yeah, that’s the word.

In all seriousness, for our sprint this past week we were given 5 tasks. We needed to create an organization for our team in capstone, fork & clone the ng2-amrs repository from AMPATH’s GitHub account, read through its’ README.md file, set up the development environment, and then learn about testing with Angular. As it turns out, this was a whole lot more frustrating than we originally anticipated. When setting up the development environment using the ng2-amrs repo, the entire class got errors. People had issues with sass, issues with CSS packages, issues with typescript and issues with javascript memory management. Thankfully having the slack was an extremely helpful tool because not only could we offer catered help to our individual team channels, but the entire class was working together in order to get things up and running. As it turns out, there are a lot of ways that an angular/node project can encounter errors purely based on the environment that you’re running it in.

By FAR the most difficult thing was getting the development environment set up for everyone in our team. I was running on Mac and everyone else was running on Windows. The common issue amongst us was an issue with the styles.css or styles.scss file in the /src folder in the project. For the windows users, the specific error they got was “Node Sass does not yet support your current environment: Windows 64-bit with Unsupported runtime (57).” Professor Wurst found that it was a problem with sass, which required them to run npm rebuild node-sass. After this, it seemed to fix that issue. Since I was the only one who had a mac, that was not an error that I got. When I got my error, it included “Can’t resolve ‘ion-rangeslider/css/……’. After a big of digging, it seemed as though there may have been a package I was missing regarding the ion-rangeslider, and so I found the tool npm-check, which allows you to check what packages you have installed in your project and what version is the most recent one. From there, I discovered that I didn’t have the ng2-ion-range-slider package, and after I installed that, my styles.css issue was resolved.

Once past the styles.css issue, it seemed like everyone encountered an issue when trying to resolve a .ts file. My teammate Harry emailed AMPATH directly about this, and they told him that he needed to run ng build –prod in order to get the production build of the server, as opposed to just running ng build. This worked perfectly and solved that typescript issue for everyone who encountered it. However, the very final error that most people were getting was an issue with the javascript heap running out of memory while building the server. Upon a little bit of googling, Harry also found the solution to that issue on this Stack Overflow post. Finally, the server ran and built as it was intended to — but not after much trial and error.

Along the way, there were constant issues with angular and npm versions that needed to be resolved. I can’t even tell you how many times I ran npm clean cache –force, rm -rf node_modules, rm -rf package_lock.json, and npm install@x.x.x just trying to figure out if the issues were a version or installation problem. I actually do feel like I learned a lot about the environment that Angular and Node need in order to run, just from digging through files and trying to see if all that was necessary was a small change to a .json file. There was a lot of reading, exploring, and self-development involved in finding changes for the issues, especially since we haven’t had a tremendous amount of front end development experience yet.

Currently, we’re all working on understanding testing in Angular a bit better and we still have one group member encountering technical difficulties. His seems to be partially related to his actual physical laptop which is hindering his progress, so that will likely get sorted out with time. Overall I think this sprint was really great way to kick off the projects. I enjoy my team and think we all work well together. Excited to continue onwards!

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Our very first sprint went successfully by our measurement of done. We had five objectives to accomplish in the week long sprint; creating a trello board for our product and sprint backlogs, creating a github organization for our group, forking and cloning the AMPATH repository, setting up our environments to run the project, and learning about testing frameworks Karma and Protractor.

As it was our first sprint ever, we all learned about setting up and organizing the foundation of a group project, particularly through the lens of Scrum. We familiarized ourselves with the tools and processes Scrum uses that keep our team on track, such as the trello board and standups.

Also, we learned the value of inter-group communication, as our success is in large part due to the help of the entire class when it came to resolving errors. The organization skills and teamwork we have been practicing will definitely set the tone for how we will approach our goals in the future.

The beginning objectives of our sprint were straightforward and we accomplished them in a short amount of time. By the end of the first class we had set up our trello and github groups, forked and cloned the APMATH repository, and prepared to set up our environments to build the project.

That is where we ran into problems. When initiating nodejs to build and run the application, we all had completely different errors from each other. In my case, the first problem I had was building some of the modules. Thankfully,  Professor Wurst was able to help me solve the issue with the node –rebuild command, which drastically reduced the amount of errors I was getting.

Still though I had a few more issues. I knew we were getting close to being able to build the project because every member of our team was getting the exact same error messages. Sam, collaborating with others in different groups, was able to solve the issues by using the combination of ng build –prod and npm start commands. I admit I’m not entirely sure why that solved the problem, and it would be wise for me in the future to take a closer look into what these commands exactly do, will help me avoid errors in the future.

After a few more troubleshooting attempts, everyone in our team was able to build the project on our own computers. I was relieved at this because we were at the end of the sprint, and I was concerned that solving the errors would take all the time we had, and not allow us to learn about the testing frameworks.

Thankfully, Sam was able to help me with my remaining errors, so I had some extra time before the end of the sprint, so I did research and compiled summary notes for testing in Karma and Protractor. That really worked out well for us because we were able to essentially split the job and kill two birds with one stone. If possible I would like to apply this process in the future. While we definitely need to get more hands on and technical about learning the testing frameworks, I am satisfied to say that we realistically accomplished all of our goals in this sprint.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

Our first sprint was rather difficult and unproductive. We did not start off with many clear goals, so we weren’t able to move forward much and had no clear direction. This is definitely a huge hurdle and one I hope we can get over soon. Our group would definitely benefit from clear, tangible goals and perhaps a little more structure. Other than that, we had many productive and insightful conversations about the needs and features necessary to the application we are trying to develop for the food pantry.

One of the things I worked on a little bit was trying to find a way to interpret the a data set so that we can further search and manipulate it. The data source was provided from our professor and our goal was to find a way to display that information in a way that could interact with a REST API interface. A great help to this end was an article found by group member Andy Pham. Using the exact code by the provided article works to some degree, although the field headers need to be changed to appropriately handle the data set for the food pantry project. This doesn’t seem like it will be too difficult moving forwards, although there is still a little work to be done in this department to finish it up. Overall, in this task I think we are headed in the right direction and nearly complete. However, I question how useful this work will be, as we may find out that a lot of this beginning work is already complete by another group or another university.

Another big goal of ours is to set up a server that can run this REST API so we can use it across the network. My team members have been doing research into what resources we can use and what would be best, however it is a choice that is hard to make when we cant consider any of the other needs of the project (yet). This server doesn’t need to be big or complicated, as with what we have we would only need to host a small data set as well as a pretty simple REST API interface to interpret said data set. However, we are unsure where this server will be hosted or who will front any potential costs.

It is challenging having no practical or finished work to show, as it highlights a lack of progress and means we have no reference for how we are performing. However, I think as the ball gets rolling and our project goals become clear we can build up momentum and reach our goals as they come to us. In the meantime, Team FIG has been using our time to discuss what we could potentially need to work on and other elements of the project. We have looked up different universities and food banks solutions and what programs they used to maintain their databases, and are considering what might work for our University.

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.