Blog do Andre Fonseca

Já a um tempo desde que fui apresentado a todo o movimento ágil por meio do Guilherme Chapiewski, Alexandre Martins, Evandro Flores… e desde que fui levado a novas tecnologias e linguagens por estes e por outros como Henrique Bastos,  que sempre que conversamos sobre o assunto com o pessoal que ainda não conhece nada sobre o tema, ouço toda vez as mesmas perguntas e frases:  Você usa ágil por ser idealista; você gosta dessas metodologias por ser nerd e gostar desses modismos; Ágil não é para gente que quer ganhar dinheiro? Python é coisa de universidade!  Ruby on Rails é para pequena empresa!

Uma primeira coisa que gostaria de deixar claro: Sou capitalista e gosto de ganhar dinheiro. Não tenho absolutamente nada contra os demais regimes econômicos existentes, nem a políticas, teses sociais e etc.  Sou um cara que acredita no trabalho e que devemos ganhar dinheiro com ele. Só isso.  Sendo assim, como uma empresa,  busco o lucro. E quanto maior minha margem de lucro melhor.

Margem de lucro, quando estudei macro economia na faculdade, em termo simples,  é quanto porcentos de dinheiro que você ganha frente ao custo daquela coisa que você “está vendendo”. De certa forma, vendemos nossas horas de trabalho… de um jeito que prefiro, vendo meu conhecimento para criar software.  Horas soa como operador de máquina. Operário.  Seguindo com o raciocínio,  para maximizarmos nossos “lucros”como desenvolvedores, temos que gerar o maior valor agregado para o nosso cliente com menor esforço possível.

Esforço no nosso caso é arquitetar soluções, criar ambientes, codificar, testar, instalar a solução para o cliente e depois dar a manutenção dele.  Claro que isso pode não aplicar a todos, mas pelo menos algumas das coisa citadas são feitas. Bom, se existir algo que me facilite realizar as tarefas acima e ainda permita que eu gere um alto valor para o cliente, seria sensacional, não ?! É exatamente isso que encontrei a adotar essas “novas” tecnologias (Python e Ruby existem a tanto tempo quanto Java)  e o fato de ser ágil .

Essas linguagens me permitem fazer com menos… Ágil permite eu me livrar de burocracias que não me ajudam e tomam meu precioso tempo.  Enfim, escolhi usar essas coisas pois quero ganhar mais dinheiro com menos esforço. Muitos, com certeza, irão me criticar dizendo que estou fora do ideal da comunidade. Eu gosto de ajudar e contribuir. Faço isso sempre que posso, a questão que o motivo principal que me mostrou valer realmente a pena em aprender coisas novas, investir para me inserir em novas formas de gestão foi o fato de eu ver que isso ajuda a melhorar meu trabalho e a ganhar dinheiro.

Um erro comum das pessoas que entram nessa nova onda é achar que só existe idealismo envolvido que o resto é mal ou desprezível. Dinheiro não é mal, é de fato o que move nosso mundo. Por que não mostrar que ser ágil, usar uma tecnologia aberto para fazer as coisas, usar uma linguagem mais simples, pode ser um meio de aumentar lucro? Pois é exatamente o que acontece.  Usar Git ao invés de CVS ou SourceSafe(exagerei)  é lucro: não pago licença por algo que é muito bom e além disso ganho com recursos que facilitam a vida do time.

Acredito firmemente que é preciso dar um sentido menos utópico as coisas.

Bem era isso… aguardo a opinião de vocês.

Quem lida com desenvolvimento de sistemas o tempo todo, ainda mais quando tem uma certa experiência – ou até é o mais experiente do grupo, sabe que o tempo todo deverá tomar decisões. Decisões estas de natureza diversa: desde uma contratação, uma demissão, quais tecnologias, qual arquitetura, licenças(argh), etc.  Claro, pelo menos no meio que convivo, as decisões de carater mais técnico tendem a ser mais “leves”  e, erroneamente, não é dada a devida importância ou seriedade que o assunto merece. Isso tem impacto direto sobre muitos produtos “estranhos”que acabam sendo entregues que, para o usuário leigo, pode até passar desapercebido porém alguém com perfil mais técnico chega a ser gritante.

