Category Archives: Sprint-3

Sprint Retrospective – 14 March 2018

This sprint, unfortunately, was cleaved in twain by Father Winter. There were multiple white-out blizzards, which resulted in numerous missed class meetings. This proved to be a serious blow to productivity. In the face of nature’s obstacles, however, my group did manage to get more done than we would have anticipated had we known how little we would have been able to collaborate.

This sprint, we solidified much more of our understanding of PouchDB and the structure of our service. Due to the weather, much of our progress was done separately except for during a single impromptu meeting on Discord, so a gap in our respective grasps of the service has begun to form. However, in some capacity, each of us managed to learn and share with each other something new about PouchDB. As for me, I was concerned with the code itself. Much of my time in the first few days of the sprint was spent tinkering with the exercises we had completed during the previous sprint, in an effort to attain more than a working knowledge of PouchDB’s functionality. To this end, I redid the exercises from memory as best I could, but also framed the app in the context of Ampath’s patient data. The result was a rudimentary form of what the final service may look like – albeit without encryption, decryption, login, etc.

Of course, catastrophe managed to strike. As it happens, there are two versions of PouchDB: a JavaScript version, and a TypeScript version. We had been writing our code in the former, and wished to switch to the latter. In terms of syntax for the programs we’d written, this wasn’t all that major of a change, as we only really needed to change the import statement at the top of the file. Installation, however, was another issue. I spent hours with Fuve and Caleb one day, fighting with install errors that would pop up for one of us but not the other, until eventually Fuverion made some breakthrough that fixed everything. Admittedly, I still have no idea what he did, I’m just thankful that he did it.

Due to the inconsistent meeting times, coupled with the headaches brought about by switching to the TypeScript version of PouchDB, this was about as much as we were able to get done in this sprint. We have in fact discussed this already in an in-class retrospective, and have all agreed to make better use of our channels of communication: Slack, Discord, and a group text message thread between the five of us. In doing so, we hope that future unforeseen bouts of meteorological calamity will have far less power over our capacity for progress.

In this sprint, a very critical lesson was taught (or, perhaps a better word may be “reinforced”) to all of us: Do not assume that anything will go as planned. Do not assume that anything will be smooth, or easy. Because in the event that some blizzard comes along to remove two consecutive meeting periods, it’s far better to have modes of communication available for use and at the ready. In future sprints, I will work to ensure that my communication with my team is upheld in the times where I am, or any of them is, unable to be present.

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 3

This week’s Sprint retrospective we decided to look up different types of encryption services. Everyone had an encryption service that they were to look up and then write a shorts program see how it works. We decided out of all the encryption service out there we wanted to look at crypto-JS, Forge, web crypto, pouchdb, and bcryptjs. The one I researched was forged encryption service. It did do what we wanted however we decided not to use it because it has not been updated in 4 years so since we are working with sensitive data and did not want it to be leaked forge was out of the picture. Pouchdb was another one that we ruled out because this encryption service was made by someone that did it during their free time so it wasn’t updated regularly. The encryption service that we did decide to use was crypto Js because it was the simplest encryption service that we could have used and is not too old and the last update was not that long ago.

Finally, we decide what kind of encryption service we wanted to use. We started to talk about how we encrypt the data that is given to us. Oran gave an idea that we would encrypt the data as it comes our way so it would act like a blanket. Whenever some data such as a string, array, and any other sensitive information would come through the encryption service. It would take that data and encrypt it. However Oren had a colleague that was familiar with encryption services and he told him that data like that should be encrypted already. So that brought up a good point we want to ask Ampath if they have the data already encrypted or is this encryption service itself supposed to encrypt the data that they have. So for now moving forward we decided that we’re going to act like they need the data to be encrypted. We also need to start working with the other teams to know what data that is going to be given us to us and if cryptojs would be able to work with what they are planning.

So for the next week I will be studying up more on crypto Js and then trying to help the team write a basic program that can take inputs and give outputs of strings, letters, and words. I learned a lot about encryption during the week that we were encryption service in the beginning I did not know how the encryption service works such as what was salt and encrypt a string how would it remember what encryption that use to the string and if you were to send it to another device to be encrypted with that device need that same type of program to unencrypted password

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 3

