Category Archives: Sprint 5

Sprint 5 Retrospective

This sprint felt much more productive than the previous sprints from my perspective.  I think that is mostly because we did more than research or creating test programs. This sprint we started writing services for the AMPATH project.  We created an encryption service, at this time it specifically focuses on hashing passwords. We also added a test for this method simultaneously, by the end of this sprint though we were unable to run the test successfully.  Moving forward that will have to be one of the focuses is to get this test working, I believe that it is necessary for us to get this test successful in order to use it as a template for creating our other tests. There are two pieces of wisdom that have stuck with me that I believe will really come in handy for this next sprint.  “Slow is smooth, smooth is fast” and “Those who fail to plan should plan to fail”.

If we rush into writing other tests without building a successful one I think that there is a very high chance that we will get in over our head with too many tests that will fail for various reasons and we will start to try and fix different issues at the same time and just creating more issues.  If we take our time and focus on fixing this test first then we will have a clear picture of what is needed to write successful tests. We need to slowly approach this to help the project from a larger perspective move smoothly and at a good pace.

Since we are quickly approaching the end of the semester and the end of the project, everyone participating in the next sprint planning meeting is crucial.  If we do not take the full opportunity to carefully plan out what we will each be doing over the next week and a half the risk of us falling incredibly far behind to not be able to produce any meaningful deliverable to the project and negatively affect the ability for the other teams to effectively move forward on their own projects.

The service we did write however is a good start, we created an encryption directory within src/app.  In this, we created a hashed password service that takes a string and hashes the string. In the spec service for the hashed password, we wrote a test to test if the hashed password does not equal the original string that was used as a test password.  The test originally failed and produced the error that “Cannot find type definition file for ‘source map’.” After doing some research I thought I found a solution for manually adding “@types/source-map” to the package.json folder. After adding this and running ‘npm install sourcemap@latest –save’ the new error that was given was that there were now conflicting definitions for source map.  The solution on stack overflow that I found called for doing both, but I will now try removing the line from the package.json folder and see if that produces any significant changes. Depending on what that produces will determine the direction that we move in from there.

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

CS@Worcester – Fun in Function 2018-04-19 23:37:14

This sprint was productive despite lots of small impediments along the way. My main task was to implement the front end of the checkbox we’ll be using to decide whether a user’s credentials will be stored when they log in. I managed to complete this and submit a pull request which got merged by Wednesday.

Problems building the app stopped me from making much progress in the beginning. At first it would just take a very long time, but after pulling changes, the user settings page I was meant to be modifying wouldn’t show up. I had initially placed the checkbox on the login page, which had been easier and made more sense to me, so I asked AMPATH to deviate from our mockup by switching the location of the checkbox to there and they agreed this seemed like the more intuitive choice. Getting a checkbox in the right place was easy once the app would load. The slightly more complicated part was getting the checkbox to appear only if there was an internet connection, since the option to store credentials shouldn’t be available in the offline state. I used an ngIf directive connected to a boolean value, and had the boolean update based on whether the app was online according to the online tracker service. However, the boolean appeared to be updated after the page’s HTML had already loaded, meaning the boolean was always read as its default false value. The checkbox therefore never appeared and the page didn’t update when the boolean changed. I wasn’t sure how to proceed at first, but I ended up deciding that the code controlling the online tracker dot was close enough to what I needed that I could use similar code to control the checkbox. This worked well enough, though the checkbox will simply disappear from the page if internet connection is lost in its current implementation.

Our team also restructured how we wanted to manage the branches on our repository from now on this sprint. The master branch is now a direct copy of AMPATH’s code. The branch which incorporates all our team’s edits is the offline-login branch. When we want to edit the code in the future, we’ll make our own branch for the change, push, then make a pull request to merge the branch into the offline-login branch. I’d made some edits on the offline-login branch by the time I wanted to push my changes, so I made my own branch and used git reset –hard to change the offline-login branch back to the way it had been in compliance with these new guidelines.

The teamwork keeps getting better in every regard, as with this new policy which will improve our organization and with communication. Team members answer requests for help or feedback quickly, getting back to each other within the day and sometimes within minutes.

Going forward, I want to complete the backend of the checkbox, ensuring that a user’s credentials are stored when it’s checked and that they aren’t when it’s unchecked. Both Luigi and I are assigned to this task. We also want to create documentation of our current offline-login implementation to help the AMPATH team and whoever works on our code next to understand what we’ve done so far. I have hope that we can get a decently functional implementation of the offline login done by the time the course ends.

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 5 Retro

This week marked the end of sprint 5, and so far this one was by far one of the most informative sprints for me as well as the most productive. This week I got the opportunity to dig much deeper into typescript because I needed to implement some back-end code. I got a chance to actually implement some of the basics that I had been reading up on, such as declaring new variables and making variables visible from one class to another. I know these are some very basic things, but this was an important thing to do because it is fundamental to every programming language and having this foundation will help me build and implement more advanced functionality that we will soon need. I also learned that Ampath has some very strict code style settings. I had the build complain because I declared a public variable after a private one, and also because I had left an extra new line between two of my methods. I of course realized this after I had already pushed my changes up to later receive a message telling me that I had broken the team build. Had I known in advance that these rules were so strict, I would have checked the state of the build before pushing up my changes because even though this did not hold our team back long, this is something that could’ve wasted tons of time and should be avoided in the future.

