O XML é aquele tipo de linguagem que pode ser usada pra tudo. Ele descreve, transporta e armazena dados quaisquer, em qualquer formato. Mas nem sempre devemos usar ele em sua maneira pura. Vou explicar:

Imagine que o XML é o nosso alfabeto (de a a z), com o nosso alfabeto podemos escrever em diversas línguas, como o inglês, português, espanhol, galego, latim e tantas outras. As letras por si só não tem significado algum, o que tem significado são as definições que cada linguagem possui. No XML também é assim, o XML em si não é nada além de uma ferramenta muito boa para construir linguagens (assim como um alfabeto).

O surgimento do XML aconteceu justamente por isso: era necessário estabelecer um “alfabeto” para descrever vários tipos de dados diferentes. Existiam muitas linguagens específicas para cada aplicação, mas elas não conversavam entre si por não usarem a mesma base (o mesmo “alfabeto”).

Tendo um mesmo “alfabeto”, o próximo problema é fazer com que as “línguas” funcionem. Não podemos por exemplo criar duas ou três linguagens pra definir equações químicas, deve haver apenas uma linguagem pra isso.

Se você usa o XML para si mesmo, por exemplo para montar uma galeria de fotos em Flash, você não estará compartilhando esse documento XML com ninguém, será apenas uma interação interna da aplicação, portanto não se faz necessário o uso de uma linguagem universal porque sua aplicação não conversará com ninguém.

Isso é bem comum, no dia-a-dia estamos sempre criando novas pequenas línguas quando trabalhamos com XML. O importante é sempre ter cuidado de usar uma linguagem mundialmente “falada” se quisermos que nossa aplicação converse com outras por aí.

Pesquisar se já existe algum tipo de linguagem XML para o que você quer é algo que pode poupar seu tempo. Criar novas linguagens em XML no começo pode até ser divertido, mas depois acaba se tornando um porre.

Na Web Semântica, existem uma porção de linguagens XML para diversos fins, eis algumas delas:

RDF/XML

Descreve metainformação no formato XML. É uma das linguagens pelas quais o RDF pode se manifestar.

RDF-S

Baseada no RDF, serve para criação de vocabulários específicos de metainformação.

OWL

Significa “coruja” em inglês, é a linguagem para criação de ontologias, também baseada em RDF.

SKOS

Linguagem para criação de tesauros (dicionários de sinônimos e palavras similares)

Por enquanto eu só falei do RDF mesmo, mas pretendo falar sobre RDF-S, OWL e SKOS em breve.

Como você usa o XML do dia-a-dia? Tem algum exemplo?

Esse é o post de número 51. Sem perceber já escrevi 50 posts desde o surgimento do blog que já tem 160 comentários!

Aqui vai uma lista dos artigos do Acorda pra Web! prediletos do autor:

• O Framework do futuro - Como iremos programar?
• Exemplos de Web Semântica
• Web Semântica pra quem viveu na primeira web
• Os três estados da matéria no CSS

Acha que faltou algum?! Comente!

E acima de tudo obrigado pelas visitas e comentários!

Programador, Analista de Sistemas, WebDesigner, Administrador de Bancos de Dados, Arquiteto de Informação, Técnico em Informática, Gerente em Tecnologia da Informação, Blogueiro, Administrador de Redes. A tecnologia da informação gera uma centena de nomes, cargos e títulos. Todos na verdade não passam de carpinteiros, no bom sentido.

A carpintaria, principalmente no primeiro milênio, era tida como de conhecimento obrigatório. Qualquer homem de família tinha que conhecer os princípios básicos de como trabalhar com a madeira, era um trabalho muito comum, embora existissem os grandes carpinteiros profissionais que faziam obras sensacionais.

Informática nos dias de hoje é conhecimento obrigatório assim como a carpintaria era no milênio passado. E assim como existiam os carpinteiros homens de família, os carpinteiros fazedores de barcos, os especializados em móveis, os especializados em construções e os carpinteiros artísticos, existem diversos tipos de profissionais na tecnologia da informação.

Talvez seja por isso que nosso trabalho seja tão desvalorizado: não passa de uma obrigação que o mercado e sociedade nos impõe, embora tenha um leque infinito de especializações.

