Web Standards

Hoje em dia, o mínimo que se espera de um bom desenvolvedor web é o conhecimento dos Web Standards, XHTML e CSS. Eles contribuem para a criação de documentos mais consistentes entre si, mais compatíveis e de manutenção extremamente mais simples. Aliás, o conhecimento dos padrões não é mais um diferencial como era há alguns anos atrás, mas sim um requisito básico. Se hoje sonhamos com a web semântica, os padrões web são o primeiro passo. Com documentos mais semânticos, temos mais acessibilidade e também mais relevância, principalmente no que diz respeito a motores de busca.

Mesmo depois de muita evangelização, ainda temos desenvolvedores que acabam de descobrir as maravilhas do mundo validado. Também temos aqueles que não fazem a mínima idéia do que isso signifique, ou que não tem o mínimo interesse em aprender. Se você é um desses, hora de rever seus conceitos…

JavaScript

O JavaScript, apesar de ter sido muito injustiçado no passado, é uma linguagem onipresente, e de extrema importância. Qualquer usuário tem pelo menos um interpretador instalado em seu computador. Além do mais, ela é a única linguagem client-side disponível, e permanecerá assim por um bom tempo.

JavaScript vai ser a próxima grande linguagem. Apesar de ainda estarmos longe de resultados surpreendentes, caminhamos rápido nesse sentido. Muita coisa que antigamente só era possível com Flash hoje é feita com JavaScript.

Além da própria linguagem, aprenda a usar alguma biblioteca, como Mootools, jQuery ou Prototype. Aliado a essas ferramentas, você poderá criar aplicações muito mais interessantes em muito menos tempo. Mas atenção: não aprenda somente a biblioteca, sem aprender antes JavaScript puro. Afinal, saber só jQuery é coisa de designer.

Expressões Regulares

Um simples replace nem sempre é suficiente quando trabalhamos com manipulação de textos. Aí entram as Expressões Regulares, poderosa ferramenta que todos conhecem, alguns usam, e poucos realmente sabem. Seja em PHP, Ruby, Python ou mesmo JavaScript, algum dia você precisará delas.

Se você leva desenvolvimento a sério, dedique um tempo a aprender expressões regulares (Expressões Regulares – Uma Abordagem Divertida é um bom começo!). Além de uma ferramenta de desenvolvimento, elas podem se tornar ferramentas de produtividade. Se você usa IDEs com suporte a busca e substituição com expressões regulares, pode se beneficiar muito disso.

Controle de Versão

Para alguns, o Controle de Versão mudou completamente, e para a melhor, a forma de trabalhar. Para outros, parece simplesmente inútil, principalmente para quem trabalha sozinho. Seja CVS, SVN, GIT, Mercurial ou qualquer outro, o controle de versão, aliado a ferramentas como o Trac, pode fazer maravilhas. Além de manter controle de suas alterações, podendo sempre voltar atrás caso alguma modificação dê errado ou mesmo quando o cliente não aprova, você pode manter um controle de sua produtividade, analisando quantos commits foram feitos em quanto tempo, quantos tickets foram fechados, quantos ainda permanecem pendentes.

Desde que passei a utilizar SVN em alguns projetos, como no próprio Spaghetti, notei uma grande melhora no controle sobre o código. Nunca mais pensei duas vezes em apagar grandes blocos de código pensando que eles poderiam ser úteis outra vez (e geralmente nunca seriam realmente necessários). Uma excelente forma de analisar seu progresso, uma excelente forma de backup, uma excelente forma de manter seu código sincronizado. Esqueça aquele colega que tem uma versão ultrapassada de seu código e sobrescreve partes importantes. Quando passei a utilizar ferramentas de tracking, bugs não eram esquecidos, idéias estavam sempre à mão. Digo, como muitos por aí: isso realmente mudou a minha maneira de desenvolver.

MVC

O Model-View-Controller, ou MVC para os íntimos, nunca fez tanto sentido quanto na web. Depois do Ruby on Rails, virou quase um requisito básico para o desenvolvimento de bons projetos. E desde então, desenvolver não tem mais graça. Além disso, a separação de aplicações nessas 3 camadas torna o desenvolvimento e manutenção muito mais simples.

