Posts de ‘Bruno Mentges de Carvalho’

[Bruno Mentges de Carvalho] Instalando ImageMagick e rmagick no Mac OSX Snow Leopard sem sofrimento

Thursday, February 17th, 2011

Amigos, recentemente vinha sofrendo para instalar o ImageMagick e o rmagick no Mac OSX Snow Leopard porque não uso o port, uso o homebrew e o brew install imagemagick nao tá instalando direito.

Para instalar sem sofrimento o ImageMagick e o rmagick siga estes passos:

Baixe o binário do ImageMagick em http://www.imagemagick.org/download/binaries/ImageMagick-x86_64-apple-darwin10.6.0.tar.gz.

tar -zvf ImageMagick-x86_64-apple-darwin10.6.0.tar.gz
sudo mv ImageMagick-6.6.5/ /opt

Agora coloque em seu ~/.bash_profile ou ~/.bashrc (no que estiver usando):

export MAGICK_HOME="/opt/ImageMagick-6.6.5"
export DYLD_LIBRARY_PATH="$MAGICK_HOME/lib"
export PATH=$PATH:$MAGICK_HOME/bin/

Depois basta digitar:

source ~/.bashrc
ou
source ~/.bash_profile
sudo gem install rmagick

Vai rolar :)

[]s

[Bruno Mentges de Carvalho] ApacheCon 2010

Thursday, October 28th, 2010

ApacheCon 2010

Na próxima semana agora irei para a ApacheCon, em Atlanta, Georgia para conferir as novidades no mundo de software livre apache, com um interesse especial em Solr e Lucene, que são engines de busca que usamos aqui na globo.com.

Estou inscrito no treinamento “Solr Application Development Workshop“, que acontecerá nos dois primeiros dias e pretende ser um hands-on de desenvolvimento de aplicações utilizando o Solr, com técnicas para analizar e resolver problemas de busca comuns, como usar os módulos opcionais de Revisão de texto, highlight, importação de dados, extração de documentos, além de tópicos avançados como estratégias de deployment, operação do Solr em produção, etc.

Também frequentarei os 3 dias de palestras seguintes. Assistirei palestras interessantes como:

Essas são as palestras que tenho programado pra assistir e que mais me interessaram da grade de palestras desse ano. Essa conferência será bastante pertinente para o que meu time faz aqui e estou bastante ansioso para estar lá ! :)

[Bruno Mentges de Carvalho] Como aprender JavaScript

Wednesday, October 13th, 2010

Com todo o hype girando em torno do node.js, uma das questões que aparecem com frequência é: Como aprender JavaScript ?

Eu particularmente recomendo aprender vendo os vídeos do Douglas Crockford, do Yahoo!, que estão espalhados aqui: http://developer.yahoo.com/yui/theater/ (veja os links organizados abaixo).

A primeira parte fala sobre a linguagem, seus aspectos e sua história. Além de mostrar os conceitos básicos e fundamentais para entender JavaScript:

(1a parte): Douglas Crockford — The JavaScript Programming Language

Nessa segunda parte, Douglas Crockford fala sobre a API do DOM e de todos os problemas e suas possíveis soluções de rodar JavaScript no browser.

(2a parte): Douglas Crockford — An Inconvenient API: The Theory of the DOM

Na última parte da série, Douglas Crockford fala sobre os aspectos avançados da linguagem:

(3a parte): Douglas Crockford — Advanced JavaScript

Esses vídeos são imperdíveis pois Douglas Crockford é muito didático e ensina num ritmo muito tranquilo de acompanhar.

Pra quem prefere um bom livro, tem os seguintes:

É isso. Bons estudos :)

[Bruno Mentges de Carvalho] Linked Open Data – a próxima web

Saturday, August 21st, 2010

Tim Berners Lee, para quem não sabe, foi quem teve a brilhante idéia de criar a internet. A visão que ele tinha na época era que ele poderia colocar todos os documentos acessíveis e ligados, pelo que chamamos hoje de links. Ao ter essa idéia, ele percebeu que poderia tomar uma dimensão incrível, e isso iria beneficiar muito a humanidade, já que na época todo o conhecimento estava em documentos isolados e de difícil acesso (livros, papéis, documentos eletrônicos em servidores locais, etc).

Com essa visão, ele mandou um memorando pro seu chefe contando o que tinha imaginado. Demorou um tempo até que acreditassem na idéia dele: 18 meses. Dezoito meses depois ele conseguiu ser alocado para desenvolver esse projeto. Ele desenvolveu a base do que hoje temos aqui: o protocolo HTTP, as páginas web, o HTML, etc.

