Técnicas de programação defensiva IV

Setembro 29, 2008

Continuando com os posts sobre programação defensiva, vamos para a quarta técnica:

Mantenha seu código claro, evite complicações desnecessárias.

Esta tambem é fácil! Muitas pessoas, com boa intenção, tentam escrever um código muito “otimizado”, colocando várias instruções  na mesma linha, ou utilizando estruturas que não vão mais complicar do que agregar, assim, tornam o seu código fonte muito difícil de ler.

Tenha em mente que provavelmente outras pessoas vão ler seu código, e se você desenvolve algo muito complexo, mais tempo o programador vai levar para entender seu código, impactando assim o orçamento do projeto.

Um exemplo bobo que pode tornar um código mais simples de se entender, é a utilização de ( ) em empressões matemáticas, ou mesmo em comparações. Pode-se ainda pular linhas entre “etapas” do seu código fonte.

Uma boa prática para ser lembrada neste ponto, é a utilização do KISS.

Resumo da ópera: mantenha seu código o mais simples possível, obviamente sem abrir mão da perfeita funcionalidade do mesmo, mas evitando complicações desnecessárias.

Enjoy.


Não chateie seu Networking

Setembro 26, 2008

Networking: na definição que nos interessa, significa contatos. Ter um bom contato alocado em uma boa empresa ou ainda no lugar certo e na hora certa pode trazer muitos benefícios para as pessoas.

O grande problema é que algumas pessoas não sabem utilizar seu networking da forma correta, e cometem erros que podem abalar ou até dar fim a relação.

Com base em fatos que ocorrem/ocorreram comigo e com amigos, escrevi algumas dicas para serem utilizadas no relacionamento com seu contato, vamos lá:

(Novo) Faça uma auto análise antes de pedir algo: Esta eu pensei pois acabei de passar por N situações dessa forma. Publiquei uma notícia aqui no blog falando de vagas de emprego em Java para quem tem Inglês para conversação pelo menos no nível intermediário. Já recebi pelo menos 20 currículos, dos quais exatamente 12, não tem o mínimo conhecimento de Java e nem de inglês intermediário. Não peça algo (emprego, etc) sem estar preparado para isso. Pode ser duro, mas é a realidade. Eu ainda respondo as pessoas falando que preciso de melhor habilidades na tecnologia e no inglês, mas a maioria das pessoas simplesmente apaga o e-mail.

O contato não é bibliotecário: é muito, mas muito comum mesmo, as pessoas enviarem e-mail para seus contatos perguntando algo do tipo: “você sabe onde encontro material sobre X? Poderia me recomendar sites?”. A não ser que X seja um tema estremamente novo e você realmente não encontrou NADA em lugar algum, e, seu contato realmente saiba o que é X, não faça isso. Para isso existe o Google. Com este tipo de atitude você pode facilmente passar a impressão de ser folgado e então passar a ser ignorado.

Contato não é psicólogo: acreditem, também é comum pessoas começarem a falar de seus problemas pessoais com o contato. Ficar falando que está nervoso para a entrevista que o contato te arrumou, é o fim da picada! Guarde suas emoções para você. Novamente, a não ser que o contato de liberdade para isso, não o faça. Você pode e deve falar sobe carreira, mas tem que tomar cuidados e saber o momento certo de tocar em certos assuntos. Algumas pessoas não gostam de falar sobre salário e do local onde trabalham, então, procure “conhecer” mais seu contato antes de entrar em certos assuntos.

Cobre sim, mas com moderação: seu contato lhe prometeu algo ontem, e ainda não enviou? Espere. Na maioria dos casos, um contato não tem obrigação nenhuma em relação as pessoas, então espere um pouco. Se a demora persistir, envie um e-mail, cobrando educadamente, agora, se começar a demorar muito mesmo, eu desistiria, a não ser que já exista um bom grau de intimidade, até sim, pode pegar o telefone e cobrar.