Se você não quer ficar para trás, adote seu framework. O pattern é usado na maioria deles, e de brinde você ganha muita produtividade. Frameworks tornam as linguagens menos ruins. Se você usa PHP, eu sugeriria o Spaghetti. Se você usa Ruby ou Python, e é seu primeiro contato com frameworks, siga a tendência e adote Rails ou Django. Se você é corajoso, faça como fizemos na minha agência: crie seu próprio framework. Usando algum framework ou não, o que importa é pegar o espírito da coisa.

SQL

Mesmo com toda a flexibilidade e abstração da camada de dados que os frameworks MVC nos oferecem, SQL ainda é necessário. Apesar de você não vê-lo, ele ainda está lá. Consultas complexas ou mais específicas nem sempre são disponibilizadas pelos frameworks, e sempre pode haver a necessidade de uma incursão via terminal, para tarefas de manutenção, por exemplo.

Talvez você não acredite no retorno que isso pode trazer. Até ter nas mãos uma aplicação gigante e extremamente dependente de banco de dados, onde as consultas devem ser otimizadas ao máximo para minimizar a carga do servidor. Você não quer sua aplicação baleiando por você não saber SQL, quer?

Desenvolvimento Guiado a Testes

Test Driven Development, ou simplesmente TDD, é, na minha opinião, a melhor maneira de manter seu código livre de bugs. Fazer o desenvolvimento guiado a testes significa desenvolver o teste antes da funcionalidade. A cada iteração, os testes são rodados novamente, de maneira automática, e você sempre saberá se alguma modificação quebrou o restante do código.

Sem testes automatizados, aplicações nunca são testadas como deveriam. São tarefas repetitivas e cansativas. Com o auxílio de ferramentas de testes, eles podem ser rodados várias vezes, certificando de que tudo está correndo bem. Se um novo bug é descoberto, um novo teste é criado, as modificações são feitas, e você terá a certeza de que o problema foi resolvido para todo o sempre, sem quebrar o restante da aplicação. E convenhamos, não há nada pior do que bugs…

Não é obrigatório que um desenvolvedor saiba tudo isso, embora eu considere extremamente importante, mesmo alguns não sendo necessários todos os dias, todos podem melhorar nossa maneira de trabalhar. Ainda não domino todos os itens citados, mas tenho um bom conhecimento em todos eles. O que importa mesmo é buscar isso, e sempre continuar aprendendo. Mexa-se! Você não quer ficar para trás, quer?

Posts Relacionados

• Qual curso devo fazer pra me tornar um desenvolvedor web?
• Comodismo vs. Inovação
• E a tal da Web 2.0?
• CodeCast #1 – Impressões sobre Início de Carreira
• ResponseXML

Desta vez falamos sobre os novos padrões, XHTML 2 e HTML 5. Coisas legais, mancadas, acessibilidade, semântica, enfim. Seguimos algumas dicas do pessoal, fizemos o podcast em apenas 30 minutos, tínhamos uma pauta (que não foi seguida muito à risca, mas ela existia) e também já temos o RSS funcionando.

Como disse o Rafael, escutem que está bem legal!

Posts Relacionados

• CodeCast #3 – Semântica e Microformatos
• CodeCast #1 – Impressões sobre Início de Carreira
• CodeCast #4 – Adobe Flash
• CodeCast #5 – Frameworks
• Semântica

O site é focado em “ler sobre código, ler código e colaborar”, segundo o próprio Élcio. Não há muitos posts até o momento, mas o que já foi postado, tanto pelo Élcio quanto por outros colaboradores, é um conteúdo selecionado, e de boa qualidade.

Gostei muito da política do site, bastante rígida quanto à seleção de conteúdo. Teremos uma boa referência se ela for cumprida. O cadastro e postagem são abertos a qualquer um, basta enviar bom conteúdo.

Já assinei o feed e me inscrevi. Falta acertar todos os dados do cadastro, e logo estarei postando algum conteúdo, talvez até exclusivo (se me vier alguma idéia). Se quiser, também sinta-se livre para cadastrar-se e começar a postar.

Posts Relacionados