Imagine você que seu time está começando um novo projeto. O dono do produto começa a conversar de forma ampla do que ele espera e das interações que ele espera que os usuários terão, etc. Ele aproveita e também fala sobre a quantidade de acesso que ele espera para aquilo, tempos de respostas, etc. Quem é desenvolvedor, assim como eu, nessas horas não consegue escapar de ir já imaginando a arquitetura do projeto, como as coisas vão interagir, etc. Pela experiência que tenho isso pode ser uma armadilha fatal.

Otimizações e arquitetura prematuras, no meu ponto de vista, são uma das maiores fontes de problemas de projetos. Dentro do príncipio Lean (justo necessário) de desenvolvimento, devemos nos ater aos problemas que existem e não aos que existirão. Fazer a coisa de forma a facilitar evoluções sim mas não “dê um passo maior que a perna”. O que vejo são verdadeiro monstros de empilhamento para um requisito de baixo número de usuários, zero de evolução, etc. Um exemplo para facilitar: Imagina que o cliente quer que você faça um site para empresa dele. Esse site será pouco acessado e servirá apenas, num primeiro momento, para ser uma página informativa da empresa. Num futuro, assim que os negócios decolarem, ele irá desenvolver uma mega ferramenta, mas não agora… já vi muito gente fazendo sistemas em mil camadas, com cache, banco de dados oracle mega 3 plus, etc… Sendo que, se fizesse tudo com html estático, funcionaria perfeitamente.

Prefiro que as coisas evoluam organicamente. Isso significa dizer, que a medida da necessidade as coisas vão sendo alteradas para melhor atender. Novamente insisto que também não é para fazer uma parada em html e depois querer com pouco esforço torná-lo dinâmico.  Pense em Darwin: evolução é perpetuação do mais aptos ao ambiente.  Simplificando seria que a medida que nossos sistemas vão crescendo vamos deixando as coisas que funcionam bem dentro daquele contexto de requisitos e vamos alterando ou trocando as coisas contrárias.

Diante de tudo dito acima, fica claro que bom sistemas são aqueles que mudam !!! Não pense que conseguirá fazer uma aplicação mágica que será capaz, depois de  ”pronta”, de se adaptar a todos cenários possíveis. Até porque precisamos de trabalho né . Software não é como um prédio, associação que muitos fizeram e fazem erroneamente . Software está muito mais parecido com algo orgânico que vai crescendo e sofrendo mutações.

Num próximo artigo pretendo trazer a questão do empilhamento e horizontalidade. Essas duas coisinhas que quase ninguém sabe ao certo os seus reais valores e como (e quando) usá-los.

Não é algo que eu faça com certa freqüência mas acredito que a vaga seja boa e interessante para muitos que leêm o blog. A empresa é brasileira e tem como atividade principal um produto de portal. Essa ferramenta de portal é muito interessante e concorre em igualdade com outras existentes no mercado ( Vignette, Websphere Portal, Oracle, etc) .

Mande seu CV para lumisit@lumis.com.br , coloque no corpo do email que viu a vaga no meu blog.

Desenvolvedor Junior (Projeto)

Conhecimentos necessários:

• Estar formado em Ciência de Computação, Engenharia de Computação, Informática ou
  correlatos;
• Ter 6 meses de experiência de desenvolvimento em projetos Web;
• Ter conhecimentos nas tecnologias – PHP, ASP e .NET
• Conhecer os conceitos de orientação a objetos
• Conhecer Infra-estrutura, configuração e manutenção de servidores Apache e IIS

Conhecimentos desejáveis:

• Ter conhecimento da linguagem XML, XSLT, SQL e DHTML;
• Conhecer os bancos de dados: SQL Server 2000/2005, e MySQL.

Habilidade:

1. Transformar projeto em implementação;
2. Escrever código fonte em PHP, ASP e .NET;
3. Avaliar a implementação;
4. Executar os testes;
5. Avaliar a execução dos testes;
6. Depurar problemas no código;
7. Pesquisar soluções tecnológicas;
8. Controlar e cumprir prazos de suas tarefas;
9. Alertar com antecedência sobre problemas;

