Chris B. - idéias e pensamentos » Tecnologia

Links bacanas sobre Progressive Enhancement e Graceful Degradation

Chris — Mon, 22 Mar 2010 12:03:59 +0000

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:

Posts relacionados

Sinais que indicam que você não deve contratar aquele profissional de web

Chris — Tue, 01 Dec 2009 13:32:34 +0000

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

Posts relacionados

Conferência Web W3C – debate sobre certificações

Chris — Tue, 24 Nov 2009 17:27:14 +0000

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.

Posts relacionados

2009 CMS Vendor Map

Chris — Mon, 16 Nov 2009 20:51:46 +0000

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

Fonte: http://www.cmswatch.com

Veja também

Do DOS para Unix: tradução dos comandos

Chris — Fri, 06 Nov 2009 00:31:11 +0000

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.

	Purpose	DOS	UNIX/Linux
.	display list of files	dir/w dir	ls
.	display contents of file	type	cat
.	display file with pauses	type filename \| more	more
.	copy file	copy	cp
.	find string in file	find	grep
.	compare files	comp	diff
.	rename file	rename OR ren	mv
.	delete file	erase OR del	rm
.	delete directory	rmdir OR rd	rmdir
.	change file protection	attrib	chmod
.	create directory	mkdir OR md	mkdir
.	change working directory	chdir OR cd	cd
.	get help	help	man
.	display date and time	date, time	date
.	display free disk space	chkdsk	df
.	print file	print	lpr
.	display print queue	print	lpq
.	clears screen	cls	clear
.	closes prompt window	exit	exit

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

Posts relacionados

Usando compressão gzip no Apache e vendo os resultados num log

Chris — Fri, 30 Oct 2009 00:44:54 +0000

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:

SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|rar|zip|pdf)$ no-gzip dont-vary

Header append Vary User-Agent

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:

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

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

Posts relacionados

iui – framework para desenvolvimento de interfaces para iPhone

Chris — Wed, 28 Oct 2009 16:38:15 +0000

Nunca me preocupei – nem tive a necessidade – de fazer uma versão de um site para o Iphone (ou qualquer outro dispositivo móvel). O máximo que fiz foi instalar um plugins em alguns dos meus blogs que, dependendo do dispotivo móvel, utiliza um jogo de templates diferenciado.

Aproveitei um tempinho livre – não que esse existe em quantidade – aqui na MMCafé para procurar como escrever interfaces (html/CSS e javascript) voltado ao Iphone. Depois de alguns bons posts, me deparei com uam espécie de framework, o iui: ele fornece a estrutura de html/CSS e implementações javascript para se criar aplicações pro Iphone. Tem muita coisa bacana, como aquela estrutura já famosa de webapps do Iphone, com menu em forma de lista com navegação por elas, bem como o CSS que já deixa com aquela carinha meio “azulada“, assim como outros temas.

Fuçando um pouco mais, encontrei esse post que explica como trabalhar com o framework: http://www.k10design.net/articles/iui/

Pelo que pude ver, ele não é o framework definitivo (falta coisa, inclusive na documentação, existem muitos reports de erros principalmente relativos ao javascript), mas para quem – como eu – está começando nessa história de interfaces para dispositivos móveis, ele ajuda a ser produtivo no início e entender como algumas coisas podem funcionar!

UPDATE: a @caracolis me mandou um link bem bacana da Smashing sobre tendências em design para aplicações para o Iphone, vale a pena olhar!

Posts relacionados

Criar um arquivo de log por dia no Apache com o rotatelogs

Chris — Wed, 14 Oct 2009 18:44:12 +0000

Vi ontem no blog do Danilo um post sobre como criar Virtualhosts no Apache, para servir diversos sites, e aproveitando a idéia, vale a pena falar como criar logs para cada Virtualhost.