The team worked very well together during this sprint, I would go as far as to say that this was the best sprint that we’ve had teamwork wise. I was having a few build issues and my team members quickly helped me resolve them so I could get back to work. The later on another teammate was having an issues that I previously had, they asked for help and I was able to quickly get them back on track. Even the way that we split our tasks was efficient, we had individual tasks that we would later link together. We would definitely like to keep this very high level of teamwork going forward and improve on it if at all possible.

During this week, the main focus was to get a checkbox or switch that could be toggled to decide if the user would like to save their credentials for later storage and let that determine what happens going forward. We were able to get that done, I was in charge of writing the back-end code (which was fairly simple) and Dominique was in charge of the UI aspect. That however was not the only work that was completed this sprint. There were improvements made to the offline detection that our code used. Previously we would know that we were offline because of a failed API call and our logic would run from there, now we use the service that was written by another group. We have also run some of our proposed changes by Ampath to ask for their approval.

This sprint, we have accomplished a whole lot and the coming sprint we plan on tidying up most of what we did. I believe that after the coming sprint, we will essentially have a nearly have the offline functionality exactly how we want it and we can shift gears and focus on other things like encryption, but in the meanwhile we will continue building on the progress we’ve had.

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 #5 Retrospective

During this sprint in my software development capstone class, my team and I tried to make some progress on establishing our offline data capture service. Before creating our tasks, we organized our team’s trello board to be a bit better. We changed the layout of our board by creating different columns that were categorized by our names to indicate who was in charge of doing a specific task that was assigned to them. We did this because it could make us as team to better understand who was doing what, and what was currently worked on in this sprint.

The team and I attempted to find out more ideas from the people at AMPATH through the communication with Jonathan Dick. We felt that we needed to get some ideas to further progress at our offline data capture or else we wouldn’t know what to do during this sprint. One question that I had asked to JD pertained to a GUI, which he wanted that indicates and separates offline data from the online data through our service. We are still currently figuring out on how to create the GUI. Other tasks that we attempted were:

  • If dealing with CORS issues, create a desktop shortcut loading an instance of Chrome disabling web security.
  • Create balsamiq diagrams outlining current and anticipated implementations of offline-capturing the OpenMRS / ETL data.
  • Write tests for our implementations.
  • Design the HTML part of an offline component that will be used for our GUI. Should be similar to the layout of the AMPATH Patient Search Component.
  • Collaborate with the encryption team regarding the process of how our captured data ought to be encrypted.
  • Touch base with all teams (encryption, offline-storage, and login) regarding their overall progress.
  • Create a mock diagram in Balsamiq illustrating an idea of a GUI that presents the captured data in a meaningful way.
  • Develop mock diagram in Balsamiq where a “Doctor/Provider” can pick and choose what patients to sync.

All of these tasks are still ongoing, leading into the next sprint. I felt that we were unable to complete any of these tasks within this sprint because we spent most of the time asking questions. I would admit that there were times where we were lost because we weren’t  communicating enough to JD. However, one task that we got done was:

  • Get ALL patients in the database (not just those with “test” in the name). Store each patient results into an array, then iterate through it to store each into separate files in PouchDB.

What we learned from attempting these tasks was that it taught us to constantly communicate with AMPATH to develop a smooth transition from task to task so we don’t get stuck and waste time on what to do next.  Communicating with AMPATH and asking questions to them will help us develop ideas on how to proceed with a task to validate what we are doing is what the people at AMPATH and JD wants. This was the main thing we learned from our mistake. This can be applied in other situations because in the software development career, communication is one of the most important things to do for this particular reason. If there is not constant communication, whether it be to your teammates or anyone in the workplace, work can become difficult and you can become unaware of what to do, which can further delay the project or task from getting done.

The effort that my team put into this sprint was sufficient despite the incomplete tasks. Everyone still tried to attempt at something even though we were still stuck on how JD and the people at AMPATH wanted our Offline Data Capture service to look like. For this sprint as an individual I mainly tried to still gather ideas and find a suitable encryption implementation for the AMPATH code and I think that using crypto.js wouldn’t work efficiently, so I decided to keep on researching. I also talked to the encryption team and found out that they ran into some impediments as well on developing their encryption service. Moving forward, my team and I need to communicate more effectively with the other teams as well as with JD and AMPATH. Doing this will help us work better.

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.

Sprint 5 Retrospective

This Sprint led to a frustrating conclusion. Our group essentially completed the offline storage service, which incidentally does much more than just store data, but came upon some sudden issues.

