Todos os post de egomesbrandao

HOL do TFS – Code Analysis

Este hands-on lab é sobre a ferramenta Code Analysis, disponível a partir da versão Professional, e com um set reduzido de regras na versão Express do Visual Studio.Net.

Ela ajuda o desenvolvedor a identificar pontos de melhoria de design, globalização, interoperabilidade, performance, segurança, entre outras categorias… e personalização!

Além do uso stand-alone, pode ser utilizada na automação de build com o TFS, veremos no futuro como fazer isso.

Espero que gostem.

De volta… e com novidades!

Olá, pessoal!

Faz muito tempo! E muitas coisas aconteceram. Meu último post aqui foi sobre o DevDay 12, ano passado… E eu já participei do DevDay 13, e nem consegui postar nada a respeito. Mas bem antes disso, eu fui trabalhar na BR Soluções Integradas, com arquitetura de soluções e ALM. E agora estou mais focado neste último… Muita coisa e pouco tempo. Mas resolvi reatar o compromisso de escrever aqui, agora com um foco maior em ALM, tanto ferramenta, como processo, soluções, … E quando sobrar um tempo outros assuntos, como arquitetura, integrações, nuvem, …

Vou começar compartilhando os primeiros passos que um desenvolvedor, ou administrador, ou até mesmo um consultor de ALM, deve fazer para entrar neste mundo: os Hands-On Labs do Team Foundation Server. Normalmente compartilhados juntamente com uma Virtual Machine do Tfs, os HOL são exercícios que demonstram como usar features e novidades da plataforma Tfs. É a maneira de colocar o pé no ALM usando o Tfs.

Estou gravando os HOL em vídeos e disponibilizando para a comunidade. Se quiserem fazer perguntas ou trocar ideias, sobre o vídeo utilizem os comentários no post.
Assine o feed para ficar por dentro das novidades. As postagens de vídeos irão ocorrer ás terças e quintas, até o final dos HOL. Depois teremos muitos outros assuntos para debater, distrinchar, detalhar. Afinal ALM é colaboração.


Referências citadas no vídeo:

#DevDay2012 nas Gerais

Tive o prazer de ter a submissão da minha palestra aprovada para o #DevDay2012! O pessoal da organização foi extremamente atencioso e nos receberam com uma agradável surpresa!

O evento

O evento aconteceu na UNA Campus Aimorés, mas primeiramente por um pequeno erro de interpretação no mapa de um certo colega palestrante fomos parar em outro campus…

É  uma iniciativa do Dev Island e eles se denominam uma comunidade de desenvolvimento plural, não pertencente a uma tecnologia ou linguagem. Tanto que foram feitas palestra de Java do Juan Lopes, de Python do Luciano Ramalho, … E várias outras distribuídas por 3 salas, durante o dia todo.

Encontrei além do Juan Lopes,  que é do RJ, o Elemar Jr. que é do RS; Essa é uma boa “desculpa” para ir nesses eventos, dá para reencontrar amigos distantes… Mas também outros que estão aqui do lado em SP, como o Victor Cavalcante, Rodrigo Yoshima e o Vinícius Quaiato, que foi comigo e espantou um cara da nossa fileira no avião antes mesmo da decolagem!

Minha palestra

Submeti a palestra que eu havia apresentado no #TDC2012, que é o assunto que eu tenho estado mais envolvido no últimamente. Mas não queria apresentar da mesma forma. O meu objetivo era diminuir os slides, que sofreram um Refactoring (SIM!), diminuir o tempo “teórico”, e mostrar um Refactoring ao vivo. Infelizmente ao treinar o tempo percebi que seria muito difícil encaixar nos 45 minutos disponíveis; e infelizmente novamente, mesmo reduzindo o código que eu ria demostrar, o tempo não foi suficiente. Acho que é preciso 1 hora e 30 minutos, talvez, ou só focar no código.

Mas o objetivo não era ensinar técnicas de Refactoring, só é possível estudando, treinando, praticando… O objetivo foi passar a mensagem de que somos responsáveis pelo nosso código, não o analista, não o arquiteto, não o gerente. E que temos que perder o medo de melhorá-lo.

“It’s easier to beg forgiveness than to ask permission.”, Grace Hopper

“É melhor pedir perdão, do que pedir permissão”

Não pedimos para colocar um If, um For, por que devemos perdir permissão para melhorar o nosso “ambiente” de trabalho? Só depende de nós! E para isso é preciso estudar, ler, codar, e até mesmo errar; mas com consciência! Aprenda os Code Smells, as técnicas de Refactoring, maneiras de garantir a mudança com testes; que você não irá se arrepender e terá muito mais segurança.

Desafio

Me propus nessa semana de gravar o Kata completo em vídeo e publicar, quando fizer eu tuíto. E vou publicar também o código no GitHub!

Agradecimentos

Galera da organização, Diogo Damiani, Douglas AguiarGibran Silva, vocês estão de parabéns pela organização, que é bem puxada! Também quero agradecer o Quaiato e o Juan por algumas dicas de última hora sobre o Git que salvaram a minha pele, ou não, já que o que eu havia preparado deu pau, tsc… tsc… tsc…, mas eu chego lá.

