Markdown no Wordpress

Você já ouviu falar em Markdown?

Mardown é um formato de texto criado por John Gruber. Seu objetivo é ajudar aqueles que escrevem conteúdo para web a se tornarem mais produtivos, permitindo que se escreva o mesmo código (X)HTML com uma sintaxe mais simples e direta.

Para o seguinte texto Markdown, por exemplo:

Meus links favoritos:

* [Google](http://www.google.com)
* [Ruby](http://www.ruby-lang.org)
* [Rails](http://www.rubyonrails.com)

Teremos a seguinte saída HTML:

<p>Meus links favoritos:</p>
<ul>
    <li><a href="http://www.google.com">Google</a></li>
    <li><a href="http://www.ruby-lang.org">Ruby</a></li>
    <li><a href="http://www.rubyonrails.com">Rails</a></li>
</ul>

A sintaxe completa do Markdown pode ser obtida neste link.

É claro que para essa sintaxe se tornar realmente útil ela precisa ser implementada com alguma linguagem de programação, e então ser embutida como um filtro de uma ferramenta de publicação (um blog, por exemplo). As implementações de Markdown são várias. Para Ruby, por exemplo, temos a biblioteca BlueCloth.

Já para PHP temos a implementação de Michel Fortin. Nesse mesmo link você pode baixar a implementação, aprender como incluir o suporte em seus programas e, talvez o mais importante, aprender como habilitá-la no Wordpress.

Se você ficou com preguiça de seguir o link anterior, aqui vai uma ajuda:

  • Baixe o pacote PHP Markdown aqui.
  • Descompacte o pacote.
  • Copie o arquivo markdown.php para o diretório wp-content/plugins/ da sua instalação do Wordpress.
  • Dentro da interface administrativa do Wordpress ative o filtro Markdown (em “Extensions”).
  • Desabilite o uso do editor visual para o seu usuário (em “Users”).

Não é possível alternar entre editor visual e sintaxe Markdown dentro do Wordpress. Uma vez realizados os passos acima, seus posts futuros (e também os antigos) passam a ser interpretados como textos Markdown.


Ruby on Rails pode não ser o framework adequado para o seu projeto

Nos últimos dias passei por uma “crise existencial” enquanto procurava justificativas para o meu TCC. Como alguns podem lembrar o tema já foi “Adaptabilidade em um LMS baseado em SCORM”, mas eu acabei tirando a parte de “adaptabilidade” pois não vou conseguir dar conta de fazer tanta coisa até outubro (preciso ainda confirmar esse assunto com meu orientador, na verdade).

De qualquer modo o restante do título poderia ficar intacto, “Um LMS baseado em SCORM”. Pois bem, aí entra Ruby. Já há alguns anos eu escrevo pequenas coisas em Rails, mais para aprender os conceitos por trás do framework do que para fazer algo realmente útil. Mas com o TCC batendo à porta ficou cada vez mais necessário escrever meu primeiro projeto sério com Rails, que é o meu LMS, batizado “Astra”.

Agora como você justifica a escrita de um LMS em Rails?, quando há um outro, em PHP, já próximo da versão 2.0, muito bom em termos de funcionalidade, com uma grande comunidade de usuários e desenvolvedores e, principalmente, com uma arquitetura modular (sim, estou falando do Moodle). Pois bem, como justificar?

Eu pensei, é claro, em várias coisas:

  • Ruby é uma linguagem mais poderosa (Closures, Módulos, Metaprogramação etc.)
  • Rails é um framework de peso no mundo Open Source, e sua arquitetura MVC junto de bibliotecas como ActiveRecord e a integração com RSpec promovem desenvolvimento ágil e orientado por testes, uma boa prática quando se quer alcançar maior produtividade e menos bugs.

Mas fica faltando algo… vocês percebem? Cadê a parte que diz que uma aplicação Rails pode ser feita de forma facilmente estensível? Quero dizer, da mesma forma que o Moodle pode ser estendido com módulos de atividades, filtros de texto e caixinhas, como podemos escrever uma futura aplicação Rails?

A resposta: com muito, muito esforço. O autor do Radiant CMS, John Long, comenta isso em seu blog. De fato, ele até defende mudanças profundas na estrutura de diretórios do Rails. Essa discussão está em seu blog, e também se alastrou pela lista de discussão do Rails. O que a comunidade “core” do Rails disse? “Desenvolvimento baseado em componentes não nos interessa. Quando houver mais desenvolvedores com esse mesmo desejo - justificando uma mudança -, então pensamos no caso”.

Justificando este post: nessa mesma discussão alguns desenvolvedores Rails mais experientes deixam claro que o Rails foi projetado para criar projetos rápido “do zero”, e não para criar grandes projetos baseados em componentes, tais como Moodle, Wordpress ou Drupal. Não que isso seja impossível em Rails, mas há frameworks muito mais adequadas para isso.

Quero dizer, como justificar o Rails como um bom substituto para a arquitetura do Moodle, se nessa troca as melhores características desse último (modularização, por exemplo) são perdidas?

Então o Rails não parece ser a minha melhor opção, certo? Errado. Apesar de “ruim”, precisa existir algo melhor para que o Rails deixe de ser minha melhor opção (nesse projeto em particular). E parece que existe: o Django, um framework web escrito em Python, que parece ser baseado totalmente no desenvolvimento orientado a componentes - exatamente aquilo que estou procurando para o meu LMS.

Sobre o Django eu não posso dizer mais coisas, pois ainda não pesquisei nada sobre ele. Mas essa é a minha próxima lição de casa, e volto a falar mais sobre ele nos próximos posts.

Links interessantes sobre (falta de) modularidade no Rails: