We’ve just completed our final working sprint, consisting of six primary objectives.

1.  Maintain communication and collaboration with all other teams.
2.  Create a mock diagram demonstrating our implementation ideas.
3.  Capture the specific data requested by the AMPATH team.
4.  Store this specific data into the PouchDB database.
5.  Write tests for our existing code.
6.  Develop an offline GUI to display specific offline data.

Maintaining communication and collaboration:

Sprint 6 involved substantial communication between ourselves and the other teams. Since this was our last working sprint, our team knew it was imperative to keep up to date on what everyone is working on. Each team is working on a critical part of the offline AMPATH implementation. I like to think of these critical parts as pieces to a puzzle. Eventually we’re all going to have to put these pieces together, and they all have to fit right. Our team agreed that communication is the best way to ensure how the pieces will fit in our final stages of implementation.

Based on our cross-team discussions during this sprint, we began brainstorming how to connect all teams’ implementations as a whole. We’re in the process of designing a mock-up that demonstrates the idea. This ought to be done in time for our final presentation next week.

Creating a mock-up demonstrating our implementation ideas:

We felt that designing a mock diagram was important for the AMPATH team (and our classmates) to see exactly what we envision our final implementation to look like.

We would like to give credit to the offline-storage team for designing the original mock-up above. Small changes were made to reflect the specific information we plan on capturing. After receiving approval from JJ, we began working to implement this overall design.

Capturing the specific data requested by the AMPATH team:

This refers to capturing five specific categories of information to be stored in a PouchDB database:

1. Basic Patient Information
2. Patient Visits
3. Vitals
4. Lab Results
5. HIV Summary

We were able to accomplish updating our offline-data-capture component to include functions that capture the aforementioned data. We were able to accomplish this by using existing OpenMRS services located within the AMPATH app. We made functions where each focuses on capturing and storing one specific category.

Storing the aforementioned categories into PouchDB:

The AMPATH team suggested that we separate the different categories when storing them into PouchDB. This makes a lot of sense; we noticed the original data we were capturing tended to exceed over 3000 lines per patient. The larger the file, the longer it takes to load. We want our offline implementation to load as quickly as possible for the convenience of those using it.

Now that we’re only capturing specific data and storing each category separate, the file sizes are significantly smaller. We opted to store them by name of the category, followed by a given patient’s UUID. For example:

patient-064e419c-ff4e-4a6f-b83f-e1df48e80723
vitals-064e419c-ff4e-4a6f-b83f-e1df48e80723
visits-064e419c-ff4e-4a6f-b83f-e1df48e80723
labs-064e419c-ff4e-4a6f-b83f-e1df48e80723
hivSummary-064e419c-ff4e-4a6f-b83f-e1df48e80723

Writing tests for our existing code:

Ideally, we should have written our tests prior to any actual implementation. Then we could have written our code in a specific fashion to make our tests pass. I am still new to unit testing; this is something I need to work on in future projects (writing tests before implementation). On a positive note, the offline-storage team has made substantial progress writing tests for their component and service. Since they’re using PouchDB as well, our team should be able to easily revise their tests to suit our needs.

Developing a GUI to display specific offline data:

This concerns designing a component with the overall look of the aforementioned mock-up we came up with. We are in the process of implementing this GUI, but we’re having issues getting anything to display to the user. Everything I’ve tried so far hasn’t been working, and it’s pretty frustrating. Here’s the type of errors I am getting:

I think it has something to do with losing the result once leaving the promise. I am hoping to get this working by our project presentation. If anyone wants to see my most recent attempt at getting this working, the commit can be found here.

Overall

I think this was a very eventful sprint. We’ve all done a good job communicating not only with each other, but with other teams as well. Personally, I believe many of my contributions would not have been possible without the communication and support from my teammates, AMPATH, the other teams, and my professor.

 

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

It seems that as each sprint goes by, we tend to achieve a substantial amount more than the preceding one. This sprint is no exception. I feel it has a lot to do with us becoming more familiar with the project, as well as the Angular framework.

Our main objectives for Sprint 4 were the following:

1.  Finish refactoring online-tracker to include a service.
2.  Successfully install PouchDB within the AMPATH app.
3.  Research and attempt using the PouchDB API to:
        (a)  perform REST calls.
        (b)  deal with synchronization.
        (c)  encrypt the data within the database.

