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.