Disponibilizando conhecimentos de TI!!!

segunda-feira, 11 de janeiro de 2016

Explicando o mundo AngularJS

Muitas pessoas hoje me perguntam porque usar angularjs, como aprender a usar uma framework baseada em client side e javascript?

Hoje vou apresentar o que angularjs tem como usar para iniciantes, e alguns cursos gratuitos.

Cursos gratuitos

O próprio Google libera o code School para uso e aprendizado free para aprender o AngularJS, tem também a especificação da API para aprendizado, segue abaixo:

http://campus.codeschool.com/courses/shaping-up-with-angular-js/intro
https://quizzpot.com/courses/introduccion-a-angular-js
https://docs.angularjs.org/guide/introduction

E o AngularJS, quero conhece-lo.!

Para usar o angularjs primeiramente deve-se importar a biblioteca para seu projeto, ele que te dará a chave para o universo AngularJS.

Agora vem o grande feito do AngularJS.

O acesso a todo o DOM do HTML e usar o binding das diretivas do AngularJS.

As principais:

O ng-app que da acesso ao módulo que você criou para sua aplicação.

O ng-model que cria uma instância ou variável para acessar o valor do input, entre outras tags html.

O ng-controller que da acesso ao controller criado da controller do AngularJS.

Exemplo de código:

- Criando um módulo

var myApp = angular.module('myApp');

</body>

O método module cria um módulo para sua aplicação, ele te da acesso ao universo do DOM do HTML, para manipulação e uso entre sua camada view.

A criação de uma controller para manipular os dados e criação de métodos de acesso, segue exemplo:

myApp.controller('loginController', ['$scope', 'loginService', '$state',

function($scope, loginService, $state){

Method when authetications for user approved

$scope.loginAcess = function(email, pass){

$state.go("exemplo");

};

}]);

A chamada do método e declaração da controller:

E a chamada:

Mas como consigo ter acesso aos valores digitados?

Segue a resposta:

</div>

</div>

Lembre-se que o ng-model eu crio uma variável de chamada para aquele input e com isso consigo manipular os dados.

Essa diretivas listadas, são as básicas, temos mais diretivas de uso, vou listar mas não vou detalhar, tem na documentação da API a descrição e ensinando como usar. Site: https://docs.angularjs.org/guide/introduction

- ng-bind

- ng-class

- ng-click

- ng-animate

- ng-view

- ng-repeat

Entre outras...

E porque usar?

Hoje vejo o motivo de usar o AngularJS pois facilita o uso e manipulação do DOM do HTML. Facilita e separa as camadas para que camada frontend seja frontend e backend fica totalmente backend. E não renderiza no servidor fica totalmente client side.

Caso tenham algo a acrescentar deixe um recado.

quinta-feira, 7 de janeiro de 2016

Arquitetura Mobile Hibrida

O objetivo do artigo é mostrar um pouco do conhecimento que adquiri com arquitetura mobile e porque decidi me aprofundar mais em um estilo que é a arquitetura hibrida.

O que foi usado

Após pesquisas eu cheguei a decisão de usar o Cordova com Ionic para uso juntamente com o AngularJS. E transformar toda minha parte negocial com o uso da arquitetura de micro serviços.

Html5 + css3 + Ionic + AngularJS

A ideia de usar todo o frontend na camada de webview do celular e deixá-lo de forma que pudesse ser reaproveitado, foi a grande jogada que eu decidi e escolhi.

O uso do html5, css3, ionic e angularjs facilitou a criação da estrategia das páginas, sua navegação e facilidade na criação das rotas das páginas.

Arquitetura de Microservices

Como já possuía conhecimento em Java decidi continuar com Java para a minha aplicação, usando RestEasy do Jax-RS, e juntamento com as minhas controllers de rotas, usei para minha camada negocial EJB 3.1 e na camada de persistência JPA com Hibernate.

A disponibilização dos meus métodos em formato de URI ajudou bastante, pois todo o consumo é feito via HTTP 1.1 com o retorno do meu JSON na minha camada de visão da aplicação.

A premissa da minha aplicação era ter acesso a internet e que pudéssemos ter um reaproveitamento de código, para que dessa forma pudesse ter um controle melhor das minhas alterações e a fonte fosse em um único repositório.

Conforme imagem a a ideia é ter um melhor aproveitamento de tudo, para que a arquitetura de microservice esteja bem empregado e consiga liberar um catalogo de todos os métodos e URI.

Compilação

Com o Cordova eu solicitava a compilação e já executava diretamente no emulador da framework e o aplicativo para ser testado no meu Android.

Conclusão

O sucesso eu obtive ao optar por uma arquitetura mobile hibrida, pois consegui encurtar o tempo, obtive dinâmica no meu código fonte, manutenção ficou mais e fácil e consegui atingir todas as premissas do projeto.

