Páginas

terça-feira, 25 de maio de 2010

O pior é impossível?

Sabemos que hoje a TI é uma das áreas que tem a melhor relação entre salário e tempo de aprendizado / experiência. O que quero dizer é que hoje uma pessoa que tem um mínimo necessário de instrução já consegue trabalhar recebendo um salário razoável. Isso, entre outras coisas, causado pela falta de regulamentação que temos na nossa categoria.

Com isso, várias pessoas que ainda não estão preparadas são atraídas para este ramo, e isso só traz desvantagens, como sistemas mal projetados e codificados. Isso se traduz em dores de cabeça para os demais analistas e programadores. Dou como exemplo a imagem abaixo, que foi tirada da vida real.

Vamos entender o problema que há nesse código.

Temos uma classe X (retirei os nomes e namespaces para evitar que a pessoa fique chateada), que será exposta em um serviço WCF. Podemos perceber isso pois ela é decorada com (ambos!) os atributos Serializable e DataContract. Ou seja, instâncias dessa classe serão trafegadas pela rede, seja através de TCP, HTTP ou qualquer outro binding disponível nesse framework, nas chamadas do serviço.

Agora perceba o que há dentro da classe. Temos membros que são instâncias de classes do ASP.NET (camada de interface da aplicação), como System.Web.UI.Page e HttpSessionState! O que foi feito foi acoplar tipos que não deveriam ser conhecidos na camada de serviços. Se amanhã esse serviço passa a ser consumido por um sistema que é construído em WPF, por que ter esse tipo de objeto envolvido na chamada?

A brilhante idéia que se teve aqui foi para apenas poder capturar informações da interface ASP.NET na camada de serviços, por exemplo o nome do usuário logado através da propriedade User.Identity.Name (na imagem não dá pra ver, mas acreditem, é isso), entre outros. Se há a necessidade disso, porque não trafegar essas informações em uma estrutura própria? Pra que ter esses objetos pesados instanciados sempre?

Nesse ponto, não dá apenas para culpar a pessoa que fez o código, mas principalmente que a colocou para trabalhar com uma tecnologia a qual ele ainda não está preparado. A pessoa pode não ser ruim, atire a primeira pedra quem nunca escreveu uma “pérola de programação”, o que falta é treinamento. Falta da parte de gerência uma visão de que para se efetuar trabalhos de qualidade é necessário investimento em pessoas bem treinadas, que gostem do que fazem e comprometidas.

 Pérola

Obs. Infelizmente isso não se restringe a área de informática. Já vi pessoas formadas em Direito falando “cabeleleiro” e “mendingo”. É um triste retrato da instrução do nosso país.

quarta-feira, 12 de maio de 2010

O que são design patterns?

Design patterns não têm segredos: tratam-se de soluções bem experimentadas e documentadas para problemas comuns. São as boas soluções para problemas que sempre enfrentamos. E esse conceito não está relacionado apenas à TI (aliás, nem começou na TI, começou na engenharia).

Se observarmos, até na natureza existem tais conceitos de patterns. Tomemos como exemplo o vôo das aves. Existe um problema que é o desgaste que uma ave tem ao voar longas distâncias, geralmente em rotas migratórias. Para resolver esse problema, os pássaros voam em grupos, em uma formação “V”: dessa forma, as aves que estão atrás da primeira se aproveitam do vácuo gerado pelo vôo da líder, diminuindo o atrito com o ar e conseqüentemente diminuindo a energia gasta por elas. Quando o primeiro pássaro se cansa, ele vai para o final do grupo, e é substituído. Com isso, o grupo consegue uma autonomia de vôo em média 70% melhor do que se estivessem sozinhos. Este padrão de vôo é utilizado por aeronaves militares e também é muito comum em shows aéreos.

Gansos selvagens

Thunderbolt III

Voltando à TI, temos alguns patterns famosos da Orientação à Objetos, que foram descritos no “Design Patterns Elements of Reusable Object-Oriented Software”. São eles:

  • Creacionais: Abstract Factory, Builder, Factory Method, Prototype e Singleton.
  • Estruturais: Adapter, Bridge, Composite, Decorator, Facade, Flyweight e Proxy.
  • Comportamentais: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method e Visitor.

Vale muito a pena conhecer esses padrões, pois eles são muito úteis quando encaramos determinados problemas. Os patterns que eu marquei em negrito foram os que eu descrevi em artigos da .NET Magazine, que já foram lançados ou que serão lançados em breve.

[]’s

domingo, 9 de maio de 2010

Backup de webmail

Preocupado com a possibilidade de perder as mensagens armazenadas no webmail que uso (Yahoo!), decidi fazer um backup dos meus e-mails.

No entanto, o próprio webmail não dá uma funcionalidade desse tipo (fazer o download das mensagens em algum formato que possa ser lido em qualquer programa de e-mail como o Outlook). Com isso, houve a necessidade de fazer uma “gambiarra”.

Decidi instalar o Mozilla Thunderbird pra baixar todas as minhas mensagens da caixa de entrada através de POP3 (felizmente o Yahoo! dá suporte para isso). Dessa forma, eu baixei todas as minhas mensagens (pra ser sincero, ainda estou baixando, pois é um processo demorado já que o POP3 só baixa o que está na caixa de entrada, e para fazer o backup das mensagens enviadas, por exemplo, estou tendo que movê-las da pasta Enviadas para a Entrada).

Bom, até aí é a metade da solução. Falta exportar essas mensagens em disco, para poder guardar em um DVD de backup.

Eu até poderia, mas não quero guardar os arquivos de armazenamento do próprio Thunderbird (esse arquivo fica em alguma subpasta dentro de C:\Documents and Settings\<usuário>\Dados de aplicativos\Thunderbird\Profiles\), já que tenho receio que só com essa ferramenta é que eu poderia ler as mensagens. Então decidi que as exportaria para disco, em formato EML. O problema é que eu não consigo fazer isso de forma simples no Thunderbird, teria que salvar mensagem por mensagem, e isso demoraria muito tempo.

Por sorte, encontrei um add-in do Thunderbird que faz todo esse trabalho para mim. É o ImportExportTools, e pode ser encontrado em http://www.nic-nac-project.de/~kaosmos/mboximport-en.html. Com ele, é possível importar e exportar os e-mails entre o Thunderbird e qualquer dispositivo de armazenamento (ou seja, qualquer pasta em disco).

image

Com isso, puder gerar esses arquivos em uma pasta local, e agora consigo fazer o backup em DVD. Só um detalhe que eu acharia bem interessante é se esse add-in, quando usada a opção de salvar em formato HTML, também armazenasse os arquivos anexos das minhas mensagens. Com isso, ficaria bem melhor, já que eu não precisaria de nenhum programa para ler os arquivos em formato EML.

Mas, de qualquer maneira, meus e-mails estão salvos de qualquer problema que venha a ocorrer com o serviço gratuito de e-mail do Yahoo! (nunca me deixou na mão, mas vai que um dia deixe…).

Obs. Não sei se existe uma melhor forma pra fazer esse backup, uma forma mais rápida e fácil, de repente um programa já pronto que me poupe todo o trabalho. Se houver, agradeço sugestões!

[]’s