Um pouco sobre certificações (W3C)

Ontem aconteceu a Conferência da W3C Brasil. Infelizmente não pude ir, mas acompanhei tudo pelo twitter através da hash tag #webbr2009.

Diversos assuntos foram discutidos neste dia, dentre eles o que mais me chamou a atenção foi a quantidade de opniões divergentes com relação ao ter ou não ter certificações para os profissionais que lidam com o desenvolvimento front-end todos os dias.

De todas as opniões que foram expressadas neste dia, se juntar tudo e fazer uma categorização das opiniões, vocês vão ver que tudo gira em torno da desilusão dos profissionais quanto a este assunto.

Vi muitas pessoas sendo contra a certificação, pelo fato de muitos ja terem comprovado e sentido na pele o grande interesse de algumas instituições – que prefiro não citar – em vender somente o papel e não o conhecimento.

Depois da discussão que tive com alguns amigos que trabalham na área pude ver que as pessoas não são desiludidas com A CERTIFICAÇÃO em si. Os profissionais estão desiludidos na maneira como ela é vendida e mantida pelas instituições e a forma como as empresas fazem a utilização desta certificação.

A certificação é vendida como se fosse um curso qualquer. Onde o candidato à certificação entra em uma salinha, responde umas perguntas e sai certificado. O que é uma demonstração CLARA de que as instituições não estão nem um pouco interessadas no nível do profissional que sai dali com este papel de baixo do braço e sim pelo dinheiro dos que acreditam que este papel vai mudar o seu mundo – o que tem uma pitada de verdade.

Vi também que muitos estavam “indignados” pelo fato das empresas utilizar tais certificações como filtro em um processo de seleção. Veja bem, eu também acho isso uma sacanagem mas não acho isso, o fim do mundo. A empresa tem um senso equivocado as vezes pensando que se eles ignorarem todos os que não tem certificação e entrevistar somente o que tem estarão fazendo um bom negócio pois os que não tem é lixo – na visão deles.

Mas por outro lado em grandes corporações este filtro serve puramente para agilizar o processo. Imagina uma empresa com uma fila de 3 mil candidatos a uma vaga. Eles iriam demorar 5 anos para entrevistar todo mundo da forma mais humana e minuciosa possível, mas infelizmente, eles acreditam que mesmo ignorando 2 mil sem certificações eles acreditam que pelo menos 10% destes mil que sobraram sejam bons profissionais.  Se pensarmos por este lado, é totalmente aceitável o filtro quando aplicado em uma situação como esta – mesmo sabendo que eles podem ter perdido os steve jobs pessoal deles. Steve Jobs não tem nível superior, imagina ele procurando emprego? milhares de empresas aplicando seus filtros em cima de uma mente brilhante, cool. 😉

A minha opinião sobre estas certificações é: Devemos sim ter certificações. Quanto mais o nosso ramo amadurecer neste sentido e ter instituições que comprovem e testem os profissionais que atuam neste meio é mais um passo que damos rumo a extinção dos sobrinhos. Quanto mais formal tornarmos o nosso ramo de trabalho, mais dificulta o acesso das empresas sérias a profissionais sem compromisso e consideração com o ramo e as pessoas que atuam nele. Tevemos sim ter certificações, talvez tenhamos que amadurecer melhor esta idéia e talvez não oferecermos uma certificação de HTML ou CSS mas sim de Padrões Web, quem sabe…

Se a forma como tudo é “vendido” mudar, estas certificações servirão como uma forma de valorizar o profissional que possui esta certificação. Tudo tende a agregar valor.

Este é um ótimo assunto e que diferente de só fornecer a certificação, devemos GARANTIR que o profissional que porta este selo é um profissional que no mínimo se importa com a gente, com a nossa luta e principalmente, com o cliente.

Meu amigo Chris também falou e apontou suas consideração sobre o debate, vale a pena dar uma lida também.

[]’s
Igor.

Posts Relacionados:

10 Dicas JavaScript e Boas Práticas

Recentemente alguns site e blogs vem divulgando listas de dicas para se codificar em javascript. Apresentando melhores práticas de desenvolvimento e muitas dicas bacanas, Pensei que este seria um bom tópico para se extender e compartilhar com vocês. Neste post estou reunindo as minhas top 10 dicas e boas práticas para codificação javascript.

Espero que gostem.

1. Use o atributo defer para indicar o uso scripts externos no IE