#TDC2012

Tenho escrito pouquíssimo aqui no blog, falha minha! Não estou conseguindo me organizar para manter a constância. Tenho vários posts em rascunho que preciso publicar, tentarei encaixar essa tarefa nas lista de atividades semanais.

E falar sobre o TDC 2012 é algo que eu não posso deixar de fazer apesar de atrasado!

O evento

Novamente o TDC foi além das minhas expectativas. Esse ano mais pessoas inscritas, mais trilhas foram criadas, por exemplo TV Digital e Management 2.0; e algumas foram quebradas em várias tecnologias (além de uma de Mobile, como no ano passado, tivemos trilhas específicas sobre iOS e Androide).

Minha palestra

Tive a satisfação de ter a palestra que submeti aprovada na trilha de Arquitetura (esse ano foi uma das trilhas que foram quebradas: Arquitetura Java e Arquitetura .Net).
Apesar de estar na trilha de Arquitetura,  eu quis apresentar algo mais prático para que pudessem chegar à noite em casa ou no próximo dia no escritório começar a pesquisar mais sobre o assunto, já que uma palestra de 45 minutos não é,  de maneira alguma,  suficiente, e já aplicar, na mesma hora, no projeto atual. Sem precisar instalar framework, mudar paradigmas, ter que pedir autorização.

Que assunto melhor para isso do que falar de Refactoring!?  É uma prática que deveria ser comum no ciclo de desenvolvimento, no TDD após uma funcionalidade passar no teste de unidade você faz Refactoring para melhorar o código. Ao pegar uma aplicação já em funcionamento para fazer uma correção de bug ou mesmo para colocar novas funcionalidades, por que não aplicar um Refactoring em algo que está ali do lado e pode ficar melhor?

Infelizmente o medo é uma constante para muitos, medo de estragar o código, de quebrar a aplicação, ou de que o Refactoring demore muito mais do que só desenvolver a nova funcionalidade. Isso prejudica a melhoria contínua do código, você pode acumular uma dívida técnica e sabemos que a Entropia existe e com o passar do tempo irá dar as caras, ou os bugs, no seu código.

Mas se tudo isso é verdade, então não devemos mesmo fazer Refactoring, certo? Não! Existem técnicas que ajudam nessa hora e muito.

  • Viu que existe código que está lá no meio e pode virar um método e ter reuso em outros lugares? Existe uma técnica para fazer isso
  • Viu que na verdade tem código que está na sua classe mas que não é do que essa classe deve fazer? Existe uma técnica para extrair esse código para uma nova classe

E por aí vai… É novidade? Não, pelo menos não deveria, essas técnicas estão descritas no livro do Martin FowlerRefactoring: Improving the Design of Existing Code.

Mas não é só isso! Você tem que ter certeza de que ao extrair um código e transformar em um método e reutilizá-lo em outros pontos do sistemas não vai quebrar o software! E então, como fazer? Existem técnicas para isso também!!

  • Eu preciso fazer uma mudança… Mas quais métodos preciso testar?
  • Preciso quebrar dependência…

E novamente por aí vai. Você pode encontrar várias respostas para isso no livro do Michael Feathers: Working Effectively with Legacy Code.

Logicamente é impossível se aprofundar nesse assunto durante uma palestra, portanto a mensagem mesmo que eu quis deixar foi:

“It’s easier to beg forgiveness than to ask permission.”, Grace Hopper

Essa frase é sensacional, ou seja, não espere para pedir para o seu gerente permissão para fazer um Refactoring, estude as técnicas e pratique no seu código, melhore ele antes que seja necessário ou antes que alguém peça! Não tenha medo.

Melhor do que simplesmente falar sobre técnicas é demonstrar. Portanto fiz um Kata do o passo a passo de Refactoring do primeiro exemplo do livro do Martin Fowler, em C#. Estou organizando o repositório e vou publicar no Github aqui, dê um Watch para acompanhar ou fique ligado no meu twitter que avisarei quando fizer, provavelmente essa semana ainda. Por hora,  veja os slides da apresentação abaixo:

Segunda palestra! (0_O)

Calhou que no mesmo dia, 30 min depois, apresentei uma lightning talk sobre Brownfield na trilha .Net University, voltada para estudantes, infelizmente e aproveito para me desculpar com o Victor Cavalcante, eu falei demais e não consegui chegar no fim dos slides que montei! Então para não ser totalmente em vão, uma dica: ao fazer uma lightining talk,  cronometre rigorosamente o tempo nos ensaios e NÃO SAIA DO SCRIPT!! Mas valeu a experiência. O tema foi um resumo da minha apresentação ano passado na trilha de Arquitetura do TDC.

Outras trilhas

