Our second sprint mainly consisted of reviewing the source code of the Ampath application.  The first of our 4 meetings was uneventful, because only 2 of our 5 members were present.  During the other 3 meetings, we worked with one of the other development teams to review the services within the application, reviewed the ReST API, and discussed how we might be able to utilize them in our own work.  Our team then accepted the task of implementing offline encryption for the application, and got in contact with some of the people at Ampath to get their input on their preferred encryption libraries.

Our team members collaborated well with one another and the other development team we worked with.  We were able to gain more of an understanding of how the Ampath application works, through our reviews, and we were able to begin planning our course of action as we head into the coming sprints.  We devoted a majority of this sprint to review and planning, so we have yet to start working on any kind implementation.  We hope to begin coding once we have some more structure and concrete direction, in the next sprint.

Toward the end of the sprint, we began working on the offline encryption task and we found 3 suitable libraries that we could use in our implementation.  We wanted input from the Ampath people before we chose a library to begin working with, so we sent them the 3 that we selected.  In their response, they commented on the fact that the encryption library ‘forge’ seems to be the most popular on GitHub, but stated that we could use whichever one we think would work best.  We will likely make our decision in the next meeting.  In our correspondence with the people at Ampath, we were also provided the main ReST API calls that are used within the application.  This will be extremely useful in the future when we have to begin sending and retrieving medical data in the implementation of the other offline features.

It was, once again, a fairly straight forward sprint.  I think that all of the development teams could use a bit more direction right now, but the coming sprints will certainly be more productive now that we are more familiar with our team members and the application itself.  I have so far been enjoying the Scrum development cycle and I look forward to beginning implementation.

From the blog CS@Worcester – by Ryan Marcelonis and used with permission of the author. All other rights reserved by the author.

I choose this topic because i wanted to know more about it, how it works and why developers choose to follow this style than our normal JavaScript style. Also to help me understand and do the coding for the duck simulator in typescript on design pattern.

TypeScript starts from the same syntax and semantics that millions of JavaScript developers know today. Use existing JavaScript code, incorporate popular JavaScript libraries, and call TypeScript code from JavaScript.

TypeScript compiles to clean, simple JavaScript code which runs on any browser, in Node.js, or in any JavaScript engine that supports ECMAScript 3 (or newer).

Types enable JavaScript developers to use highly-productive development tools and practices like static checking and code refactoring when developing JavaScript applications.

Types are optional, and type inference allows a few type annotations to make a big difference to the static verification of your code. Types let you define interfaces between software components and gain insights into the behavior of existing JavaScript libraries.

TypeScript offers support for the latest and evolving JavaScript features, including those from ECMAScript 2015 and future proposals, like async functions and decorators, to help build robust components.

These features are available at development time for high-confidence app development, but are compiled into simple JavaScript that targets ECMAScript 3 (or newer) environments.

Examples of typescript

The global variable foo contains the number of widgets present.

Code

console.log("Half the number of widgets is " + (foo / 2));

Declaration

Use declare var to declare variables. If the variable is read-only, you can use declare const. You can also use declare let if the variable is block-scoped.

/** The number of widgets present */
declare var foo: number;

Global Functions

Documentation

You can call the function greet with a string to show a greeting to the user.

Code

greet("hello, world");

Declaration

Use declare function to declare functions.

declare function greet(greeting: string): void;

Objects with Properties

Documentation

The global variable myLib has a function makeGreeting for creating greetings, and a property numberOfGreetings indicating the number of greetings made so far.

Code

let result = myLib.makeGreeting("hello, world");
console.log("The computed greeting is:" + result);

let count = myLib.numberOfGreetings;

Declaration

Use declare namespace to describe types or values accessed by dotted notation.

declare namespace myLib {
    function makeGreeting(s: string): string;
    let numberOfGreetings: number;
}

After learning and observing. I found out that this is way better than then normal javascipting coding. The reason why is say that is because with the typescript , i kind of like dealing with class (objects) like java coding which makes it easier for me. I like how things are organized and it also readable. I guess with this my coding will be javascript/typescript will be fun and cleaned. I really hope pupils enjoy this post and also research more about typescript.

link :: https://www.typescriptlang.org/

https://www.typescriptlang.org/docs/handbook/declaration-files/by-example.html

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.

Link to blog: https://blog.codecentric.de/en/2016/01/writing-better-tests-junit/

In this blog written by Tobias Goeschel, he makes the arguement that in order to create a readable, maintainable, and useful test suite, we need to change our testing habits by focusing on behavior instead of implementation. Throughout his blog, he outlines some of the aspects that are needed to understand on how to write better tests with J-Unit.

The Value of Test Code

Goeschel states that writing fast, bug-free code is easy, if it’s not too complex, written once, and never touched again. In order to keep the code in high quality and maintainable as possible, you need tests because they allow you to makes changes in the design and architecture, without damaging the behavior. Well written tests will reveal how to access the API, what data is suppose to go in and out, what possible variations of an expected behavior exists, what kind of exceptions might occur, how the individual parts of the system interact with others, examples of a working system configuration, and what the customer expects the software to do.

Test Behavior not Implementation

Goeschel states that we create fragile tests if we set our testing focus on implementation. He then defines behavior as “the range of actions and mannerisms made by individuals, organisms, systems, or artificial entities in conjunction with themselves or their environment.” He specifically highlights that “range of actions and mannerisms” explicitly limits our view to what is observable from the outside. The tests will become more flexible if we refrain from disclosing internals and phrase the tests accordingly.

