This Sprint, we got everyone on board with AMPATH test2 server and checked out the code issue that was assigned on JIRA. It was interesting that we spent a huge amount of time trying to get standalone server to work and then it became useless as we transition to the test2 server.
We have an interesting issue on our JIRA issue in that we are unable to reproduce the error that was given to us. The JIRA issue was that a randomly typed location can be typed in and saved. When we tested with the test2 server, the location if randomly typed cannot be saved. I have commented on the JIRA ticket asking for clarification on this issue. Meanwhile, we are all just studying the code base for further understanding of the entire AMPATH system.
The last two chapters of the book talked about teams and also mentorship. The book talk about forming team first then assign the project to that team. Doing the opposite is foolish since you are not sure if the team members can mesh together properly and will work way less efficiently than a team that knows each other.
It’s interesting since in school, many times you don’t get to pick your own team. So you end up first getting to know what everyone’s strong and weak points are, try to work around that. It can be incredibly cumbersome and inefficient to work through that. Of course the stakes of a large company project and a school project is extremely different.
In the last chapter, the book talked about mentorship and craftsmanship, where in the end it goes, school can teach you about theory, but schools cannot teach you discipline, practice, and skill of being a craftsman. In reality, experience truly trumps over everything else.
In chapter 12 of Clean Coder, the book talked about collaboration. In the end, the book said that”Perhaps we didn’t get into programming to work with people. Tough luck for
us. Programming is all about working with people.” This just goes back on how communication is one of the most important thing for being a programmer.
Unless you are working on some passion project and is the sole developer, chances you are going to work in a more corporate setting. Knowing the social norm there is important. Meeting the deadline set by your boss is extremely important.
Not only with employers, working with your fellow programmers can be extremely difficult also. You have to talk to fellow workers to understand their section of the code, especially on huge projects. You have to talk to others to make sure you don’t have redundancies on the project. You might run into issues if office politics come into play. However, collaboration is extremely important to being a programmer.
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.
- 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.
Chapter 9 and 10 of Clean Coder talks about time management and estimation. Both of these issues goes hand in hand. Meetings are abundant in workplaces and it can lead to huge amount of time wasted that could be better used to focus on the project. Of course you need meetings to keep track of progress, give updates of project status, and check if the project is on track with expectation. The key is to find a balance between those two.
Time estimation is something every project faces. The book gives good advice on one should make probabilistic estimate unless they are absolutely sure they can give a hard number of the time it takes to finish a task. In the real world this goes way less smoothly. Many projects even if you are confident in your own ability relies on many other people from different teams, department, and even other companies. You can give an estimate that is only as good as if other people also make their estimate. That is an important key to keep in mind. Sometimes, even when making probabilistic estimation, upper management may want certain goals to reach by a certain deadline. This lead to anything from crunch time to unexpected delay in other task. Practical estimate is good advice, but sometimes it just does not match the practical reality.
This week in capstone, we dig deeper in the OpenMRS project.
The steps we did this week
- Forked the openMRS git repo
- Got ng2-amrs to build and run
- Installed ng2-amrs standalone back end
- Looked over how the ng2-amrs authentication system worked
People initially had issues with setting up the system. This was actually an issue with multiple OS. People where using OS bash, Node.JS terminal, Bash on W10, and Git Bash. People were confused on what to use at first and we had to clear that situation up and also the different IDE people were using.
We tried to get an understanding of how the entire system works. Initially we set up the front end of the system but was confused on how we get the login system to work (the back end system). It wasn’t until some noticed that there is a standalone that is needed for the back end system that we realize that is actually where we auth.
Although we got everything to work in the end, the steps could’ve been made smoother if everyone was using the same OS and IDE so there’s no differentiating the set up process. Obviously this is much harder to do in a school environment, but having to trouble many different IDE and OS set up can be very stressful especially if a much more complicated project comes up.
Also people speaking up in a team environment is also key, not realizing we needed a back end, we fumbled around confused on how they got auth to work. Until one person spoke up about the back end and then we got confirmations from outside the team on how the entire thing worked.
In Chapter 7 of Clean Coder, the book talked about communication and situations such as premature precision and specifying interface. In my opinion, the most important thing is communication bar none. I have faced situations like described in the book where Business side wanted exactly this but it wasn’t possible due to technical issues. There were also cases where there are multiple departments that want different things, where you end up having conflicting reports on what to do.
Many time in those experience, you end up either doing extra work that was not necessary at best, and at worst missing a key feature that the client really wants. You end up wasting time on features not needed and then crunching before the deadline to get what is needed done. It is imperative to get the full communication down and get everyone on board. The acceptance test, or QA is important here since it serve as an end goal and checklist to get the details and specifications right.