Looking Back on Sprint 5

Before heading into the last working sprint, I would like to reflect on how happy I am with the progress made by all members of the team during the fifth sprint. It would seem that my hope that getting a rudimentary implementation of the offline login pushed up to the team repository did generate some buzz and get other team members pushing code as well. I’m looking forward to seeing what we can accomplish in the final push.

One of the story items that I was assigned for this sprint was the “Take offline status checking outside of error checking” task. This was not too difficult to accomplish, but did require some investigation into how to make use of a service in TypeScript. While it seems like a relatively basic concept, it was the first time I had ever attempted to use a service. Following the examples set by the AuthenticationService and SessionService, I managed to piece together how services are imported, included as part of the constructor, and then used within the class.

While working on changing my rudimentary implementation of the offline login to use the OnlineTrackerService rather than the error checking logic of the LoginComponent, I discovered a bug. Because I needed the OnlineTrackerService working for my offline login implementation, I chose to investigate and attempt to fix this bug. The bug was not difficult to identify, and I fixed it relatively quickly. After attempting to build the project, however, one of the tests failed. I looked into the failing test, and found that the test was expecting the incorrect value for isUpdating when offline, causing the test to fail when the program was behaving properly. I corrected this test and submitted a pull request to AMPATH. The pull request can be seen here: https://github.com/AMPATH/ng2-amrs/pull/671. Just a few hours before writing this post, the pull request was approved and merged into AMPATH’s master. While this task was not originally assigned at the beginning of the sprint and was done out of necessity, I feel that it was important contribution. For this reason, I added it to the Trello board as a story item, and marked it as complete once the pull request was accepted.

Although I was a bit distracted during the middle of the sprint by the OnlineTracker bug, I got back down to business with our offline login implementation once the bugfix code was submitted to AMPATH. I noticed that the build had failed for the code that I pushed that took the offline status checking outside of error checking, and set out to investigate why. The description given by the testing framework was vague, but I eventually determined that the test was failing because of a missing import in the login.component.spec.ts class. Because I was implementing the OnlineTrackerService in login.component.ts, I also had to import the service in the test class. Once I added this import, the build passed.

The final task that I took on for the sprint was fixing our severely broken team git tree. Because we did not branch for development of the offline-login, our master branch became cluttered with many small, meaningless commits and merge commits. This became apparent when I attempted to submit a pull request to AMPATH for my bugfix. I worked with Matt in class to get all of the commits related to the offline-login in a new offline-login branch. He then developed guidelines for a git workflow for the team repository.

I’m very excited about what we’ve accomplished this sprint. It is rather unfortunate that just as we are getting up to speed and comfortable working with the ng2-amrs application, we are entering our final working sprint. I’m still hopeful that we will be able to make significant progress towards a working implementation in the last sprint.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Sprint 5 Retrospective

Sprint 5 was a continuation of sprint 4. Again, we started sprint 5 by reviewing what was done in the sprint 4, particularly our achievements and failures. As a matter of fact, we revisited pouchdb to make sure that we have it installed and running in everybody PC. This success in Sprint 4 has helped us very much in continuing to explore ways of capturing the offline data. In Sprint 5, there were no any interruptions and the team was able to do our regular team meetings without any interference. I will say Sprint 5nwas very effective in terms of meetings and discussions. We were able to hold effective discussions, coming up with some ideas and also explaining to each other what we meant by the ideas we came up with. I will personally give credit to Rick Phillips for offering those pieces of advice. His advice has been very informative and that has helped the team a lot in doing and understanding our work. Jason has also been doing well in integrating those ideas we came up with and the advice offered by Rick Phillips into code.

Again, for our offline data capture task, even though, the idea of using local storage system was established in the previous sprint, the team was still unsure of if the pouchdb I have been preaching on since day one will work for us. But now, I can authoritatively say that the team is confidence that we could capture the data remotely using pouchdb based on our further experiments. As usual, we continue to and will still do more research on pouchdb to gain insight of how we can possibly capture the data; we continued to dig deeper into pouchdb by learning more tutorials of how to synchronize data between two servers. One of the major problems we were facing in our data capturing task was getting the data. We could initially write a dummy data into the pouchdb but we wanted to capture the data from the AMPATH database. By Rick advice, we were able to search for data through the patient database of the AMPATH and store it into an array which we could iterate through to store each into separate files in pouchdb.

