10 coisas que todo o programador deveria saber

Listas de x coisas só servem para lembrar de tudo o que ficou de fora, portanto, IMHO, as 10 coisas que todo o programador deveria saber são:

0 – usar o google
1 – fazer um hello world em pelo menos 5 linguagens de programação diferentes (sendo uma funcional e uma script)
2 – instalar o wordpress e tudo o que é necessario para que o mesmo execute.
3 – instalar e configurar o Ubuntu, ou outro *nix, incluindo configuração de rede e impressão
4 – entender o que é CLASSPATH
5 – saber a diferença entre HTTP e FTP, entre TCP e UDP e qual camada OSI eles atuam. bonus: saber como funciona um GET ou POST (é possivel ver usando o live http headers do firefox).
6 – conhecer o comando grep e algumas opções como -c, -v, -A
7 – SQL: entender o que é select,update,insert, delete, commit, rollback
8 – como ler e gerar XML
9 – entender o que é NULL, \0, **qqcoisa do C e quais os seus usos (principalmente em strings)
10 – a diferença entre licença BSD e GPL veja aqui.

Alem disso é bom seguir alguns blogs, frequentar foruns, listas de discussão e ler muito. Mesmo um texto “chato” como A Catedral e o Bazar traz informações relevantes e outras referencias.

Boa sorte e que começe a flame-war :)

Rating 3.80 out of 5
[?]

JMock – trabalhando com mock objets em java

Lendo sobre testes unitarios, imagine o caso onde o seu teste é complexo: um objeto que chama outro e, então, realiza as suas tarefas. Um bom caso é um DAO que acessa o banco de dados para fazer alguma coisa: se vc pensa em testar esse codigo de forma unitaria teria que subir um banco de testes e, se encontrasse um problema, poderia ser dificil dizer se é problema do DAO ou dos objetos que ele depende (como a conexão com o banco, ou o banco em si).

A solução para estes casos pode ser trabalhar com mocks: objetos “burros” que podem não ter nenhuma função alem de responder ao que vc especificou. A abordagem mais utilizada é vc programar estes objetos para responder a um ou mais metodos com argumentos especificos, assim como as respostas esperadas. No caso do DAO eu posso esperar um determinado SQL e especificar uma determinada resposta, tudo de acordo com o meu cenario de teste.

É claro que Mock Objects em excesso podem atrapalhar, mas é tudo uma questão de bom senso: costumo dizer para quem esta começando a focar os testes nas partes mais importantes do sistema, o core do modelo e regras de negocio e, então, incrementar estas praticas caso veja necessidade. Sem falar que volta e meia surge algo novo.

Para java existe o excelente framework JMock. Logo de cara o site oficial traz um exemplo de como utilizar um mock bem simples (incluindo a integração do mesmo com JUnit 4)

http://www.jmock.org/getting-started.html

Para entender, imagine esta interface

interface Subscriber {
    void receive(String message);
}

Imagine que eu tenho um objeto do tipo Publisher que, ao invocar o metodo publish(message), ele envie esta mensagem para um Subscriber (que recebe com o metodo acima). Para testar o publish eu teria que me certificar que o metodo receive deste objeto Subscriber foi invocado com a mensagem especificada, mais ou menos assim:

import org.jmock.integration.junit4.JMock;
import org.jmock.integration.junit4.JUnit4Mockery;
import org.jmock.Expectations;
 
@RunWith(JMock.class)
class PublisherTest {
    Mockery context = new JUnit4Mockery();
 
    @Test
    public void oneSubscriberReceivesAMessage() {
        // set up
        final Subscriber subscriber = context.mock(Subscriber.class);
 
        Publisher publisher = new Publisher(); // objeto que vou testar
        publisher.add(subscriber); // tenho que adicionar o mock!
 
        final String message = "message";
 
        // aqui eu programo o que eu espero do teste
        context.checking(new Expectations() {{
            oneOf (subscriber).receive(message);
        }});
 
        // aqui eu executo!
        publisher.publish(message);
    }
}

Facil?

Rating 4.00 out of 5
[?]

XStream – Simplicidade ao lidar com XML em Java

Quem nunca passou por isso: ter que gerar e/ou ler arquivos xml e teve que escolher dentre diversas tecnologias e frameworks diferentes. Seja carregar tudo pra memoria ou ler aos poucos, se é um parser push ou pull, etc, é possivel dizer que para cada situação existe uma boa escolha.

Se o seu caso é trabalhar com arquivos cujos elementos podem ser mapeados em objetos java, uma boa escolha é o XStream

XStream xstream = new XStream(new DomDriver());
Person pac = new Person("Tiago", "Pac Man");
String xml = xstream.toXML(pac);
 
/* Simples. É, para fazer o contrario, basta */
 
Person newPac = (Person)xstream.fromXML(xml);

Este e outros exemplos podem ser conferidos aqui:
http://xstream.codehaus.org/tutorial.html

É claro que o xml gerado assim, cru, nem sempre serve. Para isso vamos usar algumas linhas a mais para trabalhar com os recursos de alias, annotations e os Converters.

xtream.alias("pessoa",Person.class);

Dessa forma, para se livrar do nome.do.pacode.Person e trabalhar com algo mais expressivo como pessoa, basta adicionar este alias antes de converter de/para xml. Para trabalhar com aliasing de atributos (e coleções implicitas) o ponto de partida é este:

http://xstream.codehaus.org/alias-tutorial.html

É possivel trabalhar com annotations no seu modelo de classes, evitando toda essa configuração manual

http://xstream.codehaus.org/annotations-tutorial.html

Para trabalhar com o maximo de flexibilidade do XStream, entretanto, vc precisa trabalhar com Converters – Veja o exemplo da classe Birthday

http://xstream.codehaus.org/converter-tutorial.html

XStream trabalha muito bem com classes imutaveis, pois não recria os objetos usando o construtor e sim de maneira semelhante ao mecanismo de serialização de objetos, fazendo um bypass do construtor. Sem falar que traz um pensamento menos voltado a “tags” e mais OO.

Rating 2.00 out of 5
[?]