Sprint-2 Retrospective

This sprint session was really tough for me at the beginning. I was confused as to what exactly was expected from us and was stressed for some time. Not having a sense of direction regarding which specific file to look at was a big issue. Thanks to the team members especially Rick Phillips who came out with an outline of what the team at that point need to focus on.

First and foremost, we started the sprint by deciding how we want to manage the gitHub repository. We came out with the decision that Rick Phillips should make a copy and give every team member the right to pull and edit. We also had to read the user story by the AMPATH which was quit straight forward. I did not know all these at the beginning.

Also, one most important among our task was to come up with design ideas to implement the ng2-amrs offline module and I think it is a good idea to have such a system. If my memory is right, I think we concluded with an idea that there should be a front server, intermediate and the remote server. Even though we are not sure if that will work for AMPATH, I believed we had a good idea. The intermediate server will act in between the remote server and the front server. The offline service would then be pending within the intermediate servers and anytime service is restored the front and the remote server would be updated.

Rick Phillips again draws our attention to the router component which helped us dig more to see how components are in connection with each other. With regards, we try to understand the AMPATH node paths on mapping the routes of the code in connection with AMPATH server; we together experimented some search by checking the URLs to see what component get invoked when a particular call is made. Even though things were not quit clear, I still have little ideas as to how some of the component got called. This was really helpful in understanding some of the parts in the ng2-amrs code that I do not understand earlier. Digging to the router component too has caused us as a team to do more outside the project search and tutorials to understand better how routing in angular work. Though, at this point, I cannot strongly say I understand how it works, I still had little knowledge which help me understands things to the point the team discussion has been. I will continue to explore the router component to improve on the little knowledge I had from this sprint.

Besides, per the recommendation by Jason, I had also learned a couple of angular tutorials which help in figuring out of what is going on in the app. Though it has been time consuming trying to figure out things by ourselves, the sprint has actually challenge me to learn more stuffs on angular and above all routing which I have never thought of. I believed if the team keeps up with the enthusiasm that it put into work in this sprint period, we would have more work accomplished in our future sprints.

 

 

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 2 Retrospective: Deliberating and Conceptualizing

This sprint was an interesting one. It seemed to offer insight for what we should expect going forward in our professional careers. In college we can become overly accustomed to expecting and working with concrete tasks. I feel this sprint was a great reminder that out in the world of software development, tasks can often be anything but concrete.

As time has progressed, in terms of scrum, I’ve been thinking of the AMPATH app’s consumers as the customer, Jonathan from the AMPATH development team as the Project Manager, and our professor as the Scrum Master. The project manager gives us as team members direction on what we should be focusing on. This is based on his knowledge of what the customer needs. The scrum master offers guidance in best optimizing these tasks. If we hit a road block, the project manager and/or the scrum master help “clear the way.” They are available for general questions and direct us to the answers of these questions. But virtually nothing has been concrete, and I realize we should not expect it to be. Ultimately it is our jobs as scrum team members to figure out how we’re going to tackle each “story” in our sprint backlog. And that is why I feel this sprint has closely emulated a real-life scenario of working in the field of software development. I am grateful for the experience.

We’ve spent this sprint with the primary goal of conceptualizing ideas to implement offline capabilities for the AMPATH project. From there, it seems to have led each team on interesting paths. For instance, our team quickly realized it was initially near impossible to conceptualize any practical implementation of an offline module. In order to proceed, we thought it was imperative to understand the complexities of the AMPATH app. While scrutinizing the code, our team noticed a pattern of repeated references to routing, HTTP calls and REST APIs. These are all subjects we had limited to no knowledge about prior to this sprint. Thus we dedicated the majority of our time becoming more familiar with these processes.

