Sprint #4 was a very productive sprint for my team. We were able to get a lot of research and planning done in regards to the tab component that we will be creating for the AMPATH project. We also narrowed down the exact functionality that this component will have and discussed how it will interact with the rest of the app. During this sprint, each member of my team began coding an Angular component to get a better understanding of how we can implement the tab functionality. I was able to create a test component with tab functionality that displays patient information.

My plan for writing the test component was to follow the beginning of the Angular Tour of Heroes tutorial then build off of it. This was a useful way to do it because I was able to start with a base application that I could modify into something else. My team decided that we should each create a component just to see how it worked, so it didn’t necessarily have to be related to the tab functionality. However, I decided to build a tab functionality for my component because I felt that it would give me a better understanding of what we would have to do to to get our project built. What my code does is display patient names on tabs at the top of the screen. When you click on one of the tabs, it brings up information about the patient including the name, id number, age, and gender. It also allows you to edit the patient’s name, which reflects instantly on the tab itself. For our actual project we will need to connect to some sort of database for patient information, but for this test I just created a Patient class with the attributes that each patient will have. I then have a mock-patients.ts file with an array of predetermined patient information. The patients.component.html file is where the tab functionality resides. I used the Angular Material Design tab component to build the tabs. This link was very helpful for showing how to implement that: https://material.angular.io/components/tabs/examples

The biggest challenge I had was making the correct set of patient information display when clicking on a tab. I originally had something similar to the Tour of Heroes tutorial, where clicking on something brings you to a separate section of html. However, this didn’t work great with the tab functionality, as it required waiting a few seconds before clicking on a tab would bring up the correct information. I was able to fix this by putting the part that displays patient information in the mat-tab-group and using *ngFor.

Overall I feel that this we made a lot of progress during this sprint. It felt good to finally code something with a tangible result. By creating the test project my memory of Angular and html was refreshed and I learned how to implement Angular Material Design. This will be a big help throughout the next few sprints as we develop the tab component for the AMPATH project.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

During this sprint there was a lot of confusion on how we should move forward with certain things. In the last sprint we were able to determine which components each team was going to be working with but we have yet to set up our branches on GitHub. We sat down as a class to recreate the whole Git system/directories/branches. We decided to pull fork the original, clone it, and moving forward we would add any changes we make to our code to our forked repo and create an upstream to the original to be able to merge as a class.

There were some problems we encountered; the biggest was not being able to correctly style our component given the angular material code. We hope to be able to solve this issue by the end of the next sprint. Other than this, we had some minor issues when actually running ng serve but we later found out that some of our angular versions were not up to date. A simple update fixed this.

That was pretty much all for this sprint. Our goal for the next sprint is to finish our component!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

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.

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.

sessionStorage: https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage

localStorage: https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage

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.

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

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

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

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

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

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

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

During the fourth sprint of our Software Development Capstone class, my team and I made some progress towards fulfilling our primary task of creating an offline data capture service. Some tasks that we created in order to reach towards the offline data capture were to figure out and introduce ourselves to pouch-db and how it could be implemented with Angular and the AMPATH code, getting pouch-db to work and compile with the AMPATH code, and researching cryptojs and finding out if it would work well with pouchdb to establish an encryption service with the offline data capture service. We manage to tackle these tasks that we created because other teams had researched cryptojs and pouch-db, so we felt that we had to do the same by introducing and exposing ourselves to these JavaScript implementations.

When we attempted these tasks, we managed to successfully learn about pouch-db and got some ideas about how it would work with the AMPATH code. Once we gathered all of our ideas together during our meetings and communication on the team’s slack channel, we started to tinker with the code itself and installed pouch-db within Webstorm’s terminal so that the dependencies can be present within the code. At first, we had trouble getting pouch-db to work with the AMPATH code because we kept getting compile errors. We assumed that the errors were coming from the packages that were installed from the pouch-db installation, which happened to be true. So, our team member Jason, stepped up and tried to find out how to troubleshoot this issue. He went and found how to properly install pouch-db since we had initially installed it the wrong way. We had to clone a clean copy of the AMPATH code from our own repository and make a new project from that copy. Once that was done, we had to remove the “Package-Lock.json” component from the code, then install it. That component happened to be the main cause of the problem. It was smooth sailing from there, and we successfully connected to the AMPATH server and log into it without any issues.

For crypto-js, we are still researching it and is considered an ongoing task. However, since my team and I did not come up with any ideas with the implementation of crypto-js in our offline data capture service, my team and I can categorized this task as a failed task for this sprint. Our goal is to get some ideas on crypto-js and implement it successfully by the end of the next sprint.

My team and I learned a substantial amount from this sprint, especially about the implementation of pouch-db. Despite the problems that we had with it initially, we overcame that problem through effective researching and communication within this team. I can’t think of any way to approach it differently because I’ve seen that with this group, we learn most effectively through trial and error. I felt that we researched pouch-db the best we could’ve done and successfully implemented it despite of the first compile error we ran into. This situation could be applied in other situations with any software development workplace. Working through trial and error is normal with this type of work and learning to overcome issues that may arise is a daily obstacle for developers such as myself, so I feel that this obstacle that we had with pouch-db was a great learning experience.

I feel that my team and I were very productive throughout this sprint. As an individual I had done my fair share of work and expected good quality from everyone. I mainly researched articles about pouch-db and crypto-js, and communicated the information that I found out to my teammates during our sprint meetings. For everyone else, they did wonderful. Jeremiah did his job with participating in team meetings and communicating over slack to remind each of us to do our standups. Rick helped gathered ideas for the code itself. Jason did the most work with the code and was the main person to work directly with AMPATH in getting ideas from them and at the same time getting pouch-db to work.

Overall, I’d say this sprint was very successful.

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