sexta-feira, 27 de maio de 2016

Vert.x an event-driven application framework

Vert.x is an asynchronous event-driven platform  (paradigm where the program flow is determinate by events like user actions) where is possible creating web applications.

It processes all I/O using Netty. Therefore, it is meaningless to verify differences of the performance between Vert.x and Netty.

Vert.x is a server framework that provides API and functions different and independent from Netty, designed with different purpose from Netty.

Netty is a framework that can process the low-level I/O and Vert.x can process the higher-level I/O than Netty.

Vert.x is similar the Node.js and Akka, run in the JVM, is scalable, concurrent, non-blocking, distributed and polyglot.

  •        Each component is called verticle.

  •       Vertx can scale when create more instances of verticle.

  •       Vert.x treats its verticle as an 'actor' of the Actor model.

  •       Each verticle runs simultaneously on a separate thread single.

  •       There is no state that is being shared between the Verticle.

  •       Uses Event-bus as the Vert.x core.





The Event-bus is a system message that work like JMS.

All communication between Verticle happens through Event-Bus.

Verticle can publish or listen event in an address on event-bus

The Vert.x Event-Bus supports point-to-point, pub-sub, and request-response messages.

The numbers of event-loops are created by default with the number of CPU core.

If a verticle's event-handler for example has some I/O operations heavy, it may take time until

If the event-handler verticle has, for example, some I / O heavy implemented that may take some time to complete, it will block the event-loop.



All event messages will not be delivered to other verticle operating in the same event-Loop to the previous handler was completed

A single event loop serving a high volume of connections via an asynchronous programing model.

Most of the real work is done in a pool of background threads.

Vert.x does not block 100 concurrent long running requests.


Core API:
  • TCP/SSL clients and servers
  • HTTP/HTTPS clients and servers including Web Sockets
  • Event Bus
  • File System
  • 100% asynchronous


Mainly provides asynchronous API.

A general-purpose application framework running in JVM

Very performative, asynchronous APIs, event-driven, on-blocking (asynchronous I/O is a form of input/output processing that permits other processing to continue before the transmission has finished.)
Highly scalable but also easy to implement concurrency.

Polyglot, are possible use Java,JS, Ruby, Groovy, Python, Scalam Clojure and Ceylon.

Use all available cores on a single machine

A verticle never gets executed by more than one thread concurrently.

No race conditions, no deadlock. You write your code as single threaded.

Is good for:
  •   Real-time Analytics dashboard 
  • Big data queries and task coordination






--------Comparison---------

Vert.x Vs NodeJS

Polyglot - JS
JVM      - V8
Huge ecosystem of Java Libraries - big ecosystem of node modules
Small community - big community
-----------------

References:




















terça-feira, 24 de maio de 2016

CouchDB on Amazon Linux - Ec2


Steps to install CouchDb on Amazon Linux

1. Change the first entry to:
-> sudo vim /etc/yum.repos.d/epel.repo
-> enabled=1

2. update all packges
-> sudo yum update

3.update develops packages 
-> sudo yum groupinstall "Development Tools"

4. necessary tools
-> sudo yum install perl-Test-Harness erlang-erts erlang-os_mon erlang-eunit libicu-devel autoconf-archive curl-devel erlang-etap erlang-asn1 erlang-xmerl js-devel

5. download couch
-> wget http://mirror.ox.ac.uk/sites/rsync.apache.org/couchdb/source/1.6.1/apache-couchdb-1.6.1.tar.gz

6. extract 
-> tar zxvf apache-couchdb-1.6.1.tar.gz

7. go to folder  apache-couchdb-1.6.1 and execute
-> ./configure --with-erlang=/usr/lib64/erlang/usr/include
-> make
-> sudo make install

8. create user and give permission:
-> sudo adduser -r --home /usr/local/var/lib/couchdb -M --shell /bin/bash --comment "CouchDB Administrator" couchdb
-> sudo chown -R couchdb:couchdb /usr/local/etc/couchdb
-> sudo chown -R couchdb:couchdb /usr/local/var/lib/couchdb
-> sudo chown -R couchdb:couchdb /usr/local/var/log/couchdb
-> sudo chown -R couchdb:couchdb /usr/local/var/run/couchdb
-> sudo chown -R couchdb:couchdb /usr/local/lib/couchdb
-> sudo chmod 0770 /usr/local/etc/couchdb
-> sudo chmod 0770 /usr/local/var/lib/couchdb
-> sudo chmod 0770 /usr/local/var/log/couchdb
-> sudo chmod 0770 /usr/local/var/run/couchdb
-> sudo ln -s /usr/local/etc/rc.d/couchdb /etc/init.d/couchdb

9. start couch
->  sudo /usr/local/etc/rc.d/couchdb start

10. check if everything are working
-> ps aux | grep couchdb
->  curl http://localhost:5984

result should be:

{"couchdb":"Welcome","uuid":"8ea450411a2d8caaad12d2bb23386079","version":"1.6.1","vendor":{"name":"The Apache Software Foundation","version":"1.6.1"}}