Besides, at this point, we look close to getting the task done but still face some problems. We are not completely sure of what need to be sync back. I personally suggested to the team that I think the ideal way is to synchronize just the differences. I will prefer we are able to add a function that checks for difference and synchronize that to the database than synchronizing the whole data captured remotely including the old that was retried while going offline. I also think it will not be useful for the doctor to have a whole bunch of data that he/she doesn’t need and I think we should be able to come up with away that the doctor could filter the data down to just what he/she need at the time when he/she is going offline. This also led us to haven to design a GUI for the doctor. With regard, I created an abstract ER Diagram with three entities; thus the Doctor, Appointment and Patient, showing how the relationships and cardinalities. Rick and I are now waiting to kickoff with design for the GUI when we are clear of the filed they want us to include.

In summary, I would say this Sprint has been very interesting due to the enthusiasm and passion that we put into work. I believed if the team keeps up with this enthusiasm, we would definitely get the work done. I also think the work sharing that has been listed on trello board will also help keeps everyone busy.

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

This sprint we finished our prototype API and had it approved by Ampath.  We also started working through the implementation details for our service as a group.  Finally, we figured out how to repair our local versions of the app and get our group repository in synch with Ampath’s master branch so that we can implement our API over the next sprint.  I learned how to coordinate with other teams to build an API, and how to implement password hashing and data encryption.

I think the biggest takeaway for me this sprint was how to coordinate with other teams on a project to write an API for them to use, and how to integrate details of their implementations into my team’s work.  Because we’re providing a “background” service for the other teams, they can work for now assuming that our service will do what it’s supposed to.  However, this means that we need to understand some details of their implementations so that we can provide them with what they need.  Given the speed with which the semester is coming to a close, the encryption service may not be integrated into other services or components this year.  However, we hope to have something that’s usable for Ampath or another group working on this project to take over in the future.

Our biggest job this sprint was to work on our service’s public API.  We did this primarily through team work periods in class.  This followed a roughly three-step process, which we repeated until we believed our API was in a state where we could send it to Ampath for approval.  First, we spoke with another team to get a handle on their requirements for our service.  Second, we wrote a set of function signatures that we believe filled those requirements.  Third, we discussed implementation of those functions and what other private functions we might need to implement them, as well as which parts of the Crypto-JS API we want to use.

One of the biggest parts of this discussion was to figure out how we want to derive private keys and store hashes in order to provide the best compromise between security and usability.  For password hashing, we decided to store a hash derived from the password with salt derived from the username and timestamp of the offline session creation.  This will be stored with the username in-browser, by the offline login team’s code.  For private key derivation and storage, we spoke with Ampath and agreed on temporary private key storage for the duration of a login session (the key will be generated from the password using a password-to-private-key function and stored in a file that is deleted on logout).  While not optimally secure, this allows encryption/decryption of data without requiring password entry for each data operation.

We followed Jason Knowles’ intructions to rebuild our apps, and used git to update our team repo with Ampath’s latest changes.  For next sprint, our job is to implement and test as much code as we can manage.

I think our team coordination could have been better this week.  It felt like a lot of what we were doing didn’t engage the entire team, although I’m not sure how to manage that better.  Not everyone was present for each work day for varying reasons, although we did keep in touch on Slack we could also probably have kept better notes to send to absent team members.  I think dividing up labor will be easier next sprint since we have actual code to work on.  We will have to make sure we keep our repositories synched, as we don’t have a ton of practice with that.

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

Sprint Retrospective 5