Group Tests by Context

In order to keep tests organized, we need to make sure that test methods should be grouped closely together. This is important because it helps find each single test, and to understand the behavior of the system much more quickly and easily.

Enforce a Single Assertion Rule

It is important that we try to limit each test method to a single assertion because it makes the code easier to read by assigning meaning to an anonymous block of assert statements.

Choose Meaningful Names

Applying variables and names to method names are important as well. This means that avoiding names like “a”, “test1”, “data” or anything like those names would be best.

Avoid Complex Configuration 

Avoiding complex or bloated configuration promotes fast tests. It applies to extensive use of dependency injection frameworks like Spring. A better way is to declare dependencies explicitly.

Avoid Test Inheritance 

If tests depend on each other, we make it harder and more tedious to change our system. We don’t want our tests to introduce additional dependencies to the code base we create. Inheritance introduces performance problems when working with JUnit.

Overall, Goeschel’s outline of writing better tests with JUnit was very clear and concise as he highlighted the six key actions when performing the JUnit tests. I chose this blog because I was a little unclear about the nature of how JUnit tests are done. This blog made me understand on how effectively test with JUnit. Understanding JUnit may help me in my future career field if video game development because it is another type of test that I can implement when I run and test my gaming software.

From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.

In this blog post, Justin Albano talks about the basic Strategy pattern and the “fundamental principles that make for solid strategy implementations.” He also goes into the use of Dependency Injection (DI) “to select a strategy implementation” along with a walkthrough of a basic payment system using the Strategy pattern.

The purpose of the Strategy pattern is “to decide the algorithm used in a specific context” by encapsulate algorithms into classes with the same interface, and by using the same interface, we allow the algorithms to be interchangeable based on what is needed. The following is a UML class diagram of the Strategy pattern:

The way the author makes sense of the Strategy pattern is to see the Context class as a desk, “where the Strategy interface represents a slot in the desk that accepts drawers” and each the concrete strategy implementations “can be thought of as actual drawers, where some are completely undivided, and others have various divider configurations; some may be good at storing papers, while others may be better at organizing pens, pencils, and paper clips. Each serves its own purpose and excels in a specific context, but vary only in their internal configuration: The external configuration of each drawer is the same so that it can be accepted by the desk.”

I selected this article because I wanted to learn more about the Strategy patterns, and design patterns as a whole. This post had topics that I didn’t know about like Dependency Injection, using the Introduce Parameter Object refactoring technique. It also goes well into detail an implementation of a payment system showing both the Strategy pattern and Factory pattern. I feel my knowledge of the Strategy pattern has improved after reading this article, and seeing it implemented in a new way helps me understand it more. The author is very detailed and explains the topic clearly. I learned about the importance of selecting the appropriate strategy, whether it’s more appropriate to have a run-time selection (a conditional run-time selection will require logic whose complexity is proportional to the number of possible concrete strategies) or a static selection (Strategy is selected once when the application starts-up and is never reinitialized for the duration of the execution of the application. I plan on using the Strategy pattern when I am developing software, the Strategy pattern has many uses in the world of software development and will continue to be utilized.

The post Java: The Strategy Pattern 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.

Over the past few weeks reading about unit testing, I’ve come across a few articles and blogs claiming that unit testing is not the most efficient way to ensure code accuracy and quality. I’ve been under the impression that unit testing is always a good idea, so I wanted to read about Robert Martin aka Uncle Bob’s input regarding this subject. He is a reputable computer programmer and the author of the well-received book “Clean Coder.” The following is a brief summary, along with my personal takeaways, from one of Bob’s blogs entitled First-Class Tests.

Bob is critiquing a TechBeacon blog where the author is condemning unit testing as bad practice. It seems to me that the TechBeacon blog author has claimed to “give up” unit testing for something that he calls “system testing.” But Bob insists that the TechBeacon author is not only running his tests in an inefficient way, but using improper terminology as well.

Bob gives a few definitions of different types of testing, some of which seem to contradict the views of the TechBeacon blog author. First, he explains that unit tests are written to ensure that the code is doing what the programmer intends it to do. Bob then gives his definition of system testing, stating it is not what the TechBeacon author believes it to be. System testing, according to Bob, are “plumbing” tests to ensure the internal workings of the entire integrated system is working as expected. This is in contradiction to the TechBeacon blog who claims he is running “system tests.” Bob claims what is actually being run here is “user-interface to database” functional tests, which are, in actuality, slow unit tests. I agree with Bob’s terminology here; it seems to coincide with what we’ve learned in class regarding unit testing thus far, some of which I’ve discussed in some of my previous blogs.

I believe the main point that Bob is trying to get across is that it seems many people tend to have the wrong idea of what unit testing is. If someone is writing unit tests that rely too heavily on outside resources, for example, it can slow down and hinder the whole purpose of testing software. It can make unit testing seem inefficient, when in actuality is the result of badly written unit tests. He stresses that programmers should not be trying to think of ways to circumvent unit testing. Instead, we should find ways to write unit tests as efficient, clean, and self-sufficent as possible.

I truly enjoyed reading Bob’s blog regarding his opinion on unit testing. I found it both amusing and informative. Bob leaves us with a final thought; we ought to treat our unit tests as “first-class citizens.” I will strive to do this throughout my professional career based on the advice he has given in his blog: I will avoid coupling unit tests with outside resources and make great efforts to always keep my unit test code “clean” and up-to-date.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.