Entre outras apresentações, fiz uma intitulada “Writing Scalable Software in Java – from multi-core to grid-computing”.

A agenda e descrição do evento podem ser encontrados no site oficial. O PT.JUG terá uma track na parte da tarde com apresentações do Samuel Santos, Hugo Pinto e outra minha.

Dado que o evento terá lugar em Braga, está a ser organizada uma excursão para quem venha do Sul. Para quem quiser participar, junte-se à conversa na mailing list do PT.JUG.

Inscrições e agenda na página do evento na Sun Portugal.

Agenda

No entanto, também são necessários os conceitos base. Fora o ensino superior e certificações, livros são um recurso essencial que me parecem que hoje em dia muita gente despreza. E estou a falar daqueles em papel, não dos pdfs que se sacam da net.

Foi com esta ideia que decidi juntar uma lista de 10 livros que considero essenciais para um programador Java – i.e. que contêm a matéria mínima que gostava de ver nos membros das minhas equipas de desenvolvimento. Alguns destes podem ser substituídos por outros porque trata-se de escolhas pessoais, mas os temas e áreas abrangidos penso serem extensivos. De referir também que se trata de uma lista de livros técnicos, não se focando no desenvolvimento das chamadas “soft skills”. Fica a lista.

1 – The Java Programming Language

Escrito pelos criadores da linguagem, serve tanto como livro de introdução à linguagem como também de excelente referência para manter por perto.

Cobre desde as áreas básicas da linguagem até I/O, threading e acima de tudo as collections, para as quais é muito útil como referência.

2 – Effective Java

Escrito pelo Joshua Bloch, Effective Java é provavelmente o melhor livro sobre Java que já li.

Está organizado em 78 itens e cada um é uma boa prática, por exemplo, “Preferir composição no lugar de herança”, “Evitar Finalizers” ou “Preferir anotações a padrões de nomenclaturas”. Em cada um destes pontos, o autor discute os diversos ângulos da questão aprofundadamente e com justificações que demonstram um conhecimento extremo da plataforma.

Adicionalmente, o estilo de escrita é facílimo de ler. Eu demorei 2 noites a ler o livro todo.

3 – Java Concurrency in Practice

“Concorrência é difícil”, é uma das mensagens principais deste livro. O autor do livro, Brian Goetz, parte deste princípio para demonstrar ao longo do livro como evitar as principais falhas quando se desenvolve software concorrente em Java. Os bons e maus exemplos são demonstrados facilmente com snipplets de código com smileys negativos e positivos, o que ajuda a memorizar os padrões.

Além de explicar os principais problemas de concorrência – live locks, dead locks, race conditions, etc. – são explicadas detalhadamente as novas estruturas de dados para suporte a concorrência introduzidas no Java 5 e 6. Depois de ler este livro encontro-me a usar estas estruturas mais e mais vezes, e também a construir em cima delas conforme vou compreendendo como funcionam internamente.

4 – Concrete Mathematics: A Foundation for Computer Science

Sim, coloquei aqui um livro de matemática!

Todos estudamos matemática mas por vezes a dificuldade reside em encontrar aplicações para o que aprendemos. Este livro ensina conceitos matemáticos que são facilmente mapeados para problemas informáticos com os quais no encontramos no dia-a-dia. Também são conceitos que nos ajudam a perceber melhor os diferentes algoritmos.

5 – The Algorithm Design Manual

Este não foi o primeiro livro de algoritmos que comprei nem é considerado o “standard”. O primeiro que comprei e que sinceramente nunca consegui ler todo foi o Introduction to Algorithms. Além de espesso, segue uma aproximação extremamente académica e formal.

Por outro lado, este The Algorithm Design Manual é bastante acessível e completo. Os exemplos não estão escritos em Java mas vale pela quantidade e pela forma como são explanados os algoritmos. Cobre a maioria das áreas esperadas num livro para iniciantes/intermediários: estruturas de dados, algoritmos de pesquisa, grafos, programação dinâmica, combinatória, geometria, conjuntos e outras áreas.

6 – Algorithms in Java

Decidi incluir um outro livro de algorimos, desta vez em Java. Escrito pelo Robert Sedgewick que já tinha escrito a mesma versão do livro para C++ no início dos anos 90, o livro serve de excelente fonte de referência para se ter no local de trabalho e consultar rapidamente quando necessário.

O livro está dividido em 5 partes, separadas ao longo de 2 volumes – Fundamentos, Estruturas de Dados, Ordenação e Pesquisa no primeiro volume; e Grafos no segundo volume.

7 – Design Patterns: Elements of Reusable Object-Oriented Software

Conhecimento sobre design patterns – especificamente GoF neste caso, mas também hoje em dia padrões de arquitectura ou mesmo os Core J2EE patterns da Sun – é essencial para o profissional que trabalhe em linguagens orientadas a objectos. Isto pode ser provado tipicamente na entrevista de emprego, já que no mínimo uma perguntinha de padrões é sempre feita (dica: se vos perguntarem para referirem um padrão de desenho que conheçam, NÃO respondam Singleton!).

8 – The Pragmatic Programmer: from Journeyman to Master

Tal como o já referido Effective Java está para o Java, este livros está para a profissão de desenvolvimento de software. Os autores tentam cobrir as áreas que apenas se aprendem com a experiência profissional como um conjunto de boas práticas a seguir.

Tanto para profissionais com pouca experiência – que vão aprender algumas boas dicas – como para profissionais com extensiva experiência – que vão rever no livro muita coisa pela qual passaram mas agora organizada e esquematizada -, este livro prova-se uma leitura útil e bastante agradável.

9 – Refactoring: Improving the Design of Existing Code

Refactoring, refactoring, refactoring!

Actualmente a grande maioria dos profissionais sabe o que é refactoring – mesmo que não o pratiquem assim tanto – mas é extremamente estranho como um conceito tão simples não tinha sido esquematizado correctamente antes deste livro.

Pode-se pensar que não é necessário ler um livro sobre refactoring, pois na prática temos IDEs que nos ajudam a fazer grande parte do trabalho mas quando se olha para o projecto numa perspectiva macro, o refactoring não é assim tão simples. Este livro ajuda a reprogramar a nossa cabeça para estar constantemente em modo refactoring.

10 – Agile Software Development, Principles, Patterns, and Practices

Embora o título o possa fazer entender, este livro não é exclusivamente sobre metodologias ágeis. A verdade é que conjuga a enumeração de múltiplas metodologias ágeis com princípios de desenvolvimento de software como orientação a objectos e UML.

Ao contrário de outros livros sobre metodologias ágeis, o autor – que é um dos signatários iniciais do Agile Manifesto – não tenta puxar por nenhuma metodologia, embora fale mais de eXtreme Programming – TDD, refactoring, pair programming. É esta perspectiva integrada de agile + tecnologia que torna este livro num recurso essencial.

11 – Bónus – livro de Python/Ruby/Haskell/Scala/Groovy/Clojure ou outra linguagem

Esta lista é focada em Java e exactamente por causa disso, aconselho a se aprender pelo menos uma outra linguagem, esteja esta disponível para a JVM ou não.

Aprender linguagens novas faz-nos melhores programadores e especialmente agora com o renascimento de linguagens funcionais, também pode vir a ser uma vantagem profissional.

Certamente esqueci-me de outros livros importantes mas estes são daqueles que considero poderem contribuir muito para a qualidade que um profissional pode vir a atingir. Aceito recomendações para outros livros.

Variância neste contexto está directamente relacionada com herança. É relevante para compreender como é feito matching de parametros de métodos, resultados de retorno, tipos genéricos e outros casos.

Existem três tipos de variância: invariância, covariância e contravariância.

• Covariância

Suponhamos o seguinte caso:

public class X {
    Object getValue() { return null; }
}

