Life Data

CFTV com Zoneminder e Linux

noreply@blogger.com (Renato) — Tue, 15 Nov 2011 01:26:00 +0000

Resolvi a algum tempo instalar um sistema de vigilância para minha casa.
Por acaso acabei encontrando no DealExtreme uma placa de captura para câmeras de vigilância que, pelos comentários, era facilmente configuravel no Linux.
Tomei então a iniciativa de pesquisar um pouco e montar meu próprio sistema de monitoramento e gravação utilizando o Zoneminder.

Uma das primeiras dúvidas foi qual sistema utilizar, qual *nix flawor, qual hardware, quanto de espaço para armazenamento, qual a necessidade real de processador, etc.
Muitas dessas perguntas ainda não possuo uma resposta ou regra básica para determinar, mas neste texto vou descrever os passos que tomei para deixar o sistema funcional.

HARDWARE:
Como motor do sistema, após ver diversos comentários do tipo "utilize seu velho pc", resolvi adotar uma motherboard de "baixo consumo".
Por não ser algo comum foi um pouco problemático escolher, mas acabei encontrando uma VIA PC1 da Phitronics na loja da JNE Informática da Av. Paulista.
A configuração é modesta, um processador VIA C7-M de 1.6Ghz com o básico encontrado onboard atualmente, USB 2.0, som, ethernet e adaptador VGA.
O modelo que encontrei foi o VIA PC3000E+.

Adicionei à motherboard 2GB de memória DDR2 e dois HDs, sendo um IDE de 40GB para o sistema e um SATA de 1.5TB para armazenamento das gravações.
É necessário que o equipamento possua bastante memória já que o Zoneminder faz uso de memória compartilhada entre seus processos para tratamento e detecção de movimento.
Já o armazenamento grande é obvio, pretendo manter as gravações por um período extenso e isso requer espaço.

A placa de captura que acabei encomendando da China não é uma Ferrari, mas tem um preço baixo e para meu sistema pareceu o bastante.
4-Channel DVR Video Capture PCI Card for 25/30 FPS Security Cameras

As câmeras, apenas duas até o momento, requisitei da loja Ribershop que encontrei no MercadoLivre, loja essa que se mostrou bastante rica em equipamentos para segurança.
Optei por duas câmeras CCD no padrão NTSC que é o mesmo operado pela placa de captura.

Tudo montado, vamos ao software.

SOFTWARE:
Enfrentei diversas dores de cabeça e perdi um tempo consideravel testando algumas opções de sistema operacional até chegar ao Debian como o mais indicado para meu projeto.
Dentre as tentativas, desisti do Ubuntu por ser extremamente integrado com o sistema gráfico e não pretendo utilizar um monitor ligado ao sistema, ficando muito complicado efetuar uma "limpeza" do sistema base instalado e o que mais pretendo é ter uma formula rápida para montar o mesmo.

Testei também o FreeBSD 8.2 e mesmo sabendo que o suporte do driver do sistema para a placa de captura poderia não ser eficiente o bastante, sequer consegui testar o mesmo pois a instalação do Zoneminder a partir do ports foi falha e também precisava de diversas configurações para deixar o mesmo funcional.

Ao chegar na minha terceira tentativa, o Debian 6, pela facilidade de instalar o ambiente acabei parando com os testes de escolha e decidi partir para produção.

Configurações:

Após ter o sistema básico instalado, pode-se instalar o Zoneminder com apenas um comando:


apt-get install zoneminder

O mesmo vai instalar todo o ecosistema de softwares necessários para a execução do ZM, a base de dados inicial no MySQL, os scripts de inicialização do sistema, Apache, PHP5 e as bibliotecas e programas necessários para manipulação de imagens/vídeo.

A única ação necessária para acessar o console do ZM foi informar ao Apache dos arquivos do mesmo:


ln -s /etc/zm/apache.conf /etc/apache2/sites-available/zm
a2ensite zm
apache2ctl restart

Após isso você pode acessar o console na url http://ipdoservidor/zm

Problemas:

Até aqui, tudo muito fácil, a parte complexa que vou resumir foi encontrar as configurações corretas para o ZM funcionar com o hardware descrito.

UDEV
O primeiro detalhe é a permissão de acesso ao dispositivo da placa de captura.
Após a instalação, sem qualquer configuração o Linux já havia detectado minha placa de captura e criado o device /dev/video0.
No entanto, as permissões do mesmo não deixavam o ZM acessar o dispositivo e mesmo mudando com chmod após a reinicialização as permissões padrão eram retornadas.
Para resolver isso foi necessário criar uma regra para o udev que determine quais permissões devem ser dadas ao dispositivo.

Criei então o arquivo /etc/udev/rules.d/70-persistent-bttv.rules com o seguinte conteúdo:


KERNEL=="video*", GROUP="video", MODE="0666", OPTIONS="last_rule"

Após o reboot, as permissões estavam corretas.

BTTV
Embora o kernel Linux reconheça o chipset de captura automaticamente, esta não fica 100% funcional sem informarmos qual "placa" o sistema deve utilizar.
Para isso foi necessário informar ao driver bttv qual o modelo da mesma com o seguinte código:


echo "options bttv card=77" >> /etc/modprobe.d/bttv.conf

Feito isso, na próxima carga do driver (reboot ou rmmode/modprobe) deverá ser encontrado nas mensagens do dmesg algo do tipo:

bttv0: using: GrandTec Multi Capture Card (Bt878) [card=77,insmod option]

E sua placa está pronta para utilização.

TWEAKS:

Neste ponto, o ZM já está instalado e funcional, e você pode brincar na interface do console adicionando monitores, item que não pretendo discutir no momento.
Apenas para nota de alguns outros detalhes interessantes e possívelmente necessários, vou deixar mais algumas notas.

SHMMAX
Como descrito anteriormente, o ZM utiliza espaço de memória compartilhada para processar as imagens que captura da placa.
A questão é que nem sempre o valor padrão do sistema é o bastante. Para aumentar esse valor, criamos uma regra de sysctl:


echo "kernel.shmmax = 134217728" >> /etc/sysctl.d/60-kernel-shm.conf

CAMBAZOLA
No console do ZM é possível acessar as imagens capturadas no monitor de câmeras (clique no nome do monitor). O detalhe é que o mesmo exibe por padrão uma imagem estática que é recarregada de tempos em tempos utilizando javascript.
Para visualizar um fluxo "contínuo" de imagens, podemos utilizar o applet Cambazola que faz esta carga de forma transparente.
Precisamos apenas efetuar o download do mesmo, copiar o arquivo cambazola.jar na pasta raiz do ZM e informar que o mesmo deve utiliza-lo.


wget http://www.charliemouse.com/code/cambozola/cambozola-latest.tar.gz
tar -zxvf cambazola-latest.tar.gz
cp cambazola-/dist/cambazola.jar /usr/share/zoneminder

Para configurar o Zoneminder, acesse o link opções do console e no painel Images utilizar as seguintes opções:


CAN_STREAM: auto
STREAM_METHOD: jpeg
OPT_CAMBOZOLA: sim (check)
PATH_CAMBOZOLA: cambazola.jar

ARMAZENAMENTO
Embora esta dica não seja diretamente ligada ao Zoneminder, a mesma me fez perder um tempinho para descobrir.
Como possuo um dois HDs, pretendo utilizar o maior apenas para armazenamento das gravações.
O procedimento no Debian é relativamente simples:

fdisk -l

Lista quais HDs estão plugados na placa mãe e suas patições.


cfdisk /dev/sd

Para editar as partições do seu segundo disco.


mkfs.ext3 /dev/sd

Para formatar o mesmo após editar as partições.

