A visualizar apenas posts da categoria Programação Web

Nem todos os programadores de PHP desenvolvem a pensar no futuro. Quer estejam a desenvolver sozinhos ou em equipa é sempre bom obedecer a algumas regras que se devem manter em todo o projecto, assim como documentar o nosso código.

Aqui ficam algumas dicas que actualmente aplico em todos os meus projectos.

Portátil na relva

Indentação do código
Se não temos código legível como o vamos alterar no futuro? É por isso que a indentação é muito importante.

1
<?php if (empty($var)) {echo 'Está vazio';} ?>

No exemplo acima temos tudo numa linha de código apenas. Com pouco texto é perceptível, mas com uma função mais complexa seria o caos. Se utilizarmos indentação o código fica perceptível quer por nós quer por quem visualize o código posteriormente.

1
2
3
4
5
<?php
  if (empty($var)) {
    echo 'Está vazio';
  }
?>

Pessoalmente não aconselho a efectuar a indentação com espaços, é preferível usar tabulações pois o seu tamanho pode ser definido directamente na aplicação que estamos a usar para editar o código. O número de tabulações entre linhas de código fica ao vosso critério, mas seja qual for lembrem-se de o utilizarem sempre para que o código fique igual em todo o projecto.

Nomes de funções e variáveis
O PHP é uma óptima linguagem pois deixa-nos programar da forma a que mais nos adaptamos. Isto tem um custo associado, e por vezes as nossas escolhas nos nomes de funções e variáveis podem não ser as mais correctas.

1
2
3
4
$variable_name
$VariableName
$variableName
$variablename

As primeiras três linhas são bons exemplos de como dar um nome a uma variável ou função. A primeira é normalmente a mais utilizada, usando um underscore (_) em substituição de um espaço.

A quarta linha é um mau exemplo porque o nome da variável fica mais confuso e torna-se mais difícil ler o seu nome.

Eu opto sempre por colocar o nome de variáveis e funções na forma CamelCase com a primeira letra minúscula (mixedCase) tal como na terceira linha do exemplo acima.

Números mágicos
Guardar um número como ID em vez de uma palavra numa base de dados torna a indexação mais rápida e ocupa menos espaço em disco, tornando a base de dados mais eficiente. Fazer o mesmo em programação é o oposto.

1
2
3
4
5
<?php
  if ($var == 3) {
    // Corre função
  }
?>

Visualizando o código ficamos sem saber a que corresponde o algarismo 3, um número mágico. Se definirmos uma palavra ao nosso algarismo tornamos o código mais perceptível e fácil de manter caso o valor deste algarismo altere.

1
2
3
4
5
6
<?php
  define('ACTIVO', '3');
  if ($var == ACTIVO) {
    // Corre função
  }
?>

Podemos assim definir uma palavra que corresponde ao algarismo, e se desejarmos basta alterar num local o algarismo correspondente e todo o nosso código vai saber que ACTIVO para a corresponder a um novo número.

Comentários
Colocar comentários no código a documentar o que cada função faz é crucial. Não apenas para quando trabalhamos em grupo mas também quando são projectos individuais. Certamente com o código fresco na cabeça se lembram do que cada pedaço de código faz, mas se necessitarem de alterar algo após 6 meses ou 1 ano certamente vão agradecer que o código esteja devidamente documentado.

Sempre que declararem uma função é bom explicar o que ela faz e explicar o que cada argumento recebe.

Anda por aí um hype desgraçado com o HTML5, principalmente com as guerras do uso do vídeo. O HTML5 é sinónimo de web semântica, não de vídeo online.

E se alguns fanáticos já andam a ditar a morte do Flash, a verdade é que isso não vai acontecer tão cedo, e não sou eu que o digo, é mesmo a equipa de developers do Youtube.

Youtube a usar HTML5

Para quem lê o blog e não percebe muito disto (aqueles que pensam que Web 2.0 é uma nova versão da Internet :lol: ), o HTML5 não é nada que se instale, é apenas uma especificação. Por exemplo, este blog está em XHTML 1.0, existem sites em HTML4 e todos eles funcionam correctamente, apenas mudam as tags que podem ser usadas e os atributos associados.

Um site em XHTML ou HTML5 não vai ter diferenças de performance ou funcionalidade. Temos também que ter em conta que o HTML5 é, de acordo com a W3C, um working draft e não a versão final.

Sem mais demoras, passo a explicar porque desisti da versão HTML5 do Youtube. Certo que a página carrega de forma mais rápida por não ter que carregar um plug-in, mas todas as restantes desvantagens tornam a tag vídeo em algo totalmente obsoleto para um site como o Youtube.

Vídeos em ecrã completo apenas são suportados por alguns browsers e com aceleração por software. Tentar ver um vídeo em 1080p com WebM do HTML5 em fullscreen não é muito interessante, já o mesmo com Flash e suporte a aceleração por hardware corre bem até em computadores mais fracos como o meu netbook.

Depois temos a questão do streaming, que simplesmente não existe, para isso necessitamos do Flash. Outras funcionalidades como as legendas apenas estão disponíveis com Flash.

Não é o HTML5 que vai trazer o vídeo para a web, quem fez isso foi o Flash numa altura em que se fazia embed de vídeos em WMV, Real Player ou Quicktime. O Flash definiu um standard de vídeo para a web poderoso, e embora tenha problemas de performance em computadores mais lentos, continua a ser a escolha acertada em relação à tag <video>. Se não fosse o Flash hoje sites como o Youtube, Vimeo ou Hulu seriam miragens.

O HTML5 vai ser óptimo para uma internet semântica, tags como o <header> e <footer> fazem mais sentido que um <div id="header">, mas para isso necessitamos que o HTML5 chegue à sua especificação final e de um Internet Explorer 9 com updates frequentes, assim como o suporte retroactivo a HTML5 para o IE8.

HTML5 para vídeo aplica-se a sites com clips vídeo mais pequenos e dimensões reduzidas, sites com conteúdos de alta definição e streaming vão ter que continuar a usar o Flash.

Tenho partilhado várias dicas aqui no blog sobre como tornar um site mais rápido. Algumas incluem a compressão de ficheiros quer através de redução como de compressão gzip.

Mas nem todos os compressores fazem um bom trabalho, e o conhecido /packer/ é um deles.

Carruagem de metro cheia

O /packer/ anuncia maravilhas, afinal de contas com um algoritmo complexo que consegue codificar o código JavaScript com Base62, reduzir o nome das variáveis e consegue resultados em tamanho de ficheiro muito parecidos ao de um ficheiro Gzip.

O problema é que um ficheiro Gzip é descarregado uma vez, descomprimido uma vez e fica em cache no browser. O utilizador poupa largura de banda e deixa de fazer pedidos ao servidor.

“Mas Eduardo, com um ficheiro .js do /packer/ acontece o mesmo”, devem pensar vocês. Certo, o ficheiro fica em cache mas comprimido com o algoritmo usado, e cada vez que se acede a uma página com este JavaScript existe um trabalho desnecessário de descodificação do ficheiro e posterior colocação dos dados em memória no browser.

Se em computadores com boa capacidade de processamento isto equivale a alguns milissegundos, num computador mais fraco como um Netbook ou num telemóvel estamos a falar de o uso de recursos para processamento e memória que se poderiam evitar.

Para mim o /packer/ é uma alternativa para os preguiçosos. O meu conselho é não usar o seu Base62 encode e optar antes pela compressão dos ficheiros no servidor.

O PHP teve durante alguns tempos a fama de ser inseguro, mas os problemas nunca foram do PHP mas sim dos programadores amadores.

Felizmente com a versão 5.3 algumas das atrocidades anteriores passaram ao estado deprecated e vão ser removidas na versão 6 do PHP.

ElePHPant na praia

Alguns programadores vivem para funções e métodos perigosos como o register_globals. Se tu programas a pensar no register_globals e usas esta função então já sabes porque é que o teu site foi alvo de ataques.

Para resolver os problemas dos programadores preguiçosos foram lançadas algumas soluções de recurso, algumas feitas a pensar nos Hosting Providers como o safe_mode, outras a pensar nos programadores que confiam em tudo o que o mundo lhes diz, como o magic_quotes.

Eu adoptei a filosofia do Chris Shiflett, todas as informações introduzidas pelo utilizador (ou por sistemas de terceiros) são perigosas, e devemos tratá-las como tal. Devemos analisar todo o conteúdo introduzido por um utilizador ou fornecido por um serviço web antes de correr uma query de MySQL ou executar uma qualquer função de PHP.

Podemos usar um preg_replace para limitar informação apenas ao caracteres por nós permitidos, usar o real_escape_string em todas as querys MySQL, definir o conteúdo de uma variável como vazia antes de a utilizarmos no script. Tudo isto são pequenos gestos que tu e qualquer programador devem adoptar para melhorar o estilo de programação.

Infelizmente tenho visto muitos erros destes em vários scripts que me passam pela mão, mas o pior de tudo é ver aplicações estabelecidas no comércio online a necessitarem de funcionalidades perigosas como o register_globals. Depois existem os programadores que continuam a enveredar por um caminho desactualizado e que irá ser removido brevemente, fazendo com que os seus scripts deixem de funcionar.

Ao menos a web vai ser mais segura, não porque o PHP mudou, mas porque os programadores vão ser obrigados a mudar.

Existe uma boa razão pela qual algumas aplicações ou linguagens de programação são tão usadas, e é algo que existe em comum entre o PHP, o WordPress e o jQuery. Todos eles possuem boa documentação que torna a curva de aprendizagem mais curta.

Documentação do PHP

É certo que não basta boa documentação para garantir o sucesso de uma aplicação, mas vejam quantas pessoas trabalham com o PHP, o WordPress e o jQuery em detrimento dos seus concorrentes quando fazem todos a mesma coisa.

A diferença é que com uma simples pesquisa no site do PHP, WordPress ou jQuery obtemos uma lista de funções ou métodos com uma explicação sobre o que cada função faz e um ou mais exemplos. Se tenho um exemplo posso começar a partir daí, efectuar alguns testes e chegar rapidamente ao resultado que pretendo. Com outras aplicações é virtualmente impossível.

Isto faz com que a curva de aprendizagem seja curta e que com o site da aplicação aberto e uma página de código se obtenham bons resultados que rapidamente podem ser aplicados num ambiente de produção com segurança.

Vejam o exemplo do Bing (antes Live) que alterou o SDK do serviço de mapas e está agora finalmente a retirar algum mercado os utilizadores do Google Maps API, como uso no Mais Gasolina.

Esta é também a razão pela qual muitos webmasters iniciados no HTML procuram tags e o que faz cada uma delas no site W3Schools e não no site do consórcio W3C.

Tornar um site rápido e leve é simples, e deve ser sempre feito e todos os sites. Já aqui partilhei várias dicas sobre como o fazer, algumas são tão simples como adicionar meia dúzia de linhas ao ficheiro .htaccess usando alguns módulos do Apache.

Usar o mod_expires do Apache é mais uma dessas dicas.

Cache HTTP

O mod_expires indica ao browser do cliente qual a validade de determinado ficheiro, permitindo mantê-lo em cache sem fazer um novo pedido ao nosso servidor. Se pensarmos que uma imagem nunca muda, e que um ícone (favicon) ou um ficheiro css e js raramente são alterados podemos reduzir vários pedidos do browser ao servidor tornando o acesso mais rápido e reduzindo o tráfego no servidor e na ligação do cliente.

