Desenvolvimento web

Desenvolvimento de site por R$150,00/Mês

Desenvolvimento Web responsivo com Melhor Custo-beneficio

Planos de desenvolvimento web com hospedagem Gratís
Arquivo de Empreedendores | LCF HOST

Empreedendores


Desenvolvimento Orientado a Modinha (DOM)

Você é adepto do Desenvolvimento Orientado a Modinha? Saiba como escapar dos hypes tecnológicos e se preservar através de importantes análises e dicas.

Você já trabalhou  com equipes que usam aquela metodologia de desenvolvimento infalível, o Desenvolvimento Orientado a Modinha? Você mesmo já usou (e/ou está usando) a mais nova tecnologia de software que aquela grande empresa lançou mês passado? Precisamos conversar sobre Hype Driven Development.

Equipes de desenvolvimento de software muitas vezes tomam decisões sobre arquitetura de software ou pilhas tecnológica com base em opiniões imprecisas, mídias sociais e, em geral, sobre o que é considerado “quente” (hype), em vez de sólida pesquisa e qualquer consideração séria do impacto esperado em seus projetos. Essa tendência pode ser chamada de Desenvolvimento Orientado a Modinha ou DOM —  originalmente, Hype Driven Development. Obviamente, existe uma abordagem mais profissional, chamada por alguns de Engenharia de Software Sólido (Solid Software Engineering). Saiba mais sobre como ele funciona e descubra o que você pode fazer em vez disso.

Nova tecnologia, nova esperança

Qual seu hype favorito?  🙂

Soa familiar? Uma equipe escolhendo tecnologia mais recente, mais “quente” para aplicar no projeto e alguém lê uma postagem em um blog, vê que é tendência no Twitter e todos acabaram de voltar de uma conferência onde houve uma grande conversa sobre isso. Logo a equipe começa a usar esta nova tecnologia brilhante — ou paradigma de arquitetura de software –, mas em vez de ir mais rápido (como prometido) e construir um produto melhor,  começa a se deparar com sérios problemas.

A velocidade de desenvolvimento diminui, todos ficam desmotivados, têm problemas para entregar a próxima versão do projeto para a produção. Algumas equipes ainda mantêm a correção de bugs em vez de fornecer novos recursos. São necessários “apenas mais alguns dias” para resolver tudo…

Desenvolvimento Orientado a Modinha ou Hype Driven Development

Desenvolvimento Orientado a Modinha (ou Hype Driven Development) vem em muitos sabores e toca seu projeto de muitas maneiras diferentes:

  • Desenvolvimento Orientado a Reddit. Quando uma equipe ou indivíduo decide sobre a tecnologia/arquitetura/design com base no blogueiro popular que escreveu o que está quente no Reddit, Hacker News, blog do Twitter, Facebook, GitHub ou outras mídias sociais.
  • Desenvolvimento Orientado a Conferência. Observe cuidadosamente o que acontece depois que pessoas (e programadores) retornam de uma conferência: elas ficam inspiradas. E isso é uma espada de dois gumes: começar a usar o mais novo paradigma/biblioteca/framework/arquitetura sem pesquisa suficiente pode ser uma estrada para o inferno.
  • Desenvolvimento Orientado ao Cara que Fala Mais. As decisões mais influentes são as do que está falando o tempo todo sobre esse novo framework/biblioteca/tecnologia que ele não tem experiência, mas fala sobre isso o tempo todo e finalmente a equipe decide adotar a coisa.
  • Desenvolvimento Orientado a Gem/lib/plugin. Um viés especialmente forte na comunidade Ruby On Rails, em que é possível ver um Gemfile por tanto tempo que a única coisa que leva mais tempo é para carregar o aplicativo. Vem da idéia de que cada problema em Rails deve ser resolvido através de um gem — sendo que, às vezes, apenas uma ou duas linhas de código dariam conta do recado ao invés de resolver o problema acrescentando mais problemas com libs, plugins, gems e/ou frameworks.
  • Desenvolvimento Orientado a Stack Overflow. Certamente uma das mais comuns de acontecer, dá-se quando programadores copiam e colam soluções do Stack Overflow (ou encontradas na web, em geral) sem realmente entendê-las.

A raiz de todo o mal?

O problema com hypes é que eles facilmente levam a más decisões. Tanto a decisões arquitetônicas ruins, quanto a decisões tecnológicas sobre stacks costumam assombrar uma equipe meses ou mesmo anos mais tarde. No pior caso, elas podem levar a outra situação muito problemática em engenharia de software: A Grande Reescrita (The Big Rewrite).

A raiz de todo o mal parece estar nas mídias sociais, nas quais novas idéias se espalham muito mais rápido do que são testadas; muito mais rápido do que as pessoas são capazes de compreender os seus prós e contras.

A anatomia de um hype

A maioria dos hypes têm uma estrutura similar a esta:

“Ciclo do Hype” (clique para ampliar)

Passo 1: Problema real e solução

Eles começam em alguma empresa com um problema. Uma equipe dentro de alguma empresa decide que a solução para o problema está além da pilha tecnológica atual, processo ou arquitetura. A empresa cria uma nova estrutura, biblioteca ou paradigma e logo o problema é resolvido.

Passo 2: Buzz & Keywords

A equipe está animada para mostrar seu trabalho para o resto do mundo e logo eles escrevem posts e fazem palestras e conferências. O problema muitas vezes não é trivial, então eles se orgulham de apresentar os resultados impressionantes de uma solução “da casa”. As pessoas ficam entusiasmadas com a nova tecnologia. O maior problema é que nem todos que ficam animados são capazes de compreender exatamente qual era o problema inicial e todos os detalhes da solução — afinal, tratava-se de um problema não-trivial com uma solução não-trivial.

Leva mais do que um tweet, bate-papo ou post no blog para explicar. Com ferramentas de comunicação como mídias sociais, artigos de blogs e conferências-relâmpago, ocorre muito ruído na comunicação e a mensagem fica “borrada” ao longo do caminho.

Passo 3: Obsessão

Toda força do hype leva desenvolvedores a lerem artigos e a participarem de conferências sobre a tecnologia. Logo as equipes de todo o mundo começam a usar a usá-la. Devido à mensagem “borrada”, algumas delas tomam decisões precipitadas de uso da tecnologia — mesmo que ela não resolva qualquer um de seus problemas reais. No entanto, a equipe tem expectativa de que esta nova tecnologia vai ajudar.

Passo 4: Desapontamento

Conforme os sprints passam, a tecnologia não melhora a vida da equipe tanto quanto as pessoas esperavam, mas traz muito trabalho extra. Há muita reescrita de código e aprendizagem extra para a equipe. As equipes diminuem a velocidade, a administração fica chateada. Todos se sentem enganados.

Passo 5: Realização

Finalmente, a equipe faz uma retrospecção e percebe quais são os prós e contras da nova tecnologia e para que finalidade ela seria mais relevante. Todos ficam mais sábios… Até o próximo hype aparecer.

Exemplos reais de hypes

É só pensarmos um pouquinho para lembrar de alguns exemplos reais do “Ciclo do Hype”, em ocasiões que trouxeram muitos infortúnios para muitas equipes de desenvolvimento pelo mundo.

React.js

  1. Problema real e solução. SPAs, como o próprio Facebook, têm tantos eventos de mudança de estado que é difícil manter o controle do que está acontecendo e manter o estado do aplicativo consistente.
  2. Buzz & Keywords. “Funcional”, “DOM Virtual”, “Componentes”.
  3. Obsessão. “Facebook criou a estrutura front-end do futuro! Vamos escrever tudo em React de agora em diante!”
  4. Desapontamento. Há muito trabalho, mas nenhum retorno rápido sobre o investimento.
  5. Realização. React é ótimo para SPAs avançados com muitas notificações em tempo real, mas não necessariamente vale a pena para aplicativos mais simples.

“TDD está morto”

  1. Problema real e solução. David Heinemeier Hansson (criador do framework Ruby on Rails) percebe que é difícil fazer TDD com Rails — já que ele não tem uma boa arquitetura, que comporta OOP — e faz uma escolha pragmática: não escrever mais testes antecipadamente; não trabalhar mais com TDD.
  2. Buzz & Keywords. O hype começa com um post no blog de DHH e uma conferência. Termo-chave do hype: “TDD está morto”.
  3. Obsessão. “Vamos pular os testes! Nosso Guru diz isso. Nós não escrevemos eles de qualquer maneira. Agora, pelo menos, não estamos fingindo. Finalmente somos honestos.”
  4. Desapontamento. Há muito trabalho, mas nenhum retorno rápido sobre o investimento.
  5. Realização. “TDD não está morto ou vivo. TDD está sujeito a tradeoffs, incluindo o risco de mudanças de API, habilidades dos participantes e design existente.” — Kent Beck.

Microservices

  1. Problema real e solução. Grandes aplicações monolítica têm escalonamento difícil. Há um ponto em que é possível dividí-las em serviços. Será mais fácil de escalar em termos de req/sec e mais fácil de escalar entre várias equipes.
  2. Buzz & Keywords. Palavras-chave do hype: “Escalabilidade”, “Baixo Acoplamento”, “Monolítico”.
  3. Obsessão. “Temos um ‘código de espaguete’ porque temos uma arquitetura monolítica! Precisamos reescrever tudo para microservices!”
  4. Desapontamento. Agora é mais lento desenvolver o aplicativo. E difícil de implantar e se passa muito tempo rastreando bugs em vários sistemas.
  5. Realização. Microservices exigem habilidadess “devops” na equipe. Antes de se chegar a graves questões de escalonamento, são um um investimento excessivo. Microservices são extraídos, não escritos.

NoSQL

  1. Problema real e solução. Bancos de Dados SQL têm problemas com cargas elevadas e dados não estruturados. Equipes de todo o mundo começam a desenvolver uma nova geração de BDs.
  2. Buzz & Keywords. Palavras-chave do hype: “Escalabilidade”, “BigData”, “Alta Performance”.
  3. Obsessão. “Nosso banco de dados é muito lento e não é grande o suficiente! Precisamos do NoSQL!”
  4. Desapontamento. “Precisamos usar JOIN nas tabelas? Isso é problemático”. Operações SQL simples se tornam cada vez mais desafiadoras. O desenvolvimento fica lento e os principais problemas não são resolvidos.
  5. Realização. NoSQL são ferramentas para resolver problemas muito específicos — tanto volumes extremamente elevados de dados, dados não estruturados ou cargas muito altas. SQL é realmente uma ótima ferramenta, capaz de lidar com alta carga e volumes de dados enormes se for bem usada.

Elixir e Phoenix (ou sua dobradinha favorita de linguagem/framework)

  1. Problema real e solução. Frameworks web como o Ruby On Rails não lidam bem com aplicativos de alto desempenho, aplicativos distribuídos e websockets.
  2. Buzz & Keywords. Palavras-chave do hype: “Escalabilidade”, “Alta Performance”, “Distribuído”, “Tolerante a Falhas”.
  3. Obsessão. “Nosso aplicativo é lento e nosso bate-papo não é escalável!”
  4. Desapontamento. “Aprender programação funcional e abordagem distribuída não é tão fácil. Agora estamos muito lentos.”
  5. Realização. Elixir e Phoenix formam um excelente framework, mas demanda um esforço significativo para aprender. Haverá retorno a um longo prazo se você precisa especificamente de um app de alto desempenho.

E a lista continua…

O espaço lotado da Engenharia da Computação apresenta muitas áreas em que hypes são comuns. No mundo do JavaScript, por exemplo, novos frameworks  são criados todos os dias. Node.js, Programação Reativa, Meteor.js, Front-end MVC, React.js. Na engenharia de software nascem novas arquiteturas: Domain Driven Development, Hexagon, DCI…

Qual é o seu hype favorito?  🙂

Boas práticas para evitar o DOM

Aprenda sobre uma tecnologia não somente de blogs, mas com a experiência.

Então, se não podemos confiar no que a internet diz e opiniões de outras pessoas, como tomar decisões inteligentes em relação ao Desenvolvimento Orientado a Modinha? Eis algumas dicas e boas práticas.

Teste e pesquise antes de decidir

Aprenda sobre uma tecnologia não somente de blogs, mas com a experiência. A caráter de testes, invista 1 ou 2 dias para construir um protótipo de alguma funcionalidade na nova tecnologia antes de tomar uma decisão. Deixe a equipe analisar os prós e contras. É possível usar algumas tecnologias competitivas e permitir que diferentes partes da equipe construam protótipos com tecnologias diferentes.

Participar de hackathons é uma ótima maneira de construir a consciência de uma equipe através da análise de tradeoffs de diferentes tecnologias. Tome 1 ou 2 dias para toda a equipe testar todas as tecnologias que estão em ascensão. Isso permitirá que a equipe tome decisões inteligentes por si mesma, com base em sua própria experiência.

Quando arriscar?

A princípio, quando o retorno do investimento é enorme. A maioria das tecnologias são criadas para resolver um problema específico. Você tem esse problema? É um problema grande? Será que vai economizar muito tempo? Será que o uso da tecnologia paga o custo da curva de entrada e reescrita? E se inicialmente retardarmos o desenvolvimento pelo fator de dois? Ou quatro? Ainda vale a pena?

Algumas equipes são mais rápidas do que outras em entregar valor, chegando ao ponto de ficarem entediadas ao realizarem entregas de maneira mais fácil. Essas equipes podem introduzir novas tecnologias com mais freqüência — por outro lado, se a equipe tem problemas com entregas, este um forte indício para proceder com cautela.

Trabalhe com as pessoas certas

Ter uma formação técnica sólida é essencial: pessoas que conhecem diferentes paradigmas, compreendem a teoria da programação (por exemplo, algoritmos, concorrência etc) e têm boa cultura de engenharia tendem a ser menos suscetíveis a hypes.

Experiência também conta muito. Hypes impressionam mais desenvolvedores jovens. Com o passar dos anos, as pessoas que viram muitas tecnologias e estiveram em problemas muitas vezes tendem a ter uma visão mais equilibrada da tecnologia e sabem escolher melhor.

Conclusão sobre Desenvolvimento Orientado a Modinha

Desenvolvimento Orientado a Modinha (ou Hype Driven Development) não é novidade. Acontece de de um hype realmente se consolidar no mercado e se tornar “a nova melhor prática”, mas a quantidade de hypes é tão grande que, estatisticamente, poucos são os que alcançam o status de “paradigma” e se mantêm lá.

As dicas de testar e pesquisar, saber quando arriscar e trabalhar com as pessoas certas — com ênfase aos não tão jovens e/ou aventureiros — realmente surtem resultados. Seguí-las pode determinar o sucesso ou fracasso de seus negócios no mundo dos softwares.

bom senso sempre foi um dos melhores aliados de todos nós. Parece que é hora de começar a dar mais atenção a este velho amigo.


Erros comuns em desenvolvimento web para campanhas de SEO

Conheça erros comuns em desenvolvimento web para campanhas de SEO e saiba como evitá-los

Uma boa campanha de SEO acontece quando várias ações de otimização são realizadas, conjunta e simultaneamente. E, certamente, uma dos aspectos da estratégia de uma ação de SEO são as ações técnicas tomadas no desenvolvimento web.

Este é um artigo traduzido do original “Why my SEO campaign failed? Part 2: Common Web Development mistakes“, do blog Web SEO Analytics, e sofreu pequenas modificações.

Passar muitos argumentos no URL

Quando o site é dinâmico, os desenvolvedores web precisam ter uma referência sobre o qual a página, o produto ou categoria o visitante quer ver. Normalmente um ID é necessário para recuperar os dados do banco de dados. Em outros casos, devido à complexidade do projetoou devido a más técnicas de programação, mais variáveis são necessárias para identificar uma determinada página. Aqui está um exemplo de um URL dinâmico:

Infelizmente, este tipo de URL não é amigável nem para pessoas, nem para mecanismos de busca. Segundo é possível ler nas Diretrizes Técnicas das Diretrizes para Webmasters da Central do Webmaster Google,

Se você decidir usar páginas dinâmicas (por exemplo, o URL que contém um caractere “?”), saiba que nem todos os spiders de mecanismos de pesquisa rastreiam as páginas dinâmicas e estáticas. Isso ajuda a manter os parâmetros curtos e a quantidade desses parâmetros pequena.

Por isso, é altamente recomendado usar algum tipo de reescrita de URL, como mod_rewrite, para converter as URLs dinâmicas para URLs amigáveis. Qual é o risco, se isso não for feito? Bem, se há muitos parâmetros em URLs: os motores de busca podem não indexar as páginas; além disso, geralmente  URLs não amigáveis não contém palavras-chave importantes no endereço, então, não raramente você pode conseguirá rankings inferiores para essas páginas do que se elas tivessem URLs amigáveis.

Usar muito JavaScript, frames/iframes, AJAX, Flash e Silverlight

JavaScript, frames/iframes, AJAX, Flash e Silverlight são ferramentas úteis e alguns deles, quando bem usados, melhoram a experiência do usuário. Mas nenhum deles é search engine friendly.

As mesmas Diretrizes Técnicas do Google citadas, indicam:

Use um navegador de texto como o Lynx para examinar o seu site, pois muitos spiders de mecanismos de pesquisa veem o site do mesmo modo que o Lynx. Se recursos especiais como JavaScript, cookies, IDs de sessão, frames, DHTML ou Flash permitirem que você veja todo o site em um navegador de texto, os spiders dos mecanismos de pesquisa poderão ter dificuldade em rastrear o seu site.

