Monthly Archives: March 2017

Sprint 4

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.

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

Reflections (3/8/17) Week 5

This sprint has definitely been a busy one. After everyone got the programs downloaded and the server accessed, everyone was waiting for their invitation to the JIRA tracker for AMPath so we can all get ready to work on bugs. Before the bug tracking, we had an open conference online with developers of AMPath where developers were talking about different projects they are working on such as rewrite code to angular 3. It was after the conference that we start focusing on the bug tracking. I was one of the first ones to get an invite to the tracker so  I set up my account and showed off the tracker to my team. We did not know what bug we were going to work on but we were told that everyone will get to pick in the next class.

Eventually, after a coin flip and discussing among other groups, we decided to take the issue in the tracker known as AMRS-287, which was an issue that wasn’t really priority to address but would have been nice to take care off. The issue in detail was to find the “return to draft button” when navigating the forms and then move it to a more convenient place. Originally we thought it was an easy thing to do, but it was a bit more involving than we thought since we ran into some difficulty. First and foremost we had trouble finding the button. This took the longest portion of the sprint. We knew that we had to go to the locations where the forms were located to find the buttons but the links to the forms would not open for the life of us. We did not know what was happening, let alone we tried other servers as well to see if it worked and they did not.

Eventually I contacted Johnathan Dick through the tracker and he said to use the same test server we were using to find the button and edit the code. We tried again the week after, and then Kyle managed to find it after managing to access the forms. This was strange but the forms were accessed this time around. We debated where to put the button, and we decided to put the button near the task bar either above or below the vitals. We did not decide on a final place just yet but we will soon and hopefully take care of that button.

Other than the button issue, we have to address team behavior in regards to lateness so we are going through that as well, and that is to be continued.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

The Clean Coder Ch. 13 and Ch. 14

This week I read the final two chapters of Robert C. Martin’s The Clean Coder.  These chapters were not very long and only covered a couple topics.  In fact I only took away two points from chapter 13 on “Teams and Projects.”  These two topics were on the “Gelled Team” and “Velocity.”  A quick overview on Martin’s “Gelled Team” is a group of about twelve programmers, testers, analysts, and one project manager, who have worked long enough together to develop a symbiotic relationship.  I have worked closely with a few students during my time at WSU and we have certainly developed something close to what Martin described.  I know how these students think and work, and it aligns well with my process.  Martin describes “velocity” which my group and I have been experimenting with and adjusting as we figure out how much work we can accomplish over our sprints.

Chapter 14 was entitled “Apprenticeship, and Craftsmanship” which focused on the idea that school does not prepare programmers for the field.  To be honest I am concerned that I have not accrued enough knowledge to be an effective programmer in the field.  Martin suggests a system in which there are Masters, Journeymen, and Apprentices, where the more experienced teach the less experienced.  I like this idea, where for the first year, the Journeymen teach the Apprentices, and over time the Journeymen become Masters who orchestrate the entire process.  Martin also discusses the idea of Craftsmanship, which he calls “a mindset of values, disciplines, techniques, attitudes, and answers,” which are handed down from the experienced to the inexperienced.

Well that wraps up, The Clean Coder.  Stay tuned for more posts starting next week on a whole new text!

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Learning Reflection – Sprint 3

I was studying the ngpoc-184 issue and I figured there are basically two modules that we need to work with: clinic-dashboard and main-dashboard. I also found a few questions in stack overflow useful in helping us develop the feature requested. We did not do anything else during this sprint.

I wish we could move faster as a team and take on more issues, but everyone else is still learning Angular 2 so we can’t move any faster.

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

Sprint 3 (2/23/17 – 3/7/17) Learning Reflection Blog

