Reinaldo Junior

Um outro tech-blog

Migrando o blog para Octopress

| Comments

O Ano novo sempre traz a intenção (promessa) de fazer melhor. E para manter a tradição: ano novo, blog novo.

Histórico

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.

Os problemas

  1. 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

  2. O workflow envolve muitos passos online/offline
    Por causa do problema (1) eu era forçado a usar o seginte workflow:

    • Rascunhar os posts “offline”, escrevendo num arquivo .txt. Essa parte demora.
    • Acessar o painel do blog “online”, criar o post
    • Formatar o post “online”, olhar como ficou no editor WYSIWYG, repetir.
    • Colocar color highlight nos códigos, disponibilizar os códigos pra download, etc.

    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.

Solução

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.

Octopress

No final do ano, por acaso, conheci o Octopress - um framework de blog baseado no Jekyll (um gerador estático de website).

Instalando

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.

Importando do Blogger

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.

Workflow

Agora meu workflow é simples:

  1. Criar o rascunho em .txt (na verdade em .markdown)
  2. Escrever e formatar ao mesmo tempo
  3. Dar uma conferida na formatação:
    • Quando tô no Mac, uso o app Marked
    • Independente de onde estou, dá pra usar rake generate && rake preview e visualizar o blog em localhost:4000
  4. rake generate
  5. rake deploy

How to build GStreamer from source

| Comments

This post shows how to build and install GStreamer from source. It targets building GStreamer for Mac OS X Lion. The procedure is quite similar if you want to build GStreamer for Linux.

The 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.

Pre-requisites

1
2
3
4
5
6
7
8
brew update
brew install gettext pkg-config glib

#autopoint is missing on Lion
PATH="$PATH:`brew --prefix gettext`/bin/"

#Required libs provided by homebrew
brew install libiconv libffi

Environment

1
2
3
4
5
BUILD_ROOT=~/gstreamer-src
BUILD_TARGET=~/gstreamer

mkdir $BUILD_TARGET
mkdir $BUILD_ROOT && cd $BUILD_ROOT

Getting the source

1
2
3
4
5
git clone git://anongit.freedesktop.org/gstreamer/gstreamer
git clone git://anongit.freedesktop.org/gstreamer/gst-plugins-base
git clone git://anongit.freedesktop.org/gstreamer/gst-plugins-good
git clone git://anongit.freedesktop.org/gstreamer/gst-plugins-bad
git clone git://anongit.freedesktop.org/gstreamer/qt-gstreamer

Building the base module (gstreamer)

1
2
3
4
5
6
7
8
9
10
11
12
cd $BUILD_ROOT/gstreamer

GST_CONFIG_PATH="`brew --prefix libiconv`/lib/pkgconfig:`brew --prefix libffi`/lib/pkgconfig:`brew --prefix gettext`/lib/pkgconfig"

./autogen.sh --noconfigure
./configure --disable-gtk-doc --disable-debug --with-pkg-config-path=$GST_CONFIG_PATH --prefix=$BUILD_TARGET

make
make install

# Required
GSTP_CONFIG_PATH="$BUILD_TARGET/lib/pkgconfig"

Building the plugin base module (gst-plugins-base)

1
2
3
4
5
6
7
8
9
10
11
12
13
# liborc support
# http://code.entropywave.com/projects/orc/
brew install orc

# Vorbis support
brew install libvorbis

cd "$BUILD_ROOT/gst-plugins-base"
./autogen.sh --noconfigure
./configure --disable-gtk-doc --disable-debug --with-pkg-config-path=$GSTP_CONFIG_PATH --prefix=$BUILD_TARGET

make
make install

Building the “good” plugins (gst-plugins-good)

1
2
3
4
5
6
cd "$BUILD_ROOT/gst-plugins-good"
./autogen.sh --noconfigure
./configure --disable-gtk-doc --disable-debug --disable-goom --disable-libpng --with-pkg-config-path=$GSTP_CONFIG_PATH --prefix=$BUILD_TARGET

make
make install

Building the “bad” plugind (gst-plugins-bad)

Note: osxvideosrc and qtwrapper are disabled because they use deprecated APIs (more info).

1
2
3
4
5
6
7
8
9
# dependencies
brew install rtmpdump libvpx libmms faac faad2

cd "$BUILD_ROOT/gst-plugins-bad"
./autogen.sh --noconfigure
./configure --disable-gtk-doc --disable-debug --disable-apexsink --with-pkg-config-path=$GSTP_CONFIG_PATH --prefix=$BUILD_TARGET

make
make install

Deploy automatizado de aplicações Rails com Capistrano e Github

| Comments

Nesse tutorial irei abordar a realização de deploy automatizado de uma aplicação Rails (3.0.X) utilizando o Github como repositório. A idéia é utilizar o capistrano para automatizar (e organizar) as tarefas de deployment. Para isso, irei criar um usuário no servidor que utilizará minha chave privada (cadastrada no Github) para fazer o deployment da aplicação.

Configurando o servidor

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

scp ~/.ssh/id_rsa.pub reinaldo@servidor:/home/reinaldo/my_key.pub
ssh reinaldo@servidor


No servidor

sudo adduser deploy
MY_PUBLIC_KEY=/home/reinaldo/my_key.pub
sudo mkdir -p /home/deploy/.ssh
sudo cat $MY_PUBLIC_KEY >> /home/deploy/.ssh/authorized_keys && rm $MY_PUBLIC_KEY
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod 700 /home/deploy/.ssh
sudo chown deploy:deploy -R /home/deploy


Configurando a aplicação

Adicione a gem capistrano no seu Gemfile
gem ‘capistrano’

Em seguida, no diretório da aplicação

bundle install
capify .
echo “.bundle\n” >> .gitignore


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

Realizando o Deploy


Depois disso, você poderá realizar seu deploy automático executando o comando:
cap deploy