Fica a dica de um pequeno tutorial de como converter vídeos de AVI e similares para DVD, com legenda embutida.

Instalando o tovid:

sudo apt-get install tovid

Convertendo de AVI com legenda para uma DVD-ISO.

tovid -dvd -in Video.avi -subtitles Legenda.srt -out Video
/usr/share/tovid/makexml Video.mpg -out Video
export VIDEO_FORMAT=NTSC
/usr/share/tovid/makedvd Video.xml
mkisofs -dvd-video -udf -R -o Video.iso Video/

Depois disso, basta gravar a ISO pelo Brasero, por exemplo.

Na PHP Conference Brasil deste ano, Todd Trichler da divisão de Developer Marketing da Oracle disponibilizou para quem passou no estande uma Developer Virtual Machine em DVD, para o Virtual Box, contendo além de um Linux como sistema operacional, o Oracle Database 11g Release 2 e as ferramentas de desenvolvimento. Apesar da VM estar prontinha, é necessário alterar as configurações de rede da máquina virtual para que a mesma funcione corretamente. Prometi ao Todd que postaria no blog isso em português, então aí vai o passo-a-passo.

Quem não possui o DVD, pode fazer o download da VM através do endereço http://www.oracle.com/technetwork/community/developer-vm/index.html

1) Sobre o nome da máquina virtual, clique com o botão direito e vá em Configurações;

2) Na aba Rede, selecione a interface de rede ativa e mude o tipo de rede para NAT;

3) Salve a configuração e inicie a VM.

Qualquer dúvida, entre em contato ou comente abaixo.

Até mais,
Rafael Kassner.

After an intense debug into Magento, we (Filipe Ibaldo and me) have found two problems in Magento code, related to slow Place Order with many products in cart (not many qty of a product).

One of the problems is the order item save, which is executed precisely in app/code/core/Mage/Sales/Model/Entity/Order/Attribute/Backend/Parent.php, on afterSave method, who spent many time on my machine (Core 2 Duo 2.26/4GB RAM), about 0.3 second for each product.

Considering the number of items average of customer’s cart is about 50 distinct products, this time, adding to another code executions and a high server load, is easily more than one minute, and this is unacceptable.

The found workaround is disable some observers from Mage_Downloadable and Mage_Rss, who execute in afterSave of each item in order.

In app/code/core/Mage/Downloadable/etc/config.xml, remove/comment the following lines:

            <sales_order_item_save_after>
                <observers>
                    <downloadable_observer>
                        <class>downloadable/observer</class>
                        <method>saveDownloadableOrderItem</method>
                    </downloadable_observer>
                </observers>
            </sales_order_item_save_after>

The code above appears twice.

In app/code/core/Mage/Rss/etc/config.xml, remove/comment the following lines:

            <sales_order_item_save_after>
                <observers>
                    <notifystock>
                        <class>rss/observer</class>
                        <method>salesOrderItemSaveAfterNotifyStock</method>
                    </notifystock>
                </observers>
            </sales_order_item_save_after>
            <sales_order_item_save_after>
                <observers>
                    <ordernew>
                        <class>rss/observer</class>
                        <method>salesOrderItemSaveAfterOrderNew</method>
                    </ordernew>
                </observers>
            </sales_order_item_save_after>

With this workaround, the save time of each product went from 0.3 second to 0.001 second, an incredible speed improvement.

However, if you are using downloadable products or Magento Inventory Management, this modifications can broke related features, so, be careful.

Another problem found is related with module disable feature into System > Configuration > Advanced > Advanced > Disable Module Output. If you disable some module, their observers did not disabled, and you need to remove their configuration or delete module folder.

Bye.

Após um exaustivo trabalho de debug no Magento, o Filipe Ibaldo e eu acabamos por descobrir dois problemas no Magento, relacionados à lentidão na conclusão da compra com muitos produtos (produtos diferentes, e não um produto com 100 unidades).

Um dos problemas é o save de cada produto que está no Order, que é executado precisamente em app/code/core/Mage/Sales/Model/Entity/Order/Attribute/Backend/Parent.php, no método afterSave, que demanda MUITO tempo de processamento na minha máquina (Core 2 Duo 2.26/4GB RAM), cerca de 0.3 segundos para cada produto.

Levando em consideração que os clientes deste determinado eCommerce compram, em média, mais de 50 produtos diferentes por compra, esse tempo, somado a outras execuções e server load bastante alto, ultrapassa 1 minuto para efetuar o fechamento da compra, um valor inaceitável.

A solução encontrada foi desabilitar os observers que executam após esse salvamento, que são do Mage_Downloadable e do Mage_Rss:

Em app/code/core/Mage/Downloadable/etc/config.xml, remova/comente as seguintes linhas:

            <sales_order_item_save_after>
                <observers>
                    <downloadable_observer>
                        <class>downloadable/observer</class>
                        <method>saveDownloadableOrderItem</method>
                    </downloadable_observer>
                </observers>
            </sales_order_item_save_after>

O trecho de código acima aparece duas vezes.

Em app/code/core/Mage/Rss/etc/config.xml, remova/comente as seguintes linhas:

            <sales_order_item_save_after>
                <observers>
                    <notifystock>
                        <class>rss/observer</class>
                        <method>salesOrderItemSaveAfterNotifyStock</method>
                    </notifystock>
                </observers>
            </sales_order_item_save_after>
            <sales_order_item_save_after>
                <observers>
                    <ordernew>
                        <class>rss/observer</class>
                        <method>salesOrderItemSaveAfterOrderNew</method>
                    </ordernew>
                </observers>
            </sales_order_item_save_after>

Feito isso, o tempo do save de cada produto passou de 0.3 segundos para 0.001 segundos, um ganho incrível de velocidade no geral.

Entretanto, vale ressaltar que se você estiver utilizando produtos “baixáveis” ou controle de estoque pelo Magento, essas alterações podem trazer problemas ao sistema, portanto, execute com cuidado a alteração.

Outro problema encontrado por nós foi relacionado com o recurso de desabilitar módulos do Magento, disponível no admin em Sistema > Configuração > Avançado > Avançado > Desabilitar saída dos módulos, o qual, mesmo estando o Mage_Rss e o Mage_Downloadable desabilitados, seus observers continuaram funcionando, sendo necessário remover a pasta do módulo (ou a configuração) para o mesmo parar de funcionar totalmente.

Até mais.

Today I found a problem in Zend Framework and his class autoloader, where an class_exists function call fires the Zend Framework autoloader. The function has an option to ignore the autoloader, but any class that I need loaded by Zend_Loader will return false.

Then, if I call class_exists without disable autoloader, I got an file not exists PHP warning, that’s why Zend_Loader doesn’t check if the file exists, just include.

The trick is change Zend/Loader.php to check if file exists before include, and this must be wrote in loadFile method.

    public static function loadFile($filename, $dirs = null, $once = false)
    {
        self::_securityCheck($filename);

        /**
         * Search in provided directories, as well as include_path
         */
        $incPath = false;
        if (!empty($dirs) && (is_array($dirs) || is_string($dirs))) {
            if (is_array($dirs)) {
                $dirs = implode(PATH_SEPARATOR, $dirs);
            }
            $incPath = get_include_path();
            set_include_path($dirs . PATH_SEPARATOR . $incPath);
        }

        /**
         * Try finding for the plain filename in the include_path.
         */
        if (!self::fileExists($filename)) {
            return false;
        }

        if ($once) {
            include_once $filename;
        } else {
            include $filename;
        }

        /**
         * If searching in directories, reset include_path
         */
        if ($incPath) {
            set_include_path($incPath);
        }

        return true;
    }

    public static function fileExists ($filename) {
        $paths = explode(PATH_SEPARATOR, get_include_path());
        foreach ($paths as $path) {
            if (file_exists($path . DIRECTORY_SEPARATOR . $filename)) {
                return true;
            }
        }
        return false;
    }

Bye.

Hoje me deparei com um problema no Zend Framework e seu autoloader de classes, onde uma chamada ao class_exists dispara o autoloader do Zend Framework. A função tem uma opção de não disparar o autoloader, porém, ela sempre retorna false para objetos que são carregados dinamicamente via Zend_Loader.

Além disso, se eu uso class_exists sem desabilitar o autoloader, eu recebo um warning o arquivo com  a classe não exista, isso por que o Zend_Loader não faz a verificação se o arquivo existe, ele apenas inclui.

