COST do password_hash

Como complemento para o post Como armazenar as senhas corretamente com PHP, quero mostrar como o parâmetro “cost” é utilizado no password_hash e com isso te ajudar a entender qual é o valor mais adequado para você usar.

Um detalhe quanto ao valor do “cost”, não há um valor certo para a sua aplicação, você tem que escolher um valor que faça sentido para ela. Por isso esse post, ele é para explicar justamente o impacto que esse parâmetro tem.

Para saber o tempo que de cada valor do “cost” executei esse script.

E esse foi o resultado em segundos.

A configuração da máquina que estou usando é essa.

Com base nesses valores, você consegue ter uma base de quanto tempo vai levar para gerar uma senha, lembrando que sempre que um usuário se cadastrar, ou logar ela vai chamar os comandos de password várias vezes e isso vai impactar no tempo que ele leva para entrar em seu sistema e fora isso, vai sobrecarregar o seu servidor, então, outros usuários podem ser impactados com isso.

É isso.

Integração contínua com FTP em hospedagem compartilhada

Deploy via FTP hoje em dia é tipo o Batman, o herói que nós precisamos e não o que queremos.

Nos últimos dias, estou trabalhando em um projeto que não há orçamento disponível, basicamente, minha esposa mandou parar de gastar.

Junto com um amigo, tenho um plano de revenda de hospedagem compartilhada, esse aqui, vendemos esse serviço para outros amigos e por ai vai. Como não há orçamento para esse projeto, estou usando uma cota minha da revenda.

Sendo uma hospedagem compartilhada eu perco diversas coisas, uma delas é o acesso SSH, algumas até disponibilizam, mas a minha experiência com isso não foi das melhores.

Vamos ao ambiente. Como repositório de código eu deixo no Bitbucket, isso porque eu posso criar repositórios privados de graça. Com ele eu uso o serviço de pipeline, também de graça. No pipeline, posso montar da mesma forma como no Trevis CI, um arquivo de configurações e ele se vira para rodar os testes unitários, de aceitação e por ai vai.

O deploy, faço via FTP, sim é muito chato fazer isso, mas tem um cara que resolve esse problema para mim, novamente, DE GRAÇA, ele é o DeployBot, com ele, consigo rodar “composer install” em uma imagem docker e ele gerencia isso para mim, pega os arquivos criados na pasta vendor e encaminha para o servidor, conforme for alterado o composer.json ele vai enviar novamente essa pasta, caso contrário só vai enviar as alteraçõs que estão no commit, esse gerenciamento é o que possibilita o deploy via FTP ser aceitável.

Juntando tudo isso, eu consigo fazer meus deploys de forma fácil, não preciso deixar as dependências no projeto e o melhor, usar efetivamente um FTP, o DeployBot que se vire nisso.

Volto a falar, existem formas melhores de fazer isso, mas o deploy via FTP é uma realidade, vamos deixar isso pelo menos mais fácil.

Assim que terminar eu posto o mão na massa, explicando como eu fiz tudo.

 

[ATUALIZAÇÃO]

Link explicando como foi feito.

Automatizando o não automático

Aposto que você já ouviu várias pessoas falando sobre a automatização de tarefas no desenvolvimento de software e acredito que seu foco estava no Jenkins, Trevis CI e por ai vai. Depois de algum tempo trabalhando em um projeto que iniciei na empresa onde trabalho, percebi que os projetos open source tinham uma grande contribuição que ia além das ferramentas de CI.

Nos projetos que participei, notei que algumas das informações que eu precisei pedir para alguém, eu simplesmente não precisaria, essa informação poderia estar em algum lugar mais simples do que na mente de alguém, não falo em documentação em si, falo dos itens básicos para que alguém que não faz parte do seu dia a dia possa te ajudar no seu produto.

Imagine o seguinte. Você faz deploy todos os dias no ambiente de QA, ali você coloca diversas alterações de código, você garante que o código que esta ali funciona basicamente com duas coisas, testes manuais para validar aquele teste automatizado que acabou de fazer e testes automatizados, esses para garantir que não quebrou nada. Para “avançar” de ambiente, não há muita diferença, logo o maior trabalho de deploy automatizado esta em QA.

Agora, como resolver problemas de automatização com as coisas que você não precisa fazer todos os dias. Se não se faz todos os dias não precisa ser automatizado, simples, problema resolvido. Só tem um pequeno problema, sua vida não esta ficando mais fácil.

Como você resolve aquele problema de explicar para o cara novo como a banda toca? Um README.md já resolve a maior parte de seus problemas, um CONTIBUTION.md então, nem se fala. Olhe o README.md do Skeleton do ZF2, ele se explica.

Monte uma documentação pensando em alguém que chegou agora no seu time pode fazer um “hello word”, do contrário, toda a vez que uma nova pessoa chegar ela vai precisar falar com você. Ninguem chega alterando o core, simples assim, por conta disso, essa é a documentação que mais precisa ser visível.

Faça isso com um exemplo simples, formate seu computador (ou crie uma VM), você PRECISA conseguir subir seu projeto seguindo apenas a documentação do README.md e do CONTRIBUTION.md, se precisar ir no stack overflow já sabe seu próximo commit. Ou melhor ainda, use o cara novo, tudo o que ele tiver de fazer para rodar o projeto na máquina dele ele coloca na documentação.

Você não automatizou o processo da criação de uma nova máquina de desenvolvimento, mas você automatizou você, seu conhecimento agora esta em um arquivo de fácil leitura (eu acho), agora não é mais necessário chegar até você para iniciar o projeto, essa documentação já resolve o quick start.

Automatizar não é apenas para as tarefas de todo o dia e sim para tarefas repetitivas, sendo elas eventuais ou não. Toda a vez que você automatiza um processo, você reduz possíveis erros operacionais.

Vagrant para ambiente de dev

Há alguns dias, perdi um bom tempo tendo que acertar algumas configurações para um servidor WAMP. Sim, isso me irritou, pois como rodar um Apache no Ubuntu é mais fácil eu demorei para achar como configurar. Ai eu tinha que configurar um LAMP e depois um WAMP, isso me deixou um pouco irritado, pois eu fiquei pensando, deveria ter algo melhor para fazer isso.

Mas tudo isso é apenas algo trabalhoso que pode ser feito, não chega a ser um grande problema, agora, imagine que a sua aplicação usa PHP, MySQL, Memcached, Redis, MongoDB e para terminar a festa, uma API RestFul feita em Java rodando no Apache Tomcat. Isso para um projeto, agora pense nos inúmeros ambientes que podemos precisar em uma mesma máquina, instalando tudo isso estaríamos sobrecarregando essa máquina, deixando até as tarefas mais simples como responder um e-mail complicadas de serem executadas pela demora na resposta da máquina.
Agora, você poderia ir desativando e ativando os serviços conforme necessário, porem isso também seria trabalhoso. É nesse ponto que entra o Vagrant. Nele podemos subir uma interface mais próxima ao nosso servidor e habilitar e desabilitar ele com apenas um comando. Como nem tudo na vida é fácil, ainda vamos precisar configurar o ambiente, porem isso sera feito apenas uma vez.

Site Vagrant

Vamos agora ao que interessa 🙂

Para o Vagrant funcionar, precisamos ter um gerenciador de máquinas virtuais, o Vagrant suporta VirtualBox, VMware e Hiper-V. Para nosso teste vamos utilizar a VirtualBox, ela pode ser baixada aqui.

Vamos precisar também baixar o Vagrant Aqui.

Depois dele instalado precisamos iniciar o Vagrant em alguma pasta, da mesma forma que fazemos para o git.

vagrant init

Esse comando vai criar o Vagrantfile, esse arquivo sera usado mais a frente para fazer algumas configurações.

O Vagrant, funciona com “boxes”, que são as VMs. No site vagrantbox.es você pode baixar a box que quiser. Eu escolhi a precise32 para demonstrar.

vagrant box add precise32 http://files.vagrantup.com/precise32.box

Ai só esperar baixar e partir para a configuração.

vagrant up

Esse comando ira iniciar a VM.

Quando ela estiver iniciado, basta acessar ela via ssh e configurar da forma que achar melhor.

vagrant ssh

Se por acaso você fizer merda, basta destruir a VM, depois disso basta iniciar e acessar via ssh.

vagrant destroy

Agora vamos configurar o Vagrantfile.


Vagrant.configure(2) do |config|
    config.vm.box = "ubuntu32"

    config.vm.network :forwarded_port, host: 8080, guest: 80
    config.vm.network :forwarded_port, host: 3306, guest: 3306
end

Com essa configuração, estamos fazendo um redirecionamento de portas, apontando as portas do host (minha máquina) para o guest (VM).
Bom, eu não sei muito sobre o Vagrantfile, mas aqui esta a sua documentação.

Até aqui falamos como configurar, subir e bla bla bla. Agora vamos falar sobre o motivo de usarmos o Vagrant e não a VM direto.

A parte interessante do uso do Vagrant é o fato que ele já monta uma unidade de disco “/vagrant” dentro da VM, essa pasta é a mesma que você fez o “vagrant init”.

Se ainda não consegui te convencer, seguem alguns dos meus motivos para usar o Vagrant.

  • Todo o trabalho para instalar uma VM
  • “vagrant destroy” desfaz toda a merda que você fez
  • Redirecionamento de portas de forma simples
  • “vagrant up” tudo funcionando “vagrant halt” seu computador fica limpo
  • Monta uma unidade de disco por padrão