10.  Comunicar dúvidas ou questões encontradas.

Atividades do Cargo:

Trabalhará alocado Analista/Desenvolvedor, com conhecimento em portais utilizando a plataforma Lumis Portal Suite (ASP). Ter alguma experiência com PHP, ASP e .NET

Estamos trabalhando com pretensão salarial

E dando seguimento a serie sobre algumas coisas interessantes sobre o desenvolvimento, vamos para mais um novo capítulo.  [OFF] São tantas histórias vou acabar escrevendo um romance [/OFF].   Após a repercussão do primeiro artigo de mesmo nome, alguns conhecidos me procuraram para dizer que, existiam outras situações que poderia abordar dentro da série.  Uma dessas situações foi sobre estruturas de equipes de desenvolvimento e  com isso, acabei  me lembrando de uma época,  numa dada empresa, em que tínhamos a figura do revisor de códigos. É isso mesmo que você leu, meu amigo …revisor de código.

O revisor de código é o cara que após você ter implementado toda  a solução, antes de você colocar as sua alterações no CVS  (meu deus, antigo), ele vem e verifica se o seu código está bom, onde bom, significa dentro de um padrão que não está em lugar que não na cabeça dele.  Antes que me apedrejem em praça pública,  sei que nem todos são assim, e que em muitos tinha ou tem, regras de estilo bem claras e até automatizadas através de plugins em suas IDEs.

Revisar o código não é uma atividade ruim. Ter premissas de estilo e formatação é algo interessante pois padroniza e pode facilitar qualquer pessoa, que esteja acostumado com os padrões da empresa, ler o fonte e entender.  Essa preocupação, inclusive,  tem sido tema de discussões muito atuais e serve até de argumento para definir o uso ou não de linguagens ( sendo mais específico, são questões como expressividade, legibilidade, etc – suggar sintaxe) . A questão que eu coloco é isso passar o limite do bom senso e do razoável e se tornar uma ditadura sem direito de questionamento.

A própria situação de ter uma única pessoa responsável por zelar pela qualidade do código para mim já é algo péssimo.

Mas então? Qual é o melhor cenário?  O que pode ser feito, já que eu disse que qualidade e estilo são bons, se ter alguém revisando é péssimo?

Alguém aí, por acaso, disse … Programação em par!?!?!? Bingo!!!   Essa, no meu entender, é um bom caminho.  É bom, pois permite a troca, a interação. É bom, pois permite, que a responsabilidade seja de todos e não somente de uma única pessoa. Tira gargalos ( quem nunca ficou parada esperando o revisor ter tempo para ver e validar a implementação).  O time como um todo decide o que é melhor.

Nesse cenário as chances das coisas serem menos impostas e mais consenso são grandes. Não existe um ponto único e sim diversidade de visões.  O time fica aberto e sempre como abertura para melhorar ou experimentar, desde que todos concordem ou pelo menos seu par, que aquilo traz algum valor.

Observem – bem lembrado por um colega – que nem toquei no fato de revisão de tecnologia, arquitetura.  Na velhas e empoeiradas estruturas de fábrica,  tem casos em que além do revisor, tem ainda o grande e todo poderoso arquiteto que decide quais tabelas, quantas classes, como as classes são, qual linguagem, api, framework, qual papel higiênico, que  todos devem usar.  Para mim isso consegue ser pior que o revisor. Pois ele tolhe a inovação, o salto para frente.  não quero dizer com isso, que devemos fazer de nossos projetos um laboratório de novas linguagens e etc… estou dizendo que se existe algo que venha a facilitar porque não pelo menos olhar o que é …

Novamente transferir essa “responsabilidade ” para o time é a melhor coisa.  Pois se discute. Todos tem voz.  A chance de escolher algo interessante é maior… não fica a cargo de um louco que pode ser um tarado por novidades ou um louco que nunca deixará de usar Java 1.3.1 pois sempre funcionou e “não se mexe em time que está ganhando”.