Após isso pode-se montar o disco aonde desejar e criar um link da pasta /usr/share/zoneminder/events para a pasta montada.
Meu problema ocorreu com o fato que durante o boot era atribuído um nome de device para o HD secundário e após a inicilização o mesmo era alterado, ou seja,
após incluir uma entrada no fstab para a montagem automática do mesmo, na inicialização do sistema o kernel montava o hd secundário no lugar do primário
e acabava efetuando um checkforced.

Para resolver isso precisamos utilizar os UUIDS dos HDs.


blkid

O comando blkid lista os UUIDS dos HDs e com o mesmo é possível criar um fstab que não depende da nomenclatura do device no /dev

Ficamos com uma entrada no fstab do tipo:


UUID=a5a06f7d-91d4-406f-8000-748b3ee444f2       /home/zm      ext3   defaults,noatime,nodiratime,errors=remount-ro    0      2

Note que utilizei também as opções noatime,nodiratime, as mesmas são um pequeno ajuste para reduzir o tempo de acesso ao disco já que não me importo, neste caso, com o registro de quando foi o último acesso aos arquivos/diretórios.

CRONTAB
Finalizando, embora tenha um espaço consideravel de armazenamento, o mesmo não é infinito.
Resolvi então limitar a 10 dias de gravação apenas.
Não pesquisei muito se existe uma forma de fazer isso a partir do próprio zoneminder mas, para início, uma simples linha no crontab resolveu meu problema:


0 0 * * * find /home/zm -name "*.jpg" -mtime +10 -exec rm -f {} \;

Isto vai apagar apenas as imagens que o zoneminder cria na pasta de eventos que tenham mais que 10 dias, mas isso não apaga a referência que o ZM faz aos mesmos.

Conclusão
Espero que, com um pouco mais de uso do Zoneminder, possa escrever mais detalhes sobre ajustes e melhorias neste setup, mas com esses passos é possível reproduzir o mesmo sistema que tenho como funcional no equipamento descrito.
Boa sorte a quem tentar o mesmo :)

Diretórios vazios com o Git

noreply@blogger.com (Renato) — Thu, 31 Mar 2011 20:25:00 +0000

Diversas vezes eu precisei manter um diretório vazio na árvore do projeto mas como o Git é um gerenciador de conteúdo, um diretório vazio não pode existir no repo.

Uma solução simples é criar um arquivo .gitignore dentro de cada diretório que você queira manter e depois adicionar todo o conteúdo da pasta, com excessão dos arquivos .gitignore, ao .gitignore padrão.

Exemplo:
Digamos que você quer manter a pasta public/uploads/images vazia no repo.
Crie um arquivo .gitignore no caminho public/uploads/images/.gitignore
Edite o arquivo .gitignore padrão (na pasta raiz do projeto) e adicione as seguinte linhas:


