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.

The Abstract Class – Sprint Retrospective #4

What did I learn this sprint?

With each passing sprint, our team is able to find better and easier methods to communicate and accomplish our tasks. Each of us has our specific responsibilities and we each make sure that our tasks are done. We also made great strides sharing our repositories using gitlab. We each were able to pull the latest AMPATH builds as well as having a teammates merge request accepted by the application owners.

Refactoring the Online Tracker

Our team was tasked with separating the online status marker with the logic that determines whether or not there is an active internet connection. We were to refactor the existing code to provide a clear distinction between the display and controller. Once completed, we packaged up the change into the proper merger request and sent it to AMPATH.

After some minor adjustments to make the request pass the tests, our update was accepted and our teammate, Jason Knowles, now has a contribution credit to the AMPATH application.

Dealing with Pouch DB

Installing and configuring Pouch DB proved to be a particularly difficult task. Our team discovered that some of the customizations made by the AMPATH team add a layer of difficulty to installing other third party modules.

After some setup, we were able to get Pouch DB up and running within the AMPATH application. We also provided a node with which to interact with the database instance. We could also create temporary records that existed in memory. When we tried to write these records to a permanent file, we ran into problems. There was errors regarding the CORS pattern that we had to use to connect to the AMPATH test server.

Having discovered that the CORS module could be disabled once a connection was made to the test server. Once we disabled this, the records that were giving us trouble we successfully creating permanent records.

From here, we decided to reach out to the AMPATH development team next sprint and show them some workflows to be created next sprint.

What did I do this sprint?

I completed tutorials for both Pouch DB and Encrypt JS for use with the upcoming sprint. We need to establish a strong understanding of how the modules work and the development tools they provide us.

I offered answers to some important questions my team had about the appropriate usage of subscribers, observables, and promised. We had extensive conversations about callback functions and the concept of a function as a primitive data type.

Each of these concepts requires a little bit different way of applying things we have already been taught. I provided insight and answers into their application in the context of Pouch DB specifically and asynchronous requests.

What Can We Do Better?

The next sprint,  we will be focusing on furthering our momentum as we learn more about the intricacies contained within these modules. We must learn to better communicate among the groups within the class. We have gotten better as not overlapping work but there is plenty of room for improvement.

We can also leverage the tools given to us in a more productive manner. Trello, for example, has not proven to be the useful device that it has first seem to be. We should also be using the other items as well.

CS-448
CS@Worcester
Sprint-4

From the blog Rick W Phillips - CS@Worcester by rickwphillips 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.

Sprint 4 Retrospective

This week I got as far as I could with my spike solution before my group reconvened and chose an encryption library to use going forward.  I was finally able to work with PouchDB (creating a database, storing and retrieving data) successfully.  Unfortunately, I wasn’t able to use crypto-pouch to do what we needed to.  It purports to extend PouchDB features, but even when installed and included in dependencies did not actuall appear to add the proper functionality.  Additionally, it does not provide the kind of granular, on-demand encryption that we think will best suit this project’s needs.

Most of what I learned from my spike solution over the last two sprints is that working with multiple packages from different sources can be a challenge.  Also, I had to do some translating between javascript examples and the typescript that I was writing in.  I had to remove and reinstall modules at times, and I also learned that I really should have kept careful track of how I did what I did and in what order, so that if I broke it later I could reinstall more easily.

My group started this sprint with more independent work.  We all had some degree of success with our chosen encryption libraries.  It turns out that, of the libraries we looked at, only bcrypt was suitable.  It has the features we need (password salting and hashing plus on-demand object encryption), and is easy to install and use.  After the group made that determination mid-sprint, we reallocated work.  One person started to figure out how to implement the features we need with bcrypt.  The rest of us started to work out how to test our functions in Angular.  We also created a prototype data flow through our service on Balsamiq.

I think as a group we learned more about how to evaluate external libraries for our needs.  While I think that the way we used this sprint was worth our time both from individual and group learning standpoints, we probably could have saved some time if we’d known going in what to look for in encryption libraries, or written a specification of some kind that we could then look to fill.  We ended up with the following requirements, built from Ampath’s specifications:

  • Need to be able to salt, hash, and store passwords and then compare an entered password to the hash.
  • Need to be able to encrypt arbitrary data objects and decrypt them later.
  • Need to be able to encrypt/decrypt pieces of data on demand, and in a granular way.  This potentially allows more than one user to have data saved on the device, accessible with different keys.