• Cliente x Seu Ego
• O que você faz em 4Kb?
• Back Button Improved!
• Ajax vs. Acessibilidade
• Ativando o Botão Voltar

Justamente nesse pseudo-browser é o problema que vou expor. Não sei se ele foi resolvido por muita gente, mas eu dei um jeito e funcionou bem. Quem mais tiver feito algo parecido coloque o link nos comentários.

A função é a seguinte:

function innerOptions(oSelect,mOptions) {
	var ini = 0;
	if(mOptions.toLowerCase().indexOf("<option") < 0) {
		var oOption = document.createElement('option');
		oOption.innerHTML = mOptions;
		oOption.setAttribute("value", mOptions);
		oSelect.appendChild(oOption);
    }
	else {
	    var ini = 0;
	    while (ini != -1) {
        ini = mOptions.indexOf('<option', ini);
	        if (ini >= 0) {
				var valueIni = mOptions.indexOf('value="', ini);
        	    if(valueIni >= 0) {
					var valueFim = mOptions.indexOf('"', valueIni);
    	        	var value = mOptions.substring(valueIni,valueFim);
				}
            	ini = mOptions.indexOf('>', ini) + 1;
	            var fim = mOptions.indexOf('</option>', ini);
    	        text = mOptions.substring(ini,fim);
        	    elOption = document.createElement("option");
            	elOption.innerHTML = text;
				elOption.value = value;
    	        oSelect.appendChild(elOption);
	        }
    	}
	}
}

A idéia é a seguinte: caso não haja uma tag option em mOptions, ela é criada e tem value e texto como mOptions. Caso contrário, as tags são recriadas e adicionadas ao select através de appendChild. Simples, mas chatinho de fazer, pelos indexOf (odeio isso).

Essa função é bem útil tanto para Ajax quanto para só JavaScript.

Update: aproveitem e dêem uma olhada na função do Micox também. Utiliza uma idéia diferente, mas funciona legal.

Posts Relacionados

• Histórico para Navegação via JavaScript
• Ajax sem o X
• Cookies em JavaScript
• Funções em Diferentes Escopos
• Efeito Glide

A maioria das pessoas que passar por aqui vai responder essa pergunta sem nem pensar: “SIM”. Será mesmo?

Não duvido que muita gente saiba DE VERDADE Webstandards (falo aqui só de XHTML e CSS), mas muita gente se equivoca. Isso porque falta experiência. Antes de começar esse meu trabalho secreto (suspense…), pensava que sabia razoavelmente WebStandards. Me enganei. Eu já tinha certa experiência, mas ela foi bem mais elevada agora. Principalmente no que se diz respeito a posicionamento. Agora dá pra ver que não estou tão perto assim.

E você, ainda acha que sabe? Tem certeza? Experimente colocar uma coluna do lado da outra sem usar float… Ou resistir a colocar uma tabela em algum lugar (é, isso que eu nunca trabalhei com tabelas). Se você ainda se sente inseguro, treine bastante. Se você já é experiente, continue treinando, tenho certeza de que não sabe tudo, e experiência nunca é demais.

E isso serve para qualquer coisa, não só Webstandards. Usei esse tema para se relacionar com as dificuldades que passei (resolvi sozinho, mas levei uns dois dias quebrando a cabeça, na tentativa-e-erro). Treine, leia, estude, faça desafios a si mesmo, experimente converter um site (em caso de WS), colocar JavaScript em algum lugar, enfim…

Posts Relacionados

• Qual editor você usa?
• Pra quem você escreve?
• O que você faz em 4Kb?
• Cliente x Seu Ego
• Semântica

Continuo defendendo aquele meu velho ponto de vista, mas desta vez vou ampliar um pouco minha “visão da coisa”.

Impor o Firefox como browser a ser escolhido pelo seu cliente é suicídio. Nem tente. No máximo uma sugestão. Mas aí surge um problema: se 80% dos internautas usam Internet Explorer, vale a pena usar os padrões? Já voltamos aí.

Por mais que seu ego diga “Valida logo!”, seu cliente diz “Termina Logo!”. No caso, IE, gambiarra, hack, defeito, dor de cabeça… Se você desenvolve primeiro no Firefox, há uma grande possibilidade de tudo estar validadinho. Se você desenvolve primeiro no IE, nem vou falar.

