My name is Timothy Kmiec, I am a senior at Worcester State University and this will be my blog site during Spring 2018 semester for CS-448.
From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.
CS448-02 Spring 2018 semester test blog post.
From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.
This is the blog I will be using for this course.
From the blog CS@Worcester – orscsblog by orscsblog and used with permission of the author. All other rights reserved by the author.
Hello everyone; this is my first blog post for the CS-448 Software Development Capstone course.
From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.
This post is to satisfy the WSU CS-448 blog entry post required for class.
From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.
Welcome to my blog, beginning January 16th, my blog will be focusing on the book, Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by David H. Hoover and Adewale Oshineye.
The post Software Development Capstone Introduction appeared first on code friendly.
From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.
I will be using this blog in the Spring 2018 semester for CS-448 and an independent study project.
From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew 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.
As my final semester approaches here at Worcester State University, I figured a relatable blog topic would be the best practices you can learn as a Software Engineer. The article can be found here: http://www.excella.com/insights/best-software-engineering-practices
This article touches upon three different practices that the author thought highly enough to include. The three practices are S.O.L.I.D., Automated Unit Testing, and continuous integration.
S.O.L.I.D. – an acronym for an object oriented design principle.
S – Single Responsibility – a class should have only a single responsibility.
O – Open/Closed Principle – Software should be open for extension, but closed for modification.
L- Liskov substitution principle – objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
I- Interface Segregation Principle – Many client-specific interfaces are better than one general-purpose interface.
D- Dependency inversion principle – One should depend upon abstractions, not concretions.
When you use all of these principle together, a developer can create code that is much easier to maintain and improve over time. The code is SOLID.
Automated Unit Testing
Automated unit testing is a software development and testing approach where you independently test units to ensure that they are operating correctly. Unit testing can be done manually and it was in the past, but automation has taken over and everyone is thankful for that.
I use JUnit in eclipse to test java programs continuously. It makes it very easy to track where there is an error and what caused it to happen.
Developers become much more confident in their work when they don’t have to worry about wasting a bunch of time finding errors, instead we test immediately and fix the problem before it gets too clustered.
Continuous Integration
Continuous Integration quite literally means that you continuously ingrate the code and fixing issues before they are submitted to the actual project repository. In my classes we used Github or GitLab to manage repositories.
It works by a developer checking new code submissions in the repository. The integration process then builds and runs tests while analyzing the code. The CI detects any problems with the code and gives feedback to the developer. The developer fixes them and then approves the changes to the code. This way no code ever gets broken.
One of the benefits about using Continuous integration is that the version control system holds all current and changed code. You can easily go back to see what changed and how something may have broke.
From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.