Based on the collaboration between the AMPATH development team, my teammates and my professor, here’s my brief understanding of the project so far:

  • The AMPATH app communicates to servers primarily by REST (Representational State Transfer) API.
    • REST is an approach that uses HTTP requests to GET, PUT, POST and DELETE data.
  • The app is dependent on not one, but TWO servers, OpenMRS and ETL.
    • OpenMRS seems to handle the majority of the resources, such as user accounts, locations, visits and encounter types.’
    • The responsibility of ETL seems to focus on what the acronym suggests, i.e. Extract, Transform, Load. Based on my research, it seems that the job of the ETL server is to optimize the data retrieved from OpenMRS server, such as extracting data from one database to another.
      • As of this writing, the ETL server seems to be down, and the AMPATH development team is working to resolve this.
  • Many of the AMPATH components seem to consume the OpenMRS LocationResourceService. The service seems to provide a gateway allowing other components to call HTTP requests. It is located in the openmrs-api folder within the project, i.e. 
    './src/app/openmrs-api/location-resource.service.ts';

I would like to give a special recognition to Felix (fmaiko) from the AMPATH development team for providing me with much of this information. These findings seem to indicate that we should be focusing on understanding the OpenMRS functionality. Further, the LocationResourceService seems to be a pivotal factor in making REST calls to the OpenMRS server. Felix provided me with a link to the OpenMRS wiki; I suggest anyone working on the AMPATH project to check this out going forward. It outlines pivotal information such as obtaining sever resources, as well as the format for sending each request.

For a sprint initially focused on conceptualizing ideas for offline implementation, it definitely seemed to branch off in all sorts of different areas of research. That’s what I enjoyed the most about this sprint. We started off thinking we would be primarily designing offline implementation mock diagrams. But the learning process involved turned out to make it a very informative and eventful sprint. As for our original hopes for coming up with an offline module idea… based on the information we’ve gathered during this sprint, we were able to conjure up a very abstract idea using Balsamiq:

Client-Server Check if OnlineWe are hoping to improve on these ideas in the sprints ahead.

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

Sprint Retrospective 2

On Thursday February 15th, Everyone Else (our team) sat down together to talk about what we would be going over for this sprint. We came up with a plan for this sprint to be our research and designing sprint We wanted to figure out what options we had available to us and what kind of design we were expected to create. We didn’t really get too much physical work done that affects our goal to the actual project, however I did get a chance to learn about some things that I hadn’t studied before.

To start, we had a slack message from our friends at AMPath who suggested we looked into PouchDB. PouchDB is an open-source JavaScript database inspired by Apache that is designed to run quickly within the browser. This is exactly the type of thing that we were looking for. Since our overall goal for the class is to be able to have the ability of an “Offline” mode for the medical records app from Ampath, PouchDB would be the perfect way to store data and then sync with the server once you are connected to the internet.

I followed the guide on their website to get the feel of the tool and be able to implement it into code that is already written. You can find the tutorial here: https://pouchdb.com/getting-started.html

The first step I had to take to be able to go through the getting started guide was downloading python from https://www.python.org/ . This guide used a python Simple HTTP Server to get the application running but I am sure that it can be implemented into the AMPath application anyways. After installing python (and PouchDB), I downloaded and unzipped the pouchdb-getting-started-todo.zip files that setup your “todo list” application (with missing features that you add yourself.) This tutorial helped me figure out how to create a database, write information to the database, show data from the database and manage a user interface. The last step in the tutorial shows you how to set up a two way sync with CouchDB which is the server tool used for this tutorial.

Another resource i used to get more familiar with the framework of Angular2 was Youtube. This video which is 1 hour and 18 minutes long really helped me work through the basics of the Angular2 framework and how to work with the three language (HTML, CSS, and Typescript) together. https://www.youtube.com/watch?v=bJKejcQJqHE

In this video, the narrator has you go through steps to set up your own personal website using the Angular2 framework. While it isn’t progress to the actual goal of our sprint, it was an essential part of me understanding the languages and taking some steps to practice writing in the language we will be using for the project.

The team is doing well communicating our ideas. We set up a group chat over texting to remind each other of deadlines and to talk about our progress. Everyone is encouraging each other to get work done. One thing that I think we will be doing differently this week is putting time into the project code and working together more to write code and get some progress done. Since the planning phase is over, we can finally take some steps towards the true goal of this project, an offline module.

Our team has also already accepted the task of working on an offline data storage service, so the information I learned about PouchDB should be very useful in the coming sprints.

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

Post #21 – Ampath Application Development – Sprint 2 Restrospective