segunda-feira, 7 de setembro de 2015

Composição versus Herança

Muitos hoje na equipe atual que estou me perguntam qual é melhor, usar herança ou composição na escrita de seus códigos? A minha resposta é sempre a mesma depende do código que será escrito e considerar vários pontos em questão.

Temos que levar em consideração o acoplamento, a manutenção desses objetos, se estamos usando adequadamente os objetos criados, entre outros fatores. As vezes digo que na dúvida use composição e veja até que ponto sua classe será escrita corretamente e não irá fugir do objetivo que ela foi construído.

Segue a explicação de herança para compararmos com composição. Herança é um objeto É UM, onde ele estende a classe de forma que ela vira do tipo da classe, um exemplo clássico é a classe Cachorro estende Animal, então a classe Cachorro acabou de virar do tipo animal, assim herdando os vários atributos e métodos públicos.

Já a composição ela passa no teste TEM UM, a classe possuí o objeto da classe X, exemplo é a classe Ferrari tem um objeto MotorV12, quando for olhar no código tem um objeto instanciado de MotorV12 e assim por diante. Não necessariamente temos criar uma dependência da classe estendendo a mesma, podemos usar composição para acessar métodos específicos.

Após a explicação de ambos, a questão que temos sobre qual usar depende muito do código que iremos escrever, as vezes ficamos tanto na dúvida que é melhor criar de uma forma e ver até onde é benéfico e depois refatorar o código de forma que seja bem escrito. Sempre falo que composição deve ser usado com muita sabedoria pois as vezes temos instâncias de objetos que nem fazem parte da classe, ou métodos de MotorV12 na classe Volante, onde não tem nada haver.

Sempre solicito a equipe um pensar de alto nível e abstrato, as vezes o estender uma classe resolve mais que criar uma instância da classe, hoje em dia várias pessoas dizem é melhor usar composição que herança, será?

Não mesmo, pois composição e herança tem suas particularidades e nem sempre a escrita daquele código é daquele jeito mesmo. Como eu disse anteriormente tem que parar pensar e analisar, pois as vezes vale a pena escrever um código usando composição e o outro código é melhor usar herança.

Fica a dica, pare, pense, análise e depois execute....

domingo, 26 de abril de 2015

Rest Estrutura e Arquitetura

A estrutura que o Rest (Representational State Transfer) usa é do HTTP 1.1 onde o acesso a informação fica mais rápido e leve. Onde posso liberar o conteúdo a partir de qualquer estrutura, sendo ela XML, JSON, Texto puro, entre outros.

Com isso o REST herdou alguns códigos de mensagem para retorno da informação, segue:

Código 200 indica que sua requisição foi um sucesso, todo sucesso no código fonte deve-se retornar HTTP 200.
Código 201 ele deve ser a resposta de inserção de algum dado feito pelo Controller ou Collection.
Código 202 enviado para o Controller que obteve uma conexão assíncrona.
Código 204 a resposta irá mostra que intencionalmente o corpo de código foi deixado em branco.
Código 301 indica que um novo URI foi inserido para o cliente.
Código 303 resposta é enviado para retornar dados que considera opcional.
Código 304 resposta enviada para preservar o consumo da banda.
Código 307 indica que uma URI foi gerado temporariamente para o cliente consumir seu recurso.
Código 400 indica que o caminho acessado está com erro.
Código 401 indica erro que o cliente não está autorizado para o envio da requisição.
Código 402 envia para a requisição negar o recurso para o cliente.
Código 404 a requisição pode estar fora ou não existe.
Código 405 interage com o cliente a partir do momento que o cliente envia um método HTTP não suportado.
Código 406 erro retornado quando o cliente tenta solicitar tipo de dados não suportado.
Código 409 indica que o cliente tentou violar um estado do objeto.
Código 412 mostra para o cliente que uma de suas condições requisitadas não foi cumprida.
Código 415 erro mostrado quando o cliente envia dados de uma mídia não suportados.
Código 500 retorna para o cliente dizendo que possuí erro grave.

Com isso o REST determina alguns pontos de aceitação em sua camada, que são (GET, POST, DELETE, PUT, HEAD, TRACE, OPTIONS e CONNECT).

Mas para os desenvolvedores os mais usados são GET, POST, PUT e DELETE. Segue a especificação dos mais usados:

GET: Para recuperar os dados.
PUT: Alterar um dado.
POST: Para criar um dado.
DELETE: Para deletar um dado.

A arquitetura REST ela funciona para liberar uma URI, definida para o serviço de execução, e trafega os dados a partir da requisição solicitada, além de trabalhar totalmente em MVC.

