Category Archives: Sprint 4

Sprint Retrospective – 4 April 2018

This sprint was easily our best one yet. We were highly productive, completing a range of tasks concerning design, merging with other teams and test-driven development. Where the previous few sprints have illuminated the pitfalls and obstacles of Agile development to our team, this sprint gave us a feel for what it’s like when Agile development is running like a well-oiled machine.

Not long after the beginning of the sprint, we identified a design dilemma that had us scratching our heads. We noted that if we had the patient data encrypted with an algorithm that made use of the active user’s password (as all groups seemed to agree upon), then we would run into a problem:

Suppose Doctor A is logged into a machine, making use of the offline data module. He does his work, no problems, everything is fine; all patient data is encrypted with respect in some capacity to his password. Suppose, then, that Doctor B comes along and tries logging into the same device. In spite of having provided perfectly valid login credentials, Doctor B will be unable to access the patient data, due to the patient data being encrypted with respect to Doctor A’s password. We spent a few days trying to figure out exactly how to solve this predicament, but our ideas kept coming up unsatisfactorily for a number of reasons.

I take some pride in being the one to figure out the answer, and consider it one of my two major contributions to the team this sprint. It turns out that the way to both satisfy the specification (which lists that the login must feature encryption using the user’s password + a salt) and the dilemma we encountered was a split in what we were storing. Rather than a single offline database, we would have two. One of these would be responsible for storing the patient data – encrypted with its own algorithm, irrespective of the user’s login credentials. The second database, however, would consist of only strings. Specifically, each string would be the result of running the encryption algorithm with respect to the user’s password on their user ID. For login, the method would therefore be:

  1. User enters username/password
  2. Run the encryption service on the username provided, using the password provided
  3. Perform a database lookup for the result in database 2
  4. If there is a match, successful login. If there is not a match, unsuccessful.

This information was spread to the other groups and has been accepted as the plan for all encryption service use moving forward.

In addition to this important design step, my other major contribution this sprint was in writing test cases for the create, addDoc, and getDoc methods. In class, we were able to get tests to pass with the code written by other members of the team, and observed in browser that a PouchDB database had successfully been created, added to and read from.

The biggest takeaway from this sprint was easily that having specific roles in the group is a powerful motivational force. When it was determined that I would fall into the role of test writer, and the other members of the group picked their specific methods to focus on, it was clear that we had each found the direction we needed in order to get the ball rolling. Going forward, I hope we will continue this practice of providing concrete roles for one another, to make the project feel less like a behemoth and more like a set of separate goals to be achieved.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 4

This week’s Sprint retrospective we had many issues. Most of the group could not open ng2-amrs program. So, for some of the sprint we were trying to get it working. When we first saw the projects, we are all able to download and able to run ng2-amrs program without any issues. However, for some reason four out of the five people’s program were not working. We sent messages to Ampath to see if it was something that they would be able to help us fix. However they were no help. We were also asking other students in the class of they were having similar issues but no one else was having the same issues. Most of us tried uninstalling and reinstalling the program and it did work for a few. While we were trying to work on fixing the ng2 we were also thinking of ideas of how to get this encryption service into the website. First we were thinking that they wanted only an encryption for the password. But from talking to Jonathan this encryption service was meant to encrypt everything from data coming in, going out, passwords, and files. We were looking up research about other encryption services that might have done this before but most of the encryption service are not done offline. This is because we would not be able to save the hash password and the salt on the tablet because if we did they would be saved on the tablet they are using. That is not really safe a encryption especially because it is patient data. At this point we are confused with what we must do. Unlike other projects that give us specifications and an end goal of what they want. The ampath project is different for us because you cannot just message them and expect a response right away because they live on the other side of the world and most of the times when we are brainstorming ideas on what we want to do. We don’t know exactly what they want and when we do ask they gave us a “yeah that seems fine.” kind of answer. Most of times we just want exactly what they want. For me this project has been difference because for other classes and other products that I have been working on such as personal project and project for classes I would be told what the final expectation for this project would be. Since this project for Ampath is such a huge project and many of us are just learning new stuff just for this project. We don’t know much of what they want or what to do. Once we understand that they wanted a websites that would be able to hold all the patient data offline so that they would be able to meet patients where they would have no cellular service. But part of the problem with that is when doing encryption services from the standpoint of view of programmers we want this to be perfect so that way and path would not have any troubles but I’ll find encryption to us feasible or possible we hope that the next Prince able to get a lot more work done we would try and get something so that they can work off of this or maybe the next project for the next class would be able to take the coat that we have now and work off of that

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

Sprint Retrospective 4

At the beginning of this sprint, we assigned ourselves tasks to request server-side code from the AMPATH team, to design a user interface for storing credentials offline, and several tasks related to PouchDB. We decided on a UI where, when logging in while online, a user could check a box in order to store their credentials so they could later log in offline. We created a Balsamiq mockup of this design and began investigating how to store credentials so that they would be accessible offline.

We researched PouchDB to see if it would be easy enough to implement that we could create a simple mock to use in our design. In the end, we didn’t use PouchDB to store our login information. From what we could understand, while logged in, the authentication service stored encoded information about the currently authenticated user in sessionStorage. It turned out to be much simpler to create a way to log in offline by storing the same information in localStorage instead, so that the information persisted even after the session ended. In this way, a user logging in offline could have their entered credentials checked against the information stored in localStorage at the time of logging in online. George posted resources to the team channel so we could understand this approach and was successful in getting this implementation working.



In addition this sprint, we contacted the AMPATH team to ask whether we were taking an approach they were happy with. They have not gotten back to us yet, so one of our tasks for the next sprint will be to follow up with them regarding this.

A current problem we’re facing with our implementation is that we only have one user to work with. We have no way of checking, for example, that User A can only log in if their entered credentials match User A’s stored credentials, not User B’s stored credentials. We also plan to ask the AMPATH team how to proceed in light of this, and we will possibly request another test user to work with.

Tasks to collaborate with both the team working on the offline database and the team working on encryption carried over from the last sprint. I didn’t manage to collaborate with the latter group, as they’re not far enough along for us to give each other useful information yet.

Our team worked well as usual this sprint, with members sharing our progress with each other and the class on work days, on our team channel, and on the AMPATH documentation channel. I personally spent most of this sprint improving my knowledge base so I could better serve the team in upcoming sprints. It should be easier to create concrete tasks which will get us closer to our goal now that we have a functioning implementation to work with, and I’m looking forward to contributing some work on the front end of the user interface. I think what I’ve been learning about JavaScript, the REST API, and asynchronous functions throughout this process will ultimately be useful for creating or working with any web application which involves authenticating users.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 4

During Sprint 4, our team worked individually on different encryption libraries to gain a little more insight into the quality and usability of each one. I continued to research WebCrypto API and found the performance of the library to be much faster than other encryption libraries.

The test platform was a MacBook Pro (MacBookPro11,5) with a 2.8 GHz Intel Core i7 running MacOS 10.13 Beta (17A306f) and Safari Technology Preview 35.

On the WebKit blog, authors noted what they thought the disparity was caused by, “Working with our JavaScriptCore team, we learned that the causes of these pure JavaScript implementations not performing well is that most of them are not actively maintained. Few of them take full advantage of our fast JavaScriptCore engine or modern JavaScript coding practices. Otherwise, the gaps may not be that huge.”  WebCrypto API also boasts better security models and gives an example why: “When developing with pure JavaScript crypto libraries, secret or private keys are often stored in the global JavaScript execution context.” Noting this leaves users extremely vulnerable as “keys are exposed to any Javascript resource being loaded”, and allows XSS attackers to steal the keys. WebCrypto API protects the secret or private keys by storing them completely outside of the Javascript execution context. Implementations on MacOS and iOS are based on CommonCrypto routines “which are highly tuned for our hardware platforms, and are regularly audited and reviewed for security and correctness.” They go on to say WebCrypto API is the best way to ensure the highest security protection. WebCrypto sounds like a great resource for quality encryption services but there are others that perform the same tasks and can do what we want securely. The team has decided to focus on CryptoJS, which in this case I don’t think performance will be a big issue, but will keep this information close because I may need it in the future.