During sprint 3, I worked more with encryption services and Webstorm trying to create a working an Angular app that encrypts and decrypts data using Webcrypto API. I have been researching the Webcrypto API for some time as it is completely new to me, including Javascript. I learned that there are not many Angular related examples of the Webcrypto API but I did find an example using Crypto JS that I am also interested in and I believe it will help me understand cryptography and how its implemented in Angular.  This resource had a lot of good information including why Webcrypto API is a good choice.

  • WebCrypto offers protection against overwriting (in Chrome), since window.crypto.subtle is read-only. This is good news for security but bad news for usability, because it makes it harder to work with polyfills.
  • Non-extractable keys make it very hard for attackers to steal your keys. Therefore, the “JavaScript is always insecure” issue is mostly resolved. You can create a key, store it at the client, and use it. But if you don’t specify it, you can never read the key, which means that attackers cannot do so. Tip: Use IndexedDB to store the keys.
  • WebCrypto uses SSL only (with the exception of localhost and extensions) which ensures that the data sent between the web server and the browser is encrypted and secure.

I think the team worked well on the day we were together in class. We missed class because of the weather and that was unfortunate because I feel more accomplished when I get to work with my team face to face. I am working hard learning about encryption, how it works, and what the current standard for secure web encryption is so we have a good path to start after getting the o.k. from the AMPATH team on a direction to go. I believe we are all learning something new about web cryptography, as we are all focusing on different javascript libraries. I plan to bring what I learn from the Webcrypto API to the team and allow us to make an informed decision on what encryption library we should choose.

During spring 3, I spend most of my time researching Web Cryptography API, including webcrypto-examples on GitHub. I’ve been using what I learn from the documentation and examples to get a working implementation on an app of my own to help the team move forward in creation of an offline module. I started focusing on the Webcrypto API because it seemed like a good starting point as it’s a popular javascript library that outperforms others significantly. The algorithm I am focusing on is AES-GCM, “the symmetric block cipher ratified as a standard by National Institute of Standards and Technology of the United States (NIST)” During the latest sprint meeting the team, we decided to keep working on our respective projects implementing an encryption service, once we meet after spring break we will began to make a game plan as to what to pitch to the AMPATH team.

The post Sprint Retrospective 3 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 3 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.

CS@Worcester – Fun in Function 2018-03-16 21:38:34

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:

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.

Sprint 3 Retrospective – Implementing Offline Storage

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: 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.

Sprint 3 Retrospective – Offline Services: Development Stage

We started off this sprint with two primary objectives in mind. Soon I will discuss a bit about our sub-tasks to complement these objectives; i.e. Collaboration, research, complete tutorials, research some more, rinse and repeat…

But first, I want to elaborate on our primary objectives:
1.  Refactor online-tracker-component.ts to include a service.
Begin the implementation of an offline capture data service.

Our first goal, refactoring the online tracker component, proved to be a lot more simplistic than the second. For the most part, it only took moving around code from one file to another. The end result is the online-tracker-component now calls functions from the new online-tracker-service to determine whether there is an internet connection. Though a simple refactoring modification, this change should be beneficial to all teams in the near future. We can now use our new online tracker service to call functions to check for connectivity status. Since all teams are working towards an offline module for AMRS, we feel this is essential for any of us to go forward.

The good news is the AMPATH development team will likely accept the pull request for our online-tracker modification once we make the tests pass. I should get this done by the end of this weekend, if not later today. In the meantime, if anyone wants to checkout our refactored online tracker implementation, the commit is available on my forked repository here.

Implementing an offline data capture service ultimately proved to be our greatest endeavor. We chose to approach this situation by first evaluating various techniques to achieve an offline capturing ability. PouchDB appeared to be the most promising tool from the start. Our reasoning was that other teams seem to anticipate using PouchDB themselves. We thought it would be best to do the same, so our future implementations would be compatible with other teams.

