Category Archives: CS448

The Clean Coder (Week 5)

This blog will revolve around chapters 9 & 10

Chapter 9

This chapter is about time management and how it’s imperative to have this skill. The book talks on the topic of how meetings are a waste of time. I honestly agree with this to a certain extent. Whenever i’m in a meeting at my job, I find that most of the time, the meeting usually goes nowhere and is not very beneficial for everyone. I also find that when meetings occur, there would be a selected few who will hold the group back by asking repetitive questions that could be answered on their own time and not the time of everyone in the room.  In programming, I find that meetings are imperative if they don’t last long. Meetings that don’t last long, can be very beneficial for everyone in the room, by  keeping everyone focus and happy.

Chapter 10

This chapter talks about estimation and how it’s important to make valid estimations. It’s tough to give an accurate answer when someone asks you how long something will take, because you really don’t know. In the programming world, there could be a plethora of obstacles that will hinder the progress of the project so it’s best to give options to when something will be done to the answer seeker so that they won’t be disappointed. This chapter also talks about commitment. This is different than an estimation, because a commitment is something you MUST see through.

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

Clean Coder 9 & 10, (Week 5)

The ninth chapter of the Clean Coder book is about time management. The is only 28,800 seconds in a working day and it is the duty of a professional to use those precious few seconds effectively. According to the author meetings take a lot of time and money; as professional you need to know when to go to a meeting you are invited and when to decline.

The advice that I found most interesting was the following: any argument that can’t be settled in five minutes can’t be settled by arguing; and so there is no point wasting meeting time to try and resolve the issue. The other interesting thing is the Pomodoro technique to manage time and focus.

The tenth chapter of the book was about estimation and how to make valid estimations. The author explains and differentiates between the concept of an estimation vs. a commitment. He also talks about the different ways to make estimations.

There is not much that is new to me in chapter 9, but I found some of the estimation techniques useful. I plan to try out those techniques in our ng2-amrs project.

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

Week 4: The Clean Coder

I read chapter 7 & 8 of the clean coder this week.  To sum up chapter 7, it basically talked about how important it is to write automated acceptance tests.  Communication between two parties can be extremely difficult in the workplace.  There are many times where a customer and a developer, or really any two parties might think they completely agree on all the details they discussed, but in reality they might leave having two totally separate ideas.  It is very easy to assume someone understands something when in fact they aren’t on the same page at all.  This chapter showed me that writing these acceptance tests are a great way to solve the problem of miscommunication in the computer science field.  The chapter defines acceptance tests as, “tests written by collaboration of the stakeholders and the programmers in order to define when a requirement is done”.  I really enjoyed reading this chapter.  It brought light to my eye that there is a way to fix the problems of not getting across what will be done clearly and precisely.  I remember in class we talked about “the definition of done”, and this chapter also discussed this.  Your definition of done can be completely different then the person sitting next to you.  It is very important to clarify specifically when discussing what is going to be done so everyone is on the same page.  I remember I had a presentation once and I thought one of the members in my group was going to make slides on a certain topic.  When it came the day to present, we realized that we completely miscommunicated and ended up both doing the same thing.  This chapter reminded me of this specific time.  It’s a good idea to follow this practice in order to prevent these types of things from happening in the workplace.

Chapter 8 discussed how important it is to constantly test your code as a developer.  This chapter touched on 5 main types of testing that should be run as frequently as possible.  1.

  1. Unit Testing
  2. Component
  3. Integration
  4. System
  5. Exploratory

I could not agree with this chapter more.  The deeper I get into the field of computer science and programming, the more I am starting to see the importance in testing.  Although testing can be extremely tedious and boring, it is something that you must do as a professional engineer.  Many developers tend to think that they don’t need to test anything because that’s the QA’s job.  However, this is not true at all.  This chapter talked about the importance of the developers and QAs working together to test EVERYTHING.  An interesting statement that was mentioned in this chapter was, “It should be the goal of the development group that QA find nothing wrong.” I really liked what the author said and I agree.  In order to be a great coder, you need to not only be able to write a good program, but you also need to write good tests so you can catch the problems before the QA, or worse, the customer.

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 Ch. 7 and Ch. 8

If you were feeling a void in your heart for some more testing since chapter 5’s lesson on TDD, then chapters 7 and 8 are sure to get that blood pumping organ to swell.  Chapter 7 is called “Acceptance Testing” and focuses on how to determine when a programmer has completed a requirement.  Chapter 8 is called “Testing Strategies” and focuses on the “The Test Automation Pyramid” which I provided below.

Screen Shot 2017-02-14 at 12.23.36 PM.png

In chapter 7, Robert C. Martin gives his “Definition of Done” which is accomplished when “all code is written, all tests pass, QA and the stakeholders have accepted.”  Just today our development team drafted our own Definition of Done.  Ours contains slightly different criteria as we are not engaging in TDD.  Additionally, due to our constraints, do not have the time or resources in order to produce automated acceptance tests as Martin suggests.  He focuses immensely on how integration testing through a continuous integration system is the best form of communication between programmers and stakeholders.

In chapter 8 Martin focuses on test coverage.  He believes that unit tests should cover 100% of a programmer’s code, although he admits that 100% coverage is unrealistic.  He also suggests component tests should cover about 50%, integration tests about 20%, and so forth.  Martin suggested, once again, that he believes that QA should find nothing wrong with the software that they are reviewing.  However, in this and the previous chapters, he explains that QA has the responsibility of writing the acceptance tests in conjunction with the stakeholders.  Therefore, if QA does a good enough job, and programmers ensure that their code passes these tests, then I finally agree with Martin. There exists a slim possibility that programmers can ship code to QA with some confidence that there exists no bugs in the code.

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 (Week 4)

