Olá.

     O Mauro Sant'Anna apresentou dois webcasts sobre componentes de arquiteturas multi-camadas. Muito interessantes, o primeiro webcast tem foco teórico e o segundo é bem mais prático.

     Nas palavras do Mauro:

Nesta apresentação uso como base o esquema colorido do documento “Designing Application and Services” do site Paterns & Practices e digo o que significa cada caixinha, quais as possibilidade de organização (1 a 4 camadas), questões de que tipo de dados são tocados entre camadas, de quebra lógica e física, serialização, segurança e aderência a SOA. Ela é baseada em experiência prática e bastante temperada pelas minhas opiniões a respeito de bibliotecas ORM, análise orientada a objetos, OOP remota e outros tópicos.

     Baixei, assisti, são bem curtos, um pouco menos de uma hora cada um. Às vezes é polêmico, mas certamente vale a pena.

     Parte 1 Parte 2

     Você vai precisar ter um ID do Passport para prosseguir (se você tem uma conta do hotmail ou msn já é suficiente).

Abraços.

Olá.

     Region é um recurso da maioria das linguagens modernas de programação que permite ao programador agrupar trechos do código-fonte utilizando um nome ou frase (embora aqui eu esteja citando o C# mais claramente). Não tem efeito nenhum efeito sobre compilação ou sobre a lógica/performance do código-fonte em si, mas sim, permite melhorar sua legilibidade.

     Ora, é muito bom quando você acessa um código-fonte e a leitura do mesmo está dividida em blocos. Facilita muito a leitura.

     Por outro lado, algumas vezes o programador perde a noção da quantidade de regions a utilizar no código e acaba super-utilizando este recurso. O resultado final é um código-fonte com leitura muito quebrada e, por causa disso, difícil de ler. A cada X linhas o pensamento é interrompido por um Region que necessita ser expandido para que a leitura continue.

     No exemplo abaixo, criei uma classe para demonstrar como o abuso na utilização de Region dificulta a leitura do código-fonte. Chega a ser engraçado, você abre o código-fonte e encontra algo inocente como exibido na imagem abaixo:

     E então você começa a expandir region após region até exibir todo o código-fonte e no final se depara com um código-fonte como definido nessa imagem. A proporção de regions utilizadas supera em muito a complexidade do código-fonte: a classe contém um construtor padrão, uma propriedade, um método privado e outro público, porém, há não menos que 20 regions definidas. Exagero é pouco, certo?

     Novamente, o uso das regions é bem-vindo desde que sua utilização sirva para melhorar a leitura do código-fonte. Agrupar trechos comuns do código, utilizando poucas mas bem posicionadas regions torna a leitura "agradável". Dividir excessivamente o código-fonte utilizando muitas regions quebra a sequência/fluência de leitura. Evite.

Eduardo.

Olá.

     Qualquer código-fonte é passível de revisão, consertos e melhorias. Na maioria das vezes, na minha opinião, estas alterações (ou refatorações, se preferir) são auto-contidas e transparentes, em outras vezes isto não é possível. Por exemplo, quando um método tem seu comportamento interno alterado porém tanto sua assinatura quanto seu retorno continuam com os mesmos tipos, pode-se dizer que esta alteração foi transparente pois quaisquer outras classes/métodos que o consumam não são afetados.

     Em outras vezes pode ser necessário modificar a assinatura do método ou a sua saída. Os motivos variam, claro, mas pode acontecer de se estar melhorando a legilibidade do método, ou eliminando "números mágicos" ou simplesmente porque a mesma funcionalidade do método já existe em outra classe. Por exemplo, durante a revisão de um código-fonte encontra-se um  método como o abaixo:
     public string InserirUsuario(string nome, int idade, int tipoDeSexo) {...}

     O parâmetro tipoDeSexo é do tipo inteiro mas quais números inteiros recebe? Se não houver documentação, talvez seja necessário ler o código para descobrir que 1 é igual a masculino e 2 é igual a feminino. Por outro lado, informações deste tipo são melhores representadas por enumerações. Partindo daí há duas possibilidades:

1. Criar uma enumeração, alterar a assinatura do método trocando o parâmetro inteiro tipoDeSexo pela enumeração e alterar a chamada do método em todos os locais do código-fonte;
2. Criar uma enumeração, criar um novo método com a assinatura refeita, mover a implementação do primeiro método pro segundo e marcar o primeiro método como "obsoleto".

     A implementação do item 2 ficaria mais ou menos assim:
     public enum TiposDeSexo {Masculino = 1, Feminino = 2}

     [Obsolete("Esta versão do método está obsoleta. Utilize a 2a versão deste método.")]
     public string InserirUsuario(string nome, int idade, int tipoDeSexo) { return(InserirUsuario(nome, idade, (TiposDeSexo)tipoDeSexo))); }

     public string InserirUsuario(string nome, int idade, TiposDeSexo tipoDeSexo) { ... }

     A vantagem de se criar um novo método é não ter que alterar todo o código-fonte buscando todos os locais que chamam o método InserirUsuario passando um inteiro para o parâmetro tipoDeSexo. Isto poderá ser feito aos poucos e cada caso de uma vez. Mantem-se a compatibilidade com todo o código, o que é bom. Ao mesmo tempo, o método foi marcado como "obsoleto". Isto significa que em todas as vezes que alguém precisar utilizar o método InserirUsuario será notificado de que a 1a versão do método está antiga e não deveria mais ser utilizada. No futuro, depois que todas as chamadas para a 1a versão do método tiverem sido alteradas para a 2a, o método em si pode ser removido do código-fonte. Muito bom, certo?

     Dei toda essa volta pra informar que a MS possui um site que informa uma lista de todas as APIs do .NET Framework 2.0 que foram marcadas como obsoletas. Esta página informa também as APIs substitutas que você pode utilizar e, principalmente, quais APIs não possuem substitutas (ou seja, a API "estacionou" em termos de evolução de código).

     Ainda que uma API esteja marcada com o atributo "[Obsolete]" você é livre para continuar utilizando. O único inconveniente é que o compilador gera avisos ("warnings") para cada linha de código que utilizar uma API obsoleta. Dependendo da quantidade de ocorrências a lista pode encher a paciência.

     O site é este aqui. É possível visualizar a listagem por assembly (dll) ou por namespace (o que é mais legal).

