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

Last week marked the end of the end of sprint 4, and we successfully built one the last sprint that we had. During this sprint got to learn a little bit more about javascript, angular, and generally how the front end of an application works at a higher level. Going through the code with t

he team find the correct way to implement the offline auth gave me a better understanding of local storage and how web browsers like Firefox and chrome save data. Being able to use the same local storage used throughout the AMPATH application, we were able to see places that we may not have to use pouchDb thereby saving us some time. I wish I had known about this before because if I did, it would’ve sped up the time that it took to understand the correct implementation that would be required.

As usual, the team worked together very well. Our team was able to come up with a basic implementation because we all threw out ideas and tried to help each other understand the problem. My participation was extremely helpful this sprint because I provided some potential ideas/and approaches that our team could take, and some of those ideas were built upon to come up with the implementation that we currently have. During this sprint we accomplished lots, was able to locate some of the server side API code and looking through it helped me come up with a few implementation ideas that I shared with the team. Our team was also able to get the flow laid out, and we plan on sharing that with AMPATH soon to get their thoughts. Most important accomplishment by far was actually being able to save the user info when logging in and using that later on to log back in when offline. Although this implementation currently falls short of a few AMPATH requirements, it is a fantastic foundation that we will build on in the following weeks.

Having built this foundation cleared our vision for what we need to do next, and what we need to add in before we can really consider this complete. Currently our version of the app knows to use the offline auth to log in via handling of an error received when offline. This method is not the most graceful and is very limiting. Another team has completed a proper offline checker, if we had realized this sooner we could’ve easily used that instead. Integrating with the offline checker will be one of the first things that we do going forward. We also plan on having an API defined and documented, not only for our team, but for any other team that could need to integrate with our component. We also plan to communicate with the encryption team as well as the storage team, even if they don’t have a complete implementation yet we can at least try to agree on how our components will mesh.

This sprint went very well and we finally have a concrete product from it. The plan is to keep up the good teamwork and communication so we can accomplish even more next sprint.

From the blog CS@Worcester – Site Title by lphilippeau 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.

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.