Despedida do Antonio

Esta foi a ultima semana do Antonio na globo.com. A despedida foi em grande estilo, com direito a galeria gourmet. Fica o exemplo e a saudade desse grande colega.

Em clima de festa com direito a montinho e tudo:


Fico feliz por ter surpreendido do Antonio nesses poucos meses que trabalhei com ele, agora os desafios são outros (aka Expurgo...)!

Toninho, boa sorte no Yahoo!

SQL Injection - A fina arte de criar paginas realmente inseguras

Este post diz tudo:


Por mais que existam alertas sobre os perigos de SQL Injection, muita gente resolve ignorar e criar sistemas cujas consultas ao banco de dados são feitas através de concatenações de strings com os dados oriundos do usuário.

Uma das primeiras coisas que aprendi quando trabalhava como testador foi tentar este código em telas de login:

' or '1' ='1

Imagine que o impacto dessa belezinha em uma query como esta:

"SELECT USUARIO FROM TABELA WHERE USUARIO = '" + usuario + "' AND SENHA = '" + senha + "'"

temos, então:

SELECT USUARIO FROM TABELA WHERE USUARIO = 'qqCoisa' AND SENHA = '' or '1' ='1'

Consegui efetuar o login devido a extrema preguiça do desenvolvedor que nunca se interessou em estudar um pouco de segurança, muito menos sabe o que é um prepared statement. Isso no melhor dos casos, posso querer inserir um DROP TABLE da vida facilmente, pois o sistema está, literalmente, de pernas abertas.

Recentemente um colega testou esse tipo de ataque contra um site de uma instituição por curiosidade. Ele conseguiu obter um arquivo contento a senha e o IP do banco de dados e conseguiu acessa-lo, perceberam o perigo?

Sinceramente? Se eu vejo um site que cai nesse truque eu não sinto pena. Não vou zoar ou fazer algo maléfico, as vezes até tento avisar, mas não sei se vale a pena: ou o sistema custou muito barato ou custou muito caro, foi produzido por uma consultoria que lucou 1980% em cima do salario do estágiario e que, por mais documentos que tenham produzido não conseguiram fazer algo básico: um site seguro contra hackers que estudam pela Wikipedia.

Se o seu site não pode receber aspas simples, duplas ou %, tenha MUITO medo, pois alguem VAI fazer algo em breve...

Closures em Java - Parte 2

Ainda sobre a Closures do java 7, agora será possivel fazer isso:

public class A {
        public static void main(String args[]) {
            @Shared int acumulador = 0;

            {int => int } xxx  = { int i =>  acumulador += i; i};

            System.out.println(xxx.invoke(1));
            System.out.println(xxx.invoke(2));
            System.out.println(xxx.invoke(3));
            System.out.println("o valor do acumulador eh " + acumulador );

        }
}

Só eu estou achando divertido?

http://gafter.blogspot.com/2008/08/java-closures-prototype-feature.html

Closures em Java

Olha o que vai ter no java 1.7

public class A {
        public static void main(String args[]) {
                exec( { int a, int b => a + b });
                exec( { int a, int b => a * b });
                exec( { int a, int b => 
                        System.out.println("closure " + a + ":" + b); 
                        (a * a) + (b * b) 
                });
        }
        public static void exec({ int, int => int } closure){
                System.out.println(closure.invoke(3,2));
        }
}

$ java -Xbootclasspath/p:./closures-2008-08-04/lib/closures.jar   A
5
6
closure 3:2
13

Divertido :)

Fonte:
http://guj.com.br/posts/list/99477.java

Parsing de XML na linguagem ABC

A maior parte das linguagens de progração em uso pelo mundo tem pelo menos 1024 bibliotecas para trabalhar com arquivos XML. Me espanta saber que muitos querem "gravar e ler" arquivos nesse formato mas não fazem ideia do que é um XML!

Eis um bom começo:
http://www.w3schools.com/xml/default.asp

Acho que nenhuma linguagem tem mais variações sobre o mesmo tema que Java: http://guj.com.br/artigos.jsp#87031

Testable & Untestable Code

Leitura recomendada:

http://misko.hevery.com/2008/07/24/how-to-write-3v1l-untestable-code/
http://www.testingreflections.com/node/view/7221

The Good, the Bad and the Ugly

Depois de ter visto algumas vezes "Era uma vez no Oeste" (com Charles Bronson tocando harmônica), finalmente pude conferir o clássico "Três Homens em Conflito" (The Good, the Bad and the Ugly) do mestre Sergio Leone.

Clint Eastwood, Eli Wallach e Lee Van Cleef estão perfeitos nessa história cheia de sangue, traições e a obcessão pela riqueza. As panorâmicas de Leone sobre o desertico velho oeste e a caracterização dos homens embrutecidos daquela época, onde a vida não valia mais do alguns dólares, são majestosas, com direito à mostrar parte da guerra civil americana.



Esqueçam aqueles filmes de indios e tiros falsos: são personagens densos, únicos, em um momento diferente da história, com momentos fantásticos (como a cena em que o "Feio" monta um revolver com as peças de outros). Sem falar no olhar mortal do "Olhos de Anjo" Lee Van Cleef, que passa uma frieza na espinha...

- "When you have to shoot, shoot. Don’t talk!"

Sem falar no maravilhoso tema de Ennio Morriconi, clássico absoluto. O estilo Western não é vazio como muitos pensam, basta saber apreciar.

Voltas às Aulas e o Java - parte 2

Existe o clássico problema de determinar se um aluno passou ou não de ano quando são informados as notas e o número de faltas.

Vejamos:
1) O número de faltas é acima do permitido?. Aqui entra um if dos bons com uma comparação numérica, quando um número é maior ou igual a outro.
2) A média é basicamente somar as X notas e dividir por X (se for média aritmética). Somar e dividir são operações matemáticas básicas.

Uma forma de fazer é:
if( numero_de_faltas > maximo_de_faltas_toleradas) {
// reprovado por faltas
} else if ( media_do_aluno < media_para_passar ){
// reprovado por nota
}
// se nem um nem outro, esta aprovado


O ruim dessa abordagem é que o aluno estar aprovado é uma condição "que sobra". Se passarmos a focar a aprovação do mesmo ficaria assim:

if( media_do_aluno >= media_para_passar && numero_de_faltas <= maximo_de_faltas_toleradas) {
// aprovado!
} else {
// reprovado!
}

É claro que eu posso que eu posso querer saber o motivo pelo qual o aluno foi reprovado:

if( media_do_aluno >= media_para_passar && numero_de_faltas <= maximo_de_faltas_toleradas) {
// aprovado!
} else if(numero_de_faltas > maximo_de_faltas_toleradas){
// reprovado pelo número de faltas: ignoro a média.
} else {
// aqui só sobra a reprovação por nota,
// basta fazer a tabela-verdade dessas expressões
}

Se o foco do professor for o algoritmo, isso é o que deveria ser analisado. Quem implementa corretamente um método que recebe X notas e um número de faltas e consegue responder a essas perguntas consegue descrever facilmente os casos de teste para verificar se a implementação corresponde ao que se espera.

Um programa que tenha algum tipo de interação (seja Swing ou console) ajuda a fazer um macarrão de código, mesclando o algoritmo com o controle de estado dos "menuzinhos". No fim vemos laços de repetição aonde não são necessários, calculo de média errado, etc.

Ok, não acho que um marinheiro de primeira viagem devesse começar por JUnit, mas uma com boa noção dos fundamentos da linguagem e evitando a interação desnecessária com o usuario (poderia ser usado até os parâmetros do main), acredito num melhor desempenho. O risco é o aluno acreditar que java é dificil ou que tudo se resume a getters/setters e gigantescos try/catch's onde as exceptions são varridas pra debaixo do tapete.

Eu colocaria TDD num segundo momento, mas ai sem perdão, ensinando o caboclo a fazer do jeito certo o quanto antes. O que é dificil se eles conseguem passar sem saber fazer aritmética básica.

Algumas pessoas PRECISAM fazer programas interativos

Este código:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv){
        int i;
        double total =0;

        for(i=1;i < argc;i++){
            total = total + atof(argv[i]);
        }

        printf("A soma dos %d parametros eh %f\n",(argc - 1),total);

        return 0;
}