Se o objetivo é que o site seja amigável aos mecanismos de busca, devemos verificar se eles podem ser vistos usando browsers de texto simples como o Lynx (que é como o googlebot “vê” os sites). É possível usar emuladores do Lynx ou desabilitar CSS e imagens diretamente no navegador (se usar, Firefox, uma ótima opção é usar o plugin Web Developer).

Não usar o atributo alt em imagens e não otimizar o caminho das imagens

Os motores de busca (e computadores, em geral) não são muito bons em identificar o que é representado em uma imagem. Portanto, a fim de compreender sobre o que uma imagem é, os bots analisam o nome e o atributo “alt” das imagens.

O Google Image Search pode trazer uma quantidade significativa de tráfego. Se você não garantir o “apoio” a mecanismos que permitam a otimização de imagens, você pode perder uma boa fonte de tráfego. Assim, garanta que você use corretamente ambos, o atributo alt e o nome da imagem – usar um CMS que permita esse tipo de otimização é uma boa dica.

Usar métodos incorretos para oferecer suporte a idiomas diferentes

Quando você tem sites multilíngue, tenha certeza de que a arquitetura está correta. Não há uma única forma “correta” para fazer isso. Basicamente, há três maneiras corretas para suportar um site em vários idiomas e cada um dos métodos a seguir tem alguns prós e contras:

  • Subdomínios. Exemplo: fr.example.com, gr.example.com, etc
  • Subdiretórios. Exemplo: www.example.com/fr/, www.example.com/gr/, etc
  • Diferente domínios. Exemplo: www.example.fr, www.example.gr, etc

A dica é evitar o envio de conteúdo baseado em IP sem ter a mesma versão do site disponível para todos. Também não implementar soluções ruins como passar o idioma como uma variável GET, por exemplo www.example.com/?lang=fr.

Não se preocupar com o tempo de carregamento da página

Recentemente o Google informou que passou a usar a velocidade de carregamento dos websites em seus algoritmos de classificação (apesar de isso não estar valendo para sites de todos os países do mundo). Há um debate sobre se esse recurso deve ser incluído, uma vez que não tem nada a ver com a relevância de um site. No entanto, a velocidade aumenta a experiência do usuário. Além disso, ter um site leve, que carregue rapidamente, pode melhorar seu ROI e diminuir a carga do seu servidor (conheça 8 maneiras de melhorar a performance de um site).

7 dicas de desenvolvimento web

Algumas dicas para guiar o desenvolvimento de suas páginas web são:

  • Colocar menus, cabeçalhos e rodapés em arquivos separados, a fim de realizar mudanças globais rápidas (funções “include);
  • Tentar usar subdomínios em sites multi idioimas;
  • Usar caminhos absolutos para cada página, imagem, CSS e javascript do site;
  • Usar canonicals para evitar conteúdo duplicado;
  • Usar redirecionamento 301 ao invés de 302 quando o caminho para a página mudar e nunca apagar páginas;
  • Redirecione corretamente as versões sem “www” para as que tenham “www” e vice-versa;
  • Não adicionar IDs de sessão nas URLs.

E você, conhece algum outro erro comum em desenvolvimento web que pode atrapalhar uma campanha de SEO e o que fazer para evitar/corrigir?


Os melhores bancos de imagens (stock images) grátis

Lista com os melhores bancos de imagens grátis (free stock images) em uma compilação sensacional para usar imagens em qualquer projeto web.

Todos nós já fizemos uma busca por imagens no Google. Mas em função do acordo antipirataria antipirataria com a Getty Imagesa empresa decidiu remover o botão “Ver imagem”. Também pensamos que fosse algum topo de brincadeira de mal gosto, mas é a sério mesmo! Se você fizer uma busca por imagens neste exato momento, já vai notar a falta do amado botãozinho…

A opção de arrastar uma imagem para a barra de busca (“busca reversa”) continua lá — e para os que não descuidaram dos mistérios profundos do clique com o botão direito do mouse, o impacto pode não ser assim tão grande –, mas o grande público, com a ausência da opção, certamente vai começar a visitar muito mais sites do que fazia antes, se é que vocês me entendem.

Fazendo do limão que a Google nos deu uma deliciosa limonada, segue lista dos melhores sites para conseguir imagens grátis para serem usadas — as famosas stock photos. Isso mesmo: os melhores bancos de imagens grátis que podem ser usadas à vontade, imagens sem direitos autorais. E estamos falando de boas imagens, de alta resolução, para serem usadas em qualquer projeto web!

Pexels

Sem dúvida alguma, Pexels é um dos melhores serviços de banco de imagens de graça que existem atualmente. Grande parte das imagens “hero” aqui do desenvolvimento para web são de lá. Dê uma passeada pelos posts para ter uma amostra da qualidade das imagens que o site oferece.

Para virar fã de vez, todas as imagens estão sob a licença Creative Commons Zero (CC0), que, na prática, significa que são de domínio público e é permitido usá-las à vontade, para qualquer fim, com ou sem edição, inclusive comercialmente.

O objetivo do Pexels é oferecer “high quality and completely free stock photos“, quer dizer, fotos de alta qualidade e completamente grátis. Até o momento, estão conseguindo. Com louvor.

Foter

Uma outra excelente opção quando o assunto é banco de imagens gratis é o Foter. Ao oferecer “Premium Royalty-Free Stock Photos“, ele também é uma alternativa de peso que deve ser sempre altamente considerado ao se procurar boas imagens.

Mas qual é o segredo para ser um stock de imagens com mais de 220 milhões de opções? Eles usam a API do Flickr para buscar fotos licenciadas sob Creative Commons!

Fazer uma busca por algum termo do interesse/necessidade ou navegando pelas categorias do Foter, rapidamente você vai comprovar que ele também é uma das melhores opções de banco de imagens disponíveis atualmente.

Pixabay

A primeira coisa que pode ser lida ao entrar no Pixabay é: Imagens gratuitas de alta qualidade. Mas talvez você encontre algo a mais: vídeos! Para entender melhor, não é preciso mais do que as própria explicação que consta no site:

Imagens e vídeos gratuitos que você pode usar em qualquer lugar: Pixabay é uma vibrante comunidade de criativos, compartilhando imagens e vídeos livres de direitos autorais. Todos os conteúdos são lançados no Creative Commons CC0, o que os torna seguros de usar sem pedir permissão ou dar crédito ao artista — mesmo para fins comerciais.

Com quase 1,5 milhão de opções (e crescendo), talvez você se arrependa de não consultar o Pixabay quando estiver procurando por imagens.

Unsplash

Há 3 regras do Unplash que você deve saber:

  1. As imagens são grátis para uso pessoal e comercial;
  2. Nenhuma atribuição é necessária e;
  3. Novas fotos são adicionadas diariamente.

A empresa canadense oferece incontáveis opções de imagens para serem usadas à vontade que podem ser encontradas através de busca, categorias ou coleções próprias, organizadas e disponibilizadas também de maneira gratuita.

Acesse e navegue um pouquinho pela Unsplash para comprovar a qualidade. Realmente não fica devendo nada para qualquer outro serviço de stock image similar.

Visual Hunt

Se você entra em um stock de imagens e quer opções, qual é o número de opções de imagens disponíveis bom o suficiente? Se a resposta é algo em torno de 350 milhões de fotos grátis, então certamente este é o momento de conhecer o Visual Hunt.

High quality free photos in one place“. Esse é o lema do Visual Hunt. Para tanto, eles são uma espécie de agregado de vários stocks de imagens, coletando diversas fotos pela web à fora e as juntando em um só lugar — também usando aquela ajudinha marota da API Flickr.

A maioria das imagens têm licença CC0, são divididas por categorias e tags e a busca é bastante eficiente. Ah, e eles deixam fazer o embed diretamente do site!

StockSnap

Sendo um auto-denominado serviço de curadoria de imagens, a frase que o pessoal da StockSanap gosta de divulgar é: “StockSnap is the best place on the internet to find beautiful free stock photos”, ou, em outras palavras, o melhor banco de imagens grátis da internet. Para saber se é verdade ou não que seja “o melhor”, você mesmo vai ter que entrar para conferir.

Todas as imagens — que podem ser encontradas pela busca, categorias ou uma seção especial de “tendências” — também estão sob Creative Commons Zero. Use sem pudores!

Contribua com os bancos de imagens grátis

Certamente a lista de sites de stock photos apresentados no artigo não pretende ser uma completamente abrangente. Existem literalmente milhares de sites que disponibilizam bancos de imagens e seria uma maluquice querer colocar todos em uma só listagem.

Mas estes são excelentes sites, de renome e reconhecimento mundiais. E sabe como chegaram a este status? A maioria deles permite a contribuição de qualquer um que julgue que suas imagens sem realmente de qualidade e devam ser compartilhadas sem limites com o mundo.

Se você gosta de dar uns cliques e gostaria de ajudar com estes fabulosos serviços de banco de imagens, veja quais desses lhe agradam mais, faça seu login e comece a fazer do mundo das imagens grátis um lugar ainda melhor!


Responsive Components: uma solução para container queries

Conheça Responsive Components, uma solução para componentes responsivos que resolve o problema de Container Queries e pode ser usada imediatamente!

Você já deve ter ouvido falar em Container Queries, uma proposta que permitiria a desenvolvedores web estilizarmos elementos DOM com base no tamanho do elemento contentor (“que contém”) ao invés do tamanho da viewport do navegador. Mas já ouviu sobre Responsive Components?

Se você é um desenvolvedor a par das discussões envolvendo responsividade, provavelmente já ouviu falar sobre Container Queries antes. Desde quando toda a festa de web design responsivo começou, já havia desenvolvedores pedindo por tal recurso (inicialmente Element Queries, depois mudando para Container Queries) — de fato, Container Queries podem ser o recurso CSS mais solicitado que os navegadores ainda não têm.

Já existem muitosmuitosmuitos artigos explicando exatamente porquê container queries são difíceis de fazer no CSS e porquê os fabricantes de navegadores hesitaram em implementá-las. Essa discussão não precisa ser revivida neste post.

Ao invés de focar estritamente na proposta formal de CSS chamada “Container Queries” (Consultas de Contêiner), este artigo abordará o conceito mais amplo de construção de componentes que respondem a seu “ambiente” — responsive components. E se você aceitar esse “enquadramento” maior, realmente já existem novas APIs que permitem que se obtenha isso. Isso mesmo: não é preciso esperar Container Queries chegarem oficialmente para começar a criar componentes responsivos; é possível começar agora!

A estratégia proposta neste artigo permite o uso hoje e é projetada como um aprimoramento, então os navegadores que não suportam as APIs mais recentes ou não executam JavaScript funcionarão exatamente como fazem atualmente. Também é simples de implementar, altamente performática e não requer nenhuma ferramenta especial, bibliotecas ou frameworks.

Para ver alguns exemplos dessa estratégia em ação, existe o site de demonstração Responsive Components, em que cada exemplo aponta para o código-fonte CSS.

Mas antes de começar a realmente ver alguns exemplos, é importante saber como a estratégia proposta funciona.

A estratégia de Responsive Components

A maioria das estratégias/metodologias de web design responsivo funcionam de acordo com estes 2 princípios fundamentais (e aqui não será diferente):

  1. Para cada componente, define-se primeiro um conjunto-base de estilos genéricos que se aplicam independentemente do ambiente em que o componente esteja contextualizado/inserido
  2. Em seguida, definem-se adições ou substituições para os estilos-base que se aplicam em condições ambientais específicas

O poder desses princípios é que eles funcionam mesmo se o navegador não suportar os recursos necessários para cumprir ou permitir condições de ambiente específicas. E isso inclui casos em que o recurso requer JavaScript — usuários com JavaScript desativado obterão os estilos-base e eles funcionarão normalmente.

Na maioria dos casos, os estilos-base definidos no item “1” acima são estilos que funcionam para os menores tamanhos de viewport possíveis (uma vez que viewports menores tendem a ser mais restritivas do que as maiores) e elas não estão envolvidas com nenhum tipo de media query (o que significa que se aplicam em toda parte).

Eis um exemplo que define estilos-base para .MyComponent e depois os substituem em 2 breakpoints arbitrários, 36em e 48em:

Claro, esses breakpoints usam media queries, então eles se aplicam ao tamanho da viewport do navegador. O que os defensores de container queries procuram é a capacidade de fazer algo como isto (nota: esta é a sintaxe proposta; não a sintaxe oficial):

Infelizmente, a sintaxe acima não funciona em nenhum navegador atualmente e não funcioná tão cedo… No entanto, funciona hoje algo mais ou menos como:

Claro, este código assume que os contêineres de componentes têm as classes corretas adicionadas a eles (neste exemplo, .MD e .LG). Mas ignorando esse detalhe por enquanto, a segunda sintaxe ainda faz sentido para qualquer desenvolvedor CSS que quer construir um componente responsivo.

Quer esteja escrevendo uma container query como uma query de comparação de largura (a primeira sintaxe) ou usando classes de breakpoint nomeadas (a segunda sintaxe), os estilos ainda são declarativos e funcionalmente os mesmos. Contanto que seja possível definir breakpoints nomeados, aparentemente não há um benefício claro a favor de um ou de outro.

E para que o restante do artigo fique claro, aqui está o mapeamento das classes/breakpoints (no qual min-width se aplica ao contêiner, não à viewport):

BreakpointLargura do Container
SMmin-width: 24em (384px)
MDmin-width: 36em (576px)
LGmin-width: 48em (768px)
XLmin-width: 60em (960px)

Agora é preciso garantir que os elementos de contêiner tenham sempre as classes de breakpoint corretas; então os seletores de componentes corretos irão corresponder (match).

Observando redimensionamento de contêineres

Quase desde sempre em desenvolvimento web foi possível observar mudanças em window, mas também quase sempre foi difícil ou impossível (pelo menos de uma forma significativa) observar mudanças de tamanho em elementos individuais de DOM. Isso mudou quando o Chrome 64 disponibilizou ResizeObserver.

ResizeObserver, seguindo os passos de APIs semelhantes, como MutationObserver e IntersectionObserver, permite que sejam observadas mudanças de tamanho nos elementos DOM de uma forma altamente performática.

Aqui está um possível código necessário para fazer com que o CSS mostrado anteriormente funcione com ResizeObserver:

Este exemplo usa a sintaxe ES5 porque (como será explicado mais adiante) pode ser interessante inserir este código diretamente no HTML em vez de incluí-lo em um arquivo JavaScript externo. A sintaxe mais antiga é usada para garantir um amplo suporte de navegadores.

O código cria uma instância única de ResizeObserver com uma função de callback. Em seguida, consulta o DOM por elementos com o atributo data-observe-resizes e começa a observá-los. A callback — que é invocada inicialmente após a observação e novamente após qualquer alteração — verifica o tamanho de cada elemento e adiciona (ou remove) as classes de breakpoint correspondentes.

Em outras palavras, esse código transformará um elemento de contêiner com 600px de largura assim:

Para:

E essas classes serão atualizadas automática e instantaneamente sempre que o tamanho do contêiner mudar. Com isso, os seletores .SM e .MD corresponderão (mas não os seletores .LG ou .XL) e esse código funcionará perfeitamente.

Customizando breakpoints

O código na callback de ResizeObserver acima define um conjunto padrão de breakpoints, mas também permite que sejam especificados breakpoints personalizados por componente, passando um JSON através do atributo data-breakpoints.

A estratégia recomendada é alterar o código acima para usar qualquer mapeamento-padrão de breakpoints que faça mais sentido para o projeto que se está trabalhando e, em seguida, especificar inline um conjunto de breakpoints específicos para qualquer componente que precise:

O site Responsive Components tem um exemplo de um componente que configura seus próprios breakpoints juntamente com componentes usando breakpoints padrão.

Lidando com alterações dinâmicas no DOM

O exemplo de código acima apenas funciona para elementos de contêiner que já estão no DOM.

Para sites baseados em conteúdo (content-based sites), isso geralmente é bom, mas para sites mais complexos, cujo DOM muda constantemente, será preciso se certificar de que a observação de todos os elementos de contêiner adicionados dinamicamente está acontecendo.

Uma solução “one-size-fits-all” para este problema é expandir o snippet acima para incluir um MutationObserver que acompanha todos os elementos de DOM adicionados. Esta é a abordagem usada no site Responsive Components, que funciona bem para sites de pequeno e médio porte com modificações de DOM limitadas.

Para sites maiores, com atualizações freqüentes no DOM, já se usa algo como Custom Elements ou algum framework com métodos de lifecycle que rastreiam quando elementos são adicionados/removidos do DOM — se for este o caso, provavelmente é melhor apenas fazer um hook a esses mecanismos.

Por exemplo, um elemento personalizado <responsive-container> poderia ser algo assim:

Embora seja tentador criar um novo ResizeObserver para cada elemento de contêiner, é realmente muito melhor criar um único que observa muitos elementos. Para saber mais, veja as descobertas de Aleks Totic sobre o desempenho do ResizeObserver na lista de discussão blink-dev.

Componentes aninhados

Nas primeiras experimentações com esta estratégia, cada componente não foi envolvido com um elemento de contêiner. Em vez disso, foi usado um único elemento de contêiner por área de conteúdo distinta (header, sidebar, footer etc.) e, no CSS, usados combinadores de descendentes (descendant combinators) ao invés de combinadores de filho (child combinators).

Isso resultou em marcação e estilo mais simples, mas rapidamente se desfez quando se tentou aninhar componentes dentro de outros componentes (o que não é muito raro). O problema é que, com a abordagem do combinador descendente, os seletores corresponderam a vários containers ao mesmo tempo…

