What I've learned this week?: March 2017

Sunday, 26 March 2017

This week 6/2017

I did fast research of Vue.js (v. 2.2.2) and I'd like to summary what I got to know about it and how it presents itself in compared to Angular 2 and what I think about it.

1. Performance

Project krausest/js-framework-benchmark tested over 20 JavaScript frameworks, below are results.

src: js-frameworks-benchmark4

As you can see in most cases Angular 2 is slower than Vue.js.

2. Size of attached scripts.

In my case small Angular 2 project with 3 additional modules takes 800kb (prod version and after minification). I wonder to know what will be the size with Vue.js. I found comparison of raw frameworks on Vuejs's web side. Vue.js size is about 23kb but Angular 2 about 50kb. It's really interesting....

3. Learning curve

The creators of Vue framework estimate that it is possible to learn their framework in one day or faster if you know AngularJs. I will see ...

In my opinion to learn Angular 2 in one day is impossible. The same is with AngularJs but I think it was easier then with Angular 2.

4. Testing
On project web page unit testing looks similar to Angular Js or Angular 2 unit.

Resources:

This week 5/2017

In this article I'd like to collect some ideas connected with Microservice Architecture.

1. Bounded context and organisational aspect.
In many sources there is recommendation to create small teams dedicated to one or a few microservices. One microservice should resolve a problem of one bounded context. A small team should well understand implemented part of domain (bounded domain) and should gather maximum "two-pizza team".

2. Possibility to scaling every service of application.

Microservice architecture requires usage of many servers, that's why they have to be monitored and managed centrally. On each server works one instance of service but if we need more instances it is very easy to install it on more servers. This way it is possible to start new instance of service and shut down it if it is needless. Another advantage of Microservice is that small application boot faster than big monolith and it is easy to deploy new code without outage.

3. Duplication of code

There is common opinion that much easier is to control monolith than Microservices. Martin Fowler recommends to try resolve business problem in monolith architecture and then eventually move into microservices. However this style have become fashionable and everyone tries his hands at it and it has nothing common to do with business needs... During migration process there is a lot of duplicated code between services. It could be also big problem. However my idea is to move shared parts of code into small utils jars.

4. Latency time & lack of consistent = additional complexity

Common question is how to get consistency and availability concurrently? Answer is sad but it is impossible. Consistency requires to have shared database where every business operation locks updated or removed record.
However, firstly we have to remember that coding, transmitting and decoding message takes time, especially if services are situated in worldwide locations, transmission has significant influence.
Secondly, fault tolerant services move task to available instance of service.
Then, to have hight performance every service has its own database or even every instance of service. That's why in most cases there is used optimistic locking, data partitioning or CQRS and Event Sourcing. Sometimes it is not enough and some business decisions are required to be ready for border conditionals, ex. hotel's room reservation problem.

5. Interface development - contract problem
This subject is good known for SOA and Microservices as well. The common solution for SOA is to use the same wsdl file for producer and consumer but what if we have many different consumers and we need to extend our interface without engaging teams responsible for immutable services?
There is one way to do that - Consumer-Driven Contract. This approach requires to use only needed fields and inform producer about customer schema.

Resources:

Sunday, 5 March 2017

This week 4/2017

This post collects some of my experiences about creating E2E test in protractor using TypeScript for AngularJs page.

At the beginning, it is required to prepare protractor (v4.0.9) configuration. Mine is below.

exports.config = {
  specs: [
    './e2e/angularjs/**/*.e2e-spec.ts'
  ],
  capabilities: {
    'browserName': 'chrome',
  },
  directConnect: true,
  baseUrl: 'http://localhost:8080/test/',

  framework: 'jasmine',
  rootElement: 'html',
  jasmineNodeOpts: {
        // If true, display spec names.
        isVerbose: true,
        // If true, print colors to the terminal.
        showColors: true,
        // If true, include stack traces in failures.
        includeStackTrace: true,
        // Default time to wait in ms before a test fails.
        defaultTimeoutInterval: 120000
  },
  // compile ts files before run test
  beforeLaunch: function() {
    require('ts-node').register({
      project: 'e2e'
    });
  }
};

In my case I have application which isn't single-page application but every functionality requires to load separate page. However I am going to change it if I find free time.

My notices & tips:

It is good to create a utils class with static methods.
Create one shared authorization method to use it in all tests.
For some test it is good to logout and even clean cookies. It is possible by code: browser.driver.manage().deleteAllCookies();
Sometimes it is good to create screen shot. It is easy to do it.

browser.takeScreenshot().then((png) => {
  let date = new Date();
  let path = './target/_test-output'
  if(!existsSync(path)){
    mkdirSync(path);
  }
  let stream = createWriteStream(path + '/test_' + date.getTime() + '.png');
  stream.write(new Buffer(png, 'base64'));
  stream.end();
});

In configuration file it is good to set long enough timeout interval. I assumed 2 minutes. It is possible to set other, then default 11 sec, timeout in synchronisation mode - parameter allScriptsTimeout.
Look out if you use $timeout. Some demon task can lock synchronisation and test will fail on timeout. Better use $interval.
If you don't use synchronisation, warm up your application before test or set sleep time before each action loading data from server. Ex. My application load dictionaries from db but all constant values are archived in cache. Loading from db is of course much longer then from cache. It is important to remember about it.
Some examples of css selectors:

td:nth-child(2) input
td:nth-child(1) img#saveButton
input[title="Is active?"]

Friday, 3 March 2017

This week 3/2017

This week I spent a little time during my sickness for exploration of Apache's Big Data tools, ex.

Apache Zeppelin
Apache Hadoop
Apache Spark.

Apache Zeppelin is some kind of notebook which allows to get data from supported repositories, ex Spark, Cassandra and jdbc or postgres data source, and process them as a task in notes. You have to configure only connection in XML or by GUI. Zeppelin support a few kinds of presenting data, ex. Table, grids, diagrams.

Hadoop and Spark are used to distributed data processing. Spark is the new idea of that processing and use mainly distributed memory instead of distributed storage as Hadoop. This solution allows Spark to be up to 100 times faster than Hadoop, because as noticed 90% of time consume reading from and writing to storage.

How works distributed processing?

At the beginning there is a cluster with hundreds or thousands of servers. We have to count one hundred arithmetic task. To be fast and fault tolerant, master node of cluster split task between ex. 200 servers. The same task is resolved on two separated machines. If on would fail, the second one will return us solution. In the end main node collect solutions and return them to client.

Hadoop and Spark are used to processing big data by programing model MapReduce. MapReduce retrieves useful data from huge volume of data archived in Big Data resources as nosql databases, files and other resources.

In my case I prepared a small input file and implemented:

- data producer - class which retrieves interesting data from each row of my file.

- mapReducer - class which implements algorithm of aggregate for data retrieved by producer.

Then I need only execute my classes by hadoop.

If you impression after my article is that Hadoop and Spark are the same tools with a little differences, you are in the wrong. I am not an expert in that subject and I have just written about main differences. My little experience is that are different tools with different modules. Of course probably some of them are shared.

Resources: