Nesta série de artigos falei sobre praticamente todo o processo de migração do meu antigo blog para este que vossemecê vê agora. Da motivação até aspectos avançados da customização de um tema, tudo foi dito até o momento. Em minha opinião, falta apenas eu dizer como é o fluxo de trabalho cotidiano que mantém o MexApi alimentado com contéudo, desde a criação do post até a publicação final, e de um detalhe que ninguém dá muita bola: o licenciamento do conteúdo que publico.

Hoje falarei disso e encerrarei essa série.

Workflow

Acho dispensável dizer o que é um workflow, não é? Sei que vocês são espertos e sabem o que é isso.

Pois bem, o workflow que adoto no dia a dia para publicar algo aqui é o seguinte:

  1. Idéia do post;
  2. Criação do post;
  3. Escreve, escreve, escreve;
  4. Edita, edita, edita;
  5. Revisa, revisa, revisa;
  6. Publica.

Eventualmente, há um workflow adicional: o de desenvolvimento, ou bugfix, ou melhoria no código do blog. Este workflow é assim:

  1. Identifica problema/melhoria;
  2. Dev, dev, dev;
  3. Testa, testa, testa;
  4. Commita;
  5. Publica.

São dois fluxos bastantes distintos. Nem tanto pelos passos, que são essencialmente os mesmos, mas pelas atividades e finalidades. Para o incauto essas diferenças poderiam tornar as coisas complexas no dia a dia da separação entre código e conteúdo do blog. Poderiam, não fossem duas palavrinhas mágicas:

GitHub Pages

Quando 'descobri' o Octopress, notei que ele se integrava a um treco chamado GitHub Pages. Esse treco nada mais é que um serviço gratuito de hospedagem web embutido no serviço de repositório que o GitHub fornece desde o princípio.

O GitHub Pages fornece dois tipos de hospedagem, a saber:

  • User & Organization: nesta modalidade, todos os arquivos do site (html, css, js, imagens etc) ficam num repositório à parte. Este repositório, que tem um nome especial, é acessado como um site quando alguém digita, por exemplo, atmos.github.io no navegador.
  • Project: no Project Pages, os arquivos do site ficam num branch especial, chamado obrigatoriamente de gh-pages. O acesso é feito a partir de um endereço tipo username.github.io/projectname.

Agora, note que no Project Pages os arquivos do site ficam num branch diferente do master. Isto abre a seguinte possibilidade:

  • Código do site no branch master.
  • Conteúdo do site no branch gh-pages.

Mais fácil e intuitivo impossível!

E é justamente assim que o Pelican se integra com o GitHub Pages. Lindo de morrer!

Ok... ele também se integra com o User & Organization pages, mas não acho tão legal e flexível quanto o Project.

Código

No começo do seu blog, você vai customizar o tema e fazer um monte de trabalho de desenvolvimento. Neste momento, o workflow mais utilizado será o de desenvolvimento, que eu já citei acima. Na linha de comando, ele ficará mais ou menos assim (considerando que o make regenerate já está rodando em outro console):

$ cd path_to/meusite
(meusite)$ workon meusite
(meusite)$ vi themes/meutema/meutemplate.html
Dev, dev, dev;
testa, testa, testa.
:wq
(meusite)$ git add themes/meutema/meutemplate.html
(meusite)$ git commit -m "Fiz algo em meutemplate."
(meusite)$ git push

Pronto, seu código novo está devidamente guardado no GitHub.

Conteúdo

Depois que o seu tema estiver tinindo, o trabalho de desenvolvimento diminui e começa o ciclo de conteúdo, ou a vida útil do seu blog. Aí quem vai dominar é o workflow de conteúdo, que na linha de comando ficará parecido com isso, também considerando que o make regenerate já estará lá rodando:

$ cd path_to/meusite/content
$ vi content/meu-post-fodao.rst
escreve, escreve, escreve;
edita, edita, edita;
revisa, revisa, revisa.
:wq
$ workon meusite && cd path_to/meusite
(meusite)$ make github