O propósito do defer é avisar o script que está sendo requisitado externamente para esperar  até que a página seja carregada ou o DOM esteja preparado. O mesmo pode ser realizado através de bons métodos não-obstrutivos via javascript, que usualmente inclui códigos que previne a execução de scripts antes que o DOM seja carregado por completo.

A vantagem do defer ocorre quando utilizamos o Internet Explorer, tendo em vista que é único browser que suporta o atributo defer. Então, se você precisa de um rápido script que rode únicamente e exclusivamente no Internet Explorer, e você não quer que ele execute antes que o DOM esteja preparado, então simplesmente adicione defer="defer" no sua tag <script> e ela irá rapidamente tratar o seu problema. Corrigir a transparência de arquivos PNG no IE6 é uma das possibilídades práticas do uso do defer.

(Edit: O atributo defer deve ser usado quando escondemos um script de outros browsers com o uso dos comentários condicionais  – conditional comment – que afete somente os navegadores da Microsoft – de outra maneira o script vai rodar normalmente em outros browsers.)

2. Use o CData Section para previnir erros de validação XHTML Strict

Muitas vezes seus scripts vão residir em arquivos externos e chamados dentro da tag <script> dentro do  <head> do documento, ou então antes do fechamento da tag </body>.

Mas este documento pode estar eventualmente usado em um local que junto dele existem marcações HTML, como abaixo:

<div>
<p>
<script type="text/javascript">
var my_variable = 100;
if (my_variable < 50) {
// alguma coisa aqui...
}
</script>
</p>
</div>

Você pode notar que no código acima, dentro do if, existe o símbolo <  que representa “menos”, que é parte da sintax, corréto? Este símbolo causa um erro de validação. O validador interpreta ele como um inicio de uma marcação ou uma tag HTML que não foi fechada, a não ser que você encapsule o seu código com o CData, assim:

<div>
<p>
<script type="text/javascript">
//<![CDATA[
var my_variable = 100;
if (my_variable < 50) {
// alguma coisa aqui...
}
//]]>
</script>
</p>
</div>

3. Evite palavras-chaves reservadas do JavaScript quando estiver criando funções e identificadores

Muitas palavras são reservadas no javascript, então você deve evitá-las quando forem criar variáveis ou outros idenficadores. A lista completa de palavras-chaves do javascript segue abaixo:

break
case
catch
continue
default
delete
do
else
finally
for
function
if
in
instanceof
new
return
switch
this
throw
try
typeof
var
void
while
with

4. Evite palavras reservadas do JavaScript quando estiver criando funções e identificadores

Que estão também algumas palavras reservadas, que não estão necessariamente sendo usadas pela linguagem mas são reservadas para o uso futuro. São estas:

abstract
boolean
byte
char
class
const
debugger
double
enum
export
extends
final
float
goto
implements
import
int
interface
long
native
package
private
protected
public
short
static
super
synchronized
throws
transient
volatile

5. Não mude o tipo das variaveis depois da declaração inicial.

No javascript, tecnicamente, isso é perfeitamente legal:

var my_variable = "Esta é uma string";
my_variable = 50;

Depois que a variável é inicialmente declarada como string na linha 1, na linha 2 o seu valor é mudado e o seu tipo também. Esta não é uma boa prática e deve ser evitada.

6. Não use variáveis globais.

Para previnir possíveis conflitos, em 99% dos casos, use o “var” no início quando estivermos declarando uma variável e seu valor. Isso faz com que a sua variável exista somente no escopo da função e não fora dela, ou seja, toda variável criada pelo var, só poderá ser acessível dentro do escopo no qual ela foi declarada e não mais fora dele. Então, se acontecer de você utilizar duas variáveis com o mesmo valor em lugares diferentes do seu script, nenhum conflito ocorrerá.

7. Javascript é Case-Sensitive.

Lembre-se do que vem a seguir: No código que segue temos duas variáveis que estão armazenando seus valores em 2 lugares diferentes na memória, e não um só, como alguns podem pensar. São duas variáveis completamente diferentes alocadas em lugares diferentes na memória:

var myVariable = "data";
var myvariable = "more data";

8. Use o switch para lidar com multiplas condições

Não faça isso:

if (example_variable == "cyan") {
// faça algo aqui...
} else if (example_variable == "magenta") {
// faça algo aqui...
} else if (example_variable == "yellow") {
// faça algo aqui...
} else if (example_variable == "black") {
// faça algo aqui...
} else {
// faça algo aqui...
}

Faça isso:

switch (example_variable) {
case "cyan":
// faça algo aqui...
break;
case "magenta":
// faça algo aqui...
break;
case "yellow":
// faça algo aqui...
break;
case "black":
// faça algo aqui...
break;
default:
// faça algo aqui...
break;
}

O segundo bloco de código faz exatamente a mesma coisa que o primeiro – mas o segundo é limpo, fácil de ler, fácil de dar manutenção e modificar.

9. Use o try-catch para previnir que erros sejam expostos para os usuários

Encapsulando todo o seu código no try-catch, você pode evitar que o usuário final nunca veja um feio erro de javascript exposto na tela. Assim:

try {
funcaoQueNaoExiste();
} catch (error) {
document.write("Um erro ocorreu.")
}

No código acima, eu tentei chamar uma função que não existe, para forçar um erro. O navegador não vai exibir o típico erro “not an object” ou “object expected”, mas ao invés disso, vai exibir um erro mais customizável que eu incluí dentro do meu “catch”. Você pode também deixar o catch vázio para nada ser mostrado para o usuário, ou você pode criar uma função que seja chamada dentro do catch que faça o tratamento deste erro para propósitos de debug etc.

Mantenha na sua cabeça que isso pode esconder erros do desenvolvedor também, então uma boa decumentação do código e comentários podem ser úteis neste ponto.

10. Faça comentários multi-linhas legíveis, mas simples

Em javascript, você pode comentar uma linha de código colocando um // no início da linha. Você também pode criar um comentário em bloco como mostra a seguir: /* [comentário aqui ] */. Algumas vezes você precisa incluir um comentário longo, um comentário de mais de uma linha. Um bom método para se utilizar que não tenha uma visual esmagador, mas é fácil de identificar o código é esse a seguir:

/*
* Este é um comentário multi-linha...
* bla bla bla...
* bla bla bla...
* bla bla bla...
* bla bla bla...
*/

E é isso 🙂

Este artigo é uma adaptação e tradução do texto: 10 JavaScript Quick Tips and Best Practices

Posts Relacionados:

As microempresas e a pseudo-vontade de aderir os padrões.

Acredito que a grande maioria de vocês, senão todos vocês, começaram de baixo, em uma empresa pequena, com poucos funcionários porém lutadora.

De todas as pequenas que trabalhei, lembro-me que a Web 2.0 era (e ainda é) utilizada como uma forma de atrair e conseguir clientes, era Web 2.0 aqui, Web 2.0 lá, os donos das empresas utilizavam o termo, mais nem sabiam ao certo, que ele queria dizer, eles só sabiam que isso estava atraindo a curiosidade dos clientes e eles depositavam as suas esperanças nessa tal de Web 2.0 (na época) a Web 2.0 já estava sendo muito bem falada, estruturada e aplicada por algumas grandes empresas que possuíam uma boa organização e principalmente maturidade.

Era mais ou menos igual aquela propaganda da escova de dentes com o limpador de línguas: – Quando crescer, vou querer ser como você.

Tudo bem, admirar não faz mal a ninguém, mas a maioria das empresas acabavam dando um passo maior que as pernas para poder logo sair contando para os clientes que podem desenvolver sistemas utilizando os conceitos que a Web 2.0 trazia.

A Mudança

Toda empresa esta familiarizada principalmente os lideres a desenvolver sites da forma tradicional, abrir um editor WYSIWYG (Ex: Dreamweaver) e sair criando tabelas, inserindo as imagens do layout, os textos etc, sem nem olhar o que esta sendo criado por trás. Este era o cenário a anos atrás.

São poucas as microempresas que possuem maturidade o suficiente para entender o passo que é começar a desenvolver utilizando conceitos da Web 2.0.

O cronograma aumenta, mais processos no ciclo de vida do projeto são acrescentados, pessoas precisam ser contratadas (dependendo do caso), documentação aumenta, o paradigma do desenvolvimento fica mais complexo e detalhado…tudo aumenta.

Toda essa adição de pessoas, processos e complexibilidade é consecutivamente convertida em mais despesas e mais tempo aplicado a um único projeto. As micros querem isso? na visão deles é Web 2.0 pra todos os lados na cabeça do cliente, e o melhor, sem adição no custo, e no prazo.

