Qualquer aplicação web com formulários que não exigem autenticação do usuário, sofre do mesmo problema: o SPAM! Em sua maioria, preenchido por spambots.
A técnica mais utilizada para a prevenção é o uso do reCAPTCHA, oficialmente originado do CAPTCHA, que foi desenvolvido pioneiramente na universidade de Carnegie-Mellon, nos EUA.
Um CAPTCHA usual envolve um computador (um servidor) que pede que um usuário termine um teste. Como os bots são incapazes de resolver o CAPTCHA, todo usuário que incorpora uma solução correta é presumidamente humano.
Já o reCAPTCHA pede para usuários digitarem palavras distorcidas exibidas na tela. Além de proteger que os robôs preencham os formulários, ele ajuda a digitalizar o texto de livros.
O problema é que o reCAPTCHA se torna chato para os usuários, o que atrapalha e muito na UX.
A técnica de Honeypot ou Invisible Captcha consiste no uso de um campo invisível no formulário. Os bots em sua maioria não carregam todo o HTML, CSS e Javascript da página. Isso faz com que eles não tenham uma visão da página como ela realmente é, não conseguindo distinguir os campos visíveis dos invisíveis.
Qual o resultado?
Eles vão preencher o nosso honeypot!
A gem invisible_captcha é muito simples, vamos ao passo a passo:
Adicione ao seu Gemfile:
1
|
|
Existe mais de uma forma de implementação, abordaremos aqui a implementação no Modelo.
Baste adicionar um atributo virtual a sua classe, como no exemplo abaixo e setá-lo como ‘invisible_captcha’:
1 2 3 4 |
|
Se você estiver usando strong_parameters, não se esqueça de colocar o atributo na hash de parâmetros.
1 2 3 |
|
Para customizar as configurações, adicione o arquivo invisible_captcha.rb em config/initializers com o seguinte:
1 2 3 4 5 |
|
Agora basta colocar o formulário na view:
1 2 3 |
|
Para ver o funcionamento, vá ao seu formulário com o inspetor do elemento do seu navegador e procure pelo honeypot. Veja um exemplo abaixo:
]]>Web Design Responsivo é uma abordagem que permite que um site proveja a melhor experiência de navegação e leitura para o usuário, adequando-se à diferentes cenários, baseando-se na resolução do dispositivo que o visualiza, seja um tablet, smartphone, computador, etc…
Quer ver um exemplo prático? Visite o nosso site: http://algorich.com.br utilizando um tablet e/ou smartphone, ou até mesmo, tente redimensionar a janela do seu navegador. Veja como os elementos são redistribuídos na tela e proporcionam fluidez e uma excelente experiência na navegação, adaptando-se a resolução.
Por mais que tudo isso pareça muito novo, esta abordagem começou em 2010, quando Ethan Marcotte publicou o artigo Responsive Web Design para o site A list Apart.
Na prática, para os desenvolvedores, este conceito baseia-se no uso do sistema de grids, que usa dimensões relativas em suas unidades de medida, como porcentagens e em, e não mais absolutas como pixels ou pontos. O que isso significa? O conteúdo não fica mais fixo e engessado em containers pré-definidos com 960px de largura por exemplo, e ainda possuem a capacidade de reorganização, de acordo com a largura disponível. As imagens também são flexíveis e se adaptam ao contexto onde estão, previnindo que ela desrespeite e escape das dimensões do elemento HTML em que está inserida.
Outra técnica é o uso das media queries do CSS3, que nada mais é do que uma extensão da regra @media que foi incluída desde a versão 2.1 do CSS. Com ela pode-se definir regras e comportamentos associados ao tamanho, orientação do dispositivo (retrato ou paisagem) ou a resolução de tela.
Os desenvolvedores não estão sozinhos. Hoje podemos contar com frameworks front-end maduros, robustos e com boa documentação disponíveis para uso, como por exemplo o Bootstrap, Foundation e Gumby
Alguns dados segundo pesquisa realizada pelo Datafolha:
Pesquisas apontam também que serviços como Facebook, Twitter e Youtube tem sido acessados cada vez mais por dispositivos móveis. O Youtube por exemplo, no final do ano passado já contabilizava 40% de seu acesso derivado de dispositivos móveis.
A NBC News divulgou esta imagem, ilustrada abaixo, que mostra um comparativo da Praça São Pedro, primeiramente no ano de 2005, durante a posse do Papa Bento XVI, e posteriormente em 2013, durante a posse do atual Papa Francisco. Numa diferença de 8 anos pudemos perceber a evolução da tecnologia e o crescimento absurdo do uso de dispositivos móveis.
Esses e outros fatos comprovam que o Web Design Responsivo veio pra ficar, e esse é um caminho sem volta. Vivemos num mundo cada vez mais conectado, hoje carregamos smartphones com grandes poderes de processamento em nosso bolso bastando alguns toques para termos facilmente um mundo de informações disponíveis em tempo real cabendo na palma de nossa mão.
Aqui na Algorich nossos trabalhos incluem as técnicas de web design responsivo. Quer saber mais? Entre em contato agora mesmo!
]]>Como exemplo, posso citar a regra de negócio de um seguinte cenário:
O pagamento de um aluguel deve ser realizado em uma data específica de cada mês, exceto quando esse data cai em um fim de semana. Nesse caso, o pagamento será realizado na próxima segunda-feira.
Onde a gem timecop atua?
Timecop é uma gem que provê à nossa aplicação a capacidade de viajar ou parar no tempo, isso permite que consigamos realizar testes com dependência de tempo de forma muito simples, e certamente assegurar os testes para a nossa regra de negócio detalhada acima.
Com a nova release do Rails 4.1, agora temos os métodos: #travel_to e #travel_back.
Com o #travel_to podemos facilmente alterar o dia e horário fornecendo um valor ou duração de tempo. Já o #travel_back faz com que retornemos ao estágio atual, desfazendo as alterações do #travel_to.
Essa feature teve um destaque muito pequeno (o que não diminui sua importância, na minha opinião), sendo mencionada apenas no final das notas da release:
1 2 3 4 5 6 7 8 9 10 11 12 |
|
Referência: http://brandonhilkert.com/blog/rails-4-1-travel-to-test-helper/
]]>Irei mostrar os principais motivos pelo qual devemos ter cuidado ao utilizar o FactoryGirl.
Existiria grande diferença entre estes dois exemplos?
1
|
|
1
|
|
Tudo depende de nossa definição na factory Event:
1 2 3 4 5 6 7 8 9 10 |
|
Utilizando esta factory nós não iremos apenas criar um novo objeto Event. Criaremos também um objeto Organizer, que é uma dependência de Event. Ou seja, estamos acessando a factory de organizer e definindo um objeto que muitas vezes nem iremos utilizar no teste.
1 2 |
|
1 2 |
|
Este exemplo mostra a implicação do uso inconsequente da FactoryGirl. Imagine quanto tempo acabamos perdendo em testes unitários que devem ser rodados constantemente. O principal fator causador de problemas de performance no primeiro caso é o acesso ao banco de dados. O FactoryGirl#build, apesar de não salvar o próprio objeto Event, ele possui um comportamento que sempre salva as dependências do objeto passado para este método, neste caso, o objeto Organizer.
Muitas vezes, a melhor opção para os casos em que precisemos do objeto salvo no banco de dados é um simples #create.
Velocidade nos testes é uma qualidade essencial, porém este não é o principal argumento para evitar o uso do FactoryGirl em testes unitários.
Ambientes de teste crescem, ficam complexos (assim como a aplicação), e chegam no ponto de visível lentidão para a prática de TDD por motivos citados acima. Quando isto acontece em testes unitários, algo está errado. Acabamos aceitando uma certa comodidade criada pelo alto acoplamento dos objetos gerados pelo FactoryGirl, e perdemos a especificidade do teste em questão.
Imagine a utilização desta factory:
1 2 3 4 5 6 7 8 9 |
|
Facilmente percebemos que caso alguém tente descobrir a utilização do método Event#can_enroll? pelo primeiro exemplo (utilizando FactoryGirl), não entenderá de fato o que o método faz.
Ou seja, além de ser muito mais custoso, estamos sendo implícitos.
Com FactoryGirl
1 2 3 4 5 6 |
|
Sem FactoryGirl
1 2 3 4 5 6 |
|
Definição do método
1 2 3 4 5 |
|
A questão é que sempre haverão mais validações, e mais dependências, causando um custo muito maior a médio/longo prazo, onde técnicas como Mocking & Stubbing se encaixam perfeitamente, tornando os testes específicos e principalmente unitários novamente.
]]>O que fazer quando temos aquela clássica situação de “funciona na minha máquina, o problema é na sua”? Todos já passaram por isso pelo menos uma vez na vida. Agora, a parte que costuma ser esquecida: rodar os testes somente no seu computador não é o suficiente! Por que? Porque ele está viciado. Sim, você já estava com o projeto “semi pronto” e isso pode deixar passar alguns problemas.
O ideal, seria que você construísse um novo ambiente, do zero, realizasse todo o processo de preparação dele para rodar a aplicação e então rodasse os testes. Mas se o projeto é grande, rodar todos os testes já deve tomar um tempo considerável, imagina então montar o ambiente do zero… Para nos ajudar com este problema, nós, na Algorich a técnica de integração contínua.
Mas que diabos é isso?
Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver multiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente.
Resumidamente, o tal “build automatizado” é quem vai fazer aquele procedimento trabalhoso de montar o projeto em um ambiente limpo e então verificar se os testes do projeto estão passando. Em um caso de falha de algum dos testes, toda a equipe é rapidamente notificada via email (o que pode facilitar integração com outros serviços externos, como o Trello). A partir dai, a equipe pode rapidamente idenfiticar a fonte deste erro e corrigî-lo, para que não sejam introduzidos erros no projeto junto com uma nova funcionalidade ou refatoração.
Mas não para por ai, calma, jovem. Um processo de integração contínua pode fazer muito mais por você do que você imagina. Vamos pensar: o que você precisa, ou desejaria, que fosse feito a cada commit enviado para o repositório? Aposto que você pensou naquele deploy para o servidor de staging. Se não pensou, ou nem tem um servidor de staging, ou nem sabe o que é isso, meu amigo… Recomendo que você leia esse material.
Então, se a idéia de integração contínua é automatizar as coisas (inicialmente, a integração do seu código com o repositório), por que não automatizar também o deploy para o ambiente staging? Assim, seu cliente terá um ambiente muito próximo ao de produção para poder testar as funcionalidades e encontrar bugs enquanto isso. Acredite, a quantidade de bugs que seus clientes encontrarão no servidor de staging vai te assustar, porque nós, desenvolvedores, não pensamos como usuários, por mais que nos esforcemos e acabamos deixando muita coisa passar. E nada melhor do que resolver isso antes do projeto entrar em produção, certo?
Mas peraí, faltou um detalhe: não podemos deixar o ambiente de staging uma bagunça! Vamos atualizar o código de staging se, se somente se, todos os testes do build passarem, assim podemos ter (e dar ao cliente também) uma garantia maior que o sistema não possui algum comportamento indesejado ou bug.
Agora você deve estar pensando em copiar e colar todos aqueles comandos que você usa para fazer seu deploy, né? Pois é, vamos dar um jeito nisso. A idéia é automatizar tudo! Testes foram automatizados para poupar tempo e evitar falha durante este processo delicado e repetitivo dentro da metodologia ágil, por que não automatizar o deploy também? Para cada caso, cada linguagem e até framework, existe a ferramenta de automatização de deploy adequada. Para nossos projetos web, onde usamos Ruby on Rails, utilizamos o Capistrano para esta tarefa, que com os scripts e recipes pré-definidos, basta um simples comando para fazermos um deploy para o servidor de staging ou produção, quando necessário, sem qualquer preocupação, sem erros.
Como dito anteriormente, nós da Algorich, utilizamos integração e deploy contínuos em nossos projetos. Para isso, usamos o Jenkins (uma conhecida ferramenta de integração contínua, software livre, e em constante evolução), Gitlab (nosso repositório de código) e o Trello (organização e gerenciamento dos projetos).
E como isso tudo se junta? Bem, através do plugin Gitlab Hook para o Jenkins, ele ficará escutando em uma determinada URL para receber requests que informarão sobre novos commits enviados ao repositório remoto. Em seguida, configuramos nos nossos repositórios para que eles enviem essa esperada requisição a cada push feito, através da interface de administração do Gitlab, e pronto, temos uma build disparado no projeto. Novamente no Jenkins, dizemos qual é o tipo de versionamento do projeto, o endereço do repositório remoto e quais comandos ele executará após clonar o projeto. Estes comandos são: instalação das dependências, um drop em qualquer banco de dados do projeto existente, execução das migrações do banco de dados ou criação das tabelas, execução dos testes e o deploy para staging. É importante notar que, caso sua ferramenta de testes gere uma saída de erro para o terminal, o build não chegará na parte do deploy. Caso contrário, você precisará fazer algo para “descobrir” quando aconteceu algum erro e evitar manualmente que o deploy seja iniciado.
O Jenkins é uma ferramenta completíssima e com inúmeros plugins, então pensamos: vamos integrar isso com o Trello? Vamos! E qual é a alternativa mais simples? Não sei se vocês sabem, mas é possível criar cards em um quadro do Trello via email. Dito e feito. Após a execução do build, em caso de falha, um email é enviado para um board do Trello específico para nossas builds (previamente criado por nós), que transforma-o em um card na lista correta, bingo!
Através desse grupo de ferramentas, conseguimos, dentre muitos outros pontos:
Diminuir a quantidade de deploys enviados para staging com bugs, e ainda mais para produção;
Diminuir a quantidade de pedidos do tipo “ai cara, faz um deploy pra mim” durante todo o dia de trabalho;
Ter um feedback ainda mais rápido dos nossos clientes, que viam as funcionalidades assim que o build e deploy finalizava com sucesso e o card da tarefa no Trello era movido para “Pronto”;
Bom galera, tentamos fazer aqui apenas uma descrição sucinta do que é deploy e integração contínua, apresentar as ferramentas que usamos para realizar estes importantes processos e como interligamos elas. Aguardem novos posts com tutoriais passo-a-passo de como configurar todas elas para fazer sua própria integração contínua!
]]>A melhoria é muito grande. Só para dar uma ideia, no meu notebook a lockscreen abriu em 10 segundos usando o AVD com o processador Intel e em 57 segundos usando o AVD com o processador ARM-based!
No site da Intel você encontra a documentação mostrando como fazer isso em ambientes Windows, Mac OS e Linux. Contudo, fiz minha versão em português, com algumas outras dicas e específica para Linux. Eu utilizei o Linux Mint 15, mas provavelmente funciona da mesma maneira no Ubuntu.
Em primeiro lugar, você tem que ter a SDK do Android instalada é claro. Se não for o caso, veja como fazê-lo neste post.
A KVM é uma solução completa de virtualização para Linux que roda em máquinas com processador Intel (x86). Para instalar e rodar a KVM primeiro você precisa checar se sua CPU suporta a virtualização de hardware, o que pode ser feito com o seguinte comando:
1
|
|
Se a resposta desse comando for 0, seu CPU não tem suporte. Se a resposta for 1 ou mais, beleza, mas ainda tem que ver se está habilitado na BIOS. Primeiro instale o pacote cpu-checker:
1
|
|
Em seguida, faça a verificação:
1
|
|
Sua resposta deve ser algo desse tipo:
1 2 3 |
|
Se não, sua resposta será algo como apresentado abaixo e você terá que entrar na BIOS para ativar a Intel Virtualization Technology:
1 2 3 4 |
|
O próximo passo é instalar a KVM e alguns outros pacotes necessários:
1
|
|
Depois, você deve adicionar seu usuário aos grupos kvm e libvirtd:
1 2 |
|
Em seguida, faça logout e login novamente para que as alterações tenham efeito.
Primeiro, vamos intalar o pacote que dá suporte a escolha da CPU da Intel na
criação do AVD. Abra o SDK Manager com o comando android
e instale o pacote
“Intel x86 Atom System Image” para a versão do Android que pretende usar (Figura
1). No meu caso escolhi a versão 4.2.2 porque o 4.3, que saiu ontem, ainda não
tinha suporte.
Em seguida, vamos criar um AVD normalmente, porém, com o processador da Intel.
Abra o AVD Managet com o comando android avd
. Para facilitar, usei uma
definição de dispositivo da aba “Device Definitions”, no caso, o Nexus 4. Basta
clicar na definição, depois em “Create ADV…”, escolher o target “4.2.2” e o
CPU “Intel Atom (x86)”. Além disso, para facilitar na hora de usar com o
emulador, troquei o nome do ADV para “nexus4” como pode ser visto na Figura 2.
Ponto, agora você tem seu dispositivo virtual com o processador Intel. Agora vamos utilizá-lo no emulador:
1
|
|
Se você quiser ver a diferença entre utilizar o processador Intel e o ARM, feche o emulador, edite seu AVD trocando a CPU dele para AMR e inicie o emulador novamente. A diferença é grande, né? =)
Inicie seu emulador e veja se acontece erro abaixo:
1 2 3 4 5 |
|
Se sim, para corrigí-lo basta encontrar o arquivo em sua máquina e criar um link simbólico na pasta onde está o Android SDK. Para encontra o arquivo:
1 2 3 4 5 6 |
|
Como meu sistema é 64 bits, vou usar o aquivo /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0 para fazer o link:
Obs: mude o ~/android para o local onde está o Android SDK na sua máquina.
1
|
|
Se isso não solucionar seu problema, dê uma olhada nessas respostas do stackoverflow.
Uma outra coisa que você pode fazer para acelerar ainda mais seu emulador é habilitar o uso da GPU. Basta editar seu AVD e selecionar o item “Use Host GPU”. Isso fará com que o emulador carregue ainda mais rápido (em 8 segundos na minha máquina), as animações de transição sejam mais rápidas e fluidas e os gráficos fiquem mais bonitos e bem definidos. Repare na diferença do papel de parede na Figura 3.
O único problema é que se você, assim como eu, utiliza o PhoneGap para desenvolver seus apps, o uso da GPU fará com que sua aplicação não abra direito, como na Figura 4. Não encontrei nenhuma solução para isso e eu mantive essa opção desmarcada. Se alguém solucionar esse problema, por favor deixe um comentário! =)
Mas e quando o comando não tem um autocompletar? Ou quando você gostaria de seus próprios scripts tivessem um autocompletar?
Neste post vou mostrar como você pode criar suas próprias funções de auto completar! =)
Para essa tarefa, o Bash nos fornece os comandos complete
e compgen
, além de
algumas variáveis:
Utilizando as variáveis fornecidas pelo Bash, podemos fazer o seguinte:
1
|
|
Assim, se estivermos digitando “nome mari” e apartarmos [TAB][TAB], o valor de
current
será “mari”.
Para isso vamos utilizar o comando compgen
com a opção -W
. Ele vai receber
uma lista de palavras, comparar com a palavra desejada e retornar uma lista de
possíveis “completadas”, por exemplo:
1 2 3 4 |
|
Sendo assim, podemos utilizar o resultado do compgen
para popular a variável
COMPREPLY que será utilizada pelo comando complete
.
As funções de autocompletar podem ficar em um arquivo na a pasta /etc/bash_completion.d (que inclusive é um ótimo lugar para ver exemplos de código) ou ficar direto no seu arquivo ~/.bashrc. Para simplificar, vou usar o ~/.bashrc e adicionar o código:
1 2 3 4 5 |
|
Estamos dizendo ao comando complete
que utilize a função _nome
para
modificar a variável COMPREPLY
com as possíveis “completadas” para o comando
nome
. Recarregue o seu ~/.bashrc e teste:
1 2 3 4 5 6 7 8 9 |
|
Agora que já entendemos como funciona, vamos para um exemplo real.
Um exemplo bem simples é o autocompletar que criei para o
Oh my gems! (um
substituto para os gemsets do rvm, geralmente usado em
conjunto com o rbenv). Além da opção reset, o comando
ohmygems
pode receber como parâmetro o nome de um novo “gemset” ou dos
“gemsets” existentes, que são nada mais que os os subdiretórios de
~/.gem/repos:
1 2 3 4 5 6 |
|
Agora vamos para um exemplo um pouco mais complexo.
Acredito que todo programador ruby utiliza o Rake (Ruby Make). Contudo, diferente do Make, o Rake não cria automaticamente um autocompletar com as tasks que você define no Rakefile. Mas nós podemos criar criar um! =)
Para ver todas as tasks disponíveis, podemos utilizar a opção -P
ou
--prereqs
do rake
, que mostra as tasks e suas dependências:
1 2 3 4 5 6 7 8 9 |
|
Beleza. Agora, para pegar apenas as tasks vamos usar o grep
e o cut
:
1 2 3 4 5 6 |
|
Já temos nossa lista de possíveis “completadas”, então vamos criar nossa função:
1 2 3 4 5 6 |
|
Geralmente, as tasks do rake
são separadas por contextos e esses contextos são
separados por “:”. Por exemplo rake db:drop:all
. A variável COMP_WORDBREAKS,
que guarda os caracteres separadores de palavras para o autocompletar, tem como
valor original a lista "'><;|&(:
. Repare que o : está entre esses caracteres,
mas não queremos que ele seja um separador de palavras. Para removê-lo, vamos
adicionar o seguinte antes da nossa função no ~/.bashrc:
1
|
|
Com isso você já tem um autocompletar para o rake
. No entanto, se estiver em
um projeto Rails, o rake
carrega a aplicação antes de executar as tasks.
Assim, a cada vez que você faz rake [TAB][TAB]
vai levar alguns segundos para
te mostrar as possíveis tasks, o que torna o auto complete inútil. Para resolver
esse problema, podemos criar um arquivo que será nosso cache de tasks do rake
e apenas atualizá-lo se algum dos arquivos de tasks for alterado depois da
criação do cache. Podemos verificar também se existem o arquivo Rakefile antes
de executar qualquer coisa. Nossa função de autocompletar final para o rake
fica assim:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
No manual de referência do bash do site do projeto GNU você encontra a documentação completa para a criação de funções para autocompletar. Você pode criar funções bem mais complexas, que completam de acordo com a opção anterior e etc. Só depende da sua criatividade e habilidade com shell script =)
]]>Aqui na Algorich nós utilizamo o PhoneGap para desenvolver aplicações mobile. Como diz no site, desenvolver com PhoneGap te dá a liberdade de criar aplicações mobile para 7 plataformas diferentes (com suporte completo à Android, iOS e Windows Phone) usando as tecnologias da web que você conhece e adora: HTML, CSS e Javascript.
Os apps criados com o PhoneGap não são nativos, porém, se comportam como tal. Eles são instalados no dispositivo e rodam em uma instância do browser padrão do sistema, ocupando 100% da tela. Além disso, o PhoneGap fornece uma API que te possibilita acessar funcionalidades nativas do sistema operacional (como a câmera, acelerômetro e etc) usando JavaScript. Os apps são criados utilizando o modelo single-page, onde a lógica do app fica em uma única página HTML que nunca é eliminada da memória, e todas as transições e apresentação dos dados são feitas através de atualizações no HTML DOM. Um exemplo de app criado com o PhoneGap é o app do Wikipedia.
Neste post irei mostrar como começar a desenvolver apps para Android utilizando o PhoneGap. O getting started do PhoneGap indica a utilização do Eclipse para montar o ambiente de desenvolvimento. Contudo, como não gosto de IDEs complexas e pesadas como o Eclipse (quando não estou usando Java), vou mostrar aqui como fazer o setup sem o uso dele, utilizando a linha de comando e seu editor preferido (no meu caso, o Sublime Text). Além disso, eu utilizo o sistema operacional Ubuntu Linux (versão 12.04 64bits), então algumas coisas que mostrarei aqui podem não ser válidas para outros sistemas.
Primeiro, você deve ter o java instalado. Caso não tenha, instale assim:
1
|
|
Após instalar o java, baixe o Android SDK no site de desenvolvedores do android. Para instalar descompacte o tar.gz em algum diretório de sua escolha. No meu caso, eu utilizo o diretório ~/install/. Em seguida, adicione a seguinte linha no seu arquivo ~/.bashrc:
1
|
|
Isso irá adicionar os diretórios onde estão as ferramentas do SDK (tools e plataform-tools) ao path de executáveis. Desta forma, será possível invocar as ferramentas sem necessidade de colocar todo o caminho onde elas estão, como comandos padrão do shell.
Vejamos algumas ferramentas essenciais do Android SDK:
Você deve baixar pacotes (packages) com imagens de sistemas Android, também chamadas de plataformas. Para abrir o SDK Manager use o comando android
com a opção sdk
.
1
|
|
O SDK Manager irá abrir. Você deve escolher uma (ou mais) versão do Android para instalar. Você só precisa instalar o pacote SDK Platform, sendo o restante opcional. Como é apresentado na figura 1, no meu caso, escolhi instalar apenas a versão 2.3.3 que é a versão que roda no meu celular.
Depois de instalar os pacotes, pode fechar o SDK Manager.
Um AVD (Android Virtual Device) é um emulador de configurações que te permite criar um modelo virtual de dispositivo, definindo o hardware e o software que serão emulados pelo Android Emulator. Desta forma, você pode emular diferentes configurações de dispositivos que rodam Android. Você pode criar quantos AVDs você precisar, de acordo com as configurações dos dispositivos os quais seu app é compatível (por exemplo, com diferentes tamanhos de tela e versões do Android), para testar seu app em cada uma delas. Você pode criar um AVD pela linha de comando, contudo, existe o AVD Manager que facilita um pouco. Para abrir o AVD Manager use o comando android
com a opção avd
:
1
|
|
Em seguida crie um novo AVD como apresentado na figura 2.
Obs: Caso você esteja rodando o Ubuntu 64 bits pode ser que você tenha o problema apresentado na figura 3 ao criar o AVD.
Caso isso ocorra, é porque você não tem o pacote ia32-libs
instalado. Para instalá-lo:
1
|
|
Depois de criado o AVD corretamente, pode frechar o AVD Manager.
O Android SDK espera que seu projeto siga uma estrutura específica de arquivos e diretório para que ele possa compilar e empacotar sua aplicação corretamente. A ferramenta android
criar um novo projeto com toda a estrutura definida. Recomendo que você veja a documentação para conhecer a estrutura de um projeto, entendendo para que serve cada diretório e arquivo do seu projeto.
Para criar um projeto Android, rode o seguinte comando:
1 2 3 4 5 6 |
|
Onde:
android list targets
.Para este artigo, vou criar um app HelloWorld:
1 2 3 4 5 6 |
|
Com isso, será criada a estrutura do projeto Android, como apresentada na figura 4.
Se você utilizar um sistema de controle de versão (se não utiliza, deveria) como o git, faça com que o arquivo local.properties e os diretórios bin e gen sejam ignorados pelo controle de versão.
Com a estrutura do projeto criada, é hora de adicionar o PhoneGap. Para isso, faça o download do PhoneGap e descompacte o .zip em algum diretório de sua escolha. No meu caso, eu utilizo o diretório ~/install/. Em seguida, no terminal, entre no diretório da sua aplicação e execute os seguintes comandos:
1 2 3 4 5 |
|
Abra o arquivo da classe Activity
(arquivo java contido no último subdiretório do diretório src), que no exemplo é o arquivo HelloWorldActivity.java, e edite o seguinte:
Activity
, mude para herdar de DroidGap
setContentView(R.layout.main);
por super.loadUrl("file:///android_asset/www/index.html");
import org.apache.cordova.*;
import android.app.Activity;
android:versionName
:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
|
android:configChanges="orientation|keyboardHidden"
a tag activity
no AndroidManifest.xml1 2 3 4 5 6 7 8 9 10 11 12 |
|
Obs: A única permissão realmente necessária para iniciar um hello world com o PhoneGap é a seguinte:
1
|
|
O restante pode ser adicionado quando/se houver necessidade.
Você pode mudar o nome de apresentação do seu app alterando a tag <string>
com o atributo name="app_name"
no arquivo res/values/strings.xml.
Existem duas formas de construir o seu app: release e debug. Neste post vou mostrar apenas como construir em modo debug, ficando o modo release para um outro post. Para construir o app, é utilizado o Ant. Para instalar o Ant faça o seguinte:
1
|
|
Com o Ant instalado, basta usá-lo para construir seu app:
1
|
|
Isto irá criar seu arquivo .apk de debug no diretório bin, chamado nome_do_app-debug.apk. Este arquivo será utilizado para instalar o app no emulador ou no dispositivo real, como veremos a seguir. Recomendo a leitura da documentação para entender os passos que o Ant executa internamente para a construção do app.
O Emulador te permite prototipar, desenvolver e testar dois apps sem a necessidade de utilizar um dispositivo real, através da simulação das configurações dos AVDs existentes. Assim, para iniciar o Emulador, você deve especificar qual AVD deseja carregar. Cada AVD funciona como um dispositivo independente, com seu banco de dados privado de informações de usuário, cartão SD e etc. Quando você inicia o Emulador com um AVD, ele automaticamente carrega todas as informações do diretório do AVD, onde estas informações são salvas por padrão. Para iniciar uma instância do Emulador, basta usar o comando emulator
definindo qual AVD será utilizado:
1 2 3 |
|
Uma janela com o Emulador será aberta como mostrado na figura 5. É normal o emulador demorar alguns segundos até terminar de carregar.
Para encerrar o Emulador, basta fechar a janela. O Emulador é uma ferramenta muito completa. Você pode interconectar diferentes instâncias do Emulador, manipular o cartão SD, simular envio de sms, entre outras diversas coisas. Veja na documentação todas as funcionalidades do Emulador.
Para executar o app no Emulador, você deve primeiro estar com uma instância do Emulador rodando, como mostrado acima, e ter construído seu app com o Ant. Em seguida, basta usar a ferramenta adb para instalar o app no Emulador:
1
|
|
Após estar instalado, para atualizar (reinstalar), deve-se utilizar o parâmetro -r:
1
|
|
Para (re)compilar e (re)instalar ao mesmo tempo usando você poderia concatenar os comandos:
1
|
|
Contudo, você pode fazer isso diretamente com o Ant da seguinte maneira:
1
|
|
Após ter sido instalado, o app pode ser encontrado no menu de apps do dispositivo emulado. Na figura 6 podemos ver o Hello World sendo executado no Emulador.
Você também pode utilizar dispositivos reais para desenvolver e testar seu app, especialmente nos casos em que o emulador não oferece suporte. Para isso, você deve seguir alguns passos:
Declarar o app “debuggable” no Android Manifest
No arquivo AndroidManifest.xml adicione android:debuggable="true"
ao elemento <application>
.
Obs: Lembre-se de remover isso quando for lançar a release do seu app.
Ativar a “Depuração USB” no seu dispositivo
No seu dispositivo, vá em Configurações > Aplicativos > Desenvolvimento e ative a Depuração USB (em dispositivos com Android 4.0, esta configuração está localizada em Configurações > Opções de desenvolvimento).
Dica: Ative também a opção Permanecer ativo para quando o dispositivo estiver carregando (ou seja, ligado ao computador pelo cabo USB) a tela não apague.
Configurar o sistema para reconhecer seu dispositivo (se não usa o Ubuntu, veja a documentação)
Você precisa adicionar um arquivo de regras udev que deve conter as configurações USB para cada dispositivo que deseja usar para desenvolvimento. No arquivo de regras, cada fabricante de dispositivos é identificado por um id único. Você deve ver na lista de fabricantes qual é o id do fabricante do seu dispositivo. Para configurar a detecção do dispositivo, faça o seguinte:
Faça login como root e crie este arquivo: /etc/udev/rules.d/51-android.rules.
Use este formato para adicionar cada fabricante ao arquivo:
SUBSYSTEM=="usb", ATTR{idVendor}=="0fce", MODE="0666", GROUP="plugdev"
O atributo ATTR{idVendor}
indica o id do fabricante, que neste exemplo é Sony Ericsson. O atributo MODE
especifica as permissões de leitura/escrita e o GROUP
define a que grupo do sistema o dispositivo pertence.
Agora execute o comando: chmod a+r /etc/udev/rules.d/51-android.rules
Após ter seguido estes passos e estar com o dispositivo ligado à porta USB, você pode usar o comando adb devices para listas os dispositivos.
Para executar o app em dispositivos reais você usar o mesmos comandos apresentados para o Emulador, sendo que ao usar o adb deve ser adicionado o parâmetro -d. Já ao usar o Ant, não precisa modificar nada no comando, uma vez que o Ant tenta instalar em uma instância do Emulador e, caso não encontre uma instância rodando, tenta instalar em algum dispositivo conectado.
Assim como no Emulador, após ter sido instalado, o app pode ser encontrado no menu de apps do dispositivo. Na figura 7 podemos ver o Hello World sendo executado no meu telefone.
Na versão 2.0 do PhoneGap, lançada no dia 20 deste mês, foi adicionado o Command Line Tooling, que é um conjunto de scripts para realizar tarefas repetitivas e comuns à todas as plataformas como criar, construir e emular apps.
Todos os passos realizados anteriormente para criar um projeto Android e adicionar o PhoneGap são resumidos à um único comando.
Contudo, para executar no Ubuntu devemos fazer uma alteração no script, pois ele utiliza o interpretador padrão do sistema (que pode ser acessado pelo /bin/sh
) que no Ubuntu é o dash
. Porém, devido aos erros que encontrei ao rodar o script, acredito que ele foi feito para ser interpretado pelo bash
. Assim, basta mudar a primeira primeira linha para: #! /bin/bash
.
Para criar o projeto basta rodar o script create
encontrado no diretório do PhoneGap:
1 2 3 |
|
No caso do nosso exemplo seria o seguinte:
1 2 3 |
|
Com isso, será criada a estrutura do projeto Android, como apresentada na figura 8.
Repare que é criado um diretório cordova com alguns scripts. Para saber o que cada um desses scripts faz, veja a documentação, mas vamos ver dois que fazem tarefas que mostrei anteriormente.
Para iniciar o Emulador:
1
|
|
Para construir o app:
1
|
|
Na figura 9 podemos ver o Hello World criado pelo create
do PhoneGap sendo executado no Emulador.
O legal desse app padrão criado é que ele tem vários exemplos de utilização da API do PhoneGap que você pode ver, modificar e testar.
Neste post mostrei como criar um Hello World do zero usando o PhoneGap e as ferramentas de linha de comando do Android SDK, sem a necessidade da utilização do Eclipse. A partir desse ponto, você tem condições de brincar tranquilamente com a API do PhoneGap =)
Até a próxima!
]]>Olá pessoal,
Hoje vamos mostrar como deixar o seu servidor com acesso SSH mais seguro. Por padrão, o SSH aceita conexão através de senha em texto livre. Quem souber a senha, pode se logar no servidor. Isso é bastante perigoso, pois se a senha não for muito complicada, um bot pode descobri-la através da força bruta.
Uma forma de evitar isso é configurar o SSH para aceitar apenas conexões através da chave pública (saiba como criar uma chave). Funciona da seguinte forma: você envia sua chave pública para o servidor (na pasta home do usuário que você quer logar) e configura o SSH. Quando você tentar fazer o login, ele vai realizar a verificação da sua chave pública e requisitar que você digite a senha. Caso esteja tudo OK, você se loga normalmente.
Lembrando que essa configuração foi testada no Debian/Ubuntu.
Antes de configurar o SSH, copie a sua chave pública para uma pasta qualquer no servidor.
1
|
|
E quando estiver logado no servidor:
1
|
|
Com isso feito, podemos configurar o SSH. Para isso, como root, abra o arquivo /etc/ssh/sshd_config e altere as seguintes opções:
1 2 3 4 5 6 |
|
Em seguida, reinicie o SSH:
1
|
|
Pronto! Sempre que você acessar o servidor, a autenticação será por chave pública. Caso queira que mais pessoas tenham acesso ao servidor, basta adicionar as chaves públicas no arquivo /home/.ssh/authorized_keys.
Abraços e até a próxima!
]]>Fala pessoal, tudo certo?
O feedback de vocês em relação ao post passado foi sensacional e muita gente está a fim de participar do #horaextra Campos. Então ele acontecerá!
O primeiro #horaextra Campos ocorrerá na terça-feira (dia 05/06/12) às 19h no Bar da Boa. A ideia é manter esse dia da semana, horário e local. Para quem não conhece o local, ele fica em uma esquina da Avenida Pelinca com a Formosa mapa no google.
Conto com a presença de TODOS lá!
Abraços!
]]>Assim, como queremos contribuir e ajudar a criar um ambiente colaborativo e conhecer melhor os profissionais da região, vamos criar o #horaextra Campos!
Olá pessoal,
Hoje, oficialmente, inauguramos o blog da Algorich! Nosso objetivo é compartilhar conhecimento e ter um canal de interação com todos os desenvolvedores, programadores, web designers e empreendedores da região.
Neste espaço falaremos de diversos assuntos como Ruby on Rails, Empreendedorismo, Ruby, Python, Shell, Linux, HTML, CSS, JavaScript, jQuery, desenvolvimento mobile, entre outros. Além disso, iremos mostrar também como trabalhamos aqui na Algorich e algumas das experiências que passamos em nosso dia a dia.
Assim, como queremos contribuir e ajudar a criar um ambiente colaborativo e conhecer melhor os profissionais da região, vamos criar o #horaextra Campos! Para quem não conhece, o #horaextra surgiu no Rio de Janeiro e tem o objetivo de reunir amigos e profissionais de tecnologia em um dia da semana após o expediente. Para mais detalhes, acesse horaextra.org.
E então? Quem topa? Que tal vocês se apresentarem nos comentários? Vamos lá, dê-nos esse feedback e apareça! Nosso #horaextra será toda quinta-feira às 19:30h. O local ainda será definido e informado pelo blog e redes sociais (Facebook e Twitter)
Para nos conhecer, basta acessar a página da nossa equipe.
Esperamos que vocês curtam o nosso espaço e o #horaextra!
Abraços!
]]>