Category Archives: Sprint 2

Sprint Retrospective 2

This week’s sprint retrospective we finally figured out what we are doing.  We started to talk about what we wanted to do for the project. Looking at the Trello board there were quite a few options. However, since Eric had some experience with encryption services we decided to work on the encryption for the website. While we were reading the google doc to see what they wanted us to do for this project. We noticed that they wanted to be able go to download a certain patient information before they were to go out onto the field because whenever they were to work on the field the internet would cut off and it would impact their work dramatically. So, we know that since they are taking sensitive information with them outside they have the risk of it getting stolen.  With this information, we wanted to have an encryption that is not just some username password but also a keygen so that way it would last a few weeks or however long the doctor would want the information on the tablet to be accessible on the tablet but after that it would get locked out where you would not be able to access the information at all. We then started to look up what kind of library’s we could use to make this encryption such as crypto-js, forge, bcryptjs, and webcrypto. We sent a message on the slack asking what kind of encryption that they have already used or would like us to use and they are fine with us choosing. We then set up on our Trello board what each and everyone has to research and write a sample project with the assigned library. Moving forward we just want to be able to work on our communication with each other and how we would be able to share the information that we have with not just each other but also with the rest of the class. Throughout the week all I have done was read though the code and to see what it does. Reading though the code it looks like they have some kind of implication for security however it looks very basic.

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

The second sprint has just finished, and though this one was not as involved as the last one, I still learned a whole lot about software design and javascript itself. While the last sprint was very informative due to the environment set up, and generally getting familiar with the new tool, this sprint was informative in the sense that it taught me some of the challenges that come with breaking down a very big task. As developers, we want the tasks to be broken down and very clearly defined for us from the start when in reality, that is never really the case. As frustrating as that is sometimes, it is a lot is learned when you are able to break down and design a task yourself. I would say that was the most important thing that I learned from that sprint, because having to work as a team and breaking down a task that we barely understood forced us to ask some questions that we probably wouldn’t have if the task was handed to us like “here, code this”. I think that this ambiguity is ok to an extent when it leads you to ask questions that give you a clear picture, it is very easy to be too ambiguous where it leads to time being wasted since it feels like there is no starting point.

Work wise, I think that this sprint was a bit lacking (since it was mostly planning and design), so our team worked through that very well. As a team we bounced ideas off of each other and asked questions that helps clear up some ambiguities. More impressive than that is how well our team worked with other teams, we know that class-wide communication will be needed to complete this project and I thought our team asked the right questions to get a good idea of how we will integrate some of the key functionality (like how does the app know that it is offline). I thought that my participation in this was sizeable because I threw out a few ideas on potential ways that we could implement this offline detection functionality.

The most important thing that came away from this sprint was each team coming away with an understanding of the modules that will be needed, a general understanding of how they will fit together, and starting to get a feel for which component in particular they intended to work on. We accomplished this by talking to each other and staring at the code the learn how it works and sharing that knowledge with each other. If we could have done something different it would be going into that deeper level of detail much sooner in the sprint, but now that we know how well this works we will improve on that for the next sprint.

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

Sprint 2 Retro

The second sprint has just finished, and though this one was not as involved as the last one, I still learned a whole lot about software design and javascript itself. While the last sprint was very informative due to the environment set up, and generally getting familiar with the new tool, this sprint was informative in the sense that it taught me some of the challenges that come with breaking down a very big task. As developers, we want the tasks to be broken down and very clearly defined for us from the start when in reality, that is never really the case. As frustrating as that is sometimes, it is a lot is learned when you are able to break down and design a task yourself. I would say that was the most important thing that I learned from that sprint, because having to work as a team and breaking down a task that we barely understood forced us to ask some questions that we probably wouldn’t have if the task was handed to us like “here, code this”. I think that this ambiguity is ok to an extent when it leads you to ask questions that give you a clear picture, it is very easy to be too ambiguous where it leads to time being wasted since it feels like there is no starting point.

