return 1;
Computação
Área destinada a algoritmos, pensamentos e filosofias.
Ubuntu 10.04 + Acer Aspire 1410
Apr 28th
Recentemente comprei um Notebook Aspire 1410 de 11.6″, e depois de instalar o Ubuntu 10.04 eu vinha experimentando problemas de performance, e recorrentes problemas de IO do HD, sempre tinha que reinstalar o sistema, pois corrompia o raiz(/) do sistema, até que resolvi estudar os comentários sobre esse notebook e achei a origem dos problemas. Acabou que descobri que existe um bug na BIOS, no módulo AHCI, que é uma funcionalidade de SATA 2, então resolvi atualizar a BIOS, porém lendo mais fórums sobre a instalação nesse notebook e sobre essa tecnologia AHCI, ela somente dá suporte a hot swapping e NCQ, o hot swapping é a possibilidade de desconectar o hd com a placa ligada(o que eu não vou fazer) e NCQ é uma tecnologia de acesso a disco mais eficaz em ambientes de intensa leitura e gravação de dados no HD, suporta cache e etc, o que também não é o meu caso. Portanto eu não preciso dessa tecnologia AHCI, e na BIOS o SATA MODE estava configurado para AHCI, troquei para IDE MODE e pronto. Os problemas pararam de ocorrer e a máquina ficou mais rápida e o boot já não leva 5 minutos.
Com o Ubuntu 9.10 eu instalei e funcionou corretamente, mas de vez em quando aparecia uns erros estranhos envolvendo HD no /var/log/syslog. O que não me deixava feliz e me deixava preocupado.
Portanto fica a dica, se você tiver um computador igual ao meu Aspire 1410 (11″6), desabilite o modo AHCI que muito provavelmente você não vai utilizar os recursos e poupará dores de cabeça e depois instale o seu Ubuntu 10.04. 
Tirando esse problema, esse notebook é show de bola, tenho usado ele para trabalhar também e ele segura o trabalho sem frescuras, as vezes ele se esquenta ;-) , mas agente acaba se entendendo. Cheguei até a me arrepender de ter comprado ele, mas já pedi desculpa dele e estamos felizes. 
Só queria deixar registrado a dica!
:wq!
Bossa Conference ’10 – em Manaus
Mar 2nd
Faz algum tempo que estou querendo escrever vários posts técnicos e da minha viagem a sampa que fiz em janeiro, mas realmente o tempo está escasso. Mas não podia deixar passar em branco a divulgação do Bossa Conference que é um evento que sempre tive vontade de participar e que era realizado em Porto de Galinhas. Esse ano o Bossa Conference ’10 será realizado em Manaus – Amazonas. Uma chance dos nerds nortistas poderem participar até onde sabemos deste excelente evento.
__hg_ps1 – Nome da branche na linha de comando do bash
Nov 4th
Pra quem já usou git, sabe que existe o __git_ps1 que você pode usar para colocar na linha de comando do bash para lhe mostrar qual a branch atual de trabalho. Sem essa funcionalidade fica difícil trabalhar com as branches sem se perder de vez em quando. Procurando por algo similar no mercurial, achei o __hg_ps1.
Muito simples de instalar:
- baixe o tarball
- instale como qualquer aplicação python ( python setup.py install )
- configure PS1 no ~/.bashrc
wget -c http://bitbucket.org/krbullock/hg_ps1/get/tip.tar.gz
tar xvf tip.tar.gz
cd hg_ps1/
sudo python setup.py install
Coloque no ~/.bashrc o seguinte:
1 | PS1='${debian_chroot:+($debian_chroot)}\[\033[01;31m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[01;33m\] $(A=`__hg_ps1` && echo "[$A]" ) \[\033[0m\] \[\033[00m\]$ ' |
Se você tiver também o git instalado, coloque este abaixo:
1 | PS1='${debian_chroot:+($debian_chroot)}\[\033[01;31m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[01;33m\]$(__git_ps1 " [%s]") $(A=`__hg_ps1` && echo "[$A]" ) \[\033[0m\] \[\033[00m\]$ ' |
Como pode ser visto no comando acima, tem também o __git_ps1, se você entrar em algum repositório git, também funciona, a melhor configuração para manter os dois foi essa acima. Isso é muito útil.
Trabalhando com o Mercurial – HG
Nov 3rd
Introdução
Nos últimos tempos estou conscientizando os meus colegas de trabalho sobre os benefícios da utilização de um controle de código distribuído. Fiz uma análise nas vantagens e desvantagens do Git e HG (Mercurial) e escolhemos o Mercurial pois precisamos trabalhar em um ambiente heterogeneo e o suporte do Git ao windows ainda é precário, até achamos algumas iniciativas como o MSysGit, porém ainda possuem um longo caminho pela frente para se tornar uma ferramenta que atenda as nossas necessidades(realidade). A comunidade do mercurial está mais evoluida neste sentido, e ao que estudamos o Mercurial disponibiliza todas as funcionalidades que almejamos em um gerenciador de código distribuído.
O objetivo deste post é mostrar o fluxo de trabalho com mercurial, comentando os comandos executados em um fluxo de trabalho escolhido por mim. Alguns devem se perguntar, “Por que escolhido por você ?”, porque com o gerenciador de código distribuído não existe um fluxo de trabalho obrigatório a ser seguido, as ferramentas oferecem recursos para você adaptar fácilmente o fluxo de trabalho, portanto uma vez que você entende os conceitos do gerenciador de código distribuído você nota que é você quem faz seu fluxo de trabalho.
Não se assuste com as sequências de códigos, logo abaixo segue os comentários sobre as operações efetuadas, uma das coisas legais do mercurial é que a maioria dos comandos são legíveis, portanto tente entender somenter ao ler os comandos, senão entender, leia os comentários e avalie novamente os comandos, tudo deve fazer sentido, pelo menos eu espero que faça sentido.
Como dito anteriormente o objetivo não é explicar os conceitos. Portanto para entender os conceitos por trás do que é um gerenciador de código distribuído recomendo a leitura dos seguintes textos:
- Conceitos básicos de controle de versão de softwew: Centralizado e Distribuído.
- Entendendo git e instalando gitorious. Nesse post recomendo os capítulos Mudança de paradigma, Problemas da centralização 1, 2 e 3, Git: Ferramenta para pessoas sem paciência, Mundo ideal .
- Introdução ao controle de versão distribuído (Ilustrado). (Inglês)
Configuração
Para este post estou usando mercurial 1.3.1 instalado no ubuntu através do easy_install.
Recomendo configurar também o __hg_ps1, como nesse post.
Antes de começar configure seu .hgrc. Crie um arquivo no seu home:
touch ~/.hgrc
E então edite com seu editor favorito e coloque as seguinte informações sobre a aparência do hg:
[ui]
username = Seu Nome <seu@email.com.br>
style = compact
Antes de continuarmos, uma coisa que é muito legal no mercurial são as extensões. O mercurial já vem com uma série de extensões incluídas, para uma lista completa clique aqui, abaixo algumas que julgo essenciais, embora eu não vá explicar a utilização de todas nesse post, já deixe habilitado, não custa nada com certeza explicarei nos posts seguintes.
- mercurialqueue
- rebase
- graphlog
Para habilitar adicione ao arquivo ~/.hgrc também uma nova seção para as extensões:
[extensions]
hgext.graphlog =
hgext.mq =
hgext.rebase =
Comandos básicos
Tendo em mente que você já sabe os conceitos, vamos fazer uma lista breve de comandos básicos que você deve saber na ponta do dedo.
hg clone <url>
faz uma cópia local do repositório informado
hg pull
faz download das mudanças no repositório de origem (pai)
hg push
faz upload das mudanças no repositório de origem (pai)
hg status
verifica se há alterações locais
hg tip
verifica qual a versão que está a frente no repositório, ou se preferir no topo(HEAD)
hg incoming
verifica o que tem de novo no repositório de origem, frequentemente usado antes de fazer um hg pull, para saber o que se esperar.
hg outgoing
verifica o que você tem de novo em relação ao repositório de origem, frequentemente usado antes de fazer hg push
hg merge
uni duas branches ou changeset transformando em uma.
Trabalhando
Vamos agora iniciar o trabalho, você vai codificar um projeto novo, então você cria uma pasta, inicia o repositório e adiciona inicialmente um arquivo de README com instruções ou informações sobre o projeto:
1 2 3 4 5 6 7 8 9 10 | :~/src $ mkdir projetonovo :~/src $ cd projetonovo/ :~/src/projetonovo $ ls :~/src/projetonovo $ hg init :~/src/projetonovo $ echo "Este projeto vai dominar o mundo" >> README :~/src/projetonovo $ hg add README :~/src/projetonovo $ hg ci -m "Adicionado arquivo de README com informações sobre o projeto" :~/src/projetonovo $ hg tip 0[tip] b65bb6ffc97c 2009-11-02 14:55 -0400 root Adicionado arquivo de README com informações sobre o projeto |
Agora temos uma pasta com o nosso projeto e que está sendo versionado pelo mercurial, adicionamos um arquivo com informações para ser rastreado, fizemos o commit e depois verificamos qual o tip(head) do repositório. Você pode verificar que a saída do hg tip foi algo bem resumido, isso por que configuramos no ~/.hgrc na seção [ui] , o estilo compacto style = compact . Se você deseja que o output dos comandos do mercurial sejam mais verbosos, basta comentar o style = compact ou remover do ~/.hgrc.
Dentro de uma equipe de desenvolvimento de software, existem pelo menos 2 ciclos básicos que ficam em loop olhando pela perspectiva de implementação e não de análise, eu chamo de ciclo implementativo e corretivo.
Abaixo apresento minha solução para os ciclos em um mundo ideal. Há quem diga que não vivemos em um mundo ideal, mas eu acho importante para entender e fixar os conceitos.
Ciclo implementativo
- Identicar nova funcionalidade e traçar funcionamento básico
- Abrir uma ramificação(branch) do projeto
- Codificar e testar na branch criada SOMENTE para esta feature
- Unir(merge) tip da branche da nova feature ao tip da mainline (branche default) e commitar
- Fechar a ramificação da branche da nova feature
Claro, aqui não é usado nenhuma formalidade nem nome bonito. É simplesmente como eu resumo minhas tarefas implementativas ao meu gosto.
Esse processo pode variar, o mercurial dá a liberdade de você fazer isso como quiser, abaixo eu demonstro como eu faço isso. Uma coisa interessante de ser mencionada é que as branchs são operações no repositório e portanto entram para o histórico do repositório, não esqueça que as branches precisam ser commitadas, dependendo do seu projeto você pode não querer saber como cada desenvolvedor criou a branch ou que nome deu para a branch, eu acho interessante e não vejo problema nisso, muito pelo contrário, temos um histórico fidedigno do desenvolvimento do projeto.
Então vou criar a branche para implementar a funcionalidade UltraMegaBoga de todos os tempos .
1 2 3 4 5 6 | :~/src/projetonovo $ hg branch NovaFeature_UltraMegaBoga marked working directory as branch NovaFeature_UltraMegaBoga :~/src/projetonovo $ hg ci -m "Criado branch para implementar NovaFeature UltraMegaBoga" :~/src/projetonovo $ hg branches NovaFeature_UltraMegaBoga 1:7fc70f299283 default 0:b65bb6ffc97c (inactive) |
Dae você pode ver que usamos o hg branch para nomear a branche padrão atual (default) e depois criamos de fato através do commit (ci), e depois confirmamos usando o hg branches para verificar quais as branches que temos no repositório. E agora sim podemos codificar a funcionalidade. No commit automaticamente somos movidos para a branch nova que acabamos de criar.
Então, implementando uma nova feature:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 | :~/src/projetonovo $ touch teste.py :~/src/projetonovo $ echo "print('Hellowww mercurial')" >> teste.py :~/src/projetonovo $ python teste.py Hellowww mercurial :~/src/projetonovo $ hg status ? teste.py :~/src/projetonovo $ hg add teste.py :~/src/projetonovo $ hg status A teste.py :~/src/projetonovo $ hg ci -m "Criado arquivo da funcionalidade UltraMegaBoa" :~/src/projetonovo $ hg glog @ 2[tip] c192d84f042a 2009-11-02 17:16 -0400 root | Criado arquivo da funcionalidade UltraMegaBoa | o 1 7fc70f299283 2009-11-02 17:01 -0400 root | Criado branch para implementar NovaFeature UltraMegaBoga | o 0 b65bb6ffc97c 2009-11-02 14:55 -0400 root Adicionado arquivo de README com informações sobre o projeto :~/src/projetonovo $ echo "import this" >> teste.py :~/src/projetonovo $ hg status M teste.py :~/src/projetonovo $ hg ci -m "Nova funcionalidade UltraMegaBoga implementada" :~/src/projetonovo $ hg glog @ 3[tip] f337dc212ea0 2009-11-02 17:19 -0400 root | Nova funcionalidade UltraMegaBoga implementada | o 2 c192d84f042a 2009-11-02 17:16 -0400 root | Criado arquivo da funcionalidade UltraMegaBoa | o 1 7fc70f299283 2009-11-02 17:01 -0400 root | Criado branch para implementar NovaFeature UltraMegaBoga | o 0 b65bb6ffc97c 2009-11-02 14:55 -0400 root Adicionado arquivo de README com informações sobre o projeto :~/src/projetonovo $ echo "print('Testando funcionalidade ultramegaboga...')" >> teste.py :~/src/projetonovo $ hg status hg M teste.py :~/src/projetonovo $ hg ci -m "Implementado TesteUnitario e tudo funcionando como esperado" :~/src/projetonovo $ hg glog @ 4[tip] 63ddafc85f03 2009-11-02 17:21 -0400 root | Implementado TesteUnitario e tudo funcionando como esperado | o 3 f337dc212ea0 2009-11-02 17:19 -0400 root | Nova funcionalidade UltraMegaBoga implementada | o 2 c192d84f042a 2009-11-02 17:16 -0400 root | Criado arquivo da funcionalidade UltraMegaBoa | o 1 7fc70f299283 2009-11-02 17:01 -0400 root | Criado branch para implementar NovaFeature UltraMegaBoga | o 0 b65bb6ffc97c 2009-11-02 14:55 -0400 root Adicionado arquivo de README com informações sobre o projeto |
Opa!, muita informação?… nada, só algumas sendo repitidas.
Linhas 1 ~ 10: Nestas linhas apenas criamos um arquivo, colocamos conteúdo dentro dele, executamos, verificamos o status do repositório e eles nos diz que o arquivo novo não foi adicionado e então o adicionamos ao projeto para ser rastreado e então commitamos. Simples hein ?!
Linhas 11: Na linha 11 há um comando novo que ainda não comentamos, o comando hg glog que mostra o log do repositório através de um grafo, o que facilita bastante a vida quando estamos trabalhando com branches(ramificações), para entender melhor veja bem que o glog traz a arvore de forma natural, ou seja, da raiz até o topo ou nós. Na primeira coluna mostra os nós e aonde você está em relação aos nós da arvore, cada nó desse representa um commit, os nós são representados por o e onde você está através do @, na segunda coluna estão as revisões de números inteiros e sequencias que você pode usar para se direcionar ou situar na árvore ou histórico, o mercurial usa revisões sequencias e hashs para controlar o histórico e os changesets(conjuntos de mudanças).
E então esses procedimentos se repetem até o nó 4 ou changeset 63ddafc85f03, conforme pode ser visto localizando o @ no resultado do comando hg glog.
Vamos voltar para o branche default para fazer o merge e incorporar as modificações da branche UltraMegaBoga
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | :~/src/projetonovo $ hg update default 0 files updated, 0 files merged, 1 files removed, 0 files unresolved :~/src/projetonovo $ hg glog o 4[tip] 63ddafc85f03 2009-11-02 17:21 -0400 root | Implementado TesteUnitario e tudo funcionando como esperado | o 3 f337dc212ea0 2009-11-02 17:19 -0400 root | Nova funcionalidade UltraMegaBoga implementada | o 2 c192d84f042a 2009-11-02 17:16 -0400 root | Criado arquivo da funcionalidade UltraMegaBoa | o 1 7fc70f299283 2009-11-02 17:01 -0400 root | Criado branch para implementar NovaFeature UltraMegaBoga | @ 0 b65bb6ffc97c 2009-11-02 14:55 -0400 root Adicionado arquivo de README com informações sobre o projeto |
Outro comando novo, hg update, com esse comando você pode alternar entre as branches(ramificações) do seu projeto e nas revisões também bastando passar o parâmetro hg update -r REV, na linha 1 alternei para a branch default e você pode perceber na saída do comando hg glog que o @ voltou para revisão 0 que é onde a revisão default parou, certo ? os outros commits foram da branche NovaFeature_UltraMegaBoga.
Agora vamos fazer o merge das duas branches.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 | :~/src/projetonovo $ hg merge NovaFeature_UltraMegaBoga 1 files updated, 0 files merged, 0 files removed, 0 files unresolved (branch merge, dont forget to commit) :~/src/projetonovo $ hg tip 4[tip] 63ddafc85f03 2009-11-02 17:21 -0400 root Implementado TesteUnitario e tudo funcionando como esperado :~/src/projetonovo $ hg glog @ 4[tip] 63ddafc85f03 2009-11-02 17:21 -0400 root | Implementado TesteUnitario e tudo funcionando como esperado | o 3 f337dc212ea0 2009-11-02 17:19 -0400 root | Nova funcionalidade UltraMegaBoga implementada | o 2 c192d84f042a 2009-11-02 17:16 -0400 root | Criado arquivo da funcionalidade UltraMegaBoa | o 1 7fc70f299283 2009-11-02 17:01 -0400 root | Criado branch para implementar NovaFeature UltraMegaBoga | @ 0 b65bb6ffc97c 2009-11-02 14:55 -0400 root Adicionado arquivo de README com informações sobre o projeto :~/src/projetonovo $ hg ci -m "Incorporando branch NovaFeature_UltraMegaBoga a arvore principal de desenvolvimento" :~/src/projetonovo $ hg glog @ 5[tip]:0,4 b270c2750162 2009-11-02 17:24 -0400 root |\ Incorporando branch NovaFeature_UltraMegaBoga a arvore principal de desenvolvimento | | | o 4 63ddafc85f03 2009-11-02 17:21 -0400 root | | Implementado TesteUnitario e tudo funcionando como esperado | | | o 3 f337dc212ea0 2009-11-02 17:19 -0400 root | | Nova funcionalidade UltraMegaBoga implementada | | | o 2 c192d84f042a 2009-11-02 17:16 -0400 root | | Criado arquivo da funcionalidade UltraMegaBoa | | | o 1 7fc70f299283 2009-11-02 17:01 -0400 root |/ Criado branch para implementar NovaFeature UltraMegaBoga | o 0 b65bb6ffc97c 2009-11-02 14:55 -0400 root Adicionado arquivo de README com informações sobre o projeto |
hg merge <nome_do_branch> e então a união é feita, mas você pode ver pela saída do hg glog da linha 7 que o @ aparece tanto na revisão 0 quanto na 4, porque faltou criar o nó que significa a união dos projetos e que será ponto de partida para novas alterações, e eles nos avisa ao fazer o merge não esqueça de fazer o commit. E então fizemos o commit informando que estamos incorporando a nova funcionalidade. e então você pode ver o resultado do glog novamente, gerou-se a revisão 5 e novo hash. Agora percebesse que o glog é realmente muito útil né ?
Agora para finalizar o ciclo, precisamos fechar a branch que criamos para desenvolver a feature, essa é uma funcionalidade que veio no mercurial 1.2, pois antes disso o mercurial não permite deletar branch, imagine a quantidade de branches que perduravam a vida toda no repositório ?!.
Encerrando as atividades da branch UltraMegaBoga.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | :~/src/projetonovo $ hg update NovaFeature_UltraMegaBoga 0 files updated, 0 files merged, 0 files removed, 0 files unresolved :~/src/projetonovo $ hg ci -m "Fechando branch, feature implementada e incorporada a arvore principal" --close-branch created new head :~/src/projetonovo $ hg branches default 5:b270c2750162 :~/src/projetonovo $ hg glog @ 6[tip]:4 7992ab50038d 2009-11-02 17:26 -0400 root | Fechando branch, feature implementada e incorporada a arvore principal | | o 5:0,4 b270c2750162 2009-11-02 17:24 -0400 root |/| Incorporando branch NovaFeature_UltraMegaBoga a arvore principal de desenvolvimento | | o | 4 63ddafc85f03 2009-11-02 17:21 -0400 root | | Implementado TesteUnitario e tudo funcionando como esperado | | o | 3 f337dc212ea0 2009-11-02 17:19 -0400 root | | Nova funcionalidade UltraMegaBoga implementada | | o | 2 c192d84f042a 2009-11-02 17:16 -0400 root | | Criado arquivo da funcionalidade UltraMegaBoa | | o | 1 7fc70f299283 2009-11-02 17:01 -0400 root |/ Criado branch para implementar NovaFeature UltraMegaBoga | o 0 b65bb6ffc97c 2009-11-02 14:55 -0400 root Adicionado arquivo de README com informações sobre o projeto |
Basicamente na saída acima, voltamos para a branch da funcionalidade UltraMegaBoga e fazemos um commit de encerramento, com o parâmetro –close-branch. Com isso damos fim ao Ciclo Implementativo.
Ciclo corretivo
No ciclo corretivo, existem 2 aspectos:
- Você encontrou o problemas durante o desenvolvimento, antes de lançar uma versão.
- Você encontrou ou encontraram pra você depois de ter lançado a versão.
Para primeira ocasião você pode usar o mesmo mecanismo do ciclo implementativo para fazer as correções. Agora na segunda ocasião eu sugiro uma abordagem diferente, o ideal é corrigir o problema e gerar patches para serem incorporados uma vez que o software já foi congelado(lançado a versão) e está apenas sofrendo correções esporádicas e não mais vivendo em um intenso processo de produção, para isso eu uso a extensão do mercurial chamada MercurialQueues, que é um conjunto de comandos para gerenciamentos de uma fila de patchs no estilo LIFO(Last-In / First-Out), o ciclo corretivo se divide em:
- Identificar a causa do problema
- Consertar o bug
- Gerar patch e exportar
Alguns devem ser perguntar o porque de eu sugerir MercurialQueues, pelo motivo de que os commits são maleáveis, no padrão os commits do mercurial são imutáveis, já com o MQ posso trabalhar em varios patches ao mesmo tempo somente manipulando a fila ao invés de ter que ficar importando e/ou exportando patches, posso também mesclar patches sem que isso interfira nos commits. IMHO, é mais conveniente. Você pode também usar o patch para aplicar a correção na versão que está em desenvolvimento
Comandos básicos
hg qinit
hg qnew
hg qrefresh
hg qpop
hg qpush
hg qfinish
hg qimport
Abaixo um exemplo de como criar uma fila e desenvolver um patch usando mercurial queues.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 | :~/src/projetonovo $ hg qinit -c :~/src/projetonovo $ hg qseries :~/src/projetonovo $ hg qapplied :~/src/projetonovo $ hg qnew fix_bug_01.patch :~/src/projetonovo $ echo "print('fixing bug')" >> mat.py :~/src/projetonovo $ hg qseries fix_bug_01.patch :~/src/projetonovo $ hg qapplied fix_bug_01.patch :~/src/projetonovo $ hg glog @ 9[fix_bug_01.patch,qtip,tip,qbase] b3f8a3b6f155 2009-11-02 22:55 -0400 root | [mq]: fix_bug_01.patch | o 8[qparent] 709a2b46c4cd 2009-11-02 17:29 -0400 root | Implementada feature nova e fechando branche | o 7 cd5986a79612 2009-11-02 17:28 -0400 root | criando branche para feature nova | o 6:4 7992ab50038d 2009-11-02 17:26 -0400 root | Fechando branch, feature implementada e incorporada a arvore principal | | o 5:0,4 b270c2750162 2009-11-02 17:24 -0400 root |/| Incorporando branch NovaFeature_UltraMegaBoga a arvore principal de desenvolvimento | | o | 4 63ddafc85f03 2009-11-02 17:21 -0400 root | | Implementado TesteUnitario e tudo funcionando como esperado | | o | 3 f337dc212ea0 2009-11-02 17:19 -0400 root | | Nova funcionalidade UltraMegaBoga implementada | | o | 2 c192d84f042a 2009-11-02 17:16 -0400 root | | Criado arquivo da funcionalidade UltraMegaBoa | | o | 1 7fc70f299283 2009-11-02 17:01 -0400 root |/ Criado branch para implementar NovaFeature UltraMegaBoga | o 0 b65bb6ffc97c 2009-11-02 14:55 -0400 root Adicionado arquivo de README com informações sobre o projeto :~/src/projetonovo $ hg qrefresh :~/src/projetonovo $ echo "a = 1" >> teste.py :~/src/projetonovo $ hg diff diff -r 2ae8338b6a9c teste.py --- a/teste.py Mon Nov 02 23:04:04 2009 -0400 +++ b/teste.py Mon Nov 02 23:07:04 2009 -0400 @@ -1,3 +1,4 @@ print('Hellowww mercurial') import this print('Testando funcionalidade ultramegaboga...') +a = 1 :~/src/projetonovo $ hg qdiff diff -r 709a2b46c4cd mat.py --- a/mat.py Mon Nov 02 17:29:50 2009 -0400 +++ b/mat.py Mon Nov 02 23:07:07 2009 -0400 @@ -1,1 +1,2 @@ print(2+2) +print('fixing bug') diff -r 709a2b46c4cd teste.py --- a/teste.py Mon Nov 02 17:29:50 2009 -0400 +++ b/teste.py Mon Nov 02 23:07:07 2009 -0400 @@ -1,3 +1,4 @@ print('Hellowww mercurial') import this print('Testando funcionalidade ultramegaboga...') +a = 1 :~/src/projetonovo $ hg qapplied fix_bug_01.patch :~/src/projetonovo $ hg qpop :~/src/projetonovo $ hg qseries fix_bug_01.patch :~/src/projetonovo $ hg qapplied :~/src/projetonovo $ hg qcommit :~/src/projetonovo $ hg tip 8[tip] 709a2b46c4cd 2009-11-02 17:29 -0400 root Implementada feature nova e fechando branche :~/src/projetonovo $ hg glog @ 8[tip] 709a2b46c4cd 2009-11-02 17:29 -0400 root | Implementada feature nova e fechando branche | o 7 cd5986a79612 2009-11-02 17:28 -0400 root | criando branche para feature nova | o 6:4 7992ab50038d 2009-11-02 17:26 -0400 root | Fechando branch, feature implementada e incorporada a arvore principal | | o 5:0,4 b270c2750162 2009-11-02 17:24 -0400 root |/| Incorporando branch NovaFeature_UltraMegaBoga a arvore principal de desenvolvimento | | o | 4 63ddafc85f03 2009-11-02 17:21 -0400 root | | Implementado TesteUnitario e tudo funcionando como esperado | | o | 3 f337dc212ea0 2009-11-02 17:19 -0400 root | | Nova funcionalidade UltraMegaBoga implementada | | o | 2 c192d84f042a 2009-11-02 17:16 -0400 root | | Criado arquivo da funcionalidade UltraMegaBoa | | o | 1 7fc70f299283 2009-11-02 17:01 -0400 root |/ Criado branch para implementar NovaFeature UltraMegaBoga | o 0 b65bb6ffc97c 2009-11-02 14:55 -0400 root Adicionado arquivo de README com informações sobre o projeto |
Linhas 1 ~ 10: É iniciada uma fila através do comando hg qinit -c , -c significa que a fila será versionada e portanto poderá ser usado o comando hg qcommit. Depois verificamos se está tudo zerado usando os comandos hg qseries e hg qapplied , o qseries nos permite verificar quais patchs estão na fila e o qapplied quais patchs estão aplicados efetivamente no repositório. Para criar um novo patch basta executar o hg qnew <nome_do_patch> que no exemplo acima atribui o nome fix_bug_01.patch. Alteramos o arquivo e podemos ver com o glog que ao criar o patch, já é aplicado automaticamente no repositório e por padrão coloca como msg do commit [mq]: nome_do_patch.
Linhas 40 ~ 51: É incluídas as alterações feitas no patch atual através do comando hg qrefresh. É feita uma alteração no arquivo teste.py e pra ver a diferença entre hg diff e hg qdiff é executado hg diff que é a última alteração que o repostório reconhece, quando executamos o hg qrefresh ele pega as alterações e armazena internamente no patch e as alterações não ficam mais no repositório comum e sim no patch que está sendo desenvolvido com mercurial queue. O hg qdiff mostra todas as alterações incluídas(através do qrefresh) no patch.
Linhas 67 ~ 75: É verificado que o patch continua aplicado (através do qapplied) e já que o patch está completo está na hora de armazena-lo e retirá-lo da lista de aplicados através do comando hg qpop que remove do topo da fila o patch e como o único e no topo é o fix_bug_01.patch não retorna nada o comando hg qapplied e então o patch é commitado através do hg qcommit essa fila de patchs é um outro repositório interno do mercurial, se você quiser confirmar é só entrar no .hg/patches do se repositório e rodar o comando hg glog para constatar o sub-repositório de patches criado pelo MercurialQueue.
Para exportar o patch pode usar o comando hg export <nome_do_patch> e para importar para o repositório normal use hg import ou se quiser importar para uma outra lista de patches hg qimport e então o patch será adicionado ao hg qseries.
Enfim as possibilidades são enormes com o MercurialQueue, e isso foi só uma demonstração básica do uso de MercurialQueues.
Ufa! Espero que alguém tenha paciência pra ler. Essa tá longe de ser a versão final desse post. Publiquei logo para ter um norte. Portanto agradeceria bastante as sugestões de melhoria, críticas, correções e etc.
Próximos posts(Aguardem) :
- Trabalhando com o Mercurial – Mais sobre MercurialQueues
- Trabalhando com o Mercurial – Rebaseando
- Trabalhando com o Mercurial – Resolvendo Conflitos
Compilação distribuída com ICECC no Debian/Ubuntu
Aug 12th
Para quem já compilou um projeto grande, ou seja, que possui uma quantidade considerável de código fonte sabe que demora bastante tempo para compilar, um exemplo disso é o Qt, que demora aproximadamente ~2 horas em uma máquina com 2 núcleos.
Optando pela dica de um amigo, consegui diminuir esse tempo de compilação para aproximadamente ~50 minutos usando 6 núcleos no total, 2 núcleos do meu notebook e mais 4 da minha estação de trabalho.
É algo bem simples de fazer, let’s do it
Primeiramente você precisa instalar o ICECC nos computadores que você irá compartilhar recursos para compilação e nada mais óbvio do que usar o apt-get ou aptitude:
~$ aptitude install icecc
Depois de instalado nas máquinas que você deseja utilizar os recursos é necessário configura-lás em um grupo para que elas possam se comunicar, em uma analogia equivalente seria como configurar um grupo de rede onde cada máquina consegue enxergar as outras porque estão no mesmo grupo. Para configurar essa rede é preciso editar o arquivo /etc/icecc/icecc.conf e colocar a seguinte diretiva apontando para o nome da rede:
ICECC_NETNAME=”nome_da_sua_rede“
onde tem nome_da_sua_rede substitua pelo o nome de sua preferência para a rede de compilação e configure essa diretiva com o nome que você definiu para cada máquina que você irá utilizar para a compilação e depois reinicie o daemon delas com:
sudo invoke-rc.d icecc restart
Nessa rede é preciso que ao menos uma das máquinas seja a responsável por distribuir os dados de compilação, pegar o retorno e juntar tudo. A essa máquina damos o nome de “Scheduler”, para configurar uma máquina como scheduler é preciso que o arquivo /etc/default/icecc esteja da seguinte forma:
# Defaults for icecc initscript
# sourced by /etc/init.d/icecc
START_ICECC=”true”
START_ICECC_SCHEDULER=”true”
# Defaults for icecc initscript
# sourced by /etc/init.d/icecc
START_ICECC=”true”
START_ICECC_SCHEDULER=”true”
E depois reiniciar o daemon com:
ICECC_NETNAME=”nome_da_sua_rede”
Dai em diante é só compilar algum código grande que você verá a diferença, também existe uma ferramenta para você monitar a compilação é o icecc-monitor, para instalar (nada mais óbvio):
sudo aptitude install icecc-monitor
Depois adicione o path do icecc ao seu $PATH, inserindo o seguinte comando no seu ~/.bashrc :
export PATH=/usr/lib/icecc/bin/:$PATH
source ~/.bashrc
E boa compilação, keep hacking!
Configurando nokia n810
Jan 21st
Configurar o nokia n810 no ubuntu é bem simples. Fiz um resumão..
Atualizando FirmWare
Eu tive que atualizar o firmware, para isso basta fazer o flashing. Faça o download do utilitário, depois faça o download do último firmware, recarrege a bateria do tablet, de preferência estando desligado. Após isso, se o tablet não estiver desligado, desligue-o e ligue o cabo usb e então basta executar:
./flasher-3.0 -F RX-44_DIABLO_5.2008.43-7_PR_COMBINED_MR0_ARM.bin -f -R
Dae, ele jogará na tela algumas mensages e a última será:
Suitable USB device not found, waiting
Dae você liga o tablet novamente e pronto ele irá atualizar o firmware. Para habilitar o R&D Mode,
basta fazer o mesmo processo só que ao invés de fazer o flashing da imagem basta fazer o seguinte:
./flasher-3.0 –enable-rd-mode
E então ligue o tablet para ele atualizar para o modo R&D. Depois reiniciei o tablet.
Conectividade usb
Você precisa instalar no tablet um pacote chamado maemo-pc-connectivity e após instalado o pacote, basta configura
o pc. Primeiro é preciso configurar o módulo responsável pela criação de interface de rede através da usb, o usbnet
sudo modprobe usbnet
Basta editar o arquivo “/etc/udev/rules.d/85-ifupdown.rules” e trocar:
SUBSYSTEM==”net”, DRIVERS==”?*”, TEST==”/var/run/network/initialized”, GOTO=”net_start”
por:
SUBSYSTEM==”net”, TEST==”/var/run/network/initialized”, GOTO=”net_start”
Depois acrescentar no /etc/network/interfaces:
auto usb0
allow-hotplug usb0
mapping hotplug
script grep
map usb0iface usb0 inet static
address 192.168.2.14
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
up iptables -t nat -A POSTROUTING -s 192.168.2.15 -j MASQUERADE
up echo 1 > /proc/sys/net/ipv4/ip_forward
down iptables -t nat -D POSTROUTING -s 192.168.2.15 -j MASQUERADE
down echo 0 > /proc/sys/net/ipv4/ip_forward
Estudando python EFL – edição especial :-P
Dec 16th
Bom, irei participar de um treinamento de python EFL onde o instrutor será o Gustavo Barbiery, tentarei fazer um resumo do curso até mesmo para que me sirva de referência futura e postarei aqui no blog, tenho conhecidos que trabalham e estudam também EFL e python e que ficaram tristes por não poderem participar do treinamento, infelizmente não é possível que todos participem. Mas como sou um cara legal e sempre gostei de compartilhar conhecimento , além de fazer o resumo do curso que conterá muito código de exemplo. Irei também reportar a evolução do curso pelo meu Twitter em tempo real. Para isso instalei um widget no sidebar do wordpress, o qual vocês podem acompanhar ao seu lado direito da tela.
Para quem tem twitter, pode me seguir e fazer perguntas sobre a tecnologia em tempo real, para quem não tiver, pode deixar comentário no blog pois ficarei o tempo todo on line. Não atenderei todas as perguntas, irei filtrar as mais interessantes, portanto caprichem nas perguntas (se houver) que na primeira oportunidade que surgir perguntarei ao Gustavo e postarei no resumo do blog a resposta, sei que muitas das minhas dúvidas são as dúvidas de outros que começaram a trabalhar com EFL a pouco tempo, portanto muita coisa será respondida no resumo que farei do curso e não de forma imediata.
Qualquer coisa, seja sugestão ou crítica comenta ai.
Update: Posts só sairão, no final de semana. Tá cruel, muita coisa pra fazer/estudar. 
SPL (Standard PHP Library) – DirectoryIterator
May 14th
Você conhece a SPL(Standard PHP Library) ? É uma biblioteca de componentes inteiramente escritos em PHP5 dentro do paradigma de Orientação a Objetos para lidar com problemas cotidianos na vida dos programadores que trabalham com PHP.
O ambiente onde este artigo foi desenvolvido/testado:
- PHP 5.2.1 SAPI CLI (Command Line Interface)
- Ubuntu Feisty Fawn
O que você precisa saber para aprender melhor o conteúdo ?
Recuperando arquivos deletados + Reiserfs
May 2nd
Ontem, minha esposa deletou por acidente seus 3.3GB de mp3…
Procurando no google achei o seguinte link: http://antrix.net/journal/techtalk/reiserfs_data_recovery_howto.html
Testei e funcionou, consegui recuperar os arquivos deletados, então decidir escrever uma dica rápida passo de como fazer a recuperação de seus arquivos tendo em vista que não achei nada ainda em português que podesse satisfazer minha dúvida.
O que há de errado com o Microsoft Windows Vista ?
Mar 19th
O novo sistema operacional Windows Vista da Microsoft é um grande passo retrógrado para a liberdade dos usuários.
Usualmente, novos softwares permitem você ir além com o seu computador. Vista, entretanto, é projetado para restringir o que você pode fazer.
Vista aborda as novas formas de “Gestão de direitos autoriais (GDD)” do inglês “Digital Rights Management (DRM)”. GDD é exatamente chamado de Gestão de direitos autoriais, por causa que é a tecnologia que a grande mídia e companias de computador tentam impôr para nós todos, para obter o controle de como nossos computadores são utilizados.
O especialista em segurança tecnológica Bruce Schneier explica mais concisamente:
“Windows vista inclui uma série de “funcionalidades” que você não almeja. Estas funcionalidades irão tornar o seu computador menos confiável e menos seguro. Eles irão tornar seu computador menos estável e fazer com que funcione mais lento. Eles irão causar problemas técnicos. Eles irão requerir que você faça atualizações de alguns dos seus periféricos de hardware e softwares existentes. E essas funcionalidades não irão fazer nada útil. De fato, eles estão trabalhando contra você. Eles são a Gestão de direitos autorais que vem embutido dentro do Vista que está por trás da indústria do entretenimento – E você não pode recusá-los. ”
DRM dá mais poder para Microsoft e a Grande Mídia.
- Eles decidem quais programas você pode e quais você não pode usar em seu computador.
- Eles decidem quais funcionalidades do seu computador ou software você pode usar em um determinado momento.
- Eles lhe forçam a instalar novos softwares mesmo que você não o queira (e, é claro, pagar pelo o privilégio).
- Eles restrigem seu acesso a certos programas e também seus próprios arquivos de dados.
DRM é reforçado por barreiras tecnológicas. Você tenta fazer algo, e seu computador diz que você não pode. Para isto se tornar efetivo, seu computador deve está constantemente monitorando o que você está fazendo. Este monitoramento usa recursos do computador e memória, e é a maior parte das razões do porque a Microsoft está dizendo que você tem que comprar novos e mais poderosos hardwares para utilizar o Vista. Eles querem que você compre novo hardware não por causa que você precisa, mais por causa que seu computador precisa para ser mais efetivo nas restrições do que você faz.
Microsoft e outras companias de computador, em alguns momentos referem a estas restrições como “Computação Confiável” do inglês “Trusted Computing”. Dado que estes foram projetados para fazer com o seu computador pare de confiar em você para começar a confiar na Microsoft, estas restrições são mais apropriadamente chamadas “Computação Traiçoeira” do inglês “Treacherous Computing”.
Mesmo quando você compra o Vista, você não o possui.
Windows Vista, como a versão anterior do Windows, é software proprietário: alugado para você por uma licença que restringe severamente como você pode usá-lo. e sem código fonte, portanto ninguém além da Microsoft pode alterá-lo ou mesmo verificar o que realmente ele faz.
Microsoft diz isto melhor:
O software é licenciado, não vendido. Este acordo lhe dá somente alguns direitos de usar o software. Microsoft reserva todos os outros direitos. A menos que a lei aplicável lhe dê mais direitos apesar desta limitação, você talvez use o software somente como expressamente permitido neste acordo. Deste modo, você deve concordar com qualquer limitações técnicas no software que somente permite uso de certas maneiras.
Para torná-lo ainda mais confuso, diferente versões do Vista possuem diferentes restrições de licença. Você pode ler todas as licenças em : http://www.microsoft.com/about/legal/useterms/default.aspx.
É doloroso ler estas licenças, e isto é o porque cada vez menos pessoas criam objeções para elas. Mas se nós não comerçamos com as objeções, nós iremos perder liberdades valiosas. Aqui estão algumas das restrições ridículas que você irá encontrar lendo:
- Se sua cópia do Vista vir com a compra de um novo computador, esta cópia do Vista só pode ser legalmente usado nesta máquina, para sempre.
- Se você comprou o Vista em uma loja de varejo e o instalou em computador que você já possuia, você tem que o deletá-lo completamente da máquina antes de instalar em outra máquina.
- Você dá a Microsoft o direito, através dos programas como Windows Defender, para deletar programas do seu sistema quando decidir que são spyware.
- Você consente em ser espiado pela Microsoft, através do sistema “Windows Genuine Advantage”. O sistema tenta identificar instâncias de cópia que a Microsoft acha ilegítimo. Infelizmente, um estudo recente indicou que este sistema já foi mexido[1] em mais de 500.000 casos.
Software livre como GNU/Linux não requer que você concorde com estes termos de licença absurdos. É chamado software livre porque você é livre para fazer quantas cópias você quiser, e compartilhá-lo com quantos amigos você desejar. Ninguém irá monitorar suas ações ou falsamente lhe chamar de ladrão.
O que você pode fazer para ajudar a proteger sua liberdade
Há uma batalha por trás entre aqueles que valorizam a liberdade, e corporações como a Microsoft cujo desejo é lucrar removendo esta liberdade. GDD e licenças absurdas são o coração da batalha. Porfavor junte-se a nós do lado da liberdade dizendo NÃO, não somente para o Windows Vista e outros produtos incorporados com GDD, mas para software proprietário em geral. Em troca, use produtos não-GDD, software livre como o sistema operacional GNU/Linux. Você pode trabalhar enquanto tendo certeza que seus direitos e liberdades não serão restringidos agora ou no futuro.
Como mais e mais coisas em nossa vida se tornam digital, é vital que nós protegemos nossa liberdade digital como nós sempre temos trabalhado para proteger nossa liberdade de expressão impressa e falada.
Entre na campanha BadVista.org hoje!.
[1] em inglês é Screwed Up, eu não conseguir achar uma tradução melhor.
———–x——————————————————————————–
Esta é uma tradução NÃO-OFICIAL de um artigo escrito por John Sullivan, para esclarecer perguntas que são comuns (pela quantidade de vezes que são abordadas).
O texto original encontra-se em: http://badvista.fsf.org/what-s-wrong-with-microsoft-windows-vista
Saiba mais sobre este assunto em http://defectivebydesign.org/.
É fato que a GDD está cada vez mais no nosso dia a dia e necessário que este conhecimento chegue ao maior número de pessoas possíveis.
Aqui estão mais 25 cents de contribuição.
Em trechos desta tradução usei palavras cotidianas, para facilitar o entendimento dos leitores, sempre tento deixar o texto mais simples e fácil possível de ser bem entendido, mas é claro que cometo erros seja na tradução ou no português, se acharem algum erro entrem em contato comigo ou deixem comentários para que eu possa corrigí-los e deixar o devido agradecimento e crédito a quem corrigiu o texto.
No mesmo site achei um belo wallpaper:
:wq!
powered by performancing firefox