public/uploads/images/*
!.gitignore

A ordem das regras é importante.
Efetue um commit destas alterações adicionando os arquivos .gitignore e pronto.

*Nota:
Caso já existam arquivos no diretório que tenham sido comitados anteriormente, exclua os mesmos com o comando:

git rm --cached /caminho/do/arquivo

Happy Coding!!!

Arduino - Teste 1

noreply@blogger.com (Renato) — Sun, 13 Feb 2011 16:12:00 +0000

Seguindo a listinha de simples projetos para ir me familiarizando com o Arduino, o primeiro projetinho é bem simples, um botão, um led e dois resistores.

A idéia é utilizar o Arduino para ler o estado do botão e dependendo do mesmo ligar ou desligar o led. Dei um pequena incrementada para fazer o led piscar enquanto o botão estiver precionado.

Incrivelmente, demorei mais para tirar as fotos e fazer este post do que para montar o esquema eletrônico, o código e colocar o mesmo para rodar no Arduino.

Arduino

noreply@blogger.com (Renato) — Sun, 13 Feb 2011 15:10:00 +0000

Eletrônica sempre me chamou a atenção.
É um pouco trabalhoso dependendo do que se vai fazer, mas como no desenvolvimento de software, com um pouco de emprenho consegue-se construir algo interessante.

Em 1994 eu estudava eletro-eletrônica, mas acredito que desde 1996 eu não estudava ou construia qualquer coisa utilizando componentes eletrônicos e ferro de solda.

Mais ou menos por acaso, li alguns artigos na web sobre um produto chamado Arduino.
O Arduino é um projeto de eletrônica que visa facilitar o desenvolvimento de projetos de eletrônica digital e o estudo da mesma.

Existem diversas vantagens em utilizar uma placa como o Arduino para estudar, e as possibilidades são inúmeras, dependendo apenas da imaginação de quem constrói.
Tanto que um dos projetos mais interessantes que já vi feito com o mesmo é uma impressora 3D.

A lista de projetos que se pode encontrar é grande, com uma variedade espantosa, como pode ser visto na lista de videos do Vimeo que se encontra na url http://vimeo.com/groups/arduinoprojects/videos

Um dos grandes detalhes é o fato de ser um projeto Open Source, ou seja, o projeto da placa do Arduino e diversos outros, tais como a impressora 3d, possuem seus esquemas disponíveis para download. É o mundo Open Source, tão popularizado por projetos como o Linux, no mundo da eletrônica.

Conclusão, comprei um kit de iniciante na loja brasileira Robocore e pretendo retomar meus estudos de eletrônica com o mesmo.... vamos ver no que vai dar.

Zend_Filter_Hashpath

noreply@blogger.com (Renato) — Sat, 18 Dec 2010 01:11:00 +0000

No passado, tive alguns problemas com o armazenamento de muitos arquivos de imagens em apenas um diretório.

Quando o volume ficava muito grande, não era sequer possível listar o conteúdo pelo console.

Depois desse episódio, passei a gravar os arquivos em subpastas, mas quase sempre acabava reescrevendo o código que fazia isso.

Para solucionar esse problema criei um filtro que denominei Zend_Filter_Hashpath.

Ele foi baseado na lógica do filtro Zend_Filter_File_Rename e em parte do código do Zend_Cache_Backend_File.

Bom, mais info no repo e no código fonte:

https://github.com/renatoaquino/Zend_Filter_Hashpath

Humor de Programador

noreply@blogger.com (Renato) — Wed, 01 Sep 2010 12:51:00 +0000

Quem disse que programadores não tem senso de humor?
O comentário abaixo foi retirado de uma resposta do stackoverflow:

// 
// Dear maintainer:
// 
// Once you are done trying to 'optimize' this routine,
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
// 
// total_hours_wasted_here = 16
//

Mais no stackoverflow.

TED x SP

noreply@blogger.com (Renato) — Tue, 13 Oct 2009 14:15:00 +0000

A um tempinho eu escrevo ou adiciono links de videos que assisto do TED que acho interessantes.

Desta vez estou escrevendo a respeito para avisar que será realizada uma das convenções do em São Paulo.

Os palestrantes, como se espera do TED, fazem parte das mais diversas áreas.
Entre eles temos Regina Casé atriz e apresentadora, Ronaldo Lemos diretor de Técnologia e Sociedade na escola de direito da FGV, entre outros.

Para participar está sendo feita uma triagem questionando sobre o que o "Brasil pode oferecer ao mundo" e "O que o inscrito tem a oferecer ao Brasil", entre outras.

Você pode também acompanhar via Twitter em http://twitter.com/tedxsp.

Espero que seja tão interessante quanto os demais vídeos que já assisti deste projeto.

A parábola do Git

noreply@blogger.com (Renato) — Wed, 10 Jun 2009 16:55:00 +0000

Resolvi fazer uma tradução livre do texto The Git Parable do Tom Preston-Werner.
Boa leitura....

A parábola do Git

Git é um sistema simples mas extremamente poderoso.
A maioria das pessoas tentam ensinar Git pela demonstração de alguns comandos chegando a um "tadaaaaa.", acredito que este método seja ineficiente. Esta abordagem vai ensiná-lo a usar Git para realizar tarefas simples, mas os comandos irão sempre parecer encantamentos mágicos.
Fazer qualquer coisa além do trivial será aterrorizador. Enquanto não compreender os conceitos nos quais o Git é feito você se sentirá perdido.

A seguinte parábola vai levá-lo através da criação de um sistema similar ao Git a partir de sua base. Entender os conceitos apresentados aqui é a melhor preparação para alcançar o poder total do Git.
Os conceitos em si são bastante simples, mas criam uma imensa gama de funcionalidades. Leia esta parábola do começo ao fim e deverá ter poucos problemas para tornar-se um mestre nos vários comandos do Git, liberando o maravilhoso poder que o mesmo disponibiliza.

A parábola

Imagine que você tem um computador que não tem nada além de um editor de textos e alguns comandos de sistema de arquivos.
Agora, imagine que você decidiu escrever um grande programa neste sistema. Como você é um desenvolvedor responsável, decidiu que precisa inventar alguma forma de manter o registro das versões de seu programa de forma que possa recuperar códigos que tenham sido alterados ou excluídos.
O que segue é uma história sobre como você pode arquitetar tal sistema de controle de versão (VCS) e a razão por traz das escolhas da arquitetura.

Fotocópias ( Snapshots )

Alfredo é um amigo seu que trabalha no supermercado como fotógrafo em uma boutique tipo "Momentos Especiais".
Fica o dia inteiro tirando fotos de garotinhos com poses esquisitas com um fundo de selva ou oceano.
Durante um de seus freqüentes almoços no stande de pretzels, Alfredo lhe conta uma história sobre uma mulher de nome Hazel que traz sua filha
para tirar um retrato todo ano no mesmo dia. "Ela traz todas as fotos dos anos anteriores junto" lhe conta o Alfredo.
"Ela gosta de recordar como sua filha era em cada fase diferente, como se aquelas fotocópias pudessem realmente fazê-la mover o tempo até o instante daquelas memórias."

Repentinamente, a colocação inocente do Alfredo age como um catalisador para você enxergar um solução ideal para seu dilema de controle de versão.
Fotocópias ou snapshots, como pontos de salvamento em um vide-o game, são realmente o que lhe importa quando precisa interagir com um sistema de controle de versão.

E se você pudesse tirar fotocópias do seu código a qualquer momento e ressuscitar esse código quando quizese?
Alfredo percebe o sentimento de realização espalhado por todo seu rosto e sabe que você está a ponto de deixá-lo sem dizer uma palavra e vai implementar qualquer idéia genial que ele acabou de lhe causar. Você não o desaponta.

Você começa seu projeto em um diretório chamado working. Conforme você programa, tenta implementar uma característica por vez.
Quando completa uma parte auto-contida da característica, certifica-se que todos os arquivos foram salvos e faz então uma cópia do diretório de trabalho, dando a ele o nome snapshot-0. Depois de efetuar a cópia, garante que ela nunca será alterada.

Após a próxima parte do trabalho, você faz outra cópia, mas desta vez o novo diretório é denominado snapshot-1, e assim por diante.

Para recordar quais mudanças você fez em cada snapshot, você adiciona um arquivo especial chamado mensagem a cada diretório de snapshot que contém
um resumo do trabalho efetuado e a data de realização. Verificando o conteúdo de cada arquivo mensagem fica fácil de encontrar uma mudança específica feita no passado, caso você tenha que ressuscitar algum código antigo.

Galhos ( Branches )

Após algum tempo no projeto, uma versão candidata à publicação começa a surgir. Madrugadas no teclado finalmente geraram o snapshot-99, a forma
nascente do que será a Versão de Publicação 1.0. Então esta cópia é empacotada e distribuída às massas sedentas que aguardam.
Tocado pela excelente resposta ao seu software, você se esforça, determinado a fazer com que a próxima versão seja um sucesso ainda maior.

Seu VCS até então tem sido um companheiro a prova de falhas.
Versões antigas de seu código estão lá e quando você precisa delas podem ser encontradas facilmente. Mas, não muito após sua publicação, relatórios
de erro começam a chegar. Ninguém é perfeito, você afirma a si mesmo, e o snapshot-99 está pronto para ser recuperado, orgulhoso por ser trazido
de volta para serem aplicadas as correções dos problemas.

Desde a publicação, você criou outros 10 snapshots. Este novo trabalho não deve ser incluído na versão correção de erros 1.0.1 que você vai criar.
Para resolver isso, você copia o snapshot-99 para working, deixando seu diretório de trabalho exatamente no ponto onde a versão 1.0 foi publicada.
Algumas linhas de código são tratadas e o problema está corrigido.

É neste momento que um problema torna-se aparente. o VCS trata muito bem com desenvolvimento linear, mas pela primeira vez, você precisa criar
um novo snapshot que não é descendente direto do último. Se você criar o snapshot-110 ( lembre-se que você já criou 10 cópias desde a publicação),
vai interromper o fluxo linear e não terá como determinar o ancestral da cópia. Claramente você precisa de algo mais poderoso que este sistema linear.

Estudos demonstram que mesmo pequenas exposições à natureza podem ajudar a recarregar o potencial criativo da mente.
Você esteve atrás da luz polarizada artificialmente de seu monitor por dias. Uma caminhada através das árvores sob o ar de outono vão lhe fazer bem
e com alguma sorte, ajudá-lo a encontrar uma solução ideal para seu problema.

Os grandes carvalhos que margeiam a trilha sempre lhe agradaram. Eles parecem repousar rígidos e orgulhosos do perfeito céu azul.
Metade das folhas avermelhadas caíram de seus galhos, deixando um intrincado padrão de galhos como rastro.
Fixando em um dos milhares de tipos de galhos você pacientemente tenta seguí-lo de volta até o solitário tronco.
Esta estrutura organicamente produzida permite esta grande complexidade, mas as regras para encontrar o caminho de volta para o tronco são tão
simples e perfeitas para manter o caminho de múltiplas linhas de desenvolvimento!
Vem a tona que é verdadeiro o que dizem a respeito da natureza e criatividade.

Observando seu histórico de desenvolvimento como uma árvore, resolver o problema de ancestralidade torna-se trivial.
Tudo que você precisa é incluir o nome da snapshot pai no arquivo de mensagem que você escreve para cada snapshot.
Adicionando apenas um único ponteiro para o antecessor possibilitará, fácil e precisamente, traçar o histórico de um snapshot, todo o caminho
de volta até sua raiz.

Nomes de Galhos ( Branch Names )

Seu histórico de código é agora uma árvore. Ao invés de ter apenas um único último snapshot, você tem duas: uma para cada galho ou 'branch'.
Com um sistema linear, seu sistema de numeração seqüencial permite facilmente identificar o último snapshot. Agora esta habilidade foi perdida.

Criar novos branchs de desenvolvimento tornou-se tão simples que você vai tirar vantagem disso o tempo todo.
Você criará branchs para fixar as antigas publicações, para experimentos que podem não serem concluídos; de fato torna-se possível criar um novo
branch para cada nova característica iniciada!

Mas como tudo bom na vida, existe um preço a ser pago. Cada vez que você cria um snapshot, você precisa lembrar que ele se torna o último no
seu próprio branch. Sem esta informação, alternar para um novo branch seria um trabalho extremamente penoso.

Toda vez que cria um novo branch você provavelmente da uma nome para ele em sua cabeça. Você provavelmente diz: "Este será o branch de manutenção da Versão 1.0".
Talvez prefira referir ao formal branch de desenvolvimento linear como o branch "mestre" ou "master".

Pense nisso um pouco mais profundamente. Da perspectiva de uma árvore, o que significa dar nome a um galho?
Nomear cada snapshot que aparecer no histórico de um branch resolveria seu problema, mas iria requirir o armazenamento de uma potencialmente grande
quantia de dados. Adicionalmente, isso ainda não ajudaria a eficientemente encontrar o último snapshot de um branch.

A única informação necessária para identificar um branch é a localização do último snapshot daquele branch.
Se precisar saber a lista de snapshots que são parte de um branch pode facilmente traçar pelo parentesco.

Guardar o nome do branch é trivial. Em um arquivo chamado branchs, armazenado fora de qualquer snapshot específico, você simplesmente
lista os pares nome/snapshot que representaram os branchs. Para alternar para um branch nomeado precisa apenas procurar pelo snapshot
correspondente neste arquivo de referencia.

Como você está armazenando apenas o último snapshot de cada branch, criar um novo snapshot contêm um passo adicional.
Se seu novo snapshot estiver sendo criado como parte de um branch, o arquivo de branchs precisa ser atualizado para que o nome do mesmo fique
associado com o último snapshot. Um pequeno preço a pagar pelo benefício.

Etiquetas ( Tags )

Após utilizar branchs por um tempo, você percebe que eles podem servir para dois propósitos. Primeiro, ele podem atuar com ponteiros de snapshots
para que você possa manter o rastro dos branchs. Segundo, podem apontar para um snapshot específica e nunca mudar.
O primeiro caso permite manter o desenvolvimento em execução, coisas como "Manutenção de Publicação". O segundo caso é útil para marcar pontos de
interesse, tais como "Versão 1.0" ou "Versão 1.1".

Misturar ambos os usos em apenas um arquivo parece bagunçado. Ambos os tipos são ponteiros para snapshots mas um muda e outro não.
Para clarificar e manter a solução elegante, você decide criar outro arquivo chamado etiquetas (tags) para manter ponteiros do segundo tipo.

Manter estes ponteiros, dois parentes comuns, em arquivos separados ira ajudá-lo a não tratar acidentalmente um branch como tag e vice-versa.

Distribuído ( Distributed )

Trabalhar por si mesmo acaba tornando-se bastante solitário. Não seria legal se pude-se convidar um amigo para trabalhar em seu projeto com você?
Bem, você está com sorte. Sua amiga Zoe tem um sistema de computador como o seu e quer ajudar no projeto. Como você criou um ótimo sistema de
controle de versão, acaba contando a ela sobre o mesmo e envia uma cópia de todos seus snapshots, branchs e tags para que ela possa aproveitar
dos mesmos benefícios do histórico de versões.

É ótimo ter Zoe no time mas ela tem o hábito de fazer longas viagens para lugares distantes e sem acesso à internet.
Assim que ela pegou o código fonte, saiu em um vôo para a Patagônia e você não ouviu falar dela por uma semana.
Neste meio tempo, ambos programaram uma tempestade. Quando ela finalmente voltou, você descobriu uma falha critica no seu VCS.
Como ambos estavam utilizando o mesmo sistema de numeração, cada um possui diretórios chamados 'snapshot-114', 'snapshot-115' e assim por diante,
mas com diferentes conteúdos.

Para piorar as coisas, você nem sabe quem produziu as alterações daquelas novas fotocópias. Juntos, concebem então um plano para tratar destes problemas.
Primeiro, as mensagens dos snapshots irão obrigatoriamente conter o nome do autor e seu e-mail. Segundo, snapshots não serão mais nomeadas por
simples números. No lugar disto, vocês utilizarão o conteúdo do arquivo de mensagem para produzir uma cifra ou hash. Este hash será garantidamente única
para o snapshot já que duas mensagens nunca terão a mesma data, mensagem, antecessor e autor.
Para fazer as coisas correrem suavemente, ambos concordam em utilizar o algoritmo de hash SHA1 que pega o conteúdo de um arquivo e produz uma
palavra de 40 caracteres hexadecimais. Ambos atualizam seus históricos com a nova técnica no lugar dos colisivos diretórios 'snapshot-114' e agora
possuem diretórios distintos nomeados ‘8ba3441b6b89cad23387ee875f2ae55069291f4b’ e ‘db9ecb5b5a6294a8733503ab57577db96ff2249e’.

Com a atualização do esquema de nomenclatura, torna-se trivial recuperar todas as cópias do computador de Zoe e colocá-las no seu repositório.
Como cada cópia especifica sua antecessora, quando possuem mensagens idênticas ( e também cópias idênticas ) possuirão os mesmos nomes não importa
onde são criados, o histórico da base de código pode continuar a ser mantido como uma árvore. A diferença é que a árvore é construída por snapshots
criadas por Zoe e você.

Este ponto é importante o bastante para garantir repetição. Uma cópia é identificada pelo SHA1 que a identifica unicamente ( e seu antecessor ).
Estes snapshots podem ser criadas e movidas entre computadores sem perder sua identidade ou onde pertencem no histórico da árvore do projeto.
Ainda mais, cópias podem ser compartilhadas ou mantidas privadas de acordo com sua vontade. Se você possuir alguns snapshots experimentais
que deseja manter para si mesmo, pode fazê-lo facilmente. Apenas não as torne disponíveis para Zoe!

Desconectado ( Offline )

O hábito de viajar de Zoe a faz passar incontáveis horas em aviões e barcos. A maior parte dos lugares que visita não possui acesso à internet disponível.
No fim do dia, ela passou mais tempo desconectada que conectada.

Não é surpresa, no entanto, que Zoe adora seu VCS. As operações do dia a dia que ela precisa fazer podem ser efetuadas localmente. O único momento
que ela precisa de uma conexão de rede é quando está pronta para compartilhar seus snapshots com você.

Junções ( Merges )

Antes de Zoe sair para sua viagem, você pediu-a para trabalhar em um branch chamado 'math' e para implementar uma função que gera números primos.
Neste meio tempo, você esteve também esteve desenvolvendo algo no branch 'math', só que esteve trabalhando na função que gera números mágicos;
Agora Zoe retornou e você está encarando a tarefa de unir estes dois diferentes branchs de desenvolvimento em uma único snapshot.
Como ambos trabalharam em tarefas distintas, a junção é simples. Enquanto construía a mensagem do snapshot para a junção, você percebe que esta
snapshot é especial. No lugar de ter apenas um antecessor, esta junção, ou merge, possui dois! O primeiro é a sua última snapshot no branch 'math'
e o segundo é o branch 'math' de Zoe. O snapshot de junção contêm todas as mudanças além daquelas necessárias para unir os dois antecessores em uma
única base de código;

Completado o merge, Zoe pega todos os snapshots que você possui e ela não, o que inclui seu desenvolvimento no branch 'math' e sua snapshot de merge.
Uma vez que ela fez isso, ambos os históricos casam perfeitamente!

Reescrevendo o Histórico ( Rewriting History )

Como muitos desenvolvedores de software, você tem a compulsão de manter seu código limpo e muito bem organizado. Isso leva ao desejo de manter seu
histórico de código com esmero. Noite passada você chegou após tomar alguns goles de Guinness em um bar e começou a programar, produzindo um monte
de snapshots no caminho. Hoje de manhã, uma revisão da produção da noite passada fez você se assustar um pouco. No geral, o código está bom, mas
você teve uma série de enganos que foram corrigidos nos snapshots posteriores.

Vamos dizer que a branch na qual você realizou o desenvolvimento bêbado é chamada 'drunk' e você fez três snapshots após ter chegado do bar.
Se o nome 'drunk' aponta para o último snapshot neste branch, então você pode utilizar uma notação útil para referenciar o antecessor deste snapshot.
A notação 'drunk^' significa o pai do snapshot apontada pelo branch 'drunk'. Similarmente 'drunk^^' significa o avô do snapshot 'drunk'.
Assim os snapshots em ordem cronológica são 'drunk^^', 'drunk^' e 'drunk'.

Você realmente gostaria que estes três snapshots fossem dois snapshots limpos. Uma que muda uma função existente, e uma que adiciona um novo arquivo.
Para realizar esta revisão do histórico você copia 'drunk' para working e exclui o arquivo que é novo na série. Agora working representa as
modificações corretas na função existente. Você pode criar um novo snapshot de working e escrever a mensagem apropriada para as mudanças.
Como antecessor você especifica o SHA1 do snapshot 'drunk^^^', essencialmente criando um novo branch do mesmo snapshot da noite passada.
Agora pode copiar 'drunk' para working e executar um novo snapshot com a adição daquele novo arquivo. Como antecessor você especifica aquele
snapshot que acabamos de criar antes deste.

Como último passo, você muda o branch 'drunk' e aponta para o último snapshot que acabou de fazer.

O histórico do branch 'drunk' agora representa uma versão melhor daquilo que fez na noite passada. Os outros snapshots que você substituiu não
são mais necessários e podem ser excluídos ou deixados para a posteridade. Nenhum nome da branch está apontando para eles portanto será difícil
de encontrá-los depois, mas se você não os excluir estarão lá.

Colocando no palco ( Staging Area )

Mesmo tentando manter suas modificações relacionadas a uma única característica ou pedaço lógico, algumas vezes você precisa começar a trabalhar
em algo totalmente não relacionado. No meio do caminho percebe que seu diretório de trabalho contêm algo que deveria ser separado em dois
snapshots discretos.
Para ajudá-lo com essa situação chata, o conceito área do palco é útil. Esta área atua como um intermediário entre seu trabalho e o snapshot
final. Cada vez que você termina um snapshot, você também copia aquele snapshot para o diretório do palco.
Agora, toda vez que terminar uma edição de um novo arquivo, criar um novo arquivo, ou remover um arquivo, você decide quando esta mudança deve
ser parte de seu próximo snapshot. Caso deseje, você replica a mudança dentro do palco. Senão, pode deixá-la e aplicar em um snapshot futuro.
De agora em diante, snapshot são criados diretamente do diretório do palco.

Esta separação entre programar e preparar o palco torna fácil especificar o que é e o que não é incluído no próximo snapshot.
Você não precisa mais se preocupar muito sobre causar uma mudança acidental não relacionada no seu diretório de trabalho.

No entanto, você precisa ser um pouco cuidadoso. Considere um arquivo de nome LEIAME. Você edita este arquivo e então replica o mesmo no palco.
Você continua com o que tem que fazer, editando outros arquivos. Depois de um tempinho, você faz outra alteração no LEIAME. Agora você tem duas
alterações neste arquivo, mas apenas uma está no palco! Se criar um snapshot agora, sua segunda alteração estará ausente.

A lição nisso: cada nova edição precisa ser adicionada ao palco se é para ser parte do próximo snapshot.

Diferenças ( Diffs )

Com um diretório de trabalho, um palco e um monte de snapshots armazenados, começa a ficar confuso notar quais diferenças existem entre eles. Uma mensagem de snapshot apenas fornece um resumo do que mudou, não exatamente quais linhas foram mudadas entre dois arquivos.

Utilizando um algoritmo de diferenciação, você pode implementar um pequeno programa que mostra as diferenças em duas bases de código.
Conforme for desenvolvendo e copiando coisas do seu diretório de trabalho para o palco, tudo que vai realmente querer é uma maneira fácil de visualizar as diferenças entre os dois, assim pode determinar o que mais precisa ser colocado no palco. É também importante notar como o palco está diferente do último snapshot, uma vez que estas mudanças são o que irá se tornar parte do próximo snapshot que produzir.

Existem muitas outras diferenças que você pode querer ver. Entre um snapshot e seu antecessor iria mostrar um conjunto de mudanças que foram introduzidas pelo snapshot. A diferenciação entre dois branchs poderia ser um auxílio para garantir que seu desenvolvimento não vagou muito distante da linha principal.

Eliminando Duplicação ( Eliminating Duplication )

Depois de algumas viagens para a Namibia, Istanbul e Galapagos, Zoe começa a reclamar que seu disco rígido está cheio com milhares de arquivos com
cópias praticamente iguais do software. Você também tem sentido que todas aquelas duplicações são desperdícios.
Depois de pensar um pouco, você chega a uma solução bastante inteligente.

Você recorda que aquele hash SHA1 produz uma palavra curta que é única para o conteúdo de um arquivo. Iniciando com o primeiríssimo snapshot no
histórico do projeto, você começa o processo de conversão. Primeiro, você cria um diretório chamado objetos fora do histórico de código. Depois, encontra o mais profundo diretório aninhando em um snapshot. Adicionalmente, você abre um arquivo temporário para escrita.
Para cada arquivo neste diretório você executa três passos.

Passo 1: Calcular o SHA1 de seu conteúdo.

Passo 2: Adicionar uma entrada no arquivo temporário que contêm a palavra blob ( grande objeto binário ), o SHA1 do Passo 1 e o nome do arquivo.

Passo 3: Copia o arquivo para o diretório de objetos e renomeia-o para o SHA1 do Passo 1.

Uma vez concluído todos os arquivos, calcule o SHA1 do arquivo temporário e use-o para nomeá-lo, também o colocando no diretório de objetos.

Se em algum momento o diretório de objetos possuir um arquivo com o dado nome, então você já armazenou o conteúdo daquele arquivo e não existe
necessidade de fazê-lo novamente.

Agora, suba um diretório e comece novamente. Mas desta vez, quando você chegar ao diretório que acabou de processar, inclua a palavra 'tree', o SHA1
do arquivo temporário da última vez, e o nome do diretório no novo arquivo temporário. Nesse esquema, você pode fazer uma árvore de objetos
arquivo e diretórios que contêm os SHA1s e nomes dos arquivos e objetos de diretório que eles contêm.

Quando aplicar o processo em cada diretório e arquivo no snapshot, você terá um único "arquivo objeto diretório raiz" e seu correspondente SHA1.
Como nada contém o diretório raiz, você precisa gravar o SHA1 da árvore raiz em algum outro lugar. Um local ideal para armazenar é no arquivo de
mensagem do snapshot. Assim, a unicidade do SHA1 da mensagem também depende de todo o conteúdo do snapshot, e você pode garantir com absoluta
certeza que duas mensagens de snapshots com SHA1s idênticas contêm os mesmos arquivos!

É também conveniente criar um objeto da mensagem do snapshot da mesma maneira que fez para blobs e árvores. Como você está mantendo uma lista de branchs e nomes de tags que apontam para o SHA1 da mensagem você não precisa se preocupar com perder o rastro de quais snapshots são importantes para você.

Com todas estas informações armazenadas no diretório de objetos, você pode seguramente excluir o diretório de snapshots que usou como fonte desta operação. Se desejar reconstituir o snapshot no futuro é simples como seguir o SHA1 da branch armazenada no arquivo de mensagem e extrair cada árvore e blob no seu diretório e arquivo correspondente.

Para um simples snapshot, este processo de transformação não lhe provê muito. Você basicamente converteu um sistema de arquivos em outro e criou um monte de trabalho a ser feito. Os benefícios reais deste sistema aparecem com o reuso de árvores e blobs entre os snapshots.
Imagine dois snapshots seqüenciais nos quais apenas um arquivo no diretório raiz foi alterado. Se ambos os snapshots contêm 10 diretórios e 100 arquivos, o processo de transformação criará 10 árvores e 100 blobs do primeiro snapshot porem apenas 1 novo blob e 1 nova árvore do segundo snapshot!

Por converter todo o diretório de snapshots do sistema antigo para os arquivos objeto do novo, você drasticamente reduz o número de arquivos que são armazenados no disco. Agora, no lugar de talvez armazenar 50 cópias de arquivos idênticos de um arquivo que raramente muda, você mantém apenas um.

Comprimindo Blobs ( Compressing Blobs )

Eliminando duplicações de blobs e árvores reduz significativamente o total de armazenamento do histórico do projeto, mas não é a única coisa que você pode fazer para salvar espaço. Código fonte é apenas texto e pode ser eficientemente compactado utilizando um algoritmo como LZW ou DEFLATE.
Se você compactar cada blob antes de computar seu SHA1 e salvá-lo no disco pode reduzir o total de armazenamento do histórico para outra quantia bastante admirável.

O verdadeiro Git ( The True Git )

O VCS que você construiu é agora quase uma cópia do Git. A principal diferença é que o Git lhe fornece belas ferramentas de linha de comando para tratar tais coisas como criar snapshots e trocar para antigos ( o Git usa o termo "commit" no lugar de "snapshot"), traçar histórico, manter branchs atualizados, replicar mudanças de outras pessoas, unir e analisar diferenças de branchs, a centenas de outras tarefas comuns (e outras nem tão comuns).

Conforme você continuar a aprender o Git, mantenha está parábola em mente. Git é realmente simples nos bastidores, e é sua simplicidade que o faz tão flexível e poderoso. Uma última coisa antes de correr e começar a aprender os comandos do Git: lembre-se que é quase impossível perder um trabalho que foi comitado. Até mesmo quando excluir um branch, tudo que ocorre é que o ponteiro para aquele commit será removido.

Todos os snapshots continuarão no diretório de objetos, você apenas precisa escavar o SHA1 do commit. Nestes casos, procure com o "git reflog.
Ele contêm o histórico do que cada branch apontou para e em tempos de crise, vai salvar o dia.

Git - entendendo a lógica

noreply@blogger.com (Renato) — Tue, 26 May 2009 16:44:00 +0000

Muito bem, git é uma ferramenta fantástica, mas as vezes ficava curioso com o como as coisas funcionavam internamente.
Procurando na net, encontrei a The Git Parable, uma historinha sobre o mecanismo interno e como chegou ao que é. Elucidativo demais.

Git is a simple, but extremely powerful system. Most people try to teach Git by demonstrating a few dozen commands and then yelling “tadaaaaa.” I believe this method is flawed. Such a treatment may leave you with the ability to use Git to perform simple tasks, but the Git commands will still feel like magical incantations. Doing anything out of the ordinary will be terrifying. Until you understand the concepts upon which Git is built, you’ll feel like a stranger in a foreign land.

Para ler com paciência:
http://tom.preston-werner.com/2009/05/19/the-git-parable.html

Conficker

noreply@blogger.com (Renato) — Mon, 13 Apr 2009 12:23:00 +0000

O Conficker é um Worm para Windows que está rodando na rede desde outubro de 2008 e tem se tornado a praga da internet.

Se seu computador tem dado muitas falhas de conexão sem motivo aparente, pode ser que você esteja sendo hospedeiro do mesmo.

Maneira rápida de descobrir?
Acesse http://www.confickerworkinggroup.org/infection_test/cfeyechart.html

É só observar quantas imagens aparecem na parte superior e comparar com a descrição que vem abaixo.

Descobriu que está infectado?
Aqui tem links para atualizações da Microsoft:
http://en.wikipedia.org/wiki/Conficker#Removal

Boa sorte!

mooUrl Ubiquity Command

noreply@blogger.com (Renato) — Mon, 06 Apr 2009 20:36:00 +0000

Brincando com a API do Ubiquity, acabei fazendo este comando para utilizar o moourl de forma similar ao tinyurl.

Vamos então ao código:

/*
 * mooUrl command for Firefox Ubiquity extension.
 * date: 03/04/2009
 * author: Renato Aquino <renato.aquino@gmail.com>
 * add with <link rel="commands" href="mooUrl.js"/> to your page
 */
