NOTES FROM Java Build Automation with Maven with Peggy Fisher 1. Get Started with Maven What is Apache Maven? Apache Maven, is a software project management, and comprehension tool, based on the concept of a project object model, or POM. Maven … Continue reading 
From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.
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.
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.
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.
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.
Week 3
Finished our first sprint! It has been a low week here waiting for the next sprint to happen where the interesting tasks will ramp up. Over the past week I completed my Angular Tour of Heroes, and we did a team evaluation at the end of the sprint which turned out to be a slightly awkward experience because no one wants to throw anyone under the bus. We have to progress as a team and complete our tasks though. We will see how smoothly the next sprint goes then re-evaluate.
From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.
Test-Driven Development: There are rules that the author provides about test-driven development such as you are not allowed to write any production code until you have first written a failing unit test. You are not allowed to write more of a unit test than is enough to fail and the contrary, you are not allowed to write more production code than is enough to pass the currently failing unit test. Working in small key increments making sure the units operate properly will reduce any problems. From my experience, I have noticed trying to write the entire program THEN go back to search for these errors can be troublesome–and not fun. This incremental testing will reduce defects by 2-10x, increases comfortability of the coder with their code, and more importantly provides certainty that the change will not break anything.
Practicing: Practicing is key is any element in life. Practice what you preach. Code Kata is an exercise in programming that helps a programmer hone their skills through practice and repetition (in relation to the concept of kata in the martial arts). Wasa is a two-person version of the kata where it is done in pair-programming style. Moral of the story, there are several ways to practice, and every coder needs to practice. From being in the field for a few years now, and reading blogs it is very clear how fast this field evolves. You can’t possibly stay up-to-date without studying outside of work. All professionals practice.
From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.
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.
NOTES FROM Up and Running with Public Datasets Curt Frye 1. U.S. Census Bureau and Securities and Exchange Commission American FactFinder link: factfinder.census.gov Most US residents know the United States Census Bureau as the government organization that counts the American … Continue reading
From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.
Like the first week, This week was mostly about setting up and trying things with Angular 2.
First we all made a Trello account. This was quite easy as there was a one step sign up.
Next we all needed to make an OpenMRS id and introduce ourselves on the official form. This was also quite easy. One of the team members (Danny) did happen to get banned from the board very fast. This was probably due to a random occurrence.
Then we set up Trello integration into Slack. This was just a simple command.
Then we installed the WebStorm IDE by Jet Brains. Lucky enough students get a year of some Jet Brain software for free. So that was quite helpful.
The last of the tasks was to complete the Angular Tour of Heroes. This was the hardest part of the week. It was a quite fluid tutorial, but I got stuck a few times. I had a difficult time with knowing where to put some code portions and some of the spelling mistakes took far too long to figure out. I greatly appreciate the tutorial the Angular team has produced because it gave a great overview of some great things Angular can do. I went through the tutorial a few times to try and get everything down. I don’t know if I completely understand everything. It is always process to learn a new language and I am defiantly on the right path.
From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.
In the third chapter the author discusses what “yes” means and the different types of yes. He states that there are three different ways to accept or respond to an inquiry. The first is equivalent to a sure. Not really confident that this request or situation will be accomplished. The next form of yes is similar to I will try, where you really want to get it done and you will try to get it done but you know it probably won’t happen. The last form of yes is a very confident yes, this is knowing with almost a 100% chance this task will get done. The author suggests that we all should change the way we accept commitments to only use language to suggest the 3rd situation. If it is not a 3rd situation then you should change some of the factors to be certain that it is accomplished on time, and to the fullest extent of your ability.
I tend to agree with the author on his points in this chapter. I have found myself on more than one occasion saying to myself “I will try to get this done”or “maybe I will get this done” when deep down I know I will probably put it off. This point he say about making yes possible is defiantly a good mindset to get into going into the business world where everyone has a job to do.
In the fourth chapter the author talks about a variety of situations that you will face while coding. First is to be prepared and fully understand how long a project will take you. This helps cut down on late night coding. Another situation he details is when being distracted by some event in your life. He states that you should break for a little bit to try and remedy the situation stressing you. The author details about the Flow Zone, which is a super focused state of mind.
In the fourth chapter the author talks about a handful of topics, But a few stood out to me. The first that really stood out is the concept of the flow zone. I for one did not think that this zone was an actual thing until I read about it and thought back to all of the times I have coded. The author says that the flow zone is not the place to be during coding. Also that the flow zone uses a different part of your brain. He states it is like a zombie state where you are not problem solving to your best potential. I disagree to a point. I understand his thought process, that coding under this focused state might give less efficient outcomes. But I feel as though every time I sit down to do work I do not get anything done unless I am in this flow zone.
From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.