O mod_expires permite indicar um tempo de cache igual para todos os documentos usando o ExpiresDefault, o que não recomendo. O ideal é usar o ExpiresByType que permite definir uma data de expiração consoante o tipo de ficheiro.

É ainda possível definir se queremos que a validade (em segundos) do ficheiro seja a contar a partir da data de acesso com o operador A ou se a validade é após a última data de modificação com o operador M.

A diferença é que com o primeiro operador, a cache de um utilizador que acedeu ao site na semana passada irá expirar primeiro que a cache de um utilizador de acabou de aceder ao site. Com o segundo operador todos os caches irão expirar ao mesmo tempo, pois será a data de criação do ficheiro que irá contar. Este operador poderá ser útil para colocar em cache imagens que mudam semanalmente mas não mudam de nome ou páginas HTML que são alteradas diariamente.

1
2
3
4
5
6
7
ExpiresActive On
ExpiresByType text/html M86400
ExpiresByType text/css A2592000
ExpiresByType text/javascript A2592000
ExpiresByType image/png A31104000
ExpiresByType image/jpeg A31104000
ExpiresByType image/x-icon A31104000

No exemplo em cima activamos o mod_expires na primeira linha e indicamos que os ficheiros html devem manter a sua validade até 24 horas depois de serem criados com o operador M. Isso quer dizer que um ficheiro criado a 1 de Dezembro às 14:00 se for acedido a 2 de Dezembro às 13:00 apenas ficará guardado durante 1 hora na cache do cliente.

No entanto o mesmo acesso irá manter os ficheiros css e js em cache até dia 1 de Janeiro às 14:00, independentemente da data de última modificação graças ao operador A.

Os ficheiros png, jpg e ico irão expirar um ano após o acesso pelo cliente, como indica o tempo em segundos. Para referência, 3600 segundos equivalem a 1 hora.

Existem várias possibilidades que podem ser adaptadas ao site em questão e melhorar o seu desempenho. Podem confirmar se o mod_expires está a funcionar correctamente com a ferramenta HTTP Headers.

Ontem escrevi sobre reduzir o tamanho dos ficheiros CSS, Javascript e HTML, mas ainda existem mais dicas que vou partilhar convosco para reduzir ainda mais o tamanho dos ficheiros CSS.

E é algo tão simples como combinar vários atributos num só utilizando os shorthands.

Código CSS

No post anterior já expliquei os benefícios de reduzir o tamanho de um ficheiro CSS, portanto vou directo ao assunto.

Margin e Padding
Porquê indicar o atributo margin e padding para cada um dos lados se podemos usar apenas um atributo para tudo? Fica aqui um exemplo para verificarem qual acham que é mais eficaz.

1
.class {margin-top:1px; margin-right:1px; margin-bottom:1px; margin-left:1px}

O exemplo em cima é comum em muitos sites e temas para gestores de conteúdos. Aquela linha de código ocupa 77 bytes. No seguinte exemplo usamos o shorthand, temos o mesmo efeito visual e usamos apenas 19 bytes. Aliás, bastam dois atributos de margin ou padding para compensar usar o shorthand, se for apenas um atributo não vale a pena usar o shorthand.

1
.class {margin:1px}

Parece que já vos estou a ouvir perguntar “Então e se quiser um valor diferente para cada lado?”. Vamos supor que queremos dar um padding de 10px no topo, 20px no fundo e 5px para cada lado.

1
.class {padding:10px 5px 20px 5px}

Simples, não? Os valores são indicados seguindo o movimento dos ponteiros do relógio, cima, direita, baixo, esquerda. Para aqueles que não se dão bem com ponteiros podem pensar na palavra TRouBLe e associar as consoantes aos respectivos valores. Top, Right, Bottom e Left.

Outra dica, se quisermos indicar um valor nulo não é necessário escrever 0px. Certo que em CSS temos sempre que indicar as unidades, mas 0 é 0, seja px, pt, em ou percentagem.

 

