Posts de August, 2008

[Jose Peleteiro] Installing CouchDB on Ubuntu 8

Wednesday, August 27th, 2008

Apache CouchDB is a very nice schema-free document-oriented database that I’m playing with lately.
Here’s a quick guide to get CouchDB running on Ubuntu 8:

Prepare your environment
sudo aptitude install automake autoconf libtool subversion-tools help2man spidermonkey-bin build-essential erlang erlang-manpages libicu38 libicu-dev libreadline5-dev checkinstall libmozjs-dev wget

Create a couchdb user
sudo adduser --no-create-home --disabled-password --disabled-login couchdb

Download and build the latests version
wget http://mirrors.uol.com.br/pub/apache/incubator/couchdb/0.8.1-incubating/apache-couchdb-0.8.1-incubating.tar.gz

tar -xzvf apache-couchdb-0.8.1-incubating.tar.gz

./configure --bindir=/usr/bin --sbindir=/usr/sbin --localstatedir=/var --sysconfdir=/etc

make

Install it
sudo make install

sudo chown couchdb:couchdb -R /var/lib/couchdb /var/log/couchdb

sudo update-rc.d couchdb defaults

Start the service
sudo /etc/init.d/couchdb start

CouchDB will be running on port 5984. By default it listens only for connections from the local host. To change that edit /etc/couchdb/couch.ini and restart CouchDB.

Sample code (Ruby):

#!/usr/bin/env ruby
 
# Setup
require "rubygems"
require "couchrest"
require "test/unit/assertions"
include Test::Unit::Assertions
 
# Database
couchdb = CouchRest.new("http://localhost:5984")
 
couchdb.database('helloworlds').delete! rescue nil
 
db = couchdb.create_db('helloworlds')
 
# Create
db.bulk_save([
  {"_id" => "en", "helloworld" => "Hello world"},
  {"_id" => "pt", "helloworld" => "Ola mundo"}
])
 
# Retrive
document = db.get("pt")
assert_equal "Ola mundo", document["helloworld"]
 
# Update
document["helloworld"] = "Olá mundo!!!"
db.save(document)
 
# Retrive again
assert_equal "Olá mundo!!!", db.get("pt")["helloworld"]
 
# Fails to delete, since variable msg is an only snapshot of the data
assert_raise(RestClient::RequestFailed) { db.delete(document) }
 
# But working with a last revision of the document
document_last_revision = db.get("pt")
 
assert_not_equal document["_rev"], document_last_revision["_rev"]
assert_nothing_raised { db.delete(document_last_revision) }
 
# Schema free
db.bulk_save([
  {"name" => "Maria Hernandes", "helloworld" => "Oi!"},
  {"name" => "John Wisky", "helloworld" => "Whatzup!", "age" => 24},
  {"helloworld" => "Duuuude!", "age" => 18, "country" => "Australia"},
  {"name" => "Peleteiro", "age" => 29, "country" => "Brazil", "helloworld" => "Olá"},
  {"helloworld" => "Hi guys", "name" => "Michel", "country" => "USA"}
])

[Bruno F. M. Souza] Comparando players de vídeos grátis e embutíveis

Wednesday, August 27th, 2008

Semana retrasada recebi um trabalho que consistia em ripar uns DVD`s, comprimir da forma mais eficiente possível levando em consideração um tamanho limite para o arquivo final , e posterior upload para algum site. No entanto, fiquei sem saber qual, dentre as diversas opções de free video hosting sites, seria o serviço com a melhor qualidade de vídeo e resolvi então analisar tecnicamente algumas das opções mais conhecidas:

player codec video bitrate
video (~kbps)
res frame
rate (fps)
codec audio bitrate
audio (~kbps)
size limit (MB) water
mark
api embed
Youtube h264 420 480×360 29.97 mpeg4-aac 112 500 S S S
Dailymotion vp6 700 640×480 29.97 mp3 96 150 N N S
Google sorenson 250 320×240 29.97 mp3 64 N N S
Revver vp6 400 480×360 29.97 mp3 64 100 N S S
Metacafe vp6 330 320×240 25 mp3 64 100 N N S
Vimeo vp6 460 504×380 29.97 mp3 112 500 N S S
Blip.tv vp6 500 15 mp3 80 1024 N S S
viddler vp6 410 29.97 mp3 64 500 S S S
Brightcove vp6 450 480×360 29.97 mp3 48 - N S S

Como pode ser visto, a presença ou não de marcas d`água, também foi um fator analisado, visto que ela degrada a aparência do vídeo, apesar de fortalecer o branding. Além da existência de API`s e da possibilidade de distribuir o conteúdo por outros sites (código embed).

Para esta análise, cadastrei o mesmo vídeo em todos esses sites, e acho que valem pequenos comentários em cima de alguns:

  • Tanto numa análise subjetiva, quanto numa objetiva, posso dizer que o Vimeo é o quem fornece o vídeo de maior qualidade. Com uma compressão bastante eficiente e um player leve, acabou sendo minha opção final. Seu ponto negativo ficou por conta da limitação semanal de 500MB para upload dos vídeos;
  • A aparência dos vídeos no Revver também é muito boa. Mas a limitação de 100MB por arquivo indicava a necessidade de taxas de compressão muito elevadas - os vídeos tinham mais de 1 hora, em média - o que acabaria prejudicando bastante o resultado final;
  • O Blip.tv torna-se uma excelente opção para vídeos com pouco movimento (ex. entrevistas). Isso porque seu baixo frame rate (15 fps) permite uma melhor alocação da banda disponível em cima de um número menor de quadros. No entanto, degrada bastante vídeos com muito movimento, apesar do elevado bitrate;
  • Google Video e Metacafe estão visivelmente mais focados na capacidade de escalar do que na qualidade do vídeo oferecido;
  • O Youtube com H.264 também seria uma boa opção, não fosse a presença da indesejável marca d`água, assim como o Viddler (embedded).

Por fim, mais parâmetros (mercadológicos) de análise em cima destes players e outros podem ser vistos aqui.

[Bruno F. M. Souza] Comparando players de vídeos grátis e embutíveis

Wednesday, August 27th, 2008

Semana retrasada recebi um trabalho que consistia em ripar uns DVD`s, comprimir da forma mais eficiente possível levando em consideração um tamanho limite para o arquivo final , e posterior upload para algum site. No entanto, fiquei sem saber qual, dentre as diversas opções de free video hosting sites, seria o serviço com a melhor qualidade de vídeo e resolvi então analisar tecnicamente algumas das opções mais conhecidas:

player codec video bitrate
video (~kbps)
res frame
rate (fps)
codec audio bitrate
audio (~kbps)
size limit (MB) water
mark
api embed
Youtube h264 420 480×360 29.97 mpeg4-aac 112 500 S S S
Dailymotion vp6 700 640×480 29.97 mp3 96 150 N N S
Google sorenson 250 320×240 29.97 mp3 64 N N S
Revver vp6 400 480×360 29.97 mp3 64 100 N S S
Metacafe vp6 330 320×240 25 mp3 64 100 N N S
Vimeo vp6 460 504×380 29.97 mp3 112 500 N S S
Blip.tv vp6 500 15 mp3 80 1024 N S S
viddler vp6 410 29.97 mp3 64 500 S S S
Brightcove vp6 450 480×360 29.97 mp3 48 - N S S

Como pode ser visto, a presença ou não de marcas d`água, também foi um fator analisado, visto que ela degrada a aparência do vídeo, apesar de fortalecer o branding. Além da existência de API`s e da possibilidade de distribuir o conteúdo por outros sites (código embed).

Para esta análise, cadastrei o mesmo vídeo em todos esses sites, e acho que valem pequenos comentários em cima de alguns:

  • Tanto numa análise subjetiva, quanto numa objetiva, posso dizer que o Vimeo é o quem fornece o vídeo de maior qualidade. Com uma compressão bastante eficiente e um player leve, acabou sendo minha opção final. Seu ponto negativo ficou por conta da limitação semanal de 500MB para upload dos vídeos;
  • A aparência dos vídeos no Revver também é muito boa. Mas a limitação de 100MB por arquivo indicava a necessidade de taxas de compressão muito elevadas - os vídeos tinham mais de 1 hora, em média - o que acabaria prejudicando bastante o resultado final;
  • O Blip.tv torna-se uma excelente opção para vídeos com pouco movimento (ex. entrevistas). Isso porque seu baixo frame rate (15 fps) permite uma melhor alocação da banda disponível em cima de um número menor de quadros. No entanto, degrada bastante vídeos com muito movimento, apesar do elevado bitrate;
  • Google Video e Metacafe estão visivelmente mais focados na capacidade de escalar do que na qualidade do vídeo oferecido;
  • O Youtube com H.264 também seria uma boa opção, não fosse a presença da indesejável marca d`água, assim como o Viddler (embedded).