Acho que é isso, escrevi bastante aqui, espero que tenham gostado.

Display LCD e potenciometro – Arduino

Vamos a mais um post sobre Arduino, pois é estou bem empenhado.

A brincadeira é a seguinte.
Vamos multiplicar o valor lido por dois potenciômetros e mostrar o resultado em um LCD. Simples certo.

O LCD que usei é esse aqui e essa é a pinagem dele.

Pino Função Descrição
1 Alimentação GND
2 Alimentação VCC
3 V0 Pino para ajuste do contraste
4 RS 1 = Dado, 0 = Instrução
5 R/W 1 = Leitura, 0 = Escrita
6 E (Chip select) 1 = Habilita, 0 = Desabilita
7 B0 LSB Barramento de dados
8 B1 Barramento de dados
9 B2 Barramento de dados
10 B3 Barramento de dados
11 B4 Barramento de dados
12 B5 Barramento de dados
13 B6 Barramento de dados
14 B7 Barramento de dados
15 A Anodo do LED de backlight
16 K Katodo do LED de backlight

Como montar o LCD

  • Pino 2 do Arduino vai no 14 do display (Pino 14: B7)
  • Pino 3 do Arduino vai no 13 do display (Pino 13: B6)
  • Pino 4 do Arduino vai no 12 do display (Pino 12: B5)
  • Pino 5 do Arduino vai no 11 do display (Pino 11: B4)
  • Pino 11 do Arduino vai no 6 (Enable) do display
  • Pino 12 do Arduino vai no 4 (RS) do display
  • Vcc do Arduino, ligar nos pinos 2 e 15 do display (Pino 2 : Vdd, Pino 15 : A/Vee)
  • GND do Arduino, ligar nos pinos 1, 5 e 16 do display (Pino 1: GND, Pino 5: RW, Pino 16 : 0v (luz de fundo)
  • Ligar pino 3 do display no pino central do potenciômetro, que vai fazer a regulagem do contraste (Pino 3: Vo (Ajuste de contraste)

Agora que foi explicado como devemos fazer a ligação do LCD, segue o schema do projeto.

LCD Potenciômetro Schema

Com o schema montado, é só abrir a Arduino IDE, colocar o código e mandar para o Arduino.

No fim das contas, o projeto ficou assim.
Os dois potenciômetros (esquerda e meio) são os reponsáveis por fornecer os valores para a multiplicação e o da direita gerência o contraste do LCD.

Tudo montado e rodando ficou assim 🙂
Arduino, LCD e Potenciômetro

A oficina do Diabo – Arduino

Sabe aquele momento onde você esta meio sem fazer nada e percebe que pode aprender uma coisa nova e diferente da área que você lida todos os dias. Então, foi assim que eu comecei a aprender eletrônica.

Lembrei das aulas que tive na escola, era uma matéria que eu tinha que passava por todos os cursos técnicos para que possamos escolher qual nós iriamos fazer, ai vem a mente o que é um capacitor, um resistor e um transistor.
Ai eu penso “bem que eu poderia estudar eletrônica usando um Arduino, que sabe fazer uma pequena automação residencial”. Mas isso é para quando souber o que estou fazendo rsrs.

Para conseguir eu precisva de pelo menos um Arduino. Foi ai que comecei a pesquisar, descobri que um dos meus colegas de trabalho possui um e-commerce de produtos para eletrônica o Baú da Eletrônica comprei um kit básico para iniciante, um Arduino Uno, uma protoboard maior do que a que vem no kit e mais algumas pequenas coisas para começar a brincadeira.

Agora é estudar e ver o que acontece 🙂

Conforme eu for fazendo testes e pequenos projetos eu vou postando aqui como foi feito.

Amazon AWS – Experiência de uso

Olá.

Nos últimos dias venho utilizando o serviço Amazon AWS e preciso dizer uma coisa, é animal.
Ele foi muito bem pensado (até onde percebi), criei um servidor LAMP em poucos minutos, não satisfeito fui usar o banco de dados relacional deles o RDS, sensacional.
A partir dai comecei a brincar a parte de segurança de acesso deles, muito simples, consegui dizer exatamente que porta estava aberta para quais IPs, públicos ou privados com pouco esforço.
Para finalizar minha experiência, fiz alguns testes com o load balancer. Minha primeira experiencia com essa tecnologia fico até sem saber como fazer esse review.

Tudo o que fiz ficou dentro do uso gratuito de 12 meses deles, para saber mais clique aqui.
Nos próximos posts irei demonstrar algumas aplicações que podem ser feitas

Abraço