This sprint, unfortunately, was cleaved in twain by Father Winter. There were multiple white-out blizzards, which resulted in numerous missed class meetings. This proved to be a serious blow to productivity. In the face of nature’s obstacles, however, my group did manage to get more done than we would have anticipated had we known how little we would have been able to collaborate.

This sprint, we solidified much more of our understanding of PouchDB and the structure of our service. Due to the weather, much of our progress was done separately except for during a single impromptu meeting on Discord, so a gap in our respective grasps of the service has begun to form. However, in some capacity, each of us managed to learn and share with each other something new about PouchDB. As for me, I was concerned with the code itself. Much of my time in the first few days of the sprint was spent tinkering with the exercises we had completed during the previous sprint, in an effort to attain more than a working knowledge of PouchDB’s functionality. To this end, I redid the exercises from memory as best I could, but also framed the app in the context of Ampath’s patient data. The result was a rudimentary form of what the final service may look like – albeit without encryption, decryption, login, etc.

Of course, catastrophe managed to strike. As it happens, there are two versions of PouchDB: a JavaScript version, and a TypeScript version. We had been writing our code in the former, and wished to switch to the latter. In terms of syntax for the programs we’d written, this wasn’t all that major of a change, as we only really needed to change the import statement at the top of the file. Installation, however, was another issue. I spent hours with Fuve and Caleb one day, fighting with install errors that would pop up for one of us but not the other, until eventually Fuverion made some breakthrough that fixed everything. Admittedly, I still have no idea what he did, I’m just thankful that he did it.

Due to the inconsistent meeting times, coupled with the headaches brought about by switching to the TypeScript version of PouchDB, this was about as much as we were able to get done in this sprint. We have in fact discussed this already in an in-class retrospective, and have all agreed to make better use of our channels of communication: Slack, Discord, and a group text message thread between the five of us. In doing so, we hope that future unforeseen bouts of meteorological calamity will have far less power over our capacity for progress.

In this sprint, a very critical lesson was taught (or, perhaps a better word may be “reinforced”) to all of us: Do not assume that anything will go as planned. Do not assume that anything will be smooth, or easy. Because in the event that some blizzard comes along to remove two consecutive meeting periods, it’s far better to have modes of communication available for use and at the ready. In future sprints, I will work to ensure that my communication with my team is upheld in the times where I am, or any of them is, unable to be present.

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

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

Our team began work on the offline login service this sprint. We decided to first investigate AMPATH’s current login process, which turned out to be spread over many different components and services. We found where information was sent to the servers for authentication purposes and determined that what we needed to do was to point to an offline database instead of the servers. There would be no point in creating an offline login service from scratch, and in fact we needed to use their implementation if we wanted to meet the requirement of seamless transitions from online to offline and back. We created a mockup on Balsamiq of what we thought the finished login process should look like with both offline and online options. We would use the online tracker being refactored by another team to determine whether there was an internet connection, and send the user’s credentials to a server or an offline database for authentication based on the connection status. We began to think implementing this was dependent on having an offline database to work with, and we weren’t sure how to proceed before the team working on that piece completed their work.

We also learned about the bridge pattern this sprint, which we expect will be used to handle checking the online status for all the pieces of the app which will be able to function in two different modes. George posted some good resources on it to the team channel, which can be found below:

https://www.youtube.com/watch?v=F1YQ7YRjttI
https://www.youtube.com/watch?v=9jIgSsIfh_8
https://sourcemaking.com/design_patterns/bridge

There were a couple of impediments to our progress this sprint. Multiple classes were canceled due to bad weather, and for this reason we weren’t able to collaborate as much or as effectively with the groups handling the encryption service or the offline database service as we had wanted. We did end up learning about some of the difficulties the offline database team ran into which apply to our service. They explained that patient data can’t be encrypted based on one doctor’s login information, because if it is, other doctors won’t be able to access it. They found a workaround, so going forward we’ll have a clearer idea of what’s meant to happen with the login information we send to the offline database.

