During this Sprint, my team and I tried to complete as much as we could since we are coming to an end in the semester. We wanted to at least give JJ and the AMPATH people some sort of workable interface for our offline data capture service. Throughout the process of finishing and having a workable interface, the team and I decided to focus all of our attention on that aspect, aside from the encryption service that I was trying to discuss with the encryption team involving the javascript implementation crypto.js.

Some tasks that we did during the week that helped lead us to establishing the offline data capture service interface were:

• Help ensure GUI code is compatible with any offline-capturing abilities we implement when the user is online and vice versa.
• Create balsamiq diagrams outlining current and anticipated implementations of offline-capturing the OpenMRS / ETL data.
• Ensure all new components, GUIs, etc comply with basic AMPATH CSS styles, overall look and coding convention.
• Code the offline GUI based on the help and input from Jerry and other teammates.
• Write/maintain tests for our implementations so they are always as current as possible.
• Seek help from the AMPATH development team if any of us hit a roadblock concerning implementation.
• Offer suggestions to other teams based on our overall process, so that all teams’ implementations can work together as smoothly as possible.
• Touch base with all teams (encryption, offline-storage, and login) regarding their overall progress.
• Develop high-level idea of a Doctor/Provider object so we can consider if it is worth implementation.
• Develop mock diagram where a “Doctor/Provider” can pick and choose what patients to sync.

The above tasks were what was tried and attempted. What was done and completed were the establishment of the Doctor/Provider object, and the mock diagram. For the GUI task, we had to communicate with JJ a lot. Due to the amount of time the team had, we had a feeling that there wouldn’t be enough time to create a perfect GUI, even though JJ wanted one. Midway through the sprint, we sent JJ our progress on what we did so far for the offline data capture service through a walk-through video that we shared on the slack channel. JJ then understood where were at with the progress and we concluded that it was okay to work towards establishing an interface where the user can clearly see if he is offline/online along with the data. That was one of the tasks that we had approach differently and adjusted to.

As a team, we learned to make a major adjustment to our task during this sprint. We knew that time was a concern, and what the people at AMPATH and JJ were expecting to get, which was the new offline GUI, seemed to be too much. We wanted to at least deliver something to them that at least worked, which is why we moved away from creating the new GUI. From this situation, this could be applied in real life software development environments because there will come times where I would have to adjust my tasks to deliver something that the customer wants, even if it isn’t 100% of what they want it to be, it will perform the same functions of what they want it to do.

The team’s performance during this sprint was above above average. Everyone contributed evenly or more than an adequate effort throughout this sprint. Communication was very effective between each member and between our team and AMPATH. As an individual, I performed average during this sprint. I mainly tried to talk to the other teams, trying to get some info on their status. The only team that we communicated to more than others was the offline data storage team, and we began to work alongside with them since our tasks were similar to theirs. I also tried to help find several components in the AMPATH code for which JJ wanted the interface to display such such as genral patient data, vitals, lab results, and HIV summaries.

Overall, the team worked diligently and we wouldn’t have proceeded in any other way. We will try to have our offline interface working, completed and delivered hopefully by the end of this next half sprint.

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.

During this sprint in my software development capstone class, my team and I tried to make some progress on establishing our offline data capture service. Before creating our tasks, we organized our team’s trello board to be a bit better. We changed the layout of our board by creating different columns that were categorized by our names to indicate who was in charge of doing a specific task that was assigned to them. We did this because it could make us as team to better understand who was doing what, and what was currently worked on in this sprint.

The team and I attempted to find out more ideas from the people at AMPATH through the communication with Jonathan Dick. We felt that we needed to get some ideas to further progress at our offline data capture or else we wouldn’t know what to do during this sprint. One question that I had asked to JD pertained to a GUI, which he wanted that indicates and separates offline data from the online data through our service. We are still currently figuring out on how to create the GUI. Other tasks that we attempted were:

• If dealing with CORS issues, create a desktop shortcut loading an instance of Chrome disabling web security.
• Create balsamiq diagrams outlining current and anticipated implementations of offline-capturing the OpenMRS / ETL data.
• Write tests for our implementations.
• Design the HTML part of an offline component that will be used for our GUI. Should be similar to the layout of the AMPATH Patient Search Component.
• Collaborate with the encryption team regarding the process of how our captured data ought to be encrypted.
• Touch base with all teams (encryption, offline-storage, and login) regarding their overall progress.
• Create a mock diagram in Balsamiq illustrating an idea of a GUI that presents the captured data in a meaningful way.
• Develop mock diagram in Balsamiq where a “Doctor/Provider” can pick and choose what patients to sync.

All of these tasks are still ongoing, leading into the next sprint. I felt that we were unable to complete any of these tasks within this sprint because we spent most of the time asking questions. I would admit that there were times where we were lost because we weren’t  communicating enough to JD. However, one task that we got done was:

• Get ALL patients in the database (not just those with “test” in the name). Store each patient results into an array, then iterate through it to store each into separate files in PouchDB.

What we learned from attempting these tasks was that it taught us to constantly communicate with AMPATH to develop a smooth transition from task to task so we don’t get stuck and waste time on what to do next.  Communicating with AMPATH and asking questions to them will help us develop ideas on how to proceed with a task to validate what we are doing is what the people at AMPATH and JD wants. This was the main thing we learned from our mistake. This can be applied in other situations because in the software development career, communication is one of the most important things to do for this particular reason. If there is not constant communication, whether it be to your teammates or anyone in the workplace, work can become difficult and you can become unaware of what to do, which can further delay the project or task from getting done.

