Série Dropbox: Renomeando arquivo via easyJavaDropboxAPI


 
Olá Pessoal, 
 
No post de hoje vamos ver como renomear um arquivo no dropbox usando a easyJavaDropbox API. O problema surgiu porque a API do Dropbox não tem nenhum método Java para renomear um arquivo. Na verdade tem um move que pode de fato mover um arquivo ou folder e também renomear. Achamos funcionalidades demais para um unico método, e na versão 1.2.0 da easyJavaDropbox API adicionamos um método que é capaz de fazer o rename. 
 
Lets go…
 
 
Starting… 
 
Considerando que você já tem API configurado no seu projeto, vamos ver como usar a nova funcionalidade de renomear um arquivo.
 
Requisitos
 
EasyJavaDropboxAPI 1.2.0 
 
Há apenas dois novos métodos nessa versão: 
 
  • renameFileRoot(String currentNameFile, String newNameFile): esse método renomeia um arquivo considerando que o mesmo está na raiz do dropbox: “/”.  Lembre-se de que a raiz é da app que você criou.
 
  • renameFile(String pathFolder, String currentNameFile, String newNameFile): já esse método vai renomear um arquivo para um caminho que for especificado, então você vai ter que dizer:
    •  a pasta onde está o arquivo;
    •  o nome do arquivo que será renomeado; 
    • e o nome do novo arquivo; 
 
Development 
 
Agora vamos praticar. Como sempre, o exemplo vai estar no projeto easyJavaDropboxAPIExample, que já possui exemplos das outras funcionalidades da API.
 
Passo 1 
 
No método main vamos criar um método privado que fará o rename de um arquivo na raiz e outro para um caminho específico: 
 
public static void main(String[] args) throws DbxException, IOException {
String token = "token here";
String path = "/";
EasyJavaDropBoxService easyJavaDropBoxService = new EasyJavaDropBoxServiceImpl(path, token);
renameFileFromRoot(easyJavaDropBoxService);
renameFile(easyJavaDropBoxService); 
}

Agora vamos criar os métodos: 

private static void renameFile(EasyJavaDropBoxService easyJavaDropBoxService)
throws DbxException {
easyJavaDropBoxService.renameFile("/teste/","myfile.png", "renameok.png");
}

 

private static void renameFileFromRoot(EasyJavaDropBoxService easyJavaDropBoxService)

throws DbxException {
String newNameFile = "alertfytestelocal.png";
String currentNameFile = "testelocal.png";
easyJavaDropBoxService.renameFileRoot(currentNameFile ,newNameFile);
}

No dropbox: 

Temos um arquivo dentro do diretório teste chamado de myfile.png 
 
easydropboxapirenamefile
 
Vamos renomear esse arquivo para renameok.png
 
Na raiz vamos alterar o arquivo chamado alertfytestelocal.png para testelocal.png
 
easydropboxapirenameroot
 
Testando 
 
Agora vamos testar a aplicação executando o método main. 
 
Resultado: 
  
Na pasta teste:
 
easydropboxapirenametesteworking
 
 
Na raiz: 
  
easydropboxapirenamerootworking
 
Fantástico, não? Espero que tenham gostado do post e da funcionalidade. 
 
Github Projeto 
 
 
Projeto Exemplo: 
 
 
Abracos, see ya!! 

Série Dropbox Case com dropbox API

Olá Pessoal

No post de hoje gostaria de compartilhar com vocês uma experiência que tivemos aqui na ITS usando API do DropBox para resolver alguns problemas e facilitar a vida do usuário. Aqui no blog já apresentei para vocês como  usar API do Dropbox, hoje veremos como fazer umas coisas legais na sua aplicação.

Lets go…

Starting…

Case 1

Em um projeto aqui na ITS tínhamos que renderizar imagens em algumas páginas da aplicação e queria fazer isso de maneira simples, fácil e transparente para o usuário final. Considerando que o usuário que coloca as imagens não precisasse conhecer a aplicação, ou melhor, ele poderia nem ter idéia onde aquela imagem que ele criou seria usada, o foco dele era fazer a criação e depois de pronto disponibilizar a imagem em folder chamado de “live” e pronto.  Essa imagem já estaria atualizada na aplicação automaticamente.

Como resolvemos esse problema sem precisar envolver o design com aplicação?

Simples, usando o DropBox.

É isso mesmo. Os designers usam o dropbox para colocar a arte final e uma pasta final onde outro designer faz um review para ver se está ok. Nada de especial aqui, apenas usando o dropbox de maneira tradicional, só que a arte final desse designer ia ser usada na aplicação e precisamos subir a imagem, como fazer?

  • Via upload na aplicação; ou
  • Colocar a imagem direto no servidor e dar uns tapas na app para reconhecer a nova imagem

