segunda-feira, 19 de fevereiro de 2018

Publicando módulo Angular 4 no NPM

O NPM serve para instalar, compartilhar e distribuir códigos. É um gerenciador de pacotes para JavaScript e também um repositório para compartilhamento de códigos fonte onde temos inúmeros pacotes de códigos reusáveis. Para quem trabalha com o Java, seria uma espécie de Maven para JavaScript.

O NPM é instalado juntamente com o Node.js, que pode ser baixado do seguinte endereço:


Após instalado você pode executar o seguinte comando para ver as versões do Node.js e do NPM respectivamente:

$       node -v
$       npm -v

Mesmo tendo baixado o NPM juntamente com o Node.js, eles são independentes e provavelmente você precisará atualizar sua versão do NPM, para isso use o comando  npm install npm@latest -g.

Depois de instalado o NPM, é preciso criar uma conta caso você não tenha, ou fazer login para poder compartilhar seus pacotes. A criação da conta é bem simples e eles pedem um username, password e e-mail. É necessário a confirmação do e-mail antes de publicar algo caso a conta seja nova. O comando para criar uma conta é:

$       npm adduser

Ao criar a conta ele já loga no NPM. Para efetuar logins posteriores, os mesmos dados são pedidos, e o comando é:

$       npm login

Uma vez tendo usuário e senha e estando logado, devemos entrar no diretório do projeto que queremos compartilhar e prepará-lo para ser compartilhado. Para isso precisamos do ng-packgr. Essa biblioteca vai compilar nosso código para um formato de pacote do Angular. Digite o seguinte comando:

npm install ng-packagr --save-dev

Então crie um novo arquivo chamado ng-package.json na raiz do seu projeto. Insira o seguinte trecho de código nele:

{
    "$schema": "./node_modules/ng-packagr/ng-package.schema.json",
    "lib": {
       "entryFile": "index.ts"
    }
}

Agora precisamos criar o arquivo que indicamos como arquivo de entrada no “entryFile”. Esse arquivo deve também estar na raiz do seu projeto e no conteúdo precisamos exportar nossos módulos como abaixo:

Export * from “./src/app/caminho_do_seu_modulo/seumodulo.module”

O módulo que for exportado será acessado por quem usar nossa biblioteca. Lembre-se de no decorator exportar os componentes, para que eles possam ser usados fora do módulo, como no exemplo abaixo:

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { BrowserAnimationsModule } from "@angular/platform-browser/animations";
import { FormsModule } from '@angular/forms';

import { SeuComponent } from './seu-component.component';

@NgModule({
  imports: [
    CommonModule,
    FormsModule,
    BrowserAnimationsModule
  ],
  declarations: [SeuComponente],
  exports: [
    SeuComponente
  ]
})
export class SeuModule { }

Precisamos agora adicionar um novo script no package.json e remover a propriedade "private": true. Depois de remover a propriedade, dentro do arquivo procure a propriedade “scripts” e adicione ao final:

“packagr”: “ng-packagr -p ng-package.json”

Agora execute o comando npm run packagr, que irá gerar a dist da nossa biblioteca. Note que foi criada uma pasta dist. Ela é o conteúdo que deve ser publicado.

Por fim, execute os comandos npm pack para gerar um arquivo .tgz com a versão do nosso projeto e o comando: npm publish dist para que possamos publicar a nossa biblioteca no portal npm.


Segue o link de um componente que publiquei no NPM e o fonte no GitHub:










Links de referência:

https://imasters.com.br/desenvolvimento/publicando-modulo-angular-4-no-npm/?trace=1519021197&source=single
https://medium.com/@programadriano/nodejs-criando-um-m%C3%B3dulo-global-e-publicando-no-npm-9bb046a1db4f 
http://clubedosgeeks.com.br/artigos/publicando-pacotes-no-npm

terça-feira, 6 de fevereiro de 2018

Git – Configurando o SSH no Windows e no GitHub

Criar uma chave SSH não é muito complicado. Quando instalamos o Git no Windows, ele já traz uma ferramenta para isso, o OpenSSH.

Então, vamos começar executando o git-bash, um terminal Linux para o Windows que também faz parte da instalação do Git. Após aberto o git-bash, digite:

ssh-keygen -t rsa -b 4096 -C "seu-email@aqui.com"

