Category Archives: CS448

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.

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.