Resolvi que esse ano iria participar de trilhas com tecnologias que não estavam no meu dia-a-dia. Infelizmente NoSQL não consegui ir, nem na de Arduino, mas me inscrevi para Python e Robótica e domótica no fim de semana. Porém nos dias acabei assistindo palestras de outras trilhas o que foi melhor ainda, consegui ver várias que me interessavam:

  • No sábado
    • Debate: O que muda com o Windows 8, com Giovanni Bassi, Victor Cavalcante e Igor Abade
    • Metaprogramação com Python, Tiago Albineli Motta
    • Brincando com Kinect, Guilherme Policicio Rey
    • Python para programadores PHP, Evaldo Junior Bento
    • Técnicas e recursos para desenvolvimento Web em cenários de grande escala, Alexandre Tarifa / Cleber Dantas da Silva
    • Ruby: Patterns e Anti-Patterns, Fabio Akita
    • … Vi algumas lightning, finalizações de algum, comecinhos de outras
  • No domingo
    • ADK: como o Android pode se integrar com hardware, Luís Fernando de Oliveira Leão
    • Controlando sua casa pela Internet, Vinicius Morandin Senger
    • Dicas de Startup’s, Luca Bastos e Métricas para Startups, Flávio Fonseca Alves; duas rápidas de 20 min
    • … Vi algumas lightning, finalizações de algum, comecinhos de outras

Fora  as conversas entre uma sala e outra, amigos que encontrava, conversas nos stands, que outro lugar eu poderia bater um papo com o Lucino Condé, que há tempos não via e agora foi pras nuvens, … Isso é demais, não é uma tecnologia, não é uma empresa, é tudo ao mesmo tempo junto e misturado, é Open Source do lado de proprietário, é programação de software do lado de “programação de hardware”.

Definitivamente é um evento que se deve ir, mesmo que você não entre em qualquer uma das palestras você terá o que conversar, ver e fazer muito networking.

Agredecimentos ao Leandro Daniel coordenador da trilha de Arquitetura, Victor Cavalcante coordenador da trilha .Net University, agradecimento especial ao Raphael Molesim que me ajudou a organizar o repositório Git para que eu pudesse mostrar a evolução do Refactoring de uma maneira legal, e sempre a Yara Senger e Vinicius Senger pela organização do #TDC.

Escrever errado… #atequando?

Nos comunicamos através de códigos e esses códigos são as línguas, que tornam possível interagirmos com outras pessoas. Primeiro,  aprendemos a falar e aos poucos vão nos ensinando algumas regras. E existem regras básicas, por exemplo o pronome oblíquo tônico “mim”, que  não deve ser usado na conjugação de um verbo, mim não leva, mim não faz, … Mas muitos cometem esse deslize. Depois aprendemos a escrever e várias outras regras que formam a gramática da língua. Com isso temos a possibilidade de espalhar nosso pensamento estando presente ou não. A escrita possibilita e-mails, slides em uma apresentação, comunicar procedimentos, ações ou proibições em placas de trânsito; artigos em jornais, revistas, livros, blogs, … Uma infinidade de possibilidades, até mesmo nos tornarmos imortais.

Uma frase muito comum dita por vários desenvolvedores de software em listas de discussão ou no cafezinho na empresa é: “Não preciso saber escrever,  o meu negócio é escrever código”. Isso é uma verdade? Nós desenvolvedores não precisamos saber nos expressar na língua portuguesa escrita? Um desenvolvedor escreve e-mail? Escreve um documento no Word? Ou abre uma thread em alguma lista de discussão? É lógico que sim! Um desenvolvedor de software precisa muitas vezes saber se comunicar por escrito. E precisa fazer isso de maneira extremamente correta para se fazer entender e para isso deve fazer uso das regras gramaticais, ortográficas [tem mais alguma?]. Ou não se vai  entender mesmo! Escrever errado só mostra o seguinte: Você já era incompetente no primário ou ficou preguiçosamente vagabundo depois de adulto.

Quem acha que não precisa escrever direito muitas vezes também não gosta de ler. Pergunta para alguém que disse que não precisa escrever direito qual o último livro que ela já leu. Pergunte qual o livro que ela está lendo ou qual livro na área de desenvolvimento ela leu ultimamente e que a ajudou ou que foi interessante. Você vai ficar sem resposta provavelmente. Ler é essencial e, para escrever bem é preciso ler também. A leitura no mínimo serve como a manutenção do nosso aprendizado da língua.

Se você acha que não precisa escrever português direito… como é o seu código?

A maior parte do tempo um desenvolvedor vai escrever, ou pelo menos deveria! Ele não vai escrever a maior parte do tempo e-mails, artigos, posts ou threads de discussão, ele vai escrever código em um língua que o compilador vá entender e depois transformar em uma língua que a máquina vai entender. As linguagens de programação de sua própria sintaxe, regras. Existem palavras reservadas, regras de sintaxe que, se não obedecidas, seu código simplesmente não vai funcionar. As vezes nem irá compilar! Para a sorte de muitos, erros básicos (o “dá pra mim fazer”), da linguagem de programação são pegos pelo compilador, algumas linguagens funcionam diferente.