Work wise, I think that this sprint was a bit lacking (since it was mostly planning and design), so our team worked through that very well. As a team we bounced ideas off of each other and asked questions that helps clear up some ambiguities. More impressive than that is how well our team worked with other teams, we know that class-wide communication will be needed to complete this project and I thought our team asked the right questions to get a good idea of how we will integrate some of the key functionality (like how does the app know that it is offline). I thought that my participation in this was sizeable because I threw out a few ideas on potential ways that we could implement this offline detection functionality.

The most important thing that came away from this sprint was each team coming away with an understanding of the modules that will be needed, a general understanding of how they will fit together, and starting to get a feel for which component in particular they intended to work on. We accomplished this by talking to each other and staring at the code the learn how it works and sharing that knowledge with each other. If we could have done something different it would be going into that deeper level of detail much sooner in the sprint, but now that we know how well this works we will improve on that for the next sprint.

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

Sprint Retrospective 2

During Sprint Retrospective 2, I learned more about the OpenMRS REST endpoints that Ampath uses for it’s core services. I learned more about what the Ampath team is looking for in terms of an encryption service if we are using open source code. In general they are looking for stability: i.e. number of contributors, number of commits, recent activity, any big name (Google, Microsoft, etc), and adaptability. I learned there is a standard Webcrypto that most browsers use as a standard and that we should stick to that standard. I learned more about time planning, and the need to do a better job documenting what we are doing, and splitting up tasks for individuals to work on.

The team worked well, I’m more productive when we are all together going through the code on the projector. It’s nice to have others looking at the same material you are, sometimes they notice things you don’t and it helps everyone on the team learn. I try to participate and offer any tips or advice I might have. I try being prepared for the sprint by trying to understand what is going on and how the services on the application work. I think we need to do a better job documenting everything we do and making sure to share it with those who it might help, with the addition of the documentation thread on slack, it will make sharing that information easier. Next sprint I am going to keep a log of what I am doing, or ideas I have as a personal log to help me organize and write my sprint retrospectives. Now that we have more of an idea what our team should be focusing on, we can start getting into the details of implementing the encryption service and how that ties in with the other functions being added by other teams.

During Sprint Retrospective 2, our team organized our trello board and began to add tasks we thought we could complete during the sprint. We planned on walking through some of the ng2-amrs services, looking into the REST endpoints (with the postman app), checking out Balsamiq, and to coming up with design ideas for implementing an offline service for ng2-amrs. We started our work by walking through some of the services in the openmrs-api folder. We went through some of the endpoint in the OpenMRS Rest Web Services API wiki. We looked into the service that sets a users location, the patient search function, the offline / online indicator, and we began to see how those services work with the front end, and the OpenMRS api that performs a lot of the functions on ng2-amrs. We began to turn our attention to finding out how to implement a service that encrypts and decrypts data. We did some research online for possible solutions and found a few options that we shared with the Ampath team asking for their input: bcryptjs, forge, crypto-js. We are going to look more into forge because it seems to have the most activity.

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

CS@Worcester – Fun in Function 2018-02-28 22:30:35

For most of this sprint, we tried to make progress on coming up with specific design ideas to implement the offline module. We didn’t accomplish much concretely on this front, since generating design ideas was so broad of a task that it left us without much direction. The sheer size of the application makes it difficult to parse. I believe the documentation being consolidated in the new channel about how AMPATH works will be very helpful in the coming sprints.

The concrete tasks we did manage to get done included getting ng2-amrs built on everyone’s computer and getting everyone’s local version connected to the server. We checked out Balsamiq and the wireframes there as they got added. We all read the user stories and their associated tasks.

In our most productive work class, we worked on figuring out how ng2-amrs checks whether it’s connected to the internet. We wanted to see if there was an easy way to know whether an internet connection is available and decide which version of the app a user should see and interact with based on that, for the requirement that transitions between offline and online states should be seamless. We discussed this with the group behind us, and we worked together for a bit searching for the files containing the relevant code and attempting to understand how it functioned. We also tried to decide if we should be constantly checking the status of the internet connection when we write that piece of the offline module, or if there was a more efficient way.

