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.

Sprint 2 Reflection

Over the past two weeks our Scrum team has been working through the the sprint backlog. I was able to complete all of the tasks on the first day with the exceptions of rebuilding the login module. The tasks involved installing and setting up OpenMRS as well as AMPATH. The next task was to get the two systems to talk to one another. This task took a little bit of experimentation because the two sites did not want to interact at first. The issue was caused by cross-origin resource sharing. This error is a result of one site request content from a second site. In this case the origin, which consists of the domain as well as the scheme and port number. There were two solutions found, the first involved installing an extension in Google Chrome called Access-Control-Allow-Origin. The second options, the one I am currently using, required a small amount of XML be added to the Tomcat server’s configuration file web.xml with in OpenMRS. By the end of the sprint all these tasks were completed by each member. The one item that was not finished was rebuilding the login module for practice.

Over all I believe the team is working pretty well together. getting the two programs running took some a bit longer than others but with a little help all were successful. I think the team will grow stronger and work better together once we have a list of tasks we can split up. There was not too much motivation for rebuilding the login module because it was already working and there was no ore waiting on it. I look forward to the coming sprint as it looks like there will be some bugs that need fixing.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog 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.