From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

For Sprint 2 we started to actually get involved with the AMPATH project. The first main task was to actually get the project running. First we forked the project to our GitHub accounts, then we cloned the remote repository to our local repository. If we didn’t already have Node JS installed we needed to download that and install any required packages into the ng2-amrs folder. After that we could run the server with the npm command and have a live AMPATH site running in our browser. Once we had AMPATH running we then needed to download the openMRS standalone and connect AMPATH to it. In order to connect them we needed to update the server settings on AMPATH to the standalone server and add some code to a web XML file. Connecting AMPATH to the standalone allowed us to successfully login to AMPATH with access to a mock database. As simple as these tasks sound it was far from an easy setup. At least in our group it took us all several attempts and some troubleshooting to successfully get AMPATH online. We had server errors, issues getting the standalone to run, and version compatibility problems. Each team member basically had to work through their own list of issues to get connected. Aside from the effort of getting the project up and running I completed a good Angular 2 beginner’s tutorial on thinkster.io. I thought it was a better introduction to Angular 2 and I definitely feel more confident with the framework’s fundamentals. To finish off the sprint I started browsing the AMPATH source code. It is a bit overwhelming but I think the more I review the better I will understand. The biggest learning curve is learning the complexities of Angular 2 syntax and the module style development. At the end of the sprint I thought our team retrospective went pretty well. This was another sprint where all the tasks had to completed by each individual so it’s hard to really judge the team’s effectiveness. Overall we are all completing our individual tasks and helping each other as we move through the sprints. Looking into the next sprint it looks like we will be re-writing a module and working on some known AMPATH issues. This should allow us to make our first true contributions to the project and tracking issues will improve our knowledge of the code base.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

What we did this week in Capstone. This week was more of an experimentation week, more playing around with the codes. The main concern for this week is to get everybody up to date so that everyone can run ng2-amrs with 0 problems.

1. Make sure everyone can run ng2-amrs and be connected with either openmrs standalone or the openmrs SDK.

We ran into some major issues with one of our team member unable to get openmrs server to run properly no matter what. It even went as far as reformatting the laptop but the issue still popped up. We may have to ask the OpenMRS community for help on this critical issue.

By next sprint we will have JIRA tickets set up and have minor issues to fix within the OpenMRS project. Hopefully that let us focus on a small part of the large network of OpenMRS modules. This will let us become more familiar with the code also.

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

Overall sprint two went well. Our basic Trello tasks were completed which included setting up, connecting, and building our APATH login. The main issue that arose with connecting to AMPATH was the server on the site; it wouldn’t allow any user to connect normally. Therefore either the user could download a chrome extension, which for some of us caused our Wi-Fi to crash, or add a code snippet to one of the xml file. Option B proved to be the more promising choice that most of us went with. Some of us were able to begin rewriting some of the module, nothing too special yet, but it will still be placed onto the backlog of the next sprint.

A big part of our retrospective was that we realized our communication and teamwork has been rather poor. Up to this point, the majority of the work has been done independently which we believe to be partly caused by nothing has been too extreme or challenging that we have had to collaborate on, but nonetheless we are looking to improve in those aspects come the next sprint. On the other hand we have had some issues with attendance and participation in daily scrums that we addressed and hope will be fixed for the next sprint.

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

Chapter 9 “Time Management” revolves around the different strategies we can use to ensure the proper utilization of time by effectively managing it. Author Martin fist discussions about meetings. He argues meetings are necessary but at the same time they might huge time wasters. He suggests be very careful about which meetings you attend and which you politely refuse. When the meeting gets boring, leave. If you find yourself stuck in a meeting that is not a good use of your time, you need to find a way to politely exit that meeting.
Next big thing in this chapter Martin discuss is about disagreements. He believes without data, any argument that doesn’t forge agreement within a few minutes simply won’t ever forge agreement. The only thing to do is to go get some data. The question arises how do you get the data you need to settle a disagreement? Sometimes you can run experiments, or do some simulation or modeling. But sometimes the best alternative is to simply flip a coin to choose one of the two paths in question.
Furthermore, Martin goes on to lists some intellectual exercise that helps build concentration and focus. He talks about the pattern of his sleep; the caffeine he consumes; the way he recharges himself by taking naps, meditations, and muscle focus. Never the less he explains how the well-known Pomodoro Technique, shortly knows as tomatoes, manages his time and focus.
This chapter,to sum up, was very much productive to me. I often find myself falling in the trap of priority inversion. I find ways to avoid doing the real work. I convince myself that something else is more urgent, and I do that instead. As the writer suggests from now on wards, I will try to evaluate the priority of each task, disregarding my personal fears and desires, and execute those tasks in priority order as best as I can.

 
Next chapter “Estimation” is about takes on estimates in different ways. Martin defines the term estimate in terms of business and developers point of view. He states business likes to view estimates as commitments. Developers like to view estimates as estimates. Furthermore, author describes the different techniques to make estimations such as wideband delphi, flying fingers, and planning poker.
The biggest takeaway from this chapter to me is to be more precise in my commitment. I will not commit unless I know for certain I will succeed.

From the blog CS@Worcester – Software Dev Capstone by osworup007 and used with permission of the author. All other rights reserved by the author.