Você será indagado sobre onde salvar a chave, sendo que o prompt também já mostra um caminho default. Basta pressionar o “Enter” para criar a chave SSH no caminho default. Caso já exista uma chave salva, ele perguntará se deseja sobrescrever. Logo depois, ele pedirá uma senha e a confirmação:

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Caso não queira informar uma senha, pode apenas confirmar sem digitar nada (é recomendado criar uma senha, claro!). Então o prompt lhe informa que a sua chave privada e a sua chave publica estão no caminho indicado previamente, que se for o default é: C:\Users\seu-usuario\.ssh.

Adicione sua chave SSH ao SSH-Agente:

eval $(ssh-agent -s)
ssh-add ~/.ssh/id_rsa

E por fim, adicione sua chave a sua conta no GitHub, o comando abaixo copia sua chave para a memória e deixa pronto para colar no GitHub:

clip < ~/.ssh/id_rsa.pub

Depois, acesse sua conta no GitHub e vá nas configurações:




Clique em “SSH and GPG keys”.




Clique em “New SSH key”:




Adicione um título para identificação da sua chave (pois você pode ter mais de uma, de diferentes dispositivos) e cole a sua chave SSH, depois, confirme sua senha.




Pronto! 




https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/
http://guides.beanstalkapp.com/version-control/git-on-windows.html

segunda-feira, 29 de janeiro de 2018

Tunando sua Linha de Comando Windows

As vezes compramos computadores e pela praticidade dos drivers e outras coisas que já vem instaladas ou pela pouca familiaridade com o Linux não queremos mudar o nosso S.O., porém como desenvolvedores as vezes queremos usar alguns comandos do Linux para auxiliar algumas tarefas.

Passando por isso, encontrei duas ferramentas legais e que trabalham juntas para isso.

A primeira, chamada Scoop.sh, permite pesquisarmos e instalarmos coisas via linha de comando de forma muito fácil, semelhante o Linux.

O endereço para essa ferramenta é:


Para instalar, abra o PowerShell como administrador e digite os 2 comandos abaixo:

1.     Set-ExecutionPolicy RemoteSigned -scope CurrentUser
2.     iex(new-object net.webclient).downloadstring('https://get.scoop.sh')

Esse vídeo de demonstração também é encontrado no site do scoop:


         
O scoop funciona como um gerenciador de aplicações, ou seja, o que você instala com ele, ele mantém uma lista pra que você possa gerenciar: usar, atualizar, desinstalar, etc.

O comando scoop list  mostra o que você tem instalado. O comando scoop search nomeDeUmPrograma busca um programa no repositório e lista para você escolher o que vai instalar.

Então agora vamos instalar o utilitário que disponibiliza comandos do Linux para a linha de comando do Windows. O nome dessa ferramenta é busybox.

Você pode saber mais sobre esta ferramenta em:


Os comandos são:

1.      scoop search busybox
2.      scoop install busybox
3.      scoop list

Outras ferramentas que eu aconselho são openssh, nano, 7zip. Daí em diante basta ir instalando e usando o que precisar, como git, node, etc...

Espero ter ajudado, até a próxima!

segunda-feira, 18 de dezembro de 2017

CDI - Injeção de Dependência e Contexto

O que é CDI? Para que serve? E como usar? Bom, essas três perguntas eu pretendo responder nesse post. O CDI é a especificação Java que define a injeção de dependência e inversão de controle para aplicações JavaEE. Como o CDI é uma especificação, existem implementações, e como é comum no Java, existe a implementação de referência, que nesse caso é a Weld.

O que esta especificação define? Basicamente ela trata sobre injeção de dependência (DI) e inversão de controle (IoC) no contexto e escopos de uma aplicação JavaEE. Mas o que é injeção de dependência e inversão de controle? Bom, essas duas coisas andam bem juntas.

Injeção de dependência é tornar disponível a instância de uma classe quando precisamos dela. Isso ocorre quando dentro de uma classe fazemos algo como:

MinhaClasse c = new MinhaClasse();

Nesse momento estamos dizendo que a classe a qual estamos depende da classe MinhaClasse. A questão é que isso é uma coisa corriqueira e que sempre precisamos fazer, então, por quê não tornar isso automático? Aí entra a questão da Inversão de Controle. Vamos passar a responsabilidade de colocar essa instância para o container ao invés de nós ficarmos dando um “new” sempre que quisermos usar uma classe. Dessa forma, passamos a tratar o exemplo acima da seguinte maneira:

@Inject
MinhaClasse c;

Dessa forma, quando o container perceber que precisamos da classe c, ele irá colocar a instancia para nós. Mas para isso funcionar, precisamos aprender umas coisinhas ainda!