Our second sprint mainly consisted of reviewing the source code of the Ampath application.  The first of our 4 meetings was uneventful, because only 2 of our 5 members were present.  During the other 3 meetings, we worked with one of the other development teams to review the services within the application, reviewed the ReST API, and discussed how we might be able to utilize them in our own work.  Our team then accepted the task of implementing offline encryption for the application, and got in contact with some of the people at Ampath to get their input on their preferred encryption libraries.

Our team members collaborated well with one another and the other development team we worked with.  We were able to gain more of an understanding of how the Ampath application works, through our reviews, and we were able to begin planning our course of action as we head into the coming sprints.  We devoted a majority of this sprint to review and planning, so we have yet to start working on any kind implementation.  We hope to begin coding once we have some more structure and concrete direction, in the next sprint.

Toward the end of the sprint, we began working on the offline encryption task and we found 3 suitable libraries that we could use in our implementation.  We wanted input from the Ampath people before we chose a library to begin working with, so we sent them the 3 that we selected.  In their response, they commented on the fact that the encryption library ‘forge’ seems to be the most popular on GitHub, but stated that we could use whichever one we think would work best.  We will likely make our decision in the next meeting.  In our correspondence with the people at Ampath, we were also provided the main ReST API calls that are used within the application.  This will be extremely useful in the future when we have to begin sending and retrieving medical data in the implementation of the other offline features.

It was, once again, a fairly straight forward sprint.  I think that all of the development teams could use a bit more direction right now, but the coming sprints will certainly be more productive now that we are more familiar with our team members and the application itself.  I have so far been enjoying the Scrum development cycle and I look forward to beginning implementation.

 

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

Sprint 2 Retrospective

I think I learned more this sprint about the necessity of good sprint planning than I did about anything else.  We started the sprint by laying out goals, and by going over the user stories in the doc that AMPATH sent us.  This was useful work, but after that we hadn’t planned for any real actionable items.  Broad goals are nice for setting a larger scope, and less so for getting concrete work done.

I did, however, learn some concrete things; I think it’s also important to note that most of my learning took place in a group setting both within my team and with another team meeting in an adjacent space.  I learned how the AMPATH app strings its services together to go from button press to REST API query, and how that information is propogated through the layers of services and onto the user interface.  I also learned how they check the online status, which may be more important going forward for other groups that are focused on smooth offline/online transitions (my team, for now, is taking on data encryption).

Other than team planning process (which I will get to later), the most important thing that I learned was that, at least for me, it’s far easier and better to go through code in a group setting than individually.  I tend to get lost or distracted when I’m looking through it on my own, where in a group I can focus and bounce ideas off of my peers.  We ended up using a projector to throw the code up on the wall.  We then started with a form that logically must request server access (we looked at the patient search form).  From there, we looked at the service invoked by the actual search function(s), which is set up to generate a table of search results.  In order to do that it makes use of another service, which actually builds the REST request from a URL stored elsewhere and the string passed along from the search bar.  I think a similar tracing of services could be useful in the future to other groups interested in different parts of the UI.  We also received some help from the AMPATH team, directing us to the openmrs-api folder which appears to contain all of the services that interact with the server.

The most important team-related learning that came out of this sprint is the now-clear necessity for specific, concrete tasks rather than more abstract ones.  We came to this conclusion during our team sprint retrospective, and we agreed to spend more time breaking down tasks and assigning them during sprint planning moving forward.

In addition, during the class time where we met for our retrospective, we started researching already-made encryption services that we could use to encrypt records pulled from the AMPATH servers.  We found three so far that may be promising; one way we can add specific, focused tasks for next sprint could be to assign one of these services to each team member so they can research it and prepare a brief report.  This way we will be able to present what we’ve found to AMPATH for feedback on which might be the most suitable (they’ve already given us a few guidelines).

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 #2

Highlights:

  • Team communications
  • AMPATH application
  • Learned about Scrum
CS-448
CS@Worcester
Sprint-2

From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Retreat into Competence

Summary