E o que fizemos?

Usamos dropbox. Para ser sincero eu fui dormir com esse problema, sonhei, e veio o dropbox como solução. Passei alguns dias estudando API e fazendo POC para validar a solução.

A solução

A solução é muito simples: o design vai continuar fazendo o trabalho dele como antes, a aplicação apenas vai buscar imagens na pasta “live” que é uma pasta onde tem a versão final da arte. Daí se o designer fizer alguma alteração nessa imagem, automaticamente ela é atualizada na aplicação. E não precisamos nos preocupar em fazer um novo upload da imagem no servidor  com a versão atualizada, porque há um sync com  a pasta “live”. A esta pasta “live” não é qualquer um que possui acesso, somente Designers mais Seniors tem permissão de escrita nessa pasta. Futuramente vamos facilitar a vida dos designers e implementar um esquema de automatizar os deploys de imagem nessa pasta, mas por enquanto ela ocorre manual. 

O que ganhamos?

– Nada de imagem no Server, então em uma migração de Server não preciso ficar preocupado em copiar imagens e, a depender da quantidade e tipo de negócio, pode demorar a cópia. Quantas imagens você acha que o submarino possui?

– Mais produtividade para o designer. Ele continua focado no trabalho dele fazendo tudo como antes, sem se preocupar onde e quem vai usar aquela imagem;

– Atualização automática da imagem na aplicação. Ou seja, subiu a imagem para pasta “live” já está atualizada na aplicação.

Case 2

Esse aqui também foi fantástico em outro projeto que usava  bastante documentos durante o dia. A vida dos usuários era o Microsoft Word aberto, atualizando os documentos publicados, criando novos  ou corrigindo.  Na versão atual, sempre que um documento é corrigido por uma questão de mudança de lei ou cláusula de contrato, há um prazo de publicação que, a depender da situação, é de até 8hrs a disponibilidade.  Se fosse apenas 1 documento e se acontecesse isso em um período longo, seria fácil, mas não é assim no dia a dia. Hoje o nosso cliente tem que acessar a aplicação, deletar o arquivo anterior e fazer upload do novo. E pior, é interessante manter o antigo como backup, por questão de segurança o delete não remove o arquivo do servidor, apenas move para uma pasta específica. Então o pessoal que trabalha nesses documentos passava boa parte do tempo fazendo upload, fora que às vezes enfrentavam problemas e demora nesse processo, já que tinham arquivos com 10 mb, como projetos com imagens.

E como resolvemos?

Com dropbox API. Os usuários trabalham no dropbox com limitação de acesso, vendo apenas aqueles folders de acordo com o departamento.  Eles não precisam mais se preocupar em fazer upload, apenas trabalham nos docs em uma determinada pasta. Seus superiores podem ir avaliando o documento sendo escrito e já dando feedback. Uma vez concluído, vai para uma pasta que representa o arquivo online e pronto, o arquivo já está atualizado em produção e quem fizer o download já pega o arquivo atualizado.

Fantastico, não?

O que aprendemos?

Nessa solução vimos que apenas saber uma tecnologia não é suficiente; é preciso estar envolvido com o negócio do cliente para chegarmos à solução ideal e sabermos se realmente resolve o problema e agrega valor ao dia a dia do nosso cliente. Não resolver um problema apenas por que temos que resolver, mas buscar como solucionar da melhor forma. É  assim que os profissionais na ITS vivem e respiram todos os dias, e sabemos que negócio & TI não estão separados, e sim juntos. Se você for na API do dropbox é tudo abstrato, o que você vai fazer com ela é uma questão sua. E nós chegamos a essa arquitetura devido ao nível de envolvimento que tínhamos com o negócio, senão ia ser mais uma API disponível como qualquer outra.

Agora temos mais desafios de automatizar alguns trabalhos e permitir que a promoção de uma pasta para outra seja rápida e simples.

Não deixe de conhecer o easyJavaDropboxAPI

Abraços. See ya! 

Série Dropbox Lançamento easyJavaDropboxAPI for Java Developer

Olá Pessoal,

É com muito prazer que venho apresentar pra vocês mais um trabalho da minha start-up: a ITS. Estamos trabalhando bastante com o dropbox aqui para soluções corporativas, e até final do ano devemos lançar uma plataforma para comunidade que vai estar usando a tecnologia. Nesse trabalho percebemos que era necessário criar uma API Java para o dropboxAPI. O motivo? Tínhamos muito trabalho sempre que um projeto ia precisar o dropbox API, ai decidi criar uma API  que chamei de easyJavaDropboxAPI. Como sabemos, qualidade de software, produtividade e manutenção é um desafio sempre e aqui acreditamos bastante no aprendizado contínuo para melhorar o que fizemos ontem, hoje e amanhã.  A seguir explico mais sobre a API e mostro um exemplo simples de uma aplicação Java  + easyJavaDropboxAPI.

