At the beginning of this sprint cycle my team and I thought we had a pretty good handle on what we needed to accomplish and how we were going to do it. In the previous sprint cycle we had figured out how to instantiate a pouchDB in browser database as well as add elements and get them back through the console. To test whether we could get pouchDB working within the ng2-amrs application we added some code the app.component.ts file. Once we were sure that pouchDB could work in the application we moved forward in writing the pouchDB offline storage service. However, we were trying to incorporate open-mrs api calls in our offline storage service which proved to be much more complicated than we originally though. To remedy this problem we decided to break it into smaller pieces and Conor drew up a diagram in balsamic to help us not over think what we needed to accomplish. Here is the diagram Conor made:

In this diagram my team’s responsibility is the “Offline Data Storage Service.” Instead of trying to do everything at once, we decided we just needed to write a service that will store JSON objects in an in-browser database. By narrowing the scope of what we needed to get done to one task we have been able to make more meaningful progress.

During our team meetings we were able to get started in writing an add method for our offline storage service as well as corresponding unit tests. Through writing this method and it’s corresponding unit tests we found that pouchDB databases use JSON objects by default making our job a little easier. We have not pushed any new code onto our group’s GitHub page but that will be one of the first steps we take in starting the next sprint cycle.

In our last team meeting we were able to get everyone caught up on where we were at in the project and assign specific tasks to each group member going forward. After narrowing our scope down we decided that the main methods we needed to focus on for our offline storage service included add, put, delete, and clear. The add method will store elements in JSON format in the pouchDB database. As for the put method, it should take in the id of an element already stored in the database and alter the information of that element. Finally, the delete method will take in the id of an element in the database and remove the element, this method will also return the JSON object that was deleted. We also discussed implementing a clear method that could erase all data stored in the pouchDB database but we have not decided whether or not this function will be necessary to accomplish our goals.

Moving forward, my team and I will have to contact the Ampath developers and ask if they agree with the direction we are heading in. We will also need to communicate with other teams to make sure that our service can coexist/ be implemented in the other teams’ code. If everything goes as planned, we should have a functional offline storage service by the end of the next sprint cycle and we should also be able to start piecing together our piece of the project with other teams’.

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 4 was more or less a continuation of sprint 3. We started sprint 4 by reviewing what was done in the proceeding sprint. It appeared not much was done in sprints 3 due to the weather interruptions. This time around the team was able to meet on a regular bases and things that some of the team members could not accomplish on our own was brought up for discussion and eventually, fixing them. With regards to what was to be done, things were quite straight forward because we knew what we were up to at this point; we knew we are working on the offline data capture which the app is aiming on getting data collected in the remote location where there is no internet access and synchronizing it with the main server either automatically or by manual update to the service.

Also, another task for team was the online tracker component, which the team was assigned to work on refactoring it into a service that will include an indication as to whether the user is online or offline. The main idea behind this was to have the service include an indication in the form of green light signaling the user is online or a red light for offline. That is to say, the user is connected to internet or has no internet connectivity.  Even though, Jason had this aspect of the work completed, which work exactly as we have projected it to do and ready to push back for consideration in sprint 3, we were unsure if AMPATH will accept it. The good news to this is that the pull request got accepted and it is now part of the AMPATH app.

Again, back to our offline data capture task, the idea of using local storage system was established and we were going to research how to syncs the data to AMPATH main server. We were unsure of the encryption part and as far as I know, the team hasn’t been able to lay hand on something useful regarding how we could encrypt our data. Based on our research, we could synchronize our local storage with the main server through pouchdb; we found out that we could only achieve our goals by using pouchdb even though there might be several tools out there to do the same job. As we did in the proceeding sprint, we continued to dig deep into pouchdb by learning some tutorials of how to synchronize data between two servers and we finally landed on the idea that led us to install the pouchdb on the AMPATH app. We had error initially when we tried to install it but Jason figured it out that we could only do that by cloning a fresh copy of the ng2-amrs from the original repository. The errors exist because we modified the code setting in the beginning for compilation issues. Now we are able to remotely store dummy data in our pouchdb that synchronize with our AMPATH app.

In summary, I would say even though we were challenged in this sprint, with the enthusiasm and passion for the work we were able to have something going and I believed the team is keeping up with the enthusiasm that we put into work in the previous sprints and for being able to experiment pouchdb with the AMPATH app, we are confidence that our assignment would be accomplished at the end.

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 week I got as far as I could with my spike solution before my group reconvened and chose an encryption library to use going forward.  I was finally able to work with PouchDB (creating a database, storing and retrieving data) successfully.  Unfortunately, I wasn’t able to use crypto-pouch to do what we needed to.  It purports to extend PouchDB features, but even when installed and included in dependencies did not actuall appear to add the proper functionality.  Additionally, it does not provide the kind of granular, on-demand encryption that we think will best suit this project’s needs.

Most of what I learned from my spike solution over the last two sprints is that working with multiple packages from different sources can be a challenge.  Also, I had to do some translating between javascript examples and the typescript that I was writing in.  I had to remove and reinstall modules at times, and I also learned that I really should have kept careful track of how I did what I did and in what order, so that if I broke it later I could reinstall more easily.