Indo além, como é a legibilidade do seu código? Não basta só saber usar as palavras reservadas em uma ordem que funcione, é preciso também escrever bem o seu código. Chovendo no molhado,  é preciso descrever bem o que você quer dizer com aquele código, o @vquaiato já blogou sobre o assuntou quando estava comentando o Clean Code (aliás: você já leu o livro? :D ).

Quando estiver escrevendo um código assim você poderá aplicar Command and Query Separation! O Uncle Bob escreveu apenas uma página no livro, mas acho um assunto bem interessante e tenho procurado colocar isso no meu código. A ideia aplicada em funções é que elas façam alguma coisa ou respondam alguma coisa, nunca as duas ações juntas. Exemplo:

namespace CQS
{
  class Program
  {
    static void Main(string[] args)
    {
      CalculoAumentoDeSalario calculo = new CalculoAumentoDeSalario();

      decimal SalarioComAumento = calculo.CalculaAumentoERetornaSalario(10);
      Console.WriteLine("Salário com aumento: {0}", SalarioComAumento);
      Console.ReadKey();
    }
  }
  public class CalculoAumentoDeSalario
  {
    private decimal Salario = 1000;
    //...
    public decimal CalculaAumentoERetornaSalario(decimal percentualAumento)
    {
    //...
      Salario = Salario + (Salario * percentualAumento / 100);
    //...
      return Salario;
    }
  }
}

Repare no código acima que nem tudo o que o método CalculaAumentoERetornaValor vai fazer está explicito no seu nome, para quem lê só a chamada da função vai entender que irá ser calculado o aumento e retornado e não que já irá alterar o valor do salário. Se essa classe que estiver sendo persistida uma conferência de valor, já que para aumentar o cálculo real compreende vários impostos e realmente é preciso uma conferência; o sistema seria comprometido!

Fazendo um refactoring, melhorando nomes, aplicando CQS:]

namespace CQS
{
  class Program
  {
    static void Main(string[] args)
    {
      Salario salarioFuncionario = new Salario();
      salarioFuncionario.AplicaAumento(10);
      Console.WriteLine("Salário com aumento: {0}", salarioFuncionario.Valor);
      Console.ReadKey();
    }
  }
  public class Salario
  {
    public decimal Valor { get; set; }
    public Salario()
    {
      Valor = 1000;
    }
    //...
    public void AplicaAumento(decimal percentualAumento)
    {
    //...
      Valor = Valor + (Valor * percentualAumento / 100);
    //...
    }
  }
}

O código ficou mais legível, os nomes refletem melhor o que as funções fazem. Esse é um código de exemplo, alguns nomes ficariam ainda melhores em um código funcional. A função agora realmente só tem uma única função. Faça o teste no seu código!

Obs.: Encontrando algum erro de português nesse post se atenha ao conhecimento, ou seja, faça o que eu digo e não faça o que eu faço. #Bazinga

UPDATE, links úteis:

CommandQuerySeparation, por Martin Fowler

CQRS, por Martin Fowler

CQRS, por Udi Dahan

Brownfield, Greenfield, Legacy, … O que é tudo isso?

Motivado pela minha participação no Void podcast, episódio #017 – Strawberry Brownfields Forever, (valeu pelo convite Elemar Jr. (@elemarjr), Leandro Daniel (@leandronet) e Vinícius Quaiato (@vquaiato)) resolvi começar a publicar uma série que eu estava preparando desde o ano passado, como uma continuação da palestra sobre o tema que fiz em duas cidades, São Paulo e Florianópolis, no TDC 2011, post sobre o evento, e aproveitando já foi liberada a data do evento esse ano, entre no site: The Developers Conference.

Brownfield

Apesar de trabalhar com Brownfield, não sabia que existia um nome para este “momento” ou situação no desenvolvimento. Me deparei com o termo ao encontrar o livro Brownfield Application Development in .NET, de Kyle Baley and Donald Belcham, publicado na Manning Publications Co.,o qual existe versão PDF, ePub e MOBI, veja aqui. O engraçado é que o título do livro dá a entender que o assunto será construir uma aplicação Brownfield! o_O Não poderia estar mais errado!

O termo é uma analogia a um terreno que está contaminado por lixo ou entulho, mas tem potencial, se for feita uma limpeza. No desenvolvimento de software o termo é a classificação de uma aplicação que sofreu a ação do tempo em suas linhas de código, ou seja,  uma aplicação que foi recebendo atualizações, modificações, até mesmo de objetivo; sem uma preocupação com a qualidade e como essas ações interferem  no código, deixando o processo de atualização ruim.

Mas não é só uma aplicação já em produção que se torna Brownfield. No início de um novo desenvolvimento, chamamos a aplicação de Greenfield, um campo novo no qual começamos a criar. Se não tomarmos cuidado,  essa aplicação já vai entrar em produção como Brownfield!

Do Green ao Brown

