Monthly Archives: February 2017

Week 5: Reflections on Learning and Products

This past week I focused mainly on getting the standalone server to connect to the login page properly.  I currently am having an issue where it it saying I have the incorrect password/username.  I’m not sure why this is happening but I plan to ask some of my teammates for help next class.  I did however get it to says that the server is online, which was my main goal.  The next step I am going to take is diving into the code itself and trying to rewrite an existing module from ng2-amrs.  I plan to focus more on the code, rather then just getting the program to run.  Angular 2 is still really new to me, so I want to do some more tutorials before I actually change anything in the code base.

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 11 & 12

Chapter 11 covers the topic of pressure at work and how to handle it. The first piece of advice is to try to avoid pressure to minimize the time spent under it. The author reminds us that we are not bound to commitments made by the business on our behalf. We have an obligation to do our best for the business but the ultimate responsibility comes down to the person making the commitments. Next the author mentions to always keep code clean to avoid any mess. Messy code always slows the process down and creates headaches in the future. After the tips on avoiding pressure, the author goes into handling it. The first piece of advice is to stick to your disciplines and maintain your professional behavior. He mentions not to panic and lose sleep because that doesn’t solve anything. Lastly he advises to communicate with your team and co-workers when something is going wrong. Always be clear at every step of the process so there are no surprises. Additionally, get help and pair program with a team member to get on track.

After reading chapter 11, I think there was some good advice to keep in mind in future pressure situations. The most important I felt was to maintain discipline when facing pressure. Too often it’s easy to get out of a situation in a messy way and this usually creates future problems. By sticking to the behavior you know is correct, you will handle the situation in the best way. The section where author talks about where we are not bound to our commitments disagreed with me a little. While I don’t think it’s appropriate to have a business make commitments for my work without my consent I still need to be employed at the end of the day. He mentions being able to walk away with honor however, in reality if you have a family at home it’s not that simple. You also have to think that your next employer will want to contact your most recent employer and ask about you. Not being able to meet the needs of the business is not going to land you a new job quickly. While I think the advice in this chapter is worth noting, it is more of a general way of handling pressure, not very specific to developers. However I do realize that handling pressure will be important as a future professional developer.

Chapter 12 covers the topic of collaborating. The author makes it clear that programming is not an individual activity and requires working as a team. A professional developer should make a point to understand their businesses goals and work between teams and departments to accomplish those goals. He is very clear that programmers must work with people and that pair programming is a great way to do that. It increases efficiency and allows employees to share their knowledge among each other. An important point the author makes is that the team as a whole owns the code and not one individual. In conclusion, this chapter was rather short but highlighted the important of working collaboratively on a frequent basis.

After reading chapter 12 my thoughts of collaboration were confirmed in the sense that it is extremely important as a developer. I think people who can truly see the teams goals as their own always prove to be successful because they see the bigger picture. The author’s story about the first time he got fired seemed a little off topic. It seemed to be more about his punctuality and attitude that got him fired, not his lack of collaboration. As a beginner developer I think collaboration will be necessary for success at my first professional job. It will allow me to work with people with valuable knowledge and be part of complex projects I couldn’t quite do on my own. I highly expect to be collaborating regularly upon entering my first development job.

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 Reflection 2

My team and I finally got OpenMRS and AMPATH fully functional on all of our computers. At first we were encountering many problems and did not have everyone on  the same page but as time went on we did end up figuring everything out together. Even though some of us had our stuff working, we were encountering different types of problems that were even hard to decipher at first but many different downloads and re installs later, we actually have stuff working. I even encountered an issue where my GUI was just not showing up even though I had the same standalone as everyone else. It would not show up no matter what I tried doing. Even though it took us a while, we ended up coming together and helping everyone in need to get up to speed. Plus it was hard to stay on the same page as everyone because we all have different work to do outside of this class. It is now that we are actually starting to apply this scrum framework and realizing how to go about our work and communicate better outside of school. Most of our problems were not from actual work, but set up and getting the login to work. We have not finished rewriting the module but are still working on it. All in all, we started off our team work a little shaky but are surely making up for it and improving our communication and team skills where they are lacking.

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.

The Clean Coder Chapter 9 & 10

Chapter 9:

This chapter gets into the importance of meetings. Whether you should go to meetings, should be entirely up to you. You are being invited to a meeting, and you can decline that offer if you feel that the meeting might not be the best use of your time. You should always make sure you are using your time wisely because you can be missing important meetings if you get lost in your work, while on the other hand you could be completely wasting your time by being at a meeting you don’t even need to be at. You should always make sure that your presence at a meeting is necessary and truly needed, you should make sure that it is a mandatory meeting before going. And being at meetings, you should leave if you feel that your time is being wasted. Make sure you are using your time wisely, stay focused and make sure to get your rest, it is important to do so, you can’t get anything done with a tired mind. I can relate to this because many times as an intern I had to decide if me being at the team meetings every week was important or not. Also sometimes I’ve tried to work with low amounts of sleep and it has just not ended well.

