POG Complete

terça-feira, 20 de novembro de 2007

O desconhecimento da linguagem

Dos perigos que ameaçam o programador, nenhum é tão sutil quanto a ignorância a respeito do seu meio de expressão: a linguagem. Claro que não estou falando do bom e velho Português, e sim dos cê-xarp, do vebê, javas da vida.

É uma tarefa inglória ter que programar em outra linguagem que não seja aquela com a qual você tanto se acostumou e se afeiçoou. É quase como acordar em outro país e ter que se virar para não morrer de fome no meio de outra língua, outra cultura, outros costumes. Claro que nenhuma nação vai ser igual à sua. Se são mais "desenvolvidas", ficam te olhando feio, esperando você cometer algum errinho para te discriminar. Se são mais "atrasadas", você se sente indigno de ter que colocar suas patinhas na lama pra trabalhar. (Imagine se o PHP fosse um país, por exemplo.)

Você sabe que é mais fácil xingar meio mundo do que tentar aprender alguma coisa, pois na verdade o que você mais quer é acabar logo o serviço e esquecer aquela sintaxe maldita o mais rápido possível. Afinal, não existe denominador comum entre as linguagens*. O significado de um "if" pode variar enormemente entre uma e outra. Loops? Operadores? Cada uma tem os seus, não adianta misturar, e é perda de tempo aprender tudo.

E se você vai ter que abandonar por um tempo seu super IDE modelo 2008 para fazer uma rotininha em JavaScript, você pode despejar sua raiva e criar o pior script possível, desde que funcione conforme a especificação, e ainda justificar tudo dizendo que não conhece essa linguagem e precisava fazer a coisa rápido. Ninguém vai poder falar nada. JavaScript é pra condenado, ninguém vai te culpar por não saber programar em uma linguagem assim.


*Exceto strings. Strings são o aminoácido do desenvolvimento de sistemas.

segunda-feira, 12 de novembro de 2007

Ctrl+C, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V

O crescimento exponencial na capacidade dos computadores permitiu progressos, digamos, assustadores nos costumes de desenvolvimento de sistemas. Espaço em disco, memória e processador estão aí para serem usados e abusados sem dó. Qualquer coisa, um pulo na Santa Ifigênia ou no Stand Center resolve. Ou, se você é riquinho, liga na Dell.

Portanto, não é nenhuma surpresa quando alguém abre um projeto no seu IDE favorito e, ao estudar o código-fonte, percebe uma sucessão de padrões estampados nas milhares de linhas. Padrões que se reproduzem de forma precisa enquanto se mantém pressionada a tecla Page Down. É o resultado da técnica copy+paste: livre da preocupação com o tamanho do código, o programador se preocupa em melhorar sua produtividade, reaproveitando trechos de programas. Em questão de minutos um grande sistema é construído, liberando horas que seriam tediosamente gastas com análises, arquiteturas, normalizações, desacoplamentos...

Há quem ache ruim e reclame da dificuldade de manutenção de um sistema feito desse jeito. Elitistas frustrados! Manutenção só é ruim quando se cobra pouco.

Além do mais, esse negócio de deixar o código todo coeso, arrumado e limpinho é coisa de metrossexual.

domingo, 11 de novembro de 2007

MãeJoanaState

Pode chocar algumas pessoas, mas criar uma aplicação web alguns anos atrás era muito difícil. Você tinha que aprender a mexer com coisas estranhas como HTTP, HTML, Javascript... tudo complicado demais.

Fazer uma simples aplicação de cadastro (cadastro é sempre simples!) com validação nos campos era uma tarefa árdua. Dizia-se que o comportamento da web era stateless. Mas se um simples cadastro (com validação!) precisa de que sejam mantidos alguns dados entre cada chamada, como fazer? Isso foi um paradoxo que cada nova "plataforma" e "framework" procurava resolver de alguma forma.

Com o passar do tempo, a dura e fria rocha do HTTP foi coberta de camadas e camadas de materiais mais facinhos de se trabalhar, até chegarmos ao estágio atual. O paradoxo do comportamento stateless é uma coisa superada. Os frameworks modernos dão suporte a vários métodos de gerenciamento de sessão e de estado. Considere por exemplo o ASP.NET e seu objeto ViewState. Quer coisa mais produtiva que isso?

Se antes a gente precisava programar na raça o carregamento de dados em campos ou, pior, tabelas em uma página, pegando informações a partir das variáveis de HTTP (ahn?) e fazendo consultas ao banco de dados, hoje basta ir jogando coisas na ViewState e tudo vai ficar bem.

O framework se vira para suportar tudo. A ViewState é robusta. Você pode jogar um DataSet dentro dela e automagicamente ele se perpetuará para ser usado quando for preciso. Se para isso tudo o DataSet tem que ser serializado em string XML, codificado em Base64 e transmitido entre o servidor e o browser dentro de um campo hidden, é um mero detalhe que nenhum desenvolvedor de bom senso precisa saber.

Pega mal conhecer essas coisas. São pra quem ficou parado lá atrás, nos tempos da web a vapor.

quarta-feira, 7 de novembro de 2007

A inquebrável corrente