I initially hit a roadblock understanding the functionality of PouchDB. It appeared that PouchDB tutorials specifically aimed at Angular implementation were either scarce or low quality. Not only that, the AMPATH app seemed to fail every time we would try to import PouchDB directly into it. But other teams report to have had success using PouchDB’s TypeScript installation instructions. I will attempt this installation within the next couple of days, and will ask for feedback if I have any problems.

Fortunately through collaboration, my teammates and others were able to bring me up to speed. Originally I tried to follow the Getting Started guide on PouchDB, but the tutorial seemed not to be geared towards Angular implementation at all. But the Guides page is actually very helpful. The API page is also a great resource for an overview of PouchDB capabilities and syntax.

I had a chance to go through all the mini-chapters last night; PouchDB is making a lot more sense to me now. I will attempt to implement synchronization measures between PouchDB and AMPATH’s OpenMRS data during Spring Break.

It is worth noting that we began to look for alternatives to PouchDB. I actually found an informative tutorial regarding LocalStorage. This seems to be a JavaScript functionality that allows storage of data directly into the user’s browser. With the help of a tutorial geared towards the subject, I put together a simple Angular application implementing the LocalStorage functionality:


It’s a simple little ‘breakable toy’ I’ve conjured up with the help of following the aforementioned tutorial. I put it up on GitHub if anyone is interested in looking at it. Ultimately, it looks like we’re going to move forward with PouchDB rather than using LocalStorage. PouchDB just seems like the logical choice; it appears very powerful, flexible and stable, especially in comparison to other alternatives such as LocalStorage. But it was fun experimenting with the functionality. And honestly, exploring all these various Angular capabilities is making me a lot more comfortable working with the framework. It seems like everything I’ve researched thus far regarding Angular has helped me understand the AMPATH application more, either indirectly or directly. So even though we likely won’t be moving forward with LocalStorage implementation, it’s great to know the functionality is there if we never need it in the future! Knowledge is power.

Overall, this sprint was quite eventful. Our collaboration as a team went well; communication is probably the best it’s ever been. We also had some cross-team communication, and all teams seem to be making great progress in enabling offline capabilities for the AMPATH application.

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

Sprint 3 Retrospective

I feel that this sprint was good from the aspect that during the planning phase we seemed to come together more, and everyone added more input into tasks to break the items on the product backlog into and which ones we felt that we could accomplish during this sprint.  I feel that we are starting to hit our stride and be more comfortable as a team voicing opinions and ideas to each other.  Even though we are approaching the halfway mark in the semester without making too many contributions to the project.  From this last sprint into this upcoming sprint, each member of the team is making a bare-bones application with each one using a different encryption method.  When we meet again we will all have a better understanding of how encryption is applied in Angular and we can effectively suggest an encryption method to the Ampath team.   After that, I feel like we will have better direction and a better sense of purpose as a team since we will be working on services that can be applied to the project and feel more like we are contributing.

While our communication improved during the work classes we still have a lot of work to do communicating outside of class.  Some of our work classes were canceled due to snow and I believe that negatively impacted our team more than it should have.  Someone mentioned during the sprint review that the sprint would have gone better if we had been able to have more work classes.  While I don’t disagree with that statement it did make me think; did we utilize our time and communication ability between classes as much as possible?  I cannot honestly say that we did or feel like we accomplished all that we could in the time allotted.

I was assigned to create an application using crypto-js.  My first step was to do research, this included three different areas to focus on.  The first was encryption in general to get more familiarity with it, the second was how encryption was implemented in Angular, and the third part was to research crypto-js and how it was specifically implemented.  I found several examples of how to insert the encryption code into a program as well as one to create an Angular app to encrypt a file.  I lost the link to the site and am on the hunt to find it again, I was lucky enough to have downloaded the sample code already.

I hope that after spring break we can accomplish more as a team during our sprints and feel that we will after hitting these setbacks and discussing our team shortcomings at the sprint retrospectives we will keep improving every time.  After this upcoming sprint, we will be able to choose an encryption method with reasons why to back it up when we present it to Ampath.  Then I truly believe that we will have a renewed sense of purpose that will give the team the drive we need to meet our project goals by the end of the semester.

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

Sprint 3 Retrospective

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 Retrospective

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.