Although writing and submitting abstracts for posters at several events were tasks for this sprint, we ultimately decided not to do them in favor of working on tasks that applied to the application itself.

Our team worked well together this sprint. We all showed up for both work days during the week. We shared information and communicated our ideas and concerns more easily. Toward the end of the sprint, we started feeling that we wanted to focus on the offline login and offline data storage task for the offline module. We discovered on the day of the retrospective that another team had also been focusing on this task. Since they had gotten further than we had on the offline storage aspect, we decided to take the offline login piece of the task. Going forward, we’re going to make sure we have a clear understanding of what work we’re doing in relation to other teams and narrow our focus.

Mostly what I learned during this sprint was the necessity of outside research. In future sprints, I am going to dedicate more time to acquiring the knowledge and skills necessary for the tasks we’re working on. Our path forward is clearer. The AMPATH team provided some links to give us ideas for offline authentication in the google document containing the user stories. I plan on taking a look at them and working on creating something that can successfully encrypt and store a salted password locally, even if it’s not what ends up getting used in the offline module.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Software Capstone Sprint #2 Retrospective

During the second sprint of my software development capstone class, it had a very unique feel to it for various reasons. One of the reasons on why it had a unique feel to it is because my team and I had to create some of our own side tasks in addition to the ones that we were assigned. Considering that this is the second sprint, it didn’t contain that many tasks to do besides getting use to some new applications that were introduced such as Balsamiq which is a nice tool provided by AMPATH.

What I learned in this week’s sprint was learning how to use Balsamiq, learned the fundamentals on how an offline module works, and learned how to map the node paths to understand how the AMPATH server communicates to a router module to fetch patient data. Learning how to map the node paths from the AMPATH code was one of the side tasks that I my team and I wanted to do because we felt that it would put the team as well as the rest of the class in a good position to prepare for what could come next in the upcoming sprints. Keeping that in mind, I think that this portion of work that my team and I are doing can benefit the other teams in the class because the ideas or information that my team and I come up with might be useful to other teams and vice-versa.  Looking back on how I’ve learned these things with my team, I think I did a great job and I don’t see anyway to approach this differently.

The team performance was good and the CATME Team Evaluation in my opinion was accurate.  Everyone in the group participated in all the tasks that were assigned for them to do. My performance fell under the category of completing a fair share of work, if not a little more. I assigned my personal task to be making sure that the team trello board was up to date on what tasks each person should be doing. That will be my personal task moving forward with the upcoming sprints in addition to other tasks assigned to me. As far as it goes for my teammates, they all did well. Rick and Jason contributed heavily in trying to understand the node paths in the AMPATH code. Jeremiah reminded the group to not forget to do the standups that we needed to do on Mondays, Wednesdays, and Fridays. Everyone contributed to the work fairly and I think we established an organized way to keep track on what person is doing, and making sure that they are doing something. I don’t we could’ve approached this differently.

The tasks the got done was reading the user stories for offline modules, and checking out the node paths. The one thing that I would consider that didn’t get done was figuring out the node paths. Although my teammates and I did find how the server communicates and we also got a brief idea on how it talks to the router module, I would consider this task an ongoing or work in progress. The steps that we took to approach this task was that first, we tried to search for patients, but no data returned to us. So that made us think that there might be a connection issue to the routing server in the code. In order to test that theory, we tried to locate the router module in the code, and from that point we made that our task in understanding how the communication between server and router module worked to fetch the data within a database provided by AMPATH. We succeeded in getting ideas from dissecting the code and drew a path diagram in Balsamiq on how might the communication takes place. I would say that we failed in a sense that we couldn’t fully figure how it actually communicates within the time given in this sprint. We chose this course of action by trying to fetch patient data.

Overall, the team and I were satisfied with this sprint. One thing that improved from the last sprint was communication between team members. Everyone knew what to do and everyone knew what each person was doing which promoted quality work.

 

 

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

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

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