Espero que eu esteja sendo claro: não digo que todos os profissionais da informática são iguais e que um programador deve ser comparado à uma pessoa que conhece somente o pacote Microsoft Office.

As vantagens de ser um bom carpinteiro são muitas. Você pode construir os móveis da sua própria casa, brinquedos em madeira para o seu filho e boas carroças que aguentem a força dos seus cavalos bem treinados, e isso pode até lhe garantir um serviço, mas o que o torna diferente de tantos outros bons carpinteiros de família por aí? Na informática temos um cenário muito similar. Qual é o teu diferencial?

Li agora mesmo um artigo sobre o modelo de negócios do MySQL, mostrando que projetos Open Source tem grande potencial de atingir sucesso financeiro e estabelecer organizações sólidas, deixando de lado aquela imagem de software gambiarrado.

O sucesso do MySQL teve um efeito colateral interessante: ele acabou mudando o público alvo, sem que seu público alvo antigo percebesse:

Conforme novas versões do MySQL são lançadas, novos recursos são implementados e cada vez mais o gerenciador está ficando cada vez mais próximo do ideal para aplicações que antigamente só o Oracle dava conta. Mesmo com todo esse potencial, a maioria dos usuários de MySQL são os pequenos e médios websites, como esse blog e o blog que publicou o artigo citado no começo desse post.

E o que isso muda pra nós? O MySQL está gordo demais pra um site pequeno e simples e novas soluções estão surgindo, como o SQLite, muito mais próximo da nossa realidade.

Será que isso significa que as grandes soluções OpenSource se tornarão específicas para grandes aplicações?

Atenção: Essa é a minha opinião baseada em fatos apresentados nos links. Se você tem uma opinião diferente, sinta-se à vontade para comentar, estou sempre aberto a novas opiniões!

Alguns fatos sobre PHP e Ruby:

• PHP carrega nas costas quase 10 anos de experiência.
• Ruby tem sérios problemas de escalabilidade.
• Construir um blog simples em Rails demora 15 minutos. Instalar o melhor sistema de blogs já criado (feito em PHP) demora 5 minutos.
• Comparar o Rails diretamente com o PHP é injusto, já que o primeiro é um framework e o segundo uma linguagem.
• Existem diversos frameworks para PHP similares ao Rails.
• A melhor documentação de uma linguagem web é do PHP, contando com detalhes e comentários ricos em praticamente todas as funções e estruturas de linguagem.
• PHP é uma linguagem um pouco confusa pela quantidade de símbolos.
• Wikipedia, del.icio.us, Flickr, Kelkoo, Digg e muitos outros serviços online dessa nova geração usam PHP.
• LAMP ainda é a alternativa mais barata para construir um site. Vários itens nessa lista também indicam que é além de barata, uma das mais eficientes.
• Existem funções demais no PHP e falta de padronização nos nomes.
• O PHP mantém um repositório semelhante ao apt-get, chamado PEAR. É possível conseguir código pra quase qualquer coisa por lá, automaticamente.
• Existem alguns bugs no PHP, no entanto é fácil identificar e evitar os mesmos com uma simples busca no Google.
• A comunidade PHP fornece, de graça, praticamente qualquer tipo de biblioteca necessária.
• É um mito que PHP é um código de difícil manutenção, isso é passado desde a orientação a objetos.
• PHP come Ruby no café da manhã.
• Ruby on Rails é mais divertido de programar, mas só é mais rápido pra programadores iniciantes.

Ruby exige menos linhas de código? é mais intuitivo? Nem sempre.

Alguns exemplos:

Exibir itens de uma array em Ruby:
<%
array = ['lista', 'de', 'itens']
array.each_with_index { |item, index| p “#{index}. #{item}” }
%>
Olha a leitura de nível desse código: “array com cada índice (item índice mostra índice item)”. Fácil de entender? Não pra mim.

Exibir itens de uma array em PHP:
<?
$array = array('lista', 'de', 'itens');
foreach ($array as $index => $item) { echo "$index. $item"; }
?>
Leitura de nível do mesmo código em PHP: “para cada array como indice => item (mostra índice item)”.

Eu prefiro PHP!

*Foto no artigo por Marcelo Gerpe.

Recentemente rolou na Blogosfera uma discussão sobre links, se devem ou não e quando devem ser abertos em novas janelas.

As soluções apresentadas foram várias, mas nenhuma me satisfez. Eis aqui todas elas e no final a minha própria solução:

O bom e velho target=_blank

Essa solução é a mais simples, você escolhe os links que quer abrir em novas janelas adicionando o atributo target com valor _blank ao elemento do link.

É uma solução incorreta, porque o atributo target é depreciado por não ser semântico.

O novo rel=external

A solução mais correta é o atributo rel com valor external. Semanticamente ele mostra que seu link não é interno no site, ou seja, aponta para um domínio de fora.

Infelizmente os navegadores não lêem que isso deve ser aberto em uma nova janela, o que acaba tornando necessário um script para fazer a mágica:

function externalLinks() {
if (!document.getElementsByTagName) return;
var anchors = document.getElementsByTagName("a");
for (var i=0; i<anchors.length; i++) {
var anchor = anchors[i];
if (anchor.getAttribute(”href”) &&
anchor.getAttribute(”rel”) == “external”)
anchor.target = “_blank”;
}
}
window.onload = externalLinks;

O Último Problema e a Última solução

Com as duas técnicas acima, qualquer usuário que entrar na sua página abrirá os links externos em uma nova janela, ele não terá opção de escolha.

O ato de abrir em uma nova janela é mais comum a pessoas que fazem pesquisa e não leitura, e geralmente usuários avançados não gostam que o site abra automaticamente em uma nova janela.

Pra evitar isso, o correto seria fazer com que links contento rel=external abrissem novas janelas somente quando o usuário viesse de algum sistema de busca.

O script em PHP à seguir identifica quando um usuário vem do Google ou Yahoo e somente ativa a abertura de novas janelas para esses visitantes:

<?php
if (stristr(getenv('HTTP_REFERER'),"google")||stristr(getenv('HTTP_REFERER'),"yahoo")) {
echo <<<extlinks
<script type="text/javascript"><!--
function externalLinks() {
if (!document.getElementsByTagName) return;
var anchors = document.getElementsByTagName("a");
for (var i=0; i<anchors.length; i++) {
var anchor = anchors[i];
if (anchor.getAttribute(”href”) &&
anchor.getAttribute(”rel”) == “external”)
anchor.target = “_blank”;
}
}
window.onload = externalLinks;
</script>
extlinks;
}
?>

Se você tem WordPress, pra implantar essa solução, basta copiar o código acima e incluir no template Header, logo acima do fim da tag </head>. Se alguém souber fazer um plugin pra isso (eu não sei) eu gentilmente coloco o link e créditos aqui

Fácil né?

O título significa “um elegante (posh) beijo (kiss) seco (dry)” em um péssimo inglês, mas não se asssustem! Não vou falar sobre sentimentos.

POSH, DRY e KISS são três siglas, cada qual correspondente a uma metodologia de desenvolvimento web. Siglas são legais porque são uma boa maneira de divulgar a coisa toda.

A primeira que ouvi foi a KISS, (Keep it simple, stupid), que prega a metodologia de manter as coisas simples, não complicar demais. Isso vale tanto pra programação, interface, HTML, CSS e até pra vida (não, o Acorda pra Web não é um blog de auto-ajuda).

DRY (Don’t repeat yourself) é uma característica que vi pela primeira vez no framework Ruby on Rails. Faça as coisas focando não repetir o que já foi feito. Isso economiza tempo, facilita manutenção e evita erros na hora de programar.

E finalmente POSH (Plain old semantic HTML) é a mais recente delas, surgiu em uma discussão sobre Microformatos. Não é nada muito novo, apenas reforça algumas idéias na hora de desenvolver de acordo com os padrões:

• Valide a marcação, em primeiro lugar.
• Se livre das tags de apresentação, fique com conteúdo apenas.
• Se livre de tabelas e gifs espaçadores.
• Não construa links anoréxicos. (Coloque o atributo title, atributos rel, classes e enriqueça seu link :)).
• E tudo de bom que o HTML pode nos oferecer!

