This semester for my Software Development Capstone course we are working on a AMPATH project working on a point of system by Ampaths Clinic. For this semester I will be working on this with a team. This blog is actually Sprint-2 Retrospective blog post. As part of our assignment we are assigned to complete a Sprint Retrospective blog post at the end of each sprint. As of Today, March 7th, 2019, we have completed Sprint-2. During this second sprint we were able to get everything we intended to get done during this second sprint cycle.  For sprint-2 everyone in the team had the same task except they where more individual kind of task. These task were:

1. As a developer working with ng2-arms I need to set up my development environment so I can build/run ng2-amrs.
2. As a developer working on ng2-amrs I need to learn about testing in angular. In order to be able to write test for our new code.

From the list of task above I was able to complete both task listed. Although, there is more to learn about testing in angular I was able to at least learn the basic of it. I learned about testing in angular by following the karma and protractor tutorial. These tutorial were very informative and straight forward. In my opinion, from the task of this week… learning about karma and protractor was not as complicated as trying to build/run ng2-amrs. Trying to build/run ng2-arms on my PC took a lot of researching and configuring in order to be able to successfully build/run ng2-arms. During this sprint I had better luck… where I was able to get the ng2-arms project to successfully build/run on my PC.

During sprint-2 I learned about testing in angular using karma and protractor. Karma taught me how to unit test on angular, and protractor taught me about end-to-end testing and its basics. These are testing tools that are going to help me test the code develop by my team and I. During this sprint I also, learnt a lot of different ways to handle problems when trying to build the ng2-amrs and the different ways to fix a problem when trying to build/run ng2-arms. I also realized that not everyone might run into the same problem when trying to build/run ng2-arms. What worked for me was opening Git bash in the ng2-amrs file typing “npm install”, I then “ng build”. When I did that came across a problem that stated I did not have “@angular-devkit/build-angular” so, I had to type “npm i @angular-devkit/build-angular” on the git bash command prompt. I then was able to “ng build” and “ng serve” successfully. I had a few error I did had to fix and things I needed to install. However, I don’t remember all the error and problems I came across. For this sprint I found a lot of useful information and help on the ampath slack channel, and on stackOverflow with the help of Google.

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 reflection is based on the work done from 2/20 to now, 3/5. In this time, our team has only met two times and I missed one of those meetings, so not a whole lot actually got done together during sprint two. We met in class and made progress on 2/20, I was absent from the meeting on 2/25. On 2/27, class was expectedly canceled with the optional choice to meet in class anyway, which we decided against. We figured we could wrap up anything that we needed to work on in the upcoming Monday’s class. Yesterday, on 3/4, Worcester State canceled all classes and events due to inclement weather, and the end of the sprint is next class at 3/5.

Our workload was fairly light anyway, we only had two sprint backlog tasks; make sure every team member could build and run the project, and learn more about angular testing. We could independently conduct research into testing, and we are encouraged to branch out to find potentially helpful content, so the snow day didn’t slow us down significantly.

To study angular testing, our group particularly focused on the two programs karma and protractor. Using the trello project management board we set up in the last sprint, two links were shared for the group to look over. For karma, I used the following link:

https://karma-runner.github.io/3.0/intro/how-it-works.html

This website explains in general terms how karma works. It loads multiple browsers and tests given code on each one, displaying the results conveniently to the developer. We will have to practice hands on with karma once we get some code and tests. For protractor, we used the following link:

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

All the information on protractors site is very hands on and literal. It explains steps and shows exact commands and lines for example, it should be easily set up and modified to our project. Since we downloaded the latest version of node.js in the last sprint, and have experience using npm, protractor will be a useful resource.

Our more major goal for sprint two was to have every member a working build of the AMPATH project in an IDE of choice. Right now, everybody besides me has a running project since I missed the last meeting. I will need to communicate with them for help troubleshooting and follow the same steps they took the next time we are all in class together.

At the same time, during our next meeting we will be planning for sprint three. We don’t have much on our plate currently since we’ve been making pretty good progress so far, so I’m not sure what to expect for sprint three. I think Professor Wurst will be giving us more concrete things to do, which we can add to our trello board.

We’ve also been keeping up to date on slack, every group member answers automatic check-ins two times a week. This keeps us all updated on what we’ve done since the last check in, what we are planning to do before the next check in, and state any obstacles blocking our progress.

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

With now two full sprints under my belt, I think I’m beginning to grasp not only the aspects of team dynamics with which I have comfort, but also those aspects with which I have discomfort. I am glad to be encountering obstacles and pitfalls in an academic setting rather than in a much higher-stakes workplace environment.

