Category Archives: Sprint 4

AMPATH-WSU Sprint 4 Retrospective

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.

Sprint-5 Retrospective Bog

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.

Sprint 4

Hi everyone and welcome back to another sprint retrospective blog post. This will be the fourth sprint retrospective blog post of this semester. During this sprint number 4, we had many objectives completed. We added some new features like the hyperlinks to the database so that when the tab has been clicked it would navigate to the new link. We reformat the whole prototype so it would look more cleaner and more better-looking product. We decided on what device we were going to scale the application to which was an iPad mini. The scale will only look exact on that certain device and not any other because we haven’t made that a priority. We are just waiting to have a working finished prototype before thinking ahead and making the applications more universal. The styling was easy, once we decided the font, color, etc. Every meeting we had went smoothly as we discuss the future of our component. There some of the stuff that we are still working on like moving the Trello issues to GitHub and investigate the library type things in Angular. So far have been using a device simulator to test the applications as it is the closest thing, we can to think of to test it. We did more research on mobile angular documentation so we can benefit from the perks that mobile angular has to offer. We added a couple of new stories to our sprint backlog. First, as a developer working on ng2-amrs I need to learn about testing in Angular so I can write tests for our new code. Also, as a developer working on ng2-amrs I need to watch the provided YouTube tutorials on the #ampathoffcial Slack channel, to get a better idea about what kind of web applications we’re building. I also started working on the PowerPoint for our presentation because we are almost coming to the end and finishing our application. We also finished some of doing task which we move to done column like for example we moved keep an eye out for Zeplin shared folder – where designs will be to done folder and sign up for zeplin – send info to bio Greg – verify email. There is some other task that we are also working on the side like figuring out the mocking database, duplicating amrs service – possibly using json file to store data. All in all, we are almost finish with the ampath left navigation bar application. Everyone in the group so far has done a good job contributing to the project. We doing a good job coming up with new feature to add to the project every meeting we have. We can very familiar with the method of scrum now and see why it is a great system when working with a group because it keeps everything organize so things will move smoother. I also like to mention that I like where we are at in the project and happy with how the product has turn out so far.

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

Sprint 4

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.

Sprint Retrospective – Round Four

            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.


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.

Sprint 4 Retrospective Blog

For this sprint, I worked on several different tasks to improve the project. Firstly, we needed to get the project hosted onto Heroku, so I added some of the dependencies that Joshua Farrar had created in order to allow it to be deployed directly from GitHub. There were also some minor bugs that needed to be fixed such as typos, missing new line characters, etc. Next I worked on adding build instructions to the readme by working through installing the project on a clean windows install on a virtual machine in order to figure out every dependency needed to be installed. Then I added a landing page to the project which contained a list of all of the available endpoints, however this was a very bare bones solution as it was just a list of the endpoints with no further information. We decided to integrate Swagger 2 and Swagger UI to automatically create more description documentation containing endpoint descriptions as well as a UI to test the endpoints. There was also a minor issue where the example model of the object returned by the endpoint was showing up as empty. This was due to the way the endpoints were returning objects (showing the model of the “Object” class rather than the actual classes being returned).

From what I understand, Swagger gathers the endpoint data in the same way that I did, however, it’s far more detailed and robust. I think if I were to do something differently in this situation I think definitely I would do more research into the possible alternatives to solving each task in order to figure out what the best solution would be before starting to work on it. Had I initially looked into Swagger prior to starting to work on the landing page, I would have saved a lot of time. This is something that I should take into account for the future as it will be important to avoid wasted time whenever possible.

When making the build instructions, I think using a virtual machine to start from a clean slate was definitely the best course of action, as it’s important to see what it’s like for someone who potentially started from that state to get the project up and running. By doing this, even people who already have some of the dependencies installed will be able to follow through the build instructions by skipping steps that they’ve already installed. Although, I hadn’t considered the difference in the installation process between Windows devices and Mac/Linux devices. This project in particular doesn’t require many dependencies to get started, so it’s not difficult to create combined installation instructions, but I think for larger projects it would be smart to separate them. One of the differences I ran into was including the installation of Git Bash while Mac/Linux devices would be able to just use command line.

For the next sprint I’m hoping to automatically update the version number whenever necessary, as it’s definitely bad practice to have to update it in 4 different locations every time. Also, it would probably be a good idea to add an endpoint that gives you a products maximum shelf life and best storage method, given what the data would probably be used for.

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

Sprint Reflection 4

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.

Sprint 4 Retrospective

This past sprint flew by. We did manage to get some work done, although perhaps not quite as much as I would have liked. Still, it was a valuable sprint and we learned quite a bit during it.

Since the last review, we solidified the workflow through which we’re going to be contributing to the project. For each task, we’re going to be creating a branch. Then, after committing it the new branch, we’re going to be creating a pull request for it that we’ll use for development. As we commit, the commit history will appear on the pull request in our GitHub repository, and the progress of the component can be commented on and tracked by others. Once the component is done, we’ll leave a comment saying so, and then it will be be reviewed and pulled into the main branch.

There was a bit of a hold up for some time because we are required to use Google’s Angular Material Design were struggling to identify exactly where to find that. We didn’t entirely realize that the Angular Material Design library was exactly that. Once we did though, we updated the master branch so that all future branches would have compatibility with Angular Material. Our group in particular had already made a branch called Questionnaire-Form before we got it working with Material Design, so we elected to delete this branch and create a new one, named Q-Form.

Also, from what I’ve heard, our back-end plan is currently not going as anticipated. In the beginning, we had plans to either use mocking or to create a server with fake information that we could draw upon. Then, last sprint, we had established that we were going to be using mocking and tying that in to different services that our front end components needed to use. However, it seems as though we don’t fully understand how the back end is currently implemented, and it’s something that we’ll likely need our professor to look even further into before we dive in.

If I could change one thing about how this work has been going, it would definitely be to do more work more often. Currently I think it should be entirely possible to be finishing components almost weekly, and it seems as though no one in the class has been doing that. At least, they haven’t been pushed to the master branch if there has been significant work. However, hold ups with sorting out the development environment and getting material design to function have been a major slow-down, so it is understandable that things haven’t been getting done as fast as we had anticipated.

Going forward, we’re looking to make sure that our new form component on our Q-Form branch works exactly how the Angular Material Form component is designed to work. Right now we have it functioning how it should, with an input field and a submit button, however we’re struggling to get it styled in the exact way that Angular Material is meant to be. Once we cross that hurdle, it’ll be far easier to get components finished, committed, and merged into the master branch.

On to the next one!

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

Sprint 4 Retrospective

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.

Sprint 4 Retrospective

Since the last sprint retrospective blog post, our team has begun to work on some of the components described in the first video. We are referring to the template wire frame layouts from the Zeppelin website, and we are working on form 1d in particular. It is still not very clear how to move forward and what to work on; the only way to make any progress is to keep focusing and thinking about what can be done and what to try looking at. The Angular Materials Design seemed to open the way into making progress. It established a much clearer way to begin the actual programming part of making the components. Everything we have done up to this point seems irrelevant now, but now things seem to be picking up in pace.

I have not begun writing any code myself, so my goal for the next sprint is to start writing code and finish an actual component. With the new angular materials design tool we are using now, this should be doable, since a lot of the code just comes from there, and it’s just a matter of implementing it by changing some small details. Progress has been slow, but progress is being made.

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