The cancellations impacted our group’s ability to work together as a team as well. We do better when we can meet with each other in person and update each other on the progress we’ve been making in more detail than the stand-ups. Regardless, all team members answered the stand-ups in good detail and kept each other updated through the team channel, and I think overall our collaboration is getting better with each sprint.

One more impediment was that we discovered that we didn’t have access to server-side code to see what normally happens to the login information once it’s sent, which would inform our offline implementation if we had access to it. We plan ask the people at AMPATH whether that code can be shared with us in the near future. We also plan to make at least a mock of an offline database to use temporarily for our login service, and we might start using PouchDB ourselves if it’s not too involved. If nothing else, we will understand what the offline database team is doing better and be able to integrate our piece into the overall design more cleanly when the time comes.

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

Similar to the last sprint cycle, this sprint consisted mostly of research rather than actually writing code. Right at the beginning of this sprint cycle my team and I faced some issues regarding getting pouchDB installed in the ng2-amrs application. Not every team member ran into the same issue though. In fact, Ben was able to install PouchDB into the application first try without any complications. As for myself and my other team members, upon installing pouchdb using the command “npm install pouchdb @types/pouchdb” some of the other dependencies were erased causing the application to throw a bunch of errors when we were trying to start it. To fix this problem I reinstalled all the dependencies in the order listed in the Read-Me file. After that I was able to run the application without errors and ensure that pouchDB was still installed as a dependency.
After we got pouchDB successfully installed the next step was to figure out how to instantiate a pouchDB instance to store data locally. After a lot of trial and error I found that importing pouchdb into the app.component.ts file and writing code to make a new pouchdb database in the constructor allowed me to see the new database when I started the app. To see that the database was created, I had to open up the browser’s developer tools and go to application resources. After that I tried adding elements to the pouch database and getting them back. The nice thing about pouchDB is that the commands associated with pouchdb are pretty straightforward and it uses json objects by default. To add new elements to a pouchdb database named “db” you simply write “db.add(…)” with the element you want to add inside the parentheses. Then to retrieve that data element you can simply write “db.get(…)” with the element’s id inside the parentheses.
This sprint cycle also gave way to a whole new issue that my team will have to deal with in the upcoming sprint. In my last retrospective blog post I talked about pouchDB’s asynchronous capabilities with any server running couchBD. We learned this sprint cycle that the open-mrs server is not compatible with couchDB so we will be unable to apply pouchdb’s asynchronous functionality to this application. This may be a pretty big set back as we now have to develop our own service to ensure that data stays up to date between the open-mrs server and our in-browser pouchdb database.
Moving forward we will need to reach out to AMPATH and figure out how they want us to implement the offline storage component. Some of the things we will need to consult with them about are how the code should be structured, whether or not we need more than one pouchdb instance, and how we should synchronize the storage between the in-browser pouchdb database and the open-mrs server. As far as code structure goes, we need to figure out if where we instantiate the pouchdb instance is a safe place or not. I was thinking that we may want to write an offline storage module that handles all the imports and pouchdb logic and then import that module into the app.component.ts file. Next, we need to figure out if user credential information should be stored in a separate pouchdb database than the patient data to possibly provide better security. We will also be consulting with some of the other teams to try an figure this out. Finally, since we cant make use of pouchdb’s asynchronous functionality, we need to talk to the people at AMPATH to get some advice on how we should synchronize offline storage with their open-mrs server.
Another thing I did this sprint cycle is I started to put together an offline storage service that will be used to store patient records in our pouchDB database. The code I wrote for this can be found here: https://github.com/cpruitt1230/ng2-amrs/tree/master/src/app/offline-storage. I based some of this coded off of the advice given from one of the AMPATH developers on slack. Unfortunately I have not been able to test this code which should pull patient data from the open-mrs server and store that data in a pouchdbd database in the browser. Testing is going to be another issue that my team and I will have to address this sprint cycle as none of us are too familiar with how to write tests in angular not to mention tests that will ensure the in-browser database is storing what it’s supposed to. I’m looking forward to this next sprint as I feel like we are actually making some progress and hopefully we have a lot more to show for the end of next sprint now that we know how to get a pouchdb instance up and running.

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.