Border
O border também funciona tal como o margin e o padding se todos os lados tiverem a mesma dimensão. O shorthand indica primeiro as dimensões, o estilo e a cor.

1
.class {border:1px solid #000}

A diferença para o margin e o padding é que se quisermos por exemplo o border apenas no topo e no fundo temos que indicar explicitamente esses lados, como no exemplo que se segue.

1
.class {border:1px solid #000; border-left:0; border-right:0}

É verdade que neste último exemplo apenas reduzimos o tamanho do código em 3 bytes, mas cada byte conta para um site mais rápido.

 

Cores
Os códigos hexadecimais das cores também podem ser reduzidos para ocupar menos espaço. Aliás, já devem ter reparado que nos exemplos acima apenas usei o código #000 para indicar preto.

Vamos então ver um exemplo de um border a branco e a cor de texto laranja.

1
.class {border:1px solid #ffffff; color:#ff9900}

Podemos reduzir este código facilmente, uma vez que os valores para cada canal do RGB são iguais. Por exemplo, na cor #575757 não podemos usar um valor hexadecimal mais curto, já na cor #557700 podemos usar o código #570.

Assim o código de cima poderia ser optimizado da seguinte forma.

1
.class {border:1px solid #fff; color:#f90}

A cor vai ser exactamente igual, mas cada código hexadecimal vai usar metade do espaço.

 

Fontes
Indicar a fonte que um site usa ocupa bastante espaço num ficheiro CSS. Mas podemos combinar todos os elementos (ou apenas alguns) num só atributo: font. Segue o exemplo.

1
.class {font-style:italic; font-variant:small-caps; font-weight:bold; font-size:12px; line-height:14px; font-family:Verdana, Arial, Helvetica, sans-serif}

Usando o shorthand podemos reduzir o código de 155 bytes para 85 bytes.

1
.class {font:italic small-caps bold 12px/48px Verdana, Arial, Helvetica, sans-serif}

Os vários atributos devem ser indicados por ordem, como no primeiro exemplo. Começamos com font-style e seguimos para font-variant, font-weight, font-size, line-height e finalmente font-family. Reparem que, para indicar o line-height é obrigatório indicar o font-size e estes valores devem ser separados por uma barra (/) entre eles. Tal como no exemplo, 12px/48px indica um tamanho de texto de 12px e um tamanho de linha de 48px.

Não é no entanto obrigatório indicar todos os valores. Vamos supor que queremos apenas o tamanho do texto a 12px com o tipo de letra Verdana.

1
.class {font:12px Verdana, Arial, Helvetica, sans-serif}

Os restantes valores serão usados por defeito ou serão aplicados valores de classes superiores.

 

Background
Tal como no font, o shorthand background permite poupar bastante espaço no ficheiro CSS. Vamos observar o seguinte exemplo:

1
.class {background-color:#fff; background-image:url(imagem.png); background-repeat:no-repeat; background-position:top; background-attachment:scroll}

Usando o shorthand podemos reduzir o código de 148 bytes para apenas 61 bytes.

1
.class {background:#fff url(imagem.png) no-repeat top scroll}

Tal como nas fontes, os vários atributos devem ser indicados por ordem. Primeiro o background-color e depois background-image, background-repeat background-position e background-attachment.

 

Espero que estes exemplos vos possam ser úteis e que os possam aplicar nos vossos projectos para reduzir o tamanho dos ficheiros CSS. Usar os shorthands no desenvolvimento de um projecto são uma boa prática para reduzir o tamanho do código CSS e tornar o seu carregamento mais rápido.

 
Copyright © 1985 - 2017 Eduardo Maio. Alguns direitos reservados.
eduardomaio.net - Às vezes mais valia ser Agricultor do que Programador
Ao navegar no blog eduardomaio.net está a concordar com os termos legais e de privacidade.