Quem apanha no final?

O coitado do programador que tem que fazer milagres em um curto intervalo de tempo, o coitado do cliente, que só queria o site dele prontinho em Web 2.0.
Mas quem toma o maior prejuízo no final, é a própria empresa que acaba tendo que gastar muito mais do que o vendido para o cliente, principalmente para correção de bugs e melhorias de processos que não ficou como o cliente esperava ou de acordo com a realidade da empresa.
Resultado: O Cliente fica insatisfeito, desiludido com essa tal de Web 2.0, nunca mais volta a ser cliente da empresa, fala mal de você para toda a direção da empresa e dependendo do desgaste até para a família.

A Web 2.0 trás conceitos inovadores que podem tornar uma pequena empresa, em uma grande empresa criadora de soluções e ideias. Mas toda essa força e os seus “benefícios” pode se virar contra a própria empresa e contra o seu próprio usuário, se a empresa não possui um processo sólido, com foco principalmente, no ciclo de vida de um projeto.

Para quem já trabalhou em uma pequena empresa, na época do boom empresarial em prol da Web 2.0, sabe o que eu estou falando.

Claro, que este cenário hoje já esta mudando muito, mas o velho ditado diz: Antes de melhorar, vai piorar…muito!

Tem empresas que aprendem na prática, outras aprendem na teoria para apanhar menos na prática ou caem naquilo que eu falei anteriormente, contratar mais pessoas!
Aplicar os conceitos da Web 2.0 nos seus projetos é uma questão de puro planejamento e estratégia se você entrar nessa só por entrar e ficar com um pé na web 2.0 e outro na 1.0 isso só vai fazer a sua empresa afundar e se comprometer cada dia mais com seus clientes.

Esta é uma visão minha, baseando-se em todas as pequenas empresas que eu trabalhei, se alguém possui um ponto de vista diferente e queira compartilhar, por favor, os comentários são abertos e muito bem aceitos.

Espero ter contribuído!
[]’s

Posts Relacionados:

Web Standards vs. Projeto em dia

Principalmente nas micro-empresas este é um dilema muito comum e recorrente na cabeça dos pobres desenvolvedores.

Muitas vezes o fator web standards nem é um pré requisito no projeto, acontece que a grande maioria dos programadores que entendem a essência dos Web Standards, gostam e sabem, o motivo da utilização dos padrões no projeto.

O grande problema surge, quando o cliente pede algo “lunar” e nós, desenvolvedores temos que entrar no mundo highlander do cliente e desenvolver soluções a altura.

Acontece que, geralmente, soluções mirabolantes requerem implementações mirabolantes, consecutivamente, o nível de manipulação do documento XHTML por meio de Javascript é alto e muitas informações são expostas na marcação HTML, para que o JavaScript possa se guiar.

Tenho certeza que de todos os meus leitores, pelo menos um! vai se identificar com um caso parecido.

O grande pensamento vem a cabeça:

– O sistema não esta validando, e agora? eu só consigo implementar esta solução desta forma, não consegui pensar em outra forma de implementar, e fazer com que meu código consiga se guiar de maneira eficiente, para manipular este documento.

– Perco mais 1, ou 3 dias pensando em uma nova solução somente para implementar esta solução sob o plano B ou deixo este erro de validação passar e sigo em frente com o cronograma?

Caros amigos, não se desesperem. Já se foi o tempo onde os programadores eram neuróticos por validação.

Isso já cansou de ser dito: – Validar o seu código pela W3C nada mais é do que verificar se o seu código esta “gramaticalmente” escrita de maneira correta, ele estar validado não garante que o seu código será renderizado da mesma forma em outros navegadores.

E entramos no dilêma da guerra dos browsers. Você segue os padrões, mas o browser do seu cliente não, e ai? o que acontece depois ? …

Se você se preocupa com os padrões, ótimo!, Deve!

Colocar em risco o ciclo de vida do projeto por causa de um erro de validação não compensa para você nem para sua empresa, pode ter certeza que se você tiver somente este erro, o seu site/sistema não vai se comprometer ou deixar a desejar para o seu cliente.

Pense muito bem na hora de fazer esta decisão. Se você tem um código 100% validado, ótimo! se você tem próximo a 95% validado, ótimo também!