Não recomende alguém que não vale a pena: Muitas vezes as pessoas encaminham contatos para o seu contato, na forma de indicação para alguma vaga. Tome muito cuidado com isso. Analise se quem você está recomendando vale realmente a pena. Se você indica alguem somente para “se livrar” dessa pessoa, pode arrumar um problema maior, que é seu contato ficar chateado com você.

Não inclua o e-mail do networking na sua lista de distribuição de piadas, contos, fotos, etc… A não ser que ele tenha lhe dado permissão para tal, mas leia a próxima dica antes.

Envie para o e-mail correto: Muitas pessoas costumam ter um e-mail profissional (da empresa) e um pessoal. É importante saber utilizar cada um deles no momento adequado. Quando for enviar a piada citada na dica acima, jamais envie par ao profissional.

Ainda sobre e-mail. Tenha bom senso: Participar de correntes para salvar a menininha doente, que recebe um dólar por cada e-mail enviado, é pura mentira, que sentido tem? Piorou se você incluir o e-mail do seu contato na lista. Piorou mais ainda se for o contato profissional. Acabou de piorar ainda se você incluiu ele como CC e não como cópia oculta! Cuidado com correntes! Você pode passar por idiota, no mínimo, participando de uma.

Se não tem sentido, não incomode: Nunce envie um e-mail sem sentido não solicitado, por exemplo, enviar um comentário sobre uma tecnologia X que foi lançada. Pense no que isso ai agregar para o contato. A não ser que seja realmente um tema de pesquisa do contato e que possa agregar algo. Enviar um e-mail só por enviar, não faz sentido. Mantenha suas opiniões no seu blog.

Pense bem antes de assumir um compromisso: Se assumir um compromisso com um contato, por exemplo, estiver disposto a entrar na empresa que ele está, cuidado para não desistir. Isso pode te queimar e queimar seu contato. Se assumir um compromisso, vá até o final.

Seja específico quando enviar e-mails: Nunca enviei um e-mail “do nada” para seu contato com seu currículo em anexo. Ele vai deletar o mesmo. Lembre-se, um contato não tem a mínima obrigação de se lembrar de você, então, apresente-se: “olá, conheci o senhor do dia da Santa Salvadora, e comentei que procuro um emprego na área por isso estou enviando meu currículo conforme solicitado…………”. Mesmo que não seja um currículo, deixe bem claro o motivo pelo qual está enviando o e-mail.

Agradeça: Saiba falar um muito obrigado para seu contato quando ele te ajudar em algo. Não custa nada e vai deixar ele feliz e mais motivado para ajudar você e outras pessoas. É de muito bom tom enviar um e-mail agradecendo por algo ou mesmo, postar um comentário no blog dele, uma recomendação no linkedin, etc. Agradecimentos tem muito valor, agradecimentos públicos, mais ainda.

Tempo é dinheiro: Por fim, pense em um contato como uma pessoa ocupada, que não tem todo o tempo do mundo para te ajudar, então seja sempre objetivo e tente “se responder” antes de perguntar. Muitas vezes, com um pouquinho de reflexão sobre sua pergunta, você mesmo a responde.

Enjoy!


Técnicas de programação defensiva III

Setembro 24, 2008

Dando seguência a série sobre programação defensiva, vamos para a terceira técnica:

Não acredite em ninguém.

Esta técnica é bem simples e prega que nunca devemos acreditar em usuário, arquitetos, programadores, classes, etc.

O que isso significa?

Significa por exemplo, que sempre devemos deixar nosso programa preparado para todas as possibilidades que ele possa vir a enfrentar. Um arquiteto pode lhe falar que seu programa vai receber sempre uma data quando chamado. Certo, mas é impossível não receber algum valor nulo(não acredite no arquiteto)? Quem te garante que o programa que chama seu programa faz todos os tratamentos adequadamente (não acredite em classes)? Qual sua garantia que o usuário vai sempre digitar uma data, e além disso, vai digitar no formato correto (nunca acredite em usuários)?

