quinta-feira, 10 de abril de 2014

Há dias que não valem a pena...


Em muitas situações de nossas vidas somos expostos a opiniões diferentes. Ainda bem. É salutar poder encontrar opiniões divergentes, pois o mundo seria um lugar absurdamente monótono e estagnado se todos concordássemos sempre.

Em todas as situações em que me deparo com alguém que pensa diferente, sempre penso primeiro: "estou errado". E depois com base em meus próprios argumentos tento me convencer de que posso estar certo. Às vezes ganho de mim mesmo, às vezes não. Não me importo nem um pouco em ser convencido por um argumento melhor que o meu. Mas também não aceito argumentos fracos.

Ganhar e perder disputas com base em argumentos é parte da vida. É interessante. É produtivo. É construtivo. Tanto quem ganha quanto quem perde uma discussão sai vencedor, pois saímos pessoas melhores.

Mas há dias em que numa discussão algumas pessoas não se sentem adversárias, e sim inimigas. Ao invés de tentar encontrar uma solução para um bem maior, procuram rancor ou o gosto de revanche. Nessas situações não se encontram vencedores: todos perdem. Perdem pois ao final não temos mais pessoas que juntas poderiam fazer a diferença: ao invés de multiplicar, subtraímos.

Há dias que não valem a pena... Ontem foi um desses dias, pois mesmo tendo ganho uma "disputa", perdi alguém que poderia me ajudar e ser ajudado. Perdemos ambos. Só que, mesmo já sendo adulto, eu ainda não aprendi a perder. E é por isso que fica um gosto amargo pra refletir.

terça-feira, 25 de março de 2014

Oracle Java Magazine: fonte gratuita de informação de qualidade

Edição de Janeiro/Fevereiro de 2014 da Oracle Java Magazine
Gostaria de divulgar na comunidade Java brasileira esta excelente fonte de informações gratuita que está desapercebida por muitos desenvolvedores.

A Oracle Java Magazine (não confundir com a Java Magazine brasileira publicada pela DevMedia) é uma publicação oficial da Oracle sobre a Tecnologia Java. Autores do mundo todo contribuem para produzir esta revista eletrônica bimestral com conteúdo de qualidade.

Seu conteúdo é em inglês, mas como já comentei em um post anterior e como também comentado por +Bruno Souza (o JavaMan) em seu blog, saber ler em inglês é uma habilidade primordial para qualquer desenvolvedor de software. Aproveitem a oportunidade para praticar!

E se vocês folhearem a edição atual e as anteriores poderão notar que muitos brasileiros contribuem para o alto nível da Oracle Java Magazine. Em muitas matérias brasileiros como +Vinicius Senger+Yara Senger+Bruno Souza+Fabiane Nardon+Fernando Babadopulos e outros fazem a diferença. Creio que isso motive ainda mais a nossa participação numa comunidade tão vibrante e engajada que são os JUGs (Java User Groups) brasileiros.

A inscrição é rápida e fácil. Você recebe as notificações da revista por e-mail. Não deixe de aproveitar esta oportunidade. Serve para provar que nem tudo que é bom tem que ser caro.

Bom proveito!

quinta-feira, 27 de fevereiro de 2014

Elegância: uma qualidade em falta no código e nas pessoas


Há algum tempo li uma discussão sobre "código elegante" em algum canto da Internet. A querela contrapunha código "que funciona" contra código "bonito". Como se fazer código "bonito" fosse modinha: o importante mesmo é fazer rodar.

Primeiramente gostaria de deixar claro que todo software é criado com um propósito de valor. Se não cumpre o seu propósito - seja porque é mal feito e não gera o valor esperado ou porque não funciona - nem deveria ser chamado de software. Deveria ser crapware ou qualquer outra coisa parecida.

