Inspiração

O serviço Github Pages é muito simples e interessante. Fantástico eu diria! Ao mesmo tempo que é simples, permite usar ferramentas mais complexas como o gerador de sites Jekyll que, no caso do Github Pages, a cada commit no repositório do seu projeto, gera as páginas estáticas automaticamente. Isso resolve o problema da geração sem a necessidade de instalações locais.

Infelizmente o serviço do Github limita-se a fornecer o Jekyll, como rodar outros geradores ou mesmo versões customizadas do Jekyll? Travis-ci!!!

Integração contínua

O Travis é um serviço de integração contínua. No mundo do desenvolvimento de software isso é como um servidor de compilação que, a cada integração de código feita pelos desenvolvedores (commit), executa uma compilação e, possivelmente, testes automáticos. Para entender melhor leia os artigos “Integração contínua: uma introdução ao assunto” e “O que significa integração contínua?”.¹

Na verdade, o Travis é uma máquina virtual que roda uma configuração de comandos para compilar e testar o código. Quase qualquer comando do Linux (SO nativo do Travis) pode ser executado sobre o código. Rodar o Hexo ou qualquer outro gerador é possível.

Versionamento

Para que o Travis enxergue o projeto, este precisa estar versionado em um repositório no Github. Usando o repositório deste blog como exemplo, as informações ficam no branch development. Para mais detalhes leia o post.

Configurando o Travis

Ao criar uma conta no Travis-ci utilizando as credenciais do Github e autorizá-lo, ele instalará hooks² nos repositórios de cada projeto ativado.

Pode-se configurar o Travis através de um arquivo de versionado no repositório do próprio projeto. O arquivo deve ser nomeado .travis.yml e, como a extensão sugere, ele é escrito no formato YAML.

1
2
3

language: node_js
node_js:
  - "4.4.3"

