Third Sprint Retrospective

This sprint was an important one, as we finally began true work on the project. My team and I seemed to have decided to work on the offline storage aspect of the project before even formally deciding it. We all started some preliminary research on PouchDB, the database tool suggested by the Ampath team, before this sprint started.

With this sprint, we began researching and experimenting with PouchDB in earnest. Breaking the larger task up into five individual tasks for all team members proved difficult. Thus we all began doing the same task in our different ways, and planned to meet up and discuss pitfalls and tips we discovered individually.

Unfortunately, due to snow storms and power outages caused by the storms, our next two in person meetings were canceled and communication for some team members was cut off. This meant meeting back up to discuss our experiences and research results did not happen, except a limited one between myself and two other members when we happened to be on campus at the same time. This was very helpful, and I wish we were able to have the two meetings we missed with everyone.

I began by reading through the documentation of PouchDB, learning how it is setup . It’s a NoSQL database that stores documents, that can have as many attributes as one wants. Each document has a unique ID and rev attribute. The unique ID is to give each document a unique identity. The rev attribute is to revise previous documents. The previous documents are not deleted from the database, but the new revised document is simply added to the database.

I began delving into PouchDB by doing the basic tutorial on PouchDB’s website, a basic Javascript project. I looked through the code to see the basic commands, such as creating a PouchDB database, adding documents to it, and getting documents from the database. After this I created a new angular project to play around with PouchDB in Angular. This led me to an unexpected error in creating a new Angular project using the Webworks IDE. I learned after some looking this is due to a change in Angular CLI 1.7.0 that makes creating a new project through Webworks and other JetBrains IDE’s impossible. The issue as explained by a Webworks Product Manager:

https://github.com/angular/angular-cli/issues/9655#issuecomment-370491452

After discovering this I simply made the new project using Angular CLI directly, then opened itin Webworks. I made a new project instead of playing with PouchDB in the ng2-amrs project is due to the amount of dependencies and pre-existing files in the project. I wanted to start with no baggage and play with PouchDB in a clean new environment. Through trial and error, and discussing with my team mates I learned one large mistake I made was following the Javascript and Typescript instructions for installing PouchDB. Due to the basic tutorial I did, I used the method that involves adding a script line in the index.html file of a project, and then used the TypeScript method which installed the @types folders for PouchDB, as Angular uses Typescript files. This led to issues with the import statements in my program. After getting rid of the line in my index.html, the import statements worked as stated in the instructions on the PouchDB website.

After this, using the examples shown on the PouchDB website, I was able to create a database, put in new documents, and got those documents back and logged them on the console in Angular. I read up on several resources to understand how promises work, as the PouchDB API uses promise formats for the commands I stated earlier. They are essentially a truncated try-catch block, that waits for a response before continuing on.

Despite the missed meetings, I feel like we got a good start to the project. We now have a foundation to complete the offline storage aspect of the project. Especially as one of our teammates has pushed their version of the project with PouchDB installed and dependency issues fixed on Github for us to use.

Concrete Skills

While learning how to be a great apprentice is great, the main issue is getting to that point. Specifically being accepted onto a team or project, being hired by a company. To be a part of a professional team and become an apprentice is the first step and can be the hardest thing to accomplice for some.

As the book states, it is a risk hiring someone new and untested for teams out there. You may not be able to contribute to the teams work and you may not even be able to take care of automating simple manual tasks. So then how does one solve this issue? By having Concrete Skills. Having skills that will first of all get you through the HR filter and technical skills that can and will aid any team you are on. This makes the risk of hiring you on much lower, and makes the decision easier.

This apprenticeship pattern was not really at all surprising. Every step of the way, I was nodding my head. Learning concrete skills just makes too much sense in my head to be something anyone can disagree with as a valid way of making it more likely to be hired on to teams. Reading this apprenticeship pattern has not changed any of my thoughts on my chosen profession but has solidified the path I believed I would have to take in the first place.

The story the pattern offered did make me open my horizons when it comes to what count as concrete skills. Skills gained as a therapist would obviously be helpful in a team setting, but it is not something that would come to my mind readily. I mainly think of only technical skills, but social skills that can aid the rest of the team in ways I or they would not expect are also completely valid avenues to making it easier to hire oneself.

Also, looking at others CV’s and resumes, then pulling out the concrete skills that one can learn themselves and demonstrate easily, is a simple action that I can start doing now. Something obvious in hindsight that I should have been doing from the start.

Second Sprint Retrospective

This sprint cycle was focused on coming up with the design of the offline module. We spent most of the sprint researching and thinking through what we were going to do in the future. It was mostly planning and research,. It became clear pretty quickly in that we were interested in doing the offline storage of the offline module for the application. So we did research on one of the suggested services in the users tasks, pouchDB.

I mainly read through the articles they suggested and other articles on the different ways to store data offline with an app and encryption. Doing research on the encryption aspect may turn out to be pointless since another team as decided to take up the aspect.

I also considered what the offline version of the app would look like. The look has to change somewhat to let the user know they have gone offline, and also due to the missing information and features available when offline. Also Towards this end, I went through all the pages on the apps test server to get the general visual design of the application. I also communicated with the Ampath team about the apparent loss of the fake patient data that was on the test server, but was removed for some reason. Felix, from the Ampath team, was a great help with this. The JSON representation snippets Jonathon gave us and the general description also was a great help in visualizing the look of the application when it goes offline.

I decided to make a small mock up of the visualization of the applications offline look on balsamiq. Considering the minimized nature of the data when it stored offline, and the lack of other features mentioned in the documentation, such as offline clinic viewing, I removed everything but the patient search. This should be simple to accomplish in angular from what I’ve seen by simply hiding features from users when they are offline. This means the application looks almost identical other than features being removed, and a limited number of tabs on patient information.

The team went through the code of the application during meetings to get a general gist of how it is layed out. We asked theAmpath team if they had a UML diagram to better aid us in understanding the way the code is organized and laid out, and how it all comes together. Unfortunately, they did not, which means we will simply have to get used to the way the application is organized.

The biggest take away from this sprint is the lack of direction that comes from having a higher level manager. Without this, the sprint felt somewhat lacking in direction. I realized that a lot more initiative would be required to get things going, but I still found myself lacking. I feel like this is a good learning experience. In the real world, nothing is perfect. There might not be concrete goals or plans. There is a lot that relies on me and others making ourselves be active and actively open up communication with other teams and people.