Bem esse era meu recado… aguardo as opiniões de vocês.

Participo de uma lista de discussão e por estes dias surgiu uma troca de e-mail cujo o assunto final foi a questão da segurança na aplicação.  Dentro do acalorado debate,  apareceram os que são a favor de considerar a segurança na aplicação e outros que acham que isso é um exagero.  Teve até quem disse, que segurança é “manter os funcionários felizes”.

A nossa dependência dos sistemas é cada vez maior. É também cada vez maior a quantidade de informações sobre a nossa pessoa que estão nas “nuvens”.  Diante disso é impossível dizer que a segurança da informação não é um assunto importante.  Não faltam hacker dispostos a roubar nossas senhas, encher nossas caixas de e-mail com spams, nos infectar com algum “vírus” capaz destruir, etc.  O mundo virtual  já foi um lugar mais seguro.

Pensando em nossa aplicações …primeiro, temos que evitar as otimizações prematuras… Vejo muito sistema sendo feito por aí em que o time de desenvolvedores acabam se afastando dos requisitos do cliente e criam verdadeiros monstros  - do ponto de vista de retorno de investimento, manutenção e etc – que não agradam a ninguém. Nisso eu incluo a questão da segurança.  Não pode dar o mesmo peso para segurança para um sistema financeiro e um outro que apenas encurta a Url.

Por isso a discussão é válida desde que a coloquemos dentro do contexto correto.  Isso não significa que jamais devemos pensar em fazer sistemas seguros.  Quero dizer que devemos dosar.   Essa é a mais difícil das tarefas.  Pois muitos podem dizer que o esforço de fazer será o mesmo esforço de fazer muito ( exemplo: o esforço para criptografar os dados do banco é tal que se torna interessante fazer também o trabalho de senhas e esquemas também).

Devemos fazer sistemas para o mundo real. Nele, sempre terá alguém mal intencionado capaz de fazer um ação danosa.  Por isso, backup, proteção de senha, etc fazem parte da discussão de arquitetura da aplicação, mas novamente, tendo o cuidado de dosar evitando os excessos. Um bom começo seria listar quais ações que podem ser tomadas, quantificá-las, qualificá-las (por complexidade,  custo, retorno, etc), e outras coisas afins.  Tendo a lista podemos apresentá-la para o cliente e, uma vez que o assunto é mais técnico,  tentar mostrar os prós e contra de investir nisso para o cliente. No final a decisão é dele.

Agora,  uma coisa que acredito e espero que seja um senso comum,  são os problemas de simples solução que já fazem parte de nosso folclore. Coisas do genêro de SQL Injection, senhas fortes, dados de cpf e afins criptografados, no meu entender,  devem ser tratados dentro do desenvolvimento mesmo que não haja uma anuência clara do cliente. Esses problemas são conhecidos e por muitas vezes, numa discussão de escopo, eles ficam subentendidos.  Ou deixa claro que não irá fazer e explica o motivo e já inclui o esforço nas estimativas.

Questões de diretórios,  permissões de escritas, proteção de arquivos de configurações, esses sim podem ser negociados e eu pessoal acho que deve.  Lembrando de nunca esquecer de achar a dosagem certa. Como dizem alguns farmacêutico: a diferença entre o remédio e o veneno é a dose.

No fim, o famoso bom senso reina absoluto novamente.

Conversando que a gente se entende

Um dos grandes problemas atuais de TI que encontro é a questão da comunicação. Quando esta falha,  tudo falha… mesmo se as outras partes envolvidas estejam “bem feitas”. Sem comunicação, não existe um troca eficiente, a interação entre os membros se perde, há desinformação, entre outros efeitos… sem comunicação não existe possibilidade de time, existe apenas um amontoado de gente trabalhando num mesmo projeto ou atividade.

