Web a S�rio

DNS - Email - registos MX e CNAME

themage — Thu, 05 Aug 2010 09:00:00 GMT

Como descrito no artigo anterior desta s�rie DNS - Tipos de registos, os registos CNAME e MX indicam, respecivamente, que o nome para o qual o nome que se est� a configurar/resolver � uma alias (nome alternativo) e qual o servidor a quem deve ser entregue o email.

E todos vivemos felizes com isto at� algu�m utilizar um registo CNAME da forma errada.

� que o que o CNAME diz � "tudo o que quizeres saber sobre mim, pergunta como se eu me chamasse <este outro nome>".

E isto significa que tudo o que estiver configurado para esse outro dom�nio deve ser considerado como se estivesse configurado neste, e nada do que estiver configurado neste deve ser considerado.

E, claro, o servidor de email tamb�m est� incluido. Logo, independentemente de existir ou n�o um registo MX no dom�nio actual (o que tem o CNAME configurado), o email deveria ser entregue ao servidor MX configurado no dom�nio indicado pelo registo CNAME.

O problema � que nem todos os servidores de email concordam com esta interpreta��o, pelo que, dependendo do servidor de email de quem est� a enviar emails para estes dom�nios, esses emails podem ser entregues ao servidor de email do dom�nio com o CNAME ou no servidor de email do dom�nio indicado pelo CNAME.

Como evitar este problema?

Se quer realmente receber email no dom�nio de origem e que que este email seja entregue num servidor diferente do servidor de email do dom�nio para onde aponta o registo CNAME, ent�o crie um registo MX e utilize registos A para apontar o nome para o mesmo IP para onde aponta o nome de destino.

Se o servidor de email for o mesmo, ent�o n�o deve ter problema. Neste caso n�o ter um registo MX no dom�nio de origem deve funcionar como se ele l� estivesse. Bastar� que o servidor de email esteja configurado para receber o email do dom�nio de origem.

Se n�o pretende receber email no dom�nio de origem basta que um servidor de email do dom�nio de destino esteja configurado para rejeitar o email do dom�nio de origem. A maioria dos servidores de email est�o preparados para rejeitar email de todos os dom�nios para os quais n�o foram configurados para receber email. Deve, no entanto, verificar se � o caso do seu servidor.

Tipos de registos

themage — Sun, 08 Aug 2010 15:00:00 GMT

Inicialmente, o DNS tinha registos dos tipos A, CNAME, NS e MX. Posteriormente foram adicionados os tipos AAAA, SRV e TXT.

Registos do tipo A

Os registos de DNS do tipo A s�o a raz�o final da exist�ncia do sistema de resolu��o de nomes, e o tipo de registos que d� nome ao servi�o. Este �, hoje, um dos dois tipos de registos que se destinam a fazer o que o nome diz... resolver nomes.

Os registos do tipo A - de Address - servem para relacionar os nomes de dominios com os endere�os IP - os tais n�meros dos servidores de que falamos em artigos anteriores.

Por exemplo:

www.webaserio.com A 69.60.115.53

Este registo indica que o nome www.webaserio.com � servido pelo computador com o IP 69.60.115.53.

Registos AAAA

A internet cresceu de tal forma que o n�mero de IPs inicialmente dispon�veis est� pr�ticamente esgotado e j� n�o permite acompanhar o crescimento da rede. Hoje existem computadores numa grande percentagem de casas, e cada vez mais existe um computador na m�o (ou no bolso) de casa pessoa (os SmartPhones). Para ultrapassar este problema foi criado um novo conjunto de endere�os, designados com o nome IPv6.

Os registos AAAA funcionam de forma id�ntica aos rregistos A, com a diferen�a que o endere�o � IPv6 e n�o IPv4.

Infelizmente, hoje, ainda nem todas as redes t�m routeamento IPv6 pelo que servidores que esteja em redes IPv6 n�o s�o acess�veis a toda a gente. Isto tamb�m faz com que os registos de DNS do tipo AAAA ainda n�o sejam muito comuns.

Registo CNAME

O registo CNAME indica que um nome � um nome alternativo para um outro nome. A consequ�ncia mais �bvia disto � que para obtermos o endere�o deste nome devemos pedir o endere�o do nome indicado por este registo.

O registo CNAME tem implica��es tamb�m com os registos do tipo MX, mas sobre as complica��es entre o CNAME e o MX falaremos mais � frente, num outro artigo desta s�rie.

Para j�, a reter, � que o CNAME indica que o nome que estamos a tentar resolver � um segundo nome para um outro nome que nos � devolvido.

Registo NS

O registo NS � o que faz com que a hierarquia de nomes funcione. Este registo indica qual o servidor respons�vel por resolver os nomes de um dom�nio.

Na pr�tica, quando configuramos um registo NS estamos a indicar que servidor(es) sabem responder �s quest�es de DNS de um dom�nio (ou subdominio).

Registos MX

Os registos MX indicam qual o servidor de email para um dom�nio.

Na pr�tica, quando temos um email do tipo email@example.com, devemos perguntar ao servidor de NS do dom�nio example.com qual � o servidor de email do dom�nio, isto �, qual o MX do dominio, e em seguida, enviar o email para esse servidor.

Registos SRV

Os registo SRV permitem definir quais os servidores que suportam um determinado servi�o para um dom�nio.

Este tipo de registos servem para indicar que servidores suportam cada tipo de servi�o baseado no dom�nio para o endere�amento, isto �, em que o tipo de conta seja do tipo <utilizador>@<dominio.com>, com excep��o do dom�nio que, sendo deste tipo (o endere�amento do email � do tipo acima), utiliza os dominio do tipo MX.

Registos TXT

Os registos TXT servem para associar informa��o ao dominio. Estas informa��es s�o com que pequenos ficheiros de texto, que podem conter qualquer informa��o publica que se pretenda associar ao dom�nio.

Actualmente, uma das informa��es mais comuns - mas ainda n�o comum o suficiente - que podemos encontrar neste tipo de registos s�o as chavez p�blicas dos servidores de email, que podem ser utilizadas para validar que um email enviado como se tivesse origem num dom�nio a� tem de facto origem.

Outros tipos de registos

Implementa��es diversas de servi�os implementam frequentemente altera��es ao DNS para suportar outros tipos de registos, uns mais comuns do que outros, mas os registos acima s�o os mais comuns, e os que s�o suportados pelos RFCs recomendados pelo IEEE, o organismo respons�vel pela gest�o dos RFCs que definem a maioria dos protocolos base da Internet.

Mas, claro, se acham que outros tipos de registos deveriam constar desta lista deixem-me um coment�rio para que o pesquise e adicione a esta lista.

DNS -Resolu��o de nomes

themage — Fri, 25 Jun 2010 12:35:00 GMT

Hoje como no inicio, cada m�quina ligada � rede - e hoje � uma grande rede, a que chamamos internet - tem ainda uma n�mero que o identifica, e � esse n�mero que �, ainda hoje, utilizado pelo computadores para trocarem informa��o uns com os outros, mesmo que n�s normalmente apenas vejamos os nomes.

Resolu��o passo a passo

A resolu��o de DNS tem hoje alguns elementos que permitem tornar o processo de resolu��o de nomes mais r�pida e eficiente. Mas, para j� vamos ignorar essas optimiza��es.

Assim, quando queremos converter um nome no IP correspendonte, a primeira pergunta que temos que fazer � quem � que controla a informa��o de DNS. E a resposta a essa pergunta � a de que s�o os servidores de DNS do dom�nio de topo - o dominio .. Os servidores de DNS do dom�nio . s�o normalmente designados de rootservers.

Assim, a primeira coisa a fazer � perguntar aos root servers se eles sabem a resposta que procuramos. Provavelmente eles n�o nos v�o dar a resposta que procuramos, mas indicam-nos a quem devemos perguntar a seguir - os servidores de DNS do dom�nio de topo a quem pertence o site. Se o dom�nio o dom�nio de topo a que pertence o nome que estamos a tentar resolver for com ou net, os rootservers v�o dar-nos logo os servidores de DNS do nosso dom�nio que pretendemos resolver, uma vez que s�o eles tamb�m os servidores de DNS destes dom�nios.

Com a informa��o disponibilizada pelos rootservers, dirigimos as nossas quest�es aos servidores que nos foram devolvidos pelos rootservers que, por sua vez, podem dar-nos imediatamente a informa��o que procuramos ou enviar-nos o endere�o de novos servidores a quem devemos dirigir em seguida as nossas perguntas.

Todo este processo � repetido at� se conseguir a informa��o que procuramos ou at� nos ser dito que essa informa��o n�o existe ou at� detetarmos que existem inconsist�ncias nas respostas que nos s�o enviadas - por exemplo, dois servidores, cada um deles dizer que o outro � que � o respons�vel pela informa��o que procuramos.

Resolu��o com cache

Embora cada um dos passos referidos na sec��o anterior seja r�pido e consista na transmiss�o de apenas alguns byts, a internet nem sempre foi a rede que conhecemos hoje, em que a velocidade de transmiss�o � quase sempre na ordem dos megabits por segundo - houve um tempo em que se podiam ouvir os bits a entrar e a sair da linha telef�nica. Nesses tempos apenas alguns bytes podiam demorar at� um segundo a ser transmitidos, e se a pergunta tivesse que ser feita a servidores de DNS do outro lado do mundo, a resposta ia demorar a voltar.