My group started this sprint with more independent work.  We all had some degree of success with our chosen encryption libraries.  It turns out that, of the libraries we looked at, only bcrypt was suitable.  It has the features we need (password salting and hashing plus on-demand object encryption), and is easy to install and use.  After the group made that determination mid-sprint, we reallocated work.  One person started to figure out how to implement the features we need with bcrypt.  The rest of us started to work out how to test our functions in Angular.  We also created a prototype data flow through our service on Balsamiq.

I think as a group we learned more about how to evaluate external libraries for our needs.  While I think that the way we used this sprint was worth our time both from individual and group learning standpoints, we probably could have saved some time if we’d known going in what to look for in encryption libraries, or written a specification of some kind that we could then look to fill.  We ended up with the following requirements, built from Ampath’s specifications:

• Need to be able to salt, hash, and store passwords and then compare an entered password to the hash.
• Need to be able to encrypt arbitrary data objects and decrypt them later.
• Need to be able to encrypt/decrypt pieces of data on demand, and in a granular way.  This potentially allows more than one user to have data saved on the device, accessible with different keys.

Going forward, I think our biggest challenges will be to make sure each team member is assigned an appropriate amount of work.  I think one or two people may be able to work on the module directly, one or two people can mock a module and write tests, but that still leaves at least one person without a clear task.

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

Last sprint, we were tasked with creating test-applications that utilized a few different encryption libaries, so we could get an idea which library would be the best to use for the implementation of offline-encryption.  We didn’t really finish doing that by the time this sprint began, so we decided to keep some of those tasks on the sprint backlog to continue working on them this sprint.  I spent the first half of this sprint researching and implementing encryption using the bcryptjs encryption library.  This sprint was divided by spring break, during which I mostly took a break from school work.  I did, however, do some refreshing of programming in JavaScript.  This refresher made me feel much more comfortable coming back from spring break.  I expressed my confidence in bcryptjs to my teammates, and presented them with a mock encryption service that I wrote.

The test-application that I made demonstrated bcryptjs’s usefullness in encrypting passwords, but my teammates were curious how the library would handle encrypting other kinds of data that we may experience within the Ampath application.  We came to the realization that bcryptjs is useful and easy-to-use for password encryption, but lacks functionality for encrypting other kinds of data.  We decided that this would be problematic, effectively eliminating it from our choices.  We communicated well and discussed our remaining options with a sense of direction we hadn’t had in the previous sprints.  After further research, we came to the agreement that we would run with the encryption library crypto-js. We began looking at resources for crypto-js and wanted to begin testing some implementation.  We also discussed potential strategies for dividing the work that we must do among our team members.  We do not have a solid plan in place right now, because we were unsure if it would even be necessary to divid the task among all member of the team.  During our next sprint-planning meeting, we intend to talk more about the division of labor and how we intend to move forward with implementation and avoiding compilation issues.  Unfortunately, when me, Erik, and Oren tried to run our application on the last day of the sprint, we all had the same compilation errors, despite having not changed any code since the week we worked on it.  We spent the remaining day of the sprint troubleshooting this issue, to no avail.  Shane and Caleb, members of the ‘Everyone Else’ team, recommended that we try running the command ‘npm rebuild’ in the WebStorm terminal, which is what he and his team members did when they encountered this issue.  I have not tried this solution out yet, but I intend to in the next sprint.

I feel that we made some real progress this week.  We were able to successfully agree upon the best-fit library for our task, and we began troubleshooting errors so that we can get back on track to implementing offline-encryption.  I feel much more comfortable with our strategy than I have been feeling in the previous weeks, and I feel very motivated moving forward.

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

Our team, Everyone Else is making good progress with our first module. Sense we are solely tasked with creating the offline data storage module, we had to narrow our view. We had been worrying too much about how the other modules would work with ours and didn’t focus much on just creating the offline storage module. After our meeting today, we could tell we were more focused on our task and our task only. Connor created a flowchart on Balsamiq showing the flow of the data and where we stand in the whole project. Basically we just need to create the place to store data with appropriate methods and let the other groups do their legwork. I noticed myself going to ask questions to the team that really had no relevance in our current progress of the project. Instead of focusing on getting ANY items stored, we were worried about storing the CORRECT data. Realistically, we just needed to do tests with any JSON Object to ensure that it would work. That is what we are focused on now, getting our module working and worrying about the perfection later.

This sprint was a real confident booster for me. I finally sorted out all of my issues with the application. In case you find yourself in a situation where your app won’t  build properly, I highly suggest trying “npm rebuild” in your project folder.  This reloaded all of the dependencies I had previously installed and ended up working after the first try, even with pouchDB installed!  I still feel slightly behind on knowledge, but working with my team I am learning more every day. I think if we had previous experience with this language, we would have a much easier time with it. However, for our team never working with angular before, I think we are making very good progress.

I am now in a position where I feel comfortable adding to and testing the project. The angular learning curve is steeper than I had expected but I am slowly making progress with it. I would be lost without my teammates. They helped me figure out the errors and save my project file. While I was struggling getting my code to run, the team had already taken a couple of leaps forward. We created the actual service and have a basic test implemented. We officially moved out of the research phase and are getting into the production of code. We each have our own method we need to implement by next meeting and I feel as though our progress will speed up tenfold.

I am in charge of creating the “put” method for our database so that we can easily add information into the database that we created.  Caleb, Fuverion, and Ben will be writing the other methods. Connor will be doing the majority of the testing. With the tasks broken down into different jobs we should be able to efficiently finish this module pretty quickly and show it to AMPath for improvement.

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