Muito obrigado pelos comentários! Valeu.
Muitos me perguntaram sobre livros, se vale à pena ou não, em fim. Vou tentar dar uma resposta coletiva no geral.
Livros e materiais
Apesar de que essa certificação exige mais da parte prática do que da parte teórica, ter um livro, ajudaria a “pegar” as principais idéias para iniciar o desenvolvimento. Há dois livros específicos para está certificação (parte 1/projeto): 1) Andrew Monkhouse (2005) e, 2) Terry Camerlengo,at al (2002)
O primeiro, é o mais indicado, pois está sintonizada com a última versão da SCJD e o Java 5. De novo, o livro apenas ajuda no “start up”, mas não que seja indispensável. Portanto, caso a pessoa não consiga o livro, apenas com os materiais e informações disponíveis, qualquer um consegue desenvolver o sistema. O ponto de inicio é: SCJD Reading Material e SCJD Faq
Parte 2 (prova escrita)
Na parte 2, são feitas apenas 4 perguntas (aleatórias) sobre o seu sistema. São perguntas compostas por varias sub-perguntas e, tudo tem que ser escrito. Tipo: “você usou RMI ou Sockets, quais vantagens, desvantagens de cada um”? Em fim…Quem realmente fez o projeto, não terá dificuldade de responder sobre o mesmo.
O que se aprende?
Primeiro, aprende a projetar um sistema considerando todas as variáveis propostas na especificação. A especificação deixa vários pontos em aberto, os quais lhe obriga a tomar decisões de projeto. Tipo: faço isso ou aquilo? Faço assim ou assado? Isso para mim, já é um diferencial desta certificação para com a SCJP. Como todos sabem, desenvolver, é acima de tudo uma atividade de criatividade e decisão. Como foi dito no tópico citado acima, conhecer a linguagem (SCJP) é uma coisa; saber usar a linguagem na prática é outra (SCJD).
Segundo, aprende a fazer somente aquilo que foi solicitado, na integra pelo cliente. A especificação é o roteiro geral do que deve ser feito. O cliente é o avaliador da Sun. Desse modo, o desenvolvedor aprende a pensar no cliente e a interpretar o que o cliente quer e espera de fato. Isso está no dia a dia de qualquer desenvolvedor.
Terceiro, além das questões de projeto (design) citado, você aprende a desenvolver de forma que seu sistema seja flexível para mudanças, o que, invariavelmente, acontece todos os dias. Por exemplo, na minha especificação, diz que meu sistema é para desktop, mas que, o cliente, considera a possibilidade de migra-lo para Web, sem muito impacto significativo, futuramente. Ou seja, tirar uma View e botar outra e, tudo deve continuar funcionando.
Quarto, você aprende a documentar seu sistema. A documentação envolve 3 pontos: 1) documentação do código (API completa). Neste ponto é dito que, deve-se comentar obrigatoriamente todos os métodos de Interfaces públicas e quaisquer códigos “estranhos”. É encorajado ainda, a fazer comentários somente quando realmente necessário, o que lhe obriga a pensar em nomes de classes e métodos que, se auto-documentam; 2) Documentação do usuário (manual de uso). Esse documento deve ser capaz de “pegar” na mão do usuário e faze-lo usar o sistema completamente. e; 3) Documentação de requisitos físicos (JDK, SO, etc), ou seja, o que é necessário para rodar o sistema.
Quinto, você aprende a pensar nos requisitos funcionais e não funcionais do sistema. Ou seja, você aprende a fazer perguntas como: Quais funcionalidades meu sistema deve ter? Quais recursos e habilidades? Quais confiabilidades (falhas, recuperação, concorrência, exatidão) devem ser garantidas? Quais requisitos de implementação (linguagem, padrões, API, BD etc) devem ser considerados? Quais requisitos de suportabilidade (teste, manutenibilidade, configuração, instalação, serviços) devem ser garantidos? Quais requisitos de desempenho (cache, velocidade, disponibilidade, eficiência, tempo de resposta e recuperação) devem ser garantidos e/ou considerados? Quais requisitos de usabilidade (ajuda on-line, contextual, dicas, documentação do usuário, estética) devem ser garantidos?
Sexto, você aprende a ter iniciativa e “conversar” com o cliente. Isso acontece em 4 momentos distintos: 1) A partir do momento que você está com o voucher na mão, você tem que entrar em contato (por e-mail) com o cliente (Sun), e pedir para baixar o projeto. 2) quando desenvolvendo, se necessário, você pode tirar dúvidas (por e-mail), se estas realmente fazerem sentido. Este ponto é desencorajado na própria especificação, mas há a possibilidade. Não precisei disso, pois os próprios fóruns já resolvem as dúvidas. 3) Para submeter o projeto, novamente, você tem que pedir para fazer isso. 4) Você tem marcar a prova escrita e, em um centro autorizado, novamente, responder perguntas do seu cliente sobre o projeto.
Sétimo, você aprende a confiar e defender seu trabalho. Isso acontece em dois momentos distintos: 1) ao fazer a prova escrita, como dito anteriormente e; 2) ao escrever o conteúdo do arquivo “choices.txt”, onde você deve escrever em detalhes, todas as importantes escolhas de design e códigos que você decidiu implementar. Por exemplo, no meu projeto, eu decidi validar completamente o schema do BD, uma vez que, o usuário pode escolher qualquer arquivo de BD, em qualquer lugar do SO. Isso me fez implementar uma Interface para esse fim, já considerando futuras mudanças no BD, caso o sistema fosse migrado para Web. Expliquei em detalhes essa abordagem no arquivo citado. E, para caso restasse alguma dúvida na explicação (Inglês ainda em evolução :D) , criei um diagrama UML (visto via API), onde ilustrava todos os pontos de design defendidos no arquivo supra citado.
Tempo e riscos
Normalmente, a pessoa leva de 2 a 3 meses trabalhando no projeto ou seja, mais ou menos 150 horas de trabalho (considerando uma atuação constante de 2 a 3 horas diárias). Isso porque, é muitos detalhes para ser feito por uma única pessoa, considerando que a mesma, aprecia fazer as coisas bem feitas. Não é fácil. Exige uma dedicação e atenção profunda da pessoa. Isso fica claro na especificação quando diz:
Então há a possibilidade falhar? Sim. Veja um caso recente e explícito, aqui. Mas casos de falhas são raríssimos, pois ninguém quer torrar dinheiro… :lol:
Custos ($$)
Talvez esse seja um ponto a pensar. Muitos se perguntam: será que vale a pena torrar 2 vouchers para essa certificação? Antes de fazer essa pergunta, deve-se pensar primeiro se vale à pena você provar que sabe desenvolver um sistema, considerando os pontos apresentados anteriormente. Se você tem uma “bagagem” que dispensa comentários, talvez não vale a pena. E, se falhar no projeto significa que o custo da mesma aumentará substancialmente, uma vez que precisará de um outro voucher para re-submeter o projeto. Desse modo, ao decidir encarar o projeto, deve-se entrar decidido a fazer a coisa bem feito, para não ter “surpresas”… :lol:
Finalmente, vale a pena?
No meu ponto de vista, vale e valeu. Só o fato de a pessoa ter que viver todos os pontos elencados nos itens anteriores, já vale mais que qualquer certificado. Pergunto: onde se aprende isso em uma certificação como SCJP e/ou SCWCD? Nunca! Creio (IMHO) que, essa certificação, teria que ser requisito obrigatório, para quem está começando, principalmente se a pessoa chega em uma empresa, apenas com a SCJP debaixo do braço, querendo ser programador/desenvolvedor de software sério, sem uma “bagagem” consistente anterior.
É isso ai!