lets go…

easyJavaDropboxAPI

Tudo começou de uma simples ideia, e enquanto fui dormir com um problema achei a solução durante os sonhos. Pode acreditar, foi verdade isso. Dei inicio aos estudos e achei a solução na api do dropbox. Infelizmente não posso entrar em detalhes do negócio, pois foi para um projeto corporativo que usamos. Outros projetos chegaram e precisamos da API, então certa hora eu disse “pessoal, precisamos criar uma API Java para o dropbox API. Já temos vários projetos usando e vai ser complicado dar manutenção”. Antes de tornar a easyJavaDropboxAPI pública, ela tinha outro nome, easyDropboxAPI. E por que eu deveria usar a easyJavaDropboxAPI e não diretamente API dropbox API?

É dificil responder a pergunta acima, mas vou mostrar os motivos que nos levou aqui na ITS a termos uma API .

 

Problemas

Produtividade

Estamos crescendo com soluções enterprise usando dropbox API e já estávamos entrando no terceiro projeto quando vimos que o custo de manutenção estava começando a aparecer. No inicio não tínhamos noção do quanto a API poderia ajudar em outros projetos e foi preciso usar em um projeto interno, testar por um período não só a funcionalidade, mas outros fatores de negócio. Por isso que não começamos criando uma API, mas a coisa “virou” e agora queremos ganhar tempo, e com a API é muito simples sair usando em meia dúzia de linhas e em poucos minutos você já está conectado ao dropbox.

Manutenção

Agora não é preciso ficar preocupado com a manutenção do código que conecta com a API do dropbox. Como o dropbox team está sempre atualizando e lançando novas features, temos apenas um único local que vai ter essa feature atualizada e os projetos que precisarem faz o update do .jar para a versão mais recente.

Desenvolvimento Ágil

Na interface temos os métodos mais comuns e objetos do dropbox API que é a base do serviço, então um desenvolvedor novo precisa inicialmente entender pontualmente e à medida que ele for evoluindo vai entrando nos detalhes. Por exemplo, se você pretende listar os arquivos que está no diretório /home do seu dropbox o que precisa ser feito?

1. Saber o que é um token e gerar um;

2. Chamar o método listFiles que retorna todos os arquivos do diretório informado

Cada elemento no list é um arquivo do diretório.

Esses três pontos foram o suficiente para termos API e impactou bastante no dia a dia desenvolvimento.

Vamos ver na prática?

Praticando

1. Crie um simple maven project

2. Adicione a dependência no pom.xml

dropboxeasyjavaapipom

 

<dependency>

<groupId>com.its.api</groupId>

<artifactId>easyJavaDropboxAPI</artifactId>

<version>1.0.0</version>

</dependency>

 

3. Adicione o nosso repositório no pom.xml

<repositories>

<repository>

<id>easyJavaDropboxAPI</id>

<url>https://raw.github.com/ITSStartup/easyJavaDropboxAPI/mvn-repo</url>

<snapshots>

<enabled>true</enabled>

<updatePolicy>always</updatePolicy>

</snapshots>

</repository>

</repositories>

 

4. Crie uma classe Java com o método main

 

public class DropboxMain {

public static void main(String[] args) throws DbxException {

String token = "TOKEN HERE";

EasyJavaDropBoxService easyJavaDropBoxService = new EasyJavaDropBoxServiceImpl(path, token);

List<DbxEntry> listFiles = easyJavaDropBoxService.listFiles();

for (DbxEntry file : listFiles) {

System.out.println(file.name);

}

}

}

 

5. Gere o token seguindo as instruções:

http://apps.camilolopes.com.br/dpboxapiweb

 

6. Rode aplicação e verá:

dropboxconsoleasyapi

 

Pronto, os arquivos que tenho na pasta são listados.

Simples, não?

O projeto de exemplo está disponível no repositório da ITS.

E caso queriam saber mais sobre API, visite o repositório:

https://github.com/ITSStartup/easyJavaDropboxAPI

Abracos. See ya!!!

Fazendo Mocks com DAO Mockito

Olá Pessoal,

O post de hoje veremos como usar Mockito para coberir classes e metodos DAO.  Eu particularmente gosto de usar BDUnit para testes funcionais assim, mas há quem não gosta. Para não dizer que temos apenas uma solução resolvi escrever esse post.

Lets go..

Starting..

É comum achar que não é possível chamar o método real usando mock, mas analisando a documentação vamos encontrar um cara que permite chamar o método real, usando o mesmo contexto de mock,. Isso permite manter todo seu test com mock e ainda cobrir o que é de fato necessário.

