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

Finally we completed our 3rd sprint. The good news is I was finally able to fix the “Unable to start OpenMRS”. It was to do with the path with spaces problem. Just removing spaces from the folders where the standalone was extracted fixed the issue. On the other hand, the not so good news, is we don’t need OpenMRS standalone anymore since we got AMPATH test2 server to work on.

Moreover, this week we got chance to to take part in online conference with developers of AMPATH. It was exciting to listen about the improvements and changelogs they did with the project.

The main task for the sprint was to get connected to  AMPATH JIRA system and fix NGPOC-183 issue. The bug behind the issue was “After login it allows free text when selecting location and saves successfully.” But when we tried to reproduce the issue, any free text such as ‘blablabalba’ did not saved that it a location. One of our team mate has posted for more classification. We haven’t received a reply yet. In the mean time, I am going through the AMPATH code, particularity the modules that has to do with our issue.

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

Chapter 13 “Team and Projects” discusses about team management and its formation. Martin suggests it is better to form persistent teams that move together from one project to the next and can take on more than one project at a time. He conveys the concept of a gelled team. The team members begin to frame connections. They figure out how to work together with each other. They take in each other’s characteristics, qualities, and shortcomings. In the long run the group starts to gel. Ultimately, a gelled team plan together, solve problems together, face issues together, and get things done.

I sense more confident in my work while I am working with the same person over and over again. We get to know each other opinions, skills, and abilities. It’s better to know the person with whom we are working at a personal level. It helps to form friendships.  When managed properly, I feel teamwork always is a better way to work.

The next and the final chapter of the book “Mentoring, Apprenticeship, and Craftsmanship” revolves around some of the key information that we might face in the real world after being a CS graduate. I feel this was the perfect chapter to end the book. Martin believes in adapting a program of apprenticeship rather than just learning the theory of computer programming in schools. Furthermore, author also introduced a system of masters, journeymen, and apprentices. He summarizes after apprentices knows know design principles, design patterns, disciplines, and rituals; if the masters agree, then the apprentice becomes a journeyman.

I do feel it’s all about years and years of hard work and experiences. Once we stepped into CS field we should always be learning and be willing to grow our skills.

Ultimately this post brings to the end of the series. Looking forward to read another exciting book.

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

In chapter 11 “Pressure”, author Martin, talks about various ways of avoiding and handling pressure. He suggests that the best way to stay calm under pressure is to avoid the situations that cause pressure. It is equally important it is important to avoid committing to deadlines that we aren’t sure we can meet. Another way to tackle pressure is by staying clean. It helps us to avoid pressure by keeping our systems, our code, and our design as clean as possible. Furthermore, author relates back to TDD disciplines. He suggests to choose disciplines that you feel comfortable following in a crisis. Then follow them all the time.

As being a computer science student right now, I get a lot of pressure. I need to go through sleepless nights in order to catch up my schedules and deadlines. Rather than panicking much by taking such stress I will now trust my own disciplines and try to stay clean with my projects. I will also be getting help from my teammates whenever I feel I needed support.

The next chapter is titled as “Collaboration”. Martin summarizes that programming is all about working with people. We need to work with our business, and we need to work with each other. Personally, I think the best thing about in working in team is we get to learn new techniques from our teammates, and of course we get help when we get stuck.

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

This sprint first thing we did is basically created our team organization called “Teamloading” on Github and then cloned the copy of ng2-amrs project from our organization. This way we all team members have own copy to work on, and any changes we did we be handled and review by our organization as a whole before pushing the changes to the actual AMPATH project. The same Github workflow designed by our Prof. Wurst is given below:

Next thing we did is build and run the ng2-amrs. While running the project we also needed the openMRS platform which is basically  a back-end system, with a database and APIs. But I was Unable to start OpenMRS , so I posted the issue on the openMRS talk forum. The screenshot of the issue is given below:

As of now I am still getting the error.Error thrown was: org.openmrs.api.APIException: Service not found: interface org.openmrs.scheduler.SchedulerService. The link to the page is listed below:

Issue: Unable to start OpenMRS

Hopefully experts over there will be able to troubleshoot soon.

This sprint I also looked over the code in the authentication module of the login page. Furthermore, I also looked over Angular 2 tutorials online.

From the blog CS@Worcester – Software Dev Capstone by osworup007 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.