Primeiro, para um projeto estar apito a usar o CDI, precisamos adicionar um arquivo de configuração chamado beans.xml que deve ficar dentro de /main/webapp/WEB-INF/. Esse arquivo deve conter o seguinte trecho de código:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
      http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
       version="2.0" bean-discovery-mode="all">

</beans>

Caso seja um módulo EJB ou JAR, o arquivo deve estar no diretório META-INF/. Note que temos esse atributo bean-discovery-mode="all" que informa para o CDI que todas as classes serão consideradas beans CDI. Outras opções para esse valor são: annotated - habilita apenas as classes anotadas - e none que desabilita o CDI. Mas para que a injeção funcione, toda classe que quisermos que seja um bean CDI deve ser pública e possuir um construtor padrão.

No pom.xml devemos colocar:

<!-- Weld (implementacao do CDI) -->
<dependency>
       <groupId>javax.enterprise</groupId>
       <artifactId>cdi-api</artifactId>
       <!-- Use version 2.0 for Weld 3 -->
       <version>2.0</version>
</dependency>

Quando queremos usar um Bean CDI em uma página JSF, precisamos anotar esse Bean com a anotação @Named. Isso permite ao bean CDI ter um nome que pode ser usado pela Expression Language  do JSF. Essa anotação pode receber uma String que dá a classe um nome específico para ser usado nas páginas xhtml. Caso não seja especificado, o nome padrão é o nome da classe com a primeira letra minúscula.

E quando não queremos que determinada classe ou pacote não seja injetada via CDI? Temos algumas formas de fazer isso: Via anotação @Vetoed ou via configuração no arquivo beans.xml.

Usando a anotação temos o seguinte:

@Vetoed
public class MinhaClasse implements MinhaInterface {
         ...
}

Isso fará com que essa classe seja desconsiderada pelo CDI e ela não poderá ser injetada em outras classes. Caso queira que todo o pacote seja desconsiderado, a anotação @Vetoed pode ser usada sobre o pacote:

@Vetoed
package br.com.utils;

public class MinhaClasse implements MinhaInterface {
         ...
}

Via anotação teremos o seguinte:

<beans ... >
<scan>
   <!-- posso excluir apenas a classe: -->
   <exclude name="br.com.utils.MinhaClasse.java"/>
   <!-- ou posso excluir todas as classes do pacote utils: -->
   <exclude name="br.com.utils.*"/>
   <!-- ou posso excluir o pacote util completo, incluindo subpacotes: -->
   <exclude name="br.com.utils.**">
</scan>
</beans>

É possível ainda usar condicionais para definir quando uma classe ou pacote deve ser desconsiderado para injeção usando as TAG’s <if-system-property>, <if-class-available> e <if-class-not-available>, como mostrado a seguir:

<beans ...>
 <scan>
  <exclude name="br.com.rest.*" />
   <exclude name="br.com.faces.**">
    <if-class-not-available name="br.com.MeuBean"/>
   </exclude>
   <exclude name="br.com.dao.*">
    <if-system-property name="propriedade" value="valor"/>
    </exclude>
   <exclude name="br.com.ejb.**">
    <if-class-available name="javax.enterprise.inject.Model"/>
     <if-system-property name="exclude-ejbs"/>
   </exclude>
 </scan>
</beans>

Contexto e Escopos:

O contexto é responsável pelo ciclo de vida e a visibilidade dos beans CDI dentro dos escopos definidos. Os beans CDI tem os seguintes escopos:

·       @RequestScoped – O bean tem o escopo da requisição.
·       @ConversationScoped – O bean com escopo definido pelo desenvolvedor na aplicação.
·   @ViewScoped – do pacote javax.faces.view.ViewScoped, tem o escopo de uma view. Enquanto estiver na mesma tela, o bean estará disponível. Veio para substituir o ViewScoped do JSF.
·    @SessionScoped – O bean tem o escopo da sessão do usuário. É considerado um escopo longo e deve ser usado com cuidado.
·     @ApplicationScoped – O bean fica instanciado durante todo o tempo que a aplicação estiver disponível. É o escopo mais longo e também deve ser usado em poucos casos.

     Fora estes escopos, existe um que é o principal escopo do CDI - @Dependent, digo isto porque quando nenhum escopo é definido explicitamente ele é usado por padrão no CDI (o que geralmente ocorre com a maioria das classes). Este escopo delibera que uma classe quando definida com ele, ao ser injeta em outra classe, terá o mesmo escopo da classe à qual foi injetado. Em outras palavras, quando injetamos uma instância de uma classe com escopo @Dependent dentro de uma instância de uma classe que tenha o escopo de Sessão por exemplo, a classe com o escopo @Dependent passa a ter escopo de Sessão automaticamente.

            Transações Gerenciadas pelo Container