Refactoring online-tracker to include a service:
We were able to accomplish this. I should point out that the refactoring of online-tracker was a bit more complicated than we anticipated. Initially we thought that just moving around some code would do the trick. But once we attempted to test the code, we realized we had a series of issues that needed addressing. For example, our original service essentially wasn’t returning anything, making it extremely difficult to test. Further, there were some issues with the Observable.timer() that periodically checks for connectivity. Since it wasn’t being properly closed, it was causing potential resource leaks that seemed to slow down the whole app. Felix from the AMPATH team helped us resolve these issues. The end result is that our pull request was accepted, and is officially part of the ng2-amrs repository. I tried to document the whole process the best I could to help others in the future. If you want to check it out, the PDF is located here.

Successfully install PouchDB within the AMPATH app:
We did not expect this to give us so much trouble, but ultimately we were sucessful. We were able to install PouchDB dependancies inside a new standalone Angular app, but every time we would try to install it within our clones of ng2-amrs, the app would no longer compile. With the help of another team working on offline storage, we were able to get it working. Here’s how our team was able to do it:

   1. Clone a clean copy of ng2-amrs, i.e.:  git clone https://github.com//ng2-amrs ng2-amrs-pouchdb
   2. Open ng2-amrs-pouchdb in WebStorm and press ALT-F12 (or Fn-ALT-F12) to start a terminal.
   3. Delete package-lock.json from the Project menu in WebStorm (make sure safe delete is checked)
   4. npm install pouchdb @types/pouchdb
   5. If package-lock.json is recreated, delete it again by following step 3.
   6. npm install webpack webpack-dev-server karma-cli protractor typescript release-it rimraf -g
   7. If package-lock.json is recreated, delete it again by following step 3.
   8. npm install

Research and attempt using the PouchDB API:
I believe our whole team was able to read most (if not all) the chapters in the official PouchDB guide. We were able to make some progress regarding actual implementation within the AMPATH app. For instance, we were able to configure a router for an offline-storage component, and we can now link to it directly within ng2-amrs. Further, we performed some REST calls using the PouchDB API.

Going forward into the next sprint, I think we need to focus on subscribing to data using observables, and then storing that data offline. This will require further experimentation with the PouchDB API. During the next several days, we will look into encryption at a high level, but will focus primarily on data capturing using PouchDB.

Synchronization between an offline database and the AMPATH server is our ultimate goal for this project. Based on our research so far, this task in particular seems pretty advanced. We are likely going to need assistance from the AMPATH team. I have been communicating with Felix regarding these issues.

Overall, I think we worked well as a team, and as a class in general. Everyone seems genuinely interested in completing the tasks we’ve set for ourselves. Communication has been strong for the most part; we always seem to know what each of us is working on.

 

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

We started off this sprint with two primary objectives in mind. Soon I will discuss a bit about our sub-tasks to complement these objectives; i.e. Collaboration, research, complete tutorials, research some more, rinse and repeat…

But first, I want to elaborate on our primary objectives:
1.  Refactor online-tracker-component.ts to include a service.
2.  Begin the implementation of an offline capture data service.

Our first goal, refactoring the online tracker component, proved to be a lot more simplistic than the second. For the most part, it only took moving around code from one file to another. The end result is the online-tracker-component now calls functions from the new online-tracker-service to determine whether there is an internet connection. Though a simple refactoring modification, this change should be beneficial to all teams in the near future. We can now use our new online tracker service to call functions to check for connectivity status. Since all teams are working towards an offline module for AMRS, we feel this is essential for any of us to go forward.

The good news is the AMPATH development team will likely accept the pull request for our online-tracker modification once we make the tests pass. I should get this done by the end of this weekend, if not later today. In the meantime, if anyone wants to checkout our refactored online tracker implementation, the commit is available on my forked repository here.

Implementing an offline data capture service ultimately proved to be our greatest endeavor. We chose to approach this situation by first evaluating various techniques to achieve an offline capturing ability. PouchDB appeared to be the most promising tool from the start. Our reasoning was that other teams seem to anticipate using PouchDB themselves. We thought it would be best to do the same, so our future implementations would be compatible with other teams.

I initially hit a roadblock understanding the functionality of PouchDB. It appeared that PouchDB tutorials specifically aimed at Angular implementation were either scarce or low quality. Not only that, the AMPATH app seemed to fail every time we would try to import PouchDB directly into it. But other teams report to have had success using PouchDB’s TypeScript installation instructions. I will attempt this installation within the next couple of days, and will ask for feedback if I have any problems.

Fortunately through collaboration, my teammates and others were able to bring me up to speed. Originally I tried to follow the Getting Started guide on PouchDB, but the tutorial seemed not to be geared towards Angular implementation at all. But the Guides page is actually very helpful. The API page is also a great resource for an overview of PouchDB capabilities and syntax.

I had a chance to go through all the mini-chapters last night; PouchDB is making a lot more sense to me now. I will attempt to implement synchronization measures between PouchDB and AMPATH’s OpenMRS data during Spring Break.

It is worth noting that we began to look for alternatives to PouchDB. I actually found an informative tutorial regarding LocalStorage. This seems to be a JavaScript functionality that allows storage of data directly into the user’s browser. With the help of a tutorial geared towards the subject, I put together a simple Angular application implementing the LocalStorage functionality:

It’s a simple little ‘breakable toy’ I’ve conjured up with the help of following the aforementioned tutorial. I put it up on GitHub if anyone is interested in looking at it. Ultimately, it looks like we’re going to move forward with PouchDB rather than using LocalStorage. PouchDB just seems like the logical choice; it appears very powerful, flexible and stable, especially in comparison to other alternatives such as LocalStorage. But it was fun experimenting with the functionality. And honestly, exploring all these various Angular capabilities is making me a lot more comfortable working with the framework. It seems like everything I’ve researched thus far regarding Angular has helped me understand the AMPATH application more, either indirectly or directly. So even though we likely won’t be moving forward with LocalStorage implementation, it’s great to know the functionality is there if we never need it in the future! Knowledge is power.

Overall, this sprint was quite eventful. Our collaboration as a team went well; communication is probably the best it’s ever been. We also had some cross-team communication, and all teams seem to be making great progress in enabling offline capabilities for the AMPATH application.

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

This sprint was an interesting one. It seemed to offer insight for what we should expect going forward in our professional careers. In college we can become overly accustomed to expecting and working with concrete tasks. I feel this sprint was a great reminder that out in the world of software development, tasks can often be anything but concrete.

As time has progressed, in terms of scrum, I’ve been thinking of the AMPATH app’s consumers as the customer, Jonathan from the AMPATH development team as the Project Manager, and our professor as the Scrum Master. The project manager gives us as team members direction on what we should be focusing on. This is based on his knowledge of what the customer needs. The scrum master offers guidance in best optimizing these tasks. If we hit a road block, the project manager and/or the scrum master help “clear the way.” They are available for general questions and direct us to the answers of these questions. But virtually nothing has been concrete, and I realize we should not expect it to be. Ultimately it is our jobs as scrum team members to figure out how we’re going to tackle each “story” in our sprint backlog. And that is why I feel this sprint has closely emulated a real-life scenario of working in the field of software development. I am grateful for the experience.

We’ve spent this sprint with the primary goal of conceptualizing ideas to implement offline capabilities for the AMPATH project. From there, it seems to have led each team on interesting paths. For instance, our team quickly realized it was initially near impossible to conceptualize any practical implementation of an offline module. In order to proceed, we thought it was imperative to understand the complexities of the AMPATH app. While scrutinizing the code, our team noticed a pattern of repeated references to routing, HTTP calls and REST APIs. These are all subjects we had limited to no knowledge about prior to this sprint. Thus we dedicated the majority of our time becoming more familiar with these processes.

Based on the collaboration between the AMPATH development team, my teammates and my professor, here’s my brief understanding of the project so far:

• The AMPATH app communicates to servers primarily by REST (Representational State Transfer) API.
  • REST is an approach that uses HTTP requests to GET, PUT, POST and DELETE data.
• The app is dependent on not one, but TWO servers, OpenMRS and ETL.
  • OpenMRS seems to handle the majority of the resources, such as user accounts, locations, visits and encounter types.’
  • The responsibility of ETL seems to focus on what the acronym suggests, i.e. Extract, Transform, Load. Based on my research, it seems that the job of the ETL server is to optimize the data retrieved from OpenMRS server, such as extracting data from one database to another.
    • As of this writing, the ETL server seems to be down, and the AMPATH development team is working to resolve this.
• Many of the AMPATH components seem to consume the OpenMRS LocationResourceService. The service seems to provide a gateway allowing other components to call HTTP requests. It is located in the openmrs-api folder within the project, i.e.

  './src/app/openmrs-api/location-resource.service.ts';