Segue uma imagem:

Conforme a imagem acima posso ter qualquer camada de layout em qualquer framework FRONT-END que acesso via REST os dados solicitados.

É como se eu tivesse um Serviço Web disponível a qualquer momento, segue exemplo:

REST hoje ele pode facilitar o uso e a separação das camadas, assim podendo ter uma camada indiferente da linguagem, posso usar Python, Java, PHP, entre outras linguagens que utiliza o protocolo HTTP 1.1.

Além de executar uma arquitetura baseada em Serviço, ter um reaproveitamento de código fonte, reutilização dos métodos e menos trabalho a partir de um tempo de execução da arquitetura.

Rest tem alguns padrões a serem seguidos:

Designer de caminhos:

Cada segmento de caminho URI, separados por barras representa uma oportunidade de Designer.

Atribuindo valores significativos para cada segmento de caminha ajuda a comunicar de forma clara a estrutura do projeto.

Regra que deve ser usado um substantivo singular para nomes dos documentos. Exemplo:

http://localhost:8080/funcionarios/arquitetos-software/paulo.

Regra um substantivo no plural deve ser usado para nomes de coleções. Exemplo:

http://localhost:8080/jogos/dungeons-dragons/jogadores.

Regra um substantivo no plural deve-se armazenar nomes no URI para identificação do recurso.

Exemplo: http://localhost:8080/musicas/david-guetta/playlists errado séria http://localhost:8080/musicas/david-guetta/playlist, pois estou com um recurso que é uma coleção de dados.

Regra de expressão verbal ou verbos deve ser usado como nomes de Controller, neste caso um URI

deve identificar o recurso passado para a Controller e ser nomeado para indicar sua ação. Exemplo:

http://localhost:8080/estudante/paulo/registrar.

Regra os segmentos de variáveis podem ser substituído com base em identidades e valores, alguns

caminhos podem ser estáticos e outros segmentos de URI são variável o que significa que são

automaticamente preenchidos e fornece a singularidade do URI. E uma substituição de um URI pode ser feito a partir da API REST escolhida e assim que o cliente executar a substituição, pode ser repassado um identificador numérico ou alfanumérico. Exemplo: http://localhost:8080/escola-municipal/turma-7/aluno/12 ou http://localhost:8080/escola-municipal/turma-7/aluno/1ab2.

Regra de nomes de funções CRUD não deve ser usado em um URI, a utilização da semântica do URI deve ser apenas para identificar recursos e valores variável. Exemplo:

http:localhost:8080/ctis/ms/colaboradores/123 dessa forma está correto, errado será a utilização dessa forma http://localhost:8080/ctis/ms/atualizar-colaboradores/123, além de ser fora do contexto HTTP, está mostrando qual funcionalidade do CRUD irá executar deixando frágil seu código.

Métodos de Requisição:

A RFC2616 Request-Line trabalha com o URI e os métodos específicos do HTTP 1.1 e cada método HTTP tem a semântica especifica e definida para o seu funcionamento e contexto.

Regra os métodos GET e POST não devem ser usados fora de seu contexto, assim foge de toda a

intenção da mensagem e máscara o proposito do método HTTP.

Regra GET deve ser utilizada para recuperar dados de uma consulta qualquer, apenas isso.

Regra HEAD deve ser utilizado para recuperar os cabeçalhos de uma requisição/resposta, o HEAD

recebe os dados como o GET mas sem um corpo e este recurso é usado para recuperar os metadados de uma requisição.

Regra o PUT deve ser usado para atualizar ou inserir um dado a partir de um objeto jogado na URI de chamada.

Regra o PUT deve ser utilizado para modificar/atualizar um dado mutável.

Regra POST deve ser utilizada para criar um novo item na coleção.

Regra POST deve ser usada para invocar controladores orientados por função.

Regra DELETE deve ser usado para deletar/apagar um registro a partir de uma requisição feita pelo

usuário.

Regra OPTIONS deve ser usada para recuperar metadados que gerou uma iteração e está disponível

no cabeçalho de conversação.

Conclusão:

REST facilita e trás alguns benefícios para nós desenvolvedores, mas antes devemos pensar em como implementar e como podemos reaproveitar o trabalho executado. A estrutura e a arquitetura tem que ser bem definida. Espero ter ajudado.

Referências:

http://www.rfc-editor.org/rfc/rfc2068.txt - Acessado 17/12/2014 á 02/01/2015
http://www.rfc-base.org/txt/rfc-2119.txt - Acessado 17/12/2014 á 02/01/2015
http://www.rfc-base.org/txt/rfc-3986.txt - Acessado 06/01/2015
http://www.rfc-base.org/txt/rfc-2616.txt - Acessado 07/01/2015