This sprint I learned a lot more about encryption services and typescript in general. Encryption using Javascript is not the best choice, especially in an open source project but I feel the solution we have will do the job and securely encrypt the data in the more secure way we can. I learned there are many solutions to our problem and a lot of solutions may be outdated or not maintained. We chose Crypto-JS to hash passwords and encrypt and decrypt data, it’s a popular Javascript crypto library and has an MIT license. The last update was a year ago but still feel this properly accomplishes what we want. I noticed there are a lot solutions for Javascript but not many are implemented in Typescript. I learned quite a bit about translating from Javascript to typescript and was able to implement a solution for an encryption function in a typescript service file. I learned more about testing in Angular 2 but still am having some trouble with tests. I will keep on focusing on writing good tests that comply with the Ampath standards. I enjoy getting to work on something that’s actually used by people, and will help people do their job. It’s nice to get experience working with a real web application that uses Javascript and APIs. I feel this will help me in my professional career, and will help the Ampath team improve their project.

I felt the team worked well during the sprint. We have all been having problems keeping the web application working and it seems to break even though the local files have not been touched. We all have the application working now and are on to writing the functions needed for the other teams to utilize. We have split up the tasks amongst ourselves and will hopefully have a working solution by the end of the the next sprint. I don’t see anything stopping up from completing the tasks, and we got the O.K. from Jonathan on the Ampath team on the encryption API interface. I am currently working on the encryptRecord function and am utilizing Crypto-JS for that. I have a function now that I think will do the job but still need to work on my angular 2 testing skills to make sure the function will work properly.

We began the sprint with the intention of creating an encryption service file that has the following functions: hashPassword, a function that hashes passwords with a salt when the user logs in. clearLocalSalt, a function that will clear the local salt generated at login, when the user logs out. encryptRecord, a function that takes data and a private key and encrypts the data for save local storage. decryptRecord, a function that takes the private key and encrypted data and decrypts it for when the user is connected to the internet. Now that we have a clear path and the O.K. from the ampath team, we can concentrate on our individual tasks and work the offline login team for assistance in generating a salt with a username and timestamp.

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

