Se você trabalha com interfaces web, pode não ter ouvido falar (ainda) desses dois conceitos, mas certamente muito já discutiu sobre eles. Semana passada comecei a ler mais profundamente a respeito; ainda não tenho uma opinião formada sobre ambos, nem se uma é melhor do que a outra ou, ainda, se alguma delas pode ser levada ao pé da letra no ciclo de vida de um projeto web.
Resumidamente, Graceful Degradation é sobre ter sua interface web funcionando em todos os dispositivos que o acessem, mesmo que aqueles com menos recursos tenham uma perda de qualidade e usabilidade (ou seja, a interface vai se degradando; você foca no melhor dispositivo). Já o Progressive Enhancement foca em definir um dispositivo com o mínimo de recursos (no caso, um browser mais antigo) no qual a sua aplicação seja funcional e usável, e para cada dispositivo melhor você terá funcionalidades extras, que usarão recursos do dispositivo que versões mais antigas não possuem (ou seja, sua interface vai melhorando/progredindo).
Seguem abaixo alguns links bem interessantes sobre o assunto:

• Progressive Enhancement and Graceful Degradation: Making a Choice
• Gracefull Degradation, Progressive Enhancement e Fluid Layout
• Progressive Enhancement with CSS 3: A better experience for modern browsers
• Graceful degradation é tudo sobre Acessibilidade
• Progressive Enhancement, melhoria necessária na web

Felizmente há tempos eu tenho mandado bem (uia!) ao contratar profissionais para a equipe de interface (@tivasconcelos, @renanrobe, @gserrano e outros sem @’s). Fazer isso é um processo que envolve muitos fatores – e a indicação ainda é a melhor forma. Mas, tem um texto divertido que mostra alguns pontos a serem levados em conta quando você for contratar um profissional web:

Ele se auto-intitula “webmaster”

E web precisa de especialistas em áreas específicas que conheçam o básico do “todo”, mas ninguém consegue dominar tudo. Se ele se chama assim, ele na verdade não sabe nada.

Ele é um expert em Frontpage

Primeiro que a ferramenta é ruim. Segundo que quem coloca a ferramenta à frente da tecnologia não merece crédito

Ele vai submeter seu site para diversos mecanismos de buscas

Desnecessário comentar a inutilidade disso, né?

Ele quer um “Designed by…” no rodapé

O site é para você, pro seu cliente, ou é simples parte do portfólio dele?

Ele criou um site para alguém da família

A chamada sobrinhagem: a única referência que tem são os sites feitos pro tio, pro pai, etc…

Ele vai inserir um contador de visitas no seu site

Isso era bacana na época da Geocities… e morreu lá, ok?!?!

Ele vai colocar um “melhor visualizado em…” no seu site

Ok, há toda essa celeuma do IE6 atualmente, mas ninguém pode partir do pressuposto em todos os projetos de que isso é viável

Fonte: http://davidwalsh.name/9-signs-not-to-hire-that-web-guy

Consegui ir hoje de manhã na 1. Conferência da W3C Brasil (que começou ontem e ainda está rolando nesse exato momento). Achei a estrutura bem bacana – palmas pros organizadores, inclusive por terem escolhido o Blue Tree Towers, wi-fi funcionando belezinha, bom áudio nas salas, ar condicionado ok! para o clima de verão já de São Paulo.
Algumas caras conhecidas, outras que se tornaram depois das discussões pegando fogo no debate sobre ensino de padrões web, certificação e formação profissional na área de front-end. Estava presentes o (já famoso) Diego Eis da Visie, Evaldo Bechara (da iLearn, escola carioca), Fábio Flatschart do Senac e Marcelo Moura do Grupo Impacta.

O debate durou uma hora e meia, e durante ele muito se falou sobre o benefício – ou não – de se ter certificação para o profissional front-end (aquele que escreve html/CSS, programa em javascript) e quem poderia certificar profissionais. Muitos pontos de vistas foram levantados, e ficou claro que ainda dá para separar o joio do trigo; mesmo tendo 4 representantes de instituições de ensino, nota-se que existem aquelas que estão interessadas em realmente educar e ensinar (no caso a Visie, iLearn e Senac) e outras que só querem vender um papel (não sei se essa é a real posição da Impacta, mas foi o que seu representante deixou transparecer). A própria W3C através de um representante (que esqueci o nome) deixou claro que nem ela está certa do que fazer e se seria interessante – apesar de saber que economicamente seria uma ótima forma de conseguir mais recursos, a organização tem dúvidas quanto a necessidade de certificar profissionais e que o próprio Tim Berners não é favorável a isso nesse exato momento.