Antes de mais nada, gostaria de dizer que, quando falo em comunicação,  estou tratando em seu significado mais amplo : comunicação são as conversas, os emails, os quadros de aviso,  as reuniões, os post it na parede… Enfim, ela é tudo que visa a troca de conhecimento ou ideias e informações.  Ao dar bom dia a uma pessoa que trabalha com você, você está se comunicando; ao enviar um mensagem via mensageiros instantâneos (gtalk, msn, yahoo, etc) você está se comunicando.  Muito apenas consideram a parte formal  da comunicação e esquecem que a parte informal é de suma importância.  Se este “bom dia” não acontece, você como líder, pode estar em apuros.

Do pouco que já rodei por aí, já presenciei e participei de diversas situações onde uma comunicação falha, acabou com toda a equipe.  Um dos casos que gosto de citar é de uma empresa onde trabalhei que, o pessoal não tinha uma boa interação e as raras vezes que essa acontecia era para “sacanear”alguém. Isso gerou um desconforto tamanho na equipe, que aos poucos, as pessoas que eram o alvo das brincadeiras ou que não se sentiam confortável com aquilo foram ficando insatisfeitas. Resultado: projeto ruim,  projetos atrasados, etc. Antes que alguém pergunte: “Será possível que um problema pessoal interfira tanto no resultado? Cade o profissionalismo ?”. Não pode esquecer que somos seres humanos e não vulcanos ( momento start trek) … Nossas emoções influenciam diretamente nosso desempenho, ainda mais a nós que somos latinos.

pessoas não conversam

Continuando a história… a comunicação que a principio não tinha nenhuma relação com o desenvolvimento em si, estava causando muitos problemas. Infelizmente não houve solução, as pessoas saíram, e a equipe dissolveu-se.

Bem , se algo que não tem ligação com o dia a dia de projeto já causou um estrago como na história acima, imagine quando falamos de comunicação que fala exatamente do projeto? Se ela for mal feita, o projeto corre sério risco de não dar certo.

Outra história que conto, é de um ex chefe meu que tinha a mania de não expor com clareza o que ele queria, nem explicar de forma clara os requisitos das funcionalidades que eram para ser feitas.  Nas muitas vezes que discuti com ele, exatamente por causa disso, sempre repetia uma frase: “Ainda não sei ler mente, mas quem sabe com o tempo”.  Um requisito mal explicado é pior  ou igual pior que um requisito não dito. Não foram poucas as vezes que o pessoal da equipe acabou implementando funcionalidades incoerentes com o desejado pelo cliente; foi obrigada a refazer tudo por não estar de acordo “como deveria ser” (como se soubessémos por leitura de mente); e por essa estrada o dia a dia seguia.

Mas os problemas não estão somente na parte verbal da comunicação. Acredito, na minha pouca experiência, na maioria  dos casos os grandes problemas estão nas outras comunicações que acabam  esquecidas.  Com a moda de adoção de metodologias ágeis, a questão da comunicação ganhou uma certa importância, mas maior parte dos casos que vejo e ouço de meus amigos, há uma preocupação com a interação verbal, mas esquecem das não verbais (avisos, emails,  alertas, etc) . Pode parecer até uma contrasenso em nossa era, mas parece que estamos cada vez mais nos comunicando pior!  Documentos mais escritos, pouco domínio da lingua, entre outras coisas, dão margem para interpretações equivocadas e com isso perda de tempo por parte do time com implementações incorretas, por exemplo.

afogado em post its

Não sou a favor de um revisor de português para cada empresa, mas sou sinceramente a favor de pessoas que usem bem o meio de comunicação delas.  Não adianta querer escrever um livro para explicar algo por email, nem um frase.  Tem que se dosar, e procura tirar o melhor de cada. Além disso, essa comunicação não verbal, tem que ser intuitiva, leve, fluidica e permitir uma interação entre a mensagem e o espectador.  Gramática correta, ortografica correta, coerencia e coesão,  sintaxe … tudo isso facilita a leitura e deixa a coisa direta e clara.  Canso de ver aberrações em emails de pessoas de cargos de relevancia que no final acabam indo para lixeiras contendo um aviso importante por erros de escrita grosseiros ( erros de uso de “mim”, “amostrar” ao invés de mostrar, falta de pontuação, estrangerismo em excesso – os jobs file executam em multthreading com forks de flocks vibration poles – e por ai vai ). Fazer o simples, escrever simples, “famoso feijão com arroz”, funciona na maioria dos casos.