segunda-feira, 16 de maio de 2016

Domain Driven Design - Key Benefits - DDD

Domain Driven Design is a software methodology appropriate for a particular type of application where there is significant complexity and has an important focus of a business model well defined.
DDD is a disciplined way to create a Domain Model, that's all. The focus of the technique is to create a domain that speaks the user language.
Key Points:
  • Common language between developer and business person.
  • Precise communication.
  • Provides a business view to the developer, spreads knowledge between the team.
  • Eric Evan recommends a layered architecture with: Presentation, Application, Domain, and Infrastructure.
  • The purpose of Domain Driven Design is to create better software, focusing on a domain model, rather than the technology.
  • The software is guided by domain and not by the UI.
  • DDD is a way to make them more manageable complex systems, better understands avoiding a classic ball of mud.
  • Experiment a lot and expect to make lots of mistakes. Modeling is a creative process.
Keep in mind some of the pitfalls of domain modeling:
  • Domain work is difficult and requires a lot of knowledge not necessarily related technical skills.
  • Domain modeling requires knowledge processing the business.
  • Developers tend to create models with concepts that seem superficial to domain experts.
  • It requires an iterative development process and continuous refactoring. This is hard for some companies and can become expensive.
  • DDD cannot help or don't bring benefit if the software is very generic.
  • Bad nomenclatures can harm the DDD.
  • Lack of domain is one of the main reasons for the DDD fail.
  • Lack of core domain helps to fail in the implementation of DDD.
  • Framework and Library can confuse the implementation of DDD.
  • It is necessary to have an implementation strategy (DesignBoundaries).
  • Don't try to apply DDD to everything. Draw a context map and decide on where you will make a push for DDD and where you will not. And then don't worry about it outside those boundaries.
  • Focus on specific scenarios. Abstract thought has to be agreed in individual cases.
DDD is not a silver bullet for all application development, it only helps manage complexity, where the complexity comes from the domain.
It all comes down to the complexity of the behavior in your system. If you have complicated and ever-changing business rules involving validation, calculations, and derivations you’ll want an object model.
Erick Evans Sentences:
  • A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving problem at hand and ignores extraneous detail.
  • A domain model is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of that knowledge
  • We need to decouple the domain object from other functions of the system, so we can avoid confusing the domain concepts with other concepts
  • The domain layer is the heart of the software and this is where the interesting stuff happens
  • In DDD, we don’t consider any databases.
  • DDD is all about the domain, not about the database, and Persistence Ignorance is a very important aspect of DDD

All that I  put here in this post are some phases, some conclusions, some links that I used in my studies about DDD. 
References and Interesting links:

segunda-feira, 9 de maio de 2016

Refactoring

O refactoring é uma técnica disciplinada de reestruturação de código que consiste em mudar o a estrutura, sem alterar o comportamento do código.
Cada transformação deve ser feita em pequeno escala, mas o conjuto dessa traformações podem produzir uma estrutura significativa.
Se a traformação for pequena, é menos provável que essa alteração de errado.
A consequência é a melhora do design,reduz a complexidade para melhorar a manutenção de código fonte, e a partir daí da legibilidade, de porções de código que sem refactoring se deteriorariam.
Outra consequência é a melhora no entendimento do código, o que facilita a manutenção e evita a inclusão de defeitos.
Geralmente é motivada por alguns code smells, como por exemplo: - metodos muito longos - código duplicados
Antes de começar uma refatoração em um código é importante ter testes unitários, onde esses testes servirão para garantir que o comportamento do modulo está funcionado corretamente.
Então TDD está totalmente ligado a refactoring.
Podemos dizer que o refactoring é um ciclo interativo de trasformar o código e testa-lo para garantir a exatidão, e fazer outra pequena alteração.
Se qualquer teste falhar podemos desfazer a ultima alteração e repetir o processo de uma maneira diferente.




Algumas técnicas de Refactoring:
- Encapsulate Field – o código de fields principalmente de pojos deve ser acessados por metodos getters e setters.
- Tipos Genericos – criar tipos genericos para compartilhar código. - Substituir códigos de validação por tipos de State e Strategy.
- Substituir 'IFs' por polimorfismo - Quebrar código em componetes reutilizáveis com interfaces bem definidas.
- Extrair Classes - Remover excesso de metodos para Classes.
- Extrair Metodos - quebrar grandes metodos em metodos menores (como diz Uncle Bob,"Um metodo deve ser conter até 20 linhas") 
- Mover metodos e fields para classes apropriadas
- Dar nomes a metodos e fields que revelam suas finalidades.
Muitos sistema se deterioram quando não investimos tempo em limpeza e organização. Todo sistea se degrada com o tempo, a medida que novas funcionalidades são inseridas, alteradas ou erros são corrigidos. Para evitar que o código se torne uma casa suja é importante manter um refactoring de código constante, tornando o código entendivel, claro e limpo. Assim de forma sistemática e frequente estamos investido para que o software se mantenha facil de alterar e com velocidade de desenvolvimento

Referências: