This week I am going to write about the single pattern form the book which first starts off with “your first language” this pattern talks about people who first want to start to program or have very little experience programming so that only know one or two languages. In this pattern the problem that these people face is that they feel like they must write programs in a specific programing language and be up to the same standard as their teammates however they don’t know much or as well as the other people working in their group. This part of the chapter tells the readers that they should just pick a language and become fluent in it. No matter what language you choose the basic problem-solving skills that you get from it would be able to be used in other langue’s. One of the major tips that I believe works really well is that you don’t have to learn this language by yourself. Find someone who has mastered the language and talk to them about it. You should be able to ask them for tips and tricks about the programming language. Even though you don’t see them every single day if u see them once a week it can improve your knowledge of the language. Once you learn enough code to start writing your own stuff you can start running test, tweaking, and experimenting your code. With this you can learn what can break the code and learn the limit of the code. You also aren’t limited in learning the language you can also learn about how other people’s libraries work and over time you can test points to new library’s and see the functionalities of them. A really good advice that this pattern talks about is talk to people who have mastered multiple languages and get their input on how and why they choose whatever language to learn first. I like this pattern and what they talk about because with this people who want to start programming it isn’t something that you have to naturally gifted to be able to learn and understand. This shows that people like them struggles to learn these things and all they had to do was choose one program and find someone to be able to talk to about it. Everyone learns at their own pace and their own language so that way anyone can learn programming and its not hard to do.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

http://www.ques10.com/p/2192/what-is-data-flow-testing-explain-feasible-paths-1/

Finally, for this week I decided to write about Data Flow Testing. I found a blog site called Ques10 and there was a question about what is data flow testing. The blogger Ramnarth ansered the question by explaining what Data Flow Testing is. Data Flow Testing is a test that tells us that a programmer can perform a number of test on data values which are collectively known as data flow testing. With data flow testing it can be performed at two levels static and dynamic. Static testing is performed by analyzing the source code and doesn’t involve in running the source code. It is performed to reveal potential problems in the programs which are also known as a data flow anomaly.  And with dynamic testing it looks at the path of the program from the source code and with this you would draw a data flow graph of the program select a critical testing area, then identify the paths in that data flow and test the derive inputs. He talks about how testing critical section on the data flow chart by breaking it down into paths and tests such as how we did it in class. Were we would look at the DU-Paths and look at all the edges and nodes to see if they make sense. I like this blog because it does involve some of the things that we did in class such as DU-Path testing, edges, and node testing. I like that the things I learned in class is also reflected into real life things we can do. I think data flow testing is just something we could be doing because it is just a bunch of tests that you run through so that way you do multiple test at the same time.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Source: https://dotnetcodr.com/2013/10/17/the-dont-repeat-yourself-dry-design-principle-in-net-part-1/

For my last week I decided to write about Don’t Repeat Yourself design principle. I found a blog called dotnetcodr and there was this blog about (DRY) written by Andras Nemes where he talks about (DRY). The idea behind (DRY) is that you should not add repetition of logic in multiple places in the code. He talks about the motto that you should be following “Repetition is the root of all software evil.” Repetition does not just refer to writing the same piece of logic in two different places but also the repetition testing, debugging, deployment, ect.

He then gives an example of repetition where he writes out the person and then where the live as well. In this code he hard codes everyone’s name and address. This way it is a very good example of reputation because since he is just copy and pasting whenever he would need to add or remove a person or address he would have to go back into the code and manually change it himself.

I found this blog to be very informative because it is very true you do not want to repeat yourself and the logic of a certain code in multiple places and multiple times. There are times where I do this a lot because I find it much easier to repeat the code since it is going to be the same every time I want to call something. I think the thing I get out of this the most is that I will start to try and not repeat myself when writing code. Also I can use this for future knowledge when I do write things that do call things multiple times and like it shows in the blog we can make stings that have getter and setters that would make a 40 line code down to a 10 line code which would save much more space and time as well.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Source: http://www.castsoftware.com/blog/five-reasons-to-measure-software-complexity