Quando não planejamos corretamente, não analisamos totalmente ou não temos toda a informação é que surgem as péssimas técnicas, metodologias, processos, que não precisam ser ensinadas, elas simplesmente acontecem na nossa cabeça. É mais difícil fazer algo bem feito do que algo mal feito. É simples, rápido, fácil, parecem ser características boas, mas são somente em um primeiro momento, ou a curto prazo! Porém,  quando se desenvolve um software ele não é uma solução de curto prazo ou uma ferramenta temporária, mas pelo contrário, vai durar e bastante. Todo mundo já ouviu alguém pedir uma solução momentânea, que ganha atualizações por que outra área achou interessante usar também, e que no fim vai ficando e ficando, e dali a algum tempo é core dos negócios da empresa. Uma simples parada para manutenção desse serviço poderá causar perda financeira para o negócio. Se um chef de cozinha, que está cozinhando uma refeição, que será consumida em seguida e em uma ou duas horas, mantém seu ambiente de trabalho limpo e organizado. Por quê é diferente quando se está codificando algo que vai existir por meses, anos, talvez décadas?

Exceções existem! Existem aplicações que tem um tempo de vida tão curto que invalida a necessidade de técnica, práticas, metodologias; e não estou falando de simples scripts para automatização de tarefas.  Na Forward Internet Group, uma empresa londrina, as aplicações nascem e morrem muito rapidamente! Como o foco são campanhas publicitárias que entram e saem rapidamente do ar,  para eles não existe a necessidade de fazer testes! Até mesmo por que a aplicação é tão pequena que os testes poderiam ter mais linhas de código do que a própria aplicação. Veja mais nessa apresentação da QCon 2011, em Londres.
Por isso não gosto tanto da definição do Michael Feathers de que código legado é código sem teste, pois invalida outros cenários ou situações.

A falta de planejamento constante, validando as funcionalidades a serem implementadas,  se realmente se encaixam no domínio do problema que o software se propõe a resolver; de refactoring; fazendo a limpeza do código que está sendo produzido; de controle da dívida técnica e até mesmo da organização da equipe de desenvolvimento, do turnover, levam uma aplicação do Greenfield ao Brownfield, às vezes de maneira assustadoramente rápida.

Ninguém gosta de trabalhar nesse tipo de código. Alterações tendem a gerar problemas inesperados, que fazem a equipe estender o horário de trabalho, a dificuldade de evolução faz você trabalhar nos fins de semana,  você não consegue mudar um framework de maneira simples,  não é preciso dizer que o custo aumenta exponencialmente com o passar do tempo. Uma verdadeira bola de neve, ou mais tecnicamente, um código macarrônico sem fim.

Lá e de volta outra vez…

Não é uma solução viável simplesmente reescrever o código, já que se estaria solucionando o sintoma somente e não o problema. Sair de um Brownfield não é fácil, é bem trabalhoso, mas trabalhoso por trabalhoso é melhor você se empenhar para resolver o problema do que continuar apenas queimando tempo em problemas recorrentes causados pelo desleixo com o código.

No episódio do podcast chegamos a conclusão de que alguns passos são inevitáveis:

  1. Convencer sua equipe: de que existem outras soluções, outras maneiras de trabalho; de que é possível entregar algo de qualidade com mais facilidade do que entregar com baixa qualidade
  2. Conseguir apoio para mudar: ou você resolve na calada da noite ou consegue que algumas horas gastas nas melhorias
  3. Refactoring, técnicas, metodologias: são necessárias ou você terá muito mais trabalho e não vai compensar e vai desistir
  4. Métricas: é preciso mostrar onde foi a melhoria, o que ela trouxe de benefícios

Próximos passos

Leia o livro indicado no começo do post e acompanhe o blog, vou publicar mais textos sobre o tema. Comentários são bem vindos. Até.

O prestígio do VB

Semana passada fui prestigiado com a menção do meu nome no podcast sem prestígio dos meus amigos, Elemar Jr., Leandro Daniel e Vinicius Quaiato, que cada dia ganha mais prestígio, dias atrás estava em destaque na página de downloads de podcast do iTunes: Voidpodcast ! Este episódio teve como tema “Tecnologias sem prestígio” e fui mencionado quando VB/VB.Net entrou na discussão. Mas será mesmo que esta linguagem não tem prestígio? Então, como diria o Vinicius Senger, esse post é: Pela honra do VB!

