Tuesday, 3 November 2015

Software Test links (Including Agile Testing)

Amazon: Agile Testing: A Practical Guide for Testers and Agile Teams

Brian Marick’s testing quadrant





Documenting Architecture

amazon: Applied Software Architecture




[Soni/Nord/Hofmeister] is the first article that has propagated
the idea of specifying and architecture language with UML
 Conceptual level: Conceptual architecture (components, connectors)
 Modules interconnection architecture (modules and their connections)
 Execution architecture: runtime architecture
 Code architecture level: division of systems onto files


Monday, 2 November 2015

J2EE Application / CDI / JCache / Hazelcast

2015 JavaOne EJB/CDI Alignment




https://hazelcast.com/resources/cluster-application-using-cdi-jcache/

You created a Java EE application using a REST front-end on top of relational database using JPA. Now you need to make it highly available and scalable across a large number of machines. 

This webinar will start with a simple JAX-RS/JPA application. We will turn this standard Java EE application, step by step, into a fully clustered application using a CDI extension and producers to integrate Hazelcast, as a JCache provider. To do that we will study the data model and how to persist it efficiently.  

http://www.slideshare.net/Hazelcast/j-cache-cdi-1



Angula 1 / Angular 2 (+ Typescript)

Introducing AngularJS to Java Developers

Ext JS, YUI, and Dojo represent feature-complete frameworks. AngularJS, Backbone.js, and Ember are examples of lightweight frameworks. After years of experimenting with different frameworks and libraries we decided to stick with hugely popular AngularJS by Google.
I work in a Java shop, and one of my responsibilities is to create an conduct trainings (both internal and external). Several years ago I started to work with our engineers on the curriculum introducing AngularJS to an enterprise Java developer.
The learning curve of AngularJS is not too steep for Java developers, who understand the concept of containers, dependency injections, callbacks. They must become proficient with JavaScript with its functions, closures and other good stuff.
But equally important is to be familiar with todays tooling of a productive Web developer. Here’s a short list of tools that JavaScript developers use today:
  • npm – node package manager used for installing and managing development tools
  • yeoman – a scaffolding tool used to generate the initial structure of an application
  • bower – package manager for application dependencies
  • grunt – a build automation tool
  • A JavaScript testing framework
The next decision to make is how to communicate with the Java backend. Forget about JSP, servlets, and JSFs. Preparing HTML in your Java code is out of fashion. A Java server exchanges the JSON-formatted data with a single-page HTML/JavaScript front end, which use either AJAX techniques (old) or WebSocket protocol (new).
On the Java side we like to use such tried and true technologies as RESTful Web service and Java Messaging API.
When we hire a AngularJS/Java developer, we expect him to be familiar with at least 90% of all the above buzzwords. Finding such skilled software engineers may be difficult, so we’ve created a training program to prepare such a person.
By now, we’ve taught and fine-tuned this training class multiple times. The latest online version of this class consists of seven weekly training sessions (3.5 hours each) and seven consultations (from 30 to 60 min each). Programmers learn and gradually apply all of the above tools and techniques while working on the Online Auction application that has the following architecture:
javaauction-1
We have a great feedback from people who have completed this training. But everyone says it’s challenging. And it should be. Back in the nineties a person who knew one of the programming languages plus SQL could relatively easy get a well paid job. Not anymore.

Angular 2 versus React: There Will Be Blood

Wednesday, 14 October 2015

TechRepublic: Samsung Architecture for Multimodal Interactions -> IoT + JVM

Samsung Wants to Help IoT Speak a Common Language

TechRepublic: What does SAMI stand for? Is it an acronym or something?
Dubreuil: SAMI is an acronym for Samsung Architecture for Multimodal Interactions. It’s our shorthand for what we call a data-driven platform with simple open APIs and SDKs to send and receive diverse data. We’ve tried to make it dead simple for developers to execute REST API calls to SAMI or set up WebSockets to receive data in real time.
It’s based on three big ideas critical to success in the cloud: users always own their own data, it’s a fully open ecosystem, and it’s data and device agnostic.
TechRepublic: What is Samsung’s goal with SAMI in IoT?
Dubreuil: Many developers are coming up with brilliant ideas for new devices that digitize our physical world and to capture existing or new signals that have never been available in digital form. But they carry the burden of always having to create new, complex back-end systems for receiving and processing device data from diverse sources.
Besides the time required to build the full stack from device to cloud to data services—and ensure privacy and security—too often, the end result is a device with its own proprietary cloud interfaces and siloed data.
And that is an IoT solution that has isolated itself from opportunities to correlate and fuse data with other IoT devices.
This, of course, defeats the benefits of IoT. For Samsung’s Strategy and Innovation Center, it’s the opportunity to join all of the data among IoT devices that has the highest upside for user value.



Wednesday, 23 September 2015

Software Security links



Does DevOps hurt or help security?



While security processes tests always should be an integral part of DevOps workflow, that isn’t a reality for many organizations. They’ve always struggled to properly integrate security, and those challenges certainly persist through transitions to DevOps. But Storms says that DevOps provides an opportunity to more tightly couple security into the workflow. “One of the best ways to bring DevOps and security together is to utilize the tools and the processes that DevOps really excels at and apply them to security,” he says — “things like automation, orchestration, and instrumentation. Let's use those tools to build these closed-loop security systems where everything's automated and everything's predictable. That’s a way we actually can fulfill the security requirements in an automated fashion with fewer resources.”

One success story that Storms cites is a healthcare company in the Northeast. “It has had serious compliance and security requirements so it performs continuous deployment. The company has extensively automated its security and compliance tests and the auditors are happy,” he says.

Friday, 18 September 2015

Hadoop, Spark, Storm (and ecosystem) links



What MapReduce can't do

We discuss here a large class of big data problems where MapReduce can't be used - not in a straightforward way at least - and we propose a rather simple analytic, statistical solution.MapReduce is a technique that splits big data sets into many smaller ones, process each small data set separately (but simultaneously) on different servers or computers, then gather and aggregate the results of all the sub-processes to produce the final answer. Such a distributed architecture allows you to process big data sets 1,000 times faster than traditional (non-distributed) designs, if you use 1,000 servers and split the main process into 1,000 sub-processes.MapReduce works very well in contexts where variables or observations are processed one by one. For instance, you analyze 1 terabyte of text data, and you want to compute the frequencies of all keywords found in your data. You can divide the 1 terabyte into 1,000 data sets, each 1 gigabyte. Now you produce 1,000 keyword frequency tables (one for each subset) and aggregate them to produce a final table.However, when you need to process variables or data sets jointly, that is 2 by 2 or or 3 by 3, MapReduce offers no benefit over non-distributed architectures. One must come with a more sophisticated solution.

Here we are talking about self-joining 10,000 data sets with themselves, each data set being a time series of 5 or 10 observations. My point in my article is that the distributed architecture of Map Reduce does not bring any smart processing of these computations. Just brute force (better than a non-parallel approach, sure) but totally incapable of removing the very massive redundancy involved in these computations (as well as in storage redundancy, since the same data set must be stored on a bunch of servers to allow for the computations of all cross-correlations).


This underscores the importance of a major upcoming change to Hadoop - the introduction of YARN which will open up Hadoop's distributed data and compute framework for use with non-MapReduce paradigms and frameworks.   One such example - RushAnalytics which, incidentally, also adds fine-grained parallelism within each node of a cluster.