I feel the team worked well during this sprint and learned a good amount amount each library. Respectively we worked on bcryptjs, webcrypto api, pouch-db/crypto-pouch, and forge. All options seemed to get the job done but felt that CryptoJS suited our needs the best, while still keeping in mind the Ampath team might have a different preferred encryption library. We all learned more about encryption, Javascript, and the use of Typescript services. My personal interest in security and encryption has increased after working on this project, and all the news we see every day about the privacy of consumers data being compromised.

The first week of the sprint, I spent researching WebCrypto API, looking for a solution to implement that into ng2-amrs. I found documentation but not many examples of how to implement it in Angular 2. I found examples written in Javascript but had trouble getting things to work. I found it difficult to  translate Javascript into Typescript, and how that is going to used in a Typescript service. While meeting with the team we decided that while the encryption libraries we all tested has their own pros and cons, we decided that CryptoJS best suits what we need to get an encryption service running. CryptoJS has more a little more information on how to implement what we need to get our encryption service running.



The post Sprint Retrospective 4 appeared first on code friendly.

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

Sprint 4 Retrospective

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

Sprint 4 Retro

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.

Software Development Capstone Sprint 4 Retrospective

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.

Looking Back on Sprint 4

I can’t believe that we’ve already completed four sprints! I am happy with the progress and minor breakthrough that we made during this sprint. It took a good deal of researching, trial and error, and investigation to gain the base of knowledge required to implement the rudimentary offline login authorization that I pushed to the team’s repository this sprint. I’m hoping that getting some code pushed up to the repository will be an impetus for driving renewed energy in sprint planning and the next sprint. Other things that we got done this sprint were important for ensuring that we remain on track to integrate our work with the work of the other teams.

Some of the tasks that we completed during this sprint are no longer applicable because of how we have decided to move forward in development. One task that is no longer applicable is the “Locate server code” task. Locating the server code is no longer applicable because we have implemented the offline authentication in a way mimics a response from the server rather than mocking the server itself.

Another task that may or may not be applicable are the “Install PouchDb on AMPATH app” and “Create ‘Mock’ of PouchDB (dependent on PouchDB investigation)” tasks. These tasks were certainly worthwhile even if we do not proceed with implementing the storage of credentials using PouchDB because the offline data storage team appears to be using PouchDB. We will likely move forward with storing the login credentials using localStorage because there is far less overhead and services already written into the ng2-amrs application.

While we attempted the “Contact APMATH team to determine if we are taking the correct approach” task, we have not yet heard back.

One of my assigned tasks for this sprint was “Store user credentials in localStorage so the user can login offline.” I managed to store both the “auth.Credentials” and “user” objects in localStorage once the user successfully logged in online. This user information is then later extracted from localStorage when the user attempts to login offline and used to create a session that authenticates the user.

Tasks that we will be carrying over to future sprints include “Create back end design of new UI using Balsamiq,” “Collaborate with ‘Everyone Else’,” and “Collaborate with ‘Field Idiots’ (Sprint to Sprint).” These tasks will be carried over because they’ll never really be completed, they are ongoing.

Although many of the tasks for this sprint may end up being no longer applicable moving forward, the team seems to have been productive during this sprint. In planning for the next sprint, I think it will be much easier to assign discrete tasks now that we have a basic implementation on which we can build functionality and add features. I’m hopeful that we will soon be knocking off todo items and have a fully functioning offline authentication in no time.


From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Sprint 4 Retrospective – Narrowing our Scope

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:

 Offline Data Module Architecture

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 Retrospective

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.