E aí, já decidiu? Crie tudo primeiro para o Firefox. Quando tudo estiver direitinho, faça as alterações, gambiarras, hacks, comentários condicionais… Vai tudo estar pronto antes (por mais que não pareça), e você satisfez seu ego (isso é bom, né?) e seu cliente (que vai estar feliz por funcionar 100% no IE e por você ter entregue na hora). Além disso, sua impressora fica livre de ter que imprimir alguns currículos…

E a pergunta de sempre: Validar ou não? Sim, sempre que possível (nem sempre há tempo). Não perca seu emprego por um bug do seu código ou do W3C, siga feliz!

Posts Relacionados

• ClientSide: Mostre seu Código!
• Não validou. E agora?
• Vale a pena arriscar em novas tecnologias?
• DIVless
• Caindo na Real

Dentre esses gurus, temos: Inman, Hicks, Collison, Johansson, Molly além do próprio McLellan, criador do site.

Alguns dos temas abordados: CSS, DOM scripting, acessibilidade, microformats dentre outros. Ahh! Também estão disponíveis os artigos do ano passado: 24 Ways 2005.

Espalhe a notícia! Fonte: Revolução Etc

Posts Relacionados

• Primeiro Post
• Ficando Bem-Informado
• E a tal da Web 2.0?
• DIVless
• Yoomp – Primeiras Impressões

Quando os padrões “apareceram” aqui no Brasil, e ganharam uma certa forcinha, acredito que a maioria dos desenvolvedores conscientes correu para o validador da W3C, para ver os trabalhos validados e colocar aqueles selinhos de validação. Se não validasse, tudo de novo, até estar 100% validado. Isso leva, várias vezes, em um bom tempo ajustando em todos os navegadores, para que fique igualzinho ou pelo menos apresentável.

Creio que hoje essa “mania” passou. Claro que temos vários sites validados, mas é realmente necessário todo esse trabalho? Essa é mais uma questão filosófica, e discutiremos aqui.

Como todo mundo sabe, o validador do W3C (seja ele (X)HTML ou CSS) verifica apenas se o código está bem escrito, avisando sobre tags não fechadas, erros de código e etc. Ele não diz se o site está apresentável em todos os navegadores, não verifica semântica, não mede desempenho, nada. Então, “ser ou não ser” validado?

Analisemos a nossa situação. Temos um documento não validado, e pra ajudar um browser horrível (não quero citar o nome IE para não constranger), mas nosso documento funciona perfeitamente nele e em outros browsers decentes. Existe apenas um único erro de código, que serve exatamente para nosso querido amigo azul. Ahh! Temos um prazo também, e só existe uma solução para corrigir o tal bug, mas a solução é enorme, e demoraria séculos para terminar. Temos as seguintes opções:

• Suicidar-se
• Começar a chorar
• Apelar pra tudo quanto é santo
• Perder o emprego
• Entregar o trabalho não validado

Tempo… E aí, já decidiu? Considere que as três primeiras opções não são de grande ajuda. Sobram-nos duas. Perder o emprego também não é bom…

Os nossos browsers de hoje em dia não conferem nossa marcação. Se está errado, e funcionando, tudo certo. É lógico que um trabalho validado é uma conquista, mas quando se tem um prazo pequeno não vale a pena perder boa parte do tempo para consertar um bug.

Em um futuro muito distante, os browsers lerão tudo como XML. Aí sim precisaremos de marcações impecáveis. Mas se você serve seus documentos como “text/html”, não há problema (muito).

Cortando toda minha enrolação, resuminho pra vocês: não perca tempo para consertar um bug, se está tudo certo deixe assim. Mas é lógico que se você tiver um tempinho de sobra, faça o possível para validar tudinho. Tempo = dinheiro. Validação = menos tempo. Validação + tempo extra = tudo validado. Captou? Até!

Posts Relacionados

• PC formatado, e agora?
• Desenvolver com Rails não tem graça…
• Diz que até não é … um mau blog
• Semântica
• Cliente x Seu Ego

