Templetes no NetBeans IDE

Quem programa em vários projetos sabe que muitos dos arquivos fontes são semelhantes. O NetBeans IDE fornece uma facilidade, não muito utilizada, que é a criação de templetes (modelos).

Existem duas formas diferentes de criar um modelo: salvar um arquivo fonte como um modelo ou criar um novo modelo.

Salvar um arquivo fonte como modelo: essa opção é adequada se o arquivo em questão contém algo que você precisa utilizar em todos os projetos, como por exemplo, a configuração de algum framework. Para salvar um arquivo como um modelo, basta seguir os seguintes passos:

1. Clique com o botão direito no arquivo que você deseja que se torne um modelo;
2. Escolha a opção Save as templete;
3. Defina qual a categoria que o modelo mais se encaixa.

Criar um modelo novo: 

1. No menu tools escolha ao opção templete;

2. Escolhe a categoria mais adequada;

3. Escolhe entre ADD ou Duplicate.

Já que estamos falando de templates vamos a mais uma dica. Sempre edite o template User na categoria de propriedade do usuário. O meu fica sempre com o seguinte texto:

user=Evandro Rosa Santos <email associado ao projeto que estou trabalhando>

Introdução ao Extreme Programming

A programação de software teve seu início há aproximadamente meio século atrás, e por muito tempo vem sendo realizada de forma desorganizada, sem estrutura ou planejamento, acarretando em softwares de baixa qualidade, entregas fora do prazo e, principalmente, a insatisfação do cliente e o desperdício de tempo e trabalho dos desenvolvedores. Durante a década de 70, todos esses fatores se acentuaram devido ao crescimento na complexidade dos softwares, criando um momento de insatisfação geral que ficou conhecido como a Crise do Software.

Para tentar resolver essa crise, o processo de desenvolvimento e as metodologias mantiveram os princípios mais básicos da Engenharia: a análise, o projeto, a construção – que no caso recebeu o nome específico de desenvolvimento –, a verificação de erros e a gerência de fatores técnicos, recursos, prazos e custos (esse processo, hoje, é conhecido como processo tradicional de desenvolvimento).

Inferiu-se, então, que se todas as regras do processo tradicional de desenvolvimento fossem seguidas a crise estaria resolvida. Não foi bem o que aconteceu.

O processo de desenvolvimento tradicional não foi especialmente desenhado para suportar mudanças nos requisitos do projeto de software. Porem, as mudanças de requisitos ocorriam com frequência obrigando a modificar e alterar a documentação do projeto. Com isso, a confiabilidade dos softwares e, principalmente, as previsões de prazos e custos quase nunca são cumpridas. Isso criava mais custos para as empresas de desenvolvimento e insatisfação de seus clientes e permitia que algumas características da época da crise continuassem.

Observando esses fatores contra, surgiram, em contra partida, as metodologias ágeis. Estas não trazem novos pressupostos, mas focam em novos aspectos da programação. As metodologias ágeis promoveram o surgimento do movimento Agile Alliance, para aumentar a adesão dos desenvolvedores às práticas desta. E, por sua vez, criou o Manifesto Ágil, que se propôs a dar mais prioridade ao aspecto humano, excluindo a excessiva necessidade de documentar todos os passos de um desenvolvimento de software, possibilitando uma intensa manipulação dos códigos que já estavam em funcionamento, entre outras.

Assim, alem da grande capacidade de acompanhar e adaptar-se às mudanças dos requisitos do sistema. As metodologias ágeis têm seu foco voltado para o código das aplicações e ao feedback rápido ao cliente e dão importância secundária aos contratos, ao planejamento e à documentação. Possuem as seguintes fases: a definição (momento em que se procura definir as funcionalidades, restrições, validações, interfaces e os requisitos necessários), o desenvolvimento (define-se como os dados serão estruturados e como as funções serão implementadas) e a manutenção (análise do projeto e suas modificações).

O mais conhecido processo ágil é o Extreme Programming (XP), que surgiu em 1996, possibilitando que a abordagem dos projetos pudesse ser realizada de uma maneira simples, direta e eficiente. Assim, ele tem como objetivo principal a redução dos processos burocráticos das metodologias tradicionais e a promoção de mais produtividade com menos custos. Ele atinge esses objetivos através do seu foco em equipes pequenas e nos seus quatro elementos fundamentais: comunicação, simplicidade, feedback e coragem.

A comunicação, no XP, procura manter um bom relacionamento entre os clientes e os desenvolvedores, pois como não há tanta preocupação com a documentação, torna-se necessário que todos os envolvidos tenham conhecimentos atualizados sobre o que está ocorrendo durante o desenvolvimento.

A simplicidade demonstra a tendência em utilizar códigos mais simples que não possuam funções desnecessárias e que eles sejam constituídos apenas por funcionalidades que sejam utilizadas no momento, pois implementações futuras são cabíveis numa posterior manutenção.

O feedback constante pode ser relacionado ao desenvolvedor e ao cliente. Ao primeiro, ele consiste nas informações obtidas pelos desenvolvedores através dos testes sobre os erros que podem surgir no projeto. Para os clientes, são as avaliações feitas por estes para que identifiquem erros ou não conformidades do projeto e, assim, possam fazer as modificações necessárias a tempo e de acordo com as necessidades do cliente.