É limpo, prático e scriptável. Não preciso fazer pergunta nenhuma nem tratar nada que o usuario informe: no maximo posso ver o número de parâmetros e reclamar. Basta saber como funciona o laço for e saber que argc é o número de parâmetros que eu passei para o programa e argv é um vetor de strings (que, em C puro, são vetores de chars) onde cada elemento é um parâmetro. O primeiro é sempre o nome do programa (a posição 0, que eu pulei).

$ gcc -Wall soma.c
$ ./a.out 1 2 3 4 5
A soma dos 5 parametros eh 15.000000

Eu compilo e pelo para que todos os warnings possiveis sejam mostrados. Novamente não tive nenhum problema e o código funciona bem. Nem um flush de stdin foi preciso. Se eu colocar uma palavra no meio, como abóbora, será ignorado.

Não é mais facil assim do que fazer milhões de menus? Nem precisa de system("pause") system("cls")!

Test Driven Development - parte 1.

Veja este código:

 public void testEhPar() throws Exception{
  assertTrue("2 deve ser par",algoritmo.ehPar(2));
  assertTrue("4 deve ser par",algoritmo.ehPar(4));
  assertTrue("6 deve ser par",algoritmo.ehPar(6));
  
  assertTrue("1 NAO deve ser par",!algoritmo.ehPar(1));
  assertTrue("3 NAO deve ser par",!algoritmo.ehPar(3));
  assertTrue("5 NAO deve ser par",!algoritmo.ehPar(5));  
 }

Dentro de uma classe de teste, usando o framework JUnit, a leitura dessas linhas é a seguinte:

Eu tenho um objeto chamado algortimo.
A chamada algoritmo.ehPar(2) deve retornar true, pois 2 é par, e este método informa se o parâmetro informado é, ou não, par.
O método assertTrue recebe dois parâmetros: uma mensagem informando o significado deste teste, e o resultado do mesmo.

Se o método estivesse com algum problema e retornasse false, isso:

assertTrue("2 deve ser par",algoritmo.ehPar(2));

seria o mesmo que

assertTrue("2 deve ser par",false);

Logo, o teste falha, pois 2 deve ser par.

Esta é uma forma programática de garantir o comportamento do código que eu desenvolvo: testando. Se o meu método só depende dos parâmetros informados, é muito simples verificar o seu funcionamento.

Desenvolvendo os testes antes de implementar o código, tendo apenas as assinaturas dos métodos (por isso recorri a uma interface aqui, lembra?), eu posso pensar nos comportamentos esperados e, então, vou desenvolvendo até que todos os testes estejam passando.

Não é nada fácil, funciona melhor quando o projeto que estás desenvolvendo está começando, porém os resultados são excelentes: veja o quanto de tempo estás economizando! Se tu pretendes determinar se um código teu está funcionando por programas que perguntam os valores, escrever

$ ant clean test

é muito mais rápido!

O problema surge quando queremos fazer algo complexo, pois a dificuldade de testar mostra problemas na arquitetura adotada, por exemplo. Quanto temos objetos que tem objetos, herança, polimorfismo, tecnicas mais avançadas podem ser usadas como usar Mocks de objetos (e prover os mecanismos para injetar estes Mocks).

No caso desse exemplo, esta é uma solução:

public boolean ehPar(int numero){
      return numero % 2 == 0;
}

Muitos alunos desconhecem as operações de divisão e módulo entre inteiros. O 1, inteiro, dividido por 2, inteiro, não é 0.5, (em java), e sim 0, pois este é o resultado da divisão inteira. O resto da divisão, simbolizado por %, retorna 1. Dessa forma, o resto da divisão de um numero par por 2 é 0, caso contrario é um número inteiro. São operações básicas que precisam ser dominadas. Repare que eu fiz um código que funcione, não tentei nada mais maquiavélico que dê 0.0001 milissegundos mais rápido. Evite a otimização precoce.

Programar profissionalmente é uma tarefa de muita responsabilidade. Desenvolver testes para garantir a qualidade provê excelentes resultados a longo prazo.