Monthly Archives: March 2017

Sprint 4

Coming back from spring break not much was done on my end regarding issue 184. However, our team have decided that each member should pick there own issue to solve. After I’ve updated the module from the team’s repository, i came across an issue and couldn’t connect to the server. Because of that, i spent some time trying reconnect to the server. I received help from Haider who was familiar with this problem.

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

Sprint 3 Retrospective

During this sprint i spent most of my time navigating through the ng2 module to get a strong understanding of it. Our  team spent time solving  issue NGPOC-184 and unfortunately we did not finish on time for the sprint. For me personally, i need to get a better understanding of Angular 2 to actually contribute significantly. Since this is a senior level course, we are given a lot of freedom with the expectation that we would be responsible enough to learn, communicate, and produce meaningful results within our groups. However, that is not the outcome of our team as a whole. We are about halfway through the semester and it’s not to late to pick up some of the slack.

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

Clean Coder 11 & 12

Chapter 11: Pressure

Chapter 11 is titled pressure and well it is quite straight forward. Every person deals with stress,  and all professions have a certain degree of pressure thrust upon them and being a professional Developer is no different than those other professions. The key in life is to learn how to be cool and clam under pressure. One great way to deal with presser that is detailed in the book is to properly assign your time as to allow for time to deal with crisis if it comes up. Another thing is to code cleanly (which was the title of the last book he wrote) Yet another way to deal with a problem of disaster proportions is to pair up. This is a useful technique to quickly and efficiently quiet the problem.

 

Chapter 12: Collaboration

This category is one of the ones that I feel like I need the most amount of help in, Collaboration. I definitely am one of the programmers who would like to work completely alone. I feel as though I could be more efficient by myself. But, This is not a good habit ad most of programming stems from collaboration with others. Some of these are clients and business people who know more about the situation you are coding for than you might. Therefore it is most beneficial to collaborate and communicate with other around you get the best end product that you can. Collaboration could even prevent future disasters that you have previously not even thought about.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

The Software Craftsman 1 & 2 Week 8

The first part of this reading started out by saying you should be in the field that you enjoy. Just because you make more money doesn’t mean it’s meant for you. Another point was made that just because you’ve been coding for a long time does not make you a senior coder. It all depends on what you’ve been working on and the diversity of your skills that makes a senior coder.

The next part of the reading focuses on companies being agile. It takes about how being competitive means delivering software faster and with better quality. Most companies end up making this all about their process and tools. Just because a company practices agile ways does not mean they will improve. The most important part is hiring developers that can handle this and can make it happen, without these developers that have mastered these process and tools, then it will not improve the product or speed.

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

Sprint 4 Reflections

In this sprint we were given actually issues to fix for AMPATH. We were also introduced to JIRA which is a tool to help organize bugs and issues that need to be fixed. It also helps organize who is working on what issue. After getting used to JIRA we were assigned an issue as a group. We worked on this issue but could not find a solution. JIRA is a very helpful tool to organize issues and bugs. The only thing I would change about the last sprint is trying to work on bugs together more than independently, I know this is an issue because we do not have much time in class but it would be ideal.

From the blog CS@Worcester – Software Testing by kyleottblog 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.

Sprint 4 Reflection

This sprint started off well, then we experienced how the description of an issue don’t always convey the full story. Our team “finished” what we needed to do on the issue that started in sprint 3 and carried over to this sprint. The issue we chose had to do with the location of a button on the screen. The description read, “Users are requesting if the back to drafted form button can be moved to a more convenient place for easy navigation e.g near the control menu.” With this description in mind one of the team members moved the button. I then merged the change with the latest version of the AMPATH project, set up Travis-CI, and deployed the change. After program built on Travis-CI we put in a pull request. We received a response the next day stating that they would actually like the button to stay in a fixed location on the screen while scrolling like the top bar and side bar. I believe this was a good example of the importance of communication

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

Capstone Project: Sprint 4 Refelction

This sprint reflection will be a brief one. Unfortunately for the majority of this previous sprint (8 or 9 days) I was sick. I was so sick I couldn’t really move off the bed. So unfortunately I missed out on almost the entire sprint. My team was very flexible with me being down and they were able to work around that.

Once I started feeling better I began playing some catch up with the group, communication to me teammates to see what I’ve missed and figure out where they were at. We are working on an issue in the Ampath system (NGPOC-185). Initially when we took the issue we assumed we knew what the issue was talking about. However, after I started feeling better I started testing some things out in the Ampath POC system. What I found was our initial thoughts on the issue were completely wrong! This was extremely unfortunate because the team had put in a lot of time to find a good fix to what we thought the problem was. The lesson learned here for sure was; if there is ANY doubt in your understanding of an issue, get clarification!

We concluded our sprint with a retrospective. The main thing we discussed was our failure in this area, and how to avoid this in the past. We also discussed how we were going to make up for lost time. So moving forward we’ve decided that we are going to work in pairs. The issues seem to be easy enough that 6 people to 1 issue is overkill. This should allow our team to move forward and begin progressing and be able to increase the velocity of our scrum group.

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.

Sprint 4 Reflection

In Sprint 4 we finally got our first issue assigned. Unfortunately, our first issue (NGPOC-183) was rather difficult. It took us several days to try and understand how to tackle it and we ended up not being able replicate the problem on the test server. We had posted questions on the issue in JIRA and reached out to the developers on Slack but were not able to get any clarification or guidance. Although this issue has been a dead end so far I did get gain some knowledge in the code base and have better understanding with how the location feature works in the AMPATH dashboard. Right before break our group decided to take on a new issue (APTS-296) but we have not made much progress with it yet. Aside from our issues in JIRA pulling changes from the AMPATH repo as a remote upstream always seems to create a lot of conflicts and problems connecting to the test server. It hasn’t been anything we haven’t been able to work through but does slow progress down. We find it better to pull in changes frequently to make sure we are up to date and our changes will cause as little conflict as possible if we can get to a pull request. Looking back at the last sprint we did what we could for our first issue but the lack of further guidance slowed us down and kept us from any measurable progress. Looking forward we hope to make considerable progress on our new issue and move towards our first pull request. As of right now the team is still working well together and we aren’t going to adjust our velocity for the next sprint.

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

Sprint 4 Retrospective

Sprint 4 was, I think, more productive than the previous Sprints. We actually got the NGPOC-184 issue solved. And I am thinking of picking one more issue to work on. So after this semester, hopefully, we as a team would have solved three issues.

The problem I had throughout this and previous sprints is that we are moving at a snail’s pace. The reason for that is we are all new to Angular and some of us are not able to learn Angular fast enough or not able to put in more time. It is very fustrating that we are moving so slowly. One issue in 2 months? Wow!!

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.