Eduardo.

Olá.

     Comecei minha carreira faz nove anos. De início, em 1999, fui estagiário numa multinacional e dei meus primeiros passos em atendimento, suporte e relacionamento com as pessoas. Depois de certo tempo, já como funcionário, desenvolvi meu primeiro projeto ASP.NET, modificando o portal IBuySpy (lembra?) para rodar numa intranet, lá pelos idos de 2003.

     Foi uma experiência enriquecedora ainda mais quando o projeto começou a quebrar o SQL Server 2000. Sério, havia um procedimento de carga de dados seguido de um procedimento de cálculos de estatísticas que, invariavelmente, travava a instância do SQL Server. Na época, aproveitando o contrato de suporte com a MS Corp (dado que a matriz da empresa mantinha um contrato guarda-chuva ou algo assim), foi designado um profissional da MS especialista em banco de dados para lidar com o problema, o Robert.

     Ele não falava português (assim como eu não falava inglês) então obviamente a comunicação fluía de maneira excelente. Felizmente havia um administrador da área de infra (Oi, Leonardo!) que falava ambos os idiomas e foi o que nos salvou. :) Duas semanas após avaliar o servidor e levar uma cópia do banco de dados o Robert comunicou que havia um problema no SQL Server 2000 comunicando com o ADO.NET e que seria corrigido num hotfix a ser liberado pela MS Corp. Nice! Meu primeiro projeto com ASP.NET e já consegui um hotfix da MS.

     Em 2004 eu fui trabalhar para uma outra multinacional. É uma potência em termos de mídia digital e está por trás de grandes projetos, os quais, infelizmente não posso divulgar. Não, não é a Real... Lá eu realmente me tornei um desenvolvedor e aprendi muito. Aplicações ASP.NET, serviços Windows, XML, JavaScript, fora o período em que fui "coordenador".

     Foi um tempo de grande aprendizado mesmo. Se você tiver sorte irá encontrar uma empresa na qual você tenha de lidar com desenvolvimento, partes de design, configurações de servidores, integrações com sistemas externos, enfim, uma empresa na qual você será desafiado a crescer profissionalmente em várias frentes e não somente desenvolvimento de código.

     Em 2007 saí para ser consultor no meu empregador atual, desenvolvendo para uma empresa do governo. Não vou comentar nada pois ainda é recente, porém, semana que vem cumpro o final do meu aviso prévio (sim, você leu bem, consultor cumprindo aviso prévio) e mudarei de trabalho pela 4a vez em nove anos (foram cinco anos e meio na 1a, dois anos e meio na 2a e um ano na atual). Eu não esperava mudar de trabalho tão cedo pois tenho a tendência de ficar um bom tempo em cada um deles mas, surgiu uma oportunidade para realizar um sonho antigo: trabalhar para a minha própria empresa. Não a Mutambal (oh!) mas uma empresa da qual também sou sócio.

     O meu ex-gerente está criando sua própria empresa (também um objetivo antigo dele) e me convidou para fazer parte do quadro de sócios. No futuro eu vou comentar mais sobre isto e especialmente sobre os detalhes envolvidos na criação de uma nova empresa. Existem muitos desafios a serem vencidos antes mesmo de se pisar no escritório no dia da inauguração e acredito que valerão alguns bons posts. Vou cuidar da área de desenvolvimento e espero montar um time excelente (anúncio de vagas aqui, logo, logo). Já temos projetos, já temos clientes, e já temos um sistema fantástico a ser desenvolvido.

     Particularmente o meu objetivo em ser consultor sempre foi o de acumular patrimônio suficiente para poder criar a minha própria empresa de software (não necessariamente consultoria). Óbvio que esse processo iria levar anos, claro, e é por isso que foi uma grata surpresa ter sido convidado. Foi um belo atalho para mim.

     Por fim, eu queria comentar sobre a importância de saber sair bem de uma empresa. Eu sempre tomei o cuidado pessoal / profissional de sair honesta e dignamente dos meus trabalhos. Nunca briguei, nunca levantei e fui embora, nunca deixei a equipe com um projeto no meio (ou pelo menos sem cumprir algum tipo de milestone) e sempre mantive bom relacionamento com as pessoas.

     Você não sabe o que o futuro reserva. Sair de uma empresa intempestivamente: não cumprindo nenhum tipo de aviso prévio ("fico até sexta", na quarta-feira à tarde não vale); discutindo com seu chefe/equipe; deixando claro que seu chefe é um idiota e a empresa é uma m*rda ou tomando atitudes covardes (como sumir do mapa) certamente irão diminuir a validade da sua carreira. Você pode tomar um golpe do destino, querer voltar, e encontrar as portas fechadas. É muito triste quando isso acontece.

     Na área de desenvolvimento é comum ouvir que as vagas de trabalho são "urgentes" ou "de início imediato". Recrutadores frequêntemente causam angústia nos candidatos por dar a entender que se o candidato não puder começar no dia seguinte perderá a vaga. Se a empresa não pode esperá-lo por, não sei, duas semanas, significa normalmente que você está sendo convocado para apagar um incêndio ou para ajudar a apagar um e este não é exatamente um bom jeito de começar num trabalho novo...

