Hugo Doria: Introdução ao mercurial: aprendendo com o HnTool
18 de Maio de 2010, 0:00 - sem comentários aindaControle de versão é algo muito importante para os desenvolvedores. Infelizmente, muita gente ainda desconhece ou ignora a existência desses sistemas e trabalha de forma amadora. Há alguns dias atrás, por exemplo, conheci uma empresa que usava arquivos .zip, criados pelos próprios funcionários e sem nenhum padrão, para fazer o controle de versão.
Meu primeiro contato de verdade (algo mais complexo que update e commit) com um controle de versão foi no Arch Linux, com o svn e o git. Com o HnTool cheguei a utilizar alguns dos principais sistemas (svn, git, bazaar) até chegar ao atual, o mercurial.
Notei que algumas das pessoas que estão tentando contribuir com o HnTool desconhecem, ou estão tendo dificuldades com o Mercurial. Sabendo disso, resolvi fazer este pequeno guia introdutório a ferramenta, que pode ser de grande ajuda para os novatos.
Primeiros passos
O primeiro passo a ser dado é clonar o repositório, que é basicamente baixar todo o código que está sob o controle de versão:
$ hg clone https://hntool.googlecode.com/hg/ hntool
Ao clonar um repositório você verá uma saída parecida com essa:
requesting all changesadding changesetsadding manifestsadding file changesadded 172 changesets with 289 changes to 61 files (+1 heads)updating to branch default29 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd hntool/$ ls -a.hg AUTHORS doc hntool HnTool LICENSE NEWS po README setup.py TODO
Obtendo informações sobre o repositório
$ hg parents
A saída será parecida com essa:
changeset: 171:094fbddeb14d
tag: tip
parent: 169:4fd6ed215b13
parent: 170:7c24fb8c6685
user: Hugo Doria
date: Mon Apr 26 23:48:27 2010 -0300
summary: merging apache changes
Uma outra forma de obter informações sobre o último changeset é usando o tip:
$ hg tip
changeset: 171:094fbddeb14d
tag: tip
parent: 169:4fd6ed215b13
parent: 170:7c24fb8c6685
user: Hugo Doria
date: Mon Apr 26 23:48:27 2010 -0300
summary: merging apache changes
Se você quer saber o histórico das mudanças feitas no repositório use:
$ hg log
Exemplo de saída:
changeset: 171:094fbddeb14d
tag: tip
parent: 169:4fd6ed215b13
parent: 170:7c24fb8c6685
user: Hugo Doria
date: Mon Apr 26 23:48:27 2010 -0300
summary: merging apache changeschangeset: 170:7c24fb8c6685
parent: 166:56647cd76822
user: Filipe Rosset
date: Sun Apr 25 22:14:06 2010 -0300
summary: Fix ServerSignature commentschangeset: 169:4fd6ed215b13
user: Hugo Doria
date: Mon Apr 26 23:45:09 2010 -0300
summary: Checking the delay between failed login prompts
Cada grupo desse é referente a um changeset, que nada mais é que a mudança de um ou mais arquivos, agrupadas em uma unidade lógica. No caso acima existem três changesets. Entender cada campo do changeset é fácil:
- changeset: esse campo é composto por duas partes, separadas por um ":". A primeira das partes é o número da revisão, um identificador do changeset. A segunda parte é um hexadecimal referente ao ID do changeset.
- parent: esse campo geralmente aparece quando você faz um merge no repositório e identifica todos os changesets relacionados com ele.
- user: a pessoa que criou o changeset.
- date: a data que o changeset foi criado. Esta data é referente a timezone do criador do changeset.
- summary: é a descrição do changeset. Essa mensagem é passada na hora do commit.
Sabendo clonar o repositório e lidar com o histórico de mudanças já da para começar a fazer suas próprias modificações.
Modificando o código
Uma prática recomendada antes de fazer qualquer mudança é criar um novo repositório para isolar as mudanças que irá fazer. Isso previne que você misture código que está sendo testado com seu código real, permite que você teste certas partes do código, trabalhe em diversas tarefas ao mesmo (todas isoladas) etc.
Para criar um novo repositório e isolar nosso código é preciso clonar o atual. Dessa vez não vamos clonar o repositório remoto, mas sim o local. Sim, um clone do clone:
$ cd ../
$ hg clone hntool novo-hntool
updating to branch default
31 files updated, 0 files merged, 0 files removed, 0 files unresolved$ cd novo-hntool
Agora podemos fazer nossas mudanças. Vamos, por exemplo adicionar um novo teste ao módulo ftp:
# Checking if we chroot users into the ftp users' home directory if 'DefaultRoot' in lines: if lines['DefaultRoot'] != '~': check_results['medium'].append('ProFTPd does not chroot users') elif lines['DefaultRoot'] != '~': check_results['ok'].append('ProFTPd chroot users') else: check_results['medium'].append('ProFTPd does not chroot users')
Salve suas mudanças. Agora rode o comando abaixo:
$ hg status
M HnTool/modules/ftp.py
Este comando diz o que há de novo no seu repositório. É através dele que o mercurial diz o que sabe sobre seus arquivos. Se a linha começa com "M", então o mercurial está dizendo que aquele arquivo foi modificado. Seguem alguns possíveis status:
- M NEWS : o arquivo NEWS foi modificado
- ? NEWS : o arquivo NEWS é desconhecido pelo mercurial
- A NEWS : o arquivo NEWS será adicionado ao mercurial
- R NEWS : o arquivo NEWS será removido do mercurial
Além de saber que aquele arquivo foi modificado, também podemos saber quais foram as mudanças. Para isso é só usar o diff do mercurial:
$ hg diff
diff -r a7375e5e4599 HnTool/modules/ftp.py
--- a/HnTool/modules/ftp.py Mon May 17 21:13:35 2010 -0300
+++ b/HnTool/modules/ftp.py Mon May 17 21:33:15 2010 -0300@@ -81,7 +81,16 @@
else:
check_results['ok'].append('ProFTPd allows footprinting')
+ # Checking if we chroot users into the ftp users' home directory
+ if 'DefaultRoot' in lines:
+ if lines['DefaultRoot'] != '~':
+ check_results['medium'].append('ProFTPd does not chroot users')
+ elif lines['DefaultRoot'] != '~':
+ check_results['ok'].append('ProFTPd chroot users')
+ else:
+ check_results['medium'].append('ProFTPd does not chroot users')
+
if not proftpd_conf_file_found:
check_results['info'].append('Could not find a proftpd.conf file')
- return check_results\ No newline at end of file
+ return check_results
Apesar de você já poder visualizar suas mudanças, elas ainda não foram armazenadas de fato. Para confirmar suas mudanças você precisa fazer o commit:
$ hg commit
Ao chamar o commit o mercurial te leva a um editor de texto para que você possa escrever uma mensagem descrevendo o commit. Além de escrever a mensagem você também pode ver mais algumas informações deste commit.
Adding a new test on ftp module
HG: Enter commit message. Lines beginning with 'HG:' are removed.
HG: Leave message empty to abort commit.
HG: --
HG: user: Hugo Doria
HG: branch 'default'
HG: changed HnTool/modules/ftp.py
Se preferir, você pode fazer o commit e passar a mensagem no mesmo comando usando a opção "-m":
$ hg commit -m "Adding a new test on ftp module"
O resultado é o mesmo. Lembre-se que esta mensagem passada no commit ficará armazenada no log (hg log), então tente escrever uma mensagem curta, porém esclarecedora. Caso você deixe a mensagem em branco o commit será abortado.
Se você rodar o "hg status" agora verá que não há nada com um status diferente:
$ hg status
Isso acontece porque suas mudanças já foram "comitadas".
Compartilhando as mudanças
Como dito anteriormente, os repositórios "hntool" e "novo-hntool" são isolados e independentes. Por causa disso, as mudanças que acabamos de fazer só foram aplicadas ao "novo-hntool", que não é nosso repositório "principal".
Temos algumas maneiras de fazer com que as mudanças feitas sejam propagadas em outros repositórios. Para fazer os testes vamos criar um novo clone (sim, mais um) do repositório principal, aquele que não foi modificado:
$ cd ..
$ hg clone hntool hntool-compartilhado
updating to branch default
31 files updated, 0 files merged, 0 files removed, 0 files unresolved$ cd hntool-compartilhado
Com o comando pull podemos baixar todas as mudanças que estão em outro repositório, seja ele local, ou não. Porém, antes de fazer isso é bom saber quais as mudanças que serão baixadas ao rodar o pull. Para isso faça:
$ hg incoming ../novo-hntool
comparing with ../novo-hntool/
searching for changes
changeset: 202:52926d72b9e2
tag: tip
user: Hugo Doria
date: Mon May 17 21:45:21 2010 -0300
summary: Adding a new test on ftp module
Nesse caso ele só vai baixar uma mudança, que é exatamente a que fizemos anteriormente. Agora sim podemos rodar o pull sem medo:
$ hg pull ../novo-hntool
pulling from ../novo-hntool/
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
No caso acima baixamos as mudanças no repositório "novo-hntool", mas poderíamos baixar de um repositório remoto, por exemplo.
Apesar do comando pull ter trazido todas as mudanças para o atual repositório, elas ainda não foram aplicadas. Para aplicá-las de verdade é preciso rodar o comando update:
$ hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
Achou estranho o comando pull não atualizar de verdade os arquivos? Não se preocupe, eu também achei no começo. Mas no livro do mercurial há uma boa explicação para isso:
Quando rodamos o "pull", o mercurial só atualiza o diretório ".hg", aquele que possui os metadados do projeto, o histórico de revisões etc. Depois disso, o "update" aplica nos seus dados reais (sua cópia de trabalho) as mudanças que estão apenas nos metadados .
Rodar o pull e logo depois o update é algo bem comum no mercurial. Para facilitar a vida existe um atalho para fazer as duas operações ao mesmo tempo:
$ hg -u pull
Além de poder baixar as atualizações para um determinado repositório, também podemos enviá-las para outro repositório. Para isso usamos o comando push.
Assim como fizemos no passo anterior vamos clonar o nosso repositório principal:
$ cd ..
$ hg clone hntool hntool-push
updating to branch default
31 files updated, 0 files merged, 0 files removed, 0 files unresolved$ cd novo-hntool
Nós queremos enviar as mudanças feitas no "novo-hntool" para o "hntool-push". Antes, porém, vamos ver quais as mudanças que seriam enviadas:
$ hg outgoing ../hntool-push/
comparing with ../hntool-push/
searching for changes
changeset: 202:52926d72b9e2
tag: tip
user: Hugo Doria
date: Mon May 17 21:45:21 2010 -0300
summary: Adding a new test on ftp module
Confirmando que é isso mesmo que queremos, é só rodar o comando push:
$ hg push ../hntool-push/
pushing to ../hntool-push/
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
Da mesma forma que acontece com o pull, também é preciso entrar no repositório hntool-push e rodar o update.
Quando não passamos o local para onde queremos realizar o push (ou pull), o mercurial assume o endereço padrão, que fica no arquivo .hg/hgrc, dentro do diretório do repositório. Por exemplo:
$ cat .hg/hgrc
[paths]
default = /meu/diretorio/hntool
Refertendo mudanças
Vamos supor que fizemos um mudança errada:
$ echo "lixo total" >> NEWs
Ao rodar o comando "hg status" veremos que o mercurial já reconheceu nossa mudança:
$ hg status
M NEWS
Esta mudança não é desejada. Felizmente, é muito fácil desfazê-la:
$ hg revert NEWS
$ hg status
? NEWS.orig
O que o mercurial fez foi reverter as mudanças do arquivo NEWS, deixando-o exatamente como era no último commit válido. Além disso, ele criou um arquivo NEWS.orig, que possui as mudanças erradas que fizemos. O NEWS.orig não está sob o controle do mercurial ainda. Por isso a "?" antes do seu nome. Se quiser, pode removê-lo.
Se você não especificar qual o arquivo que desejar reverter as mudanças, o mercurial irá reverter de todos os arquivos.
Alguém pode perguntar: mas e se eu já tivesse feito o commit? Mesmo assim daria para reverter? E a resposta é: sim, daria. Vamos a um exemplo:
Fazendo a mudança errada e o commit:
echo "novo lixo total" >> NEWS^C
$ hg status
M NEWS
$ hg commit -m "commit de lixo"
$ hg status
Como você ver a mudança foi confirmada. Para revertê-la podemos usar o rollback:
$ hg rollback
rolling back last transaction$ hg status
M NEWS
No caso, o mercurial desfez o commit. Entretanto, as mudanças feitas no arquivo NEWS ainda estão lá. Se quiser desfazer de vez será preciso rodar o revert novamente:
$ hg revert NEWS
$ hg status
? NEWS.orig
Adicionando e removendo arquivos
Quando criamos um novo arquivo na nossa cópia de trabalho ele não é reconhecido pelo mercurial. Por isso que ao rodar o comando "hg status" vemos um simbolo de "?" na frente do arquivo. Por exemplo:
$ > novoarquivo
$ hg status
? novoarquivo
Para que o mercurial reconheça este arquivo é preciso adicioná-lo ao repositório. Faça isso com:
$ hg add arquivo
Por exemplo:
$ hg add novoarquivo
$ hg status
A novoarquivo
Notem o "A" na frente do novo do arquivo. Isso significa que ele será adicionado ao nosso repositório no próximo commit.
Para remover um arquivo é só fazer:
$ hg remove arquivo
Por exemplo:
$ hg remove NEWS
$ hg status
A novoarquivo
R NEWS
O "R" na frente do arquivo significa que ele será removido do repositório no próximo commit.
Criando patches
Lembra que usando o comando "hg diff" é possível saber quais as mudanças que aconteceram nos arquivos? Com o mercurial também é possível gerar patches já formatados para ele. Para isso vamos usar o comando "export":
$ hg export NUMERO-DA-REVISAO
Por exemplo:
$ hg export 120
# HG changeset patch
# User Hugo Doria
# Date 1269294101 10800
# Node ID a945d6adad28ec20a81de9899e14d1edfa93cee9
# Parent 1bb54f09298ac7adebcc8ea992db24bfe16efcf5
Sorting the output by module alphabetical orderdiff -r 1bb54f09298a -r a945d6adad28 hntool
--- a/hntool Mon Mar 22 18:32:36 2010 -0300
+++ b/hntool Mon Mar 22 18:41:41 2010 -0300
@@ -108,7 +108,7 @@
# Run all the modules and its checks.
# The results of each module goes to "report"
report = []
-for m in rule_modules:
+for m in sorted(rule_modules):
report.append({'title': rule_modules[m].long_name(), \
'results': rule_modules[m].analyze(options)})
Para gerar um patch do último commit, por exemplo:
$ hg export tip
Se preferir é só jogar o output para um arquivo:
$ hg export tip > consertando-o-bug-115.patch
NOTA: Eu vou continuar atualizando este guia de acordo com as necessidades que for encontrando na hora de gerenciar o repositório do HnTool. Se for tiver alguma dúvida ou sugestão é só avisar.
Referências:
Essas e várias outras informações podem ser encontradas nos links abaixo:
- Mercurial book: http://hgbook.red-bean.com
- Hg Init: http://hginit.com/
- Mercurial Tutorial: http://mercurial.selenic.com/wiki/Tutorial
Gustavo Noronha (kov): Inacreditável, mas continua lá.
17 de Maio de 2010, 0:00 - sem comentários aindaLembra daquele cabo pendurado na minha rua? Pois é… nem mandar mensagem pra ouvidoria, nem passar o protocolo pra alguém falar com “conhecidos” na CEMIG parece ter ajudado. Já passou mais quase um mês e o cabo, apesar de alguém ter cortado um pedaço pra não ficar caído até a calçada, continua lá. Sugestões? =)
Leonardo Ferreira Fontenelle: Usando o Tiny Tiny RSS no lugar do Google Reader
17 de Maio de 2010, 0:00 - sem comentários aindaAlgum tempo atrás eu testei e aprovei o Bloglines como agregador online de feeds, após ter ficado preocupado com a política de privacidade do Google. Mas existe uma coisa muito positiva em escrever blogs, que é receber o comentário dos leitores. E os leitores do artigo em inglês me alertaram para o fato de que o Bloglines (1) não está mais sendo desenvolvido há anos; e (2) é outro serviço fornecido por terceiros, e portanto potencialmente passível dos mesmos problemas de privacidade do Google. E mais ainda, os leitores me recomendaram uma opção: o Tiny Tiny RSS, ou tt-rss para os íntimos.
Fonte: Tiny Tiny RSS (divulgação)
Até existe um servidor Tiny Tiny RSS para uso do público geral, mas ele não está aceitando novos usuários. De qualquer forma, um dos diferenciais do Tiny Tiny RSS é a possibilidade de instalar no próprio computador (local ou remoto), como no caso do Piwik. Não conheço qualquer serviço de hospedagem que facilite a instalação do aplicativo, então o negócio é usar a linha de comando. Da mesma forma que em outros aplicativos online, é necessário descompactar um arquivo dentro do diretório correspondendo ao URL onde você pretende acessar o Tiny Tiny RSS, e então criar um banco de dados MySQL ou PostgreSQL. A diferença é que o próprio tt-rss não é capaz de criar, no banco de dados, a estrutura de tabelas necessária. O usuário precisa fazer isso sozinho a partir de um arquivo de esquema distribuído junto do aplicativo.
Também é necessário editar à mão o arquivo de configuração, que é um pouco maior que o do WordPress. Existem duas possibilidades de atualização dos feeds no Tiny Tiny RSS: ele pode rodar como um daemon, ou pode atualizar periodicamente a partir de um cronjob. A DreamHost e, imagino, outros serviços de hospedagem compartilhada não permitem daemons de usuários, então no meu caso foi necessário configurar um cronjob. A maior dificuldade que tive na instalação foi a incompatibilidade do Tiny Tiny RSS com o PHP4. Essa incompatibilidade foi contornada seguindo as instruções oficiais, mas de qualquer forma em breve a DreamHost vai tornar o PHP5 a versão padrão.
Uma vez instalado, o Tiny Tiny RSS tem um conjunto de recursos semelhantes ao dos outros leitores online, exceto naturalmente pelo Google Buzz (leia também: Google Buzz pode ofender a privacidade dos usuários). Não pude avaliar adequadamente os recursos de interação entre usuários, porque optei por uma instalação em modo monousuário. Sei pelo menos que é possível selecionar artigos lidos para constar num feed gerado pelo usuário, e naturalmente outros usuários podem assinar esse feed.
Assim como o Bloglines e o Google Reader, o Tiny Tiny RSS não precisa carregar os feeds na hora em que o usuário resolve abrir o aplicativo. Se você instalar ele num computador remoto, como eu fiz, ele não vai responder aos pequenos comandos tão prontamente quanto os aplicativos instalados localmente, mas isso também vale para o Google Reader e para o Bloglines. A ideia de instalar o Tiny Tiny RSS num computador doméstico e deixá-lo rodando o tempo todo é atraente, e eu já fiz esse tipo de coisa, mas parei para economizar energia elétrica.
Para ser sincero, o Tiny Tiny RSS ainda pode amadurecer muito, por exemplo com instalação automatizada do esquema no banco de dados ou atualização automática, mas mesmo assim já é altamente usável. Por algum motivo obscuro, é o primeiro aplicativo online cujos comandos com o teclado eu me dispus a aprender; em geral, só uso o mouse. Nos aplicativos tradicionais é o contrário, uso o teclado sempre que possível.
O maior problema do Tiny Tiny RSS é que a maioria das pessoas não se diverte nem um pouco instalando aplicativos em computadores remotos. Mas acho interessante a ideia de escolas, empresas ou outras organizações terem instalações próprias do Tiny Tiny RSS, em que usuários tenham algo em comum e portanto tenham mais motivos para compartilhar artigos ou feeds interessantes. Outra possibilidade intrigante seria usar uma instalação do Tiny Tiny RSS como um servidor público, possivelmente monetizado através de anúncios. O difícil seria oferecer um diferencial, num mercado tão acirrado.
Por fim, eu gostaria de mencionar que, enquanto escrevia este artigo, fiquei sabendo do Gregarious, que tem a mesma proposta do Tiny Tiny RSS: um agregador de feeds em software livre, que a pessoa pode instalar em seu próprio computador (local ou remoto). Ao contrário do tt-rss, no entanto, o Gregarious parece não estar mais sendo desenvolvido: a última alteração do código-fonte foi realizada há um ano e meio.
Jonh Wendell: ENSOL 2010
11 de Maio de 2010, 0:00 - sem comentários ainda
Oi gente. Final de semana passado rolou o IV ENSOL, lá em João Pessoa – PB. A turma da organização está de parabéns. O evento foi show de bola.
Chegamos na quinta no começo da noite; peguei uma carona com o Marcelo Santana, de Recife até Jampa. Viajar com o Marcelão a noite: Modo adrenalina ON! Altas aventuras. Não recomendado para quem sofre de problemas cardíacos. Encontramos o Fernandes no hotel e de lá seguimos junto com outra turma de palestrantes para um rodízio de camarão. Nunca comi tanto camarão na minha vida hehehehe.
Na sexta rolou minha palestra sobre GNOME e GNOME Foundation. Foi muito legal, sala cheia, muitas perguntas, inclusive algumas tendendo para o troll GNOME x KDE ou GNOME copiando Mac OS.
A noite fomos a um rodízio básico de pizza, perto do hotel.
No sábado rolou a palestra do Fernandes, sobre tradução do GNOME. Vi que a turma se interessou bastante pelo tema, vamos ver se pinta algum tradutor novo por aí.
Fernandes falando sobre tradução
A noite rolou uma festa no “John People” (ainda acho que deveria ser “John Person” hehe). Outro rodízio, dessa vez de petiscos. Saí cedo (por volta de meia noite) porque tinha que acordar as 5h da manhã pra voltar a tempo do almoço do dia das mães (E consegui!)
O evento ainda rolou no domingo, GNOME teve mais uma palestra com a Izabel falando sobre mulheres no GNOME.
Considerações gerais:
- Como sempre, muito bom rever e fazer amigos. Dessa vez, tive o prazer de conhecer Fernandes Neto, que apareceu devagarzinho e traduziu boa parte do GNOME 2.30. Também revi o Marcelo Santana (Debian Brasil) e o Rodrigo Padula. Rodrigo que está entrando na nossa turma pra ajudar na divulgação do GNOME! Marcelo rendeu altas risadas com seu jeito “delicado” de ser hahahaha.
- João Pessoa é a cidade dos brutos. Cara, todo dia a gente levava “um fora” de algum paraibano. Isso rendeu altas risadas. Depois a gente entrou no clima deles também!
- Evento dia de domingo não rola. Ainda mais no domingo dia das mães. Esse foi o único ponto fraco do ENSOL.
- Não deu pra passear, conhecer mais a cidade, devido a correria na volta por causa do dia das mães. Fica pra próxima.
- Tivemos uma variedade de cores nas camisas show de bola. Vejam as fotos para ficarem com inveja!
- O local do evento é simplesmente lindo. Arquitetura fantástica. Também, Niemeyer né?
- Fotos: http://www.flickr.com/photos/jwendell/tags/ensol/
- Slides das palestras: http://br.gnome.org/GNOMEBR/Apresentacoes
É isso aí, adorei o ENSOL e espero poder participar ano que vem!
Lucas Rocha: Hubbard’s Straight Life
10 de Maio de 2010, 0:00 - Um comentário
Freddie Hubbard by Brian McMillen (CC-BY-SA)
Freddie Hubbard is one of my favourite jazzists. Surely one of the greatest jazz trumpeters of all times. He recorded albums as a leader and sideman with many of the greatest: John Coltrane, Herbie Hancock, Art Blakey, Joe Henderson, Wayne Shorter, Ornette Coleman, Woody Shaw, and many others. He has a furious and groovy sound. A style that can actually be seen in the way he plays (see the photo above). He became more popular during the 1970s with a series of albums recorded for CTI Records including a sort of trilogy of funk-influenced hard bop albums: Red Clay, First Flight, and Straight Life. The last one is quite special to me.
I bought a Straight Life CD back in 2007 when I was still living in Finland. As I mentioned in a previous post, I found a very nice record shop in Helsinki – close to Kamppi - and I used to go there every other weekend to pick new albums more or less randomly. Straight Life was the first-ever Hubbard album I tried. I became a fan almost instantly!
The personel is full of stars: Joe Henderson (Sax), Herbie Hancock (Electric Piano), Ron Carter (Bass), Jack DeJohnette (Drums), George Benson (Guitar), Richard Landrum (Percussion), and Weldon Irvine (Tabla/Tambourine). The album has three tracks: Straight Life, Mr. Clean, and “Here’s That Rainy Day”. The order of the tracks is an exact match on my personal rank. Straight Life is an amazing 17 minute (!) performance. Mr. Clean is a nice medium tempo funky tune. “Here’s That Rainy Day” is a ballad – but Hubbard is not good with ballads in my opinion. I love this album mostly because of the track that names the album.
Hubbard starts Straight Life with some fast arpeggios alternated with DeJohnette’s drumming. It’s like a musical greeting. Makes you curious about what’s to come. Then Hubbard starts the theme and the band follows. The rhythm is hard to explain. It’s a bit amorphous and very rich in complexity. It’s some sort of afro-latin thing. It’s interesting how the soloists make such a complex rhythm sound so natural. The solos by Henderson and Hubbard are my favourite. This was the first time I heard Henderson playing. The great moment of his solo is when he plays the theme in a different scale on top of an unexpected harmony played by Hancock. Hubbard starts his solo with a very soft sound and then moves on to a faster and high-pitched solo.
Straight Life (the album) introduced me to Freddie Hubbard and Joe Henderson at their best and I’ve been enjoying their albums a lot since then. This album is definitely in my top 10 list. You can read reviews of this album at AllAboutJazz, BBC, and Jazzbo Notes. See also this video of Hubbard performing Straight Life. Enjoy!
Lucas Rocha: Uncluttering
8 de Maio de 2010, 0:00 - sem comentários ainda
Keukenhof
Since the end of last year, I started a gradual process of uncluttering my online life in order to waste less time on distractions and get more focused on the stuff that I really care about at the moment. Here’s what (and how) I managed to do so far in this regard.
No e-mail auto-archiving anymore. When you add filters to auto-archive your e-mails into folders, you’re basically creating a situation where it’s ok to receive email you often don’t care about. I decided to auto-tag e-mail but not to auto-archive them anymore. This way I can have a clear sense of the amount of the e-mail I’m getting everyday – as they don’t auto-hide somewhere – and what mailing lists are just a waste of time.
Unsubscribed from most of mailing lists. It’s impressive how much time you waste on just skimming through a massive number of mailing list e-mails, just to feel that you’re keeping track of what’s going on. I decided to only keep subscription on mailing lists that I really care about. The no-auto-archiving approach helped a lot in recognizing the unwanted e-mails. Result: unsubscribed from 30+ mailing lists.
Unsubscribed from most of social web groups. Especially the Facebook ones. I rarely use them anyway. So, no need to keep any participation. Result: unsubscribed from 15+ groups.
Not using feed reader anymore. Ok, this one may sound a bit silly. For some reason, feed readers give me the feeling that there’s always unread stuff to be seen – and end up having a look at it too often. Also, it brings me this sort of illusion that you can read much more content than I actually can. So, I decided to simply bookmark my favourite websites (around 30) and access them whenever I feel like it. In practice, I visit only 8-10 of those everyday. The other 20 are visited at random times.
Not following too many microbloggers. I try to follow a maximum of 100-ish people on Twitter and Identi.ca. Following more than that would make me feel like I’m always missing something and checking out what’s new too often. Nowadays, I read the new entries every time I post something which is healthy frequency.
Avoiding redundant content. There’s a lot of redundant content out there. Very often the same news is published in different forms in several websites. In that case, I just chose the websites which in my opinion have higher content quality. Furthermore, sometimes just following someone on Twitter or Identi.ca is enough to get access to all new stuff coming from them as they microblog about their new blog posts, photos, videos, etc, anyway. In that case, there’s no need to subscribe to their blog feed and follow them on Twitter, for example.
There’s so much content you can get from the net nowadays that it’s quite easy to fall in the trap of thinking that you are able to consume it all. But that’s obviously an silly thought. I decided to focus on what I find relevant now and ignoring the rest as much as I can. And I’m saving some precious time for other things I care about. I may ended up deciding to expand the amount of content to read everyday but I’ll definitely do it in a more disciplined way from now on.
Fábio Nogueira: É hora de ajudar!
8 de Maio de 2010, 0:00 - sem comentários ainda
Sim… é chegada a hora!
Semanalmente recebo diversos pedidos de CDs do Ubuntu, principalmente quando se aproxima dos lançamentos das novas versões do Ubuntu. Para resolver e principalmente agilizar os pedidos que feitos através do http://shipit.ubuntu.com podem demorar até dois meses para chegar, criamos uma wiki chamada CDs No Brasil, onde fica mais fácil de encontrar na sua cidade, voluntários na doação de cds de instalação na versão e arquitetura desejada.
Precisamos de mais doadores! Pessoas que possam passar esta ideia adiante. No início tínhamos mais de 60 pessoas envolvidas, Hoje apenas 4 gatos pingados! É nesse ponto que este post quer chegar.
Queimar um CD não custa nada… no máximo pedir o reembolso da mídia. Então está mais do que na hora de ajudar o próximo… principalmente o mais próximo, mesmo porque fica dispendioso ficar enviando CDs para outros Estados, indo a agências dos CORREIOS, etc…
Fica aqui então o meu pedido para contar com novos colaboradores na ajuda daqueles desprovidos de banda larga, etc…
Para conhecer e ajudar nessa iniciativa, acesse: http://wiki.ubuntu-br.org/CDsNoBrasil. No mais, estou à disposição!
Lucas Rocha: Note to Planet readers
7 de Maio de 2010, 0:00 - sem comentários ainda
Maricá
I decided to use a tag-specific feed in the two Planets aggregating my blog posts: Planet GNOME and Planeta GNOME Brasil. I’m planning to post more often about some “off-topic” topics (music, food, personal stuff, drawings, etc) and I don’t want to cause too much distraction to Planet readers.
That doesn’t mean I’ll only aggregate GNOME-related posts in those Planets from now on. It’s just that I want to explicitly select what goes in and what doesn’t.
So, if you’re a Planet reader and for some crazy reason you feel like you don’t want to miss any of my blog posts, subscribe directly to my feed or follow me on Identi.ca or Twitter.
Jonh Wendell: FLISOL e ENSOL
5 de Maio de 2010, 0:00 - sem comentários aindaOi gente!
Eu esqueci de falar sobre o FLISOL que aconteceu semana passada. O GNOME Brasil esteve representado em 4 cidades, incluindo Maceió! Estive lá e, claro, falei sobre o GNOME, o que ele é (sim, muita gente não “conhece” GNOME, só conhece Ubuntu, Fedora, Linux, OpenOffice, etc), como ele é organizado e como é bom fazer parte deste projeto!
The talk
Two guys winning a GNOME t-shirt
Amanhã vou viajar para João Pessoa, para participar do ENSOL. Nós do GNOME Brasil teremos três palestras e também teremos um estande/quiosque, onde poderemos nos encontrar e nos divertir! O evento acaba no domingo, então, na próxima semana blogarei sobre ele.
Inté!
Jonh Wendell: Placa de vídeo SiS e o tocador de vídeo totem
4 de Maio de 2010, 0:00 - sem comentários aindaOi gente. Continuando minha saga com a placa de vídeo SiS:
Não consigo reproduzir nenhum vídeo (divx, dvd) com o totem. A solução?
Instale o VLC media player.
Ele não é tão integrado ao GNOME e não é tão simples de usar como o totem, e ainda mostra algumas falhas no vídeo sendo reproduzido, mas o que importa é que ele funciona com os drivers SiS. Isso siginifica que posso continuar acompanhando LOST!
A propósito, isso seria uma falha no gstreamer?