E, para tornar a resolu��o de nomes mais eficiente, criaram-se servidores de DNS o mais pr�ximo poss�vel dos clientes, que quando n�o sabem as respostas que os seus clientes procuram, fazem as perguntas necess�rias aos outros servidores e depois respondem directamente ao cliente e guardam a resposta para conseguir responder imediatamente quando o mesmo ou outro cliente tentar resolver o mesmo nome.

E os clientes passam a utilizar estes servidores sempre que pretendem resolver um nome, pois estes conseguem responder-lhes muito mais rapidamente nos maioria dos casos.

Este processo permite, assim, poupar tempo, e reduz drasticamente a quantidade de dados transmitidos - o que at� h� pouco tempo tamb�m era tempo. E nesse tempo a liga��o � internet era paga pelo tempo que se estava ligado.

DNS - intro

themage — Thu, 24 Jun 2010 10:24:47 GMT

Antes havia o IPX, o tokenring e montes de outras coisas, mas isso foi antes. Antes do in�cio.

Ent�o apareceu o IP, e os criadores perceberam que o IP era bom. E em cima do IP escreveram o TCP, o UDP e o ICMP. E os criadores chamaram ao conjunto destes protocolos TCP/IP. E os criadores perceberam que isto era bom. E isso foi o inicio.

E ent�o reescreveram-se protocolos que j� existiam sobre o TCP/IP e criaram-se novos protocolos. E apareceu a rede, e a rede cresceu.

Mas no in�cio n�o havia nomes, s� n�meros. Os n�meros do IP. Enquanto a rede era pequena era f�cil saber o n�mero de todos os computadores na rede. Mas quando a rede come�ou a crescer os criadores perceberam que era preciso dar nomes aos computadores, porque para n�s � mais f�cil lidar com nomes do que com n�meros. E por isso criaram o DNS.

E, porque todos escrevem sobre a web, mas poucos lembrar os protocolos que fazem a web funcionar, decidi escrever uma s�rie de artigos sobre o DNS. Neste artigo irei criando links para esses artigos, que ser�o publicados ao longo dos pr�ximos dias.

Artigos neste s�rie

DNS - Hierarquia de nomes

A Publicar

DNS - Resolu��o de nomes

DNS - Hierarquia de nomes

themage — Thu, 24 Jun 2010 10:27:09 GMT

Hoje quase toda a gente que trabalha na �rea de internet j� ouviu falar dos dom�nio de topo (normalmente abreviado como TLD - a sigla da express�o inglesa Top Level Domain).

O que nem toda a gente sabe, mesmo entre quem trabalha na �rea de internet � que existe um dom�nio acima dos dom�nios de topo. Trata-se do dom�nio . .

Este � dom�nio debaixo do qual (quase) todos os outros dom�nios est�o. E digo quase apenas porque por vezes se utilizam truques relacionados com o funcionamento do DNS para criar dom�nios (mais ou menos) privados que n�o � poss�vel resolver utilizando aquilo a que irei chamar a cascata de resolu��o de nomes tradicional.

Os nomes resolvidos pelo DNS s�o algo que nos habituamos a ver todos os dias. E isso inclui quem sem sequer utiliza a internet. Eles est�o, hoje, em todo o lado - nos carros das empresas, nas suas facturas, nos cart�es de visita, profissionais ou pessoais - s�o os endere�os dos blogs, dos sites sociais e at� parte dos endere�os de email. Todos estes endere�os s�o resolvidos pelo DNS.

Mas, como est�o estruturados?

Bem, primeiro temos o senhor de todos os dom�nios, o dominio . - que normalmente n�o � utilizado explicitamente - e debaixo dele temos os dom�nios de topo - com, net, org, pt, br, us, uk, ... - existem uns quantos globais, todos os pa�ses t�m um e algumas regi�es tamb�m t�m dom�nio de topo - como os eu ou asia.

Cada um destes dom�nios de topo tem uma entidade que gere os dom�nios que s�o criados debaixo deste TLD. Por exemplo, no caso do TLD pt, a entidade que faz esta gest�o � a FCCN.

Normalmente, satisfeitas as condi��es, � poss�vel criar dom�nios debaixo destes dom�nios de topo ou em subdom�nios deles - o com.pt ou o co.uk, por exemplo - e a gest�o destes dom�nios � entregue � entidade que fez o registo, que pode depois criar os subdom�nios que entender debaixo do seu nome.

Cada um destes nomes � separado do dom�nio acima por um ., criando-se assim os nomes que j� estamos habituados a ver nos nomes dos sites.

Tradicionalmente o primeiro nome representa o nome da m�quina, e todos os outros nomes acabavem por ser - por assim dizer - o caminho a percorrer para encontrar o servidor.

Assim, quando vemos um endere�o como www.webaserio.com, estamos a olhar para o nome da maquina www do dom�nio webaserio que est� debaixo do TLD com.

Claro que hoje, com maquinas muito mais r�pidas e com uma muito maior diversidade de servi�os, um servidor serve v�rias coisas e v�rios sites, e a primeira parte nome acaba por ser mais o nome do servi�o do que o da maquina que dispon�biliza o servi�o, havendo t�o frequentemente v�rios servi�os a ser disponibilizados numa mesma maquina como v�rias maquinas a servir um �nico servi�o.

10 Plugins de Firefox para WebDevels

themage — Tue, 12 Jan 2010 22:58:24 GMT

Fazer desenvolvimento para web pode ser uma tarefa complicada sem as ferramentas certas - mas meia duzias de plugins para firefox tornam tudo muito mais simples.

Cookie-Swap

Em primeiro lugar, um plugin que a mim me facilita imenso a vida, especialmente porque como desenvolvo as minhas ferramentas de gest�o, seja a Mason Framework para os meus projectos pessoais, seja o backoffice que estamos a adoptar no clix, tenho por vezes a necessidade de testar as diversas funcionalidade com utilizadores com permiss�es e op��es diferentes. O Cookie-swap permite-te trocar todas as cookies do meu browser entre um conjunto de identidades pr�-definidas.

Cookie Monster

Mas, como por vezes mudar de identidade n�o � o que se pretende, e como o Cookie-Swap apenas me permite apagar todos os cookies de uma das minhas identidades, utilizo o Cooki Monster para conseguir gerir os meus cookies de uma forma mais precisa.

O Cookie Monster permite-me definir site a site que cookies quero aceitar ou rejeitar, criar regras por site ou globais, ver os cookies de um site e apag�-los individualmente.

FireBug

Durante muito tempo utilizei para esta tarefa o Web Developer. Ele ainda continua instalado no meu firefox, mas j� n�o me lembro de quando foi a ultima vez que o utilizei.

O Firebug � hoje a ferramenta que me permite perceber porque � que as p�ginas n�o t�m a apar�ncia que era suposto terem, executar javascripts passo a passo, executar javascripts arbitr�rios, verificar e alterar CSSs dos sites, e muito mais.

HTTPFox

O HTTP � uma esp�cie de proxy, que nos permite analisar todos os requests HTTP que s�o feitos pelo browser, permitindo-nos olhar para dentro de cada request, ver o que foi pedido, com que headers, e qual foi a resposta que o servidor devolveu.

Desde que utilizo o HTTPFox j� quase deixei de fazer telnet directamente para o porto 80 do servidor para fazer requests manualmente!

Library Detector

O Library Detector mostra-nos, na barra de status do browser, as bibliotetas javascript que s�o utilizadas pelo site que estamos a visitar.

Isto � especialmente util quando estamos � procura de uma qualquer funcionalidade e queremos saber, rapidamente, se uma implementa��o que encontramos utiliza as mesma base que n�s estamos a utilizar no nosso site.

Search Status

O Search Status permite-nos obter v�rias informa��es relacionadas com a indexa��o e rankings do site que estamos a visitar.

Permite tamb�m verificar qual � a densidade de um conjuntos de palavras numa p�gina e verificar v�rios registos de um site, como seja o seu registo whois - a informa��o do registo do site, - vers�es mais antigas do site, com o http://archive.org, e v�rios outros dados.

Cache Status

O cache status d�-nos informa��es acerca da quantidade de cache que o nosso browser est� a utilizar, e permite-nos apagar todos os ficheiros em cache. Eu utilizo-o apenas para fazer esta tarefa.

Bot�o direito sobre os icons (tenho o resto da informa��es escondida porque n�o me interessa), escolho "Clear all caches" e... j� n�o h� cache no browser! Menos uma quest�o a causar problemas. Assim tenho a certeza que o meu browser n�o me mostra uma vers�o mais antiga de ficheiro nenhum.

Flagfox

Este � principalmente informativo... achei giro, mas n�o �, hoje, especialmente �til. Permite-me saber em que pais est� o servidor onde estou a aceder.

Por exemplo, os servidores do http://www.google.com e http://www.google.pt est�o ambos nos Estados Unidos, mas os do Clix est�o em Portugal. Nem me lembro dele, muitas vezes.

FoxTab

O FoxTab permite mudar entre as tabs abertas, utilizando o Ctrl+Tab, e mostra-nos screenshots das v�rias tabs em 3D. � bastante configur�vel, e al�m de bonito faz com que perca muito menos tempo a clicar nas v�rias tabs � procura daquela que eu quero.

Speed Dial

O Speed Dial � um plugin que utilizo como p�gina inicial, e que pode ser utilizada para guardar links para os sites mais utilizados, mostra-nos um screenshot dos sites, e pode tamb�m ser utilizado para, em qualquer tab, mesmo que a p�gina do speed dial n�o esteja vis�vel, aceder rapidamente ao site, carregando em Ctrl+<n�mero> - o n�mero pode ser composto (20, por exemplo), para aceder ao site que est� nessa posi��o da grelha do speed dial.

Outros

E voc�s, estimados leitores, que plugins utilizam, sem quais n�o podem viver? Quais consideram imprescind�veis?

Vencer a Inercia

themage — Mon, 04 Jan 2010 09:00:00 GMT

H� sempre uma desculpa, uma boa desculpa para n�o fazer alguma coisa, para adiar um qualquer projecto, especialmente quando n�o se est� a ser pago para o fazer - �s vezes at� quando se est� a ser pago.

Incluindo escrever posts num blog.

� isso que me tem acontecido ao longo dos �ltimos tempos. Com alguma frequ�ncia ainda me consigo for�ar a adicionar algumas das muitas anedotas que tenho, principalmente em papel no Melhor Rem�dio, mas escrever nos blogs mais s�rios, como este � outra cantiga.

Umas vezes ocupo o meu tempo a desenvolver novas funcionalidades no CMS que suporta todos os meus sites, e na framework sobre a qual ele � escrito, mas muitas vezes passo o meu tempo livre simplemente a ler o que muitos outros escrevem um pouco pela internet. E agora com o twitter � ainda mais f�cil isso acontecer.

Mas, ao fim de algum tempo, as funcionalidades no Mabliki e na Mason Framework n�o servem de muito. � por isso que preciso for�ar-me a escrever mais. A quest�o que se me coloca - e presumo que frequentemente se coloque tamb�m a muitas outras pessoas, talvez a algum dos meus tr�s leitores - � como fazer para escrever mais, como for�ar-me a terminar os v�rios posts que tenho come�ados no Kate do meu eeePC? Como fazer para me for�ar a escrever os v�rios posts que j� pensei v�rias vezes escrever sobre MySQL, jquery-ui, sobre a Yahoo! Pattern Library, e sobre os muitos outros temas que s�o hoje importantes e relevantes para quem faz desenvolvimento para web?

T�m este problema, de adiar constantemente escrever posts nos vossos blogs? Que truques utilizam para conseguirem escrever?

Google Go Lang e espa�o extra

themage — Wed, 11 Nov 2009 13:15:00 GMT

H� dias assim, em que por todo o lado s� se v� uma determinada marca. Os blogs sobre Web hoje falam do google, por diversas raz�es:

Cloud Storage

O Google j� permitia a quem queria ter mais espa�o para as suas fotografias no Picassa, ou no Gmail pagasse por esse espa�o adicional. At� agora o pre�o era de 20 D�lares por cada 10 GB. Esse pre�o � agora de 5 d�lares por cada 20 GB, com um limite de 16 Terabytes.

Google Wave

Depois de distribuir 100 mil convites para o Google Wave, a de dar 8 convites a cada um desse convidados iniciais para convidarem quem quizessem, o Google distribuiu este fim de semana mais 30 convites a cada um dos convidados iniciais... Ainda tenho, se estiverem interessados.

Go - A linguagem de programa��o

Hoje � f�cil encontrar tamb�m refer�ncias � nova linguagem de programa��o que o Google disponibilizou, a Go. Trata-se de uma linguagem de programa��o baseada em C, com tipagem forte, como o C, com uma aproxima��o original � programa��o orientada a objectos, com comunica��o entre threads/processos nativa e simples de utilizar, locks e muito mais.

Eficaz, minimalista e directa ao objectivo. Esta parece-me uma linguagem de que vou ouvir falar bastante ainda, depois e o hype acabar, queria eu dizer!

Posts que atraem links

themage — Thu, 22 Oct 2009 19:48:12 GMT

Na passada segunda-feira foi publicado no blog SEOmoz um post (What Makes a Link Worthy Post - Part 1) que � o resultado de um estudo feito com base nos links existentes para os v�rios posts do blog, numa tentativa de encontrar as caracteristicas dos posts que s�o alvo de mais links de outros dominios.

Algumas das conclus�es do estudo parecem obvias para qualquer blogger com um pouco mais de experi�ncia, mas algumas delas contrariam algumas das ideias mais comuns no meio do bloggers mais profissionais. Vou guardar essa para o final, pois nunca � demais refor�ar algumas das ideias mais comuns nas cabe�as da maioria de n�s, mas que ainda assim nem sempre s�o aplicadas com a frequ�ncia com que poderiam ser.

Assim, uma das caracteristicas verificadas � se a presen�a de elementos multim�dia ou lista torna os posts alvo de mais links do que os posts que n�o t�m esses elementos. e a verdade � que em m�dia, os posts que t�m listas, imagens ou videos recebem em m�dia mais links do que os posts que n�o t�m nenhum desses elementos.

Posts com videos recebem at� tr�s vezes mais links do que posts apenas com texto. E posts com esses tr�s elementos recebem at� seis vezes mais links do que posts que n�o t�m qualquer deles.