public class Y extends X {
    String getValue() { return null; }
}

A covariância neste caso está no tipo de retorno. Significa que se a classe Y é mais específica que X (Y< X) então qualquer método de Y que faça override a um método de X tem de retornar um tipo igual ou mais específico. Neste caso, o tipo de retorno do método que faz override é String, que é mais específico que Object.
Diz-se, pois, que os tipos de retornos em Java são covariantes (desde a versão 1.5).

• Covariância

Contravariância é efectivamente o inverso de covariância. Significa que se a classe Y é mais específica que X (Y<X) então qualquer método de Y que faça override a um método de X tem de retornar um tipo igual ou mais genérico.

Em Java não há contravariância e overriding de métodos é sempre invariante … que passo a explicar de seguida. É no entanto possível ter contravariância usando wildcards de generics.

• Invariância

Em Java overriding de métodos é invariante, ou seja, para se redefinir um método numa subclasse, os parâmetros têm de ser exactamente do mesmo tipo do seu ancestror.

Este comportamento é muitas vezes descurado, veja-se o seguinte exemplo:

public class A {
    boolean equals(A object) {
        //Fantastico, sempre igual
        return true;
    }
}

Como o overriding é invariante, não estamos na realidade a fazer override do método boolean equals(Object o) mas sim overload, adicionando um novo método com outra assinatura. O pior é que passa completamente despercebido.

A solução desde Java 5 é adicionar a anotação @Override que vai permitir que o compilador detecte estes casos e informe que não estamos realmente a redifinir um método. Aliás, todos os IDEs decentes sugerem que se adicione esta anotação.

Uma nota sobre Generics

As noções de covariância e contravariância são importantes de ter presente quando definindo classes tipificadas com generics, especialmente quando se usam as wildcards para explicitamente definir relações entre tipos. Não estamos a definir realmente relações hierárquicas entre tipos, pois não há a relação de herança entre classes genéricas mas estamos a definir relações entre os tipos que parametrizam essa classe, se me consigo fazer entender.

Por exemplo:

public class Teste {
    void pseudoCovariante(List<? extends A> param) {}

    void pseudoContravariante(List<? super A> param) {}
}

Aqui definimos dois métodos para dar exemplos de como dotar classes tipificadas de noções de contravariância e covariância, já que se não usarmos wildcards temos parametros invariantes.

Espero ter conseguido explicar os conceitos básicos. Estas noções aparecem em diversos textos sobre linguagens de programação e é essencial compreender estas noções para se entender bem o sistema de tipos da linguagem Java.

Explanations of Common Java Exceptions

Aqui ficam os slides da apresentação.

Data: 29 Janeiro 2009
Hora: 18h30 – 21h00
Local: Hotel Radisson SAS, Campo Grande

Apresentações:

• “Maven e companhia – gestão de builds e dependências” – Ruben Badaró (moi, moi)
• “Sistemas de Controlo de Versões Distribuídos e Integração com ferramentas Java” – Miguel Duarte

O encontro será seguido de uma jantarada de convívio e de conversa informal na área.

A sala e coffee break são patrocinados pela Truewind, que foi sensível à nossa necessidade de patrocínio e nos ajudou com pouco tempo de planeamento.

Os lugares disponíveis serão limitados por isso é aconselhado que se registem o quanto antes.

(…) o nome dado para um tipo de diagrama (…) voltado para a gestão de informações, de conhecimento e de capital intelectual; para a compreensão e solução de problemas; na memorização e aprendizado; na criação de manuais, livros e palestras; como ferramenta de brainstorming (tempestade cerebral); e no auxílio da gestão estratégica de uma empresa ou negócio.

Um mindmap é na realidade uma forma bastante simples de organizar ideias. Na prática, é para mim mais simples usar estes diagramas do que os rabiscos que antes escrevia em papel, que consistiam de pontos, subpontos e mais subpontos.
A diferença é que com o mindmap há um agrupamento visual de ideias no lugar da organização sequencial numa lista de pontos.

