Category Archives: openMRS

Capstone: Sprint Reflection 6

Sprint 6 was the final sprint of the semester. We rounded up this sprint with an unfinished solution to issue APTS-254. Over the course of this sprint, we were feeling really good on our understanding of this issue. We required quite a bit of clarification from the Ampath team. After getting some really good clarification we found that the code we needed to work on was in an entire different directory from the one we had been previously working in. Once we finally found where we should be working, we began digging in deep into the issue. The first thing we noticed is that this issue was associated with their ETL server implementation. None of us on the team had previous understanding of what an ETL server was so we I did some digging. I found a few resources online (Here’s a good brief description) that I summarized for the group. The idea was fairly simple, except the way the Ampath team was using ETL was basically by skipping the Load portion and just passing the transformed data to the end user as a notification.

I had a really good understanding of the issue at this point and even began writing some code that I thought might work for this specific issue. Part of the major issue that stopped us from being able to test this solution was the fact that we were unable to test that our solutions actually worked before committing changes. In order to test our solutions we were going to need a running ETL server. In the end I was kind of bummed we weren’t able to resolve another issue before semester’s end. But I felt good in the things I learned from trying to resolve this issue.

I would love to continue working on these issues in the future but with all my personal projects and the fact that I will be starting a new job (as a Software Developer) on the 22nd, I don’t plan on having a lot of extra time. All in all I really enjoyed working on Angular 2 and seeing how a large scale project like Ampath was built.

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

The Software Craftsman chapter 9 & 10

Chapter 9 talks about recruitment, essentially how recruiters should go about searching for qualified developers. One of the problem with finding developers is how recruiters write their job description. Adding things like years of experience, academic background, certifications is how most companies job description looks like. I have done a lot of job searching in this field and i can agree that most of the description are just specific requirements needed from developers. They fail to focus on the companies culture and values and that is why they are not satisfied we developers they’ve hired.

Chapter 10 continues the previous chapter and talks about what to look for in an interview. Just like a job description should not always list specific requirements, a developers resume shouldn’t be just about knowledge and years of experience. During an interview, recruiters should be looking for passionate developers who are willing to learn or try new things. Those are the developers where if you put them in the right environment, they can really shine. One thing i can agree with from this chapter is that developers should interview other developers. A good developer will know what their company needs and what to look for; they will hire developers that are even better than they are.

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

Reflections on Learning and Work Products, Sprint 6

With this being our last Sprint of the year, we wanted to try and get our last issue (APTS-254) dealt with – this issue being the one in regards to the Viral Load Pop-up reminder. However, right off the bat, we ran into more problems that we needed clarification on. We were able to get the code for the ETL Rest Server and looked into. Our team was able to find the file in which the reminders where generated, but we were unsure how to go about coding it. The way that the issues was phrased could mean all we needed to do was make a pop-up appear in Angular, but it could also be that we needed to work on the ETL backend. On top of this problem, we also could not get the ETL server to work locally on our computers. This means that we couldn’t see how the reminders and pop-ups worked, so we couldn’t see the issue or troubleshoot our code to fix it.

After coming to these conclusions, our team decided to message AMPATH for more clarification. A day later they got back to us saying that they would make a test2 ETL server that we could work on. However, we were never able to work on this server due to the fact that our Sprint ended before they could get back to us. I think what I’ve learned from this is that clarification should be addressed at the end of the previous Sprint. That way you can go back into your next Sprint with those problems already resolved, and it gives the team the ability to set fresh.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

Capstone: Sprint Reflection 5

This previous sprint was quite a successful sprint. We successfully had our code accepted into the Ampath project this previous sprint! It took us a while to get the understanding we required for the issue, but once we fully understood the issue it only took the team about a day to come up with a valid working solution. Once we as a team had decided to create a pull request, I went ahead and initiated this task. The biggest speed bump we hit for sure this sprint was getting the fix officially accepted and pulled into the project. The Ampath team had a specific set of guidelines they would have liked us to follow, we were not aware of these guidelines to begin with however. The first thing we needed to do was officially have the Ampath QA team checkout our fix and run it against their test systems. Then once that occurred once more developer was required to test the fix and check the quality of the code being applied to the fix. Once this was done our fix was accepted.

The second phase of Sprint was information gathering for the next issue we are working on. Towards the end of the sprint we received clarification on the issue and we have found that this may be a trickier issue then we initially thought. We are excited to get working on this issue this sprint, because we would like to see at least one more accepted change from out team before the semester’s end.

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

Reflections on Learning and Work Products, Sprint 5

For Sprint 5, our team decided to split into two groups of three people that would each work on their own issue. During this time we also looked into the other issues that were available to us and what we would be comfortable doing. Sadly for a good chuck of this Sprint I was away, but, due to my teammates keeping me up to date on what was going on via Slack, I was able to do some work while volunteering. I found out that they had chosen to work on the issue labeled APTS-254. The description for the issue was stated to be “User are requesting when a patient switches to 2nd Line the Viral Load Pop-up reminder should not pop until the patient has used the 2nd Line Regimen for 6 months.”

After pulling new changes that were made to the code, I started to look into the code and see if I could recreate the issue. I was unable to figure out anything on my end, so, when our group next met up, we tried to recreate the issue. However, we were not able to find where this “2nd Line” was or how to get a “Viral Load Pop-up reminder”. After that class we decided to ask for more clarification on the issue and steps to re-create it. Near the end of our Sprint, we were told that this issue would be found in the ETL Rest Server. After forking and cloning the repository, I tried to get it to work to re-create the issue, but I ran into some issues while doing that. At the start of the next Sprint, we plan to see if our team can re-create this issue in class and then start looking at the Rest Server code to see if we can identify where the problem is.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

Reflections on Learning and Work Products, Sprint 4

For our fourth Sprint for the OpenMRS AMPATH project, our team came together and talked about how to tackle the issue in the Ampath system; which was called NGPOC-185. Since we had already figured out what we had to do, we broke up the issue into sections and told each team member to look into what needed to be done and pick which section they wanted. This took a lot longer than it should have due to snow storms, multiple people being sick, and spring break.