Com base nessas perguntas, podemos observar então, que devemos preparar nossos programas para tratar parametros, inputs, etc, jamais acreditando que eles vão sempre ser passados, e além disso, vão estar no formato correto.

Enjoy.


Entrevista por telefone… em inglês!

Setembro 23, 2008

Hoje em dia é muito comum as pessoas fazerem entrevistas por telefone em inglês, ainda mais devido ao off-shore, ou seja, você está sendo entrevistado para trabalhar em um projeto com Americanos, Indianos, etc…

Muitas pessoas pedem dicas de como se preparar para a entrevista e como proceder na mesma. Pensei em algumas dicas preciosas ou mesmo, fatos que o entrevistado deve saber para que fique mais traquilo, então, espero que aproveite:

  1. Normalmente o entrevistador não espera que o candidato tenha um inglês fluente, mas que tenha coerência nas frases.
  2. Vai ser avaliado o perfil do canditado: Características, Pró-atividade, Interesse real em fazer parte da empresa e Probabilidade em se manter na empresa.
  3. Tenha uma “cola” em inglês nas mão. Esqueceu? Não sabe a resposta? Cole! No dia a dia o google vai te ajudar.
  4. Não minta ou enrole nas respostas. Se não sabe, diga a verdade.
  5. Se sabe a resposta, cite exemplos. Nunca fale somente: “sim, eu conheço a tecnologia X”.
  6. Somente saia do foco da entrevista (para falar de clima, família, etc) se o entrevistador sair do foco, mas mesmo assim, se vier uma pergunta sobre o clima, responda brevemente, isso foi só um quebra gelo pois o entrevistador percebeu seu nervosismo.
  7. Se você não entendeu uma pergunta, não responda, peça para repitir. Se a qualidade da ligação estiver muito ruim, peça para fazer em outra hora. Isso acontece e vão entender muito bem desde que você deixe claro o problema.
  8. Apresente-se pronunciando claramente seu nome.
  9. Deixe bem claro seu nível de inglês, é legal começar a entrevista com algo do tipo: “First, sorry about my poor english, I’m taking some classes to improve my vocabulary, I can talk technicaly without problens, but I have some problems with casual english.
  10. Use um telefone fixo, e não um celular.
  11. Seja formal e educado utilizando as seguintes “palavras mágicas” (Please…, Nice to meet you…, Could you please…, Thank you, Excuse me, Sorry, Pardon?,I see…, Let me …).
  12. Faça uma lista/glossário dos termos técnicos em pauta. Não esqueça que não pode pronunciar siglas em português.
  13. Esteja pronto a soletrar o seu nome, prepare-se para dizer datas e unidades de Medida no formato americano.

Fiquem a vontade para sugerir mais dicas. Fica ai uma tirinha do Dilbert para descontrair:

Enjoy!


Modelo de currículo em Inglês

Setembro 20, 2008

OBS: este blog mudou de endereço para http://jmmwrite.blogspot.com , acompanhe mais posts sobre TI e carreira lá.

Como estou devendo para muita gente um modelo de currículo em Inglês, as vezes prometo nas aulas, palestras, etc…. resolvi postar aqui e ai facilmente passo o endereço do blog para que baixem.

Elaborei um modelo em inglês com comentários. Salvei em dois formatos, odf e doc. Seguem os links:

Acho que vale a pena repetir aqui algumas das dicas que eu dou para estudantes e profissionais, vamos lá:

  • Elabore um currículo enxuto (Objetivo). Os profissionais que vão avaliar seu currículo não tem muito tempo para isso. Se eles percebem “enrolação”, vão logo tratando de enviar o CV para a lixeira. Também não estão interessados em experiências profissionais que não adicionem nada ao candidato.
  • NUNCA minta. Vão te pegar na entrevista.
  • Não precisa carta de referência ou apresentação a não ser que seja solicitado ou ainda, que seja uma carta do PAPA ou do Linus Torvalds. :-)
  • Coloque somente dados relevantes ao emprego desejado. Colocar que você fez um curso de “ponto cruz” não vai agregar muita coisa… acredite!
  • Não use adjetivos: “Criativo, inovador, etc” (quem tem que te avaliar é o entrevistador, e não você mesmo)
  • Sempre use termos formais.
  • Não coloque pretensão salarial a não ser que seja solicitado
  • Em se tratando de uma vaga para uma posição de TI, colocar que você conhece Windows, Word, Winzip e Internet Explorer, ou ainda, colocar aquele cursinho de Windows 98 que você fez, é totalmente dispensável. Parte-se da premissa que você conhece tudo isso. (se não conhecer… tá feio)
  • Normalmente em TI, o currículo deve ser enviado em Inglês, mas na dúvida, envie um em Inglês e um em Português.
  • No nome do arquivo de seu currículo, Identifique-se colocando o seu nome, por exemplo Fulano_da_Silva_Resume.pdf.
  • Ao enviar o currículo por e-mail, identifique-se! Escreva no e-mail quem você é e por que está enviando o currículo.

Fique a vontade para criticar ou adicionar algo as dicas acima!

Enjoy!


Linkedin: Uma ótima ferramenta para relacionamento profissional

Setembro 19, 2008

View Juliano Martins's profile on LinkedIn

Linkedin é um site de relacionamento profissional, parecido com o Orkut, porém baseado no currículo dos profissionais. Basicamente você se cadastra nele, cadastra suas experiências profissionais, e assim, vai conseguindo se relacionar com as pessoas que trabalharam na sua empresa na época que você trabalhou/trabalha, ou ainda, na faculdade na época que você estudou/estuda.View Juliano Martins's profile on LinkedIn

Mais interessante ainda é poder avaliar profissionais ou ainda ser avaliado, parecido com os testemunhos do orkut, mas claramente, mais profissional.

Existem diversas outras funcionalidades como comunidades, responder a perguntas, procurar emprego, etc.

Recomendo fortemente para qualquer profissional ou mesmo estudante, que entrem no linkedin, é um ótimo local para fazer networking.

A muito tempo eu me cadastrei no Linkedin mas achava que não daria em nada. Essa semana eu recebi um convite e voltei a logar, me surpreendi em ver que até mesmo o CEO da IBM está lá! Ou seja, o negócio não é mais uma simples brincadeira como o Orkut. As pessoas podem colher frutos sérios do linkedin.

Não seria legal encontrar pessoas por lá e estreitar relacionamentos?

Enjoy!


Técnicas de programação defensiva II

Setembro 17, 2008

Continuando os posts sobre programação defensiva, vamos a segunda técnica:

Nunca programe com pressa

Essa realmente é difícil de fazer! Ainda mais nos dias de hoje com a pressão para entregar resultados num curto espaço de tempo… Mas enfim, temos que tentar programar com a maior calma possível.

Devemos pensar linha por linha do nosso código, e NUNCA focar somente no total contexto de nossa aplicação. Se ficarmos somente “mirando” no resultado, podemos criar uma linha que vai quebrar toda nossa aplicação, então pense em TODAS AS POSSIBILIDADES de uma única linha de código. Por exemplo, o que vai acontecer se você deixar passar uma linha como essa:

If (variable.equals(“mandioca”){…..;}

Já pensou se a variável for nula? Seu código quebrou!!!

Então, pense linha por linha e espere sempre o pior, não suponha que a variável vai ter sempre um valor.

A pressa também nos faz deixar coisas pendentes no código, coisas do tipo: “Implementar teste”, “Testar se o contador está sendo iniciado”, “Trocar a list por map”, etc.

Se você deixa algo por fazer, tem grande chance de esquecer, ou mesmo que não esqueça, quando voltar para fazer vai perder um grande tempo para se lembrar do contexto do que estava fazendo.

Moral da história: mantenha a calma. ;-)


Criando documentação java de sua aplicação

Setembro 15, 2008

