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.

At the end of last sprint, 3 of our 5 team members were unable to run the application due to compilation errors.  The compilation errors continued into this sprint which made our team unproductive and a bit disheartened.  I think low-morale in the team caused a bit of a stand-still and some of our meetings were short-handed with regard to present team members.  Members of the ‘Everyone Else’ team gave us some advice on how to get our application running again, but it did not work.  As a last-ditch effort, we contacted somebody at Ampath to ask how they might resolve the errors we were experiencing.  They did not respond for several days.  During those several days, we happened upon a solution while discussing implementation with another team, and we concluded this sprint by successfully compiling the application.

The few meetings we had with team-members present comprised of planning our strategy for implementation (for when our team members are back on board) and creating an API for our offline-encryption service while we worked on finding a solution to our compilation errors.  We figured that, with only one sprint remaining, we will only be able to create an offline-encryption service for encrypting login and patient information.  We wrote a mock-service that utilized the crypto-js encryption library to encrypt login and patient information, and then used that mock-service to write an API for our planned implementation.  Once we finished the API, we sent it to somebody at Ampath for approval, and they approved it.

We then went back to addressing compilation issues.  Like many of the other developers working on this application, I have had compilation errors previously, and figured that I would be able to use one of the fixes that I had already found.  However, none of the fixes that I had used previously were working to get my application compiled and running again.  Me and the other team members experiencing this problem convened with members of ‘Everyone Else’ and they advised us to run the command ‘npm rebuild’ to potentially fix the compilation erros, but this did not work.  We contacted somebody at Ampath for advice about how they would resolve the kinds of compilation errors we were experiencing, but they did not respond by the end of the sprint.  While we were waiting for a response, we happened upon a solution while discussing implementation strategies with another team.  Matt Foley pointed us to some installation and compilation instructions that he was presented by somebody at Ampath.  This solution worked for the present team members, and we shared it with the our absent team members so that they could also get the application running.  As the sprint wrapped up, we were all able to successfully compile and run the application and, now that we have all members up to speed and an API approved by the people at Ampath, we should be able to fully resume work on implementation and we hope to have some deliverables worth presenting at the end of the semester.

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

Unfortunately my team and I were unable to meet the goals we set for ourselves at the beginning of this sprint cycle. The biggest issue we’ve been facing is writing tests for our offline storage service which implements pouchDB. In researching how to write meaningful  unit tests in Angular for services that implement pouchDB, we have found few helpful resources. The pouchDB API, which can be found here, provides little documentation on this subject so we have been forced to refer to git-issue pages and various tutorials. The issue with these resources is they tend to be somewhat outdated and don’t exactly match our particular use case.

My team and I have referred to the pouchDB API when it came to writing methods for our offline storage service. Our methods are pretty straight forward as they implement standard pouchDB functions such as get(), put(), and remove()  for getting, adding, altering, and deleting data from the offline storage database. So, for the most part, we believe our methods are correct and function as intended. However, in order to be sure our methods are functioning correctly, we need to write meaningful unit tests in Angular. The first test we wrote just checks to make sure the pouchDB in-browser database is successfully created. This test passed and when we looked at the web page Karma opens when the tests run we can open up the developer tools and see that our database is in fact created. This is depicted in the screen shot below:

Although we can see that our pouchDB in-browser database is instantiated, we run into a mess of problems when trying to call pouchDB functions. For instance, when trying to add elements into the database we use pouchDB’s “put()” function and pass in a string which then gets parsed as a JSON object. To test this method we created a mock patient object, in JSON format, at the beginning of our test class and tried confirming it was being successfully added by checking the Karma test page in the browser. I should mention that the process of debugging has been quite difficult when trying to figure out why tests aren’t passing because many of the error messages  generated after tests fail seem to lack essential descriptive information. I say this because we are rarely given specific line numbers from our service indicating where the errors occurred. Instead, we seem to get a bunch of references to files that we aren’t concerned about. I feel that this may be partially due to our lack of experience in writing unit tests in Angular.

I was actually able to make some progress today in testing the “addDoc()” method for our offline storage service. Previously, we had gotten the test to pass but I was left unconvinced that it was actually working as intended because I could not see any data being stored in the in-browser pouchDB database. After some trial and error I was able to get the method to work and physically see the data in our pouchDB database. Here is a screen shot depicting the data that was successfully added:

Now that I understand how to get mock data into our offline storage database, I will relay this information to my team and we should be able to make some real progress as this has been one of the main issues holding us up.

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.

Sprint 5 was a continuation of sprint 4. Again, we started sprint 5 by reviewing what was done in the sprint 4, particularly our achievements and failures. As a matter of fact, we revisited pouchdb to make sure that we have it installed and running in everybody PC. This success in Sprint 4 has helped us very much in continuing to explore ways of capturing the offline data. In Sprint 5, there were no any interruptions and the team was able to do our regular team meetings without any interference. I will say Sprint 5nwas very effective in terms of meetings and discussions. We were able to hold effective discussions, coming up with some ideas and also explaining to each other what we meant by the ideas we came up with. I will personally give credit to Rick Phillips for offering those pieces of advice. His advice has been very informative and that has helped the team a lot in doing and understanding our work. Jason has also been doing well in integrating those ideas we came up with and the advice offered by Rick Phillips into code.

Again, for our offline data capture task, even though, the idea of using local storage system was established in the previous sprint, the team was still unsure of if the pouchdb I have been preaching on since day one will work for us. But now, I can authoritatively say that the team is confidence that we could capture the data remotely using pouchdb based on our further experiments. As usual, we continue to and will still do more research on pouchdb to gain insight of how we can possibly capture the data; we continued to dig deeper into pouchdb by learning more tutorials of how to synchronize data between two servers. One of the major problems we were facing in our data capturing task was getting the data. We could initially write a dummy data into the pouchdb but we wanted to capture the data from the AMPATH database. By Rick advice, we were able to search for data through the patient database of the AMPATH and store it into an array which we could iterate through to store each into separate files in pouchdb.