Nem vou me preocupar aqui em colocar links e definições sobre essas boas-práticas, eu só vim mostrar mesmo a sigla. Se alguém te encher com conversas de padrões versus tabelas, POSH nele.

Pode parecer irônico, mas posts demais por dia em um blog não são bons. Inclusive o famoso Darren já citou essa característica como a principal para desassinarem seu feed.

Aqui no Acorda Pra Web eu me seguro para manter uma média de um post por dia, tentando sempre postar diariamente. É complicado entender quantos posts já tornam um feed exagerado, acredito que depende muito da qualidade e do tamanho dos posts.

Existem feeds com vários posts diários que eu não acho incômodo, como o do MeioBit e da Comunidade Tableless, por terem ótimo conteúdo e principalmente conteúdo completo (a terceira maior taxa de desassinação de feeds é cortar os posts pela metade).

Não tenho acesso, mas gostaria muito de ver as estatísticas de crescimento (em número de assinantes) da Comunidade Tableless e da Rede Brasil, que são ótimos exemplos de quantidades diferentes de posts por dia e podem dar uma ótima fonte de estatísticas.

Às vezes, se você está em um dia criativo, compensa guardar seu post extra como rascunho pra um dia que você não tiver tempo ou estiver sem nenhum assunto interessante para publicar. É claro que alguns posts exigem publicação imediata, principalmente se seu blog gosta de cobrir notícias, eventos e lançamentos (só que nesse caso os leitores já esperam por esse grande volume de posts).

Esse blog é minha primeira experiência com WordPress. À princípio eu odiei pela falta de semântica no HTML e dificuldade pra editar os templates.

Eu gosto muito de ter uma visão geral do template pra montar o CSS e o WordPress me entrega ele todo em pedacinhos. Pra construir pela primeira vez até que não dói tanto, mas a manutenção é um sofrimento só. Pelo menos já acostumei com isso.

Ele também não é muito rápido, o desenho do banco de dados em MySQL é meio estranho e confuso, não parece otimizado. Inclusive já pensei em adotar o LightPress (uma modificação do WordPress), só voltei atrás pela falta de suporte à plugins.

O que mais gosto no WordPress inclusive é a diversidade de plugins. É perfeitamente possível montar praticamente qualquer tipo de página com o WordPress, desde um fórum até uma loja virtual.

Ele até deixa você editar os templates, estilos e tudo mais, mas não incentiva que você o faça. As páginas ficam todas muito parecidas e mal-acabadas. Admiro quem consiga deixar um WordPress com visual bonito e livre do “padrão” de qualquer outro tema.

Customizar o WordPress é difícil. Eu gostaria até de algumas dicas, alguém tem?

Enquanto isso eu fico aqui, aproveitando a versatilidade dele, aguardando pelo CMS ideal (que talvez seja o SemSol).

Não sei se a falta de estudo leva as pessoas a praticarem crimes virtuais, mas de uma coisa eu tenho certeza: Golpistas, mentirosos e ignorantes são campeões em erros de português, isso é um fato.

Entrando no Quatrocantos, uma das melhores referências sobre hoaxes na internet, é comum ler notas sobre erros de português grosseiros e erros de concordância em cada hoax spam.

O mais recente que vi foi nesse post que fala sobre um spam que promete conceder vistos americanos em 48 horas. Olhem só o nível da escrita:

• Visto por meios legais atravéz de federações esportivas;
• Não há cobrança de taxas adiantadas;
• Antecipação para agendamento para visto americano em três consulados.

Além de escrever palavras erradas, comete erros de concordância primitivos.

Eu ignoro completamente textos com erros de português estúpidos demais. Por que devo considerar uma informação que provavelmente foi escrita por um leigo, não teve qualquer revisão e além de tudo dificulta minha leitura?

Fazer pequenas abreviações e cometer pequenos errinhos usando algum comunicador instantâneo (como o MSN, Google Talk, etc.) é comum, faz parte de um tipo de linguagem coloquial dentro da internet. Só que publicações não são conversas e devem ser escritos com português correto.

Se você quer evitar vírus, mentiras, hoax, enganadores, charlatões e picaretas: aprenda português.