No  padrão de uso da mock, o código a seguir não rola cobertura, uma vez que estamos usando a mock, então o método real não é chamado:

@Test

            public void testBuscaEmailCadastrado() {                   

                         user.setEmail(“camilo@”);

                      when(usuarioDaoMock.buscaUsuarioPorEmail(user)).thenReturn(user); 

        assertNotNull(usuarioDaoMock.buscaUsuarioPorEmail(user));

            }

Como podemos ver na imagem acima,  vermelho significa que não tem cobertura naquele código, uma vez que não há test case chamando ele direto.

E como resolver isso?

Para resolver é muito simples. Porém, antes de apresentar a solução vamos a outro fato tradicional, testar métodos do tipo void. Sabemos que com assert não é possível testar um método void, uma vez que este retorna “nada”. Mas com mock podemos chamar um método void e testá-lo, afetando assim a cobertura. Vejamos como:

O método doCallRealMethod() permite chamar o método real da mock, independente do tipo deste método. Sendo assim, void agora pode ser chamado e verificado no seu test case. É comum ver programadores tendo que converter um determinado método do tipo void para return alguma coisa só para satisfazer o test case. Sem o uso de mock (mockito) temos que fazer isso, porque não temos nenhum assert para verificar um tipo void que não retorna “nada”.

Observe na imagem a seguir o resultado, agora está cobrindo o DAO:

 

Note: segundo a documentação, o uso doCallRealMethod() é algo que deve ser feito cuidadosamente, pois significa que há algum tipo de complexidade no seu código, mas também não deixam de falar que há casos raros onde é possível usar the partial mock warning (é o nome que se dá quando chamamos um método real usando mock).

O code:

1         Mockito.doCallRealMethod().when(usuarioDaoMock).buscaUsuarioPorEmail(user);                               

2         assertEquals(usuarioDaoMock.buscaUsuarioPorEmail(user).getEmail(),user.getEmail());

A leitura do code: “chame o método real quando o método buscaUsuarioPorEmail for chamado pela usuariodaomock e passe o valor user para ele”.

Assim o mockito vai lá na classe que possui o método real e chama ele de fato, como vimos na imagem anterior, onde o código passa a ser coberto.

Um possível Problema

            O único problema é que precisamos ter o banco de dados rodando, ou seja, UP para as funções que precisa consultar. Pode parecer óbvio, mas nem tanto, porque quando usamos a mock apenas, esta simula a chamada e o valor esperando independente do banco estar ON/OFF.

Resultado com o banco OFF é o seguinte:

org.hibernate.exception.JDBCConnectionException: Cannot open connection

            Mas não esqueçam que ainda temos a vantagem de testar métodos do tipo void, fazendo a cobertura passar por ele. No contexto acima, na maioria das vezes vamos ter um BD ON, pois queremos ver se o nosso CRUD/DAO está fazendo o que de fato esperamos que ele faça, que é a comunicação com o BD, porém daí já estaríamos caminhando mais para tests funcionais que tests cases de fato.

Na imagem a seguir temos a cobertura em todo DAO. Observe que foi implementado um novo método que busca no banco um email e este não existe, daí verificamos se de fato o código entra no catch e este está coberto.

Cobertura antes


Cobertura depois

Mas, uma solução também é usar o banco em memoria como HSQLDB assim você poderá executar seus testes contra o banco automaticamente, ou seja, você não precisar iniciar ou parar o banco.

Vou ficando por aqui.

Abracos, see ya!!

MundoJ Ed. 49 – Artigo Criação de mocks com Mockito

olá Pessoal,

Mais uma edição da MundoJ de nro 49 e  estou completando meu terceiro artigo com eles.Porém,este é o meu primeiro artigo com outro colunista (ótima experiência escrever em par). Junto com o  Alexandre Gazola  estamos falando um pouco sobre o Mockito e como usar a API para mockar seus objetos durante o desenvolvimento dos seus unit testes.  Não posso deixar de agradecer ao Eduardo Guerra o qual tive o prazer de conhecer no AgileVale 2011. Ao colega colunista Alexandre Gazola, foi um prazer ter escrito esse artigo com ele. Enfim espero que gostem do artigo! não esqueçam de comentar lá no GUJ.

Um pouco sobre o artigo

Para quem nunca trabalhou com mocks ou quem já trabalha, mas não com Mockito API, neste artigo há duas oportunidade: A primeira é de aprender mocks para quem é iniciante e nunca brincou antes. E a segunda de conhecer mais uma API Mock que tem sido bem aceita pela comunidade, quem sabe você pode encontrar vantagens no Mockito e migrar pra ele?!

Para saber mais, só comprando a edição. 🙂

abracos, see ya!!