A minha história com o VB começou no início dos anos 2000, quando eu ainda trabalhava com projetos de automação predial. Cheguei a programar uma ou outra vez nessa época nas controladoras que utilizávamos porém em uma linguagem totalmente visual, que era um arrastar e soltar de blocos que representavam ventiladores, sensores, motores… Mas a maior parte do meu trabalho foi desenhando esquemas elétricos no AutoCAD, que para quem não conhece,  é o software padrão para desenhos de engenharia 2D e 3D. Com o meu amadurecimento no uso da ferramenta, comecei a sentir a necessidade de automatizar algumas coisas no meu trabalho. Acho que quando se conhece um processo tão profundamente as tarefas ficam tão monótonas que se começa a pensar em como podemos tornar essa tarefa melhor, mais rápida e melhor  ou ainda mais assertiva; e aí estava uma oportunidade escrever código dentro da ferramenta para atingir esses objetivos! Eu sempre gostei da ideia de programar, havia feito um curso de C, mas foi com ênfase em eletrônica, que era minha área na época. O AutoCAD até a versão 14 oferecia LISP, C++, e talvez outras coisas, para programar. Eu tentei estudar LISP (Lost In Stupid Parantheses), mas foi chato pra caramba. Até que na versão 2000, a Autodesk, incluiu o VBA para AutoCAD! Sim, o mesmo VBA que já estava presente no Access, Excel, Word. O VBA me permitiu não só criar macros para blocos de desenho no AutoCAD, como também acessar uma base de dados, criar Forms para entrada de dados, tudo de uma maneira muito simples, até mesmo para alguém sem conhecimentos profundos na área. Eu comecei aí, mas não parei, tive um mentor a época, Felipe Antunes (escreve o blog “E agora DBA”), que me ajudou muito em questões básicas, em entender como funcionava um banco de dados relacional, o que me fez pular do Access para o SQL Server em pouco tempo. Fiz os treinamentos oficiais do VB6, até mesmo o 1016 que envolvia coisas como MTS (na época do Windows NT) e COM+. Adotei a famosa arquitetura WinDNA. E consegui desenvolver um software que solucionava um gap entre a área comercial e a de projetos, agilizando o processo, dando confiabilidade a informação, e por aí vai. Não é preciso dizer o quanto fiquei entusiasmado com isso, já que vim para a área de TI logo em seguida.

Mas não é por conta da minha história com a linguagem que ela tem prestígio para mim e sim por causa da história da própria linguagem. Antes,  o que quer dizer prestígio? Segundo a Wikipedia: “…se referia à ilusão causada aos espectadores pelos truques de um mágico”. “(…) O termo foi usado com este sentido até século XVIII, quando em francês se começou a dar a ‘prestige’ o significado de renome, ascendência, influência, e o prestígio francês nas cortes da Europa traduziu este significado para a nossa lingua”. O uso atual “(…) descreve importância social, alta consideração e sólida reputação”.

No fim da década de 90 e início dos anos 2000 a linguagem que tinha mais influência no mercado, corporações, produtos, … era o Visual Basic, que chegou até a versão 6, trouxe um grande poder ao desenvolvedor, no sentido de tornar simples o desenvolvimento, fazer um acesso a base de dados relacional, criar uma tela gráfica, acessar a API do Windows, desenvolver uma aplicação distribuída, tinha ficado muito mais simples. Em 2005 62% dos programadores usavam uma forma de Visual Basic (Wikipedia), já que nessa época já estavamos entrando na versão 2.0 do VB.Net, mas até hoje o Visual Basic 6 é utilizado em produção, em projetos, até mesmo alguns novos projetos são desenvolvidos com ele! Talvez atualmente o Visual Basic 6 não seja a melhor opção para desenvolver um projeto, mas no início dos anos 2000 era uma das melhores opções, Java ainda era extremamente lento e complexo, de se programar, de se criar um ambiente, o Delphi apesar de prático exigia um pouco mais. O VB dava poder para quem estava começando, dava agilidade. Mas com todo esse poder também vinha uma grande responsabilidade, que era ignorada.  Com a mesma simplicidade que se desenvolvia no VB,  se criava uma grande dívida técnica! Infelizmente o descontrole dos projetos, de arquitetura, de boas práticas não é culpa da linguagem. Não podemos culpar armas, carros, aviões por matar pessoas! Os próprios desenvolvedores foram os culpados por toda essa quantidade de brownfield que se criou na plataforma. E que não venham dizer que foram forçados a isso, que a gerência mandou. Ninguém faz o que não quer!

E hoje em dia, essa fama do VB.Net… Sinceramente não entendo isso! Apesar de hoje o VB.Net ser uma sintaxe para compilar para IL, tanto quanto C# ou qualquer outra linguagem da plataforma, e apesar dos compiladores das duas principais linguagens (VB.Net e C#) serem separados, o código gerado, a IL é praticamente a mesma! Havia uma diferença no início que foi diminuindo com o passar das versões. Até mesmo a quebra de linha sem o uso do caractere underscore foi implementada na versão atual da linguagem. E o inverso aconteceu também, foi implementado no C# parâmetros opcionais, algo que eu nunca achei legal, mesmo no VB6, contribui para o código spaguetthi, quebra a SRP, e por aí vai. Mas de novo, só depende do desenvolvedor em deixar isso acontecer. Acho a sintaxe do VB.Net mais perto da linguagem natural e acho isso legal. Se pensarmos em linguagem de negócio, de domínio, o código fica mais legível, é mais inteligível para um analista de negócios trabalhar junto com um desenvolvedor, isso especificamente em sistemas LOB. A escolha da sintaxe na plataforma .Net não afeta em nada o resultado do desenvolvimento, é mais uma escolha pessoal do que técnica, exetuando-se algumas particularidades.