As primeiras linhas definem a linguagem e a versão do compilador/interpretador utilizado. Depois, há a lista de branches que serão compilados (#whitelist) e a lista de branches cujos os commits serão ignorados:

1
2
3
4
5
6
7
8
9

# whitelist
branches:
  only:
      - development
      - test-site-development
# blacklist
  except:
      - master
      - conteudo

Na sessão before_install são instalados o Hexo e suas dependências, exatamente como se estivesse preparando uma máquina linux nova para rodar o Hexo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

git:
  depth: 1
before_install:
- npm install -g hexo-cli
- npm install -g grunt-cli
- npm install -g bower
- npm install
- cd themes/tranquilpeak/
- npm install
- bower install
- grunt buildProd
- cd ../../
install:
- hexo generate

Caso o comando hexo generate termine em sucesso, o Hexo rodará a sessão before_script. No caso deste blog, o git faz o clone do branch conteudo, esse passo serve apenas para manter um histórico do site gerado e é completamente opcional. Um detalhe importante desta configuração está na sessão script:

1
2
3
4
5
6
7
8
9
10

before_script:
- git config --global user.name 'Josenivaldo Benito Jr'
- git config --global user.email 'jrbenito@benito.qsl.br'
- sed -i'' "s~git@github.com:jrbenito/benito.com.br.git~https://${GH_TOKEN}:x-oauth-basic@github.com/jrbenito/benito.com.br.git~" _config.yml
- git clone https://github.com/jrbenito/benito.com.br.git .deploy_git -b conteudo
script:
- grunt s3-prod-deploy
- hexo deploy --silent
after_success:
- grunt sns

Na linha 4 do trecho acima, o comando sed substituirá a URL do repositório no arquivo de configuração do Hexo. Mais precisamente, esse comando está trocando o protocolo de acesso SSH por HTTPS e acrescentando um token de autorização para poder escrever no repositório no github. Mas de onde vem a variável GH_TOKEN?³ O Travis dispões de dois mecanismos para configuração de variáveis de ambiente. Uma através do site, na configuração do repositório e a segunda através da criptografia da variável e seu conteúdo no arquivo .travis.yml.⁵

Neste exemplo foi utilizado o método da criptografia.⁴

1
2
3
4
5

env:
  global:
  - secure: O5f2zGaXraEVUOIk[...]
  - secure: bsmjzMqApTjofgAc[...] 
  - secure: A84t9ASnL11WFrqL[...]

Habilitando o repositório no Travis.

Falta pouco! Com a configuração versionada no repositório é necessário avisar ao Travis que ele deve vigiar tal projeto. No site do Travis procure pelo sinal + no canto superior esquerdo da tela, esse é o botão “Add New Repository”.

Configurações de repositório no Travis

Nas configurações do repositório (more options -> settings), habilite Build only if .travis.yml is present e Build pushes e mantenha desabilitado Build pull requests já que não desejamos que contribuições de qualquer pessoa gerem o site. Nesta mesma página é possível especificar variáveis de ambiente se necessário.

Conclusão

Pronto! Todo commit no repositório do blog irá disparar o Travis e gerar o site. Utilizando o Grunt o conteúdo produzido é atualizado no servidor.

Imagine que a situação onde o usuário faz login no servidor através de SSH, inicia uma sessão tmux, destaca a sessão e faz logout. Algum tempo depois, volta a fazer login, seja via SSH ou até mesmo localmente. Neste ponto a variável $DISPLAY está corretamente configurada, mas dentro da sessão tmux ela pode conter informações da antiga sessão. É necessário popular manualmente a variável com o valor atual. Mas como descobrir?

Procurando o servidor X

Geralmente um usuário logado ao sistema possui um servidor X ativo e este exporta um “display” que pode ser conectado através de uma porta TCP. É assim que aplicações rodando em um servidor remoto conseguem abrir interfaces gráficas (GUI) em nossa máquina local.

No cenário exemplificado, uma forma de descobrir o valor para a variável $DISPLAY seria, antes de abrir o tmux, imprimir o valor corrente e, dentro do tmux atribuir o valor novo:

1
2
3
4
5
6

$ echo $DISPLAY
localhost:10.0

$ tmux attach
[...]
$ export DISPLAY='localhost:10.0'

Repare que o formato do endereço é <ip_ou_dominio>:<porta>.<display>. O servidor X escuta em uma porta TCP geralmente acima dos 6000. No caso, do exemplo acima, a porta TCP seria 6010, sendo o número 10 correspondente ao <porta> da variável $DISPLAY. Com essa informação podemos, dentro da sessão tmux (ou qualquer outra sessão de terminal), listar os servidores X abertos para o usuário atual:

1
2
3

$ netstat -ane | grep "LISTEN " | grep "`id -u`" 
tcp6       0      0 ::1:6010                :::*                    LISTEN      1000       160206
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN      1000       160207

Usamos o netstat para listar as portas TCP, filtramos com grep pelas portas que estão em estado LISTEN e que pertencem ao usuário corrente (id -u). Como geralmente acessamos os terminais localmente ou via SSH¹, estamos interessados apenas no localhost ou IP 127.0.0.1. Mais um filtro com grep para pegar apenas os IPs localhost e pronto. Tudo isso colocado em uma função bash que pode ser convenientemente chamada para acertar a variável $DISPLAY sempre que necessário.

O código da função é simples mas note que usei um sort para ordenar a saída pelo PID e um tail para selecionar a última entrada. Esse passo serve apenas para ordenar as sessões concorrentes que possam existir na mesma máquina, pegando sempre o PID mais alto. Isso garante² a seleção do mais recente.

Conclusão

Uma função simples que resolve um problema constante no meu ambiente de trabalho onde acesso um servidor compartilhado através de SSH. A cada sessão reiniciada as chances do meu número de display mudar é muito grande. Espero que seja útil para mais alguém.

O problema

Possuo uma TV Plasma da Panasonic, o modelo é TC-P50UT20B que, ao que parece, é uma tropicalização da TX-50VT20B. Eu gosto de TVs de Plasma graças à profundidade do preto que estas telas oferecem, mas confesso que gostava mais da minha antiga TX-P50V20B (a versão não 3D e não - muito -tropicalizada). Bom mas isso é história para outro artigo.

Da noite para o dia essa TV parou de ligar pelo controle remoto. Claro que troquei as pilhas do controle remoto sem sucesso. Também testei com um controle universal sem o menor sucesso. Para finalizar o diagnóstico eu apontei o controle remoto para a câmera do celular e é possível ver o LED IR (infravermelho) piscar. Se não é o controle remoto só pode ser a TV…

Aprendendo com a experiência (ruim) de outros

Seguindo o caminho padrão recorri ao oráculo e encontrei alguns relatos de pessoas com problemas similares em modelos de outras marcas. Os relatos eram sempre de que a TV parava de responder a qualquer controle remoto mas que funcionava perfeitamente ao ser comandada pelos botões no painel ou via algum aplicativo de celular (se a mesma for uma SmartTV e possuir esse tipo de aplicativo). Esse é exatamente o sintoma que a minha Pana vinha apresentando.

Minha experiência (ruim) com assistências técnicas

Com todas as informações em mãos eu abri um chamado na Panasonic perguntando se haveria algum procedimento para fazer o reset da TV uma vez que o procedimento descrito no manual faz uso do controle remoto - justamente o que não está funcionando. Relatei em meu chamado que já havia testado o controle remoto, trocado pilhas e usado um outro controle remoto e que esse não era o real motivo. No dia seguinte eu recebi uma reposta da Panasonic aconselhando-me a verificar as pilhas do controle remoto e testá-lo com a câmera do celular… Mas não foi exatamente isso que escrevi no meu chamado? Ao que parece existe uma doença epidêmica que acomete canais de suporte técnico; tal doença apresenta sintomas como ignorar o que é escrito pelo consumidor e responde-lo com respostas genéricas de algum manual. Em casos mais graves pode forçar o suporte a não responder. Contente-se se seu suporte responder mesmo que seja repetindo exatamente o que você descreveu.

Liguei em três assistências técnicas autorizadas, a primeira disse que o modelo era velho e que não teria peça condenando minha TV ao descarte. A segunda assistência ouviu todo meu relato e negou-me falar diretamente com o técnico, disse que o procedimento era eu levar a TV até eles e em até 7 dias eles me passavam um diagnóstico e orçamento. Insisti dizendo que a assistência ficava a 35 km da minha cidade e que eu gostaria de falar com um técnico para saber se havia possibilidade de eu levar apenas a peça defeituosa ou ele simplesmente encomendar a placa de IR e eu levar a TV só para trocar. Nada! A moça que me atendeu parecia estar falando com um E.T. que apareceu falando coisas que ela não entendia e queria a todo custo burlar o processo que ela seguia de forma tão correta. A terceira assistência foi quase como a segunda, mas a moça não pensou que eu fosse um “quebra protocolo” e, percebendo que eu entendia um pouco daquilo que falava, disse: “Olha, essas TVs não têm mais peça de reposição no mercado. O que fazemos é mandar a placa para um laboratório e eles verificam se há como trocar os componentes”. A palavra laboratório foi o que me chamou a atenção para o fato de que eu mesmo poderia verificar o que estava errado na placa de IR. Afinal de contas ali não tem nenhum CI elaborado, mas sim componentes simples como resistores, capacitores e sensor de IR (óbvio ddddduuuuhhhhh!).

Desmontando a Pana

Desmontar a TV não foi complicado, por sorte eu tive auxílio de uma parafusadeira pois tirar os 20 parafusos que prendem a tampa traseira ao corpo da TV seria um trabalho ingrato de se fazer na unha. Durante a retirada da tampa me deparei com um módulo estranho, olhado as inscrições no mesmo descobri tratar-se de um módulo Bluetooth. Porque diabos essa TV tem um módulo Bluetooh que não aparece em menu nenhum, muito menos em seu manual, permanece um mistério ainda por ser desvendado.

Retirados a tampa traseira e o misterioso módulo Bluetooth, a placa IR está a um parafuso de sair. A mesma placa é compartilhada por outras duas funções: o LED de ligado/espera e o sensor de iluminação usado pela TV para calcular o brilho aplicado ao painel quando o ECO Mode está ativado. A placa possui a identificação TNPA5602, que usei para pesquisar na Internet e descobrir que a placa toda custa US$ 10,00 no eBay mas que ninguém no Brasil tem a essa placa para vender. De fato a participação de mercado da Panasonic no Brasil não é algo que salte aos olhos e quando falamos em TVs de plasma a base instalada é ainda menor. Se não tem usuário não tem mercado para peças certo?

Desvendando o circuito

Sabendo que existe placa semelhante para venda, eu fiquei mais tranquilo de tentar arrumá-la e, em caso de desastre, posso encomendar outra. Mas para mexer na placa eu preciso entender o circuito. Meu amigo Alexandre do Tabajara Labs pegou uma foto da placa e desvendou parte do circuito para mim. Mas torturando um pouco mais o Google, o Pedro - outro amigo, conseguiu encontrar o manual de serviço de uma TV que compartilha a mesma placa. O circuito está abaixo com a parte do infravermelho em destaque.

Esquemático: destaque para o circuito do receptor infravermelho

Procurando o culpado

Utilizando um multímetro e com a placa IR conectada na TV eu comecei a medir as tensões. Primeiro a entrada Vcc, provavelmente normal pois o LED da TV brilha normalmente. Como esperado, o Vcc apresentava tensão de 3.3V mas, no pino Vcc do sensor de IR (círculo azul nas imagens) havia aproximadamente 0,72V. Isso indica que algo, o sensor ou algum componente vizinho, está derrubando a tensão Vcc. Pensei que o sensor poderia estar em curto ou algo parecido, mas esses sensores são bastante robustos e pelo circuito ele não está condenado a nenhum trabalho forçado. Foi aí que reparei nos capacitores de desacoplamento que ficam próximos ao sensor (destaques amarelo e vermelho no verso da placa). Meu grande amigo Alex sugeriu que um deles ou ambos poderiam estar em curto circuito devido a fadiga.

Frente PCB - destaques para Vcc sensor e R2542. O Sr. Foco não pode comparecer

Verso PCB - destaques para R2517, C2512 e C2521

Para testar essa possibilidade eu desliguei a TV e retirei a placa depois descarreguei os capacitores para evitar danos ao multímetro. Colocando o multímetro na função ohmímetro e medindo os terminais dos capacitores esse deve apresentar resistência zero Ohm e ir aumentando, preferencialmente até indicar resistência infinita (acima da escala de medição). Porém eu obtive a leitura de aproximadamente 7,5O Ohms, isso significa que um ou ambos capacitores está com problemas, esse valor de resistência é muito baixo. Aliado ao resistor (R2517) de 47 Ohms (destaque marrom) entre Vcc da alimentação e o pino Vcc do sensor, forma-se um divisor resistivo entregando uma tensão mais baixa para o sensor. Calculando a tensão resultante desse divisor para Ventrada=3,3V, R1=47 e R2=7,5 temos Vsaída=0,45V, mais baixa um pouco que aquela que eu efetivamente verifiquei com o circuito ligado, talvez porque a resistência dos capacitores aumente um pouco quando eles estão energizados ou por erro de medida do meu multímetro. Curiosidade: o valor de R2 para que a saída seja de 0,72V teria que ser de aproximadamente 13 Ohms.

Reparando a placa

Se os culpados são os capacitores, qual deles? Ambos? Um palpite baseado na experiência diz que o capacitor de menor tensão (6,3V) tem mais chances de sofrer danos nesse circuito. Utilizando um ferro de solda eu retirei o capacitor C2512 (circulado em amarelo) e repeti a medida de resistência nele fora do circuito. Obtive aproximados 6 Ohms, de fato este capacitor estava danificado. Medi também o capacitor que ficou no circuito e obtive vários kilo-Ohms na leitura. Voltando a teoria do divisor de resistivo, com R1=47 e R2 agora valendo quase 1 Mega-Ohm, teríamos praticamente os 3,3V no pino Vcc do sensor. Testei a placa sem o capacitor de volta na TV. O circuito apresentou 3.3V no pino Vcc do sensor, apontei o controle remoto e este funcionou perfeitamente; a TV estava de volta à ativa.

Montei a TV sem o capacitor, como sua função é apenas de desacoplamento, sua falta não irá interferir (muito) no funcionamento do sensor IR. Não queria ficar sem TV por mais tempo e já estava de saco cheio de ter meu sofá tomado pela grande tela de 50” que inviabilizava qualquer um de sentar ali. E nem vamos falar no que poderia acontecer se alguém acidentalmente derrubasse o potinho de parafusos que estava ao lado, no braço do sofá. Quando eu precisar comprar uns componentes eu aproveito e coloco esse capacitor na lista.

Conclusão

Apesar do controle remoto não ser imprescindível ao funcionamento da TV, muitas configurações ficam impossíveis. O problema mostrou-se muito mais simples do que o prognóstico dado pelas assistências técnicas. Como em quase todos os problemas da vida, a fase de preparação e pesquisa tomou mais tempo que a execução; eu gastei algumas horas vasculhando a Internet por manuais e informações dessa TV, mais algumas horas discutindo o circuito com amigos e pouco mais de 2 minutos para retirar a peça problemática e testar o circuito. E como toda experiência na vida, valeu a pena cada informação absorvida no processo. Para mim o mais importante nesse tipo de situação é escapar da armadilha da obsolescência programada que nos impele a comprar produtos novos e jogar fora produtos que poderiam ter vida útil estendida.

O principal objetivo da CDN é diminuir a latência aumentando a velocidade do site, porém as CDN adicionam ainda, disponibilidade e redundância que os provedores mais básicos (e baratos) não conseguem entregar.

AWS Cloudfront

Cloudfront é a CDN do Amazon Web Services e, como é costume do AWS, possui um preços atrativos e free tier generoso. Já que esse site é hospedado no AWS S3, utilizar o Cloudfront é natural.

O Github Pages já possui uma CDN servindo seus sites. Embora não haja muito controle sobre como seu conteúdo é armazenado (cache) e distribuído, o serviço é totalmente grátis para projetos não comerciais.

Criando uma distribuição

Para criar um nova distribuição acesse o console AWS e clique no serviço Cloudfront. Na tela que se abre clique no botão azul Create Distribution. Na tela seguinte será perguntado se você deseja criar uma CDN Web ou uma CDN RTMP, selecionamos o botão Get Start na sessão Web. A tela seguinte solicita as configurações da CDN, vou explicá-la por sessão.

Origin Settings

Configurações da Origem

A Cloudfront não precisa ser usada em conjunto com AWS S3, mas sim com qualquer servidor web. Nessa sessão colocaremos as informações da origem, ou seja o seu servidor de conteúdo que geralmente é um servidor web ou no meu caso o bucket S3.

No primeiro campo, Origin Domain Name, coloque o endereço do seu conteúdo, não o seu domínio pessoal mas sim o endereço servidor onde seu conteúdo está armazenado. Pode ser um nome ou um endereço IP disponibilizado pelo seu provedor. No caso de utilizar o AWS S3, o correto é colocar o endereço (endpoint) do bucket.

O primeiro campo é traiçoeiro, ao clicar nele o console irá oferecer-lhe uma lista de seus buckets S3. Não utilize essa facilidade!
Use o endpoint do seu bucket, dessa forma a CDN irá buscar o conteúdo via HTTP e não como objetos do S3 na rede interna da AWS. Isso evita erros nas URL não terminadas em “/“.

O campo Origin Path pode deixar em branco a não ser que seu conteúdo esteja dentro de algum diretório, por exemplo http://www.exemplo.com/blog - nesse caso o path é /blog.

O campo Origin Id é um apelido para a origem, um identificador. O ID é interessante quando a distribuição possui diversas origens e através do ID fica fácil diferenciá-las, como esse não é o caso vamos deixar em branco. E por fim, os campos Origin Custom Headers devem ficar em branco para os fins deste artigo. Detalhes sobre sua utilidade estão fora do escopo deste artigo.

Default Cache Behavior Settings

Configurações de Cache

Nesta sessão as opções padrão estão boas para a maioria dos blogs estáticos. Sugiro apenas mudar para `yes` a opção assinalada em vermelho. A Cloudfront é capaz de servir o conteúdo compactado com gzip, para clientes que aceitam essa opção - praticamente a totalidade dos navegadores atualmente - isso economiza banda e acelera ainda mais o download do seu conteúdo. No futuro essas configurações podem ser modificadas para atender as necessidades que surgirem, por exemplo o uso de HTTPS.

Distribution Settings

Configurações da Distribuição

A opção padrão oferece melhor performance em todo o globo utilizando todos os servidores de borda disponíveis. É também a opção potencialmente mais cara.

Após configurar a CDN você deverá alterar a configuração do seu DNS para apontar os CNAMES aqui definidos para o endpoint da CDN.

Distribuição criada

Anote o endereço destacado em vermelho na sua distribuição, vá até seu DNS server e configure o CNAME apropriado de seu domínio apontando para este endereço. No meu caso o endereço www.benito.com.br e blog.benito.com.br são CNAMES para essa distribuição, já o [domínio APEX] benito.com.br não pode ser do tipo CNAME e necessita tratamento especial, esta função depende de seu servidor DNS.

Perceba que sua distribuição está ativa e a do exemplo acima desativada, isso porque ela foi criada apenas para escrever esse artigo. Note ainda que ela está in progress, isso significa que os servidores de borda ainda estão buscando seu conteúdo e preparando o cache. Pegue um café e relaxe, esse processo leva entre 15 e 30 minutos. Quando o processo terminar, o estado será Deployed e seu conteúdo estará sendo servido corretamente pela Cloudfront.

Endpoint S3 não aceita HTTPS

Esse é um ponto que me causou alguns problemas até eu descobrir o que estava errado. O endpoint do bucket S3 só pode ser acessado por HTTP e não por HTTPS. Já a distribuição Cloudfront pode servir tanto HTTP quanto HTTPS e, por padrão, repassa as requisições à origem no mesmo protocolo que recebe. Dessa forma se alguém acessar o site através do HTTPS, a CF irá requisitar o conteúdo no S3 através de HTTPS resultando em um erro.

Para corrigir basta desabilitar o HTTPS na origem, essa opção não está disponível no momento em que se cria a distribuição. Para acessá-la, na tela da imagem anterior clique no ID da distribuição. Na tela que se abre clique na aba Origin e selecione a origem depois clique no botão Edit. Altere as opções conforme destaque na imagem abaixo e salve clicando em Yes, edit

Edição da origem

Conclusão

Utilizar um CDN para servir o conteúdo de um blog estático é uma boa estratégia já que todo o conteúdo pode ser armazenado em cache por algum período. Assim a CDN não só acelera o download do site mas também provê disponibilidade e redundância de servidores diminuindo o tráfego direto destinado ao seu provedor. O custo de uma CDN pode ser, inclusive com opções grátis no mercado, e os benefícios são muitos. A estrutura da Cloudfront é excelente para nós brasileiros pois possui servidores de borda no Rio de Janeiro e em São Paulo com latências baixíssimas para nossos leitores no Brasil.

Espero que esse artigo ajude você a por seu site em velocidade de dobra com a AWS Cloudfront. Vida longa e próspera!

Github Pages

Um serviço gratuito e com boa qualidade é oferecido pelo Github Pages. Sua configuração é muito simples e para quem já está acostumado com o Git o setup pode ser feito em questão de minutos. O plugin ‘hexo-deployer-git` automatiza o processo de upload (o termo correto aqui é commit) tornando a manutenção do blog muito simples. Porém o Github pages não dá muito controle sobre como seu conteúdo é servido e sua CDN não permite invalidar o conteúdo do cache.

Amazon S3

A nuvem AWS possui várias regiões, utilizar a região mais próxima do público alvo diminui a latência.

O Amazon S3 é um serviço de armazenamento de massa na nuvem. Ele trabalha com o conceito de bucket que pode ser entendido como um repositório ou um diretório raiz. O usuário pode ter quantos buckets quiser com nomes distintos e o custo por Gigabyte armazenado é muito baixo. Além do armazenamento, um bucket pode ser configurado para servir, de forma estática, o conteúdo armazenado. Ainda, a nuvem AWS possui várias regiões e uma delas fica em São Paulo, se o bucket for criado nessa região a latência para usuários brasileiros é bastante baixa quando comparada a serviços de hosting localizados no exterior. Se você ainda não se convenceu, somados os custos de armazenamento e transferência de dados, um blog com 100 mil acessos semanais não custa um BigMac.

Então mãos à obra?

Criando o bucket

O nome do bucket não importa mas precisa ser único na região em que está sendo criado.

Abra o console do Amazon S3 para criar o bucket do site. Não reaproveite outro bucket pois iremos configurá-lo para servir o conteúdo através do protocolo HTTP, todo o conteúdo do bucket estará exposto na Internet. Clique no botão Create Bucket e escolha uma região para o bucket. Outro ponto importante é o nome do bucket, o domínio de nomes é compartilhado entre todos os usuários do AWS, então se eu criar um bucket chamado balde e outro usuário tentar criar um bucket com mesmo nome ele terá problemas. Para evitar esses conflitos sugiro podemos:

1. Prefixar o nome do bucket com seu nome de usuário Amazon (ideal para buckets privados que não servem conteúdo via HTTP). Exemplo jsilva-balde.
2. Prefixar o nome do bucket com o nome de domínio ou nome do domínio mais algum identificador (forma preferida para sites). Exemplos: benito.com.br ou benito.com.br-site e benito.com.br-documentos. Essa última forma ficar organizada se você tiver outros buckets para guardar informações privadas do site ou cliente.

Coloque o nome e clique no botão Create para finalizar.

Se pretende usar uma CDN para servir o site a região não importará

Criar um Bucket

Configurando o Bucket

Agora clique no botão Properties direita e depois em Static Website Hosting, selecione Enable website hosting. Indique o nome do arquivo index, esse é o arquivo padrão que o S3 irá procurar em cada diretório. Para Hexo basta preencher com index.html. O Hexo não fornece uma página de erro (404), se você possui uma página de erro informe o nome no campo correspondente. Sempre que o S3 não encontrar algo ele irá apresentar essa página ao invés de uma mensagem de erro críptica que assustará seus leitores para sempre!

Configurando o Bucket

Anote o Endpoint mostrado nessa tela, ele é o endereço de acesso do bucket na web.

O próximo passo é editar as permissões do bucket permitindo acesso público a esse bucket. Ainda nas propriedades, clique no item Permissions e depois no botão Edit bucket policy. No editor que abrirá coloque a política abaixo.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

{
"Version": "2008-10-17",
"Statement": [
{
"Sid": "Allow Public Access to All Objects",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::benito.com.br/*"
}
]
}

Altere a linha para refletir o nome do bucket, salve e feche o edito. Está garantido o acesso público de leitura a todos os objetos do bucket.

Vamos aproveitar o embalo e adicionar a configuração de CORS (Cross-Origin Resource Sharing). Esse passo é importante para garantir que outros sites possam acessar seu conteúdo, por exemplo, uma CDN servindo o conteúdo do seu S3 ou um outro site referenciando um script Javascript servido por este bucket/site. Para isso clique no botão Add CORS configuration, ao lado do botão usado no passo anterior. No editor que se abrirá coloque a configuração abaixo.

1
2
3
4
5
6
7
8

<CORSConfiguration>
    <CORSRule>
        <AllowedOrigin>*</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <MaxAgeSeconds>3000</MaxAgeSeconds>
        <AllowedHeader>Authorization</AllowedHeader>
    </CORSRule>
</CORSConfiguration>

Essa configuração é bastante permissiva e não vamos detalhar seu funcionamento agora. No futuro se pode alterar essa política conforme a necessidade do site. A Amazon provê uma vasta documentação a respeito.

Upload

Para subir suas páginas HTML no bucket, utilize o método que mais lhe convir. Nesse momento sugiro o próprio S3 Console; clique no botão azul upload, agora arraste o arquivos da pasta public do seu Hexo para área cinza demarcada no S3 Console. Espere tudo o upload terminar e teste acessando o endpoint do seu bucket digitando http://<endpoint> no seu navegador.

Depois instalaremos um plugin para fazer o upload diretamente do Hexo.

Conclusão

Pronto! Apesar do post extenso, executar os passos descritos não levará mais que 15 minutos e seu site já está no ar. Não esqueça de verificar o valor do armazenamento S3 na região que você escolheu e simular o custo mensal na calculadora AWS. Vale lembrar que Amazon oferece um free tier generoso durante um ano para novos clientes.

Ah! Quase esqueço, se você tem um domínio e deseja servir o blog deste domínio precisa apontar um CNAME para o endpoint do seu S3 bucket. Explicarei com mais detalhes quando configurarmos a CDN. Até lá.

Hoje iremos integrar o formulário ao tema e assim ganhar controle da apresentação do formulário podendo adicionar estilos e scripts e aproveitar as facilidades que seu tema disponibiliza. O tema que escolhi para meu blog é o Tranquilpeak e os exemplo abaixo serão baseados em sua estrutura. Porém, é fácil extrapolar isso para o tema de sua escolha.

Layout

As páginas source/contato/index.md e source/contato/sucesso.md criadas na parte 1 utilizam o layout page. Esse layout é obrigatório em todos os temas Hexo. Como o nome sugere ele difere do layout post e é voltado para criação de páginas do site. No Tranquilpeak v1.7.1 (mais atual enquanto escrevo esse artigo), o layout page contém:

1

<%- partial('_partial/post', {post: page}) %>

A função partial carrega um outro arquivo passando o objeto JSON {post: page}. Esse modelo de carga de arquivos parciais é bastante poderoso como veremos a seguir. Alteraremos o arquivo acima para ficar assim:

1
2
3
4
5

<% if (page.path.indexOf('contato') > -1){ %>
    <%- partial('_partial/contact', {post: page}) %>
<% } else { %>
    <%- partial('_partial/post', {post: page}) %>
<% } %>

Nessa nova versão, toda página com layout page poderá ter carregado o layout layout/_partial/post.ejsou o layout layout/_partial/contact.ejs dependendo do caminho na URL do site. Toda página cujo endereço contiver a palavra contato carregará o layout específico para páginas de contato, todas as outras continuam como antes. O arquivo layout/_partial/contact.ejs não existe no tema Tranquilpeak e devemos criá-lo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<article class="post" itemscope itemType="http://schema.org/BlogPosting">
<% if (post.coverCaption) { %>
    <span class="post-header-cover-caption caption"><%= post.coverCaption %></span>
<% } %>
<% if (!post.coverImage || post.coverMeta === 'out') { %>
    <%- partial('contact/header')%>
<% } %>
<div class="post-content markdown" itemprop="articleBody">
    <div class="main-content-wrap">
        <%- post.content %>
        <br>
        <% if (post.form) { %>
            <%- partial('contact/form') %>
        <% } %>
    </div>
</div>
</article>

O conteúdo foi extraído, com pouca modificação, do layout/_partial/post.ejs, assim a formatação fica similar. Utilizando um <DIV>com classe “main-content-wrap”, herdamos a formatação da área de conteúdo do site. E a linha <%- post.content %> é responsável por preencher o <DIV> com o conteúdo do arquivo .md já traduzido de markdown para HTML. Através da condição <% if (post.form) { %>, a variável form controla a inserção do conteúdo do arquivo layout/_partial/contact/form.

1
2
3
4
5

<form action="https://formspree.io/<%= theme.author.email %>" method="POST">
    <input type="text" name="name">
    <input type="email" name="_replyto">
    <input type="submit" value="Send">
</form>

Repare na utilização da variável provida pelo tema theme.author.email para preencher o action do formulário. Dessa forma a solução fica mais portável. Os arquivo source/contato/index.md e source/contato/sucesso.md alterados estão abaixo. O formulário migrou do arquivo de markdown contato/index.md para o layout form.ejs e foi acrescentada a variável form ao front-matter.

1
2
3
4
5

title: Contato
layout: page
form: true
---
Deixa sua mensagem!

1
2
3
4
5

title: Contato
layout: page
form: false
---
Obrigado por nos enviar uma mensagem!

Eu particularmente não gosto que a data de postagem seja incluída junto ao título da página de contato. Retirei ela criando um novo cabeçalho para as páginas de contato em layout/_partial/contact/header.

1
2
3
4
5
6
7
8
9
10
11
12
13

<div class="post-header main-content-wrap <%= (post.metaAlignment ? 'text-' + post.metaAlignment : 'text-left') %>">
<% if (post.link) { %>
    <h1 itemprop="headline">
        <a class="link" href="<%- url_for(post.link) %>" target="_blank" itemprop="url">
        <%= post.title || '(' + __('post.no_title') + ')' %>
        </a>
    </h1>
<% } else { %>
    <h1 class="post-title" itemprop="headline">
        <%= post.title || '(' + __('post.no_title') + ')' %>
    </h1>
<% } %>
</div>

Conclusão

O que foi apresentado até aqui integra o formulário HTML ao conteúdo do site, permite que os arquivo .md controlem o conteúdo das páginas mas delega o layout do formulário ao tema. Ainda é preciso criar alguns estilos CSS para os campos e legendas pois o Tranquilpeak não prevê o uso de campos de formulário. Porém, utilizando o tema dessa forma fica simples reaproveitar o que o tema oferece e ainda acrescentar estilos e scripts ao formulário.

Edição: Após terminar de escrever, revisar esse artigo, já com ele pronto para publicação percebi que seria mais elegante, ao invés de editar o layout page para escolher entre os arquivos parciais, criar um novo layout chamado contato e declará-lo no front-matterdo arquivo .md. Apesar de mais elegante essa solução demanda mais alterações no tema ficando, então, para outra oportunidade.

Veja o formulário básico:

1
2
3
4
5

<form action="https://formspree.io/your@email.com" method="POST">
<input type="text" name="name">
<input type="email" name="_replyto">
<input type="submit" value="Send">
</form>

Integrando com o Hexo

Modo rápido (e feio!)

No Hexo basta criar uma página (não um post) chamado contato:

$ hexo new page contato

Uma página nova será criada em source/contato/index.md, edite esse arquivo para conter algo similar a:

1
2
3
4
5
6
7
8
9
10
11

title: Contato
layout: page
---
Deixa sua mensagem!

<form action="https://formspree.io/your@email.com"
  method="POST">
<input type="text" name="name">
<input type="email" name="_replyto">
<input type="submit" value="Send">
</form>

Nesse ponto o formulário já funciona e pode ser acessado em http://seu.dominio.com/contato/. Mas vamos melhorar um pouco a experiência do usuário acrescentando uma página personalizada de sucesso após o envio da mensagem. Para isso vamos criar o arquivo source/contato/sucesso.md.

1
2
3
4

title: Contato
layout: page
---
Obrigado por nos enviar uma mensagem!

E acrescentamos um campo escondido ao formulário no arquivo source/contato/index.md.
(mais detalhes sobre os campos escondidos veja o site formspree.io)

<input type="hidden" name="_next" value="//seu.dominio.com/contato/sucesso.html" />

Esse campo não aparece para o usuário e instrui o formspree a retornar para a página de sucesso depois de enviar o formulário.

Pronto! O formulário de contato está integrado ao site.

Pontos negativos

• O endereço e-mail fica aberto à scrappers, porém colocar um mailto: no site teria o mesmo efeito. Também, as ferramentas de e-mail modernas são muito boas em filtrar spam.
• Esse método oferece pouco controle sobre a apresentação do formulário, isso porque o Hexo irá interpretar o arquivo .md como markdown. Isso não altera diretamente o código HTML do formulário mas torna difícil controlar o resultado final.
• O resultado pode variar muito de acordo com o tema utilizado. Essas variações podem não ser agradáveis.

Uma alternativa para ter mais controle sobre a apresentação do formulário é criar o HTML completo ao invés de um .md. O Hexo vai apenas copiar o HTML para o site final. Mas isso requer cópia da estrutura gerada pelo Hexo para dentro do HTML manualmente afim de fazê-lo se parecer com uma página do site. Manter a sincronia dos arquivos pode se tornar trabalhoso.

Outra saída é personalizar o tema. Explicarei os detalhes de como fazer isso na parte 2 desse artigo.

continua...

Se você já conhece e utiliza o Node.js, basta instalar o Hexo. Eu precisei instalar o Node.js em meu Ubuntu, e a maneira mais prática que encontrei para fazê-lo foi através do nvm; a forma também descrita na documentação do Hexo. No terminal do Ubuntu, como usuário normal (não root) fiz:

$ wget -qO- https://raw.github.com/creationix/nvm/master/install.sh | sh

E em seguida usei o nvm para instalar o Node.js.

$ nvm install 4.4.3

Muitos tutoriais na internet utilizam a versão 0.12 do Node.js com o Hexo, mas alguns plugins e módulos do próprio Node.js requerem a versão mais nova. Então preferi instalar a versão LTS, v4.4.3 enquanto escrevo esse artigo. Também poderia baixar o instalador no site do Node.js. Caso tenha usado o nvm, em novas sessões do terminal é importante ativar o Node.js rodando nvm use 4.4.3.

Instalando o Hexo e iniciando o blog

Depois foi só instalar o Hexo. No momento em que esse artigo é escrito a versão mais recente é a 3.2.0.

$ npm install hexo-cli -g

Para iniciar o blog

1
2
3

$ hexo init meuBlog
$ cd meuBlog
$ npm install

O último comando é responsável por instalar os pacotes Node.js dos quais o hexo depende para gerar o blog. Para quem já trabalha com Node.js não é novidade, mas é importante saber que o diretório do blog é como uma espécie de sistema desenvolvido em Node.js. O Hexo e todas os pacotes dos quais eles dependente são instalados dentro do diretório do blog.

Para ver o blog rodando, o Hexo possui um mini servidor:

$ hexo server

Acesse o conteúdo apontando seu navegador para http://localhost:4000.

Controlando seu blog com Git

Esse passo é opcional mas muito recomendado. Como alterações nas configurações, testes, novos artigos são operações freqüentes no blog, o versionamento do conteúdo é uma excelente maneira de manter registro dessas modificações e, de quebra, adicionar um pouco de proteção a desastres (sem dispensar o backup). Após inicializar o blog com Hexo, inicializei um repositório Git:

$ git init

Coloquei um arquivo .gitignore no repositório para instruir o git a ignorar arquivos que não devem ser rastreados.

1
2
3
4
5
6
7
8

.DS_Store
Thumbs.db
db.json
*.log
node_modules/
public/
.deploy*/
*~

E adicionei os arquivos ao repositório:

1
2

$ git add *
$ git commit -m "Blog: estado inicial"

A cada alteração importante eu gravo um snapshot no repositório com um novo commit. Dessa forma posso retroceder a qualquer momento no tempo e restaurar um estado funcional do site.

Arquivos do site

Um site recém gerado com Hexo contém:

Veja a listagem deste blog.

1
2
3
4
5
6
7
8
9
10

drwxrwxr-x 6 jrbenito jrbenito 4096 Mai 19 00:43 .
drwxrwxr-x 5 jrbenito jrbenito 4096 Mai 19 00:43 ..
-rw-rw-r-- 1 jrbenito jrbenito 2203 Mai 19 00:43 _config.yml
drwxrwxr-x 8 jrbenito jrbenito 4096 Mai 19 00:43 .git
-rw-rw-r-- 1 jrbenito jrbenito   71 Mai 19 00:43 .gitignore
-rw-rw-r-- 1 jrbenito jrbenito  727 Mai 19 00:43 package.json
drwxrwxr-x 2 jrbenito jrbenito 4096 Mai 19 00:43 scaffolds
drwxrwxr-x 7 jrbenito jrbenito 4096 Mai 19 00:43 source
drwxrwxr-x 4 jrbenito jrbenito 4096 Mai 19 00:43 themes
-rw-rw-r-- 1 jrbenito jrbenito 2590 Mai 19 00:43 .travis.yml

Os arquivos .git e .gitignore são específicos dos repositório git; o .travis·yml também não pertence ao Hexo e sua função é assunto para outro post.

Feito!

Pronto, agora é só personalizar o blog através das configurações e temas.

Dentre os geradores de sites que conheci, escolhi o hexo por sua simplicidade e por rodar em diversas plataformas sem problemas de compatibilidade possibilitando que eu edite esse blog em casa no Linux ou em uma máquina windows on the go. Continuando minha saga escreverei ainda sobre como hospedar o blog no AWS S3 e configurar uma CDN para acelerar o acesso ao site.

Recentemente meu irmão iniciou um projeto para sua esposa; um site com sua apresentação profissional e um fomulário de contato para que seus clientes pudessem encontrá-la. Ele já tinha um esboço do trabalho e estava hospedando junto ao site de um amigo apenas para teste. Começamos a conversar sobre qual domínio registrar, qual hospedagem contratar, qual tamanho da demanda e claro: preço!

Já há algum tempo que eu venho maturando a ideia de iniciar um blog com o objetivo de documentar meus projetos pessoais, compartilhar informação e manter organizado aquele conhecimento resultado de horas na Internet tentando resolver algum problema (geralmente simples). A discussão sobre o projeto para minha cunhada foi a faísca para que eu mergulhasse em uma pesquisa sobre sites, hospedagem, custos, tecnologias e acabasse por escrever esse primeiro post.

Estático vs. Dinâmico

O modelo mais comum de website contém uma mistura de páginas com conteúdo estático e páginas de conteúdo dinâmico que se alteram de acordo com a interação entre o usuário e o sistema. Por exemplo, uma oficina mecânica teria em seu site páginas de informações estáticas como endereço, serviços prestados, fotos do local e um sistema para confecção de orçamentos via internet que gera conteúdo dinamicamente.

Sistemas web necessitam que seu código fonte seja executado no servidor, também costumam depender de bancos de dados e essa estrutura pode ser bem grande e depender de vários computadores para funcionar. Um bom provedor de hospedagem oferece pacotes que alocam recursos computacionais de acordo com a necessidade dos usuários.

Já o conteúdo estático precisa apenas ser transmitido de um servidor para o cliente, geralmente um navegador web. Esse processo não envolve grande poder computacional e ainda há a possibilidade de cache diminuindo o tráfego de dados sendo possível a utilização de pacotes de serviços mais baratos e com menos recursos computacionais.

Para o projeto de minha cunhada, meu irmão e eu chegamos a conclusão que um conjunto de páginas estáticas em HTML5, CSS e Javascript seria suficiente.

Hospedagem

Na pesquisa por hospedagem eu encontrei nos serviços AWS da Amazon uma alternativa muito interessante. O [Amazon Web Services] é o nome comercial de um dos maiores serviços de computação em nuvem do planeta. Eles comercializam serviços com preços atrativos e faixas de consumo que se adaptam ao tipo do usuário.

O serviço S3 é uma espécie de disco rígido virtual onde se pode armazenar quantidades absurdas de dados com garantias de durabilidade, versionamento e preços atrativos. O S3 é capaz de servir o conteúdo armazenado em forma de site estático, o custo por GB é baixo, ele oferece um free tier para novos clientes que é suficiente para acomodar sem custos o projeto de minha cunhada nos primeiros meses. Problema resolvido.

Também através dessas pesquisas eu conheci o Hexo um gerador de sites estáticos escrito em Node.js, cheio de plugins e de fácil automação. Perfeito para iniciar meu blog e hospedá-lo no AWS.

Nasce mais um blog

Inspirado pela pesquisa e satisfazendo um desejo antigo estou iniciando esse blog utilizando:

• Amazon AWS como backend
• Hexo para gerar o site
• Draftin para escrever esse post

Além de um nome pouco criativo para o blog.

Nos próximos artigos eu farei um passo à passo de como coloquei esse blog no ar, a configuração do Hexo, Node.js, dos plugins e dos serviços AWS. Fique ligado.