CmdUtils.CreateCommand({
 name: "moourl",
  takes: {"url to shorten": noun_type_url},
 icon: "http://moourl.com/favicon.ico",
 description: "Replaces the selected URL with a <a href=\"http://moourl.com\">MooUrl</a>",
 author: {name: "Renato Aquino", email: "renato.aquino@gmail.com"},
 license: "GPL",
 baseUrl: "http://moourl.com/create/?source=",
 preview: function( pblock, urlToShorten ){
  pblock.innerHTML = "Replaces the selected URL with ",
  jQuery.get( this.baseUrl + urlToShorten.text, function( moo ) {
   if(moo != "Error")
    pblock.innerHTML += jQuery("#milked_url",moo).text();
  });
 },
 execute: function( urlToShorten ) {
  //escaping urlToShorten will not create the right moourl
  jQuery.get( this.baseUrl + urlToShorten.text, function( moo ) {
   if(moo != "Error")
    CmdUtils.setSelection( jQuery("#milked_url",moo).text() );
  });
 }
});

Linux counter

noreply@blogger.com (Renato) — Mon, 06 Apr 2009 20:06:00 +0000

Já havia me esquecido que o Linux Counter continua funcional!!!
Quem mais tem?

Zend Framework

noreply@blogger.com (Renato) — Mon, 02 Mar 2009 20:01:00 +0000

Como trabalho bastante com PHP, já havia postado anteriormente minha opinião sobre o framework Codeigniter e Symfony, agora é a vez do Zend Framework.

Tal qual o esperado de uma empresa como a Zend, este framework é bastante maduro e amplo. Um dos pontos distintos que notei é o acoplamento fraco entre as classes do mesmo, ou seja, uma parte não depende necessáriamente da outra para ser utilizada.
Caso o programador opte por seguir a estrutura padrão e o modelo mvc do mesmo, as classes devem ser conectadas para realizar as tarefas que o mesmo deseja.

Como destaque de classes totalmente independentes cito o Zend_Validate e o Zend_Form. Você pode utilizar as classes do Zend_Form e do Zend_Validate em qualquer script PHP, mesmo que este não utilize mais nada do Framework.

As desvantagens que encontrei começaram pela documentação. As APIs estão pouco descritas e o guia de referência não cobre todo o pacote de classes.
Quanto ao design do projeto, acredito que o único problema que encontrei foi o mesmo que sempre notei em Java, a granularidade das classes e a implementação impecável de padrões de projeto acabam tornando um pouco obscura a busca por como as coisas funcionam.

O melhor exemplo de dificuldade está no Zend_Decorator, conjunto de classes que são muito utilizadas para desenhar formulários. Sua funcionalidade é tão genérica que se o programador não efetuar uma leitura cuidadosa do manual não conseguira utiliza-las.

No geral, a performance do framework me pareceu muito boa e após um tempo de setup inicial até é possível tornar o desenvolvimento mais rápido, embora o framework me passe a impressão que sua função é mais padronizar que simplificar.

Linux e o mundo das versões

noreply@blogger.com (Renato) — Thu, 19 Feb 2009 02:36:00 +0000

Neste tempo que estou desenvolvendo com C++ tenho trabalhado com diversas versões de software e, ultimamente, a palavra "versão" tem sido um problema para quase tudo.

Apenas para citar um exemplo, vou comentar sobre o sqlite.

Estou desenvolvendo um software para uma base CentOS5, ou seja, estou limitado a atualizar algumas coisas que a base do sistema depende. Como o yum é dependente do sqlite, não posso atualizar a versão do mesmo da 3.3 para a atual 3.6.11.

O que eu perdi com isso já que ambas são da versão 3?

Suporte a mutexes, prepared statements melhorados e tempo de desenvolvimento.

Agora coloque na lista outras bibliotecas como libvmime, libarchive, libsmbclient, google-ctemplate, gtest, etc.

Ainda bem que para facilitar minha vida, tenho utilizado ferramentas como autoconf, automake e libtool... mas dessas eu falo depois. ;)

Wrapper para SQLite em C++

noreply@blogger.com (Renato) — Fri, 19 Dec 2008 12:56:00 +0000

Tenho codificado uma série de pequenas bibliotecas para um produto e como BD para as configurações estamos utilizando o SQLite.

O maior problema encontrado foi utilizar a API propria do SQLite, que embora até relativamente simples, mostrou-se complexa na hora de fazer uma simples consulta.

Para facilitar as coisas estive pesquisando por classes wrappers e encontrei o CppSqlite.

O site tem um exemplo bastante completo do uso.

Assim que eu testar o mesmo com mais profundidade vou postar aqui minhas impressões a respeito.

News

noreply@blogger.com (Renato) — Tue, 21 Oct 2008 13:45:00 +0000

Report um pouco atrasado mas lá vai.

Deixei meu cargo de "Analista de Suporte" na Rádio Panamericana S/A para ingressar na equipe de desenvolvimento da BluePex Security Solutions.

Essa mudança não foi apenas de empresa e cargo, mas inclui uma mudança de cidade também. Deixei a loucura de São Paulo para tentar a vida na cidade de Limeira.

Acredito que terei uma série de desafios novos, com o tempo vou reportando.

Projeto 10^100 do Google

noreply@blogger.com (Renato) — Wed, 24 Sep 2008 19:09:00 +0000

Tudo bem, eu não tenho que anunciar porquê daqui a uma semana todo mundo vai estar falando disso, mas lá vai.

Para comemorar 10 anos o Google está lançando o projeto 10^100 (10 para os 100?).
Basicamente a idéia é pedir a sua idéia do que pode ser benéfico para ajudar os outros e com os esforços conjuntos de todos, após selecionar as melhores idéias, implementar o mesmo.

O tema é amplo demais, e nem sei se consigo explicar direito a idéia.
Para ler mais a respeito:

http://googleblog.blogspot.com/2008/09/project-10100.html

Site oficial do projeto:
http://www.project10tothe100.com

Curso de Metodologia de Programação

noreply@blogger.com (Renato) — Wed, 24 Sep 2008 14:02:00 +0000

Andei perdendo um tempinho para baixar e colocar em execução no meu iPod os vídeos do curso de metodologia de programação publicados pela universidade de Stanford, mas está valendo a pena.

O curso tem o foco em metologias e não em uma linguagem em sí, embora ensine Java para usar como ferramenta no desenrolar do mesmo.

Logo no primeiro vídeo o professor Mehran Sahami explica muito bem o nível de conhecimento necessário para assistir as aulas e resume-se a identificar se o computador está ligado.

Até onde assisti, o curso explica de forma bastante intuitiva vários conceitos de programação.

Cobre rápidamente diversos tópicos, incluíndo um pouquinho de história, programação Top-Down, conceitos de OO, etc. Tudo de forma muito simples, fazendo parecer algo trivial e causando vários insights.

Quem deseja aprender Java ou melhorar seu conhecimento teórica sobre programação pode perder um tempinho que não vai se arrepender.

Infelizmente não encontrei legendas para os vídeos, senão poderia fazer minha mãe aprender Java. :)

CS106A - Programming Methodology

http://see.stanford.edu/SEE/lecturelist.aspx?coll=824a47e1-135f-4508-a5aa-866adcae1111

Framework CodeIgniter para PHP

noreply@blogger.com (Renato) — Wed, 30 Jul 2008 15:22:00 +0000

Depois de algum tempo usando o Symphony, cheguei a duas conclusões:

1- é muito bem feito.
2- é muito pesado.

As aplicações que costumo desenvolver podem, depois de um tempo, chegar a uma complexidade razoável e tornar difícil organizar todo o código, dai a idéia de utilizar um framework. Mas, o framework deve ajudar e não atrapalhar seu desenvolvimento, e no critério velocidade o Symphony deixou um pouco a desejar para mim. O custo mínimo para desenvolver uma aplicação é alto demais e a carga de qualquer página parece que vai derrubar o servidor.

Voltei então a pesquisar sobre frameworks para PHP e depois de pular os clássicos Prado e CakePHP, acabei encontrando o CodeIgniter.

A primeira vista o CodeIgniter parece um amontoado de código perdido, mas observando com mais cuidado é possível notar que o framework é simples e leve. Provavelmente um dos detalhes é ele não assumir nada por você, ou seja, se você precisa de conexão à banco de dados na sua aplicação, precisa adicionar na configuração que o framework deve carregar as bibliotecas de database.

O CodeIgniter, como a maior parte do frameworks, trabalha com MVC, possui uma abstração de banco de dados chamada ActiveRecord, sim é um plágio do RubyOnRails, e suporte a templates Smarty. Essas features podem receber upgrades com os plugins disponíveis.

De cara, encontrei apenas um problema com o CI, sua configuração básica exige para conexão ao MySQL que sua versão mínima seja a 4.1, o problema é porque o CI faz um setup na conexão acertando os charsets e collations do MySQL, opções que só existem a partir do 4.1. Sem muito esforço, encontrei no próprio site do CI um post que explica como tratar esse tipo de problema.

Vou continuar postando aqui as experiências que me ocorrerem com o CI, e provavelmente farei alguns benchmarks de algumas aplicações que pretendo portar para ele.

Sites com recursos para Flash

noreply@blogger.com (Renato) — Tue, 01 Jul 2008 18:41:00 +0000

Um amigo enviou um email com uma lista de sites, que ele foi conhecendo ao longo do tempo, sobre desenvolvimento de animações Flash.
Bom, as descrições dele estão junto:

http://www.27bobs.com
O cara desse site simplesmente não faz mais nada na vida além de flash pq o que ele faz é insano, mais decorativo do que efetivo.

http://www.flashguru.co.uk/
Se é sobre flash, está aqui, muito mais atualizado do que o próprio site da Adobe.

http://www.bestflashanimationsite.com/
Váááááááááários sources, muita coisa legal.

http://www.flashdeveloper.nl
Site muito bom pra tutoriais e sources.

http://www.flashkit.com/
O bom e velho flash kit, tem tudo.

http://www.flash-extensions.net
Site de extensões pro flash, eu já comprei uma a um tempo atrás,ajuda muito nossa vida, sempre o custo/benefício vale a pena.

http://www.flash-template-design.com
Site de templates, tem alguns grátis e outros pagos vc consegue xupinhar.

http://www.flash-template-design.com
Outro depósito de flashs, mesma coisa do de cima, só que mais pobrezinho.

http://www.dreamlinestudio.com
Mais um site de templates, só que mais xique.

http://www.flashden.net
Notório site de designer especializado em flash, "só quem é" consegue colocar as coisas nele.

http://www.flashmo.com
Esse vc já conhece muito bem...

http://www.flzone.net
Esse site tem muita informação, já me tirou de vários buracos.

http://www.kirupa.com
Site muito bom pra gente, tem muuuuita coisa e merece que vc perca um tempo fuçando nele.

http://levitated.net
O cara desse site fez um pacto com o capeta, pq as coisas que ele faz são insanas... só vendo...

http://www.muzakdeezign.com/
Tem uns flazinhos bem legais em Downloads.

http://www.phireworx.com/
Site muito bom de extensões.

http://scriptplayground.com
Ótimo site de tutoriais.

http://www.ffiles.com/
Outro sensacional site de sources.

E eu ainda adiciono a esta lista os seguintes endereços:

http://www.flashsandy.org/
Biblioteca para desenvolvimento 3D no Flash

http://blog.papervision3d.org/
Mais uma biblioteca 3D.

http://away3d.com/
E outra biblioteca 3d.

http://seraf.mediabox.fr/wow-engine/
Biblioteca de física em AS3, para dar efeitos nas suas animações!

http://www.eye4u.com
Site da agência Eye4U, a animação é a mesma desde a primeira versão do Flash, mas ainda não vi ninguêm fazer nada tão simples e tão "na medida" com Flash. É um conjunto de animações e transições simples que utilizam muito bem todo o espaço de tela. Só vendo.

http://tech.nitoyon.com/blog/2008/01/as3query_alpha.html
Se você conhece Javascript e conhece jQuery, imagine usar o mesmo poder com ActionScript3.

Bom, é isso, só aproveitar!

Como disperdiçar seu tempo - Compilando AS3

noreply@blogger.com (Renato) — Wed, 18 Jun 2008 15:45:00 +0000

Gastei um tempão tentando encontrar um erro nas classes que estava desenvolvendo para um projeto em Flash, mas sempre recebendo a mesma mensagem:

Error #1046: Type was not found or was not a compile-time constant

Depois de verificar algumas duzias de vezes, resolvi procurar no Google por alguma luz.
Pois bem, com o novo compilador do AS3 é necessário declarar as classes como públicas ou então ele simplesmente as ignora.

Ou seja, mudar de:

class SuaClasse extends OutraClasse{}

para:

public class SuaClasse extends OutraClasse{}

Claro que só consegui resolver isso porque outro sofrido fez um post no seu blog com esta solução.
Agora, o compilador do Flash não podia dar um avizo não?

Melhorias do Firefox 3

noreply@blogger.com (Renato) — Tue, 27 May 2008 18:36:00 +0000

Estive lendo a lista de melhorias no Firefox 3 e achei muito legal alguns dos adendos.
Acredito que devam existir muitos e muitos outros legais que já existam não só no Firefox mas em diversos browser como padrões DOm ou coisa do gênero, mas quando eu encontrar algum lugar que liste os mesmos eu crio uma postagem aqui no Blog.

Bom, voltando ao Firefox, eu particularmente gostei das melhorias de JavaScript que agora está com suporte a versão 1.8, novas funcionalidades DOM e no suporte de CSS.

Tem muita coisa mesmo, pra quem desenvolve páginas, é sempre bom dar uma olhada.

http://developer.mozilla.org/en/docs/Firefox_3_for_developers

AS3 e bugs com Tween

noreply@blogger.com (Renato) — Tue, 27 May 2008 15:42:00 +0000

Quando estava programando a animação Flash que comentei anteriormente, encontrei um problema que acontecia quando disparava varias animações com a classe Tween do Flash.
Por algum motivo, as animações deixavam de executar no meio, e todo o posicionamento dos itens ficava errado.

Depois de buscar um pouco, encontrei num forúm da Adobe um comentário que dizia que o Garbage Collector do Flash excluía as instâncias da classe Tween que não estivessem referênciadas em nenhum lugar.

Um exemplo pode facilitar o entendimento.

Temos um MovieClip chamado mc e desejamos animar sua posição horizontal (x) , deslocando o mesmo da posição atual para + 100 pixels. Criamos então uma instância da classe Tween e passamos os parâmetros para o construtor.

new Tween(mc,'x',Regular.easeOut,x,x+100,0.6,true);

Logo após criada, esta instância já executaria a animação e terminado seu trabalho não existe mais nenhum motivo para manter uma referência da mesma. O problema ocorre durante a animação de x para x+100, se o processo de limpeza do coletor de lixo do Flash for disparado nesse período, nossa classe não está referênciada por ninguêm e portanto, elegível para ser descartada mesmo que esteja realizando alguma atividade.

Para resolver o problema, utilizei parte de um código que encontrei ( quando encontrar o link coloco aqui ), criei uma classe Singleton com o mesmo e pronto, temos uma forma de referênciar as instâncias de Tween sem nos preocupar com limpeza de memória antes do término da animação.

O uso da mesma é simples:

Salve o script para o mesmo diretório da sua animação com o nome AntiGC.as.
Adicione a chamada de importação no topo do seu script: "import AntiGC;"
Requisite a instância do AntiGC: "aGC:AntiGC = AntiGC.getInstance();"
Execute seu código de animação passando a instância para o AntiGC:
aGC.addElement(new Tween(mc,'x',Regular.easeOut,x,x+100,0.6,true));

Até terminar a animação a instância de Tween será referênciada pelo AntiGC, evitando a exclusão da mesma da pilha de execução. Após isso a mesma é liberada para limpeza.

Você só não pode deixar de referênciar o AntiGC pois isso faria o mesmo, com todas as instâncias de Tween registradas serem elegíveis para limpeza.

Conversor de videos para iPod

noreply@blogger.com (Renato) — Tue, 27 May 2008 14:53:00 +0000

Adquiri um iPod Video faz um tempinho com a intenção de passar o tempo nas horas do trajeto entre minha casa e o trabalho. Uma das coisas chatas que aconteceu logo no começo foi a dificuldade em converter os diversos formatos de vídeo para um formato que o iPod/iTunes pudessem aceitar.

Passado algum tempo, encontrei a maravilhosa lista de softwares gratuitos da Koyotesoft.
Entre as ferramentas existe uma chamada Free iPod Video Converter que é pra mim uma das mais práticas.

Essa ferramenta consegue converter formatos FLV, divx, xvid, mpg, mp4, dvd, vob, avi, wmv, asf e acredito que mais alguns que você tenha instalado o plugin do DirectShow.

A qualidade padrão de conversão não é das melhores e o programa sequer tenta ser o melhor compactador de vídeo, mas o importante é que a qualidade basta e o arquivo final é aceito pelo iPod. Se quizer arriscar, pode editar as opções de tamanho entre outras.

Animação em Flash com AS3

noreply@blogger.com (Renato) — Mon, 26 May 2008 21:59:00 +0000

Estive trabalhando em uma animação flash para a Jovem Pan FM que exibe uma lista das 5 primeiras músicas com as respectivas imagens e links para conteúdo do bloco Hit Parade.

Para completar a dor de cabeça, eu que não entendo nada de flash, resolvi fazer em Action Script 3.
Basicamente a animação faz a carga de um arquivo XML que é passada por parâmetro na tag object e o mesmo possui uma imagem do artista e a lista de músicas, links para ouvir, letra, ringtone, video e compra na loja do grupo (Baixahits). Como nem todas as músicas possuem todos os links foi necessário um pouco de programação para determinar se deve-se exibir ou não os ícones do mesmo.
Toda a movimentação do conteúdo foi feita por AS e acredito que 13 Kb foi um tamanho razoavel para o que a animação faz.

Quem quizer ver o mesmo em funcionamento procure na home page da jpfm pela animação com a cara da imagem abaixo .

Se interessar para alguem ver os fontes do mesmo é só entrar em contato.