To be honest, out of the 3 sprints that we have already gone through, this sprint was probably the most unproductive. It might have something to do with the fact that this last sprint only consisted of about one user story; which was fixing the NGPOC-184 issue but nonetheless, it just didn’t feel as though anyone in our group (sadly, me included) made any progress. I think this might be because the class in general is too loose. We have to do check-ups on Scrum every other day but besides that, there is nothing forcing us to do the work. We could be saying we are doing something but there is no way of enforcing or checking that. For me personally I need to spend more time and focus on learning Angular 2 because its discouraging when I look at the code because it doesn’t all make sense to me.

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

The Clean Coder chapter 13&14.

We have reached the final chapters of the book. The last two chapters talks about teams, projects, mentoring, apprenticeship, and craftsmanship. Even though these two chapters are very brief, there are a lot of important facts and key points that we can take into our careers.

The first chapter talks about working in teams that will sometime consist of programmers, project managers, analyst, and testers. The book explains a concept called “gel” where each members of the team learn each others weakness, strengths, and quirks. It can take a really long time a team to really gel. I can relate to this because i work in teams all the time during school and we don’t always work effectively during the beginning stages. This why a team working on short projects that requires a portion of your time never really learn how to work with each other efficiently. And this is why it is important to form the team before the project; the collaboration will be much more effective depending on the teams experience with each other.

The last chapter of the book starts with the fact that it easy to wiggle through the system and graduate with a degree in Computer Science. Nowadays, Most of the curriculum doesn’t really prepare students for what they will face in the industry. It is important to have a mentor with years of experience working as a software engineer that can teach us what to value and how to behave. This chapter separate programmers into three categories master, journey, and apprentices/interns.  Newly graduates should always start as interns or apprentices. From there they can learn, grow, and gain experience to work on complex projects.

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

Sprint 3 Reflection

In sprint 3 we got more involved with writing code for AMPATH. Basically, each group member tried to write the authentication module from scratch. I was able to write about 50% on my own but needed to do a lot of verification with the working module. This was about the level of knowledge for the whole group. Our definition of done for this task was to just do as much as we could on our own and use the working module for assistance as needed. We decided on this because we need to be moving forward with more meaningful tasks. Also during this sprint, the AMPATH developers added a new test server for us to connect to for running an AMPATH instance. This was very helpful because we were constantly having issues with the openMRS standalone and its server. The whole group was able to connect to the new test server pretty quickly and it has not given us any trouble since. The last major task for this sprint was creating our account and getting logged in to AMPATH’s JIRA system. This system is used for issue tracking and with an account we can assign ourselves to specific issues. Our group was assigned one issue so far but we weren’t able to nor did we plan to get to it this sprint. Overall our group had a successful third sprint. We were able to get the tasks we committed to done and our knowledge of the AMPATH code base has been getting stronger. The only thing our group needs to improve on is our daily scrums in Slack. We have great communication in class and everyone is doing their tasks but we are struggling to communicate our progress outside of class time. I believe in the next sprint communication will be easier because we will all be working on the same issue. Up until now our tasks have been individual so working together has only been necessary if we get stuck on something. In conclusion another strong sprint for TeamLoading.

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

The Clean Coder (Chapters 13 & 14)

Chapter 13 of The Clean Coder discussed the importance of being able to work in a team, the right way.  Having the ability to work well in a properly formed team is very important in life, and especially as a computer programmer.  This chapter talks about something the author calls, a “gelled team”.  A gelled team is basically the idea that all team members will learn each other’s quirks, strengths, and weaknesses; which will then lead to the team beginning to “gel”.  As a team you need to work together and be aware not only of yourself, but also everyone else on your team.  There is no “I” in team!!  This chapter goes on to talk about how a good team will take the time needed to “gel” so they can progress and get as many projects done as smoothly as possible.  A gelled team is not formed around a specific project.  The author describes a gel team to have the ability to “accept many projects simultaneously and will divvy up the work according to their own opinions, skills, and abilities.”  I agreed with this chapter and agree 100%.  From my personal experience, being in a team that works well and fluently together has always been a much more successful experience then being in a team where everyone is kind of off on there own, and not communicating with one another.  It was interesting that the author talked about the idea of not forming a team based off of a project, but forming a team based off of being able to finish anything.  I really liked that idea, and it’s something that I personally have not seen in the workplace.  In my software engineering internship, the teams were mostly formed around a specific project.