Eu utilizo mindmaps para diversas tarefas:

• Escrever documentos

Esta minha necessidade intensificou-se porque, em primeiro lugar, passei escrever mais documentos e, em segundo lugar, passei a escrever exclusivamente em inglês visto encontrar-me a trabalhar na Irlanda. Embora esteja confortável a escrever na língua, organizar ideias e escrever numa língua estrangeira torna-se mais complicado.
Quando escrevo os documentos, os meus mindmaps são normalmente o mais completos possivel, não apenas um índice organizado. O trabalho depois do mindmap é tipicamente juntas as peças.

• Decisões

Quando trabalhamos, mesmo fora da engenharia de software, temos de pesar pros e contras e tomar decisões. Um mindmap é fenomenal para este efeito. Normalmente marco pros com uma seta verde e contras com uma cruz vermelha, obtendo assim uma noção visual das minhas opção apenas pelas cores. E este é apenas um dos exemplo de propriedades que se podem alterar em nós que ajudam no processo

• Anotações de reuniões

Por vezes durante uma reunião necessitamos de tirar notas: coisas a fazer, o que disse uma pessoa, o que ficou de fazer outra, etc. É uma boa ideia ter um portatil com um mindmap no lugar de um caderno pois é possivel anotar em tempo real, graças a bom software.

Para fazer tudo isto utilizo o FreeMind. É feito em java e como tal posso usá-lo tanto em Windows no trabalho como no Mac em casa. Verdade seja dita, nunca utilizei nenhum outro programa de mindmaps, fiquei contente logo com este.
Para completar, o programa é bastante simples de utilizar. Apenas com o teclado conseguimos criar um mindmap muito rápido: setas para mover entre nós, tab cria novo filho, Enter cria no mesmo nível, F2 edita nó. Apenas com isto, estamos a fazer um mindmap muito rápido.

A quem nunca experimentou, aconselho vivamente.

Um mindmap deste próprio artigo

De entre todas as apresentações, destaco uma que foi focada em java, nomeadamente em como ter alto desempenho. A apresentação foi feita pelo Miguel Duarte, que também fez uma outra sessão no 2º encontro do PT.JUG à uns meses atrás. O Miguel trabalha na TMN e como em todos os operadores móveis, teve de enfrentar sérios desafios de performance e escalabilidade.

Deixo a apresentação. Posteriormente aparecerá o vídeo, que sei que o Miguel não vai gostar que meta aqui

A saída provável de que se fala é de uma venda, sendo que os principais nomes falados são os concorrentes HP, IBM, DELL e ainda a Oracle, que gosta de comprar tudo só porque pode. De entre entes uma compra por parte da Oracle poderia ser a mais problemática, não só por uma razão de cultura de empresa como alguns conflitos de interesses – não esquecer que a MySql é parte da Sun.

A questão que interessa pensar aqui é, o que acontecerá à tecnologia Java.

Uma enorme quantidade de profissionais e empresas têm uma aposta forte na tecnologia e sendo a mesma open-source, existirá de certeza gente para garantir que a plataforma continua a evoluir. Aliás, a decisão de abrir o código da plataforma Java foi das poucas decisões 100% acertadas da Sun pois permite um grau de confiança a todos os players que não teríamos se fosse uma tecnologia proprietária – estaria agora toda gente a pensar no que pode acontecer.

Eu na realidade até penso que um enfraquecimento da Sun até pode ajudar a evolução da plataforma.
Em primeiro lugar, seria de valor uma reestruturação do JCP para agilizar e coordenar melhor o processo de evolução da linguagem que deixa muito a desejar agora. Em segundo lugar, penso que haveria muito menos conservadorismo nessas mesmas evoluções, e teríamos melhores condições de competir com plataformas que evoluem mais rápido como seja o .Net.

Em resumo, sim, a Sun está na merda, mas o Java vai continuar saudável. Ainda melhor do que está actualmente, espero eu.