I would like to give a special recognition to Felix (fmaiko) from the AMPATH development team for providing me with much of this information. These findings seem to indicate that we should be focusing on understanding the OpenMRS functionality. Further, the LocationResourceService seems to be a pivotal factor in making REST calls to the OpenMRS server. Felix provided me with a link to the OpenMRS wiki; I suggest anyone working on the AMPATH project to check this out going forward. It outlines pivotal information such as obtaining sever resources, as well as the format for sending each request.

For a sprint initially focused on conceptualizing ideas for offline implementation, it definitely seemed to branch off in all sorts of different areas of research. That’s what I enjoyed the most about this sprint. We started off thinking we would be primarily designing offline implementation mock diagrams. But the learning process involved turned out to make it a very informative and eventful sprint. As for our original hopes for coming up with an offline module idea… based on the information we’ve gathered during this sprint, we were able to conjure up a very abstract idea using Balsamiq:

We are hoping to improve on these ideas in the sprints ahead.

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

We’ve just completed our first sprint in the Software Development Capstone course. I will be posting similar blogs biweekly for the next few months. The purpose is to periodically check in and reflect upon the overall progress of our team.

Many of us, such as myself, learned for the first time what a sprint refers to in the context of software development. The whole concept of “sprints” and scrum is brand new to me. In very simple terms, scrum is a framework where teams produce material in small “bursts” (i.e. sprints) where the intention is to increase overall productivity. I must say that I am enjoying the team based environment, especially because it seems to closely emulate what we should expect when we graduate and transition to our soon-to-be careers.

This first sprint was designed to help us become more familiar with working in development teams, setting up our environment for future sprints, and the whole concept of sprints in general. We are working with AMPATH this semester, contributing to a healthcare consortium software project that is primarily used in the Kenya area. We hope to provide the AMPATH application with feasible offline accessibility, where data can be submitted online once an internet connection is reestablished. Offline access would be a great asset to those using the software, as Kenya internet access is reportedly unreliable at best.

It is our team’s personal goal to contribute as much as possible, assisting our class in accomplishing everything the AMPATH team expects from us. So we spent this sprint getting everything up and running that will be required of us to contribute to the AMPATH project:

• Slack – Our team has been (and will continue to be) using this platform for communication among ourselves and other teams. Personally I think Slack has certainly contributed to our team’s productivity. While our in-person collaboration is great, I feel it is equally important to have a means of communicating asynchronously; Slack provides this capability for us. We also use Slack to complete our stand-ups, which help periodically determine what each of us currently working on.
• Trello – We are currently using Trello as a scrum board to manage tasks during each sprint. We’ve spent this first sprint becoming familiar with Trello, such as how to create and assign one or more of us to a “task card.”  For this sprint, we’ve typically either told each other personally or via slack if we completed a Trello card. I feel managing tasks could have been easier if we used Trello more productively; this is something we should work on in future sprints.
• JIRA – This is a project management web app (similar to Trello) that the AMPATH development team uses. We’ve spent some time reading tutorials regarding the JIRA framework, because we will likely be using this soon.
• Angular, etc – It was imperative to ensure we all had the required Angular stuff up and running. We’ve also read tutorials to familiarize ourselves with the framework, and how tests work for it. The AMPATH app is written in angular, so in turn we needed the node package manager installed in order to run the angular framework. For more experienced users looking for flexibility, I would recommend Node installation via the Node Version Manager (nvm) app. This is a great tool that allows the on-the-fly switching to different versions of node, something that is much less feasible with the proprietary version from the node.js website.
• WebStorm – This IDE provides the TypeScript and Angular support we need when working on the AMPATH project. I recommend this to anyone who is a student looking for a good Angular/TypeScript IDE (it’s free for students, otherwise the price is a bit too pricey in my opinion).
• GitHub – We ensured all of us as a team had GitHub accounts because this is the version control system that AMPATH uses. We then created and forked the project repository to our personal team’s organization. From here we all helped each other successfully clone and install the application to our personal computers.

I feel we collaborated well as a team; overall I would say we’ve had a successful first sprint. My only concern is that we had to change some code in the module files to get the application to run properly. We are not sure if this is a problem in our end, or an issue that AMPATH is experiencing as well. We are in the process of communicating with the AMPATH development team to figure out the best resolution.

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