The effort that my team put into this sprint was sufficient despite the incomplete tasks. Everyone still tried to attempt at something even though we were still stuck on how JD and the people at AMPATH wanted our Offline Data Capture service to look like. For this sprint as an individual I mainly tried to still gather ideas and find a suitable encryption implementation for the AMPATH code and I think that using crypto.js wouldn’t work efficiently, so I decided to keep on researching. I also talked to the encryption team and found out that they ran into some impediments as well on developing their encryption service. Moving forward, my team and I need to communicate more effectively with the other teams as well as with JD and AMPATH. Doing this will help us work better.

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.

During the fourth sprint of our Software Development Capstone class, my team and I made some progress towards fulfilling our primary task of creating an offline data capture service. Some tasks that we created in order to reach towards the offline data capture were to figure out and introduce ourselves to pouch-db and how it could be implemented with Angular and the AMPATH code, getting pouch-db to work and compile with the AMPATH code, and researching cryptojs and finding out if it would work well with pouchdb to establish an encryption service with the offline data capture service. We manage to tackle these tasks that we created because other teams had researched cryptojs and pouch-db, so we felt that we had to do the same by introducing and exposing ourselves to these JavaScript implementations.

When we attempted these tasks, we managed to successfully learn about pouch-db and got some ideas about how it would work with the AMPATH code. Once we gathered all of our ideas together during our meetings and communication on the team’s slack channel, we started to tinker with the code itself and installed pouch-db within Webstorm’s terminal so that the dependencies can be present within the code. At first, we had trouble getting pouch-db to work with the AMPATH code because we kept getting compile errors. We assumed that the errors were coming from the packages that were installed from the pouch-db installation, which happened to be true. So, our team member Jason, stepped up and tried to find out how to troubleshoot this issue. He went and found how to properly install pouch-db since we had initially installed it the wrong way. We had to clone a clean copy of the AMPATH code from our own repository and make a new project from that copy. Once that was done, we had to remove the “Package-Lock.json” component from the code, then install it. That component happened to be the main cause of the problem. It was smooth sailing from there, and we successfully connected to the AMPATH server and log into it without any issues.

For crypto-js, we are still researching it and is considered an ongoing task. However, since my team and I did not come up with any ideas with the implementation of crypto-js in our offline data capture service, my team and I can categorized this task as a failed task for this sprint. Our goal is to get some ideas on crypto-js and implement it successfully by the end of the next sprint.

My team and I learned a substantial amount from this sprint, especially about the implementation of pouch-db. Despite the problems that we had with it initially, we overcame that problem through effective researching and communication within this team. I can’t think of any way to approach it differently because I’ve seen that with this group, we learn most effectively through trial and error. I felt that we researched pouch-db the best we could’ve done and successfully implemented it despite of the first compile error we ran into. This situation could be applied in other situations with any software development workplace. Working through trial and error is normal with this type of work and learning to overcome issues that may arise is a daily obstacle for developers such as myself, so I feel that this obstacle that we had with pouch-db was a great learning experience.

I feel that my team and I were very productive throughout this sprint. As an individual I had done my fair share of work and expected good quality from everyone. I mainly researched articles about pouch-db and crypto-js, and communicated the information that I found out to my teammates during our sprint meetings. For everyone else, they did wonderful. Jeremiah did his job with participating in team meetings and communicating over slack to remind each of us to do our standups. Rick helped gathered ideas for the code itself. Jason did the most work with the code and was the main person to work directly with AMPATH in getting ideas from them and at the same time getting pouch-db to work.

Overall, I’d say this sprint was very successful.

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.

During the third sprint of my software development capstone, my team and I were assigned the task to figure how an offline data capture service worked and how it would work with AMPATH’s patient database. The reason for creating the offline data capture service is to enable the retrieval of patient data while in an offline status. This is important because villages in Africa may not have internet connection, but AMPATH still wants to add additional information to their patient database.

One thing that I’ve learned from this week’s activities was how to an offline data capture service worked. To figure that out, my team and I also created other small tasks that aid in figuring out the offline data capture service. Another thing that I’ve learned how to do as an individual was creating tasks from scratch. In addition to our product owner assigning tasks to each group, my team and I discussed on how to approach towards the goal of establishing an offline data capture service.  This lead to the tasks that we created for us as a team to do. Throughout the entire process, I wouldn’t have done it any differently because everyone in the team, including myself, was productive in the way that we did things. This experience can be applied in real life situations, especially software development jobs. Since I want to be in the video game development industry, I’m going to have to learn how to approach the goals and objectives by creating my own small tasks that will lead up to completing the overall goal of a project.

What we did during the week was that we tried to create a balsamiq diagram which displays our idea on how an offline data capture operates. We also researched offline data capture services in Angular, and found more tutorials on them. We also checked out pouchdb and how it would be implemented in our offline data capture service and researched encryption to come up with ideas on how our offline data capture service would work cohesively with an encryption service that another team in our class was doing during this sprint. We succeeded in utilizing balsamiq to create our diagram of the offline data capture service, learned pouchdb, understood how an encryption service works, and successfully came up with ideas about how to interpret the offline data capture service by reading online articles and other resources.

The work quality for this sprint was adequate for all of us to do. From the past sprints up until this sprint, everyone contributed fairly if not more for some of us. I’d have to give a lot of credit to my teammates Rick, Jay, and Jerry as they helped me as well as the entire team on making sure everyone was on the same page. Jerry reminded the group about the standups. His contribution to the group has improved from the last sprint and I felt he communicated more in our meetings in class and on slack. Jay and Rick did an exceptional job of finding some resources about the offline data capture service and they both did well creating the diagram as well. What I did throughout this sprint was a lot of information retrieval which I shared as much as I could with my group about pouchdb, the encryption service, and about the offline data capture service. All of efforts played a huge role in getting us to where we are at with the offline data capture service right now as we are putting the pieces together with our diagram and our ongoing research.

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.