Category Archives: CS448

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.

Reflection, Week 3

I spent this week completing the Angular2 Tour of Heroes tutorial. I also spent some time learning HTML on Lynda.com. The new thing that I did this week was that I got started with katas mentioned in the Clean Coder book. I am currently working on the prime factors kata on my spare time. I plan to learn a few katas and repeat them for the rest of this year.

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

Reflection (Week 3)

Week 3 is officially over, and I’m ecstatic to say that my team finished our first sprint. This week I finished the Angular Tour of Heroes Tutorial and we did a team member evaluation for our group. Through this exercise, we noticed things we were doing well, but more importantly things that we didn’t do well. We then discussed about how we can all improve as team, before we tackle our next sprint.

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

The Clean Coder (Week 3)

This blog post will revolve around chapters 5 and 6 of The Clean Coder book.

Test Driven Development (Chapter 5)

The author provides us of some rules for test driven development.

  1.  You are not allowed to write more production code than is sufficient to pass the test.
  2. You are not allowed to write more of a unit test than is sufficient to fail.
  3. You are not allowed to write any production code until you have written a failing test.

By applying these rules, it aims to minimilazie larger problems later on in production. When I first started doing TDD, it was quite tricky, because I was confused on how to write a test case when there were no code for the methods that we were testing. By doing this, you know that your method will pass any type of test case, and you won’t have to worry about it anymore as opposed to trying to find a needle in a hay stack bug at the end.

Practicing (Chapter 6)

This chapter was pretty self explanatory, because we all know of the saying that “Practice makes perfect”.  The author mentions a programming exercise called Code Kata, which allows programmers to improve their skills with repetition and practice. As simple as this chapter is, it’s very important and you can’t stress the importance of practice enough. As a computer science student, I realize how the programming world is quickly evolving as there always seems to be a new language, or framework to learn. It’s impossible to stay relevant in this field without practicing or studying.

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

The Clean Coder, Chapter 5 & 6 (Week 3)

Chapter 5 of the Clean Coder book is about Test Driven Development. There are three laws of TDD:

1) You are not allowed to write any production code until you have written a failing test.
2) You are not allowed to write more of a unit test than is sufficient to fail.
3) You are not allowed to write more production code than is sufficient to pass the test.

There following are the benefits of TDD:
1) Certainty – Since there are a suit of tests for the code, any time you make a change you can run the suit of test to check if your change broke anything. If all the tests pass you can be sure that no new bugs were introduced by your change.

2) Defect Injection Rate – There are documented cases of defect reduction from teams that use TDD.

3) Documentation – The tests serve as a living documentation of the code and what the software is supposed to do.

4) Design – TDD forces you to write code that is decoupled.

Chapter 6 is about practice and its importance. The author recommends professional programmers practice with katas, which a simple program that you do over and over again until perfect mastery. I plan to choose a Kata and master it in my free time.

I liked the last two sentences in the chapter: Practicing is what you do when you aren’t getting paid. You do it so that you will be paid, and paid well.

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 2: The Clean Coder

This week we were assigned to read chapters 3 & 4 of The Clean Coder.  Chapter 3 was very interesting to me right off the bat; mainly because it was the complete opposite of last weeks chapter “Saying No”.  Chapter 3 was called, “Saying Yes”.  To sum up the chapter, it basically discussed how to tell if someone means what they are saying, and ways to change what you say to really mean it.  I found this chapter very useful because I personally know that I say things I don’t really mean to commit to all of the time.  One thing this chapter brings up a few times is when you hear someone say, “I need to lose weight”.  That is an extremely common phrase that people say, but it doesn’t necessarily mean they are truly going to commit to losing weight; they might just want to get around to it .. someday.  Chapter 3 stresses on the fact that as a professional, you should make it crystal clear when saying yes that you really do mean it and are going to commit to it.  Being able to say yes I will get something done as a professional and actually get it done is huge.  I have never really put too much thought into everyday conversations of people saying “yes” but not meaning.  But now that I think about it, there is so many times where someone says “yes”, but I just know that they don’t mean it so I don’t take it seriously.  In the workplace, that is not the professional thing to do and now I am aware of that.

Chapter 4 took a turn and was different then the last 2 chapters.  The difference with this chapter was that it was about your personal attitude towards coding, not how you communicate with others.  Although it is very important to have good communication skills as a developer; it is also very important to write good code.  The author took this chapter to discuss his personal things he has discovered that make his code a lot worse in the past.  A few of the tips he gave are:

  1. Don’t code if you are tired or distracted
  2. Don’t code at 3 AM
  3. Don’t code when you’re anxious
  4. Don’t code when you’re “In the Zone”
  5. Don’t code when listening to music

I am not going to sit here and list everything he said in the chapter, but I will say I don’t agree with some of his points at all while others I completely agree with.  For one, I have coded some of my best work when listening to music.  It’s interesting how music can help some people focus, while may distract others.  A tip I originally didn’t agree with at all was “Don’t code when you’re ‘In the Zone’”.  When I’m in the zone, there is no stopping me.  I love being in the zone and feel very productive when I am.  However, he did have a point that you may just be working at rapid speeds but not producing that good of work.  When you’re in the zone and writing a bunch of code, that is usually the code you will always have to revisit lateron and he’s 100% right about that.  It was interesting to me to recognize that being “in the zone” may not always be such a good thing. Finally one tip that stuck out to me that I can personally relate to is finding solutions in the car on the way home.  This has happened to me more then once where I left the office with no answer and on the way home, the solution just coming to me.  Something about taking your mind off of the problem and focusing on something else can lead to answers.  In the chapter, he calls this “disengagement” that may allow your mind to hunt for solutions in a different and more creative way.

 

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 2: Reflections on Learning & Work Products

This week my main accomplishment was setting up my work environment both on Web Storm and Trello.  My whole group made Trello accounts, and we set up our board so we can start getting the hang of how we will be working together this semester.  Trello helps us keep track of what’s done, what’s in process, and who’s doing what.  I personally really enjoy using Trello, because it’s an easy and visual way to stay on track with my group.  This week made me realize that working to complete this project is definitely different then the workplace because we don’t have full contact to each other at all times.  At work it’s everyones full time job to get the project done.  However, here at school, not everyone in the group is always accessible.

The most current thing I have been working on is completing the Angular 2 (Tour of Heroes) tutorial using Web Storm as my IDE.  This tutorial is a fun way to begin learning Angular 2.  Just beginning this tutorial with some of my group members in class taught me that working together and asking questions when you have an issue is very important to get things done efficiently.  Everyone in my group was working together in class to make sure we all had a working environment which was very helpful.  Next week I am going to be sure to post my “daily” scrum on Monday, Wednesday, and Friday because I wasn’t aware that we had to do that last week.  I think frequent updates are a great idea and will be useful when we are working on the actual task.  It will be good to see where everyone is at on daily basis.  Overall, I feel accomplished this week and am anxious to start learning Angular 2 more in depth this upcoming week.

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.