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: Enviando arquivos para o Dropbox via Java Application

Olá Pessoal,

Venho trabalhando há um bom tempo com API do Dropbox em web apps. No post de hoje vamos ver como enviar um arquivo para uma conta no dropbox via Java Application. É um verdadeiro upload via console.

Lets go…
O cenário

Imagine que você queira ter um upload na sua aplicação. Nada de diferente aqui, mas sabemos que há várias formas de fazer isso e temos bastante frameworks Java que nos ajudam. Mas, como fazer de forma rápida e segura? Aqui usamos o serviço do Dropbox para armazenamento de arquivos que vem da aplicação. Isso nos ajuda em vários pontos:

1. Segurança: Certamente o time do dropbox é preocupado com isso;

2. Histórico: Por default o dropbox mantém um histórico do arquivo, então em caso de precisar retornar uma versão é muito simples;
3. Baixo custo de desenvolvimento: API do dropbox é bem documentada e tem suporte a diversas linguagens. O que teremos que fazer é sempre implementar algo muito específico ou encapsular algumas features mais comuns para evitar de ter código repetido em várias partes da aplicação;
Ai nasceu no laboratorio da ITS a easyJavaDropboxAPI(https://github.com/ITSStartup/easyJavaDropboxAPI), que nos ajuda no dia a dia. A API ainda está nas primeiras versões e recentemente acabou de sair a versão 1.1.0 com algumas funcionalidades e melhorias e uma delas é permitir salvar arquivos no dropbox (a versão anterior nos permitia apenas ler um arquivo). O método na API que salva um arquivo é assim:

 

Vamos ver na prática

Primeiro Passo

Vamos usar o projeto easyJavaDropboxAPIExample que vimos no post: https://blog.camilolopes.com.br/serie-dropbox-conectando-com-dropbox-api-java/

Então você precisa ter feito os passos descritos no post acima.

Segundo Passo

Se fez o passo 1, certamente consegue listar os arquivos.

Terceiro Passo

Atualize o pom.xml para usar a versão mais nova da API:

<dependencies>
<dependency>
<groupId>com.its.api</groupId>
<artifactId>easyJavaDropboxAPI</artifactId>
<version>1.1.0</version>
</dependency>
</dependencies>

 

Quarto Passo

Agora vamos adicionar o código que fará o upload. Não vamos modificar o código existente, apenas adicionar. No método main adicone as seguintes linhas:

//upload service
EasyJavaDropBoxServiceImpl upload = new EasyJavaDropBoxServiceImpl(token);
saveToDropbox(upload);

 

 O código com o método main completo ficou assim:

public static void main(String[] args) throws DbxException, IOException {
String token = "your token here";
String path = "/";
EasyJavaDropBoxService easyJavaDropBoxService = new EasyJavaDropBoxServiceImpl(path, token);

List<DbxEntry> listFiles = easyJavaDropBoxService.listFiles();
for (DbxEntry file : listFiles) {
System.out.println(file.name);
}
//upload service
EasyJavaDropBoxServiceImpl upload = new EasyJavaDropBoxServiceImpl(token);
saveToDropbox(upload); 
}

 

Lembre-se de que é preciso gerar o token para sua conta. Quando tiver o token coloque como valor na variável token. Agora vamos criar o método que salva o arquivo no dropbox:

private static void saveToDropbox(EasyJavaDropBoxService uploadEasyJavaDropBoxService) throws DbxException, IOException {
//creating new file
File file = new File("camilotestedropbox2.txt");
file.createNewFile();
//writing content in file
FileWriter fileWriter = new FileWriter(file);
fileWriter.write("Test upload to dropbox api");
fileWriter.close();

try {
FileInputStream fileInputStream = new FileInputStream(file);
String fileName = file.toString();
//calling method from easyJavaDropboxAPI
uploadEasyJavaDropBoxService.saveToDropbox(fileName, fileInputStream); 
} catch (FileNotFoundException e) {
e.printStackTrace();
}

}

 

Testando

Agora chegou a hora de testar. Rode a aplicação e vamos ver a saída no console:

dropboxuploadconsole

 

Na imagem acima são listados os arquivos que tenho no meu dropbox. Agora vamos ver se no dropbox tem o novo arquivo que criei:

 

dropboxfileuploadeddone

Pronto, arquivo enviado para o dropbox. Simples, não?

O projeto foi atualizado no Github:

https://github.com/ITSStartup/easyJavaDropboxAPIExample

Vou ficando por aqui. Espero que tenham gostado do post.

Abracos, see ya!!!

Série Scrum Remoto: Time Evoluindo Sprint 3

Olá Pessoal, 

Mais um post da série Scrum Remoto e hoje estamos na Sprint 3. O objetivo é mostrar para vocês como foi a nossa Sprint, o que aprendemos e o mais legal é o fato de que ser remoto não impactou no objetivo. Então, para quem fala que times distribuídos com Scrum não funcionam, é importante ver o que tem de errado, mas não buscando colocar problemas no framework, ferramentas etc. Há outro fator envolvido, chamado de pessoas. 

Let’s go…

 

Scrum Remote Team Sprint 3 

Esse Sprint não foi um dos melhores para o time, porém melhor que os outros dois, uma vez que o time está aprendendo e pegando o jeito de trabalhar Agile, então estou considerando até um bom resultado. Conforme já falei em outros posts da série, a equipe nunca trabalhou com Agile, estavam acostumados sempre no lado “o meu está pronto” ou “eu sou desenvolvedor e não tenho que realizar teste se não for em minha máquina, quem faz isso é um tester”. E do lado técnico, o pessoal também estava aprendendo algumas práticas, como TDD, CI etc. Aqui todos metem mão na massa desde code até infraestrutura, o projeto é de todos e temos vários chapéus para ir usando até o final do Sprint.  Há desenvolvedores que no Sprint 1 nem sabiam para que servia o Jenkins, e hoje no Sprint 3 já mexem com a ferramenta, apresentam plugins que podem facilitar o processo de CI, etc. Vamos agora ao resultado: 

Iai, como foi o Sprint 3? 

Não pior que o Sprint 2, mas longe ainda de um Sprint ideal. A seguir o burndown nos fala isso. Vamos analisar 

<img sprint3handson> 

sprint3handson

O team prometeu uma entrega de 16 pontos. Se olharmos o Sprint 2, é uma capacidade maior do que havia entregado. 

 

sprint2handson

Tudo começou bem na primeira semana do Sprint, na verdade mandaram muito bem, quase mataram o Sprint rápido demais. Eu já havia suspeitado que tinha algo de estranho ai, mas preferi não comentar e ver o que ia acontecer. Quando chegou no dia 01/09, por algum motivo alguma estória voltou e faltavam poucos dias para terminar o Sprint, a equipe trabalhou duro e conseguiu fazer entrega no mesmo dia e nos próximos, mas observe que eles começaram a entregar somente faltando poucos dias do término do Sprint e no último dia de desenvolvimento, trabalharam duro para entregar. 

Velocity Chart

sprinthandsonvelocity

Foi bom?

Se comparar com a Sprint 2 e Sprint 1 foi um avanço muito bom da equipe. Percebo que agora eles estão pegando o jeito da coisa, e claro que há pontos para melhorar, mas eu sei que não é a mesma equipe que tinha no Sprint 1. É uma equipe melhorada. Tivemos um risco alto de acontecer alguma coisa ali no final e não entregar nada, ou pior, demoramos demais para entregar 5 dias depois do Sprint, ou seja, se temos 9 dias de desenvolvimento só entregamos quando já passamos da metade do tempo, não é muito bom isso. Exceto se está seguro que a estória não pode voltar e aconteceu isso: ela voltou, mas o time soube como contornar o problema e resolveu rapidamente entregando. 

Resultado

Saímos da Sprint 3 muito feliz com o resultado, pois tínhamos  no passado só tempestades, mas parece que está passando, porém o céu ainda não está ensolarado para o pessoal poder ir para praia. Aqui na ITS gosto muito que o team aprenda com eles mesmos, apesar de que algumas situações eu consigo ver que vai acontecer algo, mas prefiro que aconteça. Isso pode ser ruim para o negócio da empresa, mas para o aprendizado do team considero superimportante, pois vai impactar no negócio e no projeto. Às vezes há perdas financeiras por uma questão de contrato, mas não me importo muito com isso, até porque quando a ITS nasceu não foi por dinheiro, e sim por paixão pelo que fazemos. Não posso limitar nossos profissionais por uma questão financeira. Claro que vamos fazer um bom uso disso e sempre analisar para que não aconteça o pior de um drop do projeto. O pior é que um drop do projeto não é a grana envolvida e sim a oportunidade de aprendizado que deixamos de ter. Acredite ou não é a nossa cultura. Qualidade técnica é mais importante que seguir um contrato comercial. E mais interessante aqui é que quem faz parte do nosso comercial concorda com isso. Não temos aquela briga entre um grupo de nerd com business.

Vou ficando por aqui, e espero que tenha gostado desse post. 

 

Abracos, see ya!!

Série Scrum Remoto: Primeira Sprint – falhou e agora?

Olá Pessoal,

Mais um post da série Scrum Remoto e chegamos ao final do primeiro Sprint que falhou. Mas por que? Alguns podem pensar porque o time estava remoto. Será?

Lets go…

Começamos falhando

Fico feliz que a gente não começou diferente de alguns projetos Scrum que falham no primeiro Sprint. E umas das razões que já vi em projeto presencial com Scrum foram:

  • Estimativas;
  • Não saber a velocidade do Sprint;
  • Time aprendendo Scrum;
  • Blockers longos;
  • Comunicação;
  • Não saber o timebox do Sprint.

Quando falham em um projeto com Scrum remoto, muitos vão dizer o seguinte: “falhou porque o time não estava presente fisicamente”. Será? Ou estamos buscando uma desculpa para não enxergar os erros?

E porque falhamos aqui na ITSLabs?     

Falhamos por todos os problemas que há no Scrum Presencial, exceto um. O de comunicação. Por incrível que pareça, por estarem remotos o time se comunicava com maior frequência via chat, call, fazendo share da tela e pedindo ajuda do outro. Tudo isso em tempo muito curto comparado com o que já vi em times presenciais. O problema real, foram  os demais pontos e isso eu já esperava, na verdade eu ficaria muito surpreso se a estória e o Sprint fosse entregue com qualidade. Um dos pontos foi não saber qual o tamanho do Sprint ideal. Começamos com 2 semanas e não deu muito certo, pois parte do time ficou ocioso e houve desperdício de tempo no final do Sprint 0. Tentamos de 1 semana, e a Sprint falhou porque o time teve bastante blocker e tinha que parar a task em development para resolver e depois retornar para task e alguns blockers duraram quase 6hrs do dia. Ruim, heim? Fora quando tinham que ser dois devs trabalhando no mesmo blocker para tentar resolver rápido, ai era pior eram dois membros parados em função de um problema.

O final

Isso já sabemos, né? Todos com aquele feeling ruim por não terem entregue o Sprint como acordado e pensando em como resolver os problemas. De qualquer forma foi uma Sprint rica de aprendizado. O time se comportou muito bem em se adaptar e responder aos problemas mais criticos e ajudar o outro colega que ficou blocker. O espírito de team e foco no projeto e não na “minha entrega” era algo forte e isso me deixou muito feliz ao término do Sprint.

Veja como ficou o gráfico do Sprint 1:

scrumremotoburndownsprint1

 

E como foi a sua primeira Sprint ? Comente sua experiência… 🙂

Abraços, see ya!!

Série Scrum Remoto: Terminado a Sprint 0

Olá pessoal,

Vamos ver hoje como foi a Sprint 0. Será um post rápido.

Lets go…

Como foi o Sprint 0

Conforme já falei em outros posts da série, foi nessa Sprint que definimos o Sprint 0 como uma Sprint de setup e discussão sobre quais tecnologias eram ideais adotar para o projeto. Como por exemplo: vamos de Sprint MVC ou Vraptor? Fora outras discussões de infraestrutura, arquitetura inicial, etc. Claro que não definimos tudo aqui e pronto, mas o básico que precisamos para iniciar o Sprint 1, visando o baixo risco de ter que trocar amanha a versão ou framework escolhido por algum motivo específico, então vários pontos são analisados e discutidos com a equipe. Outro ponto interessante é que muitos membros do time criam POCs para mostrar o quanto a tecnologia X que ele defende pode ajudar. A única coisa requerida é que você apresente argumentos que convença o time da escolha da tecnologia, se conseguir ela é adotada e não precisa entrar em processo nenhum (que vai para “aquele cara” que em algumas empresas é considerado “o deus” que vai ter que dar o ok). Removi isso, não existe isso aqui. Odeio qualquer coisa que seja engessada. É o time técnico que define. Claro, nada impede de consultar especialistas, etc, mas no final é o team que decide as tecnologias que eles vão trabalhar nos próximos N Sprints que estão por chegar. O case aqui é de um projeto que participei em julho/2013.

A seguir o Burndown do Sprint:

scrumremotoburndownsprint0

Podemos ver que foi um Sprint bem apertado, mas a equipe conseguiu entregar bem na trave. Então concluímos ela acreditando que tudo que foi entregue já nos permite começar a Sprint 1 e meter a mão na massa na primeira estória. Vamos ver o que acontece no Sprint 1.

A retro do Sprint 0

Fizemos a retro usando a realtimeboard. Encontrei essa ferramenta por acaso e achei muito bacana para time remoto. Uma das funcionalidades que acho show é não precisar compartilhar a tela e a atualização é em tempo real para os convidados. Possui um chat e na versão free permite criar tres projetos privados. Olha o que rolou:

 scrumremotesprint0retro

Vou ficando por aqui. Espero que tenham gostado do post.

Abraços, see ya!!