Por fim, mais parâmetros (mercadológicos) de análise em cima destes players e outros podem ser vistos aqui.

[Bruno F. M. Souza] Compilando o MPlayer no Mac OS X (Leopard) com suporte a H.264 e AAC

Wednesday, August 27th, 2008

Depois de muito tempo perdido tentando resolver dependências impossíveis para compilar o mplayer/mencoder no Mac OS 10.5, descobri o MacPorts (desculpe a ignorância, tenho apenas 1 semana de mac) que, em conjunto com o time de desenvolvimento do MPlayer, tornou minha tarefa bem mais fácil…

Resolvi então escrever este howto para que outros também possam economizar na vaselina.

Preparando o ambiente

  1. Para compilar qualquer coisa no OS X, é necessário ter instalado o Xcode (Developer Tools). Trata-se de um conjunto de ferramentas para desenvolvimeno de software no Mac OS X. O mesmo pode ser obtido aqui;
  2. As dependências do MPlayer são facilmente resolvidas através do MacPorts. Derivado do sistema ports do freebsd, ele baixa o código fonte, aplica os patches, compila e instala automaticamente os pacotes requisitados. Para instalá-lo, basta seguir os passos descritos aqui.
  3. Ao final, vale chamar o seguinte comando para sincronizar a instalação:
sudo port -v selfupdate

Instalando dependências

  1. Inicialmente, resolvemos dependências básicas relacionadas ao encontro de determinadas bibliotecas, possibilidade de fontes para legendas, bibliotecas de compressão, etc:
  2. sudo port install subversion pkgconfig freetype fontconfig libiconv \
    ncurses zlib lzo2
  3. Então, instalamos os codecs que o mplayer e o mencoder devem suportar:
  4. sudo port install xvid x264 lame libtheora libmad faac twolame libdts \
    libdv jpeg libpng libungif

Compilando

  1. Primeiro, baixamos o source para o diretório atual:
  2. svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer
  3. Em seguida, configuramos os parâmetros de compilação:
  4. cd mplayer
    export PKG_CONFIG_PATH="/opt/local/lib/pkgconfig"
    ./configure --with-extraincdir=/opt/local/include \
    --with-extralibdir=/opt/local/lib --prefix=/opt/mplayer

    Basicamente, estamos direcionando os executáveis gerados para “/opt/mplayer”, além de passar uma referência ao encontro de bibliotecas de codecs que venham ser utilizados (Win32, RealPlayer, etc). Vale lembrar que é justamente aqui que ganhamos flexibilidade ao habilitar apenas as features realmente necessárias e/ou as que visam otimizar a nossa aplicação.

  5. Então, compilamos o fonte baixado (isso leva um bom tempo), e instalamos:
make && make install

Ajustes finais

  1. Por fim, editamos a variável bash do PATH no .profile e o recarrecamos. Isso, para que o terminal possa encontrar os executáveis gerados:
  2. echo "export PATH=\"$PATH:/opt/mplayer/bin\"" >> ~/.profile
    source ~/.profile

Pronto!

[Bruno F. M. Souza] Compilando o MPlayer no Mac OS X (Leopard) com suporte a H.264 e AAC

Wednesday, August 27th, 2008

Depois de muito tempo perdido tentando resolver dependências impossíveis para compilar o mplayer/mencoder no Mac OS 10.5, descobri o MacPorts (desculpe a ignorância, tenho apenas 1 semana de mac) que, em conjunto com o time de desenvolvimento do MPlayer, tornou minha tarefa bem mais fácil…

Resolvi então escrever este howto para que outros também possam economizar na vaselina.

Preparando o ambiente

  1. Para compilar qualquer coisa no OS X, é necessário ter instalado o Xcode (Developer Tools). Trata-se de um conjunto de ferramentas para desenvolvimeno de software no Mac OS X. O mesmo pode ser obtido aqui;
  2. As dependências do MPlayer são facilmente resolvidas através do MacPorts. Derivado do sistema ports do freebsd, ele baixa o código fonte, aplica os patches, compila e instala automaticamente os pacotes requisitados. Para instalá-lo, basta seguir os passos descritos aqui.
  3. Ao final, vale chamar o seguinte comando para sincronizar a instalação:
sudo port -v selfupdate

