Migrando do Jekyll para o Pelican

 pelican

Eu queria um blog com sistema de publicação simples, com layout mais limpo possível e sem propagandas. Front end eu resolveria com Bootstrap em qualquer plataforma, e que não apresentasse complexidades desnecessárias:

  • não precisar de manutenção no servidor
  • não ter problema com banco de dados
  • não precisar fazer backup do sistema e configurações
  • sem preocupação com firewall
  • pensar formas de fazer deploy

Podem parecer coisas bobas, mas na correria do dia a dia, estes problemas se tornam bolas de neve. Sim, vão de fato te atrapalhar e diminuir a produtividade com relação as postagens. Seja simples, faça simples e continue simples. :)

Por esse motivo escolhi ter um blog que utilizasse um gerador de site estático, já que ainda poderia versionar o código e o conteúdo, seria uma opção perfeita.

Esses geradores de site estático tem se popularizado muito e tem sido implementados em várias linguagens.

O fato de ter um template básico (esqueleto base) e escrever tudo em markdown, para no final gerar um site em HTML. Com uma separação muito clara de código template com conteúdo, se torna fantástico pela simplicidade.

Chegou até aqui e não sabe o que é site estático?

Basicamente você escreve um template/layout/tema base/modelo/padrão e o conteúdo em arquivos separados (essa parte é em HTML, CSS e JS). Quando você “compila” o site estático, ele junta as 2 partes e transforma em um site baseado no template/layout/tema que você forneceu. É a explicação mais básica que consigo encontrar.

Como esse sistema é HTML, CSS, JS e os posts são escritos em texto puro, pra min, desenvolvedor a melhor forma de gerenciar esse conteúdo é usando git. Assim tenho todo o histório de modificação e ainda posso integrar à algum sistema de CI para verificar a consistência das modificações em uma máquina zerada para fazer o build e depois se tudo der certo fazer o deploy.

Voltando a explicação de o que é um gerador de site estático, segue algumas explicações mais complexas:

Vou apresentar em formato de lista a ordem e quais geradores de sites estáticos eu testei, o que eu levava em consideração para a minha escolha final era:

  • A mistura de markdown e HTML em um documento .md
  • Fácil preparação de ambiente pra começar

Segue a lista, sim alguns testei mais de uma vez :)

  • Jekyll: me chamou atenção por ser de um dos cofundadores do Github, Tom Preston-Werner e por ter uma integração bacana com o Github e que era sempre crescente. Acabei não utilizando, por que utilizava Ruby, somente para ele.
  • docpad: a estrutura de pastas era um pouco confusa, se comparada com a do Jekyll e não fazia muito sentido pra min. Ficava perdido. Por causa disso não portei o template do Jekyll para o docpad
  • harp: tinha gostado de toda a estrutura, principalmente do suporte a SASS, precisaria converter para o sistema de template do harp (.ejs), mas eu preferia Jade (template engine) por ser mais limpo que o ejs e mais simples. Mas eu já havia decidido usar o S3 e ele não possuía uma forma de deploybuilt-in e estava ficando complicado de novo, precisaria adicionar Gruntjs ao processo de deploy para fazer o build e enviar para o S3, o foco era ser simples, vamos ao próximo. Já que o harp possuia CLI, teria de usar outra a do Gruntjs para fazer o deploy. (Pelo sistema atual que utilizo, repensando, este também faria sentido, caso goste de ejs)
  • hexo: se me lembro bem, encontrei pouca informação para a conversão do layout e olha que o meu era o mais simples que existe.
  • Pelican: na primeira vez que usei não entendi muito bem com funcionava, talvez por falta de exemplos. Fiquei totalmente perdido e não conseguia configurar da forma que eu precisava.
  • Jekyll: dessa vez esbarrei em problemas com interpretador NodeJS que ele também é requerido, depois descobri que a gemtherubyracer (e não para por aí, existem alternativas a essa gem) resolvia o problema e adicionei ao meu Gemfile.
  • Hugo: foi na época que eu começei a ler sobre Go, primeiro pelo livro do Caio Filipini, Programando em Go - Crie aplicações com a linguagem do Google (se você for aprender Go, recomendo este livro), depois acabei não continuando por não usar tanto Go, então teria de manter ele instalado só pra ter um blog e seria custoso, todo o ambiente Go, simplesmente para ter um blog, já procurava outra alternativa ao Jekyll por não usar tanto ruby mais e por ser muito complicado o setup initial, de novo, vamos ao próximo.
  • Jekyll: mesmo optimizando meu ambiente ruby com a instalação do rvm, ruby e a therubyracer, estavam demorando para instalar e começar a “blogar”
  • Pelican: por fim, dessa vez deu tudo certo, graças a algumas referências e também por que eu estava mexendo com Python no trabalho, foram diferenciais para me acostumar e usar definitivamente. Outro diferencial é que Python já vem instalado em Ubuntu e algumas outras distribuições Linux isso facilitaria, principalmente por não ter de ficar instalando pacotes a mais no sistema.

Na segunda vez que testei ele (Pelican), tive a sorte de encontrar 2 referências que me ajudaram muito:

Enfim comecei a migração, com essas referências foi bem mais simples a configuração inicial. A referências não eram só do arquivo de configuração, mas também do template, que eu analisava e migrava o meu de Jekyll pra Pelican.

Surpreendentemente foi mais simples do que eu imaginava a migração, o Liquid (template engine) do Jekyll é muito similar ao Jinja2 (template engine para Python) e a migração foi tranquila.

E estou gostando dessa mudança, até por que agora uso um gerador de site estático em Python que tenho usado tanto.

O HTML final gerado é enviado para o S3 (que possui uma opção de armazenamento de páginas estáticas) e como CDN utilizo uma opção da própria Amazon o CloudFront.

A dica é que, se usar o próprio CDN da Amazon, eles disponibilizam um serviço de certificado SSL grátis, através do AWS Certificate Manager.

Isso é uma experiência pessoal, refletindo os meus e somente meus testes baseados nas minhas habilidades e limitações. Não é verdade absoluta e nem visa ser. O intuito disto é apenas demonstrar o caminho até chegar a stack perfeita para meu uso e que pode ser uma curiosidade alheia.


comments powered by Disqus