17 Mar 2015
Meus poderes de montagens, são mais de 8 MILLLLL
Olá Pessoal, vou mostrar como é fácil gerar uma chave privada para, as suas aplicações feitas para Android, você vai precisar de apenas que ter o JAVA JDK, meu sistema operacional que estou usando é o Linux Mint, mas o processo é bem similar nos outros sistemas operacionais.
O sistema Android requer que todas as aplicações instaladas sejam assinadas digitalmente com um certificado cuja chave privada é mantida pelo desenvolvedor. O Android usa o certificado como um meio de identificar o autor da aplicação e estabelecer uma relação de confiança entre as aplicações.
O certificado não controla que aplicações o usuário pode instalar. Ele não precisa ser assinado por uma autoridade certificadora: é perfeitamente permitido, e tipico, aplicações Android usarem certificados auto-assinados.
Nesse tutorial vamos apenas gerar a chave privada, em outro tutorial vamos publicar um aplicativo desenvolvido com Phonegap (Mas isso é outro tema que vamos abordar mais para frente), então…
Atenção
Depois de gerada a chave siga as recomendações abaixo para manter a longevidade de sua aplicação, que estará publicada
- Esteja em sua posse
- Represente a entidade pessoal, corporativa ou organizacional que será identificada com sua aplicação
- Tenha um período de validade que exceda o tempo de vida esperado da aplicação. Um período de validade de 25 anos é recomendado. Se você planeja publicar sua aplicação no Google Play, observe que um período de validade que termine depois de 30/11/2034 é necessário; Você não poderá fazer upload de um apk se este estiver assinada com uma chave cuja validade expire antes dessa data.
- Guarde a senha que você gerou assim como o Alias da aplicação.
Caso tenha mais alguma dúvida, leia o artigo Securing Your Private Key
####Chega de blá, blá porque agora é mão na massa.
Para gerar a chave vamos usar o comando e ferramenta do JDK o Keytool.
Vamos abrir o terminal se preferir use o Ctrl+Alt+t:
keytool -genkey -v -keystore "nomeDaChave.keystore" -alias NomeChave -keyalg RSA -validity 10000
Precione Enter, digite a senha para a chave.
Logo em seguida aparecera informações que você deve preencher.
Depois pedira para confirmar com Sim ou Não seus dados e escolha a opção adequada…
Tudo ocorrendo com planejado, aparecerá um dialogo pedindo que você digite outra senha para a chave gerada, ou se quiser usar a mesma senha que colocou no começo apenas digite RETURN.
Como não escolhemos um diretorio, por padrão o keytool vai gerar a chave na pasta home
Simples assim
###Mas o que significa cada comando do Keytool?
keytool -genkey -v -keystore "nomeDaChave.keystore" -alias NomeChave -keyalg RSA -validity 10000
Vamos por partes
- Morgan, Dexter
Gera um par de chaves (pública e privada)
Ativa o modo verbose
Um nome para a keystore que conterá sua chave privada.
Um apelido para a chave. Apenas os 8 primeiros caracteres do apelido são usados.
Algoritmo de encriptação usado para geração da chave. Tanto o DSA quanto o RSA são suportados.
O periodo de validade da chave, em dias. Um valor de 10000 ou maior é recomendado.
Outros comando uteis, mas não necessários
O tamanho de cada chave gerada (bits). Se não fornecida, Jeytool usa um tamanha padrão de 1024 bits. Em geral, é recomendado uma chave de 2048 bits ou maior.
Um nome único que descreva quem criou a chave. O valor é usado nos campos issuer e subject nos certificados auto-assinados.
Observe que você não precisa especificar essa opção na linha de comando. Se não fornecida, o Jarsigned lhe pedirá para informar cada campo Nome Único (CN, OU, e assim em diante).
A senha para essa senha.Como precaução de segurança, não inclua essa opção na linha de comando. Se não fornecida, o Keytool pedirá que você informe a senha. Desta maneira, sua senha não será armazenada no histórico do shell.
Uma senha para a keystore.
Como precaução de segurança, não inclua essa opção na linha de comando. Se não fornecida, o Keytool pedirá que você informe a senha.
Isso é tudo pessoal!
28 Feb 2015
JSON é um acrônimo para “JavaScript Object Notation”, é um formato leve para intercâmbio de dados computacionais. JSON é um subconjunto da notação de objeto de JavaScript, mas seu uso não requer JavaScript exclusivamente.
a enciclopédia livre, Wikipédia
####Afinal, o que é JSON?
JSON é como diz a Wiki é basicamente um formato leve de troca de informações/dados entre sistemas. só podendo usar com JavaScript correto? Na verdade não e alguns ainda caem nesta armadilha.
O JSON além de ser um formato leve para troca de dados é também muito simples de ler. Mas quando dizemos que algo é simples, é interessante compará-lo com algo mais complexo para entendermos tal simplicidade não é? Neste caso podemos comparar o JSON com o formato XML.
###XML
###JSON
{"id":1,"nome":"Joao da Silva", "endereco":"R. Dos Bobos"}
Muitas das suposições sobre o quão lento, dispendioso e “gordo” o XML é se comparado à leveza do JSON, não foram sustentadas pelo teste feito por David Lee, engenheiro líder na Marklogic, após a execução de um experimento “crowd sourcing” com 33 documentos diferentes e aproximadamente 1200 testes, em uma grande quantidade de navegadores e sistemas operacionais mais utilizados. David afirma ter descoberto que o desempenho total da experiência de usuário ‒ transferência, análise (parsing) e consulta (querying) de um documento ‒ é quase idêntico em ambos os formatos: XML e JSON.
Para o seu experimento David criou e divulgou publicamente um ambiente de teste que imita um caso de uso em que documentos XML e JSON são entregues por um servidor web, para serem analisados e consultados em um navegador web.
O servidor abastece o cliente com uma fonte de dados, e coleta os resultados provenientes do cliente. O cliente é uma aplicação JavaScript executada no navegador, codificada especificamente para medir performance, exceto a parte que faz as medições de desempenho do jQuery.
Além de usar sete documentos diferentes com tamanhos entre 100Kb e 1Mb, e cada documento apresentar duas variantes JSON e três variantes XML, David também tentou cobrir uma gama de dispositivos, navegadores, sistemas operacionais e redes em seu teste. Ele fez isso através de “crowd sourcing”, ou seja, tornou pública a URL do ambiente de testes e divulgou em várias listas de e-mail e sites de mídia social. O resultado de aproximadamente 1200 testes distintos e bem sucedidos foram coletados até agora, abrangendo os navegadores e sistemas operacionais mais utilizados. Em seu artigo, David documentou todos os dados do teste, bem como os seus resultados.
Algumas das conclusões obtidas após a experiência de David são:
- A velocidade de análise (parsing) varia de acordo com a técnica usada. A análise com JavaScript puro é mais rápida para XML do que para o JSON, enquanto a consulta é normalmente mais rápida para o JSON. Ambos apresentando exceções, em que o contrário é verdadeiro.
- O uso da biblioteca JavaScript jQuery impõe uma penalidade exagerada para o JSON, e pior ainda para o XML.
- Documentos compactados em todos os formados, mesmo representações muito grandes em JSON ou XML apresentam tamanho idêntico após a compressão, o que indica que ambos possuem o mesmo conteúdo de informação.
- A transferência de documentos para uma grande variedade de dispositivos leva efetivamente o mesmo tempo em cada dispositivo, independentemente do formato adotado (XML ou JSON).
Baseando-se em seu experimento, David inclui algumas sugestões para arquitetos e desenvolvedores:
- Usar Compressão HTTP, na maioria das vezes, é o fator mais importante no desempenho total.
- Otimizar a marcação para transmissão e consulta.
- Não tentar otimizar, a menos que a transmissão de dados, a análise e a consulta sejam problemas significativos se comparados às outras questões.
25 Feb 2015
Prepare-se toda a web que você conhece esta prestes a mudar. A nova versão e muito aguardada do HTTP deu um importante passo para se tornar uma realidade na quarta-feira, quando foi oficialmente finalizado e aprovado.
Mark Nottingham, presidente da Internet Engineering Task Force (IETF) grupo de trabalho por trás da criação das normas, anunciou em um post de blog as especificações do HTTP 2.0.
HTTP, ou Hypertext Transfer Protocol, é um dos padrões da web, usando no inicio do domínio para navegação web. Ex: http://codehamper.com , rege as conexões entre o navegador do usuário e o servidor que hospeda o site, inventado pelo pai da web Sir Tim Berners-Lee.
HTTP/2 é simplesmente uma atualização do protocolo, mas é realmente uma grande atualização, porque a ultima vez que as especificações do HTTP foram mudadas foram em 1999. Isso significa que o HTTP/2 sera a primeira grande atualização do HTTP nos últimos 16 anos, desde o HTTP 1.1 de 1999.
O que é HTTP/2 ?
HTTP/2 promete entregar paginas da Web para navegadores mais rápido, permitindo que os usuários visualizem mais paginas, possam comprar mais coisas, realizar mais e mais rápidas pesquisas na Internet.
HTTP/2 é baseado no protocolo SDPY, um protocolo introduzido pelo Google em 2009 e adotado por algumas tecnologias incluindo o próprio Google Chrome, Mozilla Firefox, Internet Explorer, muitos sites como o Facebook, e alguns dos softwares.
SPDY foi projetado para acelerar o carregamento de paginas da web e melhorar a experiencia da navegação dos usuários. Ambos SPDY e HTTP/2 usam compressão de campos no cabeçalho e multiplexação para deixar navegadores realizar varias solicitações para servidores web através de uma unica conexão.
“HTTP/2 usa multiplexação para permitir que muitas mensagens que serão intercaladas em uma conexão ao mesmo tempo, de modo que uma grande resposta (aquele longo tempo que o servidor leva para pensar) não bloqueie os outros” – Nottingham.
Pesquisar tudo mais rápido
HTTP/2 não vai substituir o padrão da web tradicional que o mundo conhece e ama, mas espera ajudar a websites a carregar mais rapido e de forma mais segura, uma vez que é adotada em uma escala de largura.
O HTTP 2.o também traz outra grande mudança. O HTTP 2.0 foi originalmente planejado para empurrar a tecnologia de criptografia chamado de TLS (Transport Layer Security, anteriormente chamado de SSL) no HTTP/2, mas isso foi rejeitado por causa de transtornos para certos operadores de redes e fornecedores de proxy por sobrecarrega-las com as novas normas.
No entanto, os desenvolvedores do Firefox e o Chrome disseram que não vao apoiar o HTTP/2, a menos que ele suporte criptografia. Por isso, Nottingham disse que sites que querem obter o beneficio de uma navegação mais rápido vão precisar usar TLS se quiserem interagir com os navegadores.
via The Hacker News