Eduardo.

Olá.

     Direto ao ponto: um número mágico é todo número literal que possui um significado não esclarecido ou não documentado no código. É aquele número que você encontra em fórmulas, cálculos, instruções condicionais e métodos e que não é possível inferir o seu significado.

     Imagine encontrar um trecho de código assim:
     imposto = valorMovimentado * 0.38

     O que significa esse 0.38 na expressão? Você poderia chutar que seria a CPMF mas seria melhor que o código estivesse assim:
     constanteCPMF = 0.38
     imposto = valorMovimentado * constanteCPMF

     Vê a diferença? Ao invés de utilizar números diretamente em suas expressões é mais saudável criar constantes para representá-los e utilizá-las nas expressões. O código fica mais legível e mais prático para sofrer manutenções.

     Além disso, imagine se o valor 0.38 fosse utilizado em 30 lugares diferentes? Caso o valor mudasse para 0.35 seria necessário alterar todos os 30 lugares. Porém, caso tivesse sido utilizado uma constante, bastaria alterar a constante num único lugar e todos os outros 30 estariam automaticamente adequados. Muito melhor, certo?

     Martin Fowler, no livro "Refatoração: Aperfeiçoando o Projeto de Código Existente", chama esse padrão de "Substituir número mágico por constante simbólica". Este livro é fonte muito recomendável para o aprendizado de padrões de refatoração como o que mostrei acima. É um excelente guia de consulta também.

     O autor mantém um site na internet (em inglês) sobre refactoring que é referência para o assunto: site Refactoring.

     Espero que seja útil.

Eduardo.

Olá.

     Dogfood é a prática de consumir os produtos desenvolvidos pela empresa, ou seja, fazer com que os próprios produtos desenvolvidos (ainda e principalmente nos estágios iniciais) sejam utilizados pelas pessoas que compõem a empresa. Por exemplo, se a empresa desenvolve um sistema de CRM, seria esperado que seu relacionamento com os clientes seja gerenciado por essa ferramenta.

     O termo origina-se de uma frase maior: "Eating your own dogfood" que, até onde eu sei, foi cunhada dentro da MS num esforço para que a qualidade dos produtos desenvolvidos fosse melhorada fazendo com que todos na empresa utilizassem os produtos desenvolvidos logo de início.

     A idéia é bem "simples": o quanto antes se começar a receber feedback sobre o produto, melhor. Para quê aguardar o produto atingir massa crítica e então lançá-lo para o mundo externo para testes quando se pode fazer com que a própria empresa, desde o começo do produto, teste-o?

     Ora, o feedback interno obtido para um produto é muito mais "macio" e gerenciável. Não é necessário ter 100% das funcionalidades do produto prontas para que ele possa ser lançado para consumo interno. Pode-se dividi-lo em fases, por exemplo, tendo partes do produto disponíveis para uso e outras partes não disponíveis. O ponto crítico da abordagem é liberar o produto para receber feedback o mais cedo possível.

     Não é saudável esperar feedback somente de clientes (ainda mais se for solicitado somente na fase final do projeto).

     Dentro da realidade de cada empresa seus produtos devem ser aproveitados e utilizados pela própria empresa. No mínimo, demonstra confiança no produto. De que adianta a empresa ter um super-hiper-mega sistema de CRM se os contatos com os clientes são gerenciados na base do post-it? Ou vender um sistema de gerenciamento de conteúdo feito com ASP.NET Ajax, .NET Framework 3.5, SQL Server 200X, se o site da empresa roda páginas .ASP num layout, digamos, estático?

     Resumindo, ao desenvolver um produto, se possível, utilize a própria empresa como alpha ou beta tester e ganhe qualidade gerenciando o feedback interno. Quando chegar perto da data de liberação o produto estará consideravelmente melhor. E os clientes agradecerão.

Eduardo.

Olá.

     É clássico. Você navega, navega e navega até encontrar um bom artigo sobre um assunto de seu interesse. Encontrando-o, você decide imprimí-lo, pois ainda é muito mais conveniente / confortável ler longos textos no papel e não na tela. Ainda mais quando o site abusa da exibição de menus, banners, popup e anúncios em geral. Veja um exemplo de um "abuso" na imagem abaixo:

     Daí você decide imprimir a página. E é aí que a coisa realmente fica feia porque todos aqueles menus, banners, anúncios também são impressos, tornando a leitura do conteúdo da página impressa igualmente desestimulante e difícil de ler. Fica aquele enorme banner do Google dividindo o artigo no meio, quebrando o raciocínio e o fluxo da leitura...

     Tudo bem que se queira fazer algum dinheiro com venda de banners ou exibição de anúncios do Google AdSense, contudo, não é raro acessar um site que tenha 60%, 70% de sua área coberta com anúncios, e aquele pisca-pisca incessante, tornando muito difícil a leitura do conteúdo "real" que ele possui.

     Todos os sites sérios, independente da quantidade de anúncios que tenham, utilizam-se de algum expediente para que seu conteúdo seja impresso corretamente. Há algumas formas de garantir que a impressão da página não contenha os elementos que "atrapalham" a leitura do texto pois, no final das contas, permitir que um menu seja impresso, ou 10 anúncios, não tem o menor aspecto prático. Ninguém vai conseguir clicar no papel pra visitar o site do anunciante, certo? (Certo??)

     Num site sério, com um mínimo de cuidado com os seus visitantes, a mesma página de exemplo acima, seria impressa no papel:

     Bem melhor, de acordo? Na segunda metade deste post eu comentarei sobre uma técnica utilizada para melhorar a qualidade da impressão de páginas. Sua implementação é muito simples e garante visitantes mais felizes. Basicamente a técnica consiste em identificar quando a página está sendo impressa e, via arquivos CSS, esconder os elementos que não precisam ser impressos ou não tem relevância.

Esconde-esconde com arquivos CSS

     A técnica consiste em implementar dois arquivos de estilos CSS para a página e via atributo media determinar que um arquivo de estilos seja utilizado para a visualização da página e que o outro seja utilizado para a impressão da página.

     Normalmente os arquivos de estilos CSS ficam definidos na página na seção HEAD/HEAD em elementos LINK. Veja um exemplo:

     O atributo media = screen determina que se a página for exibida na tela deverá ser utilizado o arquivo de estilos web.css. Já o atributo media = print determina que se a página for impressa deverá ser utilizado o arquivo de estilos print.css.

     Os dois arquivos são essencialmente iguais. A diferença está em que o arquivo print.css, para cada elemento (div, imagem, tabela, etc) que não deva ser impresso, determina o estilo "display : none". Quando o estilo "display : none;" é aplicado a um elemento da página ele não é exibido. Então, quando a página é impressa, o browser a renderiza utilizando o arquivo print.css e este, por sua vez, esconde os elementos que não devam ser impressos.

     Simples assim.

     Espero que seja útil.

Eduardo.