O que é?

Basicamente (e literalmente), DIVless é a ausência de DIVs. Todas as DIVs são trocadas por listas não ordenadas e listas de definição.

Por quê?

Segundo o autor do DIVless, as listas tem um sentido inerente mais hierárquico e sintático. Em outras palavras, a hierarquia do site se apresentaria melhor, com ou sem o uso de CSS ou no código.

O autor também afirma, com ajuda do W3Schools, que as listas como elementos de layout seguem os padrões semânticos.

Também é apontada a falta de significado da tag DIV em browsers antigos, e ela também não apresenta estrutura hierárquica e visual em browsers que não usam CSS. Isso realmente é verdade. E tudo testado em IE 6 e 5.5, Firefox e Safari.

E a Semântica?

Em minha humilde opinião, a semântica vai por água abaixo. O que vale é a palavra do W3C, e não qualquer outra. Layouts são controlados por DIVs, e não listas.

Lembra-se quando ainda usávamos tabelas para posicionar elementos? DIVless é tão semântico quanto isso. Realmente a tag DIV não tem nenhum valor semântico, mas podemos adiciona-lo através dos atributos class e id.

A técnica do DIVless realmente foi bem bolada, todos os argumentos do autor são verdadeiros (exceto a questão semântica). Visitei a página sem suporte a CSS e apareceu bem melhor do que com DIVs. Isso é indiscutível. Mas e a semântica? Realmente é uma questão delicada.

Em minha opinião, DIVless não terá muito futuro, pelo menos até que o futuro chegue.

Posts Relacionados

• Tableless
• Semântica
• CodeCast #3 – Semântica e Microformatos
• Não validou. E agora?
• CodeCast #2 – XHTML 2 e HTML 5

Nas recomendações do W3C, cada elemento (tag) tem sua função própria no (X)HTML. Cada tag tem seu papel a cumprir, foi criada com um propósito. Criar documentos semanticamente corretos significa utilizar a tag certa no lugar certo. Por exemplo: <h1> para título superior, <p> para parágrafos… Não pretendo explicar aqui a função de todas as tags. Se estiver interessado, visite o W3Schools.

É completamente possível fazer um site inteiro usando apenas parágrafos. Talvez listas. É possível fazer um layout completo e apresentável usando qualquer tag. Isso é possível graças ao CSS, que permite modificar propriedades das tags. Mas essas propriedades são apenas visuais. Não é possível modificar a função semântica de algum elemento por CSS. Isso é impossível. E um site feito assim passaria na validação? Lógico! Se ele for bem formado, usar tags de acordo com o DTD, ele será validado. Não existe e nunca existirá um validador de semântica. Você mesmo terá que avaliar se seu documento é semanticamente correto. E se passa na validação, por que semântica?

A resposta é simples. Pense em um usuário que não enxerga, não ouve e ainda por cima não “raciocina”. Um exemplo desse usuário é o famoso Google. Ele não se importa com seu CSS. Então, quando ele for indexar sua página, ele procurará significado em suas tags, de acordo com as recomendações do W3C. Como ele entende apenas o significado das tags, como ele entenderá suas classes? Classes não tem valor semântico (ainda). Se seu código é bem tratado e tem significado, ele é Semântico. Aplicações como o Google, quando encontram uma certa tag, elas dão uma importância X para aquele elemento, dependendo do valor semântico que ele possui.

Analise: criando documentos semanticamente corretos, além de contriuir para uma web melhor, você estará beneficiando a si próprio. Seu site poderá aparecer primeiro no Google e outros motores de busca, será bastante amigável aos leitores de tela, será compatível com aplicações futuras, enfim, muitos outros benefícios que você descobrirá quando for desenvolver. Senti diferença ao ver que minhas folhas de estilo referenciavam mais tags do que classes. Você terá uma maior variedade de tags.

Bem, espero que tenha sido útil. Pretendo colocar mais alguns exemplos de semântica e seus benefícios a medida que meus estudos avançarem. Até a próxima!

Posts Relacionados

• DIVless
• CodeCast #3 – Semântica e Microformatos
• Tableless
• innerOptions
• Não validou. E agora?