Por isso que quadros de post its podem ser excelentes ferramentas, mas cuidado para não abusar da coisa.  Ter a preocupação de pensar nas cores, letras, tamanho de fonte,  são coisa extremamentes válidas e garante um bom retorno no objetivo de comunicar, porém isso sempre fica num segundo plano e na maioria dos casos ignorado.

Bem amigos, enquanto não tivermos evoluído o suficiente para termos telepatia e ler mentes, ou algo parecido, vamos depender, e muito, da comunicação.  Por isso trate-a com carinho em seus projetos e dedique um tempo para trabalhá-la de forma a ser a melhor coisa o possível e verá que os ganhos vão pagar cada sacrificio feito nesse sentido.

Por um motivo que prometo explicar depois, tive que criar uma api para fazer o mapeamento de objeto-relacional para um sistema em Csharp que estamos desenvolvendo.  Como não gosto de reinventar a roda, parti para ver como os frameworks mais usados fazem isso e procurei fazer uma implementação light do que eu vi. Para título de curiosidade me baseiei em Hibernate,  Linq, etc.

O primeiro passo foi determinarmos com o faríamos a questão do mapeamento : para tanto resolvi partir do que hoje é feito pelo hibernate. Dentro do hibernate, simplificando muito o seu funcionamento, você tem um configuração que diz qual campo faz referencia a qual atributo (ou propriedade), qual tabela, as relações, etc.  O hibernate então ao receber o objeto para persistir, por exemplo, pega este dados, monta a query (insert,delete, update, select) e faz a operação. Como disse antes a idéia foi fazer algo light, sendo assim, optamos apenas por mapear os campos, tabela e objetos e não sua relações (com isso eliminamos muita complexidade). Sendo assim, nosso objetos deveriam apenas “saber” qual tabela e colunas a serem mapeadas.

O segundo desafio foi definirmos como iríamos fazer esse mapeamento :  usaríamos um xml, um arquivo de propriedades, base de registro, e por ai seguimos. Após muita discussão vimos que o usuário de nossa api de persistencia seria um outro programador, por isso, teríamos que fazer algo que facilitasse a vida deste cara. Foi aí que decidimos usar Atributos (o mesmo que anotações em Java). Para minha surpresa, criar atributos customizados em Csharp é algo realmente simples (veja o post que escrevi sobre com dicas de como fazer – clique aqui)

Sei que minhas próximas palavras vão soar estranhas para quem não curte codificar como eu, mas :  Não é que a coisa ficou bonita ! A implementação ficou fácil e tudo concentrado na classe sem necessidade de xmls, arquivos externos, problemas de atualização de base de registro, etc.

O meio do caminho – a transformação dos dados dos objetos para relacional e vice versa – foi toda feita com a api de Reflection do .NET. Ela é bastante poderosa, porém com inúmeras diferenças para quem já está acostumado com o Java.  Mas insisto, ela é bem poderosa e interessante.

Ao usar Reflection e rodar nossos testes (isso mesmo estamos desenvolvendo com o TDD – desenvolvimento orientados por teste, escrevemos os testes antes e depois vamos implementando), vimos que ocorria um erro de conversão:  O sistema dizia que não era capaz de converter um valor System.Decimal para System.Int32.

Cabe uma explicação ai: em .NET, ao acessar uma base de dados, para percorres o resultado de uma query você tem um objeto DataReader. Esse objeto é como um mapa dos valores da linha.  Para ele, os valores numéricos ficam mapeados como Decimal e por isso o erro.

A solução achei graças ao Google : basta usar a seguinte linha de código e todos os meus problema sumiram:

O segredo da linha acima é de usar System.Convert.ChangeType . Ele se encarregará de fazer a conversão correta. Como argumento este metodo tem : valor a ser convertido, tipo para qual será convertido o valor.
Bem essa foi a minha aventura das últimas semanas. Achei legal compartilhar pelas dificuldades e de como fizemos para chegar a solução final.