There are times when we are reminded of the vastness of our ignorance. As we travel outside our comfort zone of experience, we are sometime left feeling overwhelmed by just how much we don’t know. When this happens, we can take a temporary reprieve into one of our stronger skill sets and reinforce our confidence in our competence. Used wisely, this method can recharge our resolve to charge ahead into uncharted territories.

My Reaction

I think that this is great advice. I particularly like how it includes the warning to not misuse this pattern in a counter productive way. There may be times when it is inappropriate to revert to old habits and methods simply to forgo more difficult but correct methods.

It further reinforces this by stating that this is considered a risky method and further warns that repeated use could result in your skills becoming obsolete. It really accomplished emphasizing the handle with care mentality needed with the Retreat Into Competence pattern. While it is very powerful, it can also quickly become a crutch that could potentially stunt your development growth.

These warnings may prove to much for me to use this pattern very often, if at all. I may not find myself In the Deep End as I bring a certain level of previous professional experience to the table. I could see myself prioritizing tasks that involve items that I am more familiar with while pushing others down the list.

One of these tasks could involve a language I have worked with before while the other involves researching a new framework. I may stick with what I know while prolonging the unknown. I may be better served going with the unknown task and reserving the known item if I find myself overwhelmed with the new task. This pattern suggests that may help.

I agree with the simplicity of the pattern; its almost immediate potential impact; and the potential pitfalls with its misuse. The next time I find myself feeling overwhelmed by my ignorance, I will try to remember this pattern and look for an opportunity to reinforce my confidence by accomplishing a task in a familiar way. This sense of accomplishment could propel me to success in overcoming my original sense of being overwhelmed.

CS-448
CS@Worcester
Week-7

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 2

Team Retrospective – Sprint 2

I think this was another important sprint. Most of my group members were all new to the technology we are learning so this sprint kind of gave us an opportunity to read more about the programs api’s and how they worked and functioned. We also had a few tasks that could not be completed in the first sprint so we carried them over. For the first sprint we were to complete building the application and setting up the environment.  Some of our members were also able to connect the application to the server but that was officially a task of sprint number 2. After reading many documentations, we all connect to the server this sprint. Some of the other tasks that we were also to accomplished this sprint included checking out balsamiq and coming up with design ideas to implement. The design idea was no simple task because almost everything we thought of was too abstract for our current knowledge or not enough to contribute to the current repo so after sometime of going back and forth with ideas, we realized that on our Trello board, we had various tasks and features that were advertised and needed to be built and implemented in the application. After much discussions, we as a team were able to agree on one task that we felt could be accomplished and completed by us based on our current knowledge as a team. we picked the “offline login and Offline data storage” as the task we wanted to get done. Personally, i have not created any “login” applications but i believe i have the skills and capacity to learn all that i would need in order to be able to contribute my share to the team. After deciding to go this route , we realized that we needed help from other teams depending on what they had selected as their tasks to complete. Since we wanted to do the users offline sign in and data storage, we needed to store the user’s passwords and usernames locally on the device that will be accessed. But since log in credentials are sensitive and needs to be secured, we realized that we needed to implement a decoding and encoding encryption system. This way, all data saved on  the local system could not be accessed by anyone who would come in contact with it. Again the patients data would also have to model the same architectural pattern because patients information are private and thereby needs to be kept safe and secure also. With all these thoughts and approaches in mind, we reached out to a team that was next to us and luckily, they agreed to handle the encryption and decryption side of the design. This brought us to an ease because  it split up the overall tasks that needed to be completed by us but on the flip side, it puts a dependency on their team. We would have to know how the encryption works so that we can code to implement it.  This to some extent makes me worry a little bit because it almost seems as though if the other team encounters issues they are not able to resolve, we will be stuck but again, i know we can use dummy variables to get at least the concept aspect completed. Looking forward to the new sprint. !

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

Looking Back on Sprint 2

The second sprint was a bit more open ended, with far fewer discrete tasks to complete than during the first sprint. This meant that rather than working independently during class to complete individual environment set up tasks, we worked as a team during class to discuss the user stories contained in the Google Doc. I feel that once again the team worked well together and everyone contributed to achieving the goals for this sprint. There are a few places where I see room for improvement, and this was discussed during our in class retrospective meeting.