Definição de elegância segundo a Wikipedia:
"Elegance is a synonym for beautiful that has come to acquire the additional connotations of unusual effectiveness and simplicity." (http://en.wikipedia.org/wiki/Elegance)
 Traduzindo literalmente:
"Elegância é um sinônimo para beleza que adquiriu as conotações adicionais de incomum eficácia e simplicidade."
Código elegante então seria algo belo (bonito - agradável ao programador, legível e fácil de entender, coeso etc), eficaz (faz o que se espera dele) e simples (com um mínimo gera um máximo de resultado). Se o nosso objetivo de vida como profissionais de software - como artesãos de software - não for produzir código elegante, então não sei mais o que é.

Além de código elegante, falta-nos a elegância de agir como profissionais:
  • Não é elegante entregar algo que não funciona.
  • Não é elegante atrasar um compromisso.
  • Não é elegante prometer algo que não vai ser cumprido.
  • Não é elegante criar expectativas de prazo falsas.
  • Não é elegante entregar menos do que foi combinado.
  • Não é elegante fazer menos do que o seu melhor possível. 

Entregar código elegante e ser um profissional elegante então não são opções. Fazê-lo e sê-lo são simplesmente questões de ética.

sexta-feira, 6 de dezembro de 2013

5 itens pra identificar um programador-índio e um chefe-cacique


Quando criança havia uma brincadeira do "chefe-mandou". Você tinha o "chefe" e os "índios". Basicamente os índios deviam fazer tudo aquilo que o "chefe" mandasse. Se o chefe não começasse a frase com "chefe mandou..." e os "índios" executassem a ação, estavam fora da brincadeira. Ganhava quem conseguisse ser o último "índio" a sobrar.

E qual o problema? O problema é que essa brincadeira virou coisa de gente grande. Tem muito "programador-índio" brincando de "chefe-mandou". Você identifica um "programador-índio" pois ele:

  1. Não tem a mínima noção do que faz, e também não se importa.
  2. Precisa de uma lista de tarefas (de preferência num issue tracker) pra poder se mexer.
  3. Se ninguém delegar um tarefa, fica o dia inteiro quietinho, sem fazer nada (preferencialmente mexendo no celular, dando umas curtidas no Facebook e vendo uns vídeos no YouTube).
  4. Conta os minutos e segundos esperando as 18h chegarem para poder continuar a brincadeira só no dia seguinte.
  5. Só faz aquilo que o "chefe-mandou", e nada mais que aquilo.

E também temos o "chefe-cacique": uma geração inteira de gerentes treinada com o que há de mais "moderno". Você identifica um "chefe-cacique" pois ele:

  1. Micro-gerencia as tarefas que cada um dos seus "índios" tem que executar.
  2. Cronometra o tempo de cada uma das tarefas.
  3. Controla até o tempo gasto no banheiro ou no cafezinho.
  4. Coloca tudo isso numa planilha ou num gráfico de Gantt pra cobrar mais empenho depois.
  5. Não confia em nenhum dos seus subordinados, pois todos só querem lhe enrolar.

Se você conhece algum "programador-índio", então peça que ele não reclame depois que tem um "chefe-cacique". Pois honestamente um "programador-índio" merece um "chefe-cacique" e merece também a remuneração ridícula que deve estar recebendo.

Se você já conviveu com algum desses tipos, saia dessa brincadeira e procure algo melhor pra você. Seja um profissional competente, um programador de verdade: um artesão de software. Não seja o último "índio" a sobrar...

terça-feira, 15 de outubro de 2013

[Hangout] Perguntas & Respostas sobre TDD com Mauricio Aniche


Aproveitando o embalo do Hangout anterior, o +Fabricio Noda resolveu convidar uma referência nacional no assunto para participar de outra sessão de Perguntas & Respostas. Dessa vez o +Mauricio Aniche nos deu a graça de sua presença e fizemos um rápido hangout.

Eu atuei mais como facilitador, pois como já disse acima, o Maurício é uma referência e compartilhou sua experiência nos poucos minutos em que conversamos.

Bom proveito!

quinta-feira, 10 de outubro de 2013

[Hangout] Perguntas & Respostas sobre TDD


Há algumas semanas o +Fabricio Noda me enviou um e-mail perguntando se eu poderia responder algumas perguntas sobre TDD (Test-Driven Development) para ajudá-lo em seu Trabalho de Graduação.

Sugeri que pudéssemos fazer um Hangout ao vivo para deixar registrado e quem sabe poder ajudar mais alguém que também estivesse interessado no assunto.

Não sei se as minhas respostas foram boas ou se servirão para a monografia do Fabrício, mas de qualquer modo o vídeo do Youtube está acima ou também pode ser visto neste link: http://www.youtube.com/watch?v=2L35NAvS5Do

quarta-feira, 18 de setembro de 2013

[Dica] Descartando suas modificações desde o último commit do git


Muitas vezes realizamos algumas alterações no código, nos arrependemos e queremos simplesmente descartar tudo e voltar ao estado em que estávamos desde o último commit.

Sim, é possível executar este procedimento com git reset e alguns parâmetros, mas ao menos pra mim o jeito mais fácil é rápido é:
git checkout -f
Dica para lembrar: o "-f" é de "f*d*-se". Ok, não é. Mas é exatamente o que você deseja fazer com o seu código descartado.