O mais básico é dentro da diretiva do Virtualhost dizer que vai haver um CustomLog (log customizado) em uma determinada pasta, com um certo formato. O que eu sempre uso é algo assim (aproveitando o exemplo do Danilo):


    ServerName meusite.dev
    DocumentRoot /var/www/meusite.dev
    CustomLog "/var/www/meusite/log/access.log"  combined

No caso, a pasta /var/www/meusite/log deve ser criada e o Apache deve ter permissão de escrita, e combined é o formato do log que o Apache vai criar (existem diversos, que podem ser encontrados na documentação oficial).

Agora, algo mais bacana é criar um arquivo de log por dia. Porque? Simples: um arquivo de log de um site mesmo de pequeno porte pode chegar facilmente a gigas de tamanho em pouco tempo – pouco tempo = poucos meses.
Criando um arquivo por dia, é mais fácil de se fazer backup, ter controle do que está sendo logado e mesmo para usar os logs – como com um log analyzer. Para isso, é possível usar no linux o rotatelogs. Sei que no Windows é possível fazer isso também, mas não lembro de cabeça qual é o aplicativo que o faz.


    ServerName meusite.dev
    DocumentRoot /var/www/meusite.dev
    CustomLog "|/usr/sbin/rotatelogs /var/www/meusite/log/access_%Y%m%d.log 86400 -180"  combined

Nesse caso, para cada dia (86400 segundos) é criado um arquivo diferente, com o nome no formato desejado (underline, ano, mês e dia no final). Voi-lá, tudo funcionando!

Posts relacionados

vnStat PHP Frontend

Chris — Sat, 10 Oct 2009 18:09:58 +0000

Em breve creio que vou escrever um manual sobre como configurar um servidor completo Linux com a quantidade de posts que tenho feito com as (novas) tarefas que tenho feito – e isso é bom, pois serve no mínimo como aprendizado. Bem, vamos lá: estava precisando de um analisador de tráfego pro servidor, uma vez que o da Locaweb ou não existe ou não consegui achar como acessar.

Bem, o primeiro passo foi instalar o vnStat:

apt-get install vnstat

E configurá-lo

vnstat -u -i eth0

Com isso, foi criado o que o database para o vnStat na saída eth0

Próximo passo foi baixar o vnStat PHP Frontend, que nada mais é do que um frontend para o vnStat para ser acessado pelo browser. Depois, só precisei alterar o config.php dizendo o caminho do bináio do vnStat

$vnstat_bin = ‘/usr/bin/vnstat’;

E tudo funcionando! Pelo browser, agora tenho estatísticas com essa carinha, bem agradável

Posts relacionados

Sendmail no servidor linux muito lento?

Chris — Fri, 09 Oct 2009 12:08:15 +0000

Continuando a saga da configuração do servidor cloud da Locaweb que comecei a usar, o que mais me deu dor de cabeça foi o envio de e-mails usando o sendmail do linux. Eu até ia instalar o Postfix, mas estava faltando tempo, então fiz o basico e instalei o sendmail e configurei no php.ini para que ele fosse usado, normalmente, com o

sendmail -t

Primeiro teste, e muito lento o envio. Testei denovo, lento denovo… comecei a ficar preocupado.
Depois de muito vasculhar, cai no forum do própria Locaweb no qual um usuário falava que teve o mesmo problema e que isso tem a ver com os DNS configurados no hosts da instalação padrão do servidor.
Por padrão, ele vem assim:

127.0.0.1 localhost
187.45.206.79 XXXCNN[xxxx]

*o [xxxx] é o número da máquina que a Locaweb me forneceu.

O problema é que o sendmail se perde para achar o host, pois não há um domínio completo, e ele fica procurando em diversos locais, por isso a demora.

A solução é simples: só configurar os domínios completos

127.0.0.1 localhost.localdomain localhost
187.45.206.79 XXXCNN[xxxx].hospedagemdesites.ws XXXCNN[xxxx]

Não sei se a minha explicação dos motivos está totalmente correta – existem muitas páginas no Google falando a respeito, é só procurar por “sendmail + dns lookup“, mas aparentemente a solução funciona