Já usei o WordPress, tanto hospedado pessoalmente quanto compartilhado no wordpress.com. O problema era: atualizar a versão do Wordpress, atualizar os plugins, acessar o painel pra postar e usar o editor WYSIWYG pra formatar. Muito trabalho.
Em 2011, usei o Blogger. Poucas opções pra customizar, e o mesmo workflow: acessar painel, usar editor WYSIWYG, alternar entre o código-fonte e o visual pra formatar. Muito trabalho.
HTML sux
Usar uma linguagem de marcação tão verbosa (<strong> e </strong> pra negrito, p.e.) e com tanto ruido atrapalha a escrita. As tags começam a quebrar a leitura (e as idéias) e no final você tem que ligar o seu interpretador de HTML cerebral pra expressar as idéias.
Muito esforço. Por isso é muito ruim escrever tudo em HTML
O workflow envolve muitos passos online/offline
Por causa do problema (1) eu era forçado a usar o seginte workflow:
A questão não é a parte dos “muitos passos” e sim “online/offline”.
O problema real é que as plataformas de blogging se baseiam no HTML (afinal de contas, se você pode publicar em HTML pode publicar qualquer coisa). Eu não quero fazer qualquer coisa que eu quiser. Quero fazer apenas o que eu preciso.
A solução seria uma plataforma de blogging que me fornecesse (por padrão) algo mais legível (mesmo que mais restrito) que HTML e que oferecesse “suporte” a HTML. O que eu queria era uma plataforma que suportasse Markdown.
No final de 2011, ainda tentei usar o Posterous pela promessa de suporte a Markdown mas ainda assim era um grande #fail: precisava de um comentário HTML no topo do post pra indicar que eu tava escrevendo em Markdown e depois pra editar, era no editor visual deles, arghhhh… Gambi.
No final do ano, por acaso, conheci o Octopress - um framework de blog baseado no Jekyll (um gerador estático de website).
A instalação foi muito simples, é só seguir a documentação. Em seguida, configurei o deploy para ser feito no Github Pages. Isso é MUITO maneiro.
Pra importar os posts do Blogger eu modifiquei um script que eu achei.
Cuidado: ele vai limpar sua pasta _posts. O melhor é criar um diretorio import, jogar o script e o .xml do seu blogger nele, executar a importação e depois copiar de import/_posts para _posts do seu Octopress.
Agora meu workflow é simples:
rake generate && rake preview e visualizar o blog em localhost:4000rake generaterake deployThe GStreamer is organized into several modules. The required modules are gstreamer, gst-plugins-base and gst-plugins-good (if you want to do anything useful). This post will show how to build also gst-plugins-bad and qt-gstreamer modules.
1 2 3 4 5 6 7 8 | |
1 2 3 4 5 | |
1 2 3 4 5 | |
1 2 3 4 5 6 7 8 9 10 11 12 | |
1 2 3 4 5 6 7 8 9 10 11 12 13 | |
1 2 3 4 5 6 | |
Note: osxvideosrc and qtwrapper are disabled because they use deprecated APIs (more info).
1 2 3 4 5 6 7 8 9 | |
No servidor, crie um usuário que será utilizado para realizar o deploy. Eu utilizei uma senha gerada aleatóriamente (um MD5 de um arquivo, por exemplo). Em seguida, adicionei minha chave privada (a que eu uso para acessar meus repositórios no Github) ao arquivo authorized_keys do usuário de deploy.
Na máquina local
1 2 | |
No servidor
1 2 3 4 5 6 7 | |
Adicione a gem capistrano no seu Gemfile
1
| |
Em seguida, no diretório da aplicação
1 2 3 | |
Isso vai criar o arquivo config/deploy.rb onde serão armazenadas as configurações de deploy, bem como as tasks.
Meu arquivo ficou assim:
Pra finalizar, você precisa criar os diretórios no servidor. Para isso simplesmente execute (no diretorio da aplicação) cap deploy:setup.
Depois disso, você poderá realizar seu deploy automático executando o comando: cap deploy.
application "Hello, Android!" com.example.android.hellodroid {
string hello = "Hello, Android! I am a string resource!"
activity HelloDroid {
=> show main
}
layout main {
textView: @string hello
}
}
application "Hello, Android!" => com.example.android.hellodroid {
string hello = "Hello, Android! I am a string resource!"
screen HelloDroid {
# textView: @string hello
}
}
application "SimpleWizard" => org.eclipse.amalgam.tutorials.android.simplewizard {
screen First {
# textView: "This is the first screen" {}
# button: "Next >" to Second {}
}
screen Second {
# textView: "And this is the second screen" {}
# button: "< Back" to First {}
# button: "Next >" to Third {}
}
screen Third {
# textView: "Now, the last one" {}
# button: "< Back" to Second {}
}
}!MESSAGE Unable to create editor ID org.eclipse.amalgam.tutorials.xtext.Droid: No editor descriptor for id org.eclipse.amalgam.tutorials.xtext.DroidAnd when I launched the “Eclipse Application” run configuration, the resulting Eclipse warned:
Could not open the editor: No editor descriptor for id org.eclipse.amalgam.tutorials.xtext.DroidAfter some time cursing Xtext, I discovered that in order to launch the “Eclipse Application” run configuration, you must to have all the generated projects opened in the package explorer (that means both .generator and .ui projects must be open). ]]>
Google Summer of Code (GSoC) é um programa que oferece a desenvolvedores estudantes estipêndios para escrever código para vários projetos opensource. [1]
Teorema: Você só deve liberar (release) objetos que você possua (ownership).
Corolário: Se você precisa armazenar um objeto recebido, você deve tomar posse dele. Geralmente você delega essa responsabilidade aos métodos accessors (@property/@synthetize).TODO: Falar sobre Autorelease Pools e Copy.
$ git cvsimport -v -d :pserver:anonymous@dev.eclipse.org:/cvsroot/modeling org.eclipse.amalgam/docs/org.eclipse.amalgam.dsltk.docE funcionou que é uma beleza. O objetivo da tarefa era apenas saber se eu sou capaz de fazer checkout de um repositório de código. Caso eu não soubesse, era só eu pesquisar, perguntar no IRC e aprender como faz.