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.

This week marked the end of Sprint 3, and during this sprint I feel like thus far this was easily the most productive sprint. Although we did not spend too much time writing code, we did do a substantial amount of planning. I think that the planning that we’ve done will make producing our component that much easier and because of this I am looking forward the the following sprint that much more.

Although the majority of the following sprint was spent planning among our team and others, I still learned some things from it. Our team spent time trying to understand the way that they currently do authentication and what changes we’d need to make to be able to do it offline. Investigating the auth code forced us to go deep into the code. We started from the ui and followed the code until we found the REST call that is made to the server to authenticate. Having followed the code to this extent, the team and I now have a very clear understanding of how it works. This investigation has also revealed to us that we may need some access to their server code as to understand better exactly how the user authentication data is queried from their end.

Had we known from the beginning that we would’ve needed some access to their server code, we could have asked them from the beginning of the sprint and save some valuable time that was wasted searching for it.

As usual, the team worked very well together we did a great job breaking the tasks down and evenly spreading them out among team members. As for performance, we completed more tasks this sprint than previous sprints but the best thing that I think came from the sprint was the discussions that we had, every member of the group contributed their ideas and it really helped us see different potential solutions to some problems and pick out which one is best going forward. Individually I think I performed well, I contributed some useful ideas and helped the team come to some key design decisions. The previous sprint, time was a slight issue for me so I feel as if I did not do as much as I could’ve, but with the time that I did have I think that I used it very well. Going forward I think that we need to continue doing what we’ve been doing and build on the great sprint that we’ve just had.

The following sprint will involve a bit more documentation as we clearly layout our interface and make sure it coincides with that of the team doing the database component. Another big part of the next sprint will be communicating with AMPATH and asking them for the server code and asking for their thoughts on some of our current data designs, hopefully we can communicate quickly and get our answers so we can begin implementing because we intend to spend the majority of the following sprint  getting a large portion of the implementation complete.

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

Sprint 3 has been very challenging due to the weather interruption of our meetings. In my opinion, this print has not been effective even though we individually learned or did something that was geared toward accomplishing our task for the sprint. In this regards, I think our goals for this sprint has not yet been met. For instance, we started sprint 3 planning by deciding on what service to work as a team. We chose the offline data capture service to work with. this service  was chosen with the mindset that the app is to collect data in the remote location where there is no internet access, so that when the user comes back to a network zone the data that has been gathered is either automatically synchronized with the main server or manually update the server to add up the new data.

Also, the team was again, assigned to work on refactoring the online tracker component of the app into a service that will include an indication as to whether the user is online or offline. This service will include an indication in the form of green light signaling the user is online or a red light for offline. This will basically tell the user whether he/she is connected to internet or has no internet connectivity.  Thanks to Jason, this aspect of the work has been completed and ready to push back for consideration. He has re-factored that part to work exactly as we wanted it to do.

In order to achieve this goal we then tasked ourselves to go research into offline data services that uses angular platform as the AMPATH app is an angular based app and study pouch db to acquire knowledge of  how to synchronize the data captured remotely to the local server. With regards, I spent quit amount of time studying tutorials on pouch db and couch db which I think will work well with synchronization of our work if properly implemented.

Again, Jason and Rick Phillips came up with the idea for implement the local storage which I think is working well with AMPATH app. We can remotely save data into it. We are now working on synchronizing the data into the server which I think this a part that pouch db come in to play. I am pretty much sure based on my little knowledge with the pouch db, it’s going to work out for us. I am confidence about that because in my exploration of the pouch db, I noticed that pouch db got doc count and update sequence. The update sequence tells you how many revisions have been made to the entire database and this is the thing that help synches all the databases together. It also has a function such db.changes which keeps pulls changes to the database.  And to do that, live have to be true. Live true tells it to keep pulling the changes to the database.

The only area I haven’t looked at and didn’t want to commit myself to saying something about it is the encryption part of the data. As the data captured needs to be encrypted for security as well as privacy policy, we are yet to figure out how to add that to our locally captured data.

Besides, per the recommendation by Jason, I had also learned a couple of angular tutorials which help in figuring out of what is going on in the app

Though it has been a rough print taken into consideration the snow storms that kept the team out of meetings, I believed the team kept up with the enthusiasm that it put into work in the previous sprints and we are on the way to having more work accomplished in our future sprints.

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 was particularly rough. Every time we were planned to meet, we had a snow day. Communication was lacking at this time because some people lost power and we definitely couldn’t go drive. Not meeting up with the team left me unmotivated because I had questions and errors that I would of benefited from asking the team questions in person. My team is working really well together. We are all included in a group chat where we remind each other of standups, CATMEs, and tasks we need to get done. We communicate often over texting. I learned that communication is key, especially in person. The reason why in-person meetings are important is because it raises the morale of the team and reassures the team that we are making progress. Now that I know this, in person meetings are much more valuable to me.

I will be honest and say I feel a little bit behind after this retrospective. I am not picking up this new framework as quickly as the rest of my team, but I am trying to get to the point they are at in their knowledge. What is great is that my team will share anything with the group that they think is useful. Caleb was able to get a working implementation of PouchDB into the Ampath App which is an excellent start to our task. Once we were all together we tried to store some data and it worked! It wasn’t exactly what we were looking for, yet, but we are just trying to understand how the PouchDB database works. I think our team has been taking the right steps to getting this project done, I am just frustrated that it is only my computer that the errors can’t be resolved. I could of definitely put more time into getting this to compile and I am working on doing that now. I will be proceeding differently by being proactive and on top of tasks. I don’tlike feeling behind, so I am going to correct that from now on.