Por fim, o VB.Net resolve o problema do cliente, que é o objetivo com que qualquer linguagem é criada, fora linguagens teóricas. E isso que é importante, juntamente com o cuidado de se escrever um código limpo.

Desenvolvo na plataforma .Net desde 2004 e tenho usado VB.Net e C#, praticamente meio a meio, e não tenho tido problemas nos meus projetos de precisar de algo que um não ofereça. Talvez hoje o VB não tenha o mesmo apelo que no incío dos anos 2000, hoje temos diversas linguagens maduras no mercado, que cresceram muito rápido e que atendem a nichos específicos. Mas certamente o prestígio do VB esta com toda uma geração de desenvolvedores que cresceu profissionalmente com ele.

#TDC2011

E passou mais uma edição do The Developers Conference, ou melhor #TDC2011, ou ainda @TheDevConf.
Foram 5 dias com 5 trilhas por dia! Ou seja, muita informação e das mais variadas: Java, .Net, PHP, Cloud, NoSQL, Games e até TV Digital, e o que é melhor, um evento de comunidade! Nada, ou quase nada de produto e o que eu vi em alguma palestra é por que tinha foco, não era simplesmente uma palestra de empresa querendo vender algo. O lado ruim é que não dá para participar de tudo. Simplesmente é impossível até mesmo participar de várias coisas que se gostaria e,  além das palestras dá para intercalar network entre a pausa para o café ou no almoço, que esse ano foi no próprio evento(então,não perdíamos tempo de deslocamento até um restaurante); codar alguma coisa com a galera da comunidade ou trocar experiências.

Palestras

Assisti  poucas palestras, mas praticamente todas que eu vi eu gostei. Eu sei que todos deixaram de trabalhar um pouco ou de se divertir. Dedicaram algumas horas para formatar um conteúdo de alto valor e  em contra partida a entrada é de um baixíssimo valor monetário! As empresas deveriam olhar com mais atenção para este tipo de evento, deixar um funcionário participar não vai dar problema no projeto ou pagar a entrada para todo mundo não vai causar problema no fluxo de caixa. O conteúdo vai se pagar. Ao mesmo tempo que pessoas tiveram que fugir de seus trabalhos para poder comparecer, teve uma empresa que contratou um ônibus para levar vários funcionários no evento, muito legal isso!
Assisti palestras muito boas, que me deram novas idéias, que me inspiraram em algumas soluções, a da Yara (@yarasenger) e Vinícius Senger (@vsenger) de como foi abrir a Global Code, novidades como o novo Windows Phone 7 (apresentada em um Mac Book) pelo Vinícius Quaiato (@vquaiato), um manifesto contra métricas absurdas e micro gerenciamento do Giovanni Bassi (@giovannibassi), escovação de bit em Intermediate Language (IL) do .Net, com vários participantes de Java, feita com propriedade pelo Elemar Jr. (@elemarjr), implantação de ALM em uma semana do Vinícius Senger só com ferramentas open source, Continuos Deployment com a Fabiane Nardon (@fabianenardon), lightning talk do Leandro Daniel (@leandronet) sobre Arquitetura evolucionária, e outras mais ou pelo menos pedaços!

Minha palestra

Nesta edição tive o prazer de não só participar como congressista do TDC, mas também como palestrante na trilha de Arquitetura, organizada pelo Vinícius Senger e Giovanni Bassi. Foi a primeira vez que palestrei em um grande evento, a ansiedade até o início da palestra foi grande, bastantes horas de trabalho, no meio do caminho mudei a direção da palestra, até o último momento verifiquei se o slides estavam bons, mas valeu muito a pena! O tema, Brownfield applications, é o que mais está presente no meu trabalho, e poder compartilhar um pouco de experiência, trocar idéias, técnicas é muito bom; ao mesmo tempo se aprende. A maioria dos ouvintes eram da plataforma Java, mas deu para perceber que os problemas são comuns tanto em uma quanto em outra! Por isso é importante essa troca de conhecimento entre comunidades.
No fim do dia aconteceu um bate-papo com os palestrantes das trilhas, o assunto de destaque: frameworks corporativos!

Comunidades

Devido à grande variedade de linguagens, tecnologias e assuntos a variedade de pessoas com quem era possível conversar é marcante nesse evento! Você pode tomar um café com o pessoal de Java ou almoçar com a galera da comunidade de NoSQL. Ser abordado por um dono de empresa a procura de desenvolvedores PHP. Mas um evento de várias comunidades como esse não seria completo se ao menos uma vez rolasse uma discussão (muito saudável, lógico) de rixa entre plataformas. No fim o pessoal acabou indo tirar a prova no código, fomos recebidos no stand da Crafters Studio e SOA|Expert, e o Elemar Jr. topou o desafio de implementar um código em .Net, ali na hora, com vários “PO’s” apontando o que deveria ser feito, opinando, criticando, apesar de a galera ser de outra plataforma; como sempre ele na postura de professor respondeu todas e deixou pessoas de outra plataforma surpresas com os recursos do C#/.Net. No dia seguinte foi a vez do Felipe Rodrigues (@felipero) topar um desafio, criar na hora um aplicativo em Ruby On Rails acessando o MongoDB através do framework MongoID, e lógico detalhando os por quês enquanto codava.



