Sprint 1 – Retrospective

Our first sprint was less productive that I had hoped it would be. I feel that during the sprint planning phase we should have made sure that everyone was assigned a task to get done working towards a clear goal. For most of the sprint I think most of us were unsure what we should be doing and weren’t sure what we were doing was leading in the right direction. This is something we should have discussed with the product owner (Professor Wurst) set up clear goals. Tomorrow during our sprint planning meeting we should definitely not leave until everyone understands exactly what they need to be doing. If we’re still confused about the requirements we should open up a discussion with the product owner. I feel the team would benefit greatly with a team lead who could potentially answer any questions the team has by handling communication with the product owner. That being said, I’m not sure that anyone would be comfortable with and/or willing to take on that role. There’s definitely a lot to improve on from the first sprint. If we don’t, then we may end up continuing to use our time unproductively. I think everyone wants to do a good job on this project, but may need a bit of direction on what they should be doing.

During this sprint, we spent some time on getting everything set up, such as GitLab, Slack, Trello, etc. We have yet to set up the project itself, however. I think because of uncertainty, most of us spent our time researching by doing tutorials rather than diving into the project blind. Although, we should have confirmed with the product owner everyone’s responsibilities for the week in order to keep the project on track. I took a look at the JSON file to understand the structure of the data, which I think was a source of confusion for many members of the team given that it wasn’t formatted for space reasons. I spent most of my time for the sprint working with GSON to convert the JSON file containing the FoodKeeper Data into objects representing the data in Java. I’m not certain that this is a necessary step for making a REST API interface for this data as I hadn’t done the proper research beforehand, so there’s no guarantee that the work that I did this sprint was necessary. That’s something that can hopefully be resolved next sprint. Also, I spent a little time following through some example REST API tutorials to get a better understanding of what our project may end up looking like. Java 11 seems to have incorporated HTTP APIs directly into the Java SE API (found at java.net.HTTP.*), so this may be worth looking into. It may be beneficial to take a look at the repository put up by the team at Western New England University to see how they’ve set up their project.

Link to the repository for the JSON converter that I worked on for this sprint: https://gitlab.com/worcester/cs/cs-448-01-02-spring-2019/team-fig/food-pantry-json-converter

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Review

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.

Sprint 1 Retrospective

In this blog, I will be talking about our first sprint retrospective. My team is working on making free food pantry software.  In the first few days of class, we were doing research on different food pantry software. There was not much we could find that is open source and free which kinda sucks since food pantries are not for profit. Since these softwares are not free, we could not even demo them, therefore it was hard to get an idea on what this software should look like and what functionalities it should have.

After getting assigned into teams, our first sprint started. The first day we all sat together, there was some initial set up that we had to do so that we could communicate with each other and have tasks assigned to each of the members. We set up a task board using trello, joined the slack group for our team, and shared everyone’s contacts and git usernames. In our second meeting, we were trying to figure out where to start. We know that we were working on a food pantry software but we were not sure as to what we should actually be doing since other colleges are working on the same software as well. Then I saw on the slack channel that the other channel that they needed a REST API. So we started planning.

The first thing that we talked about is what functionality this REST API would have. The only thing we know is that we need this API to read a JSON file from the USDA’s website. After looking through the file, there was a lot of information about food and their expiration and some other stuff like tips on cooking or if they need to be refrigerated. Since we know that we are gonna be hosting this API we discussed on where to host it. There were a couple of options but we settled with Heroku since there is a free tier option although it might be a slower service since it has a thirty seconds time out when your API is not being used. Then we talked about which language we are gonna use. Researching about reading a JSON file, most of the tutorials were in Java and since we all have experience using Java, we have settled on it. The next thing was setting up an initial commit on gitlab for our project. Most of it was done by Sean and he was handling most of the task board as well. While the others work on figuring out how to host our API on Heroku.

To host a Java application on Heroku you need three things:

  1. Java 8* 
  2. Maven 3*
  3. Heroku CLI and an Account

After that, we researched how to read and write a JSON file. We are using JSON.simple to parse the foodkeeper.json file.

Steps I took:

  1. Download JSON.simple jar file
  2. Import the jar file into Eclipse by adding it to your project’s build path
  3. Added json.simple dependency into the pom.xml file
    1. <dependency>
          <groupId>com.googlecode.json-simple</groupId>
          <artifactId>json-simple</artifactId>
          <version>1.1.1</version>
      </dependency>

There are a few tips on reading the JSON file.  JSON file consists of array and objects so you just have to create an object or an array depending on what you are trying to get.

ex. Array [], Object {}

A JSON file might have something like this:

“sheets”: [
{
“name”: “Version”,

“data”: [

That means that there is an array called sheets, and an object inside the array called “name”. You can get to it by creating a JSON object first and then creating a JSON array like this:

Object obj = new JSONParser().parse(new FileReader(“foodkeeper.json”));

JSONObject jo = (JSONObject) obj;
JSONArray sheets = (JSONArray) jo.get(“sheets”);

We still have a lot to do, so hopefully, on the next sprint we could implement and get all the necessary information from the JSON file and have methods to return them as an object or as a JSON file.

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

Sprint Review Blog #1

Hello and welcome back to benderson’s blog! This week I will discuss all the events that occurred through my teams first sprint in our Software Capstone. Our sprint started on February 7th and ends today February 19th. Since it is our first sprint, we were just working out the kinks and getting the basic things done for our food pantry project that we are working on for our school. This week we tried setting up basic slack channels, a trello board and a github group so our group could work together and get tasks done fast and efficiently. There are five members in my group all together and we all are going to give our best to this project. Besides the basics we weren’t able to really do anything this sprint since it is very early on and we don’t really have much to work off of. Actually today we got some specifications from the client that they want in the API of the software we are making so we will be able to proceed next sprint on those tasks. Something that we were asked to do that we weren’t able to finish was creating a REST API. We didn’t really know how to approach this, especially since we were notified that the REST API may become obsolete since the client may have something for us to use in the end.

A couple of sources that we used for the first sprint were: https://catalog.data.gov/dataset/fsis-foodkeeper-data      https://github.com/google/gson

The first link is a link to a food pantry type program that helps their users understand how to maximize the freshness and quality of the food items in their pantries. The reason we looked at this particular application was to get some ideas for our own food pantry software that we are going to have to make for the project and figure out what are the bear minimums we would need to have a successful application for the food pantry at school. Later on, after we have all the bear minimums for our food pantry application, we would add more features that are required by the client that we are working with. The second link is to a github project that will lead us to be able to parse a JSON file that we got from the food pantry client, this will allow us to separate the items and make the JSON file more readable and usable for our application.

This sprint provided both some easy tasks and some tasks that required some research and team communication and even though they weren’t all completed, I’m still happy with the progress that my group is making on our project. Getting the REST API and parsing the JSON file is next on the backlog to complete hopefully by the end of next sprint. Next sprint, my team and I will come out like the bulls in the bull run in Spain and try our best to get the next tasks on the next sprint done as fast and with the most quality as possible. Something I think we could approve on for the next sprint is to maybe stay on task a little more when working in class but other than that I think we did the best we could for this sprint. Something I found cool about this sprint and this project as a whole was the stand-ups that we have to do for our groups in slack which is a very interesting way to tell the members of our group how we are doing on the project and what could be impeding our progress. Thank you for joining me this week on benderson’s blog, I’ll see you next time.

From the blog CS@Worcester – Benderson&#039;s Blog by Benderson's Blog and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

This past week has been about trying to get the ng2-amrs environment working, and trying to get through the errors that show up when running the npm start command. I have learned a lot of the steps to take in order to approach this problem, although I am still not finished with it. I am not sure that I would proceed differently, I just think it would have been better if these problems were already known, since everyone is having them, and it would have been better if there were more instructions to deal with these expected problems. Most of the approach involves googling error messages, which can definitely be applied in other situations.

Most of the week was spent looking up different npm, ng and node commands, googling error messages, and trying different combinations of the commands and re-installing things after nothing worked. The reason that I took these steps is because I really do not know what I am doing and running through permutations of commands seems to be the only way to move forward to get the program to run without errors. A lot of the process involved referring to the slack channels, where teammates and other teams have run into the same problems and found solutions.

The ng2-amrs readme on the github page says to run the ng serve command for a dev server. What it does not say is what to do when this does not work. A guess at the problem involves version issues with angular, npm and node. Different versions were attempted to try to solve errors. Most of the steps involve googling the error message, which leads to a stackoverflow post that says to install a certain thing that solves the problem. When it does not solve the problem, it becomes very unclear what to do next. Changing versions and re-installing things has not seemed to work.

I have deleted and re-cloned the ng2-amrs folder from github. When I run the ng serve command, I currently see an error Could not find module “@angular-devkit/build-angular”. I google this and stackoverflow tells me to run npm install –save-dev @angular-devkit/build-angular. After I do this and re-try ng serve, a few more errors show up that do not seem to be as easy to deal with. One teammate found npm-check that will list missing things and things that are out of date, so I installed and ran that and had it automatically install everything it found using npm-check -y. After that finished, I re-tried ng serve, and it came back with a new error about styles.scss. I searched the error and found a command npm rebuild node-sass to deal with it. Running ng serve again, now I get some typescript errors. I check the group slack channel and see the command npm start, so I try that, and the next error I see is Error: Can’t resolve ‘pouchdb/dist/pouchdb’. I try running npm install and that brings back the scss error, but this time the same command that fixed it before does not fix it anymore, and it complains that I use a 64-bit operating system. I downgraded to node 8.12.0 and re-tried fixing styles.scss and running npm start. It actually seems to be working now. It says compiled with warnings, I open localhost:3000 in my browser and the ampath page comes up.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Use Your Title

While you work in the software industry, you can be promoted, formally or informally, to some high position that sometimes do not fit to your knowledge. You can be promoted to senior or lead positions, but on the other hand you have to explain away tue difference between your skill level and your job description. … Continue reading Use Your Title →

From the blog cs-wsu – Kristi Pina&#039;s Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

WSU x AMPATH || Sprint 1 Retrospective

Sams Ships (5).pngFor my first sprint retrospective, I wanted to start off by introducing what kind of project my team is working on and what we are hoping to do with it before I move onto the description of what is happening.

The project I will be working on for the rest of the semester has to do with AMPATH (Academic Model Providing Access to Healthcare); if you have not yet heard of it, it is a healthcare partnership based in Kenya made up of different organizations. Part of my sprint was getting more familiar with who they are and what we could potentially do to help them. It looks like they are mostly trying to ease or log more operations technology-wise to help people.

Our main tasks for this sprint were of course getting to know my team (classroom-wise) and getting our set-up tasks sorted. It is my first time using Trello for something and as a visual learner or visual person in general, I found it very convenient being able to see our “Product Backlog | Sprint Backlog | In Progress | Done” lined up. We decided to start by organizing because of course that is usually how projects are best done and kept on track. Along with setup tasks, we began by cloning the project and then installed Karma and Protractor.

So far, I cannot say anything failed (and hope I will not have to report that anytime this semester for the sake of us progressing) but I hope we will have more concrete plans for what is coming up next for Sprint 2. I think it also has to do with me as a person being so used to always working moving forward or on with the “next thing” and it’s just different not having that yet. That way there will be things to continuously progress on and track more efficiently.

However, if I were to proceed any differently; I would have gone back and gotten a little more background knowledge because I feel like we tend to tell ourselves “I’ll just go back later and review” but of course that doesn’t always happen. It’s just a fact when you’re a highly involved student who works on the side; but when you plan or set some time for yourself you will be able to do what you need to.

A majority of what was done during this current sprint consisted of trying to understand and introduce ourselves to Karma; which is a test runner for JavaScript.

If someone else were to follow these steps; I would recommend going in this order: Getting to know your teammates, making sure the team has a solid enough understanding of what project we will be contributing to this semester, beginning setup tasks, and then setting goals for when you should check certain things out.

Overall, I enjoyed this first Sprint as I did not feel too much pressure in terms of what needs to happen yet so we can ease into producing software that will help benefit AMPATH.

 

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

Sharing is Caring

This week I read about the Share What You Learn pattern. The pattern is all about sharing the knowledge you gain with your peers. After all, what good is all that knowledge if you don’t share it with the rest of the world? Making good use of the pattern ensures that you and everyone around you will be up to date with all need-to-know information, and gives you a good opportunity to both brush up on your teaching and communication skills and also discover what your peers know that you don’t. Everybody benefits when you share your knowledge, as it allows your peers to focus their efforts on other endeavors that haven’t been solved yet.

It is not always easy to share what you learn. Sometimes you are engrossed in your own work and don’t want to take the time away to help someone else. Maybe you think what you know is obvious and not worth explaining. Either way, it is always worth the time to help out your coworkers or fellow students. First of all, when you need help, it will be good to be able to rely on others. Second, everyone being at the same level opens up more opportunities for learning and growth.

My biggest obstacle with sharing what I know is how to communicate effectively. I am a poor communicator, and often lose myself over which words to say. It can be hard for me to effectively teach something to someone, especially with no time for preparation, as my train of thought tends to go all over the place. Knowing this, I need to work on methods of communicating information and think more carefully about how I am saying something and how it is being understood.

In conclusion, Share What You Know is a useful pattern, and one I aim to improve at. Sharing knowledge across a team is better for all the individuals involved. The more you know, the more time you can dedicate to your work and the more diverse kinds of problems you can solve.

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

Sprint Reflection 1

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&#039;s Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Sprint 1

This week was sprint 1. Sprint 1 was a rather simple and basic sprint that started with getting into teams and diving into the workload. The most work that was done for sprint 1 was done before getting into teams. Getting setup for the sprint required a lot of work, like filling out the CATME survey and getting your availability schedule together. Once we finished our prep work for the team formation, we got into our groups. Once we got our assigned groups we began sprint 1. Our first assignment was given to us by Professor Wurst. We had two tasks, one being to prepare a REST API for the food pantry and the other being finding a way to host a json file from a government organization. I took the lead on finding out how to host a server for our json file while other members of the group worked on researching REST APIs and figuring out more information on our project. Professor Wurst suggested a few options for hosting our server for free, digital ocean and heroku. I looked at digital ocean first but quickly found out that it actually costs money (a per month subscription) for us to host a server to store our json file on. After finding this out I looked into heroku. Heroku is a free service that lets you host a server for free (albeit they do limit you to a certain amount of server size/space as to avoid people from abusing the system by hosting large applications for no cost). I took on the task of doing a tutorial on heroku, which was rather simple. I went through the windows powershell to follow along with the survey. I learned a few of the heroku Java application specific commands, such as preparing the app (this was a simple process that uses the git commands to clone/pull/fork projects from github/gitlab), launching the app (heroku create), viewing heroku build logs, and scaling dynos. Dynos are specific to heroku, and are basically small containers that live within the heroku server that run your applicaiton. You can scale the amount of dynos per application to affect its performance (however you are limited to a certain number of dynos per application), and I learned that scaling down to 0 dynos does not allow it to launch the application. I feel like heroku is very similar to angular in the sense that there are commands to build/launch/diagnose applications, however angular is more of a “coding” application because you can edit code and run it all within the angular platform. Another large difference between angular and heroku is the language used to host the servers. We as a group settled on heroku for Java because we are all most comfortable using Java as it is our primary programming language. After completing the heroku tutorial I looked at the git repository that was shared with our group by Professor Wurst. I think that as a group we are unsure where to go from this point, as we have not been assigned any solid tasks yet. My hope is that for sprint 2 we can dive into the project more and will be assigned tangible tasks that we can complete for our end users.

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.