The pattern I chose this week I thought was interesting from the name. The name is what initially made me want to check out the pattern ‘Sustainable Motivations”. As it would turn out this pattern really resonated with me. Sustainable motivations talks about how you can develop you skills less effectively if you are… Continue Reading →

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

Well a not so wonderful start to my Ampath adventure and I think that is putting it lightly. My first experience was filled with errors, problems, and set backs. However what was important in this time of stress was to remain calm and not let me mental dwindle. I was consistently frustrated first trying to… Continue Reading →

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

There is a reason that parents wait to buy their children the newest iPhone, or the most expensive toys when they are younger. The reason is they wouldn’t want their children to break those items that they have spent so much money on. This analogy is sort of like new coders and projects, and more… Continue Reading →

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

Atul Gawande talks in great detail about his experience with Epic and the experience of others that he has talked with. Atul if a surgeon so his direct experience would differ from someone like Sadoughi who is a primary care doctor. He went on to explain what epic was, and that was a system that… Continue Reading →

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

https://dzone.com/articles/whos-been-naughty-whos-been-nice-santa-gives-you-j

Since Christmas was just past I was wondering how Santa could handle so much data so quickly. This blog post seems to suggest that through the use of Java and Speedment is how he accesses this database of children and presents. Speedment is a software tool for enterprises that run Java applications and relational databases. It works by creating a virtual data object, retrieving only the data the application needs when it needs it. What it does is reduces the amount of develop time, increases data access, and builds a better infrastructure. How would Santa use Speedment though? Well he would implement Speedment into java code and call on his database of children in order to gather the information he needed.

An Example:

. var niceChildren = children.stream()

. filter(Child.NICE.isTrue())

. sorted(Child.COUNTRY.comparator())

. collect(Collectors.toList());

This stream will yield a long list containing only the kids that have been nice. To enable Santa to optimize his delivery route, the list is sorted by country of residence. What is exciting about a Java application like this is you can create code that easily checks on a database. I had created a SQLite program earlier in the year and the way the code was built felt clunky. In the case of Speedment you can do this process smoother. In terms of software development when looking into database access Speedment seems like a valuable tool to implement. Their website has a code generator for different databases, and languages to make sure you can quickly implement it in any program. I believe this is truly how Santa is able to access his list so quickly to make sure he can check it twice.

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

https://www.leepoint.net/GUI/structure/40mvc.html

A lot of the focus on the end of the year is around the Model View Controller pattern. Our projects have been based on it as well so it is something that we put a lot of focus on. While studying for exams I like to find relations in things that help me to remember them. I thought that the Model View Controller reminded me of a movie production. All the little pieces fitting into their spots so that the whole thing works flawlessly.

MVC, Model View Controller is like the director hierarchy of a coding project. View is similar to the camera being used in a film. It doesn’t know about the controller except for providing methods for the user to use the information. View is used to display all the information that the user needs to see. Basically a more front end version of the code. Where the controller is like the director. When the cameras are rolling the director commands what to do next. Similar to the controller which activates when the view model has a user. It also contains all the relative information to control the operation and make everything run smoothly. Finally Model which is like the set, and actors of a movie. Overall the model contains all the information that is needed for the production or program. Inside of the model is the constructor and the methods needed to be called upon. The article listed also explains the structure in simple terms: “The idea is to separate the user interface (the Presentation in the previous example) into a View (creates the display, calling the Model as necessary to get information), and Controller (responds to user requests, interacting with both the View and Controller as necessary).”

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

http://pitest.org/

Mutation testing is something that we learned the last day of classes. In a short and simple definitions mutations are seeded into your code and then tests are run on that mutated code. If the mutated code fails the tests you have then a mutation is killed, and if the mutated code passes then the mutation lived. From here you can gage what kind of quality your code is, and how well it responds to mutations. The higher percentage mutations killed the better overall quality is you code. However what are mutations exactly? Mutations are automatically modified versions of your code that make changes with the intention of making your code fail. The code that is changed is then called a mutation. The reason that you would use mutation based testing is to make sure your tests are capable of finding faults. Traditional test coverage measures only what code is executed by your test. Mutations are particularly useful in testing tests with no assertions, and partially tested code. Partially tested code being only testing certain branches of code and not all of the branches. A leading brand name and common mutation test suite is PIT what puts PIT ahead of the competition is its fast, easy to use system that is actively developed and supported. Pits UI is not complex and shows an easy to read file of mutations.

Mutation testing is a fun gimmick of a name, and also a useful tool for testing the validity of your code. Expanding beyond just expected to results but to unexpected results.

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

https://blog.usejournal.com/lean-testing-or-why-unit-tests-are-worse-than-you-think-b6500139a009

Eugen Kiss writes in his blog about some of the disadvantages of unit testing and offers an alternative to unit testing which is lean testing. His focus is about “return on investment” of using lean testing over unit testing. Basically the focus on what is being returned for the work of unit testing. The argument is that you put resources into creating a unit test for one specific outcome when lean create end to end testing that covers the critical paths that the user would actually take.

He continues to say that the problem with unit testing is inherently in coverage. The argument is made that even with 100 percent coverage the code may cover zero. Since you create code to match that of what you expect the result can be different from the user path that is actually followed. Additionally another issue he brings up is the quality of the tests “Imagine you have three components, A, B and C. You have written an extensive unit test suite to test them. Later on you decide to refactor the architecture so that functionality of B will be split among A and C. You now have two new components with different interfaces. All the unit tests are suddenly rendered useless. Some test code may be reused but all in all the entire test suite has to be rewritten.” This would cause a come back turn around where since you are rewriting the tests you are investing more time into unit testing costing more to “payback”. Finally another point of cost efficiency is when actually designing your code. You are coding with the tests in mind, and potentially making code that you don’t need to fulfill the tests.

The blog offers incite that unit testing isn’t always the best use of time and suggests that time can be better spent focusing on user interface.

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.