HH, ou Happy Hour

Como não poderia deixar de acontecer todo dia teve HH! Então depois do encerramento diário às 19 horas do evento… o evento continuava em um HH, até 23, 24, … e mais tarde! Muito mais troca de conhecimento e idéias, mas também lugar para diversão. A honra do Clipper, COBOL, DBase, Joinner, VB, Progress, DOS, Norton Command… foi bravamente defendida várias vezes! O saudosismo rolou solto, foi combinado um evento nostálgico, até mesmo montar uma BBS! Até mesmo aniversários foram comemorados lá!

Mais um evento, mais um ano. O TDC ainda tem muito para melhorar, o que é ótimo, por que ano que vem não sabemos o que esperar, a não ser a certeza de que será melhor que este último! Parabéns à organização.


Links:

A Síndrome do Programador Herói

Algumas frases que publiquei semana passada no twitter fizeram algum sucesso. A  idéia veio de vários lugares: juntei com o que ouvi de alguém, com aquele velho e-mail sobre a carreira Y, entre outros episódios da nossa área; mas o problema é real e se chama: Síndrome do Programador Herói (SPH). Provavelmente todos da área de TI com alguns anos de carreira já viram alguém ser acometido pela SPH, alguns são afetados pelo resto da vida, enquantos outros conseguem se libertar ou serem libertos por alguém que lhes dê um chacoalhão. Acontece é que o desenvolvimento de software é um dos segmentos de trabalho mais propícios para adquirir essa síndrome.

A maneira mais fácil de contrair SPH é o programador participar de vários projetos de sucesso, principalmente se ele buscar os desafios, e todos darem extremamente certo! OK, sabemos que todo projeto tem seus problemas, mas muitas vezes os executivos não enxergam esses “problemas”. Para eles é apenas um programador que não consegue chegar no horário, um outro que não tem certificação; mas sempre tem aquele cara que gosta de matar no peito, por mais que isso vá arder no dia seguinte, ele quer comprar latinhas de energético e virar a noite na empresa, lógico que depois de pedir aquela pizza, e codar, codar, codar. O trabalho é gerar linhas de código, centenas delas, talvez milhares; ele vai ser o cara que vai carregar o projeto, o cara que vai dar o sangue… E por aí vai. Esse cara é cumprimentado pelo gerente, vai almoçar com ele, alguns colegas querem ser como ele, “o cara que coda pra baralho”, “o cara ali é o único que sabe como funciona essa regra de negócio”, “ele que sabe como esse framework funciona”.

Apesar da gerência adorar e,  talvez a sua existência seja devido ao modelo capitalista, ainda mais em contratações acordadas por valor/hora, esse tipo de profissional deve ser evitado! A qualquer custo. Parece loucura não apoiar um profissional que dê o sangue pela empresa, mas não é, essa é a atitude mais saudável que alguém poderia tomar em um projeto. O projeto deve ser feito pelo time, o mérito da execução deve ser do time, os bugs são criados pelo time; é muito fácil verificar se isso ocorre, é quando se ouve “nós falhamos na implementação de determinada tarefa”, “nós conseguimos fazer um refactoring e melhorar o código para a implementação de determinada funcionalidade acontecer”, “nós automatizamos os testes de integração”, “nós não vamos conseguir completar as tarefas a tempo para lançar essa release na data pré-determinada”.

Quando o time funciona de maneira homogênea o conhecimento técnico ou de negócio é passado para todos, todos irão saber como agir quando algo der problema, todos vão assumir os problemas, todos vão cooperar.

As frases:

  • “programador ninja = programador mercenário, q usa práticas não ortodoxas, sabotagem, espionagem… veja def.: http://ht.ly/5ejDE”
  • “programador jedi = trabalha com ficção, projetos q de uma galáxia muito distante da nossa, único empregador: LucasArts.Com”
  • “programador highlander = vai detonar todos os seus colegas, única maneira de sobreviver no projeto… afinal: só pode haver um!!”
  • “programador Daileon = resolve o seu problema mas devasta todo o ambiente…”
  • “programador AstroBoy = é bonitinho… mas vc não quer um brinquedo de crianças cuidando do sistema crítico da sua emrpesa…”

O pessoal também criou algumas:

  • @wjat777 Ninja: vem armado até os dentes (varias ferramentas), pode até resolver o problema, mas (cont.)
  • @wjat777 mas tem a capacidade de desaparecer se a situaçao pioara.. normalmente cobra caro!
  • @alistonCarlos Programador Power Ranger: junta com mais quatro pra fazer uma bazuca que mata até formiga!
  • @marcelotozzi e o rockstar?
    • Aí vai Marcelo: “tem twitter e fica falando sobre um monte de coisas e escreve um blog sobre assuntos diversos, até mesmo sobre programação, falando como deve ser a coisa”  … #bazinga, ok? ;)