The part that I decided to select for fixing the issue was creating a pop-up box that would confirm if a user wanted to leave a page if they were in the middle of editing a form and pressed the logout button. For this I looked into the Materialize CSS framework that Angular 2 uses. One of my teammates was helpful enough to post this link in our Slack channel so that I could read up on it. However, over spring break, one of our teammates found out that we had miss interpreted the issue that we had been given. Due to this, it seemed that I no longer needed to look into Materialize since there seemed to already be a box that popped up for this. The issues instead seemed to be that even when people pressed logout from a form that they were editing, they weren’t properly returned to the login screen. We had misunderstood because we were on the wrong form page. This realization made the issue a whole lot easier and less intricate than our team originally thought. (Moral of the story always ask for more clarification and find the specific page they found the issue on.

After finding this out, we decided at our end of Sprint review to make it so that only 2 or 3 teammates work on this issue, and have the rest of the team make pairs to pick other issues to work on at the start of the next Sprint.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

Learning Reflection

Our group have reached the end of sprint 2 with a lot of accomplishments. We  are all connected to the AMPATH server and have completed our stories on Trello. This sprint period was a great one for my team.We received the result of our peer review  and it was pretty comforting to know that we’re all content with the team’s progress. We have improved individually and have manage to strengthen our teamwork and communication. During this period, Professor Wurst provide a set of diagrams that shows us how we can successfully manage version control. We forked the latest version of the AMPATH project and cloned it on our computers. One of us has created a remote repository for the AMPATH project so they can pull the latest version for the rest of the team. We also have a TeamOrganization repository where we will have our version of the project with the latest changes.Since we’ve connected to AMPATH, I have edited the project on WebStorm to get familiar with it however, i haven’t made any significant change. For the next sprint our team hope to be writing some Angular and dive into the project.

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

Capstone Project: Sprint 2 Reflections

Another sprint down! This sprint was much more exciting then previous sprints. This sprint we were finally able to get OpenMRS and Ampath running locally on our machines so we could fiddle with it! I have a tendency to probe things I don’t understand until I either 1, understand them or 2 break them. Luckily this time was the former over the latter. Part of our previous sprint was to re-write an Ampath module, specifically the authentication. This was to help us learn how the REST API works and to generally learn how Angular works. We broke our sprint down into a few steps.

  1. Remove all traces of an authentication module from the Ampath directory tree.
  2. Attempt to rebuild a basic html/css of the original Ampath login page.
  3. Creating the Authentication routing so when we visit localhost it will successfully show us the html page we had just created.
  4. Make sure the login button successfully authenticates the user.

These four basic steps were what we felt as a scrum team, each individual could finish in the time we had for the given sprint. Unfortunately for me, because I enjoying coding and learning new things so much, I finished this by day 3 of our approximately 8 day sprint cycle. This left me with nothing to do, but plenty of time on my hands. I took that time to start researching TDD inside of Angular and how to write Karma tests. I really like the Karma framework and the way you simply declare what a test should be doing. I feel that it makes your testing output extremely easy to read, which is especially nice when you are showing it off to your wife who is by no means a software developer. But in the case of the real world, it gives someone A LOT of insight into what your code is supposed to do by them simply running test.

Tomorrow we start Sprint 3. From my understanding we are going to become familiar with JIRA and Ampaths issue tracking, so we can start (hopefully) resolving some issues for them! I am very exciting to be finally diving deep into this project and I hope to make some significant changes!

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

Capstone Project: Week 3 Reflections

Yet another week here and gone. This weeks reflections will be fairly brief due to it being the end of our sprint and having a weekend with nothing to work on. However, we did have a sprint retrospective this week due to our sprint completion! The retrospective went well. Our team has really great communication and that has helped us, so these retrospectives are just re-caps of things we found during the week.

One of the major issues we discussed was with our daily stand-ups. Due to us having to all do them remotely there leaves a lot open for loosely worded statements. We were using a lot of “I’ll try” or “I might get it done” and we wanted to clear up this language and be more precise. We found that two things happened when we became more precise.

  1. Others trusted what we said and knew we were going to get done what we said.
  2. We held ourselves personally accountable to truly get the things done that we said we were going to.

These two things I feel are very important for any scrum team!

We did our first real sprint planning today and I am very excited to start working with the AMPATH code and seeing what true professional software looks like!

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

Reflections Week 2

In the second week of my Software Development Capstone course, we continued on preparations for our team that would help us work on the project. The first thing that we started to do was setup a Trello account for each team member and link the board to our Slack group. This allowed us to then setup Trello so that the team could easily keep up on what everyone was doing in the current Sprint. We made it so our board had lists for “Product Backlog”, “Sprint Backlog”, “Doing”, “Done”, and “Archived Cards”. I found that working with Trello was really easy and quite intuitive for what we were using it for. Once we start the project, everyone will simply just make a card that states what they are doing in the Sprint, and then move it to the appropriate place to indicate how they are doing with it. They can even make check boxes to section out what the task involves and show how their progress is going.

After doing that, each team was instructed to go to the OpenMRS website and create an OpenMRS ID – which I had already done the first week. Once that was finished, we had to then make a short introduction post on the OpenMRS boards saying where we were from, and why were we working with OpenMRS.

The next thing that was on the list was partially setting up our environment so that we could work with Angular 2. It was suggested that Webstorm from JetBrains would work best for what we were going to be doing. After downloading that and playing around for a bit- I was familiar with IntelliJ so I didn’t spend too much time doing this – I found that several people also used PhpStorm and Atom. I decided to download them as well to look into them and see which of the three I would prefer to use for the rest of the project.

The last item that we did for the week was the (simple) tutorial found here. For the most part this tutorial was informative. I was able to understand basics of Angular pretty easily; like the syntax, different imports in Angular, how to do two-way binding, and how to make displays in Angular. However when it came to how to use Promises for data services, the basics of routing, and how to use HTTP services, this tutorial wasn’t great. There would be multiple times where I needed to look that their completed version to see where I needed to make the changes to my tutorial code because they were unclear where the lines went. Sometimes I would even have the exact same code as their working example, but mine would not show. In the end, I decided to just read what they had for the tutorial and look at how it was coded in their working example so that I understood it and didn’t confuse myself further. I think, if I were to do this again, I would just make the tutorial locally and not use the online editor they provided so that I know where the problem is.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.