A grande sacada deste texto é mostrar pra vocês que foi se o tempo onde as pessoas eram loucas e fissuradas pelo validador da W3C. O validador deve ser somente ser usado como parâmetro para verificar a sintaxe do seu código XHTML, muitas coisas podem passar despercebido na correria do desenvolvimento, da mesma forma que muitas coisas podem ser corrigidas sem comprometer o andamento do projeto com a “ajuda” do validador.

Use o validador como uma ferramenta aliada e não como uma ferramenta inimiga.

O W3C é uma organização que documenta “recomendações” e não “obrigações”, existe as recomendações que são extremamente fundamentais para a renderização e comportamento correto em diferentes plataformas, porém, temos que ter um meio termo para tudo.

Links

Espero ter contribuído!
[]’s

Posts Relacionados:

Tableless, o termo maldito ?

Recentemente, vi alguns profissionais e blogueiros revoltados com a repercussão do termo “Tableless” na mente dos pobres alunos e aprendizes.

Pensamento Tableless

Meu objetivo com este texto, é tentar salvar as pobres mentes puras de alguns destes aprendizes que talvez cheguem até aqui através dos buscadores, sites que estejam licando a matéria, etc. Provavelmente grande parte dos meus leitores já saibam exatamente o significado deste termo e como utilizar esta técnica na prática, o aprendizado é inevitável, cedo ou tarde você acaba descobrindo o que é Tableless de fato.

O Problema

O termo Tableless veio à tona no Brasil em 2003, pelos amigos Elcio Ferreira e Diego Eis, fundadores do site www.tableless.com.br, que incentiva o uso da técnica, com exemplos, mostrando benefícios, boas práticas de desenvolvimento e diversos assuntos que giram em torno do código fonte do desenvolvedor. Para a maioria destes aprendizes, este site pode se tornar evangelizador (rs), você entra crendo no poder das tabelas e sai como table-killer.

Esta é a visão interpretada pela maioria das pessoas. Sempre que alguém começa a ler sobre o termo, logo quer sair botando a mão na massa, e contar para todo mundo: – Agora eu sei Tableless, é fácil, é só nunca mais usar tabelas ;)

As pessoas tendem a ler o conteúdo pela metade ou rápido demais, ignorando detalhes, afinal, a sua teoria já esta embutida no seu próprio título certo? Errado!

Eu não sei ao certo o que acontece. É difícil identificar de quem é a culpa, enfim, de duas, uma:

Pode ser nossa (disseminadores de conteúdo), que passamos a informação as vezes incompleta, sem muita clareza, omitindo alguns detalhes, ou a culpa é do próprio leitor.

Tableless – Definitivo

O termo Tableless fez começo de 2008, 5 anos que o termo vem sendo falado, estudado e colocado na prática no Brasil.

O Tableless é um técnica de desenvolvimento web cujo o foco esta exclusivamente no seu código fonte. Antes de aplicar o tableless e sair por ai saltitando, estude a semântica das tags, amplie o seu conhecimento em relação às tags, se você não conhece o HTML a fundo, sua capacidade de criação de interfaces com Tableless fica muito limitada, e exposta ao famoso “jeitinho brasileiro” ou gambiarras, como preferir.

Tableless não é NUNCA mais usar tabelas, Tableless é usar as tags do HTML respeitando os seus valores semânticos, se você programa sob esta filosofia, automaticamente seu código no final será um código, semântico, compatível e claro, Tableless.

As tabelas foram criadas para exibição de dados tabulares e não para estruturação de layout e criação de interfaces.

A W3C diz:

“Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media.”

Tabelas não podem ser utilizadas meramente para definição da estrutura do seu layout, isso provavelmente vai gerar problemas na rederização para midias não visuais.

Se você parar para fazer uma análise, vai ver que é uma resposta meio lógica, se a web 2.0 encoraja o uso dos padrões web para o desenvolvimento, por que o Tableless, que é um técnica que surgiu junto com o amadurecimento da web, iria encorajar o contrário?

O termo talvez gera dúvida na cabeça das pessoas por que todos os lugares que você encontra fonte de informação principalmente no tableless.com.br fala-se muito em livre-se das tabelas, o fim das tabelas, tabelas nunca mais etc.

O autor do texto repete muito isso somente para fixar o objetivo do técnica e enfatizar o resultado em si. Mas em nenhum momento é citado que você deve esquecer as tabelas, se fosse somente isso, esquece-las, seria simples, tudo gira em torno de como se virar sem elas para fazer o básico o resto é com você.