A descoberta interessante � que o tamanho dos posts tem impacto na quantidade de links que esses posts recebem, mas ao contr�rio do que � normalmente vinculado em muitos dos blogs sobre SEO e sobre blogging, os posts com 1800 a 3000 palavras chegam a receber at� quinze vezes mais links dos que os posts com menos do que 600 palavras.

Isto, claro, pode ser verdade apenas para blogs como o SEOmoz, em que a grande maioria dos posts de grande dimens�o s�o tutoriais ou apresenta��o de teses ou estudos, por contrapartida com os posts menores que n�o passam de pequenos artigos informativos acerca de algo que se est� a passar num qualquer outro lugar da internet.

Mais uma vez, podem encontrar o post original no seoMoz, sob o titulo What Makes a Link Worthy Post - Part 1 (as partes seguintes ainda n�o foram publicadas).

A compreens�o das Licen�as

themage — Sun, 27 Sep 2009 21:13:08 GMT

� proibida a reprodu��o total ou parcial de posts deste blogue sem a indica��o expressa das autoria e proveni�ncia

Reservad@s todos os Direitos de Autor

Creative Commons License Esta obra est� licenciada sob uma Licen�a Creative Commons.

Esta obra est� licenciada sob uma Licen�a Creative Commons.

Esta mensagem pode ler-se na lateral do blog 100nada. Cito a licen�a apenas a t�tulo de exemplo, pois tenho a certeza que conhecem outros blogs e/ou sites que licenciam os seus conte�dos de forma igualmente conflituosa.

Mas, antes que perguntem, este duplo licenciamente �, n�o apenas conflituoso, mas tamb�m oportunista ou irrespons�vel. Ser� oportunista se tiver sido feito de forma consciente, para tirar partido das indexa��es especiais para conte�dos licenciados com Creative Commons. Ser� irrespons�vel se tiver sido colocado no blog sem se perceber o que se estava a fazer.

Eu, quando desenvolvo software a t�tulo pessoal, licencio o c�digo sob a licen�a GPL. Esta licen�a diz que qualquer pessoa pode utilizar este software para o que bem entender, sem me pagar nada, que n�o me pode responsabilizar porque nada, e que deve disponibilizar qualquer altera��o que fa�a ao meu software. � uma licen�a mais ou menos simples, mais complexa nesta vers�o 3 para deixar explicitas no corpo de licen�a quest�es que j� eram para a maioria de n�s obvias nas vers�es anteriores, mas que muitas pessoas pareciam n�o perceber, nomeadamente que ao licenciar um software como GPL, qualquer patente que cubra uma parte do software licenciado fica autom�ticamente licenciada gratuitamente - est�, para mim, explicito quando se permite a utiliza��o e altera��o do software, e ainda por cima se for�a o autor das altera��es a disponibilizar essas mesmas altera��es.

O GPL � uma licen�a mais do que imposta em tribunal, e j� poucas empresas de software acham que podem utilizar software (ou partes de software) GPL em software fechado. Mais cedo ou mais tarde acabam por ser descobertos e obrigados por tribunal a abrir todo o c�digo que est� junto com o c�digo GPL original.

A licen�a Creative Commons � uma licen�a destinada a permitir a c�pia de conte�dos em condi��es controladas. O autor pode escolher permitir apenas a c�pia da obra integral, autorizar ou n�o a cria��o de obras derivadas, e permitir a utiliza��o da obra comercialmente ou n�o. A autoria da obra, no entanto, sob Creative Commmons, deve ser sempre mantida e divulgada.

� por isto que n�o faz sentido dizer que n�o � permitida a c�pia dos conte�dos e depois dizer que est�o licenciados sob a licen�a Creative Commons. V� l�, n�o � assim t�o d�ficil ler o texto das licen�as antes de afixar os seus nomes e logos no site.

Planear Aplica��es Web de alta disponibilidade

themage — Thu, 03 Sep 2009 14:30:00 GMT

Hoje gostaria de vos deixar uma pequena apresenta��o da autoria de Yue Tian, intitulada, no original "Planning For High Performance Web Application".

Bem, esta n�o � a �nica e completa solu��o para criar sites de alta disponibilidade, mas muito do apresentado nesta pequena apresenta��o � uma base importante sobre a qual construir arquitecturas web de alta disponibilidade.

Google Adsense - Review Center e Competitive Filter

themage — Mon, 31 Aug 2009 08:30:00 GMT

O Google dispon�biliza duas ferramentas a quem quizer utilizar o Google AdSense para rentabilizar os seus sites, que lhes permite excluir os an�ncios que n�o sejam do seu agrado - O Ad Review Center e o Competitive Ad Filter.

Ad Review Center

O Ad Review Center permite validar os an�ncios que foram colocados directamente no nossos sites. No AdWords os an�nciantes t�m a poss�bilidade de an�nciar apenas num site especifico, ou se tivermos Targetable Channels associados aos an�ncios dos sites, os an�nciantes podem mesmo escolher em que Channel especifico querem que os seus an�ncios apare�am.

E, quando os nossos sites s�o os alvos dessas campanhas, o Google d�-nos uma ferramente que nos permite analizar estes an�ncios e decidir se queremos que eles apare�am no site ou n�o. Trata-se do Ad Review Center.

Competitive Ad Filter

Por outro lado, o mais normal � os an�ncios aparecerem nos nossos sites em consequ�ncia das keywords selecionadas pelo anunciante e que aparecem no nosso conte�do. Ao contr�rio dos an�ncios dirigidos especificamente ao nosso site, os an�ncios dirigidos a uma palavra-chave n�o podem ser filtrados individualmente, e o google n�o nos dispon�biliza uma lista dos an�ncios e dos an�nciantes que podem aparecer nos nossos sites ou em cada uma das p�ginas dos sites, pelo que filtr�-los n�o � t�o simples.

Mas ainda assim, o google dispon�biliza-nos uma ferramente que nos permite impedir que um qualquer an�ncio apare�a nos sites. Trata-se do Competitive Ad Filter. Esta funcionalidade destina-se a filtrar os concorrentes do nosso site, mas pode perfeitamente ser utilizada para eliminar sites que preferimos n�o divulgar, seja porque discordamos das suas pr�ticas ou porque (achamos que) eles t�m um retorno menor para n�s do que os restantes an�ncios que passam a aparecer quando o espa�o n�o est� acupado por esses an�ncios.

Eu, por exemplo, utilizo esta funcionalidade para filtrar os an�ncios de "dinheiro f�cil" e da maioria dos servi�os de SMSs que encontro. Claro que para filtrar esses sites temos primeiro que encontrar os links para onde os an�ncios nos enviam. A forma mais simples � clicar com o bot�o direito do rato (assumindo, obviamente, que s�o dextros) sobre o link do banner, selecionar a op��o Copy Link Address (ou o equival�nte na lingua em que tenham o vosso browser), colar o link num editor de texto e depois encontrar o par�metro adurl do link:



http://googleads.g.doubleclick.net/aclk?sa=l&(...)&adurl=http://www.opinionmaker.pt&nm=11