This blog post will consist of chapters 7 and 8.

Chapter 7 talks about how communication and avoiding communication errors between stakeholders and developers is imperative to the success of a project. The author emphasizes that the most effective approach to avoid miscommunication is to write automated acceptance testing.

Personally, I’ve never written tests for a corporation, but I have some experience with writing tests for small projects at my University. The tests that I wrote, were for a project that we had to work individually on, so there was never a time that miscommunication would occur.

Chapter 8 discusses all of the different testing strategies and how the most important goal for a development team is to have the quality assurance team find no bugs when they sift through the vast amounts of code. QA teams are important for a software, because without them, there will be plenty of bugs that weren’t discovered and this will effect the quality of the software dramatically.

 

 

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

Week 4: Reflections on Learning & Work Products

This past week I have managed to get the openMRS code up and stably running.  I began trying to run this by doing exactly what I did for the tutorial I completed last week.  When I realized that wasn’t work I decided to ask my teammates what they did.  Turns out there was a file called, “Read Me” on the git hub repository.  This file gave in-depth instructions on how exactly to run the code.  This was very helpful and taught me to look for that type of file first when encountering a problem with running unfamiliar code.  I have began to create a new login page at this point in time.  As I started to try to do so I was very confused with how I would do this.  I decided to take a step back and read up on some more Angular 2 stuff, focusing mostly on the structure of how you are supposed to code in this language.  This sprint I plan to successfully create the login page and then go on from there.  I still don’t have too good of an understanding of Angular 2 so I am going to try and understand everything I am doing when making the login page, rather then just doing it so it works but not really understanding what I’m doing.  Last week when I was doing the tour of heroes tutorial I didn’t always pay attention and understand what I was doing.  I was kind of just following the tutorial so it worked, which wasn’t the right way to go about it.  I should have been paying more attention to the things I was typing and not just copying down what it said to.  This week I will take that lesson and focus on learning the language as well as consciously getting the program to work.

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, Chapter 7 & 8 (Week 4)

Chapter 7 of the book is about the importance of communication and how to avoid communication errors between stakeholders and developers. According to the author the only way to effectively eliminate communication errors is to write automated acceptance tests.

Chapter 8 of the clean coder book is about testing strategies. According to the author, the goal of the development team is that the QA team finds no bugs. The development team should react with horror(it should not be something they expect) every time QA finds a bug and must take steps to prevent them in the future.

I think the whole point of this strategy is to force the development team to write clean code rather than write bad code and push them to QA, which will ultimately cost time and money since the development team will have to fix the bugs once QA finds them.

The rest of the chapter is unit tests, component tests, integration tests, system tests, manual tests and exploratory tests. Things we learnt in CS443.

Both of these chapters discuss scenarios which I have not yet faced; so I can’t give any opinions or past experiences.

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

Week 3 – Learning Reflection

Unfortunately I have not done much since my blog post last week.  In fact, since our sprint finished on Thursday, my learning has been put on hold.  In light of that fact, the structure of these blogs will change.  Instead of weekly posts, I will be posting every two weeks, when our sprints finish.  In retrospect these past three learning reflection blogs were rather unproductive, but the future posts will contain much more useful and interesting information.

As I said, we completed our first sprint on Thursday.  So now I have experienced the entire sprint cycle, and I must say, it went pretty well.  Future sprints will certainly be more involved, but I think that our group handled the process without any major problems.  As this semester progresses I anticipate that our group will embrace the sprint cycle and scrum as a whole.

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

Week 3: Reflections on Learning & Work Products

Last week I finished the tour of heroes tutorial.  I learned a lot from just working through it and understanding the implementation of Angular 2.  I liked how the tutorial brought you through something and then had you change it to make it better.  For example, we started off declaring the type “hero” in on of the main folders.  As the tutorial went on, it had me move thedecloared type, “hero”, into its own class.  I learned a lot more then I thought I would from doing that.  This week I already forked the am-path project on git and got it up and running.  That was definitely an accomplishment in itself.  My goal for this current sprint is to work through the AMPATH code and to get a feel of how everything works together.  As of right now I haven’t actually looked at any of the actual code so I am planning to start that tomorrow or Thursday.  I think everything went pretty smoothly this week and I can’t really think of anything I would do differently.  I’m happy we are getting closer to finding out what we will be doing to contribute to the AMPATH project.

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.

Week 3: The Clean Coder

This week I read chapter 5 & 6 of The Clean Coder.  Chapter 5 discusses that it’s a good habit to write the J-Unit tests before you start to code at all.  I personally am not a fan of doing this, but this chapter taught me how much it can really help.  A quote that stuck out to me was, “I know this sounds strident and unilateral, but given the record I don’t think surgeons should have to defend hand-washing, and I don’t think programmers should have to defend TDD.”  I never have really thought of TDD as a key to programming, so this was a little weird to me.  Obviously as a surgeon it’s a known thing that you NEED to wash your hands.  However, as a programmer I don’t think it’s that known that you should write your tests before coding.  It is extremely important to make sure every single program you write has high coverage tests to go along with it.  The chapter also explained things like documentation of the unit tests.  Someone who is reading through your code should be able to look at the unit tests and see exactly what it should do.

Chapter 6 of the book discussed how important it is to PRACTICE.  I agreed with this chapter a lot more then I did chapter 5.  Practice 100% does make perfect and you need to be willing to put in your own time to be the best you can possibly be.  No one is born being great at something, you need to practice and perfect your skills to make yourself great.  As a professional, you NEED to practice and this chapter doesn’t stress that enough. “Practicing is what you do when you aren’t getting paid.”  That quote really showed me that if you ever want to be the best at something you have to willingly put in your own time.  Overall I liked reading chapter 6.

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.