Because the service itself can also store, retrieve, delete, and update data while offline to an offline PouchDB database, that actually just uses IndexedDB on chrome, I floated the idea of renaming it to an offline database service instead. The idea was accepted, but currently renaming is an easy step that can be implemented after we get it working.

The main issue that has appeared is a confusing and somewhat baffling error that suddenly appeared. My team mate, Connor, had made a number of new tests for our service that were much more comprehensive than our previous simple ones. Using the tests we could see if the service worked, not just by the test results but by looking at the database itself in chromes dev tools to see the documents stored when the tests ran. The put and get commands added documents to our PouchDB database and would retrieve a JSON object from the database. However, starting this week, it simply stopped working.

I am still testing our service in isolation from the larger project, while using the same tslint.json to keep the format required the same, to avoid needless complications. Last week, running ng test to run the tests for our service through karma could no longer successfully launch. It would fail to open the browser consistently. Looking up the issue, I decided to reinstall the node modules director of my project. This ended up working, but ever since then, the methods in our service stopped succeeding.

The most baffling part is that there seems to be no feedback or explicit error at all. The commands to put and get documents and such are promises with a catch statement, so any errors should be caught and then logged. No errors are logged and yet the commands themselves also do not succeed. By viewing the database itself, it became apparent that no documents were being put into the database at all. Adding several console log statements throughout the methods to see which parts of it were executing showed that the entire put or get promise is being seemingly ignored. The promise has 3 different outcomes, it being resolves, being rejected, or an error happening. None of the options execute, which was very confusing.

This is still an ongoing issue with our service that once we fix should mean we are done. Frustratingly, this issue has shown up in my team mates projects as well, which means there must be something that happened that made it seem as if it was executing flawlessly earlier or we missed something. More research is required to fix this, it is a road block currently. I also discovered the command used for the ng2-amrs project is ‘npm run test’ instead of using angular cli’s test command ‘ng test’. This seems annoying as difference is that ‘npm run test’ seemingly has to be used every time tests need to be run, while ‘ng test’ can be used once and the tests will reload and be rerun whenever a code change happens.

I also did some more research into promises in pursuit of a fix to the issue in our project. I now understand the format of the then method much more comprehensively. And researching the PouchDB Api some more, I suggested some changes to the tests to make them much better at testing if the methods worked.

As long as we can fix our major issue right now, we can essentially finish our offline database and use is to complete the offline storage task of the project. Also, in my opinion, will somewhat easily allow us or another team to complete the offline form storage task.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

Sprint 5 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 5 Retrospective – Testing Our PouchDB Service

Unfortunately my team and I were unable to meet the goals we set for ourselves at the beginning of this sprint cycle. The biggest issue we’ve been facing is writing tests for our offline storage service which implements pouchDB. In researching how to write meaningful  unit tests in Angular for services that implement pouchDB, we have found few helpful resources. The pouchDB API, which can be found here, provides little documentation on this subject so we have been forced to refer to git-issue pages and various tutorials. The issue with these resources is they tend to be somewhat outdated and don’t exactly match our particular use case.

My team and I have referred to the pouchDB API when it came to writing methods for our offline storage service. Our methods are pretty straight forward as they implement standard pouchDB functions such as get(), put(), and remove()  for getting, adding, altering, and deleting data from the offline storage database. So, for the most part, we believe our methods are correct and function as intended. However, in order to be sure our methods are functioning correctly, we need to write meaningful unit tests in Angular. The first test we wrote just checks to make sure the pouchDB in-browser database is successfully created. This test passed and when we looked at the web page Karma opens when the tests run we can open up the developer tools and see that our database is in fact created. This is depicted in the screen shot below:

Screenshot 2018-04-18 10.51.16

Although we can see that our pouchDB in-browser database is instantiated, we run into a mess of problems when trying to call pouchDB functions. For instance, when trying to add elements into the database we use pouchDB’s “put()” function and pass in a string which then gets parsed as a JSON object. To test this method we created a mock patient object, in JSON format, at the beginning of our test class and tried confirming it was being successfully added by checking the Karma test page in the browser. I should mention that the process of debugging has been quite difficult when trying to figure out why tests aren’t passing because many of the error messages  generated after tests fail seem to lack essential descriptive information. I say this because we are rarely given specific line numbers from our service indicating where the errors occurred. Instead, we seem to get a bunch of references to files that we aren’t concerned about. I feel that this may be partially due to our lack of experience in writing unit tests in Angular.

I was actually able to make some progress today in testing the “addDoc()” method for our offline storage service. Previously, we had gotten the test to pass but I was left unconvinced that it was actually working as intended because I could not see any data being stored in the in-browser pouchDB database. After some trial and error I was able to get the method to work and physically see the data in our pouchDB database. Here is a screen shot depicting the data that was successfully added:

Screenshot from 2018-04-18 21-02-57

Now that I understand how to get mock data into our offline storage database, I will relay this information to my team and we should be able to make some real progress as this has been one of the main issues holding us up.

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.