Você conhece bem a situação. Projeto atrasado, um monte de erro aparecendo, você não dormiu a noite passada e tá todo mundo te olhando de cara feia, pois aquele check-in que você fez, hmm, fodeu todo o módulo de Controles/Unidades.

A última mudança que você fez no C/U era pra fazer um cálculo complicado de média ponderada, que você teve que buscar na internet pois não dava tempo de entender aquele negócio de multiplicar pelos pesos e depois somar. Ou era somar e multiplicar pelos pesos? Te deram a dica e dois segundos depois, google, wikipedia, pronto, algoritmo de média ponderada em VB. Tá na mão.

Agora começaram a usar e aparecem erros que você nunca viu na vida. OverflowException. CastException. NaN. NaN??? "No teste tava funcionando!" Argumento inválido, meu caro. Corrige essa merda agora!

Você se lembra das strings. A string é sua amiga, nunca te deixa na mão. Aí você varre tudo, não deixa uma variável sequer sem um .toString(), e põe um try/catch nos trechos mais cabeludos para garantir. O C/U agora está sob efeito de sedativos, calminho, calminho. Venha o que vier, o método ExecuteMediaPonderada() vai retornar, no máximo, um inofensivo "0". Entre aspas, claro.

No fim do dia, você percebe que esse negócio de entender e corrigir problema é pra gente fraquinha. Você, não. Você domina as strings. Você manda no computador e ele obedece.

Os mistérios do tempo

O tempo é uma fonte inesgotável de debates filosóficos e científicos. Durante milênios, muitos pensadores não fizeram outra coisa senão, digamos, gastar seus tempos para entender a natureza daquilo que transforma futuro em passado.

Na informática não podia ser diferente. O tempo é também uma puta fonte de indagações para o profissional de sistemas. Mas as preocupações não têm nada de abstrato. Muitas vezes os problemas são simples, como na época do famigerado bug do milênio (dois dígitos a mais, aff). E outras vezes são complicados, por exemplo: obter um valor DateTime em uma telinha e gravá-lo em banco de dados. Equipes inteiras são postas em alerta quando um 12 de outubro subitamente vira 10 de dezembro. E na minha máquina funciona, dizem alguns. São os mistérios inescrutáveis do tempo.

Dizem que se você alterar o CultureInfo, formatar a data em padrão ISO, chamar ToString() e cruzar os dedos quando o usuário clicar no 'Salvar', tudo vai dar certo. Mas não tenho certeza.

É muito difícil prever o comportamento de uma coisa que nem os filósofos entendem direito.

Help > About...

Claro que depois da splash sempre tem o About. É de lei, pra ficar uma coisa super profissional. Importante na hora em que alguém precisa ver o número de série ou as versões dos componentes instalados. (E o orgulho do programador quando os numerinhos aparecem na tela! Já imaginando a hora de dizer 'oh me desculpe sr Cliente, mas esse módulo só roda ops funciona a partir da versão 2.0.2.5b e aqui no About está indicando 2.0.2.3'.) Sem contar o easter egg. Com os nomes de toda a equipe e de seus animais de estimação.

Desculpa. Viajei e esqueci de postar o que devia. O que vou colocar no About... bom... ah quem sou eu? Eu sou um gerente (júnior) de desenvolvimento. Alcancei esse distinto degrau depois de muito ralar no desenvolvimento de sistemas. Quero dizer, não foi nada sofrido porque na verdade eu gosto muito dessa atividade, sabe. Ralei mesmo foi com tecnologias podres, colegas sem salvação, bancos de dados zuados, projetos falidos, crashes do Visual Studio... a lista é longa. O blog talvez seja bom para registrar esses fatos ridículos do dia-a-dia.

Eu prefiro linguagens com ponto-e-vírgula; ignoro linguagens com 'Basic' no nome; e não entendo a existência do PHP. Não tenho posição religiosa em tecnologia, não torço pra Bill Gates, Linux, Java, Oracle, Open Source, Macintosh ou Windows Vista (óbvio). Prefiro perder tempo lendo uns livros aí.

O nome do blog é um trocadilho com o título do clássico de Steve McConnel, "Code Complete". Eu não li esse livro mas recomendo. Agilemente falando, algo está "code complete" quando estiver, tchananan, implementado inteirinho! Desde a interface até a regra de negócio. Mas quando a regra do negócio é apenas fazer de conta que está tudo funcionando com sucesso, à base de try/catch, eu penso que está "POG complete". É isso, pode rir agora.

Clique OK.

Splash screen

Então, este aqui é o meu blog. Aqui só vai ter absurdos da programação de computador. Pra entendedor júnior, POG significa "programação orientada a gambiarra". Mas claro, você não é júnior, já tem 9 meses de experiência em cê-xarp, e sabe que POGs abundam everywhere, tanto na informática quanto fora dela. Menos no seu código, claro.

Este post aqui é o meu splash screen, que é sempre a primeira tela a ficar pronta. Menos mal. Pelo menos já tem o que mostrar! Não é muito, mas prometo que nos próximos dias vai ter mais coisas para se ver. É que estávamos trabalhando na arquitetura, no banco de dados, sabe como é, um trabalho que não tem visibilidade mesmo. Mas garanto que vai dar tudo certo e este projeto nasceu para ser um sucesso.