Besides, at this point, we look close to getting the task done but still face some problems. We are not completely sure of what need to be sync back. I personally suggested to the team that I think the ideal way is to synchronize just the differences. I will prefer we are able to add a function that checks for difference and synchronize that to the database than synchronizing the whole data captured remotely including the old that was retried while going offline. I also think it will not be useful for the doctor to have a whole bunch of data that he/she doesn’t need and I think we should be able to come up with away that the doctor could filter the data down to just what he/she need at the time when he/she is going offline. This also led us to haven to design a GUI for the doctor. With regard, I created an abstract ER Diagram with three entities; thus the Doctor, Appointment and Patient, showing how the relationships and cardinalities. Rick and I are now waiting to kickoff with design for the GUI when we are clear of the filed they want us to include.

In summary, I would say this Sprint has been very interesting due to the enthusiasm and passion that we put into work. I believed if the team keeps up with this enthusiasm, we would definitely get the work done. I also think the work sharing that has been listed on trello board will also help keeps everyone busy.

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

This sprint we finished our prototype API and had it approved by Ampath.  We also started working through the implementation details for our service as a group.  Finally, we figured out how to repair our local versions of the app and get our group repository in synch with Ampath’s master branch so that we can implement our API over the next sprint.  I learned how to coordinate with other teams to build an API, and how to implement password hashing and data encryption.

I think the biggest takeaway for me this sprint was how to coordinate with other teams on a project to write an API for them to use, and how to integrate details of their implementations into my team’s work.  Because we’re providing a “background” service for the other teams, they can work for now assuming that our service will do what it’s supposed to.  However, this means that we need to understand some details of their implementations so that we can provide them with what they need.  Given the speed with which the semester is coming to a close, the encryption service may not be integrated into other services or components this year.  However, we hope to have something that’s usable for Ampath or another group working on this project to take over in the future.

Our biggest job this sprint was to work on our service’s public API.  We did this primarily through team work periods in class.  This followed a roughly three-step process, which we repeated until we believed our API was in a state where we could send it to Ampath for approval.  First, we spoke with another team to get a handle on their requirements for our service.  Second, we wrote a set of function signatures that we believe filled those requirements.  Third, we discussed implementation of those functions and what other private functions we might need to implement them, as well as which parts of the Crypto-JS API we want to use.

One of the biggest parts of this discussion was to figure out how we want to derive private keys and store hashes in order to provide the best compromise between security and usability.  For password hashing, we decided to store a hash derived from the password with salt derived from the username and timestamp of the offline session creation.  This will be stored with the username in-browser, by the offline login team’s code.  For private key derivation and storage, we spoke with Ampath and agreed on temporary private key storage for the duration of a login session (the key will be generated from the password using a password-to-private-key function and stored in a file that is deleted on logout).  While not optimally secure, this allows encryption/decryption of data without requiring password entry for each data operation.

We followed Jason Knowles’ intructions to rebuild our apps, and used git to update our team repo with Ampath’s latest changes.  For next sprint, our job is to implement and test as much code as we can manage.

I think our team coordination could have been better this week.  It felt like a lot of what we were doing didn’t engage the entire team, although I’m not sure how to manage that better.  Not everyone was present for each work day for varying reasons, although we did keep in touch on Slack we could also probably have kept better notes to send to absent team members.  I think dividing up labor will be easier next sprint since we have actual code to work on.  We will have to make sure we keep our repositories synched, as we don’t have a ton of practice with that.

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

This sprint was not a complete success. We wanted to have some code pushed and maybe make a pull request to AMpath. However, our progress was delayed due to our inexperience in writing angular 2 methods and testing them effectively. I learned that testing code in a language you haven’t studied can be exceptionally difficult to grasp. I am still trying to work out the uses for toBe(), toThrowError(), toEqual(), and how the expect works in the test suite. Writing the method for the code seemed easy enough and I think I have the correct code, however it is hard to confirm when testing isn’t going smoothly. I understand that writing tests first would have been the correct way to do this, but I can’t write tests for code that I don’t know how to write. Therefore, I had to learn how the code worked and look at the API for pouchDB (which you can find here https://pouchdb.com/api.html) to ensure that I was using the correct calls and what-not. If I could restart this sprint, I would spend much more time on learning how to test in angular (sense that is the most frustrating part to me) rather than writing the code. At first, I was coding a method that was too complex, with the help of google I was able to finish my updateDoc method (as far as I know).

Our team is working well together, I think we could do a little bit better helping each other remember to do our standups and evaluations. Besides that we work really well together. I think we are all contributing equally to the project, so there is no problem there. As a team we feel as though we could have gotten this sprint completely finished in the allotted time if we had prior knowledge of testing in angular. However, it is what it is. Our next sprint will most likely focus around testing the methods we have created and tweak them to try to perfect them.

Our sprint plan was to finish this module, obviously that didn’t happen. Each of us was responsible for writing a method and Connor was responsible for testing. I wouldn’t blame Connor for the tests not being done because he still has to learn the testing procedures for angular as well and if he has to write a test for each of our methods, that is bound to take some time. So each of us has been pitching in and trying to debug together. This means that our sprint goal will most likely be extended to next sprint as this really is the last step to finishing off the Offline Storage Module.

I am interested to see what will happen when we (our entire class) conglomerates the code and tries to piece it together. I can imagine that some snags will occur and it won’t be very smooth at all. We will have to assign different people to test different parts of the entire offline module to ensure that everything is compatible with each other.

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.