A maioia dos desenvolvedores iniciantes não conhecem algo chamado Javadoc! Isso é primordial para se ter um bom código.  Javadoc é uma ferramenta para gerar documentação em formato HTML a partir de seus comentários no código fonte.

Comentar o código fonte é muito importante, mas se além de comentar o código, o desenvolvedor gerar o javadoc, ele e sua equipe terão um suporte maior no decorrer do desenvolvimento pois terão um material de referência padronizado e fácil de utilizar. Muitas dúvidas poderão ser sanadas simplemente consultando o javadoc.

As páginas de documentação do java, tais como as que você pode ver em http://java.sun.com/j2se/1.4.2/docs/api/index.html, foram geradas com javadoc.

Faça um teste. Crie um projeto qualquer no eclipse (ou tanto faz…) e nele, crie uma classe chamada Teste. Nesta clase, comente da seguinte forma:

/**
* Classe que imprime Alo Mundo na tela
* @author fulano
*
*/
public class Teste {
/**
* Método principal, responsável por imprimir Alo Mundo na tela
* @param args
* @author fulano da silva
*/
public static void main(String[] args) {
System.out.println(“Alo mundo”);
}
}

Repare que a forma de se documentar é um pouco diferente (/** para iniciar o javadoc e */ para finalizar). Enfim, feito isso, vá para o prompt de comando, e vá para o diretório no qual o codigo fonte do seu projeto se encontra e de o comando:

javadoc -d c:\html *

Ele vai gerar a documentação em c:\html! Veja os resultados.

O Eclise e o netbeans geram javadoc facilmente. Existem N parametros para customizar sua documentação. Veja mais em: http://java.sun.com/j2se/javadoc/index.jsp

O Faq do javadoc está em http://java.sun.com/j2se/javadoc/faq/index.html.

Enjoy.


Feliz dia do programador!!!

Setembro 12, 2008

Parabéns para nós! Hoje é dia do programador.

Mesmo quem não programa no dia a dia, sendo profissional de TI, tem um pouquinho de programador dentro de sí!

Veja mais em http://blog.dimensaozero.com/2008/09/feliz-dia-do-programador/.


Técnicas de programação defensiva I

Setembro 12, 2008

Continuando os posts sobre programação defensiva, vou falar neste post e em próximos posts sobre técnicas de programação defensiva. Para dar início vamos a primeira técnica:

Empregue sempre um estilo de codificação

Primeiro: O que é um estilo de codificação? Podemos resumir a ópera dizendo que um estilo de programação é a forma como a qual você escreve seu código fonte, por exemplo quantos espaços você dá para começar a escrever o código e quantos espaços você dá quando está dentro de um loop, ou seja, edentação. Outros exemplos podem ser nomenclatura de variáveis, de métodos, classes, comentários, etc.

É importante que você tenha um estilo e o siga em TODOS seus programas, mais importante ainda é que sua equipe siga o mesmo estilo. Quando você inicia em um projeto, a primeira pergunta para o líder do mesmo deve ser: nós temos algum documento com nosso estilo de programação? Se a resposta for sim, você DEVE seguir o mesmo. Se o projeto não tiver um documento com a especificação de estilo, crie um e o siga, proponha para o time que o siga.

Por que ter um estilo?

Imagine que você trabalhe em uma equipe de N desenvolvedores e cada um programa de uma forma. Não vai ser muito mais complicado entender o código fonte de uma pessoa que não segue padrão algum? Você não ganharia tempo lendo um código bem edentado, comentado, com nomes padronizados e dessa forma não conseguiria produzir um código melhor? É possível enumerar outros benefícios, mas pelo menos no meu ponto de vista, esse é o maior benefício: o ganho na facilidade em entender um código fonte alheio ou até mesmo um código fonte que nós mesmos produzimos a muito tempo.

Para finalizar, um pequeno exemplo de estilo pode ser:

Todo if, else, for, etc, deve ter um ‘{‘ e ‘}’ correspondente abaixo das instruções tal como no modelo abaixo:

if (msg == null)
{
msg = “TEST”;

}

Enjoy!