Por último, a coragem é tida como a flexibilidade de práticas que o desenvolvedor pode ter para indicar problemas no sistema, informar ao cliente a viabilidade do projeto, a simplificação de códigos que já estão funcionando, entre outros.

O XP, como qualquer outra metodologia, também tem seus defeitos. Percebe-se que para um melhor desempenho por parte da equipe de desenvolvimento, são necessários alguns fatores, como o trabalho em grupo, um ambiente de desenvolvimento comum a todos, uma busca constante pela qualidade do software e uma maior interatividade entre o cliente e os programadores. Fatores estes que se não forem seguidos à risca podem atrapalhar o andamento do projeto - no Brasil, para a adoção do XP esse é o principal problema. Também, apesar da metodologia ter mais de 10 anos no mercado, muitos programadores deparam-se com algumas dificuldades ao utilizar a mesma, tais como a relutância dos gestores da empresa em adotar algumas regras de desenvolvimento, que na visão deles seria um desperdício de tempo e dinheiro e a resistência dos programadores em trabalhar em equipe e principalmente seguir regras.

Referências:

PRESSMAN, Roger S. Engenharia de Software. 6.ª Edição. 2006. Considerado por todos como melhor livro de Engenharia de Software esse livro é a base para qualquer curso de Engenharia de Software.

SOMMERVILLE, Ian. Engenharia de Software. 8.ª Edição. 2007. Considerado por muitos como segunda referência obrigatória para os cursos de Engenharia de Software esse livro, em minha opinião é o melhor. A primeira edição desse livro foi publicada a mais de 20 anos atrás e a 8.ª edição possui todas as atualizações necessárias para o acompanhamento dessa importante disciplina.

TELES, Vinícios M. Extreme Programming - Aprenda como encantar seus usuários desenvolvendo software com agilidade e alta qualidade. 1.ª Edição. 2006. No Brasil, Vinícios Teles é um dos maiores incentivadores do XP. Esse livro aborda de forma descontraída todos os principais pontos do Extreme Programming.

SCJP: Você é o compilador

Apesar de existir o Sun Certified Java Associate (SCJA) a primeira certificação que a maioria dos programadores da linguagem Java considera é a Sun Certified Java Programmer (SCJP).

A Sun descreve o SCJP como uma certificação para os programadores que desejam demonstrar seus conhecimentos nos fundamentos da linguagem Java. Mas, o mercado de trabalho está seguindo uma linha de exigir/desejar essa certificação para seu futuros desenvolvedores.

Os assuntos que fazem partes dos requisitos para a prova do SCJP são:

1. Declaração iniciação e escopo
2. Controle de fluxo, Exceções e Assertivas
3. Conceitos de Orientação a Objetos
4. Fundamentos
5. APIs fundamentais
6. Concorrência
7. Generics / Collections

O importante é que todo o assunto é coberto pelo livro Certificação Sun para Programador Java 5 de Kathy Sierra e Bert Bates cobrem todos os assuntos da prova.

Passos para obter a certificação:

1. Possuir conhecimento na linguagem Java – não aconselho que a preparação para certificação seja o primeiro contato com a linguagem Java, o ideal é que o candidato tenha um conhecimento prévio. O conhecimento pode ser obtido através de um livro (aconselho Use a Cabeça Java de Kathy Sierra e Bert Bates) ou através de um curso (existe a possibilidade de fazer uso do curso da Iniciativa JEDI);
2. Estudar o livro Certificação Sun para Programador Java 5 – o livro da Kathy é referência obrigatória e é o mais indicado por todos. Leia um capítulo faça o exercício e solicite a outra pessoa que corrija, se sua média for menor do que sete leia capítulo novamente;
3. Compre o livro Certificação Java 5 – Guia Preparatório Exame CX 310-055 – esse livro é uma coletânea de perguntas com as respostas comentadas.
4. Faça quantos simulados puder – quanto maior for a quantidade de simulados melhor (fiz apenas dois dos três disponíveis no livro do passo 3, mas aconselho que faça vários inclusive os web).
5. Compre o voucher e marque a prova – compre o voucher na Sun pelo número: 0800-55-7863, marque a prova no site da Prometric e boa sorte.

Já era desenvolvedor a quase três anos quando resolvi fazer a prova, mas acredito que estudar para a certificação foi mais importante do que obter o título.

Referências:

SIERRA, Kathy e BATES, Bert. Certificação Sun para Programador Java 5. Alta Books. 2006. Referência obrigatória para todos aqueles que desejam fazer a prova do SCJP.
SERSON, Roberto. Certificação Java 5 – Guia Preparatório Exame CX 310-055. Brasport. 2006. Esse livro possui uma sequência de perguntas com as resposta comentadas e 3 simulados. Depois de ler o ligro da Kathy esse livro ajuda bastante.

Por que alguns desenvolvedores Java não sabem o que é passagem por referência?