A versão do JTA 1.2  introduz a anotação @javax.transaction.Transactional. Essa anotação possibilita que as aplicações possam demarcar os limites de uma transação declarativamente. Isto é feito utilizando beans CDI gerenciados, assim como as classes definidas como Managed beansServletsJAX-RS e os endpoints JAX-WS.

As anotações podem ser especificadas tanto em nível de método como em nível de classe, no entanto, as anotações em nível de método sobrescrevem aquelas que estão em nível de classe.

Segue o exemplo do uso na classe:

@Transactional
public class MinhaClasse {
   //...
}

Segue o exemplo do uso no método:

public class MinhaClasse {
   public void consultar() {
       //...
   }

   @Transactional
   public void incluir() {
     //...
   }
}

Esse controle de transação é fornecido através de uma implementação de interceptores do CDI que realizam o cancelamento ou recuperação da transação quando necessário.

O elemento TxType da anotação @Transactional fornece tipos de transação equivalente a semântica utilizada nos atributos de transação do EJB. Deve ser especificado da seguinte forma: @Transactional(TxType.REQUIRES_NEW) Segue uma tabela com os tipos suportados:

TxType
Fora de um contexto de Transação
Dentro de um contexto de Transação
REQUIRED (default)
O interceptor deve iniciar uma nova transação JTA, o método de execução do Managed Bean deve então continuar dentro desde contexto de transação e a transação deve ser completada pelo interceptor.
O método de execução do Managed Bean deve continuar dentro deste contexto de transação.
REQUIRES_NEW
O interceptor deve iniciar uma nova transação JTA, o método de execução do Managed Bean deve então continuar dentro deste contexto de transação, e a transação deve ser completada pelo interceptor.
O contexto de transação corrente deve ser suspenso, uma nova transação JTA será iniciada, o método de execução do Managed Bean deve então continuar dentro deste contexto de transação, a transação deve ser completada, e a transação anterior que foi suspensa deve ser retomada.
MANDATORY
Uma TransactionalException com uma TransactionRequiredException aninhada deve ser lançada.
O método de execução do Managed Bean continuará sob o contexto.
SUPPORTS
O método de execução do Managed Bean deve continuar fora de um contexto de transação.
O método de execução do Managed Bean deve continuar dentro deste contexto de transação.
NOT_SUPPORTED
O método de execução do Managed Bean deve continuar fora de um contexto de transação.
O contexto de transação corrente deve ser suspenso, o método de execução do Managed Bean deve continuar fora de um contexto de transação, e a transação anterior suspensa deve ser retomada pelo interceptor que suspendeu essa transação após o método de execução ser completado.
NEVER
O método de execução do Managed Bean deve continuar fora de um contexto de transação.
Uma TransactionalException com uma ValidTransactionException aninhada deve ser lançada.
fonte: Devmedia 

Por padrão, no CDI as exceções checadas não resultam em rollback, como é também no EJB como mostro nessa postagem. Porém instâncias de RuntimeException e suas subclasses resultam em rollback da transação.

Mas assim como no EJB existe uma forma explicita de forçar o rollback nas exceções verificadas, no CDI também é possível fazer. O elemento “rollbackOn” permite que você especifique as classes de exceções que mesmo quando verificadas no bloco try/catch devem fazer o rollback.

@Transactional(rollbackOn={Exception.class})

E como é possível especificar as classes de exceções que forçarão o rollback, também podemos especificar as classes que não devem causar rollback através do elemento “dontRollbackOn”.

@Transactional(dontRollbackOn={IllegalStateException.class})

Para concluir o assunto sobre transações, existe uma anotação que garante que uma única instância de um bean será usada em todo contexto da transação: @TransactionalScoped. Toda classe marcada com essa anotação tem seu ciclo de vida delimitado para a transação JTA ativa no momento. Se durante a transação, múltiplas instâncias desse bean são injetadas em diferentes classes, o CDI refere-se a mesma instância, assegurando que apenas uma instância do bean seja utilizada e que ela mantenha suas propriedades valoradas.

import javax.transaction.TransactionScoped;

@TransactionScoped
public class TestTransactionalScopeBean {
    //...
   

}

       




Bibliografia: