Hello my readers and welcome to my next blog post. For all of you who have followed my blog, this is the 4th sprint retrospective and I will be talking about how sprint 4 went for me and my team. For all you guys who are new to my blog, this is a summary of the what me and my teammates have been doing for our capstone class.

If you guys remember last time, I mentioned that me and my teammates decided to do the search bar task where users and doctors can search for patients in their application by putting their name. While the development of the search bar has been done on our end, we have been thinking for options of where to actually put the search bar. One of my teammates Kristi, suggested to the professor that would be better for us to push the search bar task development after the tool bar has been added to the application. While trying to support our idea with reasons, professor K. Wrust agreed with us and talked with the other team on charge to push the changes to master. As I am not very sure on how the development of the other team was going, we were told that we had to wait a bit as the professor wanted the other team to do the development of the tool bar differently.

As we were waiting for the other team to push the changes to master, we were starting to talk about what we were going to do next as a search bar was not ‘enough’ in our opinion. While there is a whole application to be build,  not having the right way of communicating with our user is a problem.

When I started this class, I was really excited on the output that we were going to have at the end. However, now in the middle of the semester I think that despite the learning process which has been great, we don’t really have a big output to show. One of the ideas that came into my mind, was to ask the professor to have other teams work in the web application for this project and we would work in the application ( IOS or Android whichever the user would prefer). While the professor found the idea interesting, we were not sure how long it would take for the user(customer) to accept and approve it. Therefor we just went back to the phase of trying to plan what to do next.

I would say that if I were to go back I would somehow try to have a better communication with the client, as it is very important in a development project.

Unfortunately, this sprint wasn’t a big progress on our end but we are not getting discourage as we are probably going to come up with something interesting for the next sprints. We will be done with classes soon and for this class we are going to give a presentation on what we did, what we learned and how the work in team was.

I am so looking forward for the next sprint as I am sure we will be coming up with a great idea on what to do next. Stay tuned for the next sprint as I am sure I will have great news about our progress.

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

It’s time for Sprint-5 Retrospective Blog Post. As you are probably aware by now, during this semester I will be working on a AMPATH project with a team I was assigned on by my Software Development Capstone professor. As part of our assignment we are assigned to complete a Sprint Retrospective blog post at the end of each sprint. As of Today, April 23rd, 2019, we have completed Sprint-5. During this fifth sprint we were able to get some task done and some task started during this past fifth sprint cycle.  For sprint-5 our task involved the following:

1. Collapse nav-bar when clicking on button to go to the new page -> ME
2. Add button in nav-bar to redirect back to the home screen -> ME
3. Adding sub-menus to the existing buttons – Mike
4. Move buttons farther down the nav-bar – kat
5. Change colors of app – kat
6. Left navigation bar – scaling -> Tim
7. Start the final presentation – Quoc

During this sprint my team and I all focus on our individual task we assigned to each other. For this sprint one of my task was to figure out how to collapse the nav-bar when clicking on the button to go to the new page. My other task is to add a button that redirects you back to the home screen on clicked. Each of my team mates had task which I have listed them. In this retrospective blog I would only discuss my task and what I have done so far.

From the task I was assigned (more like picked) I had to make the nav-bar collapse once any of the button was clicked on to navigate to the next page. This took me a little while to figure out but one I did. I realize how simple this step truly was. The way I did this was by adding “(click)=”drawer.close()”” for each button after “mat-button”. The way this work is that when you click on the button it leads you to the page expected and closes the nav-bar. For my next task I have to add a button that will redirect me to the home screen once the button is clicked on. This task I have not completed I have started it but I have not finish this task yet. For the next and final sprint I hope to have this task completed. 

I can say that during sprint-5, I’ve learned a little more about Angular Material, and how to get the nav-bar close on click. For this sprint I am still doing some reading and tutorial on Angular Material because I found its tool pretty interesting and worth learning the different cool things that can be done. In light of everything I learnt there is nothing very special that went on that requires details explanations or strategies that would be required for handling things differently next time. That being said this project is still proving to be fun and interesting. So far this project is going without a hitch, and it’s not making anything more complicated than it has to be.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

This week wraps up our fourth sprint in our software development capstone class. This sprint saw a lot in the way of front end development. One of the large tasks we were able to complete during this sprint was figuring out how to store the data that was entered in the intake form sheet using a local javascript  server that can be run through the terminal using angular. This was developed by Johnny and was attached to the front end file folder where it now lives. At first we were working in the original repository and had the project all together. This seemed fine at first but we quickly realized that not separating the repository into frontend and backend sections would prove to be a major problem down the line. We ended up having to fight with ourselves every time we wanted to run or even open the project because files were crossed and mixed up because we did not have proper file directory setups. One major problem I found right off the bat was not being able to run the front end of the project because I would get an error message in the terminal saying something to the effect of “You must be in an angular project to use angular commands”. I encountered this error after trying to run ng serve –open to get the project running. I was in the root directory for the project, where I should have been. After doing some extensive trial and error testing my groupmates and I figured out that the terminal had to be run in a subdirectory (in this case intake-form-master) which was below the root, scr, and app folders. While I thought this was strange I didn’t think much of it because it ran and it worked. We should have looked into this more because it turns out we had a massive issue. Though our project was in github and therefore a “git” project, we somehow were lacking a git.ignore file on the very top level of the directory. This went unnoticed, and ended up becoming a massive issue. It seemed like every time I pulled the most recent version of the repository I would have to scrap what I had before otherwise I would get all different kinds of error messages. This was annoying due to the fact I would have to wipe all the project files off my local file directory and then clean install from github just in order to get it to run. After a long discussion with the professor and a good hour of troubleshooting and head-scratching, we figured out that our big issue was coming from this missing git.ignore file. The basic gist of this major file is that since it was in a subdirectory and not on the top level of our repository, every time someone pulled or made a change or did anything to/with github, everybody’s local machine paths were being pulled onto your personal machine with every clone or pull of the repository. Since no two path setups are the same between machines, you would get a – for lack of better words – big spaghetti mess of pathing and branching and basically git would freak out and it would give so many errors because it was having trouble figuring out where to push/pull/do anything. To remedy this, we ended up going with the nuclear option and eradicated the old repository, set up a new one with the most current working version of the project, and had our professor merge our new repository with the parent organization. This time around we have a git.ignore file at the top directory to ignore all those different paths and other things that were confusing our terminals, and we separated the project into frontend and backend folders, which are proving to make the workflow process go much smoother. At the very end of the sprint we had planned a meeting with a food pantry representative, which will occur during sprint 5. Next sprint we hope to see some major advancements.

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.

            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.

Our fourth sprint started out a little better, with us fixing the issues, stories and tasks assigned on Git so that our group could be more clear on what was being done and by whom. This also helps us communicate with the other food pantry group outside of class. Narrowing down our stories and tasks helped us more clearly define our goals and what we were working towards. Once we were done fixing the stories and tasks, we discussed who would be taking on what task.

I took on the task of adding a weight counter component to the intake form. We first had to determine exactly why the weight was being kept track of and what changes needed to be logged to better implement the weight system the food pantry needed. After determining some of the needs of our clients, I started working on making the new component. However, our group quickly ran into issues as we had a lot of difficulty in maintaining our git repository. We spent a good class period trying to fix some of the issues we were having just getting the working code onto our local machines.

As it turned out, our git.ignore file was located in the wrong place, and a lot of the local files that aren’t supposed to be uploaded and committed were being placed on the group repository. NPM and NG commands were not working properly and things were pretty disorganized. It was hard to get a working version of the front end so that I could begin to make my changes to it. After a long class discussion with the Professor, we discussed better ways to make sure the repository isn’t getting dirtied with unnecessary files, and talked about how to add changes to the main branch and utilize pull requests accordingly.

Now that we finally have a working copy of the form back on the repository, I have begun work on the weight counter again. It is going to be a new component that tracks a current weight, and can add/remove to the weight depending on user choice. Other considerations are storing the time and date that changes are made to the weight, and making descriptions for weight changes. Other future things to consider are logging which Student ID takes out weight so that customers can only receive from the food pantry once a day.

This sprint was very stressful as our group fully realized some of the issues that can arise from git repositories. Although it was mind-racking to try to figure out what the problem was, it was very useful exposure and practice to some of the mechanisms of git, as it will doubtlessly be very important in the future. Although I am still wary that I can use git commands perfectly, I am definitely much more equipped to deal with repository related issues in the future, and am more aware of some potential issues that can arise from a misplaced git.ignore file. Hopefully I can avoid some of these problems in the future, as git problems can get annoying fast.

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.

I am confident that all my group members would agree that this fourth sprint has been by far the most productive sprint to date. We accomplished a lot of work, most notably creating a few different prototype components for our multiple patient list tab structure. We learned more about how to put together our component, as well as began to look at the Ampath specific services so we can adapt our model to their overall system.

The first thing we did was created an empty branch on the main Ampath Github repository which will serve as the connection branch between the master branch and the branch with our code. After we completed the pull request for our empty branch, we were able to use ng generate to create all the necessary files and folders for our tab component.

With all of the setup completed, we were able to start experimenting with angular’s given component materials, and after verifying that we were allowed to use them under the MIT license, we each created a basic model that best fulfilled the design goals of the multiple patient list tab component. While we still are a bit fuzzy on how to implement the tab component for the cards, we definitely have made significant progress in both producing a working model as well as further clarifying the concepts we need to implement.

At the end of the sprint, when we were reviewing the features of our prototype components, we committed our branch with out working model to github, and began to discuss with the team working on mocking the server about what types of data structures and Ampath services we need to use to make communication with the server easier. This is our current task, as we need to figure out how to communicate back and forth, so we can move on to the next step of our design. Once we have a clear understanding of what types of data need to be sent back and forth, we will be very close to creating our minimum viable product.

We as a team and me in particular hit a couple of road blocks which hindered our understanding or progress, but ultimately solving them led us to a deeper understanding of the specific needs of implementing our component. The first hiccup I stumbled on was the decision to use Google’s material design or Angular’s built in materials. After finding out that Google needed a wrapper class and a few extra dependencies, we reached a consensus to use the simpler angular materials. And as I said earlier, we are still hung up on deciding on and implementing Ampath’s services. Finally, we are still not sure exactly what type of data is needed to be displayed on the tabs components for each card.

I am very satisfied about the amount of progress that we achieved during this sprint. We not only have an interactive working model, we all also have a much better understanding of not only how to implement the features we desire, but also a clearer picture of our end-game design goals. The roadblocks we hit were only there because of the amount of progress we completed, which is a good sign to me. After we figure out what our next steps are and implementing them, we should be able to communicate with the server and start our later stages of development.

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