The reason I feel behind is because of the struggles I am going through to get the dependencies to install correctly. I have tried every method that team members suggest but to no avail. I have tried installing pouchDB first, then all of the other dependencies our project needs. That made the webpack fail to compile. Next I installed all of the original dependencies, ran npm install, then tried to install the pouchDB dependency into the project and the webpack failed to compile again. I have tried almost every combination of these installs and they all made the webpack fail to compile. I became sick of the errors. I cloned Caleb’s directory into a new folder and copied all of his files into my existing project. I then reinstalled all the dependencies into the project and ran it, it worked perfect (without pouchDB), as soon as I installed pouchDB I got a slew of errors. It’s like the pouchDB dependency is removing some of the packages that  I still need and I am working on how to prevent that.

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

This sprint, I learned about pouchdb, some about crypto-pouch, about the way that JavaScript handles asynchronous behavior, and how to create typescript classes to wrap objects that return from function calls.  My group worked well to distribute and plan our work for this sprint, but we were interrupted by multiple snow days and found that we work better when we’re all present to bounce ideas off of each other.

At the beginning of this sprint, we found five different encryption services that we could potentially use for the AMPATH app.  We decided to build a spike solution for each one, and each took one of them to work on.  I ended up with crypto-db, which is a small encryption extension for the pouchdb database system that other teams are using for offline data storage.  My plan was to follow the simple setup instructions at the pouchdb site to build a local database with one or two items, display the result of a database access without encryption, display the result of a database access with encryption but without the appropriate key, and display the result of a database access with encryption and with the appropriate key.  I also wanted to find one or two different ways to derive salt to use for additional security.

Unfortunately, it didn’t end up quite that simple.

The first step was setting up an Angular CLI project – it turns out Angular CLI updated recently to remove the ng init command, which made it harder to follow guides for project setup.  I also needed to install the dependencies and types for pouchdb, which was a little tricky — they needed to be installed after a general npm install, otherwise they were overwritten.  Once that hurdle was dealt with, I needed to learn how to actually use pouchdb.  Fortunately, there are instructions (linked above).  However, in order to understand them I needed to dig into what a Promise entails in JavaScript.

A Promise is, as I understand it, an object that allows asynchronous functions to exist.  JavaScript won’t run multithreaded, so in order to keep the scripts running properly a function must return something so that the script can continue, even if that return is delayed by a database access.  When the database access actually does come back, the Promise is able to execute a function of some kind (for example, set some object fields to values pulled from the database).

Once I had figured that out, I ended up stuck at another problem: the data that was returning from the database access could print to the console, but would only print [object Promise] when I tried to convert it to a string and display it.  On Monday, Dr. Wurst showed me how to wrap the return (which, for pouchdb, is a JSON) in a class that has the appropriate fields so that I can copy it to a local instance of that class and then access its fields from my html file.  I did not have time to implement this or get farther with my plan this sprint.

My group also had trouble of various kinds working through our spike solutions, so we decided in our retrospective and planning for the next sprint to push our current set of tasks forward.  Hopefully we will actually be able to meet during our designated work times; if not I think we will need to find a way to meet (or schedule digital meetups) so that we can accomplish our goals.

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

During the third sprint of my software development capstone, my team and I were assigned the task to figure how an offline data capture service worked and how it would work with AMPATH’s patient database. The reason for creating the offline data capture service is to enable the retrieval of patient data while in an offline status. This is important because villages in Africa may not have internet connection, but AMPATH still wants to add additional information to their patient database.

One thing that I’ve learned from this week’s activities was how to an offline data capture service worked. To figure that out, my team and I also created other small tasks that aid in figuring out the offline data capture service. Another thing that I’ve learned how to do as an individual was creating tasks from scratch. In addition to our product owner assigning tasks to each group, my team and I discussed on how to approach towards the goal of establishing an offline data capture service.  This lead to the tasks that we created for us as a team to do. Throughout the entire process, I wouldn’t have done it any differently because everyone in the team, including myself, was productive in the way that we did things. This experience can be applied in real life situations, especially software development jobs. Since I want to be in the video game development industry, I’m going to have to learn how to approach the goals and objectives by creating my own small tasks that will lead up to completing the overall goal of a project.

What we did during the week was that we tried to create a balsamiq diagram which displays our idea on how an offline data capture operates. We also researched offline data capture services in Angular, and found more tutorials on them. We also checked out pouchdb and how it would be implemented in our offline data capture service and researched encryption to come up with ideas on how our offline data capture service would work cohesively with an encryption service that another team in our class was doing during this sprint. We succeeded in utilizing balsamiq to create our diagram of the offline data capture service, learned pouchdb, understood how an encryption service works, and successfully came up with ideas about how to interpret the offline data capture service by reading online articles and other resources.

The work quality for this sprint was adequate for all of us to do. From the past sprints up until this sprint, everyone contributed fairly if not more for some of us. I’d have to give a lot of credit to my teammates Rick, Jay, and Jerry as they helped me as well as the entire team on making sure everyone was on the same page. Jerry reminded the group about the standups. His contribution to the group has improved from the last sprint and I felt he communicated more in our meetings in class and on slack. Jay and Rick did an exceptional job of finding some resources about the offline data capture service and they both did well creating the diagram as well. What I did throughout this sprint was a lot of information retrieval which I shared as much as I could with my group about pouchdb, the encryption service, and about the offline data capture service. All of efforts played a huge role in getting us to where we are at with the offline data capture service right now as we are putting the pieces together with our diagram and our ongoing research.

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.