Category Archives: CS448

Learning Reflection, February 22

This week I spent a lot of time reading and learning stuff on Angular 2. I bought the ng-book 2 along with the beginner’s screen cast; I spent a lot of time reading the book and listening to the screen cast.

I found the first few chapters in the book good and the first half of the screen cast was good. I could not understand the other half of the screen cast and some chapters in the book were not written well. I plan read more chapters in book and if I don’t like it I plan to return the book. I expect a lot more from a book worth $79.

The deeper I delve into Angular 2 I find that there are a lot of things I don’t know, things like reactive programming and asynchronous programming.

The problem that I find frustrating is that there aren’t many good books on Angular 2.

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

Sprint Review 2

It’s finally the end to an extend sprint and in all honestly, i’m disappointed with the progress that I’ve made individually. I told myself that I would get through everything on the task board, but there were many roadblocks for me in this sprint. I had a tough time connecting the OpenMRS standalone to the AMPATH. It took me a really long time to do it, but I eventually diagnosed my problems and got it to work. What I did was add a piece of code in the web.xml file, and installed a chrome plugin called ‘Allow Control Allow-Origin’ and it allowed me to connect to the database.

As of now the majority of the group is on the same page and we are looking forward to improving our performance in the next sprint by holding each other accountable for the work that we commit to do.

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 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.