No post de hoje compartilho com vocês um vídeo da Selenium conference 2014. Na apresentação, Dave Haeffner, um dos profissionais mais atuantes no trabalho com Selenium e autor do livro guia Selenium GuideBook, indica diversas fontes interessantes onde podemos encontrar materiais sobre automação com Selenium para testadores iniciantes, intermediários e avançados.
Vídeo da apresentação
Slides da apresentação
Ao meu ver existem dois pontos relativos a privacidade pessoal na web que devem ser levados em consideração:
O ponto 1 acima é algo que precisamos aprender a conviver e aprender com tempo. Mas o ponto 2, é algo inadmissível que precisa ser mudado e precisamos criar formas na web onde não fiquemos nas mãos desses “magnatas da informação”. Recentemente essa questão de espionagem atingiu a mídia do mundo inteiro com o caso Snowden. Recentes relatos mostram como essas “magnatas da informação” ajudam (e podem ajudar) o governo dos EUA a espionarem e bisbilhotarem a privacidade alheia. Microsoft (outlook e skype), Google (principalmente youtube e gmail), etc são somente alguns exemplos de “magnatas” que tem “nossas vidas” nas mãos deles.
E agora? O que fazer?
Minha previsão sobre isso tudo é que, a longo prazo, essas magnatas vão modificar a forma como implementam seus serviços para uma forma mais “descentralizada” da informação (aonde as empresas magnatas não terão poder e domínio sobre todas as informações). Mas isso é uma coisa difícil de acreditar e ainda mais difícil de checar se é realmente acontece o que as magnatas dizem que acontece.
Então a possibilidade mais tangível ao meu ver (uma vez que as pessoas amadureçam como usuários da internet) é que vamos gradativamente parar de utilizar serviços e sistemas dessas magnatas e migrar para soluções descentralizadas que serão mais seguras (apesar de não serem lá tão maduras ou bonitas como as soluções das magnatas). Esses serviços e soluções provavelmente usarão tecnologia P2P (peer-to-peer), ou algo mais avançado que ainda não conhecemos. Soluções aonde a informação seja descentralizada e seja de todos, regulamentada e protegida por todos, ao invés de somente por uma empresa “dona” dos dados. Soluções assim já são realidade hoje em dia, e um exemplo muito bom é o do BitCoin (leia aqui se você não conhece o bitcoin).
A outra possibilidade é comprar máquinas de escrever ao invés de usar computadores 🙂 A Rússia já está fazendo isso para produção de documentos confidenciais (veja aqui isso)
Temos que lembrar que a humanidade toda é um bebê no mundo da web, e precisamos começar a amadurecer, crescer, abrir os olhos e parar de engatinhar… Caso contrário, temos que continuar aceitando calados os pontos 1 e 2 que citei acima.
O BdB Recomenda de hoje apresenta um projeto muito interessante, chamado Codeacademy – Learn to Code. O projeto criado a partir das frustrantes experiências enfrentadas por Zach Sims e Ryan Bubinski. Cansados de vídeos e tutorias pouco eficientes, eles criaram o Codeacademy, como uma maneira extremamente interativa de aprender a programar, através da prática direta da programação.
Para começar o aprendizado basta se cadastrar no site (pode utilizar a própria conta do facebook) e começar a realizar os exercícios. Os exercícios são conduzidos de maneira gradual, apresentando os conceitos fundamentais para aprender a programar de maneira prática, além disso, o ambiente possui um fórum de ajuda bastante participativo e dicas para ajudar na resolução dos problemas.
O projeto é audacioso e deseja ensinar programação a pessoas de diferentes áreas de atuação. Segundo o próprio Zach “As pessoas têm um desejo genuíno de compreender o mundo que vivemos. Eles não querem apenas usar a Web; Eles querem entender como ela funciona.”
O custo para começar o aprendizado é ZERO. Atualmente estão disponíveis cursos de JavaScript e HTML.
E não esqueça de nos seguir no Twitter e juntar-se a nós no Facebook para ser informado das novas atualizações do blog!
Todos já enfrentamos diferentes problemas de performance ao acessar nossos serviços favoritos na web. Lentidão e até mesmo indisponibilidade por longos períodos são problemas que ainda afetam a maioria das aplicações web.
Desse modo, podemos apontar que a Performance é um requisito não-funcional CHAVE para as aplicações web. E menosprezá-la pode causar grandes consequências.
Podemos definir os testes de performance, como:
Através dos testes de performance podemos simular o ambiente de produção, que a aplicação será submetida e avaliar como a mesma irá se comportar.
Lembrando que….
…de forma, que através da correta execução dos testes de performance, em conjunto com um monitoramento eficiente, podemos submeter diversos pontos da aplicação aos níveis de carga esperados e avaliar o seu comportamento.
No contexto das aplicações web: “Se um usuário tem de esperar muito (para acesso, processamento do lado do servidor, para formatação ou exibição do lado do cliente), ele ou ela pode decidir ir para outro lugar.” (Pressman, 2005)
Logo, desprezar esse requisito não-funcional pode gerar perdas irrecuperáveis para um negócio.
Do ponto de vista conceitual, fala-se sempre em três tipos de teste:
Performance: Avalia se a aplicação em teste atinge os requisitos em relação a questões como: tempo de resposta, throughput e utilização sob um nível de carga esperado.
Carga: Submete a aplicação a diferentes níveis de carga, com o objetivo de identificar a capacidade máxima de operação, além de gargalos, memory leaks, etc…
Stress: Avalia a robustez, disponibilidade e confiabilidade da aplicação em condições extremas (cargas muito elevadas, escassez de recursos)
Os três são comumente confundidos, porém como descrito cada um tem sem objetivo específico e a correta utilização dos mesmos durante o desenvolvimento poderá proporcionar um nível completo de informações sobre o comportamento da aplicação.
Por fim, é importante enfatizarmos que: “Caso não sejam executados da maneira correta, os resultados são, na melhor das hipóteses, inúteis e, na pior das hipóteses, enganosos, fazendo com que uma empresa menospreze ou superestime a capacidade de sua aplicação.” (Savoia, 2000)
Logo, é fundamental que, desde o início do ciclo de vida da aplicação, o RNF relacionado a performance seja priorizado, para que todo um ambiente de testes seja preparado de maneira adequada para simular o ambiente de produção e desse modo auxiliar o desenvolvimento a atingir o nível de qualidade desejado.
Gostou do assunto testes de performance? Participe, deixando seu comentário no post.
Em breve, voltaremos ao assunto falando do Apache JMeter.
E não esqueça de nos seguir no Twitter e juntar-se a nós no Facebook para ser informado das novas atualizações do blog!
Esse post é “mais ou menos” uma tradução junto com algumas opiniões de um post de um blog bem legal chamado Coding Horror mantido por JeffAtwood. Para quem não conhece Jeff Atwood ele é o cara que criou o site Stack Overflow que você provavelmente já acessou. Decidi fazer essa “tradução” pois o tema do post é muito interessante e é importante estarmos ligados nesse tipo de coisa. O nome do post original é “Breaking the Web’s Cookie Jar” e aqui vai a versão portugês:
O plugin do firefox chamado Firesheep causou um “buruçu” (traduzindo: um reboliço, uma movimentação, um zum-zum-zum), e com motivo. Esse plugin funciona da seguinte forma:
Caramba! Esse cara que implementou o firesheep deve ser o cara né? Não exatamente. Na verdade o trabalho maior foi o de empacotar isso tudo e criar uma interface legal como plugin do firefox do que propriamente “hackear” a sessão de outro usuário em determinado site que ele esteja logado. Essa captura da sessão do outro usuário está longe de ser alguma forma de “hack” ou de “mágica”. Na verdade, o bom da audiência que o firesheep está tendo é que ele evidencia um problema fundamental de arquitetura da web, mais especificamente da questão de sessões salvas em cookies. A única forma de um site saber quem está acessando, é através de identificadores enviadas no cabeçalho das requisições HTTP a cada click que você faz em um link. Dentro do HTTP header existe a informação do cookie, que diz quem você é ao site que vocês está acessando. Para a sua surpresa essas informações do cookie trafegam em forma de text puro (plain text) sem criptografia. Isso significa que qualquer pessoa (que estiver na mesma rede que você ou em alguma posição e que consiga vizualizar os pacotes de rede) pode recuperar essas informação e imediatamente “incorporar você” em qualquer site que você esteja logado. Agora que você já sabe em partes como o cookie funciona, você já pode entender melhor o que o Firesheep faz:
Então tudo que o firesheep faz é “escutar” requisições HTTP e se aproveitar de informações do cookie presente nelas. E essa é a forma que a internet funciona desde 1994, quando o cookie foi inventado.
Então você deve estar se perguntando porque isso não era um problema antes? Porque a alguns anos atrás, vamos dizer 2003, esse problema não existia?
O HTTPS foi inventado em 1994, mesmo ano que o cookie, e isso não foi coincidência. Os próprios criadores do cookie, sabiam desde o início que eles precisariam de alguma forma de proteger os dados que trafegam do cookie. Então desde as eras mais primitivas ( como em 2003 😛 ) qualquer banco ou site que tenha autenticação, e que se preocupe um pouquinho nem pensava em usar HTTP puro.
O “buruçu” em torno do Firesheep é justificado pois na verdade O Pote de Cookies da Web sempre esteve aberto, e nós nunca fizemos nada. O que fazer então?
Você pode pensar estar pensando que quem precisa de mais segurança deveria trafegar suas informações de forma encriptada, como usando o HTTPS, mas essa não é uma solução muito adequada. Você teria que proteger todo seu tráfego de informação somente por conta de um pedaço do header (outro pedaço) de um HTTP request. Parece um canhão para matar uma formiga.
Embora não saibamos o que vai acontecer para “fechar” o pote de cookies pelo menos ficam algumas dicas que o firesheep nos trás:
A moral da história é que esses são direcionamentos muito genéricos, mas que já são um avanço quanto a educação das pessoas ao utilizarem redes wifi abertas. E quanto ao Firesheep, nós vimos que ele Não Abriu o Pote de Cookies da Web, o Pote já estava aberto! Espero que isso tudo sirva como motivação para criarmos uma saída melhor que cookies trafegando em HTTP puro!.
Bytes don't Bite! 