This week marked the end of sprint 5, and so far this one was by far one of the most informative sprints for me as well as the most productive. This week I got the opportunity to dig much deeper into typescript because I needed to implement some back-end code. I got a chance to actually implement some of the basics that I had been reading up on, such as declaring new variables and making variables visible from one class to another. I know these are some very basic things, but this was an important thing to do because it is fundamental to every programming language and having this foundation will help me build and implement more advanced functionality that we will soon need. I also learned that Ampath has some very strict code style settings. I had the build complain because I declared a public variable after a private one, and also because I had left an extra new line between two of my methods. I of course realized this after I had already pushed my changes up to later receive a message telling me that I had broken the team build. Had I known in advance that these rules were so strict, I would have checked the state of the build before pushing up my changes because even though this did not hold our team back long, this is something that could’ve wasted tons of time and should be avoided in the future.

The team worked very well together during this sprint, I would go as far as to say that this was the best sprint that we’ve had teamwork wise. I was having a few build issues and my team members quickly helped me resolve them so I could get back to work. The later on another teammate was having an issues that I previously had, they asked for help and I was able to quickly get them back on track. Even the way that we split our tasks was efficient, we had individual tasks that we would later link together. We would definitely like to keep this very high level of teamwork going forward and improve on it if at all possible.

During this week, the main focus was to get a checkbox or switch that could be toggled to decide if the user would like to save their credentials for later storage and let that determine what happens going forward. We were able to get that done, I was in charge of writing the back-end code (which was fairly simple) and Dominique was in charge of the UI aspect. That however was not the only work that was completed this sprint. There were improvements made to the offline detection that our code used. Previously we would know that we were offline because of a failed API call and our logic would run from there, now we use the service that was written by another group. We have also run some of our proposed changes by Ampath to ask for their approval.

This sprint, we have accomplished a whole lot and the coming sprint we plan on tidying up most of what we did. I believe that after the coming sprint, we will essentially have a nearly have the offline functionality exactly how we want it and we can shift gears and focus on other things like encryption, but in the meanwhile we will continue building on the progress we’ve had.

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

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.