Going forward, I think our biggest challenges will be to make sure each team member is assigned an appropriate amount of work.  I think one or two people may be able to work on the module directly, one or two people can mock a module and write tests, but that still leaves at least one person without a clear task.

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

Sprint 4 Retrospective

This sprint was a little different than the others because the week of spring break was in the middle of our sprint.  I think for most of the team, and certainly know that this applies to myself, that the week of spring break threw off my rhythm of work.  I had plans for things to accomplish, but other things kept coming up to include taking a break from all school work and reset. Although we were able to accomplish several of our goals and move forward as a team.  We worked on different basic programs that used encryption in order to try and find which library would work best for this project. In the end, we chose the crypto-js library. Crypto-js is flexible enough that it can effectively encrypt a string to allow us to accomplish our goal of encrypting passwords.  It will also allow us to encrypt objects so that will make it easier to encrypt information inputted by the users. From what we can tell so far this will cover all of the encryption needs that were laid out in the user stories at the beginning of the semester.

We also talked and realized that we may not be moving at the best pace and are not where we are all happy to be for the project at this point in the semester.  It’s important that we realize that we can’t go back and change what has happened earlier in the semester. All we can do is realize what we may have done wrong and fix those issues moving forward to the rest of the semester.  We discussed it a little during our retrospective and will talk about it more when we plan our next sprint. We will keep the lessons that we learned both good and bad while moving forward and accomplishing as much as we can for the end of the semester.

As a positive, we realized a good formula for our team in regards to breaking up the larger tasks into smaller more manageable individualistic tasks for team members to accomplish.  I feel that we have developed a good level of communication throughout our team. In my opinion, I believe that it took us a little longer than we all would have liked to get to this level of comfort and ease of sharing ideas that we may be a little nervous of that is not one hundred percent correct and the best solution.  We have developed a more open communication and I have noticed that we are starting to share more ideas and that will help us for the next couple of sprints to effectively produce a product that can help the Ampath project improve.

One obstacle that we need to realize that we need to get over is that while we may have to write a basic encryption service we will also have to develop more communication will all of the other teams and work together to write the code that will go into each of their services that the other teams are developing.  If we don’t do this then all of the teams run the risk of the services not syncing up on the encryption level or the teams trying to use different encryption libraries because we did not proactively work with the rest of the class to prevent that issue from occurring.

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 4 Retrospective

It seems that as each sprint goes by, we tend to achieve a substantial amount more than the preceding one. This sprint is no exception. I feel it has a lot to do with us becoming more familiar with the project, as well as the Angular framework.

Our main objectives for Sprint 4 were the following:

1.  Finish refactoring online-tracker to include a service.
2.  Successfully install PouchDB within the AMPATH app.
3.  Research and attempt using the PouchDB API to:
        (a)  perform REST calls.
        (b)  deal with synchronization.
        (c)  encrypt the data within the database.

Refactoring online-tracker to include a service:
We were able to accomplish this. I should point out that the refactoring of online-tracker was a bit more complicated than we anticipated. Initially we thought that just moving around some code would do the trick. But once we attempted to test the code, we realized we had a series of issues that needed addressing. For example, our original service essentially wasn’t returning anything, making it extremely difficult to test. Further, there were some issues with the Observable.timer() that periodically checks for connectivity. Since it wasn’t being properly closed, it was causing potential resource leaks that seemed to slow down the whole app. Felix from the AMPATH team helped us resolve these issues. The end result is that our pull request was accepted, and is officially part of the ng2-amrs repository. I tried to document the whole process the best I could to help others in the future. If you want to check it out, the PDF is located here.

Successfully install PouchDB within the AMPATH app:
We did not expect this to give us so much trouble, but ultimately we were sucessful. We were able to install PouchDB dependancies inside a new standalone Angular app, but every time we would try to install it within our clones of ng2-amrs, the app would no longer compile. With the help of another team working on offline storage, we were able to get it working. Here’s how our team was able to do it:

   1. Clone a clean copy of ng2-amrs, i.e.:  git clone https://github.com//ng2-amrs ng2-amrs-pouchdb
   2. Open ng2-amrs-pouchdb in WebStorm and press ALT-F12 (or Fn-ALT-F12) to start a terminal.
   3. Delete package-lock.json from the Project menu in WebStorm (make sure safe delete is checked)
   4. npm install pouchdb @types/pouchdb
   5. If package-lock.json is recreated, delete it again by following step 3.
   6. npm install webpack webpack-dev-server karma-cli protractor typescript release-it rimraf -g
   7. If package-lock.json is recreated, delete it again by following step 3.
   8. npm install

Research and attempt using the PouchDB API:
I believe our whole team was able to read most (if not all) the chapters in the official PouchDB guide. We were able to make some progress regarding actual implementation within the AMPATH app. For instance, we were able to configure a router for an offline-storage component, and we can now link to it directly within ng2-amrs. Further, we performed some REST calls using the PouchDB API.

Going forward into the next sprint, I think we need to focus on subscribing to data using observables, and then storing that data offline. This will require further experimentation with the PouchDB API. During the next several days, we will look into encryption at a high level, but will focus primarily on data capturing using PouchDB.

Synchronization between an offline database and the AMPATH server is our ultimate goal for this project. Based on our research so far, this task in particular seems pretty advanced. We are likely going to need assistance from the AMPATH team. I have been communicating with Felix regarding these issues.

Overall, I think we worked well as a team, and as a class in general. Everyone seems genuinely interested in completing the tasks we’ve set for ourselves. Communication has been strong for the most part; we always seem to know what each of us is working on.

 

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

Post #26 – Ampath Application Development – Sprint 4 Retrospective

Last sprint, we were tasked with creating test-applications that utilized a few different encryption libaries, so we could get an idea which library would be the best to use for the implementation of offline-encryption.  We didn’t really finish doing that by the time this sprint began, so we decided to keep some of those tasks on the sprint backlog to continue working on them this sprint.  I spent the first half of this sprint researching and implementing encryption using the bcryptjs encryption library.  This sprint was divided by spring break, during which I mostly took a break from school work.  I did, however, do some refreshing of programming in JavaScript.  This refresher made me feel much more comfortable coming back from spring break.  I expressed my confidence in bcryptjs to my teammates, and presented them with a mock encryption service that I wrote.

The test-application that I made demonstrated bcryptjs’s usefullness in encrypting passwords, but my teammates were curious how the library would handle encrypting other kinds of data that we may experience within the Ampath application.  We came to the realization that bcryptjs is useful and easy-to-use for password encryption, but lacks functionality for encrypting other kinds of data.  We decided that this would be problematic, effectively eliminating it from our choices.  We communicated well and discussed our remaining options with a sense of direction we hadn’t had in the previous sprints.  After further research, we came to the agreement that we would run with the encryption library crypto-js. We began looking at resources for crypto-js and wanted to begin testing some implementation.  We also discussed potential strategies for dividing the work that we must do among our team members.  We do not have a solid plan in place right now, because we were unsure if it would even be necessary to divid the task among all member of the team.  During our next sprint-planning meeting, we intend to talk more about the division of labor and how we intend to move forward with implementation and avoiding compilation issues.  Unfortunately, when me, Erik, and Oren tried to run our application on the last day of the sprint, we all had the same compilation errors, despite having not changed any code since the week we worked on it.  We spent the remaining day of the sprint troubleshooting this issue, to no avail.  Shane and Caleb, members of the ‘Everyone Else’ team, recommended that we try running the command ‘npm rebuild’ in the WebStorm terminal, which is what he and his team members did when they encountered this issue.  I have not tried this solution out yet, but I intend to in the next sprint.

I feel that we made some real progress this week.  We were able to successfully agree upon the best-fit library for our task, and we began troubleshooting errors so that we can get back on track to implementing offline-encryption.  I feel much more comfortable with our strategy than I have been feeling in the previous weeks, and I feel very motivated moving forward.

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