Por que é muito comum observar discussões se Java é passagem por valor ou se é passagem por referência? Será que toda essa dúvida é justificável? Existe na arquitetura da linguagem Java alguma característica que ajude a provocar essa dúvida? Vou tentar explicar esse assunto novamente.

Para entender corretamente esse assunto é necessário o conhecimento de alguns fundamentos:

Valor de uma variável: toda variável representa um espaço de memória onde é possível armazenar alguma informação e esse é o valor da variável. A forma mais comum de atribuir valor a uma variável em Java é através do operador de atribuição =.

Exemplo:

int x = 35; // o valor 35 foi atribuído a variável x
char y = 'u'; // o valor 'u' foi atribuído a variável y

Referência de uma variável: referência é um endereço de memória, logo, referência de uma variável é o endereço de memória onde a variável está alocada.

Em Java não existe um comando para pegar a referência de uma variável. Em C existe o operador & que tem essa função.

Exemplo 01:

int main(int argc, char *argv[]) {
int a = 25;
printf("Valor de a: %d e da referência de a: %d\n", a, &a);
return 0;
}

Ok, em Java não existe uma forma de obter o endereço de memória de uma variável, ou seja, não existe como pegar uma referência de uma variável. Então de onde vem a dúvida? O grande vilão dessa história é o comando new.

O comando new: serve para criar instâncias de classes, os famosos objetos. O que gera dúvida é a seguinte sintaxe do comando new:

ObjetoQualquer x = new ObjetoQualquer();

Observando a linha acima o desenvolvedor pode acreditar que a variável x armazena uma instância da classe ObjetoQualquer, na verdade, na linha acima, o comando new cria uma instancia da classe ObjetoQualquer e armazena o endereço de memória, dessa instância na variável x.

Ainda com dúvidas? Lembre-se do modificador final: esse modificador tem a função de não permitir que o valor (lembre-se eu disse VALOR) de uma variável seja modificado. Observe o exemplo:

Exemplo 02:

public class TesteFinal {
public static void main(String args[]) {
final int x = 55;
x = 40;
}
}

Nesse exemplo vamos observar um erro, pois tentamos alterar o valor da variável x de 55 para 40. Vamos a outro exemplo.

Exemplo 03:

classe ArmazenaInteiro {
int x = 55;
}

public class TesteFinal {
public static void main(String args[]) {
final ArmazenaInteiro a = new ArmazenaInteiro();
a.x = 40;
a.x = 990;
a.x = 312;
}
}

Pode testar... Não será encontrado nenhum erro, nos alteramos o objeto que está armazenado em a, mas não alteramos o valor de a.

Para finalizar a contraprova do exemplo 03, vamos agora alterar o valor de a:

Exemplo 04:

classe ArmazenaInteiro {
int x = 55;
}

public class TesteFinal {
public static void main(String args[]) {
final ArmazenaInteiro a = new ArmazenaInteiro();
a = new ArmazenaInteiro();
}
}

Erro na certa.

Não tenho a pretensão de achar que esse post vai eliminar com as gigantescas dúvidas sobre passagem por valor X passagem por referência em Java, mas, tentei fazer a minha parte, usei uma abordagem diferente.

Gerenciamento de Projetos

A área de desenvolvimento de software é bastante recente, porém sua evolução e profissionalização foram muito rápidas e hoje somos obrigados a estudar outras disciplinas, além das técnicas de desenvolvimento. Uma importante disciplina é o Gerenciamento de projetos.

O que é projeto?

Projeto é um esforço temporário utilizado para produzir de forma progressiva um produto, serviço ou resultado único.

Temporário - um projeto deve possuir datas de inicio e de fim bem definidas.

Exclusivo - a saída de um projeto que foi concluído sempre é um item exclusivo, seja esse um produto (Ex.: uma peça da turbina de uma aeronave), um serviço (Ex.: um serviço de alarme "X" antes do aniversário de um amigo) ou um resultado (Ex.: redução das despesas operacionais da empresa em 28%).

Forma progressiva - para atingir o resultado final do projeto, esse passa por diversas etapas entre a data inicial e a data final.

Ob.: um projeto é considerado como concluído quando o resultado pretendido for atingido, mas existem situações em que o projeto é cancelado.

Partes interessadas

Como integrante das partes interessadas no projeto podemos considerar o patrocinador do projeto, a equipe de gerência de projetos e a equipe de execução do projeto.

Patrocinador do projeto - pessoa, grupo ou empresa que solicitou o projeto e/ou está financiando.

Gerência de projeto - pessoa ou grupo responsável pelo correto andamento do projeto.

Equipe de execução do projeto - são os responsáveis pela construção do projeto.

O que é gerenciamento de projeto?

Segundo o PMBok, gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades de projetos afim de atender aos seus requisitos.

Referências

HELDMAN, Kin. Gerência de projetos: Fundamentos. Rio de Janeiro. Elsevier, 2005.

Guide PMBOK 3ª ed. Project Management Institute, Inc. Newtown Square, 2004.

HELDMAN, Kin. PMP: Project Management Professional Study Guide 3ª ed. New Jersey. Wiley Publishing, 2005.