Após a construção de alguns demos não-triviais, tornou-se claro que uma estrutura direta filho/pai para cada componente e seu contêiner era muito mais fácil de gerenciar e dimensionar. Observe que os recipientes ainda podem conter mais de um componente, desde que cada um deles seja um descendente direto.

Seletores avançados e abordagens alternativas

Como já explicado, a estratégia descrita neste artigo traz uma abordagem aditiva para estilizar componentes: inicia-se com estilos-base para adicionar mais estilos em seguida. Entretanto, esta não é a única abordagem possível. Em algumas situações, pode ser preciso definir estilos que correspondam exclusivamente e somente se apliquem a um breakpoint específico (ex: ao invés de (min-width: 48em), algo como (min-width: 48em) and (max-width: 60em)).

Se fosse este o caso, seria preciso ajustar um pouco o callback de ResizeObserver para aplicar o nome da classe do breakpoint que corresponde atualmente (currently-matching breakpoint). Então, se o componente estivesse em seu tamanho “grande”, ao invés de definir o nome da classe SM MD LG, seria simplesmente LG.

No CSS, seria possível escrever seletores como:

Importante notar que, ao usar a estratégia para correspondência aditiva, ainda pode haver correspondência exclusiva por meio de um seletor como .MD:not(.LG) — embora a leitura desse seletor seja mais custosa (para humanos e máquinas).

No final das contas, é possível escolher qualquer convenção que faça mais sentido para o projeto em questão; que funcione melhor para a situação concreta que se apresente.

O seletor :matches() ainda não é bem suportado nos navegadores atuais. Mas é possível usar ferramentas como postcss-selector-matches e similares para transpilar em algo que funcione de maneira cross-browser.

Breakpoints de altura

Até agora, todos os exemplos focaram em breakpoints de largura. Não é surpresa, já que a maioria esmagadora das implementações de web design responsivo usam a largura e nada mais (pelo menos quando se trata de dimensões da viewport). Contudo, nada na estratégia apresentada no artigo evitaria que um componente respondesse à altura de seu container, já que ResizeObserver reporta ambas as dimensões.

Portanto, se fosse preciso observar mudanças de altura, seria possível definir um conjunto separado de classes de breakpoints — talvez com um prefixo W- para breakpoints de largura e H- para breakpoints de altura.

Suporte dos navegadores

Na data de publicação deste artigo, ResizeObserver só é suportado no Chrome, mas não há absolutamente nenhuma razão para que não seja possível usá-lo imediatamente. A estratégia descrita aqui é intencionalmente projetada para funcionar bem se o navegador não suportar ResizeObserver ou mesmo se o JavaScript estiver desabilitado.

Em qualquer um desses casos, os visitantes verão os estilos-padrão — que devem ser mais do que suficientes para oferecer uma boa experiência. Na verdade, eles provavelmente serão os mesmos estilos que você já está oferecendo hoje.

A abordagem recomendada é usar media queries para o layout do site e, em seguida, essa estratégia de componentes responsivos para componentes específicos que precisem dele (muitos não irão precisar).

Se for preciso fornecer uma UI consistente em todos os navegadores, é possível usar o polyfill de ResizeObserver, que oferece um excelente suporte (IE9+). Entretanto, certifique-se de que o polyfill seja carregado somente quando for realmente preciso.

Também é importante levar em consideração que polyfills tendem a ser mais lentos em dispositivos móveis e, dado que componentes responsivos importam mais em viewports maiores, provavelmente não é preciso carregar o polyfill se o visitante estiver em um dispositivo com viewport pequena.

O site de demonstração Responsive Components leva em conta esta última abordagem: ele carrega o polyfill somente se o navegador não suporta ResizeObserver e se a largura da viewport é pelo menos 48em.

Limitações e melhorias futuras

No geral, a estratégia de componentes responsivos descrita neste artigo é incrivelmente versátil e tem poucas desvantagens. A partir de agora, é altamente recomendado que sites com áreas de conteúdo cujos tamanhos possam mudar independentemente da viewport implementem uma estratégia de componentes responsivos ao invés de confiar somente em media queries (ou alguma solução JavaScript que não aproveita ResizeObserver).

Isto posto, passemos a algumas limitações que valem a pena serem discutidas.

Não é CSS puro

Uma desvantagem óbvia desta solução é que requer mais do que apenas CSS para ser implementada. Além de definir os estilos em CSS, também é preciso se valer de marcação no HTML e coordenar ambos com JavaScript.

Certamente uma solução baseada em CSS puro é a ideal; é o objetivo final. Mas não há motivos sólidos para impedir o uso desta estratégia hoje.

“Flash of un/incorrectly-styled content”

Na maioria dos casos, é uma prática recomendada carregar todo o JavaScript de forma assíncrona, mas, neste caso, o carregamento assíncrono pode levar os componentes a renderizar inicialmente no breakpoint padrão para depois alternar para um breakpoint maior depois de o JavaScript ser carregado.

Embora esta não seja a pior experiência do mundo, é algo que definitivamente não estaria na lista de preocupações em uma solução de CSS puro. E uma vez que esta estratégia envolve coordenação com JavaScript, também é preciso prestar atenção quando estilos e breakpoints são aplicados para evitar esse re-layout.

Uma das maneiras mais ágeis para lidar com isso é incorporar o código de container query no final dos templates de HTML, garantindo que seja executado o mais rápido possível. Em seguida, adicionando-se uma classe ou atributo aos elementos de contêiner uma vez que sejam inicializados e estejam visíveis para que se saiba quando é seguro mostrá-los (e se certificar de considerar o caso em que o JavaScript está desativado ou cause erros quando executado). É possível ver um exemplo disso no site de demonstração.

As unidades são baseadas em pixels

Muitos desenvolvedores de CSS (se não a maioria) preferem definir estilos com base em unidades com mais relevância contextual (por exemplo: emvh etc.), enquanto o ResizeObserver, como a maioria das API de DOM, retorna todos seus valores em px.

No momento, não há realmente nenhuma boa maneira para contornar isso.

No futuro, uma vez que os navegadores implementem CSS Typed OM (uma das novas especificações CSS Houdini), será possível converter fácil e economicamente entre várias unidades de CSS.

Até lá, o custo de realizar esta conversão provavelmente afetaria o desempenho ao ponto de prejudicar a experiência do usuário.

Conclusão sobre Responsive Components

Este artigo descreve uma estratégia para o uso de tecnologias web modernas para criar responsive components: elementos DOM que podem atualizar seu estilo e layout em resposta a mudanças no tamanho de seu contêiner.

Enquanto as tentativas anteriores de construir componentes responsivos eram valiosas em sua exploração/tentativa, limitações na plataforma significavam que essas soluções eram sempre grandes demais, lentas demais ou ambas. Felizmente, agora existem APIs de navegador que permitem construir soluções eficientes e performáticas.

A estratégia descrita neste artigo:

  • Funciona, hoje, em qualquer site
  • É fácil de implementar (copiar > colar)
  • Tem performance tão boa quando uma solução baseada em CSS puro
  • Não requer bibliotecas específicas ou frameworks
  • Vale-se de aprimoramento progressivo (progressive enhancement): quem não tiver as APIs necessárias ou esteja com JavaScript desabilitado ainda consegue usar o site

A estratégia apresentada neste artigo é “pronta para produção” (production-ready), mas ainda estamos muito nos primeiros estágios da coisa.

À medida que a comunidade de desenvolvimento web começar a mudar o design de componentes de viewport ou orientado a dispositivo (device-oriented) para orientado a contêiner (container-oriented), certamente todos veremos o emergir de possibilidades e melhores práticas até então inimagináveis!


URLs amigáveis (slug) à WordPress

Apenda a gerar URLs amigáveis como é feito no WordPress e implemente em seu sistema PHP

desenvolvimento web em WordPress é excelente! O CMS já vem com diversas funções e funcionalidades para facilitar a vida de desenvolvedores e, até mesmo, de pessoas que não tem o mínimo conhecimento em programação (um dos objetivos é esse, mesmo).

Mas muitos desenvolvedores, principalmente os ainda incipientes, esquecem que o WordPress nada mais é do que PHP! Claro, o WP é nada mais, nada menos, que um sistema feito em PHP, como você e eu poderíamos ter feito. Mas, por motivos que me fogem ao conhecimento, as pessoas esquecem isso… Talvez o nível de abstração em programação que o CMS proporcione seja o “culpado”, mas, sinceramente, não tenho certeza.

Então, se você tiver a curiosidade de vasculhar os arquivos PHP que fazem do WordPress o que ele é, vai ter uma grata surpresa e encontrar uma rica fonte de scripts, funções e funcionalidades que você sempre quis implementar e não sabia como!

URLs amigáves à WordPress

Por exemplo, muitos querem implementar uma estrutura de URLs amigáves (gerar os famosos “slugs”) em sistemas desenvolvidos do zero  – seja através de frameworks ou em PHPU (“PHP Unha”) -, mas não sabem como. Ora, se sabemos que o WordPress possui um ótimo sistema de geração de slugs e temos acesso a seu código-fonte, tudo o que é preciso é vasculhar o código-fonte e encontrar as funções certas.

Seguindo o exemplo de gerar slugs, procurando um pouco, é possível saber que as funções necessárias se encontram em /wp-includes/formatting.php. E, como era de se esperar, as funções estão devidamente documentadas com seu escopo, parâmetros e retorno. Precisa de mais?

Para gerar URLs amigáveis à WordPress, são necessárias 4 funções. 3 “preliminares” que são:

E, com essas funções devidamente estabelecidas, a função que gera os slugs, propriamente dita:

Então, para gerar um slug em seu próprio sistema depois de implementar as funções mostradas, basta escrever:

Achou o nome da função grande ou feio? Você tem o código, altere como bem entender!

Considerações finais

O WordPress é software livre (registrado sob a licença GPL), então você pode pegar essas 4 funções e implementar em seu site/sistema/softwares sem o medo de receber uma cartinha do advogado da equipe WordPress amanhã ou depois.

Fica uma pergunta: você tem um software livre à disposição e fica quebrando a cabeça em busca de soluções de código que já existem e estão implementadas nele? Vasculhe todo o código fonte (veja alguns recursos que ajudam no artigo sobre ferramentas e recursos para desenvolvimento web) e procure por aquilo que vai lhe ser útil!

Não seja tímido! 😉


HTTP 503: a maneira correta para SEO

Considerações a respeito do status code HTTP 503: o que significa, suas implicações de uso e como usar o HTTP 503 em períodos de manutenção de um site.

Você dá a devida importância aos códigos de status que são enviados nos cabeçalhos HTTPdas páginas de seu site? Saiba que enviar um cabeçalho de resposta HTTP com um código errado pode ser fatal… Principalmente quando alguma manutenção está sendo feita no site ou sistema. Neste artigo, breves considerações a este respeito e quais medidas tomar em relação ao status code 503 quando seu site entrar em manutenção.

Códigos de status HTTP e mecanismos de busca

Um mecanismo de busca constantemente verifica se o conteúdo que ele está indexando ainda existe e/ou não mudou. Geralmente, mecanismos de busca verificam 2 coisas:

  • Se o conteúdo está sendo “encabeçado” com o código HTTP 200;
  • Se o conteúdo ainda é o mesmo.

Um código 200 de HTTP significa: “Tudo está bem, aqui está o conteúdo que você pediu”. É o único status que indica que tudo está bem com o conteúdo. Se o conteúdo foi movido, você pode redirecioná-lo – permanentemente, com um HTTP 301 ou; temporariamente, com um HTTP 302 ou 307.

Se o servidor retorna qualquer outro código de status HTTP, significa que o mecanismo de busca já não pode encontrar o conteúdo. Se um servidor retorna um HTTP 200, mas a página é, de fato, um erro e diz algo como “Arquivo não encontrado” ou tem muito pouco conteúdo, o Google vai classificá-la como um “soft 404” no Google Webmaster Tools.

Como mecanismos de busca lidam com o tempo de inatividade do servidor (downtime)

Se, durante um rastreamento, um motor de busca encontra algum conteúdo que não existe mais, por exemplo, ele retorna um status code HTTP 404 que, geralmente, remove o conteúdo dos resultados de pesquisa até que o crawler possa voltar e verificar se ele está lá novamente. Se isso acontece, geralmente vai demorar um pouco para que o conteúdo volte a aparecer nos índices de busca novamente.

O que você deve fazer é garantir que um código de status HTTP 503 será retornado! Esta é a definição do código de status 503 da RFC (que define esses códigos de estado):

O servidor atualmente é incapaz de lidar com o pedido devido a uma sobrecarga temporária ou manutenção do servidor. A implicação é que esta é uma condição temporária que será aliviado após algum atraso. Se conhecido, o tempo de atraso PODE ser indicado em um cabeçalho Retry-After. Se nenhum Retry-After é fornecido, o cliente DEVE lidar com a resposta como seria para uma resposta 500.

Então, você tem que enviar um código de status 503 em combinação com um cabeçalho Retry-After. Basicamente, você está dizendo: “Espere! Estamos fazendo alguma manutenção, por favor, volte em X minutos”. Isso soa muito melhor do que um erro que diz: “Not Found”. Um código de status 404 literalmente significa que o servidor não pode encontrar qualquer recurso para retornar à URL acessada.

Como enviar um cabeçalho HTTP 503?

A maneira como se envia um código HTTP 503 como resposta a uma requisição depende da linguagem server-side que você está trabalhando. Por exemplo, em PHP, envia-se esse HTTP 503 assim:

O tempo de atraso do exemplo, 3600, é dado em segundos, de modo que 3600 segundos corresponde a 60 minutos (ou 1 hora). Você também pode especificar o tempo exato em que o visitante deve voltar enviando uma data em GMT ao invés do número em segundos. Algo como:

Quando preferir usar GMT, faça isso com muita cuidado e consciência! Especificar uma data errada pode causar resultados inesperadamente desastrosos!

“Meu site nunca está em manutenção, eu uso WordPress!”

Bobagem. Toda vez que você atualiza o core do WordPress ou quando você está atualizando plugins, o WP fornece uma página de manutenção. Essa página, por padrão, envia um cabeçalho HTTP 503 adequado.

Você pode substituir essa página de erro padrão com um arquivo maintenance.php na sua pasta wp-content, mas, se fizer isso, você tem que ter certeza de que o arquivo envia os cabeçalhos HTTP 503 apropriados! Na dúvida, você pode dar uma olhada no código da função wp_maintenance().

Se seu banco de dados caiu, o WordPress envia um erro interno do servidor usando a função dead_db(). Se você está fazendo uma manutenção planejada no banco de dados, é preciso criar uma página personalizada com uma mensagem de erro – usando o arquivo db-error.phpem ​​sua pasta wp-content, que envia o cabeçalho HTTP 503 adequado.

Cuidado com o cache!

Se você está trabalhando com algum tipo de sistema de cache, muito cuidado ao realizar essas mudanças! Tenha absoluta certeza de que o código HTTP 503 está sendo enviado corretamente durante o tempo em que a manutenção está sendo realizada.

Se não tomar cuidado, o código HTTP 500 (“Internal Server Error”, um erro genérico) pode ser enviado e, definitivamente, isso é algo que você não vai querer que aconteça.

HTTP 503 através do robots.txt

Segundo este post de Pierre Longe no Google+, se você enviar um código de status HTTP 503 para o arquivo robots.txt, o Google vai parar todo o rastreamento no domínio até que seja autorizado a rastrear o robots.txt novamente. Essa é uma forma muito útil de prevenir uma eventual sobrecarga no servidor ao fazer manutenções.

Usar essa técnica ainda exige que você envie um HTTP 503 para cada URL do site, incluindo as que apontam para recursos estáticos, mas, depois que o Google tiver acesso ao robots.txt novamente, provavelmente vai parar de martelar seu servidor por um tempo.

Conclusão: saiba que cabeçalhos HTTP você está enviando

Em suma, você deve ter ciência do que está acontecendo em seu site/sistema e saber, exatamente, quais códigos de status HTTP são enviados em quais situações e por quanto tempo.

tweet de Vanessa Fox reforça bem essa ideia:

It’s about more than number of pages crawled – you need to know about important pages & what response code they return @vanessafox

Quer dizer: É muito mais do que sobre o número de páginas indexadas – você precisa saber a respeito das páginas importantes e qual código de resposta elas retornam.

É a mais pura verdade!


Missões de manutenção do site
Mantenha seu negócio on-line funcionando sem problemas com um controle mensal dessas áreas cruciais
Recentemente, eu estava na concessionária de automóveis assistindo o trabalho de mecânica no meu carro, e de repente um pensamento me pareceu: quantos proprietários de empresas on-line verificam regularmente sob o capô para garantir que seus sites estejam funcionando sem problemas?

E mesmo que você faça exames freqüentes no seu site, você tem certeza de que está dando uma resposta completa? Cerca de uma vez por mês, você deve “pular o capuz” para realizar um check-up abrangente, encontrar o que não está funcionando e consertá-lo. Aqui está o que você deve procurar:

Estatísticas de tráfego O
seu host deve fornecer estatísticas básicas, mas considere obter o programa gratuito do Google Analytics ou usar os serviços de uma empresa de análise de internet baseada em taxas – você terá uma visão mais profunda de como seus visitantes viajam através do seu site. Você deve ser capaz de responder as seguintes perguntas:

  • Em quais páginas seus visitantes deixam seu site? Por exemplo, eles abandonam seu site na página da ordem sem fazer um pedido? Em caso afirmativo, talvez haja um problema com o processo de check-out.
  • Quanto tempo os visitantes gastam no seu site e em cada página individual? Se eles visitam sua página inicial e depois saem quase que imediatamente, obviamente você não está chamando sua atenção.
  • Como seus visitantes o acham? São sites particulares que enviam muito tráfego ao seu lado? Você pode aproveitar isso de alguma forma em parceria com eles? A maioria de seus visitantes vem de um motor de busca específico? Em caso afirmativo, qual poderia ser o motivo disso – e como você pode contrariar o tráfego de outros motores de busca? Quais palavras-chave e ofertas em seus anúncios de pagamento por clique estão melhorando? Você pode incorporá-los em outros lugares em seu site?
  • O que está causando picos de trânsito? De onde vêm os visitantes? Existe um novo link apontando para o seu site? Uma campanha de e-mail ou anúncio de PPC é particularmente bom? Poderia haver uma razão sazonal? Como você pode fazer isso uma ocorrência regular?
  • Onde vivem os seus visitantes? Se houver muito interesse de um determinado local, você pode ajustar seu site para atender especificamente a essas pessoas (por exemplo, oferecendo serviços em outro idioma)?
  • Quais termos de pesquisa e palavras-chave resultam na maior parte do tráfego para o seu site? Você pode colocar mais destes – ou outras palavras-chave semelhantes – em seu código e conteúdo para atrair ainda mais tráfego?

Estatísticas de vendas O
tráfego é bom, mas as vendas fazem você ganhar dinheiro. Acompanhe suas taxas de conversão – a porcentagem de seus visitantes que realmente se tornam clientes pagantes. Muitas rotas com poucas conversões indicam que existe algum tipo de desligamento entre a mensagem que leva as pessoas ao seu site e a mensagem que eles estão a ver quando chegarem lá. Olhe para onde você perde essas pessoas e você verá por onde começar a ajustar e testar. O menor tráfego com altas conversões significa que você está fazendo as coisas certas no seu site e você precisa se concentrar em obter mais tráfego.

Taxas de resposta por e-mail
Verifique sempre seus números de tráfego e vendas cuidadosamente após cada envio de e-mail. Você pode descobrir quais linhas de assunto e ofertas promocionais estão funcionando melhor para você, e mesmo quais horas do dia, semana e ano são melhores para seus e-mails.

O e-mail ainda é uma das técnicas de marketing mais eficazes, e você aproveitará o máximo se você automatizar todas essas tarefas de e-mail desde o início. Um sistema de gerenciamento de e-mail como iContact economizará tempo e fornecerá resultados detalhados em um formato amigável para que você possa facilmente analisar o que está funcionando e o que precisa funcionar.

Manutenção geral
Aqui estão algumas outras coisas relacionadas ao seu site que você deve observar de perto:

  • Verifique se há links quebrados e outras falhas técnicas em seu site. As Ferramentas do Google para webmasters podem ajudar com isso. Outro bom recurso para verificar links quebrados e outros fatores que afetam o desempenho do seu site – como a velocidade de carregamento do seu site – é o Sitereportcard.com .
  • Procure palavras-chave relevantes para sua indústria para ver se o seu site aparece nos resultados da pesquisa.
  • Verifique os sites dos seus concorrentes regularmente para ver se eles estão executando promoções especiais ou têm novos produtos. Se você realmente deseja ver seu funcionamento interno, você pode usar uma ferramenta paga como KeywordSpy ou iSpionage para ver quais palavras-chave estão usando e onde. E certifique-se de se inscrever para seus boletins informativos ou feeds RSS – é uma ótima maneira de manter a guia sobre o que eles estão fazendo.
  • Procure na web frases aleatórias das páginas do seu site para se certificar de que ninguém esteja usando seu conteúdo sem voltar para você.
  • Procure no nome da sua própria empresa e URL para ver se alguém está dizendo algo ruim sobre você.

Um mau funcionamento no seu site pode ser tão prejudicial para o seu negócio como uma falha de freio seria para o seu carro. Idealmente, você deve reservar um dia a cada mês para realizar uma revisão importante do site. Isso manterá seu negócio funcionando tão bem como um motor bem oleado.


Saiba mais sobre Wireframes antes de contratar um desenvolvedor da Web
Você deve explicar sua visão se você espera que seu desenvolvedor web compartilhe sua visão.
As opiniões expressas pelos contribuintes empresariais são próprias.

Como alguém que esteve em ambos os lados do contrato, como freelancer e como cliente, uma das coisas mais bem vindas que você pode fazer para um freelancer é ajudá-los com seu trabalho de forma significativa.

Você é o cliente do inferno?

Quando se trata de desenvolvimento web, isso significa duas coisas. Primeiro, leia os Clientes do Inferno e se esforça para nunca ser “esse cara”. Em segundo lugar, esteja pronto para apresentar seu desenvolvedor web com um wireframe.

Quando digo a palavra wireframe, o que você imagina? Se você está pensando em CGI e modelos poligonais dos anos 80, você está um pouco fora da marca. Um wireframe de design web é como esse esqueleto poligonal, mas para um site.

O que é um wireframe?

É um layout gráfico e design que não exige nenhuma codificação, manipulação de imagem, ou mesmo mais do que colocar um lápis em uma folha de papel quadrado. Basta verificar alguns desses exemplos .

Um wireframe é uma ferramenta incrivelmente útil para um desenvolvedor web. Isso mostra exatamente o que você tem em mente e dá-lhes uma idéia da escala de vários elementos, os elementos cruciais que você deseja incluir em suas páginas. O wireframe é uma espécie de truque de codificação que eles podem precisar para implementar para que tudo aconteça.

Desta forma, você não os surpreende com “oh, e por sinal, eu quero a navegação na barra lateral” ou “hey, na verdade, você pode fazer essa imagem estática uma apresentação de slides?”

Você economizará tempo, você economizará dinheiro e você salvará o sangue, o suor e as lágrimas de você e seu desenvolvedor web.

Mas espere! Eu estou assustado.

Se você tem medo da complexidade de um wireframe, não se preocupe com isso. Você não precisa fazer um design em escala completa de todas as páginas em seu site. Tudo o que você realmente precisa são os princípios básicos. Você quer saber onde você terá sua navegação e qual o tipo de layout que deseja para as páginas do produto.

Você quer um par de detalhes sobre quantos slots extras você precisa para miniaturas de artigos ou outros produtos relacionados. Alguns dos wireframes da galeria acima são muito simples, não mais do que um punhado de caixas aninhadas em outras caixas, mas ainda é suficiente para um desenvolvedor web começar.

Além disso, lembre-se, faz parte do trabalho do desenvolvedor para ajudá-lo a refinar o design. Eles podem dizer-lhe “hey, este design é um pouco confuso, e se cortarmos isso e mudarmos para lá?”

O design moderno é uma chave.

Eles podem dizer-lhe que os padrões de design modernos sugerem que você não deveria ter sua navegação no lado direito na calha. Eles podem usar seu wireframe como base. Apenas corta as primeiras cinco ou seis fases de prototipagem de ida e volta, o desenvolvedor normalmente teria que passar para chegar a este estágio com você.

Os wireframes também são muito fáceis de criar, desde que você tenha e mantenha uma visão do que você deseja que seu site pareça. Eu já disse que você pode colocar um lápis em uma folha de papel e fazer um, mas você também pode usar uma das dezenas de aplicativos lá fora.

O padrão da indústria que encontrei é o Balsamiq, que é livre para tentar e barato para comprar. Ou você pode usar outras ferramentas como Wireframe.cc, Moqups ou UXPin para soluções baseadas na web.

Se preferir trabalhar a partir de um tablet ou dispositivo móvel, o OmniGraffle funciona no iOS, o Wire Flow funciona no Android e o Fluid UI funciona em ambos.

Tudo o que você faz é um processo.

Na verdade, não é tão difícil quanto parece – ou soa. Lembre-se, produzir qualquer coisa é um processo iterativo. Passando de uma idéia para um esboço, de um esboço para um wireframe, de um wireframe para um projeto mais detalhado, e de lá para um protótipo é típico.

Qualquer quantidade de ajuda que você possa trazer para o seu desenvolvedor percorrerá um longo caminho – e confie em mim – é muito apreciada.


3 Riscos de segurança ocultos para usuários do WordPress

O WordPress é indiscutivelmente o sistema de gerenciamento de conteúdo mais popular da web e a plataforma de blogs, e por uma boa razão. O sistema é gratuito, fácil de usar e fornece uma grande variedade de recursos que de outra forma custariam aos empresários milhares de dólares em despesas de desenvolvimento.

Mas se algo parece bom demais para ser verdade, geralmente é. Embora a plataforma WordPress ainda represente uma opção de desenvolvimento web útil para pequenas empresas, é fundamental que você se familiarize com algumas das fraquezas do sistema para evitar seus perigos de segurança ocultos .

O WordPress atualiza sua plataforma com freqüência para responder a ameaças conhecidas, mas não é capaz de policiar todas as possíveis. Aqui está uma olhada nas três maiores fraquezas de segurança da plataforma que você deve estar ciente:

1. O WordPress é susceptível de ataques e hacking de URL. 
A plataforma WordPress executa scripts do lado do servidor na linguagem de desenvolvimento web PHP, usando comandos enviados através dos chamados parâmetros de URL para controlar o comportamento dos bancos de dados MySQL que armazenam os dados do seu site.

Se isso tudo so bastante técnico, não se preocupe. Você não precisa entender a codificação da web para proteger seu site. O que você precisa saber é que esse tipo de estrutura do site é vulnerável a um determinado tipo de ataque. Os hackers podem usar parâmetros de URL maliciosos para revelar conteúdo de banco de dados sensível, um processo conhecido como “ataques de injeção SQL”. Uma vez que os hackers tenham essa informação, eles podem seqüestrar seu site e substituir seu conteúdo por spam ou malware.

Para proteger o seu site WordPress de tal ataque, considere modificar o arquivo .htaccess do seu site, que é um arquivo de configuração que permite que você controle a maneira como seu servidor de hospedagem se comporta. Você pode evitar que os pedidos de parâmetros de URL dos hackers sejam bem sucedidos, incluindo o código encontrado aqui.

Tenha em atenção que este código destina-se aos proprietários do WordPress que utilizam o hospedagem web baseada no Apache. Se você não tem certeza do tipo de hospedagem que você usa ou se precisar de assistência na modificação do arquivo .htaccess do seu site, entre em contato com a equipe de suporte de seu provedor de hospedagem web ou com um desenvolvedor web privado.

2. Os temas gratuitos do WordPress freqüentemente possuem explorações de segurança. 
Um dos maiores benefícios do WordPress é que você pode instalá-lo de graça, usar plugins gratuitos para adicionar funções e baixar arquivos de tema gratuitos para dar ao seu site uma aparência atraente. Infelizmente, os desenvolvedores sem escrúpulos possuem arquivos de temas para download com tudo, desde links de spam indetectáveis ​​até arquivos de malware que infectam um site uma vez que o tema está instalado.

Para manter seu site seguro, baixe arquivos apenas de fontes que você conhece e confie. Os temas pagos representam menos risco de segurança do que temas gratuitos. Mas se quiser temas gratuitos, você pode digitalizá-los para detectar malwares antes de enviá-los para detectar ataques que possam ter ocorrido usando o programa anti-vírus instalado no seu computador.

3. O processo de login padrão do WordPress pode ser facilmente pirateado. 
Todos os logins do painel do WordPress estão localizados no mesmo endereço em URLs, o que significa que quase todas as páginas de login do WordPress podem ser encontradas aqui . Além disso, as configurações padrão do WordPress não permitem logins seguros. Isso significa que um site executado na plataforma WordPress pode ser suscetível a ataques de “força bruta”, nos quais os programas de bot tentam várias combinações de logs com a esperança de que uma combinação de sorte permita o acesso ao site.

Para ter uma ideia de quão prevalecente são esses ataques, considere que os sites hospedados pelo popular blogging site Copyblogger experimentam entre 50.000 e 180.000 tentativas de login não autorizadas a cada dia .

Para proteger o seu site, instale o plugin Limit Login Tentpts . Além disso, você pode trabalhar com seu provedor de hospedagem na web para bloquear os endereços IP que fazem múltiplas tentativas de login sem êxito.

Embora possa parecer muito trabalho para tomar essas precauções, você pode gastar muito mais tempo e esforço tentando consertar seu site se você acabar com a vítima de uma tentativa de hacking bem sucedida.


5 dicas para projetar seu site para atender cada cliente individualmente

Pesquisas atuais mostram que 40% dos consumidores compram mais de varejistas que personalizam sua experiência de compra em todos os canais. Além disso, quase três em cada quatro, ou 74 por cento, de consumidores online ficam frustrados com sites quando o conteúdo exibido não tem nada a ver com seus interesses. É claro que um site personalizado é uma vantagem para todos os comerciantes ou empresários que lideram um negócio de sucesso hoje.

A personalização do site leva em consideração que os usuários têm diferentes motivações, dispositivos, locais e restrições de tempo. Com a tecnologia atual, os comerciantes podem agora reunir informações específicas sobre o que um visitante do site está procurando e traduzir sua visita em uma conversão mais alta

“As organizações gastam dezenas ou centenas de milhares de dólares, e às vezes até milhões de dólares, para criar experiências dinâmicas dinâmicas na web”, explicou Itai Sadan, CEO e co-fundador da plataforma de criação de sites móveis DudaMobile . A empresa recentemente lançou no site que adiciona conteúdo web dinâmico com base no comportamento do cliente para criar experiências de visualização personalizadas.

“Ferramentas caras e esse tipo de personalização tradicionalmente requer um desenvolvimento e projeto substancial na web, e é por isso que estamos entusiasmados por ter preços acessíveis para essa indústria explosiva”, disse Sadan.

A personalização do site em uma escala de massa é realmente possível com o crescente número de opções de baixo custo disponíveis para os empresários hoje. Aqui estão cinco maneiras pelas quais os empresários podem começar a aumentar a conversão através da personalização básica do site:

1. A frequência do visitante deve determinar diferentes experiências do usuário.  Um visitante de um site pela primeira vez quase sempre estará procurando informações diferentes do que alguém que visita o site repetidamente.

David Reischer, diretor de marketing da LegalAdvice.com , sugere acompanhar cada usuário de forma diferente para dar experiências de usuário diferentes. “Utilizamos um cookie para rastrear um visitante que retorna para que possamos direcioná-los para a página mais adequada e relevante. Isso torna a navegação no site mais fácil para usuários repetidos “.

Para aumentar a conversão de visitantes pela primeira vez, inclua um número de telefone ou endereço comercial, um formulário de contato para capturar leads ou um tutorial de vídeo para explicar um produto ou serviço para um visitante pela primeira vez.

“Para visitantes frequentes, adicione um ponto para se inscrever para uma lista de endereços ou adicionar informações sobre novos produtos ou serviços”, sugere Sadan.

2. A localização geográfica ajuda a reunir o marketing online e offline.  A capacidade de saber onde alguém está no momento em que visitam um site é a mudança de jogo para os comerciantes.

“Online, podemos acompanhar a jornada de compra individual do nosso cliente, otimizando-a a cada passo”, explica Bart Heilbron, CEO e co-fundador da BlueConic , o sistema em tempo real de engajamento de clientes online. “No entanto, nunca fomos capazes de usar esses insights em nossa interação off-line. Com a localização geográfica, agora podemos fazer. ”

Se alguém está a poucos quarteirões de distância de uma empresa e procurando em um telefone celular, é provável que eles possam ser facilmente convertidos como clientes se eles veem um endereço e até um cupom que diz: “Entre hoje e descanse 20%”. restaurantes, um botão OpenTable para reservar uma tabela ou um aplicativo Google Map que fornece instruções passo a passo para o local da loja são críticos para a conversão.

3. Ajuste o conteúdo com base em determinados horários.  Alterar o conteúdo em um site com base na hora do dia, semana ou mesmo temporada também pode aumentar as conversões. Considere substituir um número de telefone disponível para os visitantes do site durante o horário comercial com um formulário de contato quando o negócio está fechado. Isso evitará perder os clientes potenciais que desejem entrar em contato fora do horário comercial.

“A capacidade de oferecer produtos diferentes ao longo de um dia com base em tendências, hábitos ou cultura direcionados aumentará as conversões”, disse o CEO da empresa de marketing na internet , WebiMax , Ken Wisnefski. “Por exemplo, um restaurante oferece um menu diferente ao longo do dia, quando eles mudam de almoço para jantar”.

4. Reconheça feriados e outros eventos especiais.  Esta é uma ótima maneira de personalizar um site e se conectar melhor com o sentimento de um cliente. Mude o tema para os corações durante o Dia dos Namorados ou adicione uma imagem de fogos de artifício durante o 4 de julho.

“Isso poderia ter um efeito positivo no engajamento do cliente e, por sua vez, conversão”, disse Sadan.

5. Capture a fonte do visitante para adaptar o conteúdo.  Conhecer a fonte de destino original que um visitante entrou em um site deve impactar significativamente o conteúdo na página de destino que eles vêem primeiro. Isso pode proporcionar uma experiência perfeita e consistente para o visitante.

De acordo com Sadan, “Os visitantes que chegam ao seu site a partir de uma campanha de marketing por e-mail ou como uma referência de outro site devem receber mensagens dedicadas que estão alinhadas com a mensagem que eles viram no e-mail ou no site de referência. Oferecer um cupom neste ponto também pode ser uma boa idéia “.


Página 1 de 212