Tableless = Menos tabelas (rs) e não livre de tabelas ou sem tabelas ou qualquer outra variante.

Aceita uma dica? Não leve as coisas tão ao pé da letra, tente entender o por quê das coisas antes de mudar.

Eu sei que este texto não vai chegar nem a 0,00000001% das pessoas que estão começando com desenvolvimento web, mas se este texto pelo menos ajudar uma pessoa a pensar diferente sobre o Tableless se encontrando na definição dos termos já vou ficar contente.

Links Úteis:

Espero ter contribuído!
[]’s

Posts Relacionados:

  • Nenhum post relacionado!

A importância das tags

Quando queremos estudar sobre qualquer assunto, é muito importante pesquisar não só o assunto em si, mais também, grande parte dos assuntos que o cercam, este é um grande diferencial que se levado a sério pode se tornar uma grande característica.

Por quê devo estudar a semântica das tags?

Quando falamos de semântica não falamos de uma só coisa, existem várias técnicas de codificação e formatação de hiper-textos que só podem ser concluída com êxito se levado o conhecimento semântico das suas tags e propriedades a sério como o tableless por ex.

Imagine como seria a criação de um layout tableless, se existissem somente 15-20 tags HTML, sim! aquelas principais que é mais comum de se encontrar nos layouts.

Imagine quantos ids e classes diferentes teríamos que criar, para definir todo o padrão visual de um site, se todas as tags se resumissem em 10 ou 20 tags de marcação que muitos estão acostumados a utilizar.

Então…qual a importância de conhecer o valor semântico das tags? ou melhor, não só das tags que você conhece , mas procurar conhecer novas tags sua história de uso e aplicação.

Quem trabalha com a criação de sites à muito tempo, pode ver na prática a diferença quando se conhece um numero limitado de tags e um numero mais abrangente, são dois lados da moeda, levando em conta que o estudo semântico das tags, não era levado muito a sério pelos desenvolvedores na época em que tudo se resumia em tabelas.

A codificação do seu documento html/xhtml fica muito mais rápida e menos “melosa”, quem não acha um saco ter que ficar toda hora lembrando o nome “daquela” classe ou “aquele” id definido no css para que uma tag assuma uma característica visual?

Quando conhecemos um numero maior de tags, podemos deixar o nosso código muito mais ramificado/desmembrado e independente de outros recursos, sem falar na hora da manipulação do documento utilizando DOM, tudo fica muito mais fácil e prático, por que eu só preciso simplesmente, criar o conteúdo, formata-lo, livre de classes e ids e com um código CSS bem escrito, toda a sua formatação e forma é automaticamente assumida.

Para tudo existe uma razão!

Enfie insto na cabeça, para tudo existe uma razão, todas as tag que conhecemos, foram criadas por um motivo, para atender uma demanda, por isso devemos estuda-las para utilizarmos somente para o que ela for pré-destinada.

Aonde posso aprender mais sobre semântica?

Separei alguns links interessantes para você que se interessa sobre o assunto e ainda tem “aquela” preguiça de pesquisar mais sobre o assunto, é muito complicado colocar no papel todos os benefícios de se aderir esta “característica” que comentei no começo do texto, somente utilizando na prática para poder saber o quão transformador pode ser este habito.

Web Semântica é uma extensão da Web tradicional
http://www.bax.com.br/news/News_Item.2004-04-29.8261853316

As premissas da Web Semântica
http://outrolado.com.br/Artigos/as_premissas_da_web_semantica__

A Semântica é que manda
http://www.tableless.com.br/a-semantica-e-que-manda

Introdução à semântica web
http://revolucao.etc.br/archives/introducao-a-semantica-web/

Web Semântica
http://www.encontros-bibli.ufsc.br/Edicao_18/2_Web_Semantica.pdf

Semântica Web
http://revolucao.etc.br/archives/category/semantica-web/

A web Semântica
http://www.tableless.com.br/a-web-semantica

Podcast – Microformatos e Semântica
http://brunotorres.net/blogbits-podcast-8-microformatos-e-semantica

Site recomendado – Semântico
http://www.semantico.com.br/

Introdução à web semâtica
http://www.acordapraweb.com/acorda-uma-introducao-a-web-semantica/

Espero ter contribuído!
[]’s

Posts Relacionados: