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:

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

1. Identicar nova funcionalidade e traçar funcionamento básico
2. Abrir uma ramificação(branch) do projeto
3. Codificar e testar na branch criada SOMENTE para esta feature
4. Unir(merge) tip da branche da nova feature ao tip da mainline (branche default) e commitar
5. 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 .

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:

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

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.

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.

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:

1. Você encontrou o problemas durante o desenvolvimento, antes de lançar uma versão.
2. 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:

1. Identificar a causa do problema
2. Consertar o bug
3. 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.

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

Tirei algumas fotos do evento apartir do meu E71, a câmera não é boa mas como estava de dia até que as fotos ficaram boas. Segue abaixo algumas fotos.

A foto acima é da oficina de D-Bus.

Coordenação do Flisol indo almoçar.

Mais fotos no meu flickr.

Também não pude deixar de contribuir e fiz uma palestra sobre Python com EFL e ajudei em algumas oficinas. Como prometi na minha palestra que iria postar a minha apresentação no blog, cá estou eu postando.

Slides Python e EFl

Segue abaixo os códigos que fiz de exemplo, mas faltou tempo para comentar linha a linha. Para quem quiser estudar segue código.

Exemplo animado:

Link para baixar tudo, inclusive a imagem. Só não esqueça que para executar é preciso ter instalado as EFL e os python bindings.Para a instalação tenho um post sobre. Confira.

Espero que tenham gostado do evento tanto quanto eu gostei. Qualquer dúvida, crítica e/ou sugestão pode colocar nos comentários.

Até a próxima.

Mesmo o howto sendo para debian funcionou perfeitamente no ubuntu 7.10. Para os que começaram a instalação e não terminaram ou fizeram alguma coisa errada e gostaria de seguir corretamente o howto passo a passo.

Se você por ventura quiser deletar e instalar novamente o scratchbox, você precisa parar o serviço de montagem dele com o seguinte comando:

#/scratchbox/sbin/sbin_ctl stop

e então remover o diretório:

#rm -Rfv /scratchbox

se você ainda tiver o cache dos pacotes que fica em /var/cache/apt/archives, basta você executar o reinstall do aptitude, somente trocando o install do post do marcelo pelo reinstall.

E então será criado novamente a estrura do scratchbox no raiz do sistema.

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 ?

• Orientação a objetos
• Exceptions
• UML (Opcional)

Um dos problemas que encontramos sempre é a questão de trabalharmos com iteração de diretórios, por exemplo um script para backup, localizar algum determinado tipo de arquivo dentro de um diretório com muitos sub-diretórios, efetuar mudança de nomes de forma recursiva dentre outros. Precisávamos de um solução elegante e legível para efetuarmos manutenção seja corretiva e ou implementativa, isso se torna mais importante quando você trabalha em equipe ou quando você deixa um código para que outro programador seja responsável pela manutenção. Outro ponto forte para a criação e utilização desta biblioteca é a questão de termos um ponto central de soluções(amplamente suportados) para problemas cotidianos assim agilizando o processo de desenvolvimento de software, ou seja, ao invés de termos que criar sempre uma solução para um problema que já tem solução(não seria re-inventar a roda ?!) ou fazer reutilização de software através de CTRL + C e CTRL V ( como era feito e que ainda é muito utilizado ).

Minha contribuição para que possamos melhorar o desenvolvimento de software onde tem como tecnologia de programação PHP5/6 é iniciar uma série de artigos explanando a utilização da SPL, tendo como início uma classe chamada DirectoryIterator.

Para entendermos melhor o DirectoryIterator precisamos dá uma olhadinha neste diagrama de colaboração, através da figura 1 abaixo:

Figura 1.

Como podemos interpretar esse diagrama de colaboração(Figura 1) o DirectoryIterator é uma classe que implementa a interface Iterator e extende a classe SplFileInfo.
O design da interface Iterator é segundo seu diagrama de colaboração o seguinte:

Figura 2

Basicamente a interface Iterator diz que a classe DirectoryIterator deve obrigatoriamente implementar os métodos current(), key(), next(), rewind(), valid(). Portanto isto quer dizer que um objeto DirectoryIterator pode ser atravessado/iterado/percorrido e que deve ter os controles básico para uma boa iteração de fila como ir para frente( next() ), voltar( rewind() ), atual ( current() ) e controle condicional ( valid() ).

Como ele extende a classe SplFileInfo, isso quer dizer que podemos acessar os métodos públicos desta classe, métodos como isFile(), isDir() , isExecutable()  dentre outros.

Com esse raciocínio básico podemos ir para o código, afinal “Talks is cheap, show me the code”.

$dirName = “/tmp”;
$dirObj = new DirectoryIterator($dirName);

$i = 0;
for(; $dirObj->valid() ; $dirObj->next() )
{
if( !$dirObj->isDot() )
{
print “$i -> {$dirObj->getPathname()} “.” ->; {$dirObj->getType()}\n”;
$i++;
}
}

O código acima mostra os arquivos e diretórios de um determinado diretório informado no construtor do objeto DirectoryIterator.

Basicamente na linha 2 é informado o diretório para ser visualizado e percorrido, na linha 3 é instanciado um objeto DirectoryIterator e o percorremos através de um for conforme visto na linha 5 e nos condicionais deste for podemos ver que estamos utilizando os métodos implementados na classe DirectoryIterator conforme a interface Iterator manda e isso nos dá os condicionais básicos e iteradores para percorrer/iterar este objeto.

Gostou ?! vamos dá um upgrade neste exemplo… vamos criar 2 funções recursivas, uma para guardar o enderecamento dos diretórios, sub-diretórios e seus arquivos em um Array e outra função para imprimir isso de forma recursiva:

/**
* Função para guardar os diretórios/sub-diretórios e seus arquivos
* respectivamente em um vetor(Array) de forma recursiva
*
* @params string $dirName
* @return array $arr
*/
function throughDir($dirName)
{
$dirObj = new DirectoryIterator($dirName);
for(; $dirObj->valid() ; $dirObj->next() )
{
if( $dirObj->isDir() and !$dirObj->isDot() )
{
$arr[$dirObj->getPathname()] = throughDir($dirObj->getPathname());
}
}
return $arr;
}

/**
* Função para imprimir os diretórios/sub-diretórios e seus arquivos
* respectivamente de um vetor(Array) de forma recursiva
*
* @params Array $dirName
* @return void
*/
function printDir($arrDirs)
{
if(is_array($arrDirs))
{
foreach($arrDirs as $dir => $subDir)
{
echo $dir.”\n”;
printDir($subDir);
}
}else{
echo $arrDirs.”\n”;
}
}

$arrDirs = throughDir(“/home/daniel/Desktop/”);
printDir($arrDirs);

Gostaram ?! é muito legal, tudo muito bom e claro perfeito senão tivessemos problemas para serem tratados.

Um dos problemas que podem ocorrer durante a execução de seu script é a falta de permissão para ler e ou abrir diretórios e arquivos, e se isso acontecer irá comprometer a execução de seu programa, ou seja, será finalizado.

No exemplo do código acima você vai conseguir percorrer os diretórios e sub-diretórios que você possuir permissão de leitura mas ao tentar percorrer um sub-diretório onde você não possui permissão para ler, o seu script finalizará a execução.

Um exemplo é você alterar o script anterior para percorrer um diretório que você não tenha permissão, você pode trocar a string “/home/daniel/Desktop” por “/tmp”, geralmente em “/tmp” sempre tem algo que o proprietário é o root e assim não permitindo que você possa ler o conteúdo. No meu caso olha no que deu:

daniel@blackforce:~/Desktop$ php teste2.php

Fatal error: Uncaught exception ‘RuntimeException’ with message ‘DirectoryIterator::__construct(/tmp/gconfd-root): failed to open dir: Permission denied’ in /home/daniel/Desktop/teste2.php:13
Stack trace:
#0 /home/daniel/Desktop/teste2.php(13): DirectoryIterator->__construct(‘/tmp/gconfd-roo…’)
#1 /home/daniel/Desktop/teste2.php(18): throughDir(‘/tmp/gconfd-roo…’)
#2 /home/daniel/Desktop/teste2.php(48): throughDir(‘/tmp’)
#3 {main}
thrown in /home/daniel/Desktop/teste2.php on line 13

Na maioria das vezes é possível fazer com que seu programa saiba com que tipo de erro está lidando e assim fazê-lo executar outros procedimentos para tentar ignorar o problema que o está impedindo de terminar com sucesso a execução.

Para tanto é necessário que você saiba como trabalhar com Exceptions, um exemplo de como capturar exceções no exemplo do código anterior é acrescentando um bloco de try / catch na funcção throughDir() para capturar o erro como no exemplo abaixo:
/**
* Função para guardar os diretórios/sub-diretórios e seus arquivos
* respectivamente em um vetor(Array) de forma recursiva
*
* @params string $dirName
* @return array $arr
*/
function throughDir($dirName)
{
try{
$dirObj = new DirectoryIterator($dirName);
for(; $dirObj->valid() ; $dirObj->next() )
{
if( $dirObj->isDir() and !$dirObj->isDot() )
{
$arr[$dirObj->getPathname()] = throughDir($dirObj->getPathname());
}
}
}catch(RuntimeException $erro){
print $erro;
}
return $arr;
}

Apenas com este tratamento de imprimir o erro olha o resultado da execução:

daniel@blackforce:~/Desktop$ php teste2.php
exception ‘RuntimeException’ with message ‘DirectoryIterator::__construct(/tmp/gconfd-root): failed to open dir: Permission denied’ in /home/daniel/Desktop/teste2.php:13
Stack trace:
#0 /home/daniel/Desktop/teste2.php(13): DirectoryIterator->__construct(‘/tmp/gconfd-roo…’)
#1 /home/daniel/Desktop/teste2.php(18): throughDir(‘/tmp/gconfd-roo…’)
#2 /home/daniel/Desktop/teste2.php(48): throughDir(‘/tmp’)
#3 {main}exception ‘RuntimeException’ with message ‘DirectoryIterator::__construct(/tmp/orbit-root): failed to open dir: Permission denied’ in /home/daniel/Desktop/teste2.php:13
Stack trace:
#0 /home/daniel/Desktop/teste2.php(13): DirectoryIterator->__construct(‘/tmp/orbit-root’)
#1 /home/daniel/Desktop/teste2.php(18): throughDir(‘/tmp/orbit-root’)
#2 /home/daniel/Desktop/teste2.php(48): throughDir(‘/tmp’)
#3 {main}/tmp/.tmp
/tmp/.tmp/tcx
/tmp/hsperfdata_daniel
/tmp/.ICE-unix
/tmp/.X11-unix
/tmp/.esd-1000
/tmp/kde-daniel
/tmp/gconfd-root
/tmp/orbit-daniel
/tmp/hsperfdata_root
/tmp/ksocket-daniel
/tmp/orbit-root
/tmp/ssh-KcBsL23144
/tmp/gconfd-daniel
/tmp/gconfd-daniel/lock
/tmp/virtual-daniel.XCv1fR
/tmp/epiphany-daniel-OTEfiF
/tmp/keyring-vrbWn3
/tmp/.exchange-daniel
/tmp/svbd9.tmp
/tmp/plugtmp
daniel@blackforce:~/Desktop$

Como podemos ver, o erro foi impresso mas não gerou nenhum Fatal Error na execução do programa, o script continuou a execução até o fim e se por acaso tivesse ocorrido outro erro por falta de permissão, novamente ele iria imprimir o erro e seguir em diante, tudo isso porque o Fatal Error é gerado porque você não está tratando devidamente as ocilações de comportamento de seu programa de uma forma adequada.

A única exceção que vimos foi a RuntimeException, mas este post já está muito grande e não quero me estender mais para não ficar muito cansativo de ler, além do que este assunto sobre Exceptions geradas pela SPL merece um artigo somente tratando de explanar sua lógica, forma de captura e tratamento.

Com certeza isso é só o início da uma apresentação sobre a SPL. Espero que com essa introdução à classe DirectoryIterator tenha ajudado de alguma forma a tirar dúvidas sobre esta classe.

Qualquer contribuição/sugestão/correção/reclamação será bem vinda.

Comente! ajude a melhorar a qualidade do artigo.. compartilhe conhecimento.

Fontes:

• http://www.php.net/~helly/php/ext/spl/
• http://www.php.net/manual/en/ref.spl.php

Updates:
Atualizado endereços das imagens para a nova url

O projeto Seeduca e GCompris Brasil decidiram em reunião compartilhar recursos e conhecimento para que haja uma melhor e maior colaboração entre os projetos, como segue a notícia no site do GCompris Brasil escrita pelo Frederico, mantenedor do projeto GCompris Brasil.

Eu como um dos membro do projeto Seeduca.org me sinto muito feliz com esta notícia, pois é algo que só tende a fomentar a cultura de software livre nos ambientes educacionais que se utilizam da informática e também nos chamados Edutretenimentos (Não sei se existe essa palavra!), mas seria softwares de entretenimento com foco educacional, ou seja, enquanto a criança brinca e se diverte  ela está aprendendo e se desenvolvendo.

Para os que ainda não estão por dentro:

O projeto Seeduca.org é “O projeto Seeduca é um projeto que visa disseminar e incentivar o uso do Software Livre na educação, pois acreditamos que o conhecimento e a inclusão digital nos meios educacionais não podem ser obtidos e plenamente compartilhados por meio de softwares não livres.”.

O projeto Gcompris Brasil é “O objetivo desse site é reunir os trabalhos de tradução, documentação e divulgação do software educacional GCompris aqui no Brasil. Todos estão convidados para colaborar com o projeto, que é aberto a qualquer pessoa.”.

Você que de alguma forma está envolvida na educação de crianças, jovens e adultos e gostaria de conhecer o projeto Seeduca e/ou GCompris entre na lista de discussão neste link e participe.

Vale ressaltar que as contribuições podem vir de quase qualquer área do conhecimento. Seja você programador,tradutor, pedagogo, educador, pai/mãe que se preocupa o desenvolvimento/criação de seu filho(a), entusiastas e etc.

Participem:

http://www.seeduca.org
http://gcompris.teia.bio.br em breve www.gcompris-br.org

:wq!

Powered by ScribeFire.

extension=php_gtk2.so

e pronto, apenas execute:

php5 -m | grep gtk

para checkar se sua extensão foi carregada com sucesso!

Lembrando que eu estou usando os pacotes do dotdeb.org, que é um ótimo repositório para quem gosta de testar e experimentar os novos releases do php.

powered by performancing firefox

Siga os passos

1. No /etc/modprobe.d/snd-hda-intel.modprobe adicione:

options snd-hda-intel model=3stack-6ch

2. No /etc/modprobe.d/alsa-baseadicione:

options snd-hda-intel model=3stack-6ch


3. No /etc/modules adicione:

options snd-hda-intel model=3stack-6ch

Isto foi o suficiente para funcionar o som, mas no how-to tem mais coisa:

• Reinicie o sistema operacional e abra o alsamixer.
• Mude o canal para 6ch
• Você tem que tirar do mudo o <PCM>,<SURROUND>,<LFE> e <CENTER>
• Plugue os headphones no laptop e pronto! é para funcionar

O único problema encontrado é que os speakers do laptop não funcionam, talvez seja um bug ?! Não sei, se eu encontrar a solução eu posto.

Obs: Mas este problema não foi encontrado na configuração deste laptop. Cada caso é um caso!

Tudo para ajudar um amigo Antônio Jr (aka Brankinhu)! Devia escutar mais vez Kreator!!!

powered by performancing firefox

É uma dica rápida pra quem não quer ficar mexendo no source list alterando edgy para feisty ou s/edgy/feisty/g

Este Release não é recomendável para produção, ou seja, não é garantido que ele funcione, pacotes podem quebrar, programas podem não funcionar e etc, e eu não me responsabilizo se você tiver problemas na atualização para versão em desenvolvimento do Ubuntu Feisty Fawn, basicamente:

Abra o terminal de digite:

sudo update-manager –devel-release

e espere ele baixar uns 1000 pacotes, claro que isto varia conforme a quantidade de pacotes que você possui atualmente instalados.

O Alysson Oliveira publicou um jeito de fazer funcionar OO sem ‘créshar’, um “workaround”, segui as instrunções e funcionou, os passos seguem abaixo.

Todos os passos foram executados como root.

1.

#echo “LD_PRELOAD=/usr/lib/libdbus-1.so.3 /usr/bin/ooffice $1 $2 $3 $4″ > /usr/bin/ooffice2

2.

#gedit /usr/share/applications/ooo-writer.desktop

3. Mude a linha 5 de:

Exec=ooffice -writer %U

3.1. Para:

Exec=ooffice2 -writer %U

Repita os passos 3 e 3.1 para os demais arquivos:

/usr/share/applications/ooo-base.desktop
/usr/share/applications/ooo-draw.desktop
/usr/share/applications/ooo-math.desktop
/usr/share/applications/ooo-calc.desktop
/usr/share/applications/ooo-impress.desktop

Outro “workaround” é criar um alias e colocar no profile

# echo ooffice=”LD_PRELOAD=/usr/lib/libdbus-1.so.3 /usr/bin/ooffice $1 $2 $3 $4″ > /etc/profile

Esta não é maneira correta de fazer as coisas acontecerem, o certo seria recompilar o OO e ajeitar o DBUS, mas recompilar o OO não é tão simples e mesmo compilando fugiria aos padrões Ubuntu de qualidade/integridade dos pacotes, em breve irá sair do forno o pacote corrigido, a importância desse bug é “High”, ou seja, tem prioridade!.

Até lá, eu vou me virando com esse “workaround” mesmo.

Postei porque foi útil pra mim e talvez seja para outra pessoa.

Link: https://launchpad.net/distros/ubuntu/+source/openoffice.org/+bug/58508