One of the first tasks that I personally completed this sprint was looking at the mockup tool, Balsamiq. While I was a little unsure about this at first, seeing some of the mockups that other teams did later on in the sprint helped me to better understand the tool. I think that for the next sprint, using Balsamiq as a team to visualize our ideas will be extremely helpful.

Although I had already completed the build ng2-amrs and connect your ng2-amrs to the server tasks, these tasks remained on the sprint backlog because not everyone on the team completed them during the first sprint. By the end of sprint 2, however, all members of the team had completed both of these tasks and they were moved to the completed board. This was important because these tasks are essential to beginning actual development, which will likely occur as early as the next sprint.

Another task that was left over after the first sprint was learning how tests work in Angular. Although we were told at the end of last sprint that this task was probably not essential, we decided as a team to include it in the second sprint because the majority of the team had already completed it. Members of the team who had already looked at resources on Angular testing shared their sources with those who had not yet completed the task.

The most significant tasks for this sprint had to do with generating design ideas from the user stories shared by the AMPATH team through the Google Doc. We met as a team during class time and began by reading the user stories together as a group. Although much of the team had already read the user stories independently before class, I feel that talking them out was helpful in providing clarification. Members of the team shared their individual understanding of different parts of the document, and asked questions where understanding was lacking.

After we felt we had a general understanding of the user stories, we looked as a team to the tasks that were listed further in the document. We then brainstormed ideas in a document for the first task on the list. This is the task that addresses offline login and offline data storage. We collaborated with the group directly behind us to share our thoughts and also get a better idea of how they were planning on going about development.

I think that we as a team are becoming more comfortable collaborating with one another, and also with sharing our ideas with among the other teams. I think that in future sprints we need to continue to attempt to clearly communicate our intentions with other teams so as not to do overlapping work. Although the effects of duplicated work were not very severe during this sprint, it could result in a lot of wasted effort in the future. I am looking forward to continuing to work with my team in the third sprint and using what we have learned to work effectively and efficiently.

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

Sprint 2 Retrospective

Overall I feel that this sprint could have gone better, but as a silver lining, it gave us an opportunity to see what we need to improve on moving forward.  Luckily this happened early on in the project and wasn’t an issue that went unnoticed until the semester was almost over.  The important part is to reflect on the faults of this sprint in order to improve and avoid the same mistakes moving forward.  I do believe that we did start to come together as a team and work well together.  I feel that everyone on the team is willing to listen to everyone else’s opinions without passing judgment or shutting each other down even when disagreeing.

One important piece that we did not do is documenting.  We should have documented what we figured out to help us navigate what we were learning.  Looking forward I plan on taking personal notes recapping the team meetings just to keep a personal track on what we talk about.  I feel that we also need to encourage each other to start documenting what we find when working outside of team meetings, or even what we may come up with during the class time.  This will help reinforce what we learn and also allow us to more effectively share it with the rest of the team.

Another problem area was assigning tasks.  There’s an old saying that I learned years ago that if a job is assigned to everyone than it is assigned to no one.  Meaning that if it is kept general and said that “this is a team task” without specifying a role for every member, even if it is explicit for each member to complete the same task, then there is a strong chance that no one will do it and expect a different team member to do it.  There needs to be direct ownership of tasks to ensure they at least get worked on.  When there is no ownership that also means that no one can be held accountable for failing to do it.

The sprint wasn’t a complete failure though.  We read through the user stories to get a better understanding of what was going to be expected of us.  This also helped start team discussions as to which service and task we wanted to take on for the majority of the semester.  This also helped get us started on mapping out the program and services that the class will be working on improving.  We started to look at the ng2-amrs code both on our own and during the last few class periods.  We started to look at where we login to the site and walked through the code starting from the login to try and map out how the program runs and works with the REST API.  Again this would have been better to write some kind of documentation to reinforce our understanding of this mapping.

While not the most successful sprint I do believe that it was productive from the point that we learned what not to do moving forward.  My hope is that we can build on our failures and become more successful for the rest of the semester.  While it’s important not to dismiss this sprint entirely we can’t let it bring us down and lower the team’s morale.

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