The last and final chapter of The Clean Coder is chapter 14.  The final chapter of this book definitely summed up a huge aspect of what it truly means to be a computer programmer.  The whole point this chapter made was that school can of course teach you the theory of computer programming, but it will never teach you the discipline, practice, and skill of being a craftsman.  School is very helpful in getting the main idea of what you will need to be doing as a computer programmer.  School will teach you a lot of technical things like design patterns, algorithms, and how to code in general.  It is very important to know these technical and theoretical things as an engineer.  The chapter goes on to discuss that after we graduate from school and our on our way to the workplace, we are now the new mentors and guidance for the next generation of computer programmers.  When you are in the workplace you need to have the knowledge to be able to mentor the younger developers coming in.  As computer programmers we need to realize this is our job and soak in all we know now so we can later guide others.  You should pass your craftsmanship down to the younger people so they too will have the knowledge we have.

From the blog CS@Worcester – Alex's Comp Sci Blog by alexsblog13 and used with permission of the author. All other rights reserved by the author.

The Clean Coder Chapters 13 & 14 (2/28/17 – 3/7/17)

I can’t believe the book is finally done! I was kind of disappointed to know that there are no more chapters left in the Clean Coder book. I enjoyed reading it. For the most part, the last two chapters weren’t as “exciting” but there were a good amount of key values that I agree with in those chapters. One of the most important concepts I really want to emphasize is the idea that it is the responsibility of the masters and journeymen to teach the newer apprentices the correct ideologies and give them the experience they need to grow. That is the only way good software practice will survive; its if it is being correctly passed down from generation to generation. So in summary, what you learn in school and what you find in the real world are two completely different things and you need the right experience and mentor-ship to guide you through it

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

The Clean Coder Chapter 11 & 12

Chapter 11:

This chapter gets into the topic of doing what you are supposed to do, and what you’ve learned to do, even under pressure. Your training and experience has taught you to be calm and decisive and use your time wisely. It is also controlling and avoiding this pressure so it doesn’t become a problem in the first place. I personally sometimes have trouble doing this because I am very driven by the deadline, being under pressure helps me complete my work on time and drives me to finish what I have to do. But I did read that it would be best to avoid situations of pressure, to try to spread it out over a longer period of time to lessen its stress. It also talks about commitments and how they shouldn’t be made if they seem unrealistic, and the risk should be shown to the business to they can manage it the right way. It also talks about how you should make sure that there are no messes in your code, and you keep it clean. Most of all, do not panic, because worrying about it will not help you in any way, just take your time and don’t rush your work and follow your disciplines. If all else fails, go to a team member.

Chapter 12:

This chapter talks about how most programs and software are made in teams and that it is more professional to work in teams rather than a loner. Collaboration is one of the most important parts of programming. Even though sometimes it might be hard to get along with someone who isn’t really in your social circle, and you might even like to work alone, be focused all by yourself with no one to bother you, it is much better to work with people because you see the same problem from different perspectives and be able to solve issues you might have missed working by yourself. But with advantages come disadvantages, you should always make sure you know what the people who pay you are thinking and what their goals are. Your most important needs are to meet the needs of your boss. This means you would have to know all that is going on around you and interact with managers, analysts, and other team members. It is important to support everyone around you and keep your business afloat, and to do this you need to deeply understand everything that is going on around you, including your short term and long term team goals. You should always make sure that the code you are writing is accessible to the whole team and not just you, everyone needs to be able to work on it and make changes, not just you, and that is how you learn from each other. Sometimes pairing is the most efficient way to solve problems or debug. I understand this because most of the times if I ever get stuck on anything I always go to someone for help.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.