This week I looked up Software Complexity blogs. I found a blog called “Five Reasons You MUST Measure Software Complexity” written by Jonathan Bloom. This blog talks about how sometimes complex code aren’t the best thing. He gives you a few methods developed for measuring software complexity. Which are Cycomatic Complexity, Halsted Volume, and Maintainability index. With these methods companies and use the information found by them to capitalize how they are writing the code such as. Greater predictability because knowing the level of complexity of the code can make it easier to maintain and show how much maintenance a program will need. The software risk mitigation which manages the software complexity lowers the risk of introducing defects into production. Reducing cost because with lower mateine cost the origination can spend that money on other things. It extends the value of the programs because excessive complex application causes issues. With this it keeps the software in cheack and keeping the complexity of it in check. Finally, decision support with this it allows the owner the information to tell if it is worth the cost of even fixing the code or if writing new code be worth it.

The benefits of software complexity analysis are that it improves code quality, reduce maintenance cost, heighten productivity, increase robustness, and meet architecture standards. Because of this a lot of bigger and smaller business try to add this analysis to make sure that they are not losing money because the software is too complex for what they need. I like this blog because it backs up one of my other blogs that talked about keeping code short and sweet. We should do code as basic as we can to keep things neat and organized and don’t make it crazy so that way we don’t waste time doing things we didn’t have to do. I think I will keep this in mind when I move on to my next step of my life. Keeping code nice and simple is the best way. I also think that I will keep this in mind when I am working on the final project for many of my classes because we don’t want to write too complex programs for our robotics class and our software constr class as well

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Source: http://codermike.com/starting-c4

This week I decided to look up C4 Models and I found a blog that talked about what C4. This blog post called “getting started with C4” by Mike Minutillo talks about what the C4 model is. The C4 model is a way to let users communicate and describe software architecture. This is really good because when working in a group and asked to draw out the architecture of your code besides having everyone draw up a different drawing than each other everyone would have the same kind of structure across the board. C4 models is a toolbox that allows the team various well-defined layers of abstraction to develop and communicate the static structure of a solution. He then goes and talks about what the toolbox is and abstractly it is a software system that is made up of one or more containers, each of those contain one or more component which in turn implements one or more classes. With C4 there are 4 different levels of abstractions. Context, Container, Component, and Class (which is why I guess it’s called the C4. Makes sense, right?) Context shows key systems, the dependencies between them and the actors that access them. Container shows the high-level technology choices, how systems are decomposed into containers and how those containers communicate. Component shows the internal structure of a container and how it is decomposed into collaborating components. And finally class is a typical UML class diagram showing the internal structure of a component.

Why I like this blog is that in the blog Mike tells the readers step by step how these C4 diagrams are made and the perks of using it. They are very similar to UML diagrams so that way when showing these to the customer it would be easy for them to understand what you are writing and also I like this a little bit more because I feel like with the C4 diagrams they are more meant for programmers to share with each other and if someone were to join the project later on they would look at the C4 diagram and would not be lost on what to do. I think it is great that we have many ways to show our work besides UML diagrams and we are not stuck into one way of showing things and I would be using these types of diagrams in the future. This would be useful for future project in class and even when I move onto bigger and better things.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Source: http://www.softwaretestinghelp.com/web-application-testing/

This week I decided to look up different types of testing and I found a blog that talked about web testing. This website called software testing help had a blog that talked about web application testing and it gave a complete guide about testing web applications. I tried to find who the author of the post is but I could not find the name but the author talks about some web testing cheklist that programmers should go through before deploying their website. Which are

 1) functionality testing:

you should test your website to make sure that all of the links, forms, cookies, html, css, and database all work fine. It is important to make sure that the links are not broken links and that the code that you want to display onto the website are displayed correctly and in the right position.

2) Usability testing:

The usability test means that the website should be easy to use, any and all instructions that are on the website should be clear. There should be a main menu link on every page and it should be constant though out the website. You should also make sure that there are no spelling errors, all the fonts, colors, frames, etc. are all on the right setting.

3) Interface testing:

Check if the interacting between the website and the servers are functional and any errors that are given are handled properly.

4) Compatibility Testing:

Make sure that the browsing compatibility is available for all sorts of browsers and OS such as Firefox, google chrome, AOL, windows, MAC, Linux and other OS and brewers that are available today.

5) Performance testing:

You should make sure that the website can handle heavy load of traffic though the webpage so it does not crash and would be able to handle large user request simultaneously. A web stress test is to test the specific limits of the website and sees how the system reacts when it crashes and recovers from those crash.

6) Security testing:

Finally you want to make sure the security for the website especially a website that would take personal data and save it on its data base be secured enough for people to log in and feel safe that their personal information is protects.

I like this blog because right now in our class we are going to be devolving our own website and even though we are not going to have it be deployed to the public there are some testing in here that are good to remember when writing our code. In future situations when I am writing programs for websites this blog is a good reminder of what kind of tests I should do to make sure that I am doing everything before I deploy a website.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Source: https://snipcart.com/blog/tips-on-code-refactoring-from-a-former-addict

This week I decided to write about refactoring code. I found a blog written by Charles Ouellet called “tips on Code Refactoring, from a Former Addict” this blog talks about his own experience on refactoring code. Refactoring is rewriting existing code and redoing it to make it more readable and more maintainable. When Charles first started he career as a developer he had a serious refactoring addiction where it even hindered his own work and delaying him from sending out his code to the consumer. For this blog, he talks about his own perspective of what are good reasons to refactor code and what are some bad reasons to refactor code.

Some of the good reasons to refactor code is to avoid technical debt. When you write code and the business takes off after it starts to grow even more there may be new problems that arise out of it. Refactoring code can be a cheaper option of fixing the program then to write a brand-new program to do the same thing that you want it to do. Another reason why it is good to refactor code is that it can be able to teach new people that are joining the project half way though to learn the base of the code. This way it allows the new coder to see every class that is related to the application and they would be able to understand most of the code that was written before him. Finally, with technology evolving every day refactoring code to adapt to those new technology is a much cleaner and easier option to do then to write a brand-new code to adapt to the new technology that is out on the market today.

Some of the bad reasons to refactor code is to make the code look prettier. Most of the time coders would look back after a few days or weeks because the code they wrote was just ugly and wants to go back and fix it. However, that is a waste of time and money for both the coder and the company. If the code works fine you should not refactor the code just for the sake of refactoring. Another reason is to integrate new useless technology. When you are refactoring your code to integrate it for a new technology you should take a step back and think about what does this new technology bring to the table of your product and would it be worth it to even refactor the code for something that is just a one hit wonder.

I like this blog because it is from an experience developer and his own opinion of when it is good to refactor code. I think this topic is very good to learn because in school we are always changing out code to make it look nice and make sure it works so we are constantly refactoring it but in the real world we would not have the luxury to keep changing our code to make it look nice and to just re work it all together. So this blog gives you a good base of when you should refactor your code and when you shouldn’t

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Source: http://www.cigniti.com/blog/why-you-should-take-automated-testing-seriously/

This week I decided to write about Test Automation. I found a blog that talked about Test Automation. However I have never heard of test automation before so I had to do some research and find out what it was at 1^st. from what I read online test automation is basically testing programs by using other testing software outside of the application itself. Test automation has been around ever since the computer industry has been out. Testing is not like what programmers do where they just run their code in different situations and different fields and input and outputs. These test automations were people who were dedicated to testing out software not like debugging it but running it though tests. This was a much larger and more complex system that even was to be thought of as a discipline worthy of study apart from programming.  With testing it was not just some AI testing the programming for incidentally, accidently but inherently for human errors and human interaction with the program. Test automation cannot reproduce the thinking that testers do when they conceive of tests, control tests, modify tests, and observe and evaluate the product. Test automation cannot perform sapient testing. Therefore, automation of testing does NOT mean automation of the service provided by the software tester. With Test Automation it should not be programmers testing out the code themselves and seeing if things work but people who have no idea about what they are working with or doing to test these codes and seeing how human action affects the program they are using.

This topic I read was kind of interesting because it talks a bit about what the first testing there was in the computer science world. To me I think that this kind of testing should be used a bit more because I don’t think that the people who are writing the code should test it all the time because there could be mistakes that you don’t notice and especially programs that are going to be used for the public having someone who has no idea about what code is and how to read it test out the program is useful. I think I would use this in real life situation when doing testing for code I write because like people say old but gold.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.