Recentemente Tim Berners Lee escreveu um paper sobre uma nova visão: Linked Data. Na visão dele, documentos a gente pode ler, acessar e tudo mais, porém chegou a hora de publicarmos não só nossos documentos mas nossos dados. Ele cita uma apresentação onde o Hans Rosling combinou dados reunidos de vários países e desmistificou alguns mitos sobre a economia no terceiro mundo. Essa apresentação você pode ver aqui: http://www.ted.com/talks/hans_rosling_shows_the_best_stats_you_ve_ever_seen.html

O dado em si, sozinho, não tem muito valor mas combinado, pode ter um valor incrível. Imagine que seu governo publique todos os dados sobre as construções de pontes no país. Alguém poderia combinar esses dados e descobrir que uma obra em algum estado foi superfaturada, pois outras obras de mesmas características foram 10 vezes mais baratas.

Para os cientistas esses dados são ainda mais importantes, diz Tim Berners Lee. Eles poderiam cruzar dados antes isolados em centros de pesquisas diferentes, e chegar a novas descobertas e criar coisas incríveis, como por exemplo a Cura do Câncer.

Linked Open Data não é somente dados, são relacionamentos. Não é somente dizer o quanto eu peso e tenho de altura, mas saber que eu nasci no Rio de Janeiro, que é uma cidade do Brasil. E eu poderia clicar ali e ver os dados da cidade, sua população, e clicar denovo e ver os dados do país, e descobrir quem foram os presidentes, e clicar neles e assim por diante. É ligar os dados.

Linked Open Data é um dos pilares da Web Semântica. Dar significado as coisas, saber as relações. Meu time na globo.com é responsável por Busca e Semântica e eu sou apaixonado por essa idéia. Acredito que essa idéia será responsável pelo próximo grande salto da humanidade.

Assista ao TED talk do Tim Berners Lee, você não irá se arrepender:

[Bruno Mentges de Carvalho] Padronizando o versionamento do seu software com Semantic Versioning

Wednesday, August 18th, 2010

Um dos grandes problemas quando trabalhamos com múltiplos times de desenvolvimento e existem softwares que dependem entre si é saber quando uma versão continua compatível com a anterior. Muito se discute sobre como devemos versionar nosso software visando evitar o problema chamado Dependency Hell (Inferno das Dependências). Esse problema comumente aparece ou com dependency lock, ou seja, seu software não pode mais andar pra frente sem antes fazer um release de todas as dependências, ou com version promiscuity que é quando você assume compatibilidade com versões futuras sem ter certeza.

Foi aí que surgiu uma especificação formal para resolver esses problemas que se chama Semantic Versioning, ou, em português, Versionamento Semântico e essa especificação se encontra aqui: http://semver.org/ (em inglês). Não é nada novo, devo avisar, mas é uma forma de especificar o significado dos números que você usa para versionar seu software. O modelo é simples, o conhecido X.Y.Z onde X é a Major Version, Y é a Minor Version e Z é a Patch Version, exemplo: Meu Software versão 2.5.1.

Para efeito de continuidade, vou traduzir aqui as regras que são poucas mas bem interessantes:

  1. Software que usa Semantic Versioning DEVE declarar a public API. Essa API pode ser declarada no código ou existir em documentação. Quando for feita, ela deverá ser precisa e compreensiva.
  2. Um número de versão normal DEVE ter a forma de X.Y.Z, onde X,Y e Z são inteiros. X é o major version, y é o minor version e Z é o patch version. Cada elemento DEVE aumentar numericamente. Por exemplo: 1.9.0 < 1.10.0 < 1.11.0.
  3. Um número de versão especial PODE ser denominado ao adicionar uma string abritrária logo após o patch version. Essa string DEVE conter somente alfanuméricos mais o símbolo menos [0-9A-Za-z-] e DEVE começar com um caracter alpha [A-Za-z]. Versões especiais devem satisfazer e ter menor precedência que a versão normal associada. Precedência DEVE ser determinada pela ordenação lexicográfica ASCII. Exemplo: 1.0.0beta1 < 1.0.0beta2 < 1.0.0
  4. Uma vez que foi lançada uma versão, o conteúdo daquela versão NÃO DEVE ser modificada. Qualquer modificação deve ser lançada como uma nova versão.
  5. Major version que começe com 0 (0.y.z) é para desenvolvimento inicial. Qualquer coisa pode mudar a qualquer momento. A public API não pode ser considerada estável.
  6. A Versão 1.0.0 define a public API. A maneira com que o número de versão aumenta é agora dependente dessa API e em como ela muda.
  7. Patch version Z (x.y.Z | x > 0) DEVE ser incrementada se somente bug fixes que são compatíveis com versões anteriores são introduzidos. Um bug fix é definido como uma mudança interna que corrige um comportamento incorreto.
  8. Minor Version Y (x.Y.z | x > 0) DEVE ser incrementada se novas funcionalidades que são compatíveis com versões anteriores são introduzidas à public API. Ela PODE ser incrementada se muitas novas funcionalidades ou melhorias forem introduzidas no código privado. Ela PODE incluir patches.
  9. Major version X (X.y.z | X > 0) DEVE ser incrementada se qualquer mudança que quebre a compatibilidade com versões anteriores são introduzidas na public API. Ela PODE incluir mudanças minor e de patch.