A solução seria mudar o Zend/Loader.php, fazendo com que ele verifique se o arquivo da classe antes de tentar incluir, e isso deve ser feito dentro do método loadFile.

    public static function loadFile($filename, $dirs = null, $once = false)
    {
        self::_securityCheck($filename);

        /**
         * Search in provided directories, as well as include_path
         */
        $incPath = false;
        if (!empty($dirs) && (is_array($dirs) || is_string($dirs))) {
            if (is_array($dirs)) {
                $dirs = implode(PATH_SEPARATOR, $dirs);
            }
            $incPath = get_include_path();
            set_include_path($dirs . PATH_SEPARATOR . $incPath);
        }

        /**
         * Try finding for the plain filename in the include_path.
         */
        if (!self::fileExists($filename)) {
            return false;
        }

        if ($once) {
            include_once $filename;
        } else {
            include $filename;
        }

        /**
         * If searching in directories, reset include_path
         */
        if ($incPath) {
            set_include_path($incPath);
        }

        return true;
    }

    public static function fileExists ($filename) {
        $paths = explode(PATH_SEPARATOR, get_include_path());
        foreach ($paths as $path) {
            if (file_exists($path . DIRECTORY_SEPARATOR . $filename)) {
                return true;
            }
        }
        return false;
    }

Até mais.

Não devemos permitir tal ato.

http://meganao.wordpress.com/2010/08/27/blogagem-coletiva-de-repudio-ao-ai5-digital/

PS: sim, kibei do Zaip esse texto, to sem tempo pra escrever, mas desde que o projeto foi lançado sou contra o mesmo…

Esta é uma dica para utilizar em ambiente de desenvolvimento e/ou testes, onde é necessário utilizar mais de uma versão do PHP, sem que seja necessário setar uma para todo seu ambiente. Neste caso, a versão será definida via .htaccess, porém, somente é possível utilizar esta técnica se você puder compilar o PHP.

É realmente importante pra quem precisa dar suporte a ambientes e/ou sistemas legadosm ou testar a retrocompatiblidade de um código PHP. Parto do princípio que você já saiba compilar o PHP para seu ambiente, se não souber, procure no Google antes.

Resumo:

No source do PHP, substitua todas as entradas abaixo:

php5_module -> php5_x_x_module
libphp5 -> libphp5.x.x
application/x-httpd-php -> application/x-httpd-php-5-x-x

E compile normalmente. No PHP 5.3.x pode ocorrer um erro informando que o libs/libphp5.3.x.so não foi encontrado, basta entrar na pasta libs e mover/copiar o libphp.so para libphp5.3.x.so.

Passo-a-passo:

Onde eu estiver especificando 5.x.x ou 5_x_x, isso significa a versão do PHP que você está compilando.

1. Baixe o source do PHP e descompacte para um diretório de sua preferência.

2. Com o auxílio de um editor de texto (TextMate, Notepad++, DreamWeaver, etc), procure em todo o diretório do source (que você descompactou anteriormente), e substitua:

Se você está se perguntando o que isso faz: essas substituições fazem com que cada versão diferente do PHP que você vá compilar seja definida como um novo módulo no Apache, ao invés de sempre ser php5_module.

A alteração do MimeType (terceira substituição) serve para que você consiga chavear entre as versões via .htaccess, pois não podemos colocar um LoadModule no .htaccess.

3. Compile sua versão do PHP normalmente, cada versão em um diretório separado.

3.1. Se você estiver compilando uma versão 5.3 do PHP, você pode receber um erro ao executar o comando make install, informando que o arquivo libs/libphp5.x.x.so não existe. Neste caso, basta copiar o arquivo libs/libphp5.so e tentar novamente.

3.2. Em alguns casos, o comando make install ativa o php5_module automaticamente no httpd.conf. Neste caso, revise o arquivo, pois em todas as minhas tentativas, por algum motivo obscuro, ele adicionava o módulo como o nome de php5_module, e não php5_x_x_module. Se isso acontecer, apenas renomeie o módulo.

3.3. Ainda é possível utilizar extensões dinamicamente no PHP, porém, você pode obter erros por estar usando uma extensão compilada para outra versão da qual você esteja rodando. Sugiro compilar as extensões estaticamente.

3.4. Sugiro cuidado ao definir a propriedade –with-config-file-path, para que o php.ini seja o diferente em várias versões do PHP. Você pode obter erros por definir alguma propriedade errada ou inexistente para uma versão específica do PHP.

4. Reinicie o Apache para as alterações terem efeito.

5. Para utilizar uma determinada versão (que você já compilou com este método) em um projeto no seu ambiente, basta adicionar a seguinte propriedade ao .htaccess do projeto:

AddType application/x-httpd-php5-x-x .php

Onde 5-x-x é a versão do PHP que você deseja.

Dúvidas? Deixe um comentário.