Category Archives: CS448

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.

The Clean Coder (Week 2)

This weeks reading will be from The Clean Coder by Robert C. Martin. This blog post will revolve around chapters 3 and 4.

Chapter 3 talks about saying yes and when one should say it. Throughout this chapter, Roy Osherove talks about the three main points of commitment.

  1. “You say you’ll do it”
  2. “You mean it”
  3. “You actually do it”

Osherove also talks about signs of non commitment.

  1. “Hope”
  2. “Need”
  3. “Let’s”
  4. “I will…by..”
  5. “Hope”

Osherove made a lot of valid points that I agree with. I noticed that sometimes when I tell myself that I “should” get something done, it doesn’t necessarily mean that It will be done. I feel like those non commitment words are just excuses to not completing a task. When a person says “I Will” when committing to something, it exhibits assurance to the other person, because it tells them that they are taking it seriously and will follow through with their commitment.

Chapter 4 talks about coding, but more specifically, it grasps on the topic of when to code, when not to code, and what to avoid while you’re coding. There was a story where code written at 3am is bad, because it’s difficult to focus at night. I don’t know if I agree with the author completely, because I like to stay up late and code sometimes.It all depends on what my activities are during the day. On the topic of when not to code, you should stop when you find yourself not producing quality code that you know you can produce. You should take a breather and relax so you can clear your head before resuming.

 

 

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

Week 2 – Learning Reflection

imgres

This past week I spent my time working with Angular 2.  More specifically, I worked through the Tour of Heroes.  I took my time going through the tutorial, and as a result, I feel as though I learned a lot.  Unfortunately, for everything I learned, I am sure that there is an equal or greater amount of information I did not retain.  I intend to spend the next couple days reinforcing that knowledge with some more readings.  Then the fun starts.  In the same manner that I have learned everything else, I need to apply some practical application to the material and gain some experience.  Luckily, I have a group of peers, a project to look forward to, and thirteen more weeks to practice.

I find that I am disappointed with my second week of learning reflection blogging.  I don’t think that it is for a lack of effort, but that I have not begun working on our own project.  The Tour of Heroes tutorial is pretty self-explanatory, and does not require any additional commentary.  Once we dive into our project, and hopefully that time comes soon, I will be able to write about that experience.  Until then, I will continue to learn as much about Angular 2 as I possibly can.

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

Reflection (Week 2)

Week 2 was rather very interesting, because I was exposed to new technologies, applications and languages. My team and I created a slack channel where we will be communicating with each other for the duration of the OpenMRS project. Along with creating a slack channel to communicate, we also created a Trello board, where we tackled on our very first sprint in order to get the project rolling. One of the tasks on our board, was to create a user login to the OpenMRS website and to introduce ourselves in the community forum page. As previously stated in my week 1 reflection post, we are working with Angular 2, and with that I had to download an application that was foreign to me called WebStorm to write our code in. I’ve never used it before, but i’m looking forward to learning how to use it.

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

Reflections, Week 2

I spent this week learning Typescript and Angular2 (continuing from last week). I continued with what I did last week. The only thing which I did different this week was that I listened to videos on Angular2 and TypeScript on Lynda.com.

Some of the videos were good and some put me to sleep. I am also working on the Angular2 tutorial (building the tour of heroes app); I’ll complete it by the end of this sprint.

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