Chapter 10:

This chapter talks about projecting valid estimations and also about the difference between estimation and actual commitment. An estimation is a guess from your part and it might not accurately represent when it will actually be done, where as when you are actually committing to something, you will have to commit to and finish what you have on your plate. Because you are a developer you must get better at your estimations and commitments even if you might not be too good at them now, it is a something you will get better at with more practice and as a developer you will need to stay at the top of your game and actually do the things you commit to. I understand this is important because I have had committed to projects that I had given the wrong estimates for and had not been ready and finished with my work, when it was actually time to pass it in. So improving this quality as a developer is key.

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.

The Clean Coder Ch. 11 and Ch. 12

Another week, another two chapters from Robert C. Martin’s The Clean Coder.  This weeks installment were chapter’s 11 and 12 which were entitled “Pressure” and “Collaboration” respectively.  They combined for eighteen pages of fluff.  Each contained the signature Bobby Marty anecdote which ate up a large portion of both chapters.  In my last post about The Clean Coder I said that I was starting to enjoy his chapters.  I guess I spoke too soon.

So chapter 11 was about pressure.  Martin writes about avoiding pressure and handling pressure.  I found it interesting that Martin thinks maintaining discipline is both a way to avoid pressure and to handle pressure.  He uses TDD as an example.  The problem with TDD is that it is time consuming.  Not only do you have to think of the code you need to write, but you need to write tests that the code will eventually need to pass.  This means that you will be writing twice as much.  His idealistic position on deadlines is unrealistic.  Sometimes you need to make adjustments in order to make deadlines, and in those cases, disciplines must adapt.  TDD may be the best way to do something, but sometimes sacrifices must be made.

Chapter 12 was about collaboration.  It is asinine to resist collaboration for the greatest accomplishments have not been achieved by a single person, but a group of people.  The overall message of this chapter is that working with other people is important, and I don’t think that many people would disagree with that.  I found his section on cerebellums to be superfluous and poorly labeled.  Cerebellum has very little to do out of the context of that billboard he read, and thusly carries little weight outside of that chapter.  I also found that his take on collective ownership interesting.  I feel as though it needs a qualifier.  Collective ownership is certainly the best way to go, IF and only IF you can trust the people you are working with AND you are using a version control system.

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

Sprint 2 – Learning Reflection

So our second sprint has concluded, and with that, the change from posting once every week to posting once every sprint has begun!  Additionally, we have changed our sprints so that instead of having four days of downtime in between sprints, we only have a day.  I really like the way this class is developing.

This sprint included some pretty good steps in the right direction.  Everyone in my group was able to get OpenMRS and AMPATH to  run locally on their machines, and we were able to dig our hands into some code.  Each of us took it upon ourselves to rewrite the AMPATH Authentication Module in order to learn more about REST API.  A few of us, myself included, have already had some experience with this so it has not been a huge leap.  Not everyone, myself included, has completed rewriting the Authentication Module, but I intend to finish it during the next sprint.

Our group really got a good feel for how the sprint cycle works this time around.  We conducted our own sprint planning meeting, broke down our stories into tasks in our own story time, and had a successful sprint review and retrospective.  Everyone has been participating in the daily scrums, and I’m glad to see that our dedication to the process has been fruitful.  I can only imagine that, as a group, we will become more efficient and more productive as the semester continues.

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

The Clean Coder Ch. 9 and Ch. 10

This week I read another couple chapters out of Robert C. Martin’s The Clean Coder.  These two chapters were entitled “Time Management” and “Estimation.”  Time management is an interesting and important topic in this writer’s opinion.  Martin discusses the importance of meetings, and comments on various methods for limiting these meetings from being time wasters.  He also mentioned a few types of meetings, such as stand-up, iteration, iteration retrospective, and demo meetings.  These are components of the agile process which we have been utilizing in our course thus far.  In my experience with these meetings, I agree with Martin.  If there is not a clear agenda, and if all the members do not maintain focus, a lot of time can be wasted.  Fortunately, we have had pretty good success keeping our meetings on track.  Another topic that Martin broached that I found to be interesting was the Pomodoro Technique.  It is a method for ensuring that time is used effectively and I aim to try using it next time I sit down to do some coding.

As I mentioned, in chapter ten, Martin discusses how to estimate how much time is required for completing tasks.  In his previous chapters he mentioned the importance on estimations, but in this chapter he discusses the process in much more detail, and to my pleasant surprise, provided concrete calculations for how to accomplish adequate estimations.  I hope to employ these techniques in the near future so I can evaluate the validity of his lesson.  As I have read through this book I found that I have been hesitant to believe what Martin has been saying because of the lack of specifics and the overall theoretical nature of the topics.  However, these past few chapters have really started to pull the previous lessons together in a way that makes the whole seem more legitimate.  With only four more chapters to go, I hope that the useful information continues to flow.

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

The Clean Coder, Chapter 9 & 10