Foi visto que existem diferentes enfoques e utilidades – ou não – para certificações. Profissionais podem ser estimulados a estudar mais e de uma forma melhor, com conteúdo oficial de uma organização mundial que define padrões levando em conta o lado técnico do mercado e não o econômico, empresas podem se valer disso na hora do seu processo seletivo e na garantia de ter um profissional que, ao menos, comprovou uma dedicação ao estudo. E é claro que para as instituições de ensino isso pode vir a ser uma mina de ouro!
De um lado negativo, foi levantado que o profissional pode focar mais na certificação do que no conhecimento – o que ocorre em diversas certificações de outras tecnologias – e que as empresas podem acabar deixando pra trás profissionais não-certificados nas suas seleções, e que, ainda, instituições de ensino podem começar a vender “como passar na prova” do que disseminar conteúdo.

Minha opinião? É que tudo isso, àcima, aconteceria. Não há como garantir um mercado uniforme; existem empresas que adotariam a certificação como mais um filtro (especificamente as que têm processos seletivos de grande porte, ou ainda o governo), outras que continuariam com o processo seletivo da forma que fazem hoje (provas, indicações, site pessoal com portfólio, etc…); profissionais bons usariam o cerificado como um a mais, enquanto que os medíocres o usariam apenas para falar que são certificados.
E as escolas de qualidade conseguiriam mesclar ambos, conseguindo formar profissionais mais completos e com um atestado de uma organização maior.

Para aqueles que como eu se interessam pelo mundo dos CMS… tem muita coisa por aí!

Fonte: http://www.cmswatch.com

Atenção: esse post só faz sentido para quem pegou a fase do DOS, ou seja, os velhos

Praticamente todo mundo que começou a usar computador antes do ano 2000 de uma forma mais hard teve muito contato com o DOS, que era a base dos sistemas do Windows (3.x, 95, 98…). No fundo, o Windows era um gerenciador de janelas que rodava em cima do DOS, então qualquer coisa mais complexa de se fazer precisava ser feito na linha de comando (do famoso) prompt do DOS. Outras pessoas, mais raras de se encontrar, usaram DOS no começo, nos primórdios, crú.

Se tem alguém dessa época que ainda quer migrar para sistemas Unix, fica a dica desse cheat sheet com uma equivalência dos comandos.

Fonte: http://www.junauza.com/2009/11/dos-to-unixlinux-translation-dos-to.html

Existem muitos posts em diversos blogs falando de como melhorar a performance do seu site diminuindo o tráfego de dados do tipo texto (html, css e javascript, na grande maioria). Já discuti – no bm sentido – algumas vezes sobre o fato de achar desnecessário fazer aqueles minify de javascript, fazer CSS em uma linha e tirar os espaços em branco no html, se você estiver usando compressão pelo webserver.

Não vou entrar em detalhes – o Google está aí pra isso – mas você pode consigurar o Apache (imagino que outros webservers tenham algo parecido) para que ele faça compressão de arquivos (como se fosse um zip) a serem enviados. O (protocolo) http se encarrega de verificar se o browser possui a capacidade de descompactar (e acredite, qualquer browser mais ou menos atual possui) arquivos nesse formato.

Como habilitar? Habilite o módulo deflate do Apache (como fazer isso, varia de versão para versão; cheque a documentação da sua instalação do Apache) e dentro do Virtualhost do seu site, insira:

<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|rar|zip|pdf)$ no-gzip dont-vary
<IfModule mod_headers.c>
Header append Vary User-Agent
</IfModule>
</IfModule>

Isso vai fazer com que qualquer arquivo que não seja de uma das extensões listadas na terceira linha seja comprimido com gzip. Ah, porque não comprimir esses? Comprimir com gzip qualquer tipo de um desses formatos é desnecessário, pois eles já possuem compressão.

Reinicie o Apache e de um refresh na sua página, com o Firebug aberto, e veja a diferença.

Para melhorar, se você quiser fazer um log para acompanhar se está mesmo fazendo a compressão, e o quanto está comprimindo cada arquivo. Para isso, dentro do seu Virtualhost também:

<IfModule mod_log_config.c>
<IfModule mod_deflate.c>
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
SetEnvIf Request_URI \.gif image-request
SetEnvIf Request_URI \.js image-request
SetEnvIf Request_URI \.css image-request
LogFormat ‘”%r” %{outstream}n/%{instream}n (%{ratio}n%%)’ deflate
CustomLog /var/log/apache2/deflate.log deflate env=!image-request
</IfModule>
</IfModule>

Vale lembrar que esses são apenas exemplos, e você pode customizar tanto a compressão quanto o formato do log e afins ao seu prazer