É isso. São essas as regras. Mas qual a importância disso se nada disso é novo ? A importância é que se todos seguem essa especificação, todos terão o mesmo entendimento do que significam os números de sua versão e se planejar ao ter que fazer upgrade. Se só o que seu software adicionou foram melhorias e novas funcionalidades que não quebram nenhum comportamento com as versões antigas, eu sei que posso fazer um release tranquilo sem precisar alterar nada do meu lado.

Tem um FAQ legal na url da especificação que traz dúvidas comuns. Lá também orienta quem quer começar agora a usar mesmo tendo um sistema legado cheio de tags. Vale dar uma conferida e tentar espalhar essa especificação. Nós aqui do meu time de desenvolvimento já começamos a usar.

[Bruno Mentges de Carvalho] Desabilitar confirmação ao rodar um aplicativo baixado da internet no MacOSX

Tuesday, August 17th, 2010

Agora sou um usuário Mac e uma coisa vem me incomodando desde o primeiro dia: A confirmação de segurança de que quer rodar um aplicativo baixado da internet toda vez que você o abre.

Quando esse aplicativo é o firefox e você o utiliza todo dia isso realmente incomoda. Então achei a seguinte solução:

xattr -d -r com.apple.quarantine /Applications

Você pode especificar qualquer diretório onde tenha esses aplicativos, como por exemplo o ~/Downloads e ele vai parar de reclamar para os aplicativos que já existem.

[Bruno Mentges de Carvalho] Usando jQuery no console do firebug

Thursday, January 7th, 2010

Recentemente procurei como fazer pra usar o jQuery no console do firebug, e encontrei essa solução:

Adicione esse bookmarklet na barra de favoritos do firefox e clique toda vez que quiser injetar o jquery num site para voce poder manipular com facilidade:

Load jQuery

O código é simples, como podemos ver abaixo:

j=document.createElement("SCRIPT");
j.src="http://code.jquery.com/jquery-latest.pack.js";
document.getElementsByTagName("HEAD")[0].appendChild(j);

Fonte em inglês:
http://techrageo.us/2008/03/05/jquery-for-firebug/
Uma alternativa praticamente igual:
http://ajaxian.com/archives/hacking-digg-with-firebug-and-jquery

Espero que ajude :)

[Bruno Mentges de Carvalho] Usando jQuery no console do firebug

Thursday, January 7th, 2010

Recentemente procurei como fazer pra usar o jQuery no console do firebug, e encontrei essa solução:

Adicione esse bookmarklet na barra de favoritos do firefox e clique toda vez que quiser injetar o jquery num site para voce poder manipular com facilidade:

Load jQuery

O código é simples, como podemos ver abaixo:

j=document.createElement("SCRIPT");
j.src="http://code.jquery.com/jquery-latest.pack.js";
document.getElementsByTagName("HEAD")[0].appendChild(j);

Fonte em inglês:
http://techrageo.us/2008/03/05/jquery-for-firebug/
Uma alternativa praticamente igual:
http://ajaxian.com/archives/hacking-digg-with-firebug-and-jquery

Espero que ajude :)

Edit: Lançaram um plugin que faz isso direto do firebug, fazendo com que tudo isso que escrevi não seja mais necessário. Link: http://firequery.binaryage.com/

[Bruno Mentges de Carvalho] Git – como usar tags

Friday, November 13th, 2009

Alguns comandos para usar tags com git:

  • Listar tags: git tag
  • Criar uma tag do branch local: git tag minha-tag
  • Fazer push das tags: git push –tags origin master
  • Renomear uma tag: git tag -m minha-tag minha-nova-tag
  • Deletar uma tag local: git tag -d minha-tag
  • Deletar uma tag remota, no origin: git push origin :refs/tags/minha-tag

[Bruno Mentges de Carvalho] Git – como usar tags

Friday, November 13th, 2009

Alguns comandos para usar tags com git:

  • Listar tags: git tag
  • Criar uma tag do branch local: git tag minha-tag
  • Fazer push das tags: git push –tags origin master (tem dois sinais de menos ao lado do tags ;)
  • Renomear uma tag: git tag -m minha-tag minha-nova-tag
  • Deletar uma tag local: git tag -d minha-tag
  • Deletar uma tag remota, no origin: git push origin :refs/tags/minha-tag