Instalando dependências

  1. Inicialmente, resolvemos dependências básicas relacionadas ao encontro de determinadas bibliotecas, possibilidade de fontes para legendas, bibliotecas de compressão, etc:
  2. sudo port install subversion pkgconfig freetype fontconfig libiconv \
    ncurses zlib lzo2
  3. Então, instalamos os codecs que o mplayer e o mencoder devem suportar:
  4. sudo port install xvid x264 lame libtheora libmad faac twolame libdts \
    libdv jpeg libpng libungif

Compilando

  1. Primeiro, baixamos o source para o diretório atual:
  2. svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer
  3. Em seguida, configuramos os parâmetros de compilação:
  4. cd mplayer
    export PKG_CONFIG_PATH="/opt/local/lib/pkgconfig"
    ./configure --with-extraincdir=/opt/local/include \
    --with-extralibdir=/opt/local/lib --prefix=/opt/mplayer

    Basicamente, estamos direcionando os executáveis gerados para “/opt/mplayer”, além de passar uma referência ao encontro de bibliotecas de codecs que venham ser utilizados (Win32, RealPlayer, etc). Vale lembrar que é justamente aqui que ganhamos flexibilidade ao habilitar apenas as features realmente necessárias e/ou as que visam otimizar a nossa aplicação.

  5. Então, compilamos o fonte baixado (isso leva um bom tempo), e instalamos:
make && make install

Ajustes finais

  1. Por fim, editamos a variável bash do PATH no .profile e o recarrecamos. Isso, para que o terminal possa encontrar os executáveis gerados:
  2. echo "export PATH=\"$PATH:/opt/mplayer/bin\"" >> ~/.profile
    source ~/.profile

Pronto!

[Danilo Bardusco] XII Mostra PUC-Rio

Thursday, August 21st, 2008

Ontem estive na PUC rio para falar de Scrum e apresentar aos alunos como é o ambiente de desenvolvimento de software na globo.com.

A Mostra PUC-Rio acontece entre os dias 19 e 22 de agosto, com o tema “Os desafios da Inclusão do Conhecimento numa Economia Globalizada”.

os slides da minha apresentacão estão aqui:

[Anselmo Alves] Mudando as regras do jogo

Monday, August 4th, 2008

Quantos daily meetings deve haver por sprint? Este trecho retirado do livro Agile Project Management with Scrum sugere que deve haver um daily meeting por dia de sprint.

The Team members have two administrative responsibilities during the Sprint: they are to attend the Daily Scrum meeting, and they are to keep the Sprint Backlog up-to-date and available in a public folder on a public server, visible to all.

Além do mais, o diagrama abaixo indica que deve haver daily meeting apenas em dias de sprint:
scrum
O que acontece é que no último dia do sprint podem ainda existir estórias não finalizadas. Para que todas elas sejam colocadas no status done, alguns times costumam fazer um daily meeting extra no dia seguinte ao fim do sprint.

O ideal no Scrum é não iniciar uma estória enquanto outra ainda está em andamento - fazer item por item. Por outro lado, cada membro do time tem sua especialidade e pode escolher que tarefa irá fazer. Talvez um determinado membro queira assumir uma tarefa de uma outra estória que não a que está sendo trabalhada no momento, pulando tarefas da estória atual e quebrando assim essa regra. Qual é a coisa certa a fazer neste caso?

O que essas duas questões têm em comum? Ambas exploram as características empíricas e adaptivas do Scrum. Mas até que ponto as regras podem ser mudadas?

If someone wants to change the rules, use the Sprint retrospective meeting as a forum for discussion. Rule changes should originate from the Team, not management. Rule changes should be entertained if and only if the ScrumMaster is convinced that the Team and everyone involved understands how Scrum works in enough depth that they will be skillful and mindful in changing the rules. No rules can be changed until the ScrumMaster has determined that this state has been reached.

Eu acredito muito no que diz este trecho desse mesmo livro. Ele sugere que as regras podem ser livremente mudadas, desde que o desejo parta do time e que o time já entenda bem o processo. Isso serve para garantir, entre outras coisas, que mudanças nas regras não engessem o processo. Além disso, ao meu ver, quando o time já tem no sangue os princípios ágeis, dificilmente uma mudança representará um retrocesso. Somente quando o time atinge esse grau de maturidade, adaptações às regras podem e devem ser feitas.

[Claudio Figueiredo] Thought of the Day

Friday, August 1st, 2008

Isn’t loopback a redundancy?

If it’s a loop wouldn’t it be back anyway? :)