Talvez, num futuro próximo, será possível copiar e colar diretamente do Word, por exemplo, para o seu editor de texto web e ele fará o trabalho.

É verdade que se você usasse algo como o Writer, você teria a imagem automaticamente carregada no seu servidor. Mas o futuro são os softwares na Web. E eu venho falar de mais um aqui: ScreenShotMe

É fantástico! Agora você faz um print screen, acessa o endereço: http://dailyffs.com/shotme/ e já pode colar sua imagem que será automaticamente enviada ao servidor deles. Melhor ainda: você pode recortar diretamente na página!

Para este post aqui eu já usei essa técnica. Acho que vai me ajudar muito.

O funcionamento da Prototype é muito simples: para criação de um novo objeto você utiliza uma instância pré-existente desse objeto (um protótipo) e pede a ele mesmo que crie um clone.

A única dependência que você cria no seu sistema é de que essa interface comum passe a conter um método Clone, como mostra a figura abaixo.

Essa pattern torna o cliente não dependente dos produtos concretos, diferentemente por exemplo da Builder (engraçado que o livro fala que a Builder também é independente, mas acho que erraram…. do alto da minha modéstia…rs).

E a grande vantagem dessa pattern é a simplicidade. Porém tendo que pagar o preço de implementar um método Clone, que pode não ser muito simples.

Em especial o servidor DNS porque, para se colocar um site no ar, acessível à toda Internet, eu sabia que você precisava de:

1. Computador com um ip fixo e com um servidor web (como o Apache) instalado
2. Registro no Registro.br

E na hora do cadastro no Registro.br ele me pedia um bendito nome de servidor DNS.

Quando você contrata uma hospedagem eles vêm na forma “ns1.nomedahospedagem.com.br”. Mas se eu estou justamente cadastrando o meu domínio no Registro.br como será possível eu já ter um nome nesse estilo?

Eis que, hoje, lendo o FAQ do Registro.br eu me deparei com o seguinte trecho:

Os campos de endereço IP e IPv6 devem ser preenchidos somente nos casos em que o domínio do servidor DNS seja igual ou esteja contido no que está sendo delegado.
…
Exemplo: No caso do domínio XYZ.COM.BR delegado para os servidores FOO.XYZ.COM.BR, NS1.BAR.XYZ.COM.BR e NS1.KZX.COM.BR, para os dois primeiros servidores, o preenchimento do campo endereço IP é obrigatório

Ou seja, se você vai cadastrar o seu domínio: ruppel.eng.br, pode colocar no registro.br o servidor DNS ns1.ruppel.eng.br. Mas aí você coloca tb o ip fixo (que era um pré-requisito que eu já conhecia). O Registro.br só usa o ip nesses casos de o DNS fazer parte do próprio domínio que você vai cadastrar. Super interessante!

Agora indo à parte prática.

Para configurar o DNS no Windows Server 2003++ você primeiro precisa ativar o Serviço:

1. Painel de Controle -> Adicionar ou Remover Programas -> Adicionar ou Remover Componentes do Windows -> Serviços de Rede -> Clique em Detalhes e Selecione “Domain Name System (DNS)”.

Com o serviço ativado você pode acessá-lo diretamente através das Ferramentas Administrativas.

Então você precisa criar uma zona (sem trocadilhos). No meu domínio a zona seria “ruppel.eng.br”. Botão direito em “Foward Lookup Zone” (Zona Direta) e “New Zone”.

Dentro dessa sua zone, você já pode adicionar suas entradas (ou registros, como preferir). Botão direito e você terá as opções de Registro A, Registro CNAME, Registro MX, que servem, respectivamente, para linkar o seu nome de domínio para ip, outro nome de domínio e para configurar email.

Um exemplo de Registro A é não preencher nada e colocar o ip da sua hospedagem. Outro exemplo é colocar como subdomínio o “www”. Outro tb interessante é colocar como subdomínio o asterisco “*”, assim qualquer subdomínio será direcionado para aquele ip.

Aqui tem o material Microsoft sobre a instalação e configuração de servidor DNS: http://support.microsoft.com/kb/814591

Cannot obtain value of local or argument ‘variableName’ as it is not available at this instruction pointer, possibly because it has been optimized away

mas na época não dei muita atenção, é uma pequena limitação enquanto vc tenta debugar alguns códigos nativos do .Net Framework.

aliás, achei bem natural haver restrições pra isso

eis que não existem restrições! e a solução para o problema acima está descrita aqui

foi bacana que eu achei essa solução por acaso, num blog simpático e não muito ativo que eu acompanho

na verdade, na época eu nem achei q era um “problema”, por isso não fui atrás de solução… mas agora jah sei =)

mas eu vejo nisso um quê de passado

existem algumas alternativas para controlar um computador: reconhecimento de voz, as ultimamente badaladas “touchscreens”, mas há coisas ainda mais modernas:

talvez encontrar o verdadeiro futuro da UI (esses padrões parecem bizarros qdo vc pensa em uma lan house usando qqler um deles: ou seria um monte de gente falando ao mesmo tempo com seus computadores, ou fazendo gestos, e aí as coisas mais tradicionais parecem mais sensatas)

pois bem… encontrar o futuro da UI parece um bom caminho de inovação

mas eu tive alguns problemas com fancybox, e decidi trocar pelo colorbox. O bug determinante para isso foi que eu tive problemas para abrir o fancybox em IE7 quando usando o IIS do Windows 7.  E ainda depois da segunda ou terceira vez que se tenta abrir a modal. Sim, problema muito específico, então nada muito grave.

A única vantagem que vi do fancybox em relação ao colorbox é permitir o posicionamento centralizado da modal, mesmo quando fazemos scroll do conteúdo que está atrás. Opção “centerOnScroll”.

O colorbox é mais leve, mais simples, e não tem esse bug do fancybox. Além disso, há um problema chato com fancybox:

Quando eu abro arquivos da minha máquina direto no navegador, o fancybox não vai funcionar com ajax. O modo ajax só funciona através de um servidor http.

Novamente, ambos os jquery plugins são excelentes. Mas esses dois detalhes do fancybox me irritaram, então resolvi trocar para o colorbox.

o jeito indicado é usar um selector no link e chamar o método validate

não encontrei na internet como fazer essa chamada javascript manualmente, para forçar a pop-in em um momento específico

a solução descobri fuçando o código do plugin: basta incluir o type ajax nas opções da chamada manual:

$.fancybox(‘endereco_popup.html’, { ‘type’ : ‘ajax’ } );

O intuito desta pattern é separar o processo de criação de um objeto da sua representação. Assim, um objeto complexo, que exigiria algumas etapas para sua construção, pode ter um builder genérico que serviria para diferentes representações desse objeto.

O exemplo utilizado no livro é de um leitor de formato RTF. Esse leitor pode criar uma outra representação do formato RTF de várias maneiras: em puro texto, em formatação alternativas como o LeX, ou até em representações gráficas. Cada uma dessas representações é um produto distinto, mas, em todas elas, o processo de conversão a partir do RTF analisaria o texto sequencialmente, e executaria processos especiais para coisas como: mudança de fonte, mudança de parágrafo, inserção de caracteres especiais e etc.

O diagrama de classes abaixo ilustra como é a solução oferecida por esta pattern.

Na ilustração não está o papel do cliente. O interesse do cliente é obter um Produto. Para isso ele precisará ter conhecimento do Diretor (genérico) e do Builder, mas reparem que o Cliente precisa conhecer o builder concreto e não apenas o abstrato. Isso porque o método GetResult não está declarado na interface Builder.

Esta pattern, portanto, torna o seu sistema dependente do produto final. O que a pattern vai abstrair é o processo de criação do produto, guiado pela implementação do método Construct pelo Diretor (que vai construindo as partes do produto, sem precisar conhecer sequer qual é a interface do produto).

É decisivo nesta pattern a escolha de um processo de criação do produto com uma granularidade fina o suficiente para a criação das diferentes representações do Produto. Isso pode ser um problema para alguns dos builders concretos mais simples, que necessitem implementar várias partes vazias desse processo. Um jeito interessante de se fazer o Builder para evitar isso é através de métodos BuildPart vazios, para que os builders concretos implementem apenas os processos que lhe são interessantes.

Eu confesso nunca vi esta pattern em ação, mas fazendo uma comparação com a AbstractFactory vejo duas diferentes:

1. O builder está focado na construção do objeto na forma de passos (partes)
2. O cliente fica dependente da classe concreta do builder (não é um defeito, a pattern foi feita propositadamente desta forma, a intenção era permitir diferentes conjuntos de construção e representação para um produto conhecido)

A Abstract Factory é a primeira Design Pattern descrita no livro Design Patterns. Ela faz parte da categoria de Patterns Criacionais, cujo objetivo é a instanciação de objetos. Essa categoria é importante pois ela sustenta o princípio mais importante do livro: “programe para interfaces e não para implementações”.

Todas as patterns tratam a respeito de relações entre os objetos, de forma que eles sejam independentes das implementações. Porém, em algum momento esses objetos deverão ser instanciados, e aí entram em cena as Patterns Criacionais, cujo único objetivo é a instanciação de objetos de forma que seu sistema continue independente de implementações.

Posso dizer que, atualmente, essas patterns criacionais estão em desuso, sendo substituídas pelos frameworks de Injeção de Dependência, que fazem exatamente isso: instanciam para você as classes das quais você é dependente. De toda forma, conhecer as patterns, a sua motivação e entender as suas consequências é um bom exercício de design de software.

Abstract Factory

O problema específico que a AbstractFactory tenta resolver é da instanciação na existência de uma família de produtos. O exemplo dado no livro é o seguinte: você tem elementos visuais (produtos), como Window, ScrollBar, Menu e etc. Esses elementos visuais têm diferentes implementações para cada família de implementação gráfica, como o Microsoft Windows, o MAC, e X do Linux.

Nesse caso, a solução consiste de duas coisas:

1. Crie interfaces padrões para os diferentes produtos dessa família (como Window, ScrollBar e Menu). E todo o seu sistema vai trabalhar apenas com essas interfaces que você definiu.

2. Defina uma AbstractFactory, que tem os métodos de instanciação para cada uma dessas interfaces padrões definidas acima, no caso, os métodos para o exemplo seriam: CreateWindow, CreateScrollBar, CreateMenu. Toda hora que o seu sistema precisa de instâncias dos produtos ele as obterá através dessa AbstractFactory.  Algo como factory.CreateWindow()

Mas de onde virá essa factory? Em algum lugar, provavelmente na inicialização do seu sistema, você define qual AbstractFactory você vai fornecer ao seu sistema, e repassa essa factory a todos os objetos que precisarem dela.

Na figura acima, retirada do livro, o Client, que representa o “resto do seu sistema”, utiliza as classes abstratas dos produtos (AbstractProductA e AbstractProductB) e a AbstractFactory, assim como foi explicado.

Prós x Contras

É importante agora analisar os benefícios e malefícios dessa pattern. O ponto principal é que a pattern deixa seu sistema independente das diferentes famílias, ou seja, garante o baixo acoplamento que foi falado no começo.

Outro ponto positivo é que a pattern permite adicionar, remover ou modificar rapidamente qual família de produtos deseja-se usar. Isso pode até ser feito em runtime, se usado com um pouco de Reflection.

O ponto negativo desse pattern é que a adição ou remoção de um produto da família exige a modificação da AbstractFactory, o que causa um grande overhead, pois deve-se modificar todas as implementações da factory e o cliente que usa a AbstractFactory.

Na verdade, usando-se Reflection pode-se até criar um único método “Create” que recebe como parâmetro alguma indicação de qual produto ele deve criar (uma string com o nome da classe, por exemplo). Assim, você poderia criar um novo produto sem muitos problemas, basta passar o parâmetro certo para o novo produto. Mas isso funciona como uma balança: se você ganha flexibilidade na criação de novos produtos, você perde com a necessidade de uma interface única para todos esses produtos, já que eles serão retornados pelo mesmo método “Create”.  E o seu client precisará fazer um cast para o produto certo.

O livro Design Patterns é um dos maiores, se não o maior, dos clássicos em desenvolvimento de software. Seus autores ficaram imortalizados como “a gangue dos quatro”.

O primeiro capítulo do livro serve para explicar o que são Design Patterns. Traduzindo o termo para o português teríamos “Padrão de Projeto”, uma tradução bem razoável. As design patterns são padrões desenvolvidos para sistemas orientados a objetos (conhecer OO é requisito mínimo para ler este livro).

As design patterns não foram inventadas pela gangue dos quatro, o trabalho deles foi identificar e catalogar esses padrões de projeto usados em diferentes sistemas em operação pelo mundo. Eles identificaram esses padrões, as situações em que eram usados e ainda vantagens e desvantagens do uso de cada padrão. Esse catálogo que fez do livro um clássico: ele virou referência para análise de qualquer outro sistema.

E afinal, o que é uma design pattern? Design pattern é uma forma de se estruturar os objetos do seu sistema OO para resolver um tipo de problema recorrente. Assim, a mesma design pattern pode ser usada para diversos casos distintos, desde que  apresentem algumas características em comum, encaixando-se no “tipo de problema” para o qual a pattern foi concebida. As designs patterns são comumente encontradas nos grandes sistemas implementados com sucesso pelo mundo afora.

Para caracterizar uma Design Pattern, ao longo do livro, eles utilizam:

1. Nome – para podermos nos referenciar de forma fácil a elas

2. Problema (ou “tipo de problema” ou “situação”) -  uma caracterização de quando essa pattern deve ser usada

3. Solução – é a estruturação dos objetos de forma a resolver o problema acima descrito (quais as interfaces, como elas se relacionam e suas funções na resolução do problema)

4. Consequências – são as vantagens e desvantages da pattern, ou resultados obtidos com o uso daquela pattern

Dois conceitos fortíssimos ficam ao longo de todo o livro:

- Programe para interfaces e não para implementações, deixando seu sistema com baixo acoplamento

- Abtraia os conceitos que variam no seu sistema em forma de objeto. Por exemplo, se você tem um objeto que possui alguma lista, e em algum  momento esse objeto deve ordenar essa lista, mas existem vários parâmetros que alteram a forma com a qual essa lista deve ser ordenada, então, uma boa idéia seria criar objetos para as diferentes formas de se ordenar essa lista.

Os capítulos do livro descrevem, cada um, uma Design Pattern. Nos próximos dias criarei posts para cada uma dessas Design Patterns apresentadas no livro.