Essa semana as aulas voltaram e com isso, se foi o tempo extra que tínhamos para dedicarmos ao projeto. Porém conseguimos finalizar os endpoints que manipulam os usuários, sejam eles usuários representante de ONG, usuários adotantes ou usuários administradores. Continuamos as correções da documentação. Finalizamos o layout do site e estamos caminhando para a finalização do layout do aplicativo.
De: Julia Fernandes
sábado, 29 de julho de 2017
sábado, 22 de julho de 2017
Vigésima Quarta Semana - Avanços Concretos
Finalmente temos algo concreto no aplicativo: o login está 100% funcional. Agora com a estrutura de comunicação com a API montada, os próximos passos serão menos turbulentos que os últimos meses. Os próximos passos são o cadastro de usuário e a listagem de animais, que estão para serem entregues essa semana, se tudo ser certo.
O layout do site administrativo (por onde serão cadastradas as ONGs) está praticamente pronto. Com ajuda do Bootstrap, conseguimos deixar o layout responsivo e funcional. O menu do sistema no Mobile foi reconstruído tendo um novo layout e uma nova forma de construção em sua atividade (activity) em que o menu é iniciado e desenhado tendo como valores os IDs dos layouts respectivos e a escrita dos dados em métodos distintos sem o uso do método setDrawerListener. Com a nova codificação para o menu o método descontinuado, a equipe não terá problemas com alguma falta de suporte nas futuras atualizações do Android Studio.
Continuando com a revisão da documentação das tecnologias utilizadas pela equipe, o time acrescentou o Gradle, e pretendemos escrever sobre o Maven também.
De: Gabriel Renato
O layout do site administrativo (por onde serão cadastradas as ONGs) está praticamente pronto. Com ajuda do Bootstrap, conseguimos deixar o layout responsivo e funcional. O menu do sistema no Mobile foi reconstruído tendo um novo layout e uma nova forma de construção em sua atividade (activity) em que o menu é iniciado e desenhado tendo como valores os IDs dos layouts respectivos e a escrita dos dados em métodos distintos sem o uso do método setDrawerListener. Com a nova codificação para o menu o método descontinuado, a equipe não terá problemas com alguma falta de suporte nas futuras atualizações do Android Studio.
Continuando com a revisão da documentação das tecnologias utilizadas pela equipe, o time acrescentou o Gradle, e pretendemos escrever sobre o Maven também.
De: Gabriel Renato
sábado, 15 de julho de 2017
Vigésima Terceira Semana - Recomeçando o Aplicativo
Com o fim da Sprint da semana passada, os integrantes da equipe repararam que houve uma maior produtividade usando os horários fixos de trabalho no projeto para a semana, porém esta produtividade ainda não é o suficiente para recuperar o atraso.
Mudanças no menu tiveram que ter sido feitas por conta da descontinuação do método setDrawerListener que estava sendo utilizado na construção da tela. O problema que a equipe teve com a captação de imagens, que ficavam pixeladas ou não eram desenhadas, foi resolvido nesta semana tendo como resolução não atribui-la diretamente a um bitmap, mas sim a uma variável Uri para que então seja feita a conversão para evitar a perda de qualidade.
No decorrer dos últimos dias, a equipe percebeu a necessidade de atualizar nosso banco de dados (e seus diagramas) por conta de mudanças que ocorreram desde o planejamento da implementação do aplicativo. Além disso, grande parte do que foi implementado no aplicativo começou a sofrer mudanças para se adaptar ao novo funcionamento da API, que precisou ser modificada para se adequar à arquitetura RESTful. Após revisar o sistema, foi averiguado que a modelagem atual do sistema não cumpria os requisitos de segurança, ou seja, haviam muitas brechas de segurança que a criptografia implementada e a modelagem implementada não asseguravam. O sistema, então, foi remodelado, descartando a criptografia, já que, na nova modelagem, ela não é mais necessária.
A grande brecha de segurança foi a desconsideração de que todo o código disponibilizado no aplicativo pode ser descompilado e visualizado, sendo assim, a criptografia não fazia efeito algum para a segurança do sistema. Outros problemas envolviam escolhas errôneas na modelagem do sistema, como por exemplo, não associar o token a um usuário, permitindo que um mesmo token possa acessar os recursos do sistema inteiro, inclusive os recursos de todos os outros usuários. Outra escolha errada para o desenvolvimento da API foi a criação de status próprios do sistema, sendo que isso acaba fazendo com que a API deixe de ser da arquitetura REST, além de vários outros erros que distanciavam o sistema cada vez mais da arquitetura base almejada. Em uma arquitetura REST, os status do próprio HTTP devem ser respeitados e utilizados, assim como os vários padrões de criação dos requests HTTP, como por exemplo, utilizar-se dos métodos corretos para os pedidos, utilizar-se dos headers corretos para a autenticação etc.
Após revisar o capitulo “Tecnologias e ferramentas”, percebemos que não foram documentadas as ferramentas que estão sendo utilizadas para a comunicação entre a equipe, os professores e representantes de ONGs, além disso, a introdução para as ferramentas de desenvolvimento estava confusa, por isso foram refeitas.
De: Isabelle Neves
Mudanças no menu tiveram que ter sido feitas por conta da descontinuação do método setDrawerListener que estava sendo utilizado na construção da tela. O problema que a equipe teve com a captação de imagens, que ficavam pixeladas ou não eram desenhadas, foi resolvido nesta semana tendo como resolução não atribui-la diretamente a um bitmap, mas sim a uma variável Uri para que então seja feita a conversão para evitar a perda de qualidade.
No decorrer dos últimos dias, a equipe percebeu a necessidade de atualizar nosso banco de dados (e seus diagramas) por conta de mudanças que ocorreram desde o planejamento da implementação do aplicativo. Além disso, grande parte do que foi implementado no aplicativo começou a sofrer mudanças para se adaptar ao novo funcionamento da API, que precisou ser modificada para se adequar à arquitetura RESTful. Após revisar o sistema, foi averiguado que a modelagem atual do sistema não cumpria os requisitos de segurança, ou seja, haviam muitas brechas de segurança que a criptografia implementada e a modelagem implementada não asseguravam. O sistema, então, foi remodelado, descartando a criptografia, já que, na nova modelagem, ela não é mais necessária.
A grande brecha de segurança foi a desconsideração de que todo o código disponibilizado no aplicativo pode ser descompilado e visualizado, sendo assim, a criptografia não fazia efeito algum para a segurança do sistema. Outros problemas envolviam escolhas errôneas na modelagem do sistema, como por exemplo, não associar o token a um usuário, permitindo que um mesmo token possa acessar os recursos do sistema inteiro, inclusive os recursos de todos os outros usuários. Outra escolha errada para o desenvolvimento da API foi a criação de status próprios do sistema, sendo que isso acaba fazendo com que a API deixe de ser da arquitetura REST, além de vários outros erros que distanciavam o sistema cada vez mais da arquitetura base almejada. Em uma arquitetura REST, os status do próprio HTTP devem ser respeitados e utilizados, assim como os vários padrões de criação dos requests HTTP, como por exemplo, utilizar-se dos métodos corretos para os pedidos, utilizar-se dos headers corretos para a autenticação etc.
Após revisar o capitulo “Tecnologias e ferramentas”, percebemos que não foram documentadas as ferramentas que estão sendo utilizadas para a comunicação entre a equipe, os professores e representantes de ONGs, além disso, a introdução para as ferramentas de desenvolvimento estava confusa, por isso foram refeitas.
De: Isabelle Neves
sábado, 8 de julho de 2017
Vigésima Segunda Semana - Começo das Férias
A cada Sprint definimos uma pontuação baseada na quantidade de atividades pedidas por outras matérias para evitar uma sobrecarga de tarefas durante a semana, assim em semanas de provas a pontuação tende a ser menor do que em semanas de início de bimestre, por exemplo. Porém, mesmo com este método de pontuação a equipe tem falhado ao cumprir com as Sprints tendo completado poucas durante o semestre por conta da falta de compromisso dos integrantes. Percebemos que mesmo tendo uma metodologia eficiente, os integrantes precisam ser cobrados constantemente para que concluam suas tarefas durante as Sprints e que tarefas mais complexas demandam integrantes que trabalhem em harmonia, ou seja, não possuem ideias ou raciocínios distintos para atingir um mesmo objetivo, resultando em uma produtividade maior. Como entramos de férias essa semana, a pontuação das Sprints serão maiores. Por conta disso, todos os integrantes do time definiram horários fixos para trabalhar no projeto todos os dias, dedicando mais tempo durante os fins de semana visando um aumento de produtividade e recuperar as metas não alcançadas nos últimos meses.
Como resposta ao e-mail enviado semana passada, o professor explicou que as publicações devem conter além do resumo semanal, contemplar técnicas importantes que desenvolvemos no decorrer da semana, lembrando que pode haver mais de uma publicação por semana. Seguindo esta orientação, iremos apresentar a construção de uma classe que gerência as permissões necessárias de uma aplicação mobile (Android).
Construindo a classe:
Para construir a classe de permissões, criaremos um método que dado como parâmetros um activity, um requestCode e uma listagem com as permissões verifica se as permissões passadas já estão autorizadas e caso não estejam, solicita através de um "pop up" a permissão. A seguir, o código da classe de permissões:
Todas as Strings de permissão do Android
De: Giovanni Henrique
Como resposta ao e-mail enviado semana passada, o professor explicou que as publicações devem conter além do resumo semanal, contemplar técnicas importantes que desenvolvemos no decorrer da semana, lembrando que pode haver mais de uma publicação por semana. Seguindo esta orientação, iremos apresentar a construção de uma classe que gerência as permissões necessárias de uma aplicação mobile (Android).
Construindo a classe:
Para construir a classe de permissões, criaremos um método que dado como parâmetros um activity, um requestCode e uma listagem com as permissões verifica se as permissões passadas já estão autorizadas e caso não estejam, solicita através de um "pop up" a permissão. A seguir, o código da classe de permissões:
public class PermissionUtils {
//Solicita as permissões
public static boolean validate(Activity activity, int requestCode, String... permissions) {
List<String> list = new ArrayList<String>();
for (String permission : permissions) {
// Valida permissões
boolean ok = ContextCompat.checkSelfPermission(activity, permission) == PackageManager.PERMISSION_GRANTED;
if (! ok ) {
list.add(permission);
}
}
if (list.isEmpty()) {
// Tudo ok, retorna true
return true;
}
// Lista de permissões que falta acesso.
String[] newPermissions = new String[list.size()];
list.toArray(newPermissions);
// Solicita permissões
ActivityCompat.requestPermissions(activity, newPermissions, 1);
return false;
}
}
String[] permissoes = new String[] {
Manifest.permission.PERMISSAO_QUE_VOCE_QUER_1,
Manifest.permission.PERMISSAO_QUE_VOCE_QUER_2,
Manifest.permission.PERMISSAO_QUE_VOCE_QUER_3,
}
Todas as Strings de permissão do Android
De: Giovanni Henrique
sábado, 1 de julho de 2017
Vigésima Primeira Semana - Nosso Erro
Em nossa última aula de PDS, os professores orientadores nos chamaram a atenção quanto ao modelo de postagem que estamos seguindo. Apesar da conversa, continuamos com dúvidas a respeito disso, já que o modelo sugerido (ou o que entendemos dele) consiste em publicações a respeito de experiências passadas pelo time na semana, com o intuito de ajudar outros times que podem passar pelas mesmas coisas, mas o que entendemos da bíblia (dicas.ivan) consiste em relatórios semanais resumidos do progresso das atividades do grupo. Como estamos de férias a partir dessa semana, mandamos um e-mail com o intuito de tirar essa dúvida (enquanto isso vamos continuar errando).
Voltando à nossa programação, durante a semana refatoramos nosso código da documentação no LaTeX, separando os capítulos em arquivos diferentes, para facilitar a navegação. Também pesquisamos sobre análise estática, para que possamos prosseguir com nossa documentação.
Com isso, descobrimos que a análise estática de código verifica a qualidade do código-fonte. Essa verificação é realizada antes mesmo que haja execução do software, diferentemente do que ocorre com os testes unitários que validam o software com base no resultado de sua execução.
É importante ressaltar a diferença entre validação e verificação, para completo entendimento do conceito da análise estática. Uma verificação considera “fazer certo alguma coisa”, ou seja, garante que os passos para atingir um dado objetivo foram realizados corretamente. Verificação é eficiência. A validação trata de “fazer a coisa certa”, ou seja, garantir que o objetivo seja atingido, independente da forma como os passos foram realizados. Validação é eficácia. Considera-se, portanto, que a análise estática de código está relacionada à verificação, pois analisa como o código-fonte foi construído internamente.
A análise estática de código não verifica apenas arquivos texto (com extensão .java, .jsp, .js). Cada ferramenta, dependendo de sua implementação, pode realizar a verificação em código-fonte ou bytecode. Embora algumas ferramentas sejam capazes de realizar a verificação estática em arquivos JSP e JavaScript, por exemplo, a análise aqui costuma se focar especificamente em código-fonte Java (bem como EM bytecodes).
A análise estática pode ter sua verificação agrupada em três aspectos principais:
- Verificação por estilo: Considera elementos como indentação, espaços e tabs, convenção de nomes, número de parâmetros, alinhamento na vertical, formato e presença de comentários, dentre outros. São todos os aspectos que contribuem para tornar o código mais padronizado, organizado e legível. A ferramenta mais utilizada para verificação por estilo é o Checkstyle (http://checkstyle.sourceforge.net/);
- Verificação por boas práticas: Aplica uma gama de regras para verificar se práticas corretas estão sendo realizadas, como evitar duplicação de código, garantir o correto uso de encoding, implementação do método clone(), tamanho de métodos e classes, tamanho de parâmetros, uso do padrão Singleton, criação desnecessária de variáveis locais e muitas outras. O conjunto de regras é extenso e visa garantir que o código apresente as melhores práticas possíveis. A ferramenta de verificação mais utilizada para aplicar boas práticas é o PMD (https://pmd.github.io/);
- Verificação por bugs: Trata de encontrar erros no sistema. Isto é importante para antecipar a identificação de problemas no software (até antes mesmo de sua execução pelo cliente). A ferramenta mais utilizada para identificação de bugs é o Firebug (http://getfirebug.com/).
A verificação das ferramentas PMD e Checkstyle é realizada sobre código-fonte não compilado (arquivo com extensão .java), mas a verificação com Firebug analisa bytecodes (arquivos compilados do Java, com extensão .class). Desta forma, para análises envolvendo Firebug, uma compilação prévia é necessária. Isso é tratado pelo seu respectivo plugin, de forma que se faz transparente ao desenvolvedor.
Para fazer análise estática em projetos de Android, é recomendado o uso do Lint, outros softwares como FindBugs e o APK Analyzer (que já vem juntamente com o Android Studio) também são utilizados para fazer essas verificações.
Depois de tanta pesquisa, utilizamos o CheckStyle para verificar nosso código e achamos alguns erros. Na próxima semana, vamos documentar esses erros e terminar de corrigi-los.
De: Renata Souza
Voltando à nossa programação, durante a semana refatoramos nosso código da documentação no LaTeX, separando os capítulos em arquivos diferentes, para facilitar a navegação. Também pesquisamos sobre análise estática, para que possamos prosseguir com nossa documentação.
Com isso, descobrimos que a análise estática de código verifica a qualidade do código-fonte. Essa verificação é realizada antes mesmo que haja execução do software, diferentemente do que ocorre com os testes unitários que validam o software com base no resultado de sua execução.
É importante ressaltar a diferença entre validação e verificação, para completo entendimento do conceito da análise estática. Uma verificação considera “fazer certo alguma coisa”, ou seja, garante que os passos para atingir um dado objetivo foram realizados corretamente. Verificação é eficiência. A validação trata de “fazer a coisa certa”, ou seja, garantir que o objetivo seja atingido, independente da forma como os passos foram realizados. Validação é eficácia. Considera-se, portanto, que a análise estática de código está relacionada à verificação, pois analisa como o código-fonte foi construído internamente.
A análise estática de código não verifica apenas arquivos texto (com extensão .java, .jsp, .js). Cada ferramenta, dependendo de sua implementação, pode realizar a verificação em código-fonte ou bytecode. Embora algumas ferramentas sejam capazes de realizar a verificação estática em arquivos JSP e JavaScript, por exemplo, a análise aqui costuma se focar especificamente em código-fonte Java (bem como EM bytecodes).
A análise estática pode ter sua verificação agrupada em três aspectos principais:
- Verificação por estilo: Considera elementos como indentação, espaços e tabs, convenção de nomes, número de parâmetros, alinhamento na vertical, formato e presença de comentários, dentre outros. São todos os aspectos que contribuem para tornar o código mais padronizado, organizado e legível. A ferramenta mais utilizada para verificação por estilo é o Checkstyle (http://checkstyle.sourceforge.net/);
- Verificação por boas práticas: Aplica uma gama de regras para verificar se práticas corretas estão sendo realizadas, como evitar duplicação de código, garantir o correto uso de encoding, implementação do método clone(), tamanho de métodos e classes, tamanho de parâmetros, uso do padrão Singleton, criação desnecessária de variáveis locais e muitas outras. O conjunto de regras é extenso e visa garantir que o código apresente as melhores práticas possíveis. A ferramenta de verificação mais utilizada para aplicar boas práticas é o PMD (https://pmd.github.io/);
- Verificação por bugs: Trata de encontrar erros no sistema. Isto é importante para antecipar a identificação de problemas no software (até antes mesmo de sua execução pelo cliente). A ferramenta mais utilizada para identificação de bugs é o Firebug (http://getfirebug.com/).
A verificação das ferramentas PMD e Checkstyle é realizada sobre código-fonte não compilado (arquivo com extensão .java), mas a verificação com Firebug analisa bytecodes (arquivos compilados do Java, com extensão .class). Desta forma, para análises envolvendo Firebug, uma compilação prévia é necessária. Isso é tratado pelo seu respectivo plugin, de forma que se faz transparente ao desenvolvedor.
Para fazer análise estática em projetos de Android, é recomendado o uso do Lint, outros softwares como FindBugs e o APK Analyzer (que já vem juntamente com o Android Studio) também são utilizados para fazer essas verificações.
Depois de tanta pesquisa, utilizamos o CheckStyle para verificar nosso código e achamos alguns erros. Na próxima semana, vamos documentar esses erros e terminar de corrigi-los.
De: Renata Souza
Assinar:
Postagens (Atom)