Where last sprint was primarily concerned with setup tasks, this sprint was more geared toward design – be it the design of the user interface, the program structure, or the module as a whole. We determined as a team during our first meeting that we would take responsibility for developing the Offline Data Storage service. Much of the remaining class period was spent looking over user stories, and looking into the suggested service for offline storage: PouchDB. Over the next several meetings, we worked toward three goals in particular. Firstly, we wanted to figure out the best way to transition from the online state of the application to the offline state of the application. To this end, we drew up a few of our ideas, and posted a number of them to Balsamiq. In addition, we sought a better understanding of PouchDB, so many of us spent ample amounts of time doing online exercises from the PouchDB website and making small, basic offline applications for practice. Perhaps least importantly – but certainly still relevant – is that we spent time during each meeting reading through the code that Ampath has already written. We focused on their data storage service that is already in use for their online storage, and are looking to see if we can translate ideas from those sections of code to the ones we develop.

As far as my contributions to the team this week, I would say that the largest part I played was in the dissection of Ampath’s code, and in the assistance with PouchDB growing pains with the exercises. I would have liked to have spent more time working out a foundation of a plan for our service’s implementation. In the sprints to come, I hope to dedicate more resources toward the actual building of the service, so that we can get the ball rolling with the code.

The biggest takeaway I came to from this week is that self-management is a critical skill in the field of software development. Although we are not yet at the stage of writing the actual classes for the project, it is clear that each of us is not used to having a large task with no overseer. While Ampath is technically available via Slack, we haven’t had much success in getting additional information from them, such as a UML diagram for the existing project (which we were told does not exist). As a result, we have had to maintain a degree of discipline on our own without the extrinsically motivational forces we have grown used to. Going forward, I hope to develop a more productive and attentive attitude, and believe that such a change will greatly benefit the project.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.

The second sprint has just finished, and though this one was not as involved as the last one, I still learned a whole lot about software design and javascript itself. While the last sprint was very informative due to the environment set up, and generally getting familiar with the new tool, this sprint was informative in the sense that it taught me some of the challenges that come with breaking down a very big task. As developers, we want the tasks to be broken down and very clearly defined for us from the start when in reality, that is never really the case. As frustrating as that is sometimes, it is a lot is learned when you are able to break down and design a task yourself. I would say that was the most important thing that I learned from that sprint, because having to work as a team and breaking down a task that we barely understood forced us to ask some questions that we probably wouldn’t have if the task was handed to us like “here, code this”. I think that this ambiguity is ok to an extent when it leads you to ask questions that give you a clear picture, it is very easy to be too ambiguous where it leads to time being wasted since it feels like there is no starting point.

Work wise, I think that this sprint was a bit lacking (since it was mostly planning and design), so our team worked through that very well. As a team we bounced ideas off of each other and asked questions that helps clear up some ambiguities. More impressive than that is how well our team worked with other teams, we know that class-wide communication will be needed to complete this project and I thought our team asked the right questions to get a good idea of how we will integrate some of the key functionality (like how does the app know that it is offline). I thought that my participation in this was sizeable because I threw out a few ideas on potential ways that we could implement this offline detection functionality.

The most important thing that came away from this sprint was each team coming away with an understanding of the modules that will be needed, a general understanding of how they will fit together, and starting to get a feel for which component in particular they intended to work on. We accomplished this by talking to each other and staring at the code the learn how it works and sharing that knowledge with each other. If we could have done something different it would be going into that deeper level of detail much sooner in the sprint, but now that we know how well this works we will improve on that for the next sprint.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

The second sprint has just finished, and though this one was not as involved as the last one, I still learned a whole lot about software design and javascript itself. While the last sprint was very informative due to the environment set up, and generally getting familiar with the new tool, this sprint was informative in the sense that it taught me some of the challenges that come with breaking down a very big task. As developers, we want the tasks to be broken down and very clearly defined for us from the start when in reality, that is never really the case. As frustrating as that is sometimes, it is a lot is learned when you are able to break down and design a task yourself. I would say that was the most important thing that I learned from that sprint, because having to work as a team and breaking down a task that we barely understood forced us to ask some questions that we probably wouldn’t have if the task was handed to us like “here, code this”. I think that this ambiguity is ok to an extent when it leads you to ask questions that give you a clear picture, it is very easy to be too ambiguous where it leads to time being wasted since it feels like there is no starting point.

Work wise, I think that this sprint was a bit lacking (since it was mostly planning and design), so our team worked through that very well. As a team we bounced ideas off of each other and asked questions that helps clear up some ambiguities. More impressive than that is how well our team worked with other teams, we know that class-wide communication will be needed to complete this project and I thought our team asked the right questions to get a good idea of how we will integrate some of the key functionality (like how does the app know that it is offline). I thought that my participation in this was sizeable because I threw out a few ideas on potential ways that we could implement this offline detection functionality.

The most important thing that came away from this sprint was each team coming away with an understanding of the modules that will be needed, a general understanding of how they will fit together, and starting to get a feel for which component in particular they intended to work on. We accomplished this by talking to each other and staring at the code the learn how it works and sharing that knowledge with each other. If we could have done something different it would be going into that deeper level of detail much sooner in the sprint, but now that we know how well this works we will improve on that for the next sprint.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