In the 7th chapter “Acceptance testing” author Martin discuss about the communication aspects between programmers and stakeholders. Then he drives into the essentials of having acceptance tests to narrow the communication gap. Martin argues that in reality, the communication of requirements is extremely difficult. Because of which both programmers and stakeholders often falls into various miscommunication traps such as premature precision, estimation anxiety, and late ambiguity. Then Martin suggests a solution: is to write automated acceptance tests. Acceptance tests helps to define when a requirement is ‘done’. Due to cost reason acceptance tests should always be automated. Professional developers should take responsibility for their part in ensuring that acceptance tests are automated.

Furthermore, Martin clearly states acceptance tests not being the same as unit tests. Although they may test the same things, they do so through different mechanisms and pathways. Unit tests validate the system from the developer’s point of view whereas acceptance tests validate the system from the business and QA points of view.

Moreover, the chapter talks about the challenging to write acceptance tests for GUI. Alongside suggests the solution to design the system so that you can treat the GUI as though it were an API.

I personally know how to write unit tests as being a programmer. I don’t have any experience as of now as a stakeholder. From my part I will definitely make sure that the tests are fully automated and easier for non-programmers to understand. I will specify all the details during my testing phase for the stakeholders to ensure that the system they are paying for really does what they need.

The next Chapter “Testing strategies” revolves around the disciplines of Test Driven Development. Author explains about unit, component, integration, system, and manual exploratory tests. The test automation pyramid diagrams summaries the concept of those test. Author argues that unit tests provide as close to 100% coverage as is practical. As good as it is to have a suite of unit and acceptance tests, higher-level tests are needed to ensure that QA finds nothing.

I am not exposed to any other tests rather than unit. I will definitely work together with QA team to ensure the quality of the system.

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

This week we finished our first sprint. We did our first sprint review and sprint retrospective as well. We used various factors such as Attendance, Communication and Cooperation to rate each other’s performance within our group members. 1 point was given for needs improvement, 2 for acceptable, and 3 for excellent. We all received pretty good average on this one, considering there was nothing much heavy to do on our first sprint.

Looking forward for the next sprint.

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

In the 5th chapter “Test Driven Development” author Martin discussions about the use and benefits of TDD. He puts the three laws of TDD up on front, and relates them back and forth in the entire chapter, as:

1. You are not allowed to write any production code until you have first written a failing unit test.
2. You are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing.
3. You are not allowed to write more production code that is sufficient to pass the currently failing unit test.

Begin by writing a small portion of a unit test is a first step to implement. The next step is to make the unit test fail to compile by releasing there’s more code to be written. And then write the production code that make the test compile. Be that as it may, you can’t compose any more than that, so you begin composing more unit test code.

I find the whole TDD concept a little but complicated and time consuming, since I have only written test cases for small size code. I do agree, after reading the chapter, adopting TDD as a professional discipline enhances certainty, courage, defect reduction, documentation, and design. I will be looking forward to use TDD as our project progresses.

The next chapter “Practicing”, is about the ways in which programmers can practice their coding art. Martin lists several kinds of activities which helps developers practice coding that take place in a dojo such as Kata, Wasa, and Randori. They helps to broaden our approach and improve our coding skill. Most of the times we programmers are too busy writing code to think about practicing skills. We spent much of our time waiting for compiles or debugging long codes. But we should always be willing to practice in order to keep our skills sharp. I completely agree with the author. I find myself practicing and improving coding skills just by playing coding related games. From now I will also be engaging my leisure time to participate in testing and also code reviewing open source software that helps me to learn how to apply TDD, and single-responsibility to track an overwhelmingly large project.

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

Second week was mostly spent on setting up the required environment and resources for our project. We also started learning Angular 2.

We created Trello accounts and then our specific Boards. Trello looks very promising for recording our groups Sprint Backlog, Doing, and Done lists. We also integrated the Trello bot into our Slack channel through which we can get direct notifications for the cards going around. Moreover, we introduced ourselves in OpenMRS. We also setup WebStorm IDE from JetBrains. While using android studio I was quite familiar with the UI of IntelliJ IDEA, which is also a product of JetBrains.

In the course of learning Angular 2, we specifically did the Tour of Heroes tutorial that covered the core fundamentals. Overall it was fun to build the complete working app.

Looking forward to learn more on Angular and run WebStorm.

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