This sprint was not a complete success. We wanted to have some code pushed and maybe make a pull request to AMpath. However, our progress was delayed due to our inexperience in writing angular 2 methods and testing them effectively. I learned that testing code in a language you haven’t studied can be exceptionally difficult to grasp. I am still trying to work out the uses for toBe(), toThrowError(), toEqual(), and how the expect works in the test suite. Writing the method for the code seemed easy enough and I think I have the correct code, however it is hard to confirm when testing isn’t going smoothly. I understand that writing tests first would have been the correct way to do this, but I can’t write tests for code that I don’t know how to write. Therefore, I had to learn how the code worked and look at the API for pouchDB (which you can find here https://pouchdb.com/api.html) to ensure that I was using the correct calls and what-not. If I could restart this sprint, I would spend much more time on learning how to test in angular (sense that is the most frustrating part to me) rather than writing the code. At first, I was coding a method that was too complex, with the help of google I was able to finish my updateDoc method (as far as I know).

Our team is working well together, I think we could do a little bit better helping each other remember to do our standups and evaluations. Besides that we work really well together. I think we are all contributing equally to the project, so there is no problem there. As a team we feel as though we could have gotten this sprint completely finished in the allotted time if we had prior knowledge of testing in angular. However, it is what it is. Our next sprint will most likely focus around testing the methods we have created and tweak them to try to perfect them.

Our sprint plan was to finish this module, obviously that didn’t happen. Each of us was responsible for writing a method and Connor was responsible for testing. I wouldn’t blame Connor for the tests not being done because he still has to learn the testing procedures for angular as well and if he has to write a test for each of our methods, that is bound to take some time. So each of us has been pitching in and trying to debug together. This means that our sprint goal will most likely be extended to next sprint as this really is the last step to finishing off the Offline Storage Module.

I am interested to see what will happen when we (our entire class) conglomerates the code and tries to piece it together. I can imagine that some snags will occur and it won’t be very smooth at all. We will have to assign different people to test different parts of the entire offline module to ensure that everything is compatible with each other.

 

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

Thoughts on “Craft Over Art”

Craft Over Art seeks to solve the problem of a craftsman wishing to create something beautiful, elegant, or resume-padding at the expense of the party that commissioned the project.  The authors strongly advise that the craftsman deliver a product that is useful, functional, and to specification rather than one that is fancy, inspired, or unique.  The craftsman also cannot wait for inspiration, and must deliver a satisfactory product on time.  Speed is also not the only concern; the product must have at least a minimum of quality even if it takes a little longer.  This is an important concept to introduce to the client as well.

Although I do not fully agree with everything in this pattern, the basic concept speaks to me.  There are a lot of things that need to be balanced in a professional product.  I have run into this firsthand when developing software for my job; my boss obviously wants a quality product, but also does not want me to spend excessive time on it.  I have needed to balance doing things the “right” or “perfect” way with just getting things done.  I do think, however, there is still some room in my work for improvement of quality.  Reading Clean Code and trying to put those ideas into practice from the start of a project has been helpful, although my current project will still likely need a good refactoring, if the time to do so is in the budget.

I don’t necessarily agree with the way that the authors dismiss the art of programming (and the process of art in general; it’s not just waiting for inspiration to strike), although I understand it’s somewhat beyond the scope of the book they’re writing.  I think there is room for the unplayable “million-line game that pushes the frontiers of computer science” — even if the craftsman (or artist, I suppose) that developed it does not benefit directly, the whole field might be inspired or lifted up.  I think there is room for programming as an art, room to make decisions inspired partly by aesthetics rather than purely by utility.  Maybe that’s only in personal projects that don’t have hard deadlines, but I think there’s space to be found for artistic merit in the professional world as well.

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

The Abstract Class – Sprint Retrospective #5

CS-448
CS@Worcester
Sprint-5

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

As we enter the home stretch, the team has continued to make good progress on the project. It’s weird to think we only have four weeks or so left in the semester. It has flown by! The team continues to work well together and communication is never an issue. In fact, I’d say it is even one of our strengths. Even on days we don’t have class and we are at work and/or busy doing other things, team members are quick to respond to each other’s questions, put pull requests through, etc. Good communication is always vitally important to the success of a project, so it is great to see us excelling at this. I don’t have any pressing complaints or need-to-work-ons at this point. I think a lot of that stuff was hashed out earlier in the semester and if an issue comes up now, we are quick to address it mid-sprint rather than putting it off.

For sprint five, the team set out to further improve the rudimentary version of the offline login service that we created last sprint. We were able to make some progress towards this, although it still isn’t quite all the way there (it wasn’t expected to be all the way there this sprint). The other main goal of this sprint was to get Ampath’s approval for our plan to implement the offline login service. To do this, we reviewed and updated the high level designs I had created earlier as a team. I thought this was a very good exercise as it allowed for us to make sure that everyone is on the same page. We were able to present these designs to Ampath to ensure that we were going about this the correct way. They approved of the design without asking for any changes to be made to it, so we can press on with the implementation of the design with full confidence now. It was nice that we were able to get this approved because now we don’t have that lingering concern in the back of heads that we might have to scrap everything we had done.

Although those were the two main goals this sprint, we also got a bunch of other stuff done. We were able to make progress towards updating the GUI to give the user the option of storing the credentials offline rather than just doing it automatically. This is an important feature to have because we don’t want to be storing credentials for every single user that logins into the app. This is not only inefficient but, could also cause security problems. All of us were also able to do some research on subscription processing. This was done because another team is planning to use this.  George was able to fix the OnlineTrackerComponent bug and make a pull request to Ampath to fix this issue. Kudos to him for taking this on. It was a bug found mid sprint, so it could have waited until next sprint as we had already committed to a bunch of work, but he took it on anyhow. We were also able to document out new Git approach after there was a bit of hiccup this sprint (luckily, we were able to get it fixed). Several other minor tasks in addition to what I’ve mentioned were completed as well.

Next sprint is our last full sprint for the semester. I believe the plan is to continue to work on implementing the offline login service, however I think documentation of what we have done and what still needs to be done should also be a focus. This way both the Ampath folks and, should a team in next year’s capstone pick off where we left off, will be able to tell what progress/changes were made. It should make their lives’ significantly easier and prevent them from having to start from scratch.

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

Sprint 5 Retrospective: Capturing Patient Data

As Sprint 5 comes to a close, I believe we are making great progress. Our team’s primary goal is to have a completely functional data capturing service for offline purposes. With the achievements made during this sprint, it seems very realistic that we will have a working module by the end of this semester.

Our main objectives for Sprint 5 were the following:

1.  Decide what would be the most useful data to capture.
2.  Capture raw data to be stored into PouchDB.
3.  Construct ideas presenting captured data in a meaningful way.
4.  Improve cross-team communication.

Deciding what would be the most useful data to capture:
We all agreed that we should begin to focus on storing detailed patient data. Internet connectivity is often unreliable where the AMPATH app is intended on being used. We want to allow medical providers to have offline access to patient data when a given patient is expected to be seen.

Capturing raw data to be stored into PouchDB:
I believe we have made substantial progress concerning this task. We were able to use OpenMRS services (located in the ./src/app/openmrs-api folder) to help us achieve our intended goals.

Originally, we were able to capture data of some 200 patients having the word “test” in their names. This was a great starting point, but we knew we needed to improve upon our results. First, the data was being captured and stored into one large file. This contrasted with our intended capability of having each patient object being stored in its own file. Second, the data being captured was only basic patient information, such as name and address. We wanted to also include more detailed criteria, such as upcoming appointments and other patient encounters.

Initially we were using the PatientResourceService.searchPatient('test') function to capture a given array of patients. We were taking the results from the returned Observable and storing it into PouchDB. The problem we were having was figuring out a way to iterate through these results so we could store each patient in an individual file. Ultimately, we were able to achieve this by using the JavaScript lodash ability. By importing lodash in our component, we were able to use _.each to iterate through the subscribed results from the returned Observable in an array-like fashion. 

Our next step was to try to figure out a way to store patients other than those with “test” in their name. Further, we wanted to capture more meaningful information about the patient (appointments, encounters, etc).

Ultimately, we were able to manipulate an existing component, located in ./src/app/patient-dashboard/common/patient-encounters/patient-encounters.component.ts, to store a patient’s detailed data in PouchDB when it is searched for.

Presenting the captured data in a meaningful way:
This is a topic discussed in great detail during our last working class during Sprint 5. Ultimately we need to decide how we are going to present this to the user. We anticipate the user will be a provider, such as a doctor looking for information about patients to be seen. We are in the process of constructing a mock diagram for a GUI to view and manipulate the captured data.

Improving cross-team communication:
I feel we have made some progress in this area. We seem to have a general idea what everyone is working on. But at the same time, there is definitely room for improvement regarding our communication with other teams. We anticipate a lot of cross-team collaboration in the upcoming sprint. Since all teams are finishing up their work, we need to make sure all implementations are compatible with each other. For this reason, I am confident our cross-team communication will continue to improve during our next sprint.

Overall:
I believe this was an effective sprint. We’ve all done a good job letting each other know what we’re currently working on. I had a lot to do with implementing the offline capturing abilities, but this was only possible due to the support and input from all of my teammates. Regarding participation during this sprint, I think we’ve all done our fair share.

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

Concrete Skills

This week I read the book Apprenticeship Patters guidance for the Aspiring Software Craftsman. There was this one section that caught my attention and it was the Concrete Skills. This was very interesting to me because it’s quote was “Having knowledge is not the same as having the skill and practical ability to apply that knowledge to create software applications. this is where craftsmanship comes in.” Growing up we are taught that you need all the knowledge you can to even be able to be considered for a job. Many people tell us that you need even a masters to be considered for a job these days anymore. However there was a professor I meet back when I first started  programming he told me he used to be the hiring manager for IBM and he meet hundred of different candidates that tried and applied for the job. The things he learned about hiring people is that not everyone is the same.  Yes there will be people who have the knowledge of programming and would pass all these tests and get everything right. However,  once it came to actual coding and work ethics they were very questionable. There are people who got out of college that have a different perspective. They say that  everything you learn in school isn’t going to be helpful in the real world. Most of the time you learn all your skills once you get a job where they teach you what skills you need. It is really all about if the job would take the risk and hire you. There are many stories that there are people who have basic knowledge of programming are hired because they have experience in other fields that can be used to help out the team in different ways because you don’t just want a team of programmers that know one language but a team that can cover each others weaknesses. That’s why I think that this sections is very good because it gives a real perspective of what companies should look for in a person not what they can do now but how will hiring them affect us in the future and the capability of these people in the future.

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.