For most of this sprint, we tried to make progress on coming up with specific design ideas to implement the offline module. We didn’t accomplish much concretely on this front, since generating design ideas was so broad of a task that it left us without much direction. The sheer size of the application makes it difficult to parse. I believe the documentation being consolidated in the new channel about how AMPATH works will be very helpful in the coming sprints.

The concrete tasks we did manage to get done included getting ng2-amrs built on everyone’s computer and getting everyone’s local version connected to the server. We checked out Balsamiq and the wireframes there as they got added. We all read the user stories and their associated tasks.

In our most productive work class, we worked on figuring out how ng2-amrs checks whether it’s connected to the internet. We wanted to see if there was an easy way to know whether an internet connection is available and decide which version of the app a user should see and interact with based on that, for the requirement that transitions between offline and online states should be seamless. We discussed this with the group behind us, and we worked together for a bit searching for the files containing the relevant code and attempting to understand how it functioned. We also tried to decide if we should be constantly checking the status of the internet connection when we write that piece of the offline module, or if there was a more efficient way.

Although writing and submitting abstracts for posters at several events were tasks for this sprint, we ultimately decided not to do them in favor of working on tasks that applied to the application itself.

Our team worked well together this sprint. We all showed up for both work days during the week. We shared information and communicated our ideas and concerns more easily. Toward the end of the sprint, we started feeling that we wanted to focus on the offline login and offline data storage task for the offline module. We discovered on the day of the retrospective that another team had also been focusing on this task. Since they had gotten further than we had on the offline storage aspect, we decided to take the offline login piece of the task. Going forward, we’re going to make sure we have a clear understanding of what work we’re doing in relation to other teams and narrow our focus.

Mostly what I learned during this sprint was the necessity of outside research. In future sprints, I am going to dedicate more time to acquiring the knowledge and skills necessary for the tasks we’re working on. Our path forward is clearer. The AMPATH team provided some links to give us ideas for offline authentication in the google document containing the user stories. I plan on taking a look at them and working on creating something that can successfully encrypt and store a salted password locally, even if it’s not what ends up getting used in the offline module.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

During the second sprint of my software development capstone class, it had a very unique feel to it for various reasons. One of the reasons on why it had a unique feel to it is because my team and I had to create some of our own side tasks in addition to the ones that we were assigned. Considering that this is the second sprint, it didn’t contain that many tasks to do besides getting use to some new applications that were introduced such as Balsamiq which is a nice tool provided by AMPATH.

What I learned in this week’s sprint was learning how to use Balsamiq, learned the fundamentals on how an offline module works, and learned how to map the node paths to understand how the AMPATH server communicates to a router module to fetch patient data. Learning how to map the node paths from the AMPATH code was one of the side tasks that I my team and I wanted to do because we felt that it would put the team as well as the rest of the class in a good position to prepare for what could come next in the upcoming sprints. Keeping that in mind, I think that this portion of work that my team and I are doing can benefit the other teams in the class because the ideas or information that my team and I come up with might be useful to other teams and vice-versa.  Looking back on how I’ve learned these things with my team, I think I did a great job and I don’t see anyway to approach this differently.

The team performance was good and the CATME Team Evaluation in my opinion was accurate.  Everyone in the group participated in all the tasks that were assigned for them to do. My performance fell under the category of completing a fair share of work, if not a little more. I assigned my personal task to be making sure that the team trello board was up to date on what tasks each person should be doing. That will be my personal task moving forward with the upcoming sprints in addition to other tasks assigned to me. As far as it goes for my teammates, they all did well. Rick and Jason contributed heavily in trying to understand the node paths in the AMPATH code. Jeremiah reminded the group to not forget to do the standups that we needed to do on Mondays, Wednesdays, and Fridays. Everyone contributed to the work fairly and I think we established an organized way to keep track on what person is doing, and making sure that they are doing something. I don’t we could’ve approached this differently.

The tasks the got done was reading the user stories for offline modules, and checking out the node paths. The one thing that I would consider that didn’t get done was figuring out the node paths. Although my teammates and I did find how the server communicates and we also got a brief idea on how it talks to the router module, I would consider this task an ongoing or work in progress. The steps that we took to approach this task was that first, we tried to search for patients, but no data returned to us. So that made us think that there might be a connection issue to the routing server in the code. In order to test that theory, we tried to locate the router module in the code, and from that point we made that our task in understanding how the communication between server and router module worked to fetch the data within a database provided by AMPATH. We succeeded in getting ideas from dissecting the code and drew a path diagram in Balsamiq on how might the communication takes place. I would say that we failed in a sense that we couldn’t fully figure how it actually communicates within the time given in this sprint. We chose this course of action by trying to fetch patient data.

Overall, the team and I were satisfied with this sprint. One thing that improved from the last sprint was communication between team members. Everyone knew what to do and everyone knew what each person was doing which promoted quality work.

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