This week, I read chapter 9 and 10 from the book title, The Clean Coder by Robert C. Martin. The focus of chapter 9: Time Management was how to manage your time effectively and efficiently in the workplace? How to deal with meetings and other chaos going on in office? Chapter 10: Estimation, covers an important topic closely relating to time management. Uncle Bob explains how professionals deal with commitment, estimation and honoring their commitment.

There were some great points pointed out in chapter 9 regarding time management. Some of the most interested points to me were: when to go, decline or leave a meeting; habits that can help and accelerate bringing back focus and getting important tasks done on time; and most importantly his explanation of the priority inversion.

I agree with the author saying that when a meeting gets boring, leave. I feel like there would be lots of meetings in the business world where it gets boring quickly and there would be people who might be able to politely excuse themselves and move on with their usual day, but I am wondering how would it turn out for people who are in an entry-level jobs or new to the environment. I mean… what if he/she has to be there the entire time, no matter what?

I really liked the three suggestions that can contribute to sharp mind and better performance: good night sleep, limited caffeine intake and muscle focus. I have personally tried these and it helps me enormously with my studies and daily life. I could not be more agree with the author when he said that muscle focus increases capacity for mental focus.

Author talks about priority inversion, when I read this part of the chapter I saw myself as one of the victim of this habit. Until this point, I did not know what I was doing, but after reading this chapter, it explained that I am engaging in an unprofessional behavior that is effecting me in ways that I don’t know how to control. From now on, I will be a professional. I will evaluate my priorities, disregard my personal fears and desires, and perform every tasks.

In chapter 10, uncle Bob explains the importance of estimation as commitment to a task. When professionals make a commitment then they are bound to honor that commitment. Professionals do not make commitments unless they are certain about getting it done. I believe there comes lots of responsibility and pressure on individual when they make a commitment. It means that he/she is willing to sacrifice everything that comes in the way of their commitment.

Lesson that I learned from these two chapters are to fight against priority inversion and avoid commitments unless I am 100% certain.

From the blog Software Learning and Development – Haider Hussain by hhussainsite and used with permission of the author. All other rights reserved by the author.

Sprint Review 2/22

This week our group has just finished another sprint slightly longer than the last. We are still working on the AMPATH section of the open source OpenMRS project. We have started getting slightly more into the code itself and so far it has been a rewarding experience.

This spring was all about getting the cloned ng2-amrs directory to install and build successfully. Although it sounds simple enough there were quite a few bumps along the way preventing us from being able to run the build and log in. However we were able to overcome these obstacles by getting aid from the team as well as the rest of the class when it was necessary. Once that was taken care of the next step task in the sprint was to get the standalone version of the OpenMRS version downloaded and the server up and running. Again this did not come without some degree of difficulty, however it was nothing that we were not able to overcome.

Once that was all done we decided to change the way that we wanted to organize our contributions to the open source repository. So we created a github organization and forked the ampath repository into that organization, and from there we forked the organizations repository and cloned it onto each of our computers. This means that we had to delete the repository that we had just spent a good amount of time getting to run and redo the whole process. The good thing is that the entire thing was a lot easier the second time around and we were all able to redo the installations within around an hours time.

Unfortunately we did not have enough time to complete everything on the sprint backlog such as redoing one of the login modules in order to get a better idea of the code that we are working with. So that was put back into the backlog for the next weeks sprint. Upon completion of the sprint we performed a sprint review and a retrospective. Although there was not a great deal of work to be done this sprint i feel we are getting a better idea of the process as a whole and learning to work as a team. I look forward to the next sprint.

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

Sprint 2: Reflection

Sprint 2 was our introduction to the OpenMRS project Ampath. Our main goal for the sprint was to build and install ng2-amrs, and install openmrs standalone 2.5. As a team, we all were successful in completing everything individually with each other collaboration.

For me personally, sprint 2 started very problematically. I could not build or install ng2-amrs on my local machine. I consulted with my team, the class and Dr. Wurst for help, but we could not figure out what was wrong? During the extended one week of sprint 2, Dr. Wurst introduced us to the different ways of organizing and contributing to projects on GitHub. Out of the three options, our group decided to go with the organizational flow of work. One of our team member made fork from ampath to organization and we all forked from organization. Then, we cloned our individual forked into our local machine. Applying this methodology helped me built and installed ng2-amrs on my machine with obstacles. What I was doing wrong in the beginning of sprint 2 is still mystery to me.

The lesson that I learned from Sprint 2 is that it is true that I was responsible for building and installing ng2-amrs on my laptop, but it really made things better and resulted in maximum outcome when our team collaborated with positive energy with each other. Team members were not thinking about themselves, but rather made sure that everybody in the team has built and installed ng2-amrs. I believe it was this team contribution that led to more discussions on the subject and challenges we were facing, and for that matter it resulted in more clarification of information and ideas. This proves that more can be solved and achieved with each other help and collaboration.

From the blog Software Learning and Development – Haider Hussain by hhussainsite and used with permission of the author. All other rights reserved by the author.