O link nesse par�metro � o site para onde o banner ir� enviar o utilizador. � esse o site que devem colocar no Competitive Ad Filter. No caso acime, provavelmente quereriamos colocar l� opinionmaker.pt (o que n�o vou fazer, pois n�o tenho nada contra o site http://www.opinionmaker.pt - parecem-me apenas uma empresa de PR, como tantas outras, que precisava de uma grande optimiza��o no site, nada de mais).

Outra forma, obvia de encontrar o link do an�ncio seria clicar no an�ncio, mas isso � algo que est� vedado aos editores dos sites com adsense se n�o querem que as respectivas contas sejam bloqueadas. Assim, se acharem muito complicado clicar no link com o bot�o direito do rato, ou se t�m medo de clicar no link sem querer, v�o a um site onde o an�ncio tamb�m apare�a e que n�o seja vosso e cliquem no link l�. Escolham um site de que gostem, pois estar�o a dar algum dinheiro ao site. E o link que devem bloquear � aquele onde foram parar. Mas, idealmente, utilizem o bot�o direito do rato.

Filtrar concorrentes e idiologias dissonantes

Mas, para que servem estas funcionalidades? Bem, para filtrar concorrentes ou sites que violam os nossos principios (principios, n�o direitos - violar os nossos direitos est� incluido, mas n�o � tudo o que isto pode incluir).

Imaginem que fazem sites, podem querer remover do vosso site todos os an�ncios de webdesigners e empresas de webdesign. Imaginem que vendem livros, podem querer remover todos os an�ncios de lojas de livros.

Ou imaginem que n�o concordam com as politicas de uma qualquer empresa, podem decidir remover todos os an�ncios que levam os vossos utilizadores para os sites dessa empresa. � o que eu fa�o com todos os servi�os de SMS com assinaturas.

Conte�do Web distribu�do

themage — Wed, 26 Aug 2009 08:45:00 GMT

Desenvolver sites que cres�am realmente � uma quest�o que n�o se coloca todos a dias a todos os programadores web. Admitamos, para muitos de n�s um site ser� visitado, eventualmente, por alguns (poucos) milhares de pessoas por dia. Mas quando se desenvolve para gr�ficos de pageviews com milh�es, � preciso pensar como se consegue servir tantas pessoas.

Eu entrei para o Sapo em 2000 (a 3 de Maio de 2000 - depois de almo�o, para ser realmente preciso). Era na altura uma equipa com 2 ou 3 webdesigners, eu era o quarto programador, e pouco antes de mim tinham entrado os primeiros administradores de sistemas dedicados � tarefa. E uma pequena equipa editorial - bem maior do que a equipa t�cnica, ainda assim.

Mas o realmente impressionante no Sapo � que tinha em Abril desse ano ultrapassado pela primeira vez a m�dia di�ria de 1 milh�o de pageviews. E era servido, na altura numa infra-estrutura constituida por 1 servidor MySQL, e 3 ou 4 servidores Apache. Todos os ficheiros eram ent�o alojados num �nico share NFS, que era montado directamente em todos os front-ends.

Uma grande parte dos sites eram ent�o pr�-gerados, a partir do mysql, e o que chegava aos front-ends era uma vers�o est�tica dos sites. Completamente est�tica. As poucas p�ginas din�micas utilizavam o �nico MySQL existente.

Mas, h� medida que o novo s�culo se aproximou, foi-se tornando cada vez mais evidente que n�o poderiamos continuar a viver exclusivamente de p�ginas est�ticas, pois a sua gera��o tornava-se cada vez mais demorada � medida que a base de conte�do crescia, tentativas de gera��o parcial resultaram em templates desactualizados, os utilizadores e a equipa editorial, respons�vel pelos conte�dos queriam ter maior controlo sobre o que estava online com maior rapidez.

E por isso, algures entre finais de 2000 e inicio de 2001 foi decidido avan�ar com a instala��o de r�plicas de MySQL em todos os front-ends e, do dia para a noite, fizemos upgrade do nosso MySQL para a �ltima vers�o, o que nos obrigou a alterar v�rios dos nossos sites (pois tinhamos um campo chamado show - a data de publica��o dos conte�dos) e os scripts de gera��o dos conte�dos est�ticos.

Ficamos ent�o com uma r�plica, s� de leitura, em cada um dos nossos front-ends, e todas as escritas a terem que ser feitas no servidor central. Ent�o o mysql apenas permitia replica��o unidirecional.

E com isto passamos a ter o nosso conte�do distribuido. Ao longo dos primeiros meses tivemos in�meros problemas (r�plicas que se atrasavam sem nos apercebermos, algu�m escrevia numa r�plica local e toda a replica��o para essa r�plica parava, dificuldades em levantar um novo front-end, etc), mas ficamos com capacidade para servir muito mais p�ginas din�micamente do que conseguiriamos de outra forma.

Esta foi a primeira abordagem que vi ao problema de distribuir por um conjunto cada vez mais largo de servidores.

Mas, desde ent�o muitas outras formas de abordar este mesmo problema foram surgindo, algumas delas para abordar problemas ainda mais complexos, que permitam elaborar de forma descentralizada tarefas cada vez mais complexas e morosas e n�o apenas distribuir o conte�do.

Gerar as p�ginas finais de forma est�tica � uma das formas mais simples de distribuir, pois � f�cil partilhar os ficheiros entre v�rios computadores. Mas n�o � forma de fazer muitas das coisas que todos n�s esperamos hoje de um site, como conte�do diferenciado por utilizador, actualiza��es parciais das p�ginas, ou qualquer das muitas outras coisas que o ajax permite hoje.

Gerar ficheiros de dados com os conte�dos � outra das op��es. Os ficheiros podem ser gerados por uma maquina e distribuidos para todas as maquinas que necessitem desses conte�dos, e os ficheiros s�o depois utilizados para obter os conte�dos e process�-los da forma adequada a cada situa��o. Os ficheiros podes ser distribuidos utilizando protocolos como o rsync, FTP ou o SCP, ou podem ser partilhados num filesystem de rede. Independentemente da forma de distribui��o, este tipo de sistema tem ainda o atraso da gera��o dos conte�dos.

O que nos leva �quela que � a solu��o do momento. Os sistemas de Message Queue. Neste tipo de sistemas, todos os produtores de conte�do se limitam a entregar o conte�do ao sistema de message queue, que se encarrega de o distribuir para todos os interessados nesse tipo de conte�do. E podem ser utilizados para muito mais do que apenas distribuir o conte�do. Um sistema de message queue bem implementado pode ser a base de comunica��o de uma arquitectura completamente distribuida sobre a qual se conseguem implementar sistemas bastante complexos em que as v�rias partes n�o t�m qualquer depend�ncia umas das outras, com excep��o da estrutura das mensagens que trocam entre si.

Mas, claro, sistema de message queue n�o s�o a solu��o final para todos os problemas do desenvolvimento web. Muitas das velhas solu��es continuam a ser necess�rias e �teis. Muitas delas cont�nuam mesmo a ser a melhor solu��o para o problema que resolvem.

Mas, na verdade, quantos de v�s precisam de distribuir as tarefas dos sites que desenvolvem? Quantos de v�s precisam que os vossos conte�dos estejam dispon�veis ao mesmo tempo em mais do que um servidor? Quem tem curiosidade acerca deste tipo de arquitecturas, sobre como as implementar?