Note que o virtualenv do seu site só foi ativado para rodar o make. Você não precisa dele para trabalhar com o conteúdo. Somente o console onde o make regenerate está rodando e o make github precisarão do virtualenv do seu site.

Esse make github aí faz toda a sacanagem necessária para seu site ser publicado corretamente no branch gh-pages do repositório do seu site no GitHub. Quando você acessar seu repositório lá, dê uma olhada no botãozinho branch. Você vai ver que ele mostra master como padrão, mas quando clicado haverá um branch gh-pages. Isso é obra do Pelican. Selecione o branch gh-pages e veja que os arquivos são completamente diferentes do branch master. São os arquivos estáticos do seu site.

Agora acesse meuusuario.github.io/meusite e bamn!!! Seu site aparece lindão!

Dica:

O GitHub Pages permite customizar algumas coisas:

  • Domínio próprio: acha o endereço meuusuario.github.io/meusite longo, esquisito ou ambos? Use seu próprio domínio. Para colocar aquele arquivo CNAME que o gh-pages exige na raiz do site, crie o arquivo CNAME dentro do diretório meusite/content/extras/ e faça isso no seu pelicanconf.py. Configure o seu DNS para apontar o endereço desejado no seu site para o CNAME indicado pelo GitHub e aguarde propagar.
  • 404 customizada: se quiser ter uma página de erro 404 (page not found) com a cara do seu site, crie essa página do jeito que quiser em HTML puro (sem nada de Jinja2), salve-a em meusite/content/extras/ e use o mesmo método do CNAME para copiar a página para a raiz do branch gh-pages.

Licenciamento

A partir de 15/09/2016, o conteúdo do MexApi é licenciado sobre a Creative Commons 3.0. Todo o conteúdo até esta data continua sendo CC0 por toda a eternidade.

Para encerrar, gostaira de comentar sobre algo que não tem nada de técnico, porém tem tudo de ético.

Note que no rodapé de todas as páginas do MexApi existe a seguinte frase:

MexApi is licensed under CC0.

Este é a licença de domínio público do Creative Commons. Em termos jurídicos, ela significa que a pessoa (no caso, eu) que publicou o trabalho (no caso, o MexApi inteiro, conteúdo e código1)...

...renunciou todos os direitos de autor e direitos conexos ou vizinhos, juntamente com todas as reivindicações associadas e causas de ação com relação a este trabalho na medida do possível nos termos da lei.

CC0 Waiver

Na prática, isso significa o seguinte:

  1. Estou cagando e andando para os direitos autorais de todo o MexApi [1]_ e se o conteúdo dele será copiado ou tornará alguém pobre ou rico;
  2. Estou cagando dois baldes e meio se você usar o conteúdo ou código que publico através dele e não me citar como autor.

Mas por que isso? Porquê tudo que aprendi para fazer o MexApi ou qualquer coisa que publico nele eu aprendi por prazer e de graça, na internet ou com pessoas que não me cobraram nada para me ensinar. Não consigo imaginar forma mais justa e sustentável de manter vivo esse ciclo maravilhoso que é o tal do conhecimento livre do que devolver isso de uma forma completamente irrestrita, atribuída ou não a mim, para quem achar que o que existe aqui é de alguma utilidade e decida usar isso em algum lugar, obtendo ou não lucro com isso. Simples assim.

C'est fini. Desejo que tudo isto seja útil a alguém. ;)


  1. Sobre o código do MexApi, nem todo ele foi escrito por mim. Como eu disse aqui, o tema e algumas funcionalidades foram baseados em trabalho de terceiros. Esses terceiros licenciaram seus trabalhos de outras formas, cujas restrições se aplicam. Consulte o licenciamento destes trabalhos para saber como e em quais circunstâncias você pode utilizar esses recursos em seu site.