Category Archives: Sprint 5

Sprint Retrospective – 18 April 2018

By stark contrast to all previous sprints, Sprint #5 was a violent roller coaster of efficacy. For the first half of the sprint, I continued in the role set for myself in the previous sprint: the guy who writes the tests. Up to this point, we had been using a simple set of tests for the purpose of making sure we knew how to write tests and get them to pass. Now, the focus had shifted to constructing good tests – with appropriate code coverage and level of complexity – to be able to test our code against the standard we were seeking to hold it to. This sprint definitely taught us a thing or two about consistently committing changes to our GitHub, as I believe that many of our issues we encountered over this sprint could have been resolved – or, at the very least, spotted – much more quickly had we been up to date with one another’s code more frequently than we were.

As mentioned before, there was real turbulence as far as the amount of work being done adequately throughout the sprint. About a week into this more strict test-writing process, one day in the middle of a class meeting, something very strange began to happen. It started as what we thought was some bizarre install issue: karma would no longer open the browser for testing when we tried to run ng test in the CLI. We decided after a bit of reading on the issue to try reinstalling our node modules – which technically solved the problem we were seeking to address, but came with an entirely new, arguably much worse problem. Now, the tests were inexplicably no longer working.

It doesn’t end there either; not only did our newer tests suddenly stop working, but when we tried reverting back to the old, successful tests to find the step that made things go wrong, we found yet another strange issue. Now, the tests were still passing, but when we looked into the IndexedDB in the browser, and the console, both were empty. I.e., no database had been created, no patient objects had been added to said nonexistent database, and not even the console logs we put in the middle of the code for debugging were being sent to the console. We would not resolve this perplexing set of issues until only a few days ago, when we came to the abrupt realization that we were trying to use synchronous methods to test and implement an asynchronous service (PouchDB).

As soon as we figured this out, we were actually able to get back on track fairly quickly. We learned how to use Promises in our tests so that the asynchronous values being returned by our services methods could be properly evaluated. Since Promise objects are the core component of the asynchronous behaviors of our service, we needed to understand fundamentally what sorts of information they provided us to work with. Prior to this, we were trying to extract boolean, string and integer values from our methods – which proved fruitless, due to the fact that these are synchronous values. Promise objects, it turns out, give us back a kind of message. They give back a JSON object, which contains information about its status, with the most relevant field to us being the “ok” field within it. The “ok” field is simply a boolean – which is exactly what we were after. So rather than something like:

 

          expect(service.addDoc(testDB, patient1)).toBe(true);

 

We needed to actually have:

 

          service.addDoc(testDB, patient1).then( (resultOfAdd) =>

                    expect(resultOfAdd.ok).toBe(true);

          });

 

Where “resultOfAdd” is the response object returned from the addDoc method’s Promise.

For as frustrating as much of this sprint turned out to be, it was also incredibly satisfying at the end of it all. It was very reassuring to see such a monumental problem have one issue resolved that made the entire mountain of trouble it created flatten. Going forward, I will be sure to keep in mind the conditions that lead to this set of difficulties – primarily lack of diligence on commits – and the steps that were most effective in figuring out the root of the problems.

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 5

This week’s Sprint retrospective we had some issues. So, there were still the issue of ng2-amrs not working for many of the people in group. However, thanks to Jason Knowles he figured out how to fix the issue of cryptojs not working on the Ampath’s website. So, we were able to try and write something for Ampath to be able to use or try to use. Our goal in the beginning of the sprint was to write all the methods for Ampath so that way they can have something they can use for the summer or give to summer interns or people who would be working on it later on. We decided to split up the work into different parts so that way we would be able to get more methods done for them. We decided to write methods depending on what the client told us in their stories. We then decided to make the method for hashing passwords, encrypting records, generating private keys, generating local salt, clear local salt, delete keys, and writing decrypt records. I started to work on deleting private key method however i wanted to work with Oren since he was generating the private key so this was one of the issues we ran into that because since we were working on a project that we just kind of picked up and we don’t know much about it there wasn’t a lot to work on for the project so when I talked to Oren to see if he could help me with the delete private key method but Oren was actually going to work on that as well. So instead we decided to work on that part together.

So, I started to do a little research about the cryptojs and how to make private keys we decide to write a private key using PBKDF2. PBKDF2 is a password strength algorithm that makes it difficult for computers to check that anyone password is correct Master passwords during a Brute Force attack so the way that PBKDF2 works is that it requires many computations to get from the master password to Turkey anyone that’s trying to brute-force try to automatically guess a master password has to perform the same calculations PBKDF2 with PBKDF2 it prevents password-cracking flows from making optimal use of the graphics card which reduce gas rates from hundreds of thousands of gas per seconds less than a few ten thousand guesses per second.

Finally looking back through throughout this project I’ve learned a lot about encryption services. Maybe not enough to be able to write my own encryption from scratch. But this experience was helpful for me and it will help me throughout my career. Between the two classes I was taking this semester and learning about Sprints and planning’s how to work with a group and team. It was different than all the other years that I have been in school. I didn’t learn a new language or more coding skills but I l was able to get a real-world experience. how time-consuming it was to even talk to the manager, how that we were a class who that was working on the same project but we are split into four groups and none of us really talk to each other about trying to put our code together and make it work with one another. Though maybe it was because no one was really experienced in this type situation or maybe the time constraint of working on this project and also having other class work and other personal stuff to do that’s it was a 10-week project if he really boils down to how much work was done it might have been a lot shorter so that’s why we weren’t able to finish I’m what we were assigned and trying to bring it together. so, the for the final Sprint we’re going to try to just finish up what we started and then start working on our presentation.

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