Um dos argumentos dos evangelistas de software livre é que, tendo acesso ao código fonte do programa, você altera o que quiser. Mas quem tem o mínimo de experiência em desenvolvimento sabe que o processo é um pouquinho trabalhoso.

Primeiro você baixa o código fonte do repositório oficial (às vezes tendo que baixar um programa diferente de controle de versão), baixa todos os pacotes de desenvolvimento dependentes (quando eles dizem quais são), se familiariza com o código fonte (mesmo sem documentação), aprende uma nova linguagem e todas as APIs necessárias, tenta alterar e depois fica compilando até que tudo funcione (o que às vezes não ocorre).

Eu não sei vocês, mas só de imaginar tudo isso eu prefiro esperar e torcer pra que a funcionalidade que eu quero esteja disponível na versão seguinte.

Só que isso faz de você um mau menino, e os nerds olham feio pra você nos eventos de tecnologia e nas listas de discussão.

Abaixo você verá algumas etapas simples de como começar a alterar softwares utilizando os pacotes de source do Debian (Ubuntu ou qualquer derivado), através de passos reais que segui para adicionar uma pequena funcionalidade ao Transmission, mesmo sem conhecer nada de C, Gtk ou do código fonte do programa (na verdade, ainda nem comecei, estou escrevendo o post e fazendo).

Prepare-se para impressionar as gatinhas!

Baixando o código fonte e todas as dependências

Antes de começar qualquer projeto de pacote Debian em C, é fundamental que você tenha o essencial para construção instalado, que inclui compilador e biblioteca para criar pacotes, além do pacote fakeroot, necessário ao montar o pacote no final de todas as etapas:

/home/diogo/transmission# aptitude install build-essential fakeroot

Em seguida, baixe o fonte do programa que deseja alterar; no meu caso, o Transmission:

~/transmission$ apt-get source transmission

O comando apt-get source deve ser feito com o seu usuário mesmo, e não como root, apenas para baixar o código fonte no diretório atual.

Ao terminar, você terá os arquivos abaixo e todo o código fonte no diretório transmission-1.75:

~/transmission$ ls -l
total 6568
drwxr-x--- 15 diogo diogo    4096 2009-10-03 13:01 transmission-1.75
-rw-r-----  1 diogo diogo   17251 2009-09-20 19:30 transmission_1.75-1.diff.gz
-rw-r-----  1 diogo diogo    1519 2009-09-20 19:30 transmission_1.75-1.dsc
-rw-r-----  1 diogo diogo 6681496 2009-09-20 19:30 transmission_1.75.orig.tar.gz

Depois, como root, é necessário instalar no sistema todas as bibliotecas necessárias para compilar o programa:

/home/diogo/transmission# apt-get build-dep transmission

Aqui foi necessário baixar 70 pacotes (27MB) com todos os cabeçalhos (arquivos .h) e demais dependências necessárias. Talvez você queira copiar a lista de pacotes que o apt-get mostrou para poder removê-los depois de compilar o programa.

Finalizando, apenas para concluir o fluxo, assim que quiser compilar o programa e montar um pacote, basta executar o comando abaixo, a partir do diretório dos arquivos fonte:

~/transmission/transmission-1.75$ dpkg-buildpackage -rfakeroot -uc -b

O pacote .deb será gerado no diretório acima e poderá ser instalado com dpkg -i nomedopacote.deb.

Alterando o código fonte

Já tenho o código fonte e já sei como montar o pacote, mas não faço a menor idéia de como alterar o programa. Tentemos assim mesmo.

Sabendo que o Transmission é um cliente de torrent, o recurso que quero adicionar é poder salvar os arquivos no mesmo diretório onde está localizado o .torrent. Para isso, a idéia é incluir uma opção na tela de configuração como na montagem abaixo em vermelho:

Antes de começar a bagunçar o código fonte que baixamos, é interessante fazer uma cópia do original para facilitar a geração de um patch depois:

~/transmission/transmission-1.75$ cp -r transmission-1.75/ transmission-1.75-original

Dando uma olhada no diretório do código fonte, temos o seguinte:

~/transmission/transmission-1.75$ ls -F
aclocal.m4     configure*    gtk/              Makefile.am  third-party/
AUTHORS        configure.ac  INSTALL           Makefile.in  transmission.spec.in
autogen.sh*    COPYING       install-sh*       missing*     Transmission.xcodeproj/
ChangeLog      daemon/       libtransmission/  NEWS         update-version-h.sh*
cli/           debian/       ltmain.sh*        po/          web/
config.guess*  depcomp*      m4/               qt/
config.sub*    doc/          macosx/           README

Como estou interessado em alterar a interface Gtk, vamos ao seu diretório:

~/transmission/transmission-1.75/gtk$ ls -F
actions.c     icons.h         sexy-icon-entry.c        tr-core.h
actions.h     lock.h          sexy-icon-entry.h        tr-icon.c
add-dialog.c  logo.h          sexy-marshal.c           tr-icon.h
add-dialog.h  main.c          sexy-marshal.h           tr-prefs.c
conf.c        Makefile.am     stats.c                  tr-prefs.h
conf.h        Makefile.in     stats.h                  tr-torrent.c
details.c     makemeta-ui.c   torrent-cell-renderer.c  tr-torrent.h
details.h     makemeta-ui.h   torrent-cell-renderer.h  tr-window.c
dialogs.c     marshal.list    tracker-list.c           tr-window.h
dialogs.h     msgwin.c        tracker-list.h           turtles.h
file-list.c   msgwin.h        transmission.1           ui.h
file-list.h   notify.c        transmission.desktop.in  util.c
hig.c         notify.h        transmission.png         util.h
hig.h         options-icon.h  tr-core.c
icons/        relocate.c      tr-core-dbus.h
icons.c       relocate.h      tr-core-dbus.xml

Mesmo não conhecendo nada sobre a estrutura do programa, depois de dar uma olhada no nome dos arquivos, um bom palpite é que o arquivo conf.c esteja relacionado com o que preciso alterar, já que é o mais parecido com algo referente à janela de configuração. Edite-no-lo.

Como de praxe, o arquivo começa com alguns includes e em seguida passa para definições de funções. Todas estão com pelo menos uma linha de comentário e têm nomes legíveis. Até que um comentário chama atenção:

/**
 * This is where we initialize the preferences file with the default values.
 * If you add a new preferences key, you /must/ add a default value here.
 */

Vamos precisar adicionar uma preference key, para determinar se o novo checkbox da janela de configuração está marcado ou não. Então, melhor seguir a recomendação do comentário e definir um valor padrão para a nova chave:

~/transmission$ diff -u transmission-1.75-original/gtk/conf.c transmission-1.75/gtk/conf.c
--- transmission-1.75-original/gtk/conf.c	2009-10-03 14:03:28.000000000 -0300
+++ transmission-1.75/gtk/conf.c	2009-10-03 14:20:54.000000000 -0300
@@ -192,6 +192,7 @@
 #endif
     if( !str ) str = tr_getDefaultDownloadDir( );
     tr_bencDictAddStr( d, TR_PREFS_KEY_DOWNLOAD_DIR, str );
+    tr_bencDictAddBool( d, PREF_KEY_DOWNLOAD_SAME_DIR, FALSE );

     tr_bencDictAddBool( d, PREF_KEY_ASKQUIT, TRUE );

Se você não está familiarizado com o commando diff, basta saber que as primeiras linhas ali definem os arquivos comparados (o conf.c com o mesmo arquivo do diretório original), em seguida o numero da linha do trecho onde ocorreu a alteração, e logo abaixo a alteração: as linhas iniciadas com + foram adicionadas e com – removidas, as demais são apenas para referência da posição.

Contudo, a chave adicionada PREF_KEY_DOWNLOAD_SAME_DIR não existe ainda, foi inventada agora, e é necessário definí-la em algum lugar, que não sabemos onde. Meu primeiro palpite foi o arquivo conf.h, mas não tinha nada de relevante lá. Para não ter que ficar procurando arquivo por arquivo, vamos procurar onde uma outra chave qualquer já tenha sido definida:

~/transmission/transmission-1.75/gtk$ grep PREF_KEY_START *
conf.c:    tr_bencDictAddBool( d, PREF_KEY_START, TRUE );
tr-core.c:        tr_ctorSetPaused( ctor, TR_FORCE, !pref_flag_get( PREF_KEY_START ) );
tr-core.c:    const gboolean doStart = pref_flag_eval( start, PREF_KEY_START );
tr-prefs.c:    w = new_check_button( s, PREF_KEY_START, core );
tr-prefs.h:#define PREF_KEY_START                      "start-added-torrents"

Pronto, agora sabemos que a definição de PREF_KEY_START (uma preferência de checkbox no mesmo lugar onde adicionaremos a nova) foi feita no arquivo tr-prefs.h. Vamos lá adicionar nossa chave nova também:

~/transmission$ diff -u transmission-1.75-original/gtk/tr-prefs.h transmission-1.75/gtk/tr-prefs.h
--- transmission-1.75-original/gtk/tr-prefs.h	2009-10-03 14:03:28.000000000 -0300
+++ transmission-1.75/gtk/tr-prefs.h	2009-10-03 14:38:55.000000000 -0300
@@ -26,6 +26,7 @@
 #define PREF_KEY_INHIBIT_HIBERNATION        "inhibit-desktop-hibernation"
 #define PREF_KEY_DIR_WATCH                  "watch-dir"
 #define PREF_KEY_DIR_WATCH_ENABLED          "watch-dir-enabled"
+#define PREF_KEY_DOWNLOAD_SAME_DIR          "download-same-dir"
 #define PREF_KEY_SHOW_TRAY_ICON             "show-notification-area-icon"
 #define PREF_KEY_SHOW_DESKTOP_NOTIFICATION  "show-desktop-notification"
 #define PREF_KEY_START                      "start-added-torrents"

Ainda olhando o resultado do último grep, é possível observar que o arquivo tr-prefs.c também será útil, pois nele tem uma chamada a new_check_button, que apesar de não conhecer, dá a entender que cria um checkbox na janela de preferências. Editemos esse arquivo e adicionemos nosso checkbox novo:

~/transmission$ diff -u transmission-1.75-original/gtk/tr-prefs.c transmission-1.75/gtk/tr-prefs.c
--- transmission-1.75-original/gtk/tr-prefs.c	2009-10-03 14:03:28.000000000 -0300
+++ transmission-1.75/gtk/tr-prefs.c	2009-10-03 15:08:09.000000000 -0300
@@ -305,6 +305,10 @@
     w = new_path_chooser_button( TR_PREFS_KEY_DOWNLOAD_DIR, core );
     hig_workarea_add_row( t, &row, _( "Save to _Location:" ), w, NULL );

+    s = _( "Save to the same directory as torrent file" );
+    w = new_check_button( s, PREF_KEY_DOWNLOAD_SAME_DIR, core );
+    hig_workarea_add_wide_control( t, &row, w );
+
     hig_workarea_add_section_divider( t, &row );
     hig_workarea_add_section_title( t, &row, _( "Limits" ) );
 

O trecho adicionado foi baseado numa opção já existente. Para o que precisamos, não é necessário saber pra que servem as funções utilizadas, apesar de que em alguns minutos é possível descobrir isso e se familiarizar melhor com o que está acontecendo.

Bem, a princípio, o checkbox para configurar se queremos salvar os arquivos no mesmo diretório foi adicionado. Falta só utilizar o valor desta opção na janela de adicionar torrents.

Olhando novamente o diretório gtk, o provável arquivo que monta a janela que precisamos é o add-dialog.c. O que queremos nele é: caso o checkbox com a configuração PREF_KEY_DOWNLOAD_SAME_DIR esteja marcado, devemos usar o diretório do arquivo torrent ao invés do diretório configurado. Desta vez não teve muita mágica para encontrar onde mexer. A dica é ler as funções definidas e tentar identificar o que estamos procurando.

Dentro da função addSingleTorrentDialog no arquivo add-dialog.c foi possível encontrar o seguinte trecho:

    if( tr_ctorGetDownloadDir( ctor, TR_FORCE, &str ) )
        g_assert_not_reached( );
    g_assert( str );

    data = g_new0( struct AddData, 1 );
    data->core = core;
    data->ctor = ctor;
    data->filename = g_strdup( tr_ctorGetSourceFile( ctor ) );
    data->downloadDir = g_strdup( str );

Julgando pelos nomes, a função tr_ctorGetDownloadDir preenche o diretório de download do torrent da variável ctor na variável str.

O que precisamos então é definir a variável str para o diretório do arquivo torrent caso o checkbox PREF_KEY_DOWNLOAD_SAME_DIR esteja marcado.

Olhando o trecho de código anterior, sabemos que o caminho do arquivo pode ser obtido através da função tr_ctorGetSourceFile e, ainda no mesmo arquivo, é possível ver que consultamos se o checkbox da configuração está marcado com a função pref_flag_get. A única coisa que fica faltando é conseguir o nome do diretório a partir do caminho completo.

É comum que o diretório de um caminho completo seja retornado pela função ou comando chamado dirname. Como não sei nada de C pra ter certeza de como fazer, dei um grep por dirname para saber como o resto do programa obtém essa informação. Achei o cabeçalho libtransmission/utils.h que define a função tr_dirname. Tudo que eu precisava.

A alteração final, já incluindo o arquivo .h necessário para a função de diretório, ficou assim:

~/transmission$ diff -u transmission-1.75-original/gtk/add-dialog.c transmission-1.75/gtk/add-dialog.c
--- transmission-1.75-original/gtk/add-dialog.c	2009-10-03 14:03:28.000000000 -0300
+++ transmission-1.75/gtk/add-dialog.c	2009-10-03 15:26:40.000000000 -0300
@@ -17,6 +17,7 @@
 #include "file-list.h"
 #include "hig.h"
 #include "tr-prefs.h"
+#include "libtransmission/utils.h"

 /****
 *****
@@ -285,8 +286,12 @@
                                              GTK_RESPONSE_CANCEL,
                                              -1 );

-    if( tr_ctorGetDownloadDir( ctor, TR_FORCE, &str ) )
-        g_assert_not_reached( );
+    if ( pref_flag_get( PREF_KEY_DOWNLOAD_SAME_DIR ) ) {
+        str = tr_dirname( tr_strdup( tr_ctorGetSourceFile( ctor ) ) );
+    } else {
+        if( tr_ctorGetDownloadDir( ctor, TR_FORCE, &str ) )
+            g_assert_not_reached( );
+    }
     g_assert( str );

     data = g_new0( struct AddData, 1 );

O resto foi apenas baseado em código já existente.

Compilando e instalando o pacote

Para finalizar, basta deixar que o Debian compile e gere o pacote:

~/transmission/transmission-1.75$ dpkg-buildpackage -rfakeroot -uc -b

Em seguida, para instalar o pacote que foi gerado no diretório acima do diretório do código fonte, execute como root:

/home/diogo/transmission# dpkg -i transmission-gtk_1.75-1_amd64.deb

Gerando um patch

A forma universal de trocar alterações em código é através de patch, um arquivo com todos os diff’s mostrados acima.

Mas antes de criar o patch, é preciso remover alguns arquivos gerados pela compilação:

~/transmission/transmission-1.75$ dpkg-buildpackage -rfakeroot -Tclean

Agora é possível utilizar o diff para comparar o diretório original com o diretório onde as alterações foram feitas:

~/transmission$ diff -ru transmission-1.75-original/ transmission-1.75/ > download-same-directory.diff

Ao enviar o patch para alguém ou para simplesmente aplicá-lo no diretório original, basta fazer:

~/transmission/transmission-1.75-original$ patch -p1 < ../download-same-directory.diff
patching file gtk/add-dialog.c
patching file gtk/conf.c
patching file gtk/tr-prefs.c
patching file gtk/tr-prefs.h

Se você abrir o patch vai reparar que o caminho para os arquivos inicia com o nome dos diretórios transmission-1.75-original e transmission-1.75. O argumento -p1 do patch é justamente para ignorar esse primeiro pedaço do path, uma vez que já estamos no diretório onde as alterações devem ser aplicadas.

Considerações finais

Esta alteração, na verdade, foi extremamente simples e com fim didático. Para modificações reais, é fundamental ter mais dedicação para entender a estrutura do projeto e produzir um patch de qualidade, que eventualmente possa ser utilizado pelo autor. No caso mostrado, por exemplo, é provável que a melhor abordagem seria alterar o downloadDir do optional_args do tr_ctor, mas seria mais chato para descrever neste post.

Os passos acima são voltados mais para começar com pequenas alterações de forma prática, sem ter que participar ativamente do projeto.

Caso deseje realmente participar, a melhor forma continua sendo utilizar o repositório oficial e interagir com os colaboradores, até mesmo pra saber se a sua idéia já não está em desenvolvimento ou se você pode coloborar com tarefas mais importantes.

Além disso, é bem comum que os desenvolvedores não aceitem um patch porque ele foi feito baseado no código de uma versão anterior ao trunk / head (que é o caso dos releases de pacotes do Debian), não sendo mais possível aplicá-lo depois de tantas alterações na versão de desenvolvimento.

Já estou até imaginando a galera toda alterando seus programas agora… Boa sorte!

Finalmente, depois de muitos anos, achei que tivesse encontrado uma situação em que variáveis estáticas seriam úteis para mim no PHP.

A diferença da variável estática em uma função é que ela não perde o seu valor quando a execução deixa o seu escopo. Isto é, na próxima vez que a função for executada, a variável terá o mesmo valor que tinha na execução anterior.

Nunca tinha achado muita utilidade pra isso, até porque geralmente as variáveis locais de um método realmente tinham o tempo de vida de cada execução. Quando não, fazia mais sentido utilizar uma propriedade da classe.

Até que recentemente surgiu a necessidade de executar um método que consultava o banco de dados dezenas de vezes em uma única requisição, alterando apenas o parâmetro da query.

Como consultar o banco uma única vez não era viável neste caso, um raciocínio que segui para tentar poupar um pouco o servidor foi efetuar o prepare somente 1 vez para cada query. E aí entrou a variável estática, guardando o resultado do prepare para execuções futuras, na mesma requisição.

Dessa forma, a partir da segunda vez que o método for chamado, ele executa direto o prepared statement com o id que deve ser consultado, sem ter que fazer o prepare de novo.

Para minha surpresa, fazendo um benchmark simples hoje (meses depois de implementar com static, assumindo que seria mais rápido), percebi que poupar o prepare no Oracle não fez muita diferença. Pelo visto o Oracle percebe que é a mesma query e não prepara novamente, ou simplesmente fazer o prepare é tão simples que não faz diferença economizar.

Sendo assim, parece que a pequena utilidade que eu tinha dado a variáveis estáticas não me serviu de nada. Estou apresentando o resultado aqui porque, bem… “Negative results are still results. Even 20 thousand of them”.

Pelo visto vou ficar sem ter utilidade para variáveis estáticas. A não ser que você tenha outros relatos positivos :)

Acho que desde que descobri o recurso de GROUP BY … WITH ROLLUP no MySQL, todas as consultas que faço pra relatórios incluem o modificador.

Uma query de exemplo seria pra consultar a quantidade de pessoas por estado, retornando também o total parcial por região.

Para que o MySQL já calcule este subtotal, basta incluir o modificador WITH ROLLUP logo após o GROUP BY:

+--------------+---------------------+-------------+
| regiao       | nome                | COUNT(p.id) |
+--------------+---------------------+-------------+
| Centro-Oeste | Distrito Federal    |          99 |
| Centro-Oeste | Goiás               |         114 |
| Centro-Oeste | Mato Grosso         |         102 |
| Centro-Oeste | Mato Grosso do Sul  |          91 |
| Centro-Oeste | NULL                |         406 |
| Nordeste     | Alagoas             |         107 |
| Nordeste     | Bahia               |          72 |
| Nordeste     | Ceará               |         100 |
| Nordeste     | Maranhão            |          89 |
| Nordeste     | Paraíba             |         128 |
| Nordeste     | Pernambuco          |         105 |
| Nordeste     | Piauí               |          92 |
| Nordeste     | Rio Grande do Norte |          83 |
| Nordeste     | Sergipe             |         115 |
| Nordeste     | NULL                |         891 |
| Norte        | Acre                |          87 |
| Norte        | Amapá               |          97 |
| Norte        | Amazonas            |         103 |
| Norte        | Pará                |         116 |
| Norte        | Rondônia            |         111 |
| Norte        | Roraima             |          93 |
| Norte        | Tocantins           |         101 |
| Norte        | NULL                |         708 |
| Sul          | Paraná              |         112 |
| Sul          | Rio Grande do Sul   |         110 |
| Sul          | Santa Catarina      |         115 |
| Sul          | NULL                |         337 |
| NULL         | NULL                |        2342 |
+--------------+---------------------+-------------+

 
Com o modificador WITH ROLLUP, para cada região existe um valor NULL na coluna do estado, representando o subtotal daquela região.

Esta regra vale para todos os níveis de agrupamento. As demais colunas agrupadas ficam com valor NULL quando a função de agregação, neste caso o COUNT, está representando um resultado parcial.

No final é retornado ainda o total geral, como se não houvesse agrupamento algum, deixando todas as colunas agrupadas com valor NULL.

Agora basta formatar o resultado pelo código e deixar as colunas de subtotal com algum estilo diferente e descrição apropriada.

Vale lembrar que o WITH ROLLUP retorna os rows ordenados pelas colunas agrupadas, não sendo permitido misturar uma cláusula ORDER BY na mesma query, até porque o MySQL se baseia na troca do valor da coluna para saber quando deve mostrar um total parcial (da mesma forma que faríamos manualmente). Caso seja realmente necessário, é possível utilizar o WITH ROLLUP em uma query derivada e a partir dela acrescentar o ORDER BY.

Veja mais detalhes sobre modificadores de agrupamento no capítulo GROUP BY Modifiers do manual.

É comum ver scripts com dezenas de linhas de código pra fazer algo extremamente simples. Fica aqui meu apelo desesperado com algumas dicas rápidas.

1 – Listar arquivos de um diretório

Se não houver um motivo muito claro pra usar opendir, readdir e closedir (não consigo pensar em nenhum), a forma mais prática de listar o conteúdo de um diretório é com DirectoryIterator:

Se for necessário listar os arquivos recursivamente, percorrendo todos os subdiretórios, é só usar o RecursiveDirectoryIterator junto com o RecursiveIteratorIterator:

Com um pouco de criatividade, é possível estender essas classes com qualquer lógica facilmente, como por exemplo, para montar uma árvore com a estrutura dos diretórios.

2 – montar e desmontar query strings

Mesmo que menos comum (e menos útil), colocar uma query string numa URL é um trabalho trivial demais pra ser feito com implode, concatenando tudo ou qualquer outro método engenhoso. Desde o lançamento do PHP 5 é possível contar com a http_build_query:

E o inverso também é possível com as funções parse_url e parse_str:

Só fique atento que, por motivos alheios ao bom senso, parse_str por padrão extrai as variáveis no escopo onde foi chamada. É necessário passar um segundo argumento para ter um array gerado por referência, como no exemplo acima com a variável $query.

3 – ler páginas remotas

Dentre todas as implementações, a mais desnecessária costuma ser fsockopen, fwrite, feof, fgets e fclose para ler arquivos remotos por HTTP.

Uma função já resolve:

Isso é possível graças aos protocol wrappers que encapsulam a lógica de acesso aos respectivos protocolos, tal como HTTP. Esta forma de acesso, no entanto, depende da configuração allow_url_fopen estar habilitada no php.ini (que é o padrão).

Para ler os response headers da requisição, utilize fopen com stream_get_meta_data.

E se um dia você quiser impressionar a mulherada, veja a função stream_wrapper_register para criar o seu próprio protocol wrapper.

4 – submeter dados por post para uma página remota

A coisa fica mais complicada quando o desenvolvedor pensa em usar cURL pra submeter dados por POST para outro servidor. A extensão até tem seu mérito, mas usá-la apenas pra este propósito é um grande equívoco.

As funções que fazem uso dos protocol wrappers aceitam um objeto de stream context, criado pela função stream_context_create, para configurar alguns aspectos do protocolo. As opções de contexto do protocolo HTTP permitem definir, entre outras coisas, o método de acesso (GET, POST, etc) e o conteúdo a ser postado:

Quando não for necessário ler o retorno da requisição, basta chamar a url com fopen passando o contexto como quarto argumento.

5 – fazer download de um arquivo remoto

Vale lembrar que a maioria das funções de stream e filesystem aceitam URLs completas e fazem uso da abstração do protocolo. O que eu vejo muita gente esquecer é que isso inclui a função copy:

O trecho acima vai baixar a imagem remota e salvar no arquivo local /tmp/Terri Clark.jpg. E caso não seja óbvio, “local” se refere a quem está executando o script PHP, que no caso será o seu servidor caso seja um script web, e não o cliente que está acessando pelo browser.

Se o objetivo for realmente repassar o conteúdo remoto para o cliente que estiver acessando pelo browser, o script é igualmente simples:

Considerando que estamos apenas testando a funcionalidade. Ter um script de proxy totalmente funcional é bem mais complexo, e certamente já tem algo pronto por aí.

6 – fazer cálculo com data

Dentre todas as simplificações possíveis, a que mais costuma comover é a função strtotime. Pra quem já está acostumado, parece que não faz mais do que sua obrigação. Mas pra quem ainda faz cálculos com data multiplicando por 86400, chega a parecer mágico:

Mais exemplos você mesmo pode ver no manual do PHP ou na página de Date Input Formats do projeto GNU. Para o nome dos meses e dias da semana ficarem em português, utilize setlocale(LC_TIME, ‘pt_BR’); antes de chamar a função strftime.

7 – escapar sql e html

Felizmente nunca mais vi nenhum script com aberrações anti-sql-injection, mas há algum tempo era possível encontrar pessoas removendo palavras-chave de SQL de todas as strings que íam para o banco de dados. Se o usuário digitasse palavras como select, delete ou drop, elas eram simplesmente removidas da frase. Isso quando o programador não interrompia o script e acusava o usuário de estar tentando explorar alguma falha de segurança. Eu juro, isso existia.

Ao trabalhar com PDO, a melhor opção (pra não dizer a única!) é utilizar prepare e execute pra separar a query em si dos seus parâmetros:

Se estiver utilizando drivers nativos, veja as funções mysql_real_escape_string ou mysqli_prepare e mysqli_stmt_bind_param, dependendo da extensão. Certamente outros bancos de dados têm a mesma funcionalidade.

A única preocupação é garantir que os parâmetros não se misturem com a query; não precisa inventar moda e remover o que o usuário digitou.

Outra confusão comum é ao escapar HTML. O objetivo é evitar que o texto digitado por um usuário seja interpretado pelo browser de todos os usuários do site.

Conceitualmente, esta é uma responsabilidade da camada de exibição. O template é que deve utilizar htmlspecialchars antes de gerar a saída na tela, e não antes de salvar no banco. Isso garante que o conteúdo que está no banco é fiel ao que foi digitado pelo usuário e pode ser reaproveitado em outras mídias além do HTML.

O que pode e deve ser feito é filtrar conteúdo realmente indevido, como caracteres inválidos ou espaços extras, dependendo da aplicação.

Pra quem usa Debian ou semelhante, como o Ubuntu, talvez as notas abaixo sejam úteis na hora de gerenciar os pacotes pelo aptitude.

Resumo

• CTRL-T para acessar o menu
• %D é o atributo de package size no display format
• u para update
• U para upgrade
• g para executar e confirmar as alterações
• : para ignorar a atualização de um pacote
• = para deixar o pacote nesta versão até a segunda ordem
• G para filtrar ou alterar a exibição da lista de pacotes
• filter(~i !~M) mostra apenas os pacotes instalados manualmente
• m para marcar um pacote como instalado manualmente
• M para marcar um pacote como instalado automaticamente
• Isso é só cultura inútil, ignore se tiver outra coisa pra fazer

Pacotes recomendados

Uma boa coisa a se fazer ao instalar o sistema do zero é configurar o aptitude para não instalar os pacotes recomendados automaticamente, somente as dependências. Isso poupa dezena de pacotes que você provavelmente não quer.

A opção está disponível no menu Options -> Preferences, que pode ser acessado pressionando CTRL-T. Desmarque a opção Install recommended packages automatically.

Pacotes desnecessários

Logo abaixo tem a opção Remove unused packages automatically. Confirme que ela esteja marcada para garantir que pacotes que foram instalados para satisfazer dependências sejam removidos quando não forem mais necessários.

Package size

Ainda nas preferências, acho legal incluir a coluna com o tamanho do pacote a ser baixado, em caso de atualização ou nova instalação.

Edite a opção The display format for package views e inclua o atributo %D. Aqui a configuração ficou %c%a%M%S %p %Z %D %v %V.

Saber o tamanho do pacote ajuda na hora de priorizar alguns e desistir de outros, caso tenha muita coisa para atualizar.

Ignorando atualizações

Para atualizar o sistema, utiliza-se a tecla u (minúsculo) para atualizar a lista de pacotes do repositório (o mesmo que o comando aptitude update ou apt-get update) e depois a tecla U (maiúsculo) para marcar para atualização os pacotes com versões mais novas disponíveis (o mesmo que aptitude upgrade ou apt-get upgrade).

Para executar as alterações, pressione g (minúsculo). Você será levado para uma tela de preview. Pressione g novamente para confirmar.

Se quiser ignorar alguma atualização, pressione : em cima do pacote que deseja ignorar. Ele ficará como upgradable até o próximo upgrade (U).

Caso prefira manter o pacote na versão atual indefinidamente, pressione = em cima do pacote para deixá-lo em hold. Ele ficará aguardando neste status até que você remova o hold.

Filtrando a lista de pacotes

Na tela principal do aptitude estão listados todos os pacotes dos repositórios agrupados por tarefa, status e seção. Este agrupamento pode ser trocado através da tecla G (maiúsculo).

Uma visualização que faço frequentemente é filtrar os pacotes instalados com o filtro filter(~i !~M). O atributo ~i lista os pacotes instalados e o atributo ~M lista os pacotes instalados automaticamente para satisfazer dependências (neste caso, utilizado com negação).

Ao pressionar G, o filtro e agrupamentos ficam filter(~i !~M),section.

Marcar pacotes como instalados automaticamente

O benefício do filtro acima é poder diferenciar os pacotes que realmente se quer instalados dos que foram instalados por necessidade.

Utilizando o filtro e agrupmento como no exemplo anterior, a seção libs deveria mostrar uma quantidade mínima de pacotes, já que o que utilizamos são os programas, sendo as bibliotecas apenas para satisfazer dependências (salvo algumas exceções como a libdvdcss2, por exemplo).

Se com o filtro anterior forem exibidos vários pacotes na seção libs é porque, pro aptitude, estas bibliotecas foram instaladas manualmente. O problema disso é que, se todos os programas que utilizam a biblioteca forem removidos, ela vai continuar lá.

Para marcar os pacotes como instalados automaticamente, pressione M (maiúsculo) em cima do pacote, ou em cima da seção para marcar todos como automáticos, como no caso das libs.

Se esta é a primeira vez que você faz isso, é comum que vários pacotes sejam removidos. Nesse caso, ao pressionar g para concluir as alterações, vale a pena dar uma boa olhada no preview antes de pressionar g novamente para confirmar.

Para marcar um pacote como instalado manualmente e evitar que ele seja removido quando nenhum outro pacote depender mais dele, pressione m (minúsculo) em cima do pacote.

Caso você tenha muita paciência ou mais nada de interessante pra fazer, pode ser um bom longo passatempo percorrer toda a lista de pacotes (com filter(~i !~M)) e marcar como instalação automática aqueles que você desconhece ou acha que não precisa.

Na dúvida é melhor deixar instalado, principalmente se for algum relacionado a boot ou filesystem.

Ignore tudo isso

Em quase 100% dos casos os usuários vão preferir desconhecer os pacotes instalados e só usar o Synaptic de vez em quando. Eu entendo. Afinal são só pacotes no computador. É que eu estava sem o que fazer e precisava de algum lugar pra anotar isso, porque sempre esqueço.

Caso alguém se interesse, o User’s Manual disponível no menu (através de CTRL-T) é mais completo do que man aptitude.

E então o camarada decide programar orientado a objetos. Coloca todas as funções procedurais dentro de uma classe e acha o máximo. Comete o erro que eu chamo de Programação Orientada a Classes.

Assunto batido demais na altura do campeonato, mas com a quantidade de vezes que tenho visto isso acontecer, melhor tentar esclarecer algumas coisas.

Ultimamente, o erro mais comum tem sido ao criar classes de acesso ao banco. Não entrarei no mérito de usar ou não um framework já existente ou da vantagem de ORM. Se o cara quer criar as classes, que crie. Mas crie corretamente.

A dificuldade está em perceber os objetos e criar métodos orientados a cada um deles. Ao lidar com banco de dados, o primeiro passo é identificar os três sujeitos principais:

• a conexão com o banco
• o resultado de uma consulta, ou rowset
• e cada item desse resultado, ou row

Como assumem três papéis distintos, devem ser representados por três classes diferentes.

Surge então a dúvida se o rowset deve estender a conexão ou vice-versa. Esse pensamento é fruto direto do que o desenvolvedor acha que entendeu ao ver tantos extends por aí. Se não houvesse influência de achar que orientação a objeto significa objetos estendendo objetos, ficaria mais claro que as classes trabalham independentemente.

Estende-se uma classe para criar um subtipo dela. É perfeitamente válido que a classe Carro estenda a classe Automóvel, porque carro é um tipo de automóvel. Mas fisicamente não faz sentido que Carro estenda Motor; ele simplesmente usa um motor. Até porque, se fosse seguir essa linha de raciocínio, um carro teria que estender motor, porta, roda, volante…

A dúvida seguinte é de como interligar essas classes. A solução vem conforme identificamos o papel de cada uma delas.

A classe que representa a conexão precisa de um método para conectar no banco e outro para executar queries. Podemos assumir também que cada query tem um resultado. Sendo assim, a execução de queries deve retornar um objeto rowset.

O rowset por sua vez precisa de um resource no qual trabalhar. Logo, a conexão, que é quem vai criar este objeto, deve passar o resource no constructor, que nada mais é do que o retorno de mysql_query(), por exemplo. Uma vez construído, o rowset precisa minimamente de um método para contar a quantidade de rows retornados e outro para retornar cada row.

Seguindo este modelo, uma classe para conexão com o MySQL pode começar assim:

Um ponto importante a observar é que o resultado de mysql_connect() é associado a uma propriedade do objeto para ser referenciado mais tarde. Isso garante que, caso existam outras conexões, as funções mysql_select_db e mysql_query sejam utilizadas na conexão correspondente ao objeto no qual foram chamadas.

O método query executa a SQL passada como argumento e monta um objeto para representar o rowset, passando o resource retornado pela mysql_query() para o constructor.

No constructor, colocamos o resource em uma propriedade do objeto porque precisaremos dele nos métodos count() e fetchAssoc().

No fetchAssoc(), seria legal retornar um objeto próprio do tipo Row ao invés de retornar simplesmente um array. Isso ajuda principalmente se for necessário encapsular alguma lógica nos rows. Mas isso fica como dever de casa.

As consultas ficariam assim:

A principal diferença desta implementação com o que alguns desenvolvedores têm implementado é que os métodos estão realmente orientados aos respectivos objetos, e não amontuados em uma única classe.

Agora, pra impressionar mais as gatinhas:

1. Controle erros utilizando Exceptions
2. Leia sobre interfaces e factory pattern para saber como abstrair o driver do código final
3. Implemente a interface Iterator da SPL e utilize o rowset em um foreach
4. Crie classes de acesso para não ter SQL espalhado nos scripts
5. Finalmente, jogue tudo fora e use um framework com ORM :)

Espero que essa tentativa ajude a esclarecer também aqueles que estejam com dificuldade de desenhar seus objetos, mesmo que não sejam de acesso a banco.

Alguns sites insistem em atrapalhar a navegação utilizando alert() inadvertidamente, e isso sempre me irritou bastante. Resolvi procurar e acabei descobrindo uma forma no Firefox de desabilitar funcionalidades Javascript de acordo com políticas para cada site.

Como o Firefox ainda não tem uma interface para configurar estas regras, é necessário editar o arquivo user.js manualmente. Se o arquivo ainda não existir, basta criá-lo no seu diretório pessoal do Firefox.

Aqui o caminho é ~/.mozilla/firefox/5mmyfmm7.default, mas provavelmente esta última parte será diferente.

Depois é só reiniciar o Firefox.

Quando o site tentar utilizar o recurso desabilitado o console do Javascript irá mostrar Error: Permission denied to call method Window.alert.

Para aplicar a mesma política para mais de um site, separe os endereços por espaço. Se precisar criar diferentes políticas, separe cada uma por vírgula na configuração policynames.

O legal é que dá pra desabilitar todas as funções ou propriedades do DOM. Quem quiser pode dar uma olhada nos links Configurable Security Policies e Customizing Mozilla para mais detalhes.

E então, vai usar? Já faz isso de outra forma?

No post sobre Fluent Interface, testei seu uso para nomear métodos de forma clara e reutilizável nas consultas ao banco de dados.

Durante o desenvolvimento, percebi que o Eclipse completava o código conforme eu digitava, tornando o uso das classes extremamente simples:

No final, a linha de código soava como uma frase em português, exceto pelos caracteres adicionais para a sintaxe do PHP.

A idéia então foi exportar a lista de classes e métodos parar criar uma linguagem própria do sistema, de forma que o usuário final pudesse usar o autocomplete pela web para formar uma frase sem as distrações da sintaxe.

A interface ficou assim:

Se o player não abrir, clique aqui para ver o vídeo de demonstração da interface no Youtube.

O autocomplete ainda não acompanha o que o usuário digita sem escolher uma opção, mas já é possível selecionar as opções com o teclado ou mouse, preencher cada parâmetro pelo prompt do Javascript e ter os métodos listados de acordo com o contexto.

A biblioteca e uma aplicação de exemplo estão no projeto DslCatalog que criei no Google Code.

Abaixo seguem os detalhes de como implementar os catálogos em um banco de dados já existente em 3 passos rápidos. Rápidos mesmo, eu juro :)

Passo 1 de 3: Criando as classes do modelo

A aplicação de exemplo segue com um banco de dados SQLite neste modelo:

Atualmente o único adapter de banco de dados para uso no DSL Catalog é a Zend Db Table. Mesmo que o projeto já utilize algum outro ORM ou qualquer abstração, as tabelas deverão ser mapeadas com a Zend_Db_Table_Abstract. O que não significa mudar de biblioteca. Apenas o mapeamento das tabelas deve ser feito.

Utilizando a Zend Db Table, que já está inclusa no pacote para download, a classe da tabela de cidades do modelo acima fica assim:

class Model_Cidade_Table extends Zend_Db_Table_Abstract
{
    protected $_name = 'cidade';
    protected $_rowClass = 'Model_Cidade_Row';
}

Para as tabelas que têm chave estrangeira, é preciso mapear as colunas e a classe que cada chave referencia:

class Model_Matricula_Table extends Zend_Db_Table_Abstract
{
    protected $_primary = array('id_aluno', 'id_matricula');
    protected $_name = 'matricula';
    protected $_rowClass = 'Model_Matricula_Row';
    
    protected $_referenceMap = array(
        'aluno' => array(
            'columns'       => 'id_aluno',
            'refTableClass' => 'Model_Aluno_Table',
            'refColumns'    => 'id',
        ),
        'curso' => array(
            'columns'       => 'id_curso',
            'refTableClass' => 'Model_Curso_Table',
            'refColumns'    => 'id',
        ),
    );
}

A propriedade $_rowClass descreve qual classe representará cada linha da tabela e é onde os métodos que atuam individualmente nos objetos devem ser implementados.

Para nós isso é importante porque precisamos de uma forma genérica de representar na tela cada objeto do catálogo. Nos exemplos, a representação é feita apenas como string com o método mágico __toString que o PHP utiliza, mas com um pouco de criatividade pode-se evoluir facilmente para widgets mais elaborados.

Cada cidade será objeto dessa classe, e sua representação como string é o próprio nome da cidade:

class Model_Cidade_Row extends Zend_Db_Table_Row_Abstract
{
    public function __toString()
    {
        return $this->nome;
    }
}

O mapeamento das classes deve ocorrer para cada tabela que estará disponível através dos catálogos.

Passo 2 de 3: Criando os catálogos

Nas imagens anteriores a consulta era alunos matriculados no curso letras atualmente com status cursando. Quando esta frase é interpretada pelo parser, os tokens são separados e a árvore de execução fica dessa forma:

1. catálogo de alunos
2. critério matriculados
3. catálogo de matrículas
4. critério noCurso com argumento letras
5. critério atualmenteComStatus com argumento cursando

Para permitir esta gramática, o catálogo de alunos fica assim:

class Catalogo_Alunos extends DslCatalog_Abstract
{
    /**
     * Instancia e retorna tabela de alunos
     *
     * @return DslCatalog_Database_Adapter_Zend
     */
    protected function _factoryAdapter()
    {
        return new DslCatalog_Database_Adapter_Zend(new Model_Aluno_Table());
    }
 
    /**
     * Retorna ligação destes alunos com suas matrículas
     *
     * @return Catalogo_Matriculas
     */
    public function matriculados()
    {
         return $this->_reference('Catalogo_Matriculas');
    }
}

O método _factoryTable deve ser sempre implementado e retornar o adaptador para a tabela que o catálogo representa.

Já o método matriculados faz parte da gramática do usuário. Ele utiliza o _reference para instanciar e retornar o catálogo relacionado, passando o nome do catálogo como argumento. Para realizar o JOIN, é importante que a relação entre as tabelas esteja mapeada (no Zend Db, através da array _referenceMap).

Como no PHP não existe type hint de retorno, é fundamental que a tag @return do phpDoc seja sempre incluída corretamente, pois é através dela que a interface determina o contexto dos critérios.

E então o catálogo de matrículas:

class Catalogo_Matriculas extends DslCatalog_Abstract
{
    /**
     * Instancia e retorna tabela de matrículas
     *
     * @return DslCatalog_Database_Adapter_Zend
     */
    protected function _factoryAdapter()
    {
        return new DslCatalog_Database_Adapter_Zend(new Model_Matricula_Table());
    }
 
    /**
     * Filtra matrículas pelo nome do curso
     *
     * @param string $curso
     * @return Catalogo_Matriculas
     */
    public function noCurso($curso)
    {
        $cursos = $this->_reference('Catalogo_Cursos');
        $cursos->chamados($curso);
 
        return $this;
    }
 
    /**
     * Filtra matrículas pelo status atual
     *
     * @param string $status
     * @return Catalogo_Matriculas
     */
    public function atualmenteComStatus($status)
    {
        $criterio = 'matricula.id_aluno = matricula_status.id_aluno'
                  . ' AND matricula.id_curso = matricula_status.id_curso'
                  . ' AND CURRENT_TIMESTAMP BETWEEN matricula_status.data_inicio'
                  . '                           AND matricula_status.data_fim';
 
        $this->criteria()->join('matricula_status', $criterio, array())
                         ->where('matricula_status.status LIKE ?', $status);
 
        return $this;                          
    }
}

O interessante neste caso é que o método noCurso referencia e utiliza um critério do catálogo de cursos, mas retorna o próprio catálogo de matrículas. Isso foi necessário por conveniência na gramática para manter o fluxo no mesmo contexto. Mais detalhes podem ser vistos no antigo post sobre problema do contexto nas Fluent Interfaces.

E finalmente o método atualmenteComStatus adiciona um critério à query. Esse ponto tem mais a ver com a Zend Db do que com a lógica da DSL em si.

Os demais catálogos estão disponíveis na demonstração.

Uma vez com os catálogos criados, é preciso reuní-los para montar a gramática. Como o conjunto de catálogos tende a ser o mesmo em todo o sistema, parece interessante estender a classe dessa forma:

class Catalogo_Grammar extends DslCatalog_Parser_Grammar
{
    public function __construct()
    {
        $this->addCatalog('Catalogo_Alunos');
        $this->addCatalog('Catalogo_Cidades');
        $this->addCatalog('Catalogo_Cursos');
        $this->addCatalog('Catalogo_Matriculas');
    }
}

Passo 3 de 3: Criando a interface do usuário

Considerando a consulta do usuário em uma string qualquer (por exemplo vinda de um formulário), basta instanciar o parser e adicionar a ele a gramática que criamos logo acima.

A partir daí é possível interpretar a consulta e receber um catálogo que pode ser iterado e ter seus objetos mostrados na tela:

$consulta = 'alunos matriculados no curso letras';
 
$gramatica = new Catalogo_Grammar();
 
$parser = new DslCatalog_Parser();
$parser->setGrammar($gramatica);
 
$catalogo = $parser->parse($consulta);
 
foreach ($catalogo as $item) {
    echo $item, '<br />';
}

Para deixar a caixa de texto da consulta com autocomplete, o script dslcatalog.js deve ser incluído junto com a estrutura da gramática:

<form method="get" action="index.php">
<p>
    <input type="text" id="q" name="q" value="" />
    <input type="submit" />
</p>
</form>
 
<script type="text/javascript" src="dslcatalog.js"></script>
<script type="text/javascript">
    var gramatica = <?php echo $gramatica->getJson() ?>;
 
    new DslCatalog.AutoComplete(document.getElementById('q'), gramatica);
</script>

Na aplicação de exemplo, a gramática foi deixada em um script separado com o objetivo de ficar no cache do navegador. Falando em cache, atualmente nenhuma camada da biblioteca tem essa preocupação, mas com o tempo isso tende a melhorar.

Download

A biblioteca com a aplicação de exemplo na revisão 39 está disponível no link abaixo, já incluindo as classes necessárias do Zend Framework. É só baixar e acessar o caminho demo/public/index.php.

http://dslcatalog.googlecode.com/files/dslcatalog-r39.zip
ou
http://dslcatalog.googlecode.com/files/dslcatalog-r39.tar.gz

Para a demonstração, o único requisito é que o PDO esteja habilitado com o driver SQLite. Caso receba a mensagem The sqlite driver is not currently installed, basta instalar a extensão pelo pecl:

Uma vez instalada, algum dos arquivos do php.ini deve conter extension=pdo_sqlite.so. Depois é só reiniciar o Apache.

Testes

Se alguém puder testar para tentar levantar possíveis sugestões seria legal. E se der algum problema é só falar.

Alguns dos recursos já planejados incluem:

• outra camada de acesso ao banco quando a Zend Db se mostrar limitada;
• catálogos de agregação com possibilidade de agrupamento para consultas como total de alunos matriculados por curso e cidade;
• parâmetros por widgets configuráveis (consulta de datas em um calendário, consulta de cursos em um combo pré-definido, etc);
• item dos catálogos mostrados em seus respectivos widgets;
• melhorar o autocomplete;
• e por aí vai…

E por enquanto eu fico devendo os testes de unidade, foi pura falta de habilidade mesmo. Mas já serão providenciados.

No post sobre Fluent Interface no PHP foi apresentada uma API que terminou assim:

O banco de dados estava estruturado com as tabelas de aluno, cidade, matrícula e curso. Como a relação do aluno com o curso é através da tabela de matrícula, foi necessário um catálogo extra para adicionar o critério sem quebrar o significado dos métodos.

Para o critério do nome da cidade do aluno como chave estrangeira, bastou realizar um JOIN a partir do próprio método e continuar o fluxo no catálogo de alunos.

Neste caso é um critério simples, mas é comum acontecer o contrário, como no caso em que o aluno tem vínculo com a tabela de matrículas e esta tem vínculo com a tabela de cursos.

Poderia ser criado um método matriculadosNoCurso($curso) que fizesse JOIN nas duas tabelas, mas não seria uma prática adequada, já que o catálogo de alunos estaria assumindo uma responsabilidade do contexto de matrículas, o que em breve levaria à repetição de código.

O ideal é permitir que catálogos tenham referências entre si. O critério do nome do curso passa para o catálogo de matrículas que poderá ser associado com o catálogo de alunos.

Agora falta relacionar o catálogo de matrículas com o catálogo de alunos.

Passando o contexto para outro objeto

Começando de fora pra dentro, o catálogo de alunos precisa passar o contexto para o catálogo de matrículas para que a interface possa utilizar os seus métodos.

O método _reference é herdado da classe Catalogo_Abstract e é responsável por instanciar e retornar o catálogo desejado.

Os catálogos são mapeados em um array para que a referência não seja feita mais de uma vez a partir do mesmo objeto.

Ao instanciar o objeto, o próprio catálogo é passado como argumento para o construtor, e é nessa etapa que o relacionamento será realizado.

Aceitando a referência

Ao receber uma referência no construtor, três procedimentos precisam ser feitos:

1. guardar no array de referências o objeto passado;
2. utilizar o mesmo select, já que a query é só uma;
3. fazer JOIN entre as tabelas.

Para associar os catálogos é necessário saber o critério que os relaciona. Apesar de no Zend Framework essa informação estar disponível no reference map, parece que ainda não há uma forma automática de relacionar duas classes Zend_Db_Table. Como o uso do framework não é o foco, os detalhes serão dispensados.

Acompanhando o código:

Voltando ao contexto anterior (até porque voltar ao próximo é mais complicado)

O catálogo de alunos já se relaciona com o de matrículas, mas uma vez no contexto de matrículas, ainda não é possível voltar a utilizar os critérios de alunos.

Observando a consulta em português puro, é correto afirmar que a lista se trata de “alunos matriculados no curso Enfermagem em que os alunos sejam da cidade do Rio de Janeiro”.

Assim como o método “matriculados” serve como ligação semântica entre os alunos e suas matrículas, nada mais justo que criar um método para a ligação “em que os alunos sejam”.

Os três novos métodos fazem a mesma coisa e existem para deixar a chamada mais natural. Dessa forma, fica transparente iniciar a consulta pelo catálogo de matrículas e filtrar por $matriculas-> dosAlunos()-> daCidade(‘Rio de Janeiro’), ou voltar para o contexto de alunos e aplicar um método de estado, como $matriculas-> emQueOsAlunosEstejam()-> desativados().

De certa forma a escolha das palavras foi tendenciosa. A frase talvez devesse ser “alunos matriculados no curso Enfermagem que sejam da cidade Rio de Janeiro”, mas nesse caso seria difícil determinar o contexto a qual “que sejam” se refere, principalmente se a consulta iniciar pelo catálogo de matrículas.

Quando as chamadas começam pelo catálogo de alunos e seguem pelo método matriculados, o método dosAlunos não precisa instanciar o catálogo de alunos, porque o construtor já o adicionou como referência no array _references.

Quando mudar de contexto

Ao filtrar pela cidade do aluno ou pelo curso da matrícula, o JOIN foi feito no mesmo método e o contexto não mudou. Esta decisão foi totalmente baseada na prática.

Olhando a API, não era necessário ter algo como $alunos-> daCidade(‘Rio de Janeiro’)-> emQueOsAlunosEstejam()-> emOrdem(), porque a partir dos alunos não haveria nenhum critério específico das cidades.

De qualquer forma, pode ser interessante criar um catálogo de cidades e utilizá-lo ao filtrar os alunos, mesmo não mudando de contexto.

Com um catálogo próprio fica natural iniciar a consulta pelo contexto de cidades, possibilitando algo como $cidades-> comAlunos()-> matriculados()-> noCurso(‘Psicologia’).

Exemplo completo

Publiquei os testes no link abaixo, incluindo as classes necessárias do Zend Framework e SQL de amostra utilizando SQLite na memória. É só baixar e executar o index.php.

Código fonte navegável
Exemplo para download

Esses dias testei o uso de Fluent Interface para consulta de dados de forma semântica, tentando criar uma API legível e reutilizável que eventualmente servisse diretamente ao usuário.

Em uma API comum, uma classe de negócio tem diversos métodos que retornam uma lista de acordo com diferentes critérios. As consultas ficam próximas do seguinte:

Em um sistema real são muitas as variações de critérios e a classe acaba crescendo em quantidade de código e dificuldade de uso e manutenção.

A proposta é eliminar a necessidade de um método para cada tipo de consulta. Os critérios apenas configuram a consulta que será realizada uma única vez quando necessário, possibilitando que esses critérios de busca funcionem independentemente.

As chamadas passam a ser realizadas assim:

Para conseguir esta API é preciso:

1. encadear os métodos
2. ter a possibilidade de configurar a query dinamicamente
3. identificar quando a configuração termina para então realizar a consulta.

Ainda que existam outras técnicas para refatorar a primeira API, o uso de Fluent Interface é um avanço significativo até a implementação de Domain Specific Language para uso do usuário.

Method Chaining

O primeiro passo é perceber a simplicidade do encadeamento de métodos. Geralmente as propriedades de uma classe são definidas por métodos setters que não retornam nada. O objetivo é retornar o próprio objeto a partir de cada um desses métodos.

Esta técnica por si só apenas reduz a quantidade de código uma vez que não precisamos repetir a instância do objeto para cada setter.

Fluent Interface

Feito o encadeamento, é necessária uma mudança conceitual. O ponto principal é que a nomenclatura dos métodos deixe que a interface flua naturalmente.

Renomeando os métodos e retornando o próprio objeto é possível fazer a chamada de forma amigável:

Acima de tudo é importante manter consistência para que fique claro quais são as classes que trabalham com Method Chaining, evitando que o programador espere o próprio objeto como retorno equivocadamente.

Nestes exemplos será utilizado o prefixo Catalogo como tentativa de identificar essas classes. O uso de namespaces seria extremamente bem-vindo se a linguagem permitisse.

Montando a query

Diferente de uma API tradicional, os métodos anteriores devem apenas configurar o critério da consulta.

Mesmo sendo possível montar a SQL manualmente, uma camada de persistência que permita queries orientadas a objeto diminui muito a complexidade do código com o qual você precisa se preocupar. Os exemplos utilizam a modesta Zend_Db, mas uma biblioteca mais madura pode ser necessária no futuro.

Sobre o Zend Framework, basta saber que cada tabela é representada por uma classe que estende Zend_Db_Table_Abstract. Nessa classe, o método select retorna uma representação de SELECT na tabela, que pode ser configurada até o momento de executar a SQL.

Cada catálogo utilizará uma classe abstrata como base e implementará um método para identificar a tabela à qual está associado:

Desta forma já é possível combinar os métodos para consulta de alunos:

As últimas duas consultas resultariam na seguinte SQL:

Determinando o momento da consulta com SPL

Até então, os dois métodos do catálogo de alunos apenas configuram a consulta e retornam o próprio catálogo. Falta uma forma de executar a query.

Uma solução é adicionar um método consultar que vai utilizar a SQL gerada e retornar a lista de alunos. Esse método, contudo, não impressionaria em nada as gatinhas, sem contar que não fluiria tão bem se comparado a uma frase em português.

Tratando-se de um catálogo, espera-se dele uma lista de objetos que serão iterados em um loop. No cenário ideal, o código abaixo deve ser suficiente:

E esse de fato é o cenário real (Ohhh).

Para controlar a iteração de um objeto em um foreach, o PHP dispõe da interface Iterator da Standard PHP Library. Quando utilizada, é necessário implementar os seguintes métodos, que serão chamados nessa ordem:

1. rewind: reinicia a iteração;
2. valid: determina se a iteração deve continuar;
3. current: retorna o valor da iteração atual;
4. key: retorna o índice da iteração atual;
5. next: avança a iteração.

A consulta no Zend_Db retorna um objeto Zend_Db_Table_Rowset_Abstract, que já implementa a interface Iterator da SPL. Como a iteração no catálogo deve representar uma iteração neste rowset, basta direcionar os métodos para o objeto da consulta.

Para ficar mais claro como os métodos são chamados, vale a pena dar uma olhada nestes slides.

O problema do contexto

O filtro por cidade foi um exemplo simples para ilustrar o conceito de Fluent Interface, imaginando que exista a coluna cidade na tabela de alunos, sem chave estrangeira. No mundo real é mais complicado que isso.

No primeiro exemplo lá em cima, a proposta era filtrar os alunos matriculados no curso de Enfermagem, mas, na minha realidade, não existe vínculo direto entre curso e aluno, apenas pela tabela de matrícula.

A solução que encontrei foi criar um catálogo específico de matrículas que é instanciado pelo catálogo de alunos, já criando o relacionamento entre as duas classes, resultando em um JOIN entre as três tabelas.

Para evitar que este texto ficasse ainda mais longo, separei os detalhes em um post específico sobre problema de contexto nas Fluent Interfaces.

Domain Specific Language

Talvez ainda não pareça justificável todo o trabalho que uma Fluent Interface consistente vai gerar.

A grande vantagem só ficou clara pra mim quando o Eclipse começou a auto-completar os métodos dos catálogos. Se estou no catálogo de alunos, ele já mostra o filtro de cidade. Se eu escrevo a cidade, ele ainda permite filtrar pelos já matriculados. Uma vez na matrícula, posso filtrar pelo curso, e assim por diante.

Isso é o mínimo que se espera de uma IDE que ocupa tanta memória. Mas e se o usuário tivesse a mesma facilidade?

Ao invés de me ligarem falando “Garoto, preciso de uma lista de alunos da região norte inscritos essa semana no curso de Gestão em Saúde pelo edital da UAB que tenham blah blah blah”, a (quase) mesma fala seria digitada numa caixa de texto com auto-complete.

Não que o problema não possa ser resolvido com um formulário gigante incluindo todos os filtros de consulta possíveis, mas estamos falando de usabilidade. Interfaces amigáveis para o usuário, código amigável para o programador. Quem não achou o plugin Ubiquity minimamente interessante?

E pra quem concorda que digitar a busca nem sempre é a melhor opção, os catálogos seriam facilmente exportados para ambientes visuais. Combinados com ações específicas de cada entidade (como matricular aluno, aprovar inscrição, desativar tutor…), o código passa a ser extremamente plugável.

Para tornar isso possível, a idéia é utilizar reflexão nas classes e expor os métodos na interface do usuário. Assim que parar de fazer sol na praia e eu tiver algum tempo, vou tentar expandir estes exemplos para DSL externa. O post de Domain Specific Language externa no PHP demonstra a implementação.

De qualquer forma, no fundo vou sentir falta das tais ligações.

Exemplo completo

Uma implementação mais recente, já com interface para consulta pelo usuário, está disponível no post sobre Domain Specific Language externa.

Referências

• Martin Fowler – Fluent Interface
  http://martinfowler.com/bliki/FluentInterface.html
• Post de Guilherme Chapiewski que clareou minhas idéias sobre Fluent Interface
  http://gc.blog.br/2007/09/25/refatorando-para-fluent-interface/
• Zend Framework – Documentação da Zend_Db
  http://framework.zend.com/manual/en/zend.db.html
• Documentação da Standard PHP Library no PHP
  http://www.php.net/~helly/php/ext/spl/
• Resolvendo problema de contexto nas Fluent Interfaces
  http://garotosopa.wordpress.com/contexto-fluent-interface
• Câmera pra ver se está sol na praia
  http://transito.rio.rj.gov.br/imagens1/31.jpg

Em 1995 a Netscape^[1] teve a idéia de utilizar respostas HTTP multipart como implementação de server push, onde o servidor envia múltiplas respostas a uma mesma requisição. Treze anos depois eu me dei conta que esse streaming de dados realmente torna aplicações web muito mais dinâmicas, caracterizando o que alguns chamam de Comet^[2].

Outras opções para aplicações dinâmicas incluem deixar um iframe carregando tags Javascript eternamente; abrir uma conexão XMLHttpRequest a cada intervalo de tempo; ou implementar Long Polling, onde o servidor segura a conexão enquanto não houver conteúdo novo e, quando a resposta for enviada, um novo XMLHttpRequest é criado pelo navegador.

O grande conceito de server push é o servidor poder se comunicar com o cliente em tempo real sem que o navegador tenha que ficar pedindo atualizações. Nenhuma das soluções acima consegue atingir o estado da arte neste ponto.

Multipart

O conceito de multipart é o mesmo que utilizamos em e-mails MIME^[3], como quando enviamos e-mails com anexo. Um cabeçalho deve ser enviado definindo que o tipo da resposta é com várias partes separadas por um delimitador (boundary):

Content-type: multipart/mixed; boundary="delimitador"

E então cada uma das partes fica entre este delimitador, acompanhada do seu próprio content-type:

--delimitador
Content-type: text/plain
 
Primeira mensagem
--delimitador
Content-type: text/plain
 
Segunda mensagem
--delimitador
Content-type: text/plain
 
Mensagem final
--delimitador--

O delimitador é iniciado por dois hífens e o último deles também termina com dois hífens, indicando o final do conteúdo. Sem este último delimitador, o cliente vai ficar esperando por outras partes até que os dois hífens depois do delimitador indiquem o final do conteúdo.

Javascript

A diferença no Javascript para receber respostas multipart é apenas um parâmetro extra no objeto XMLHttpRequest:

var xhr = new XMLHttpRequest();
xhr.multipart = true;
xhr.open('GET', 'script-multipart.php', true);
xhr.onreadystatechange = function(){
    if( this.readyState == 4 && this.status == 200 ){
        document.body.innerHTML = this.responseText;
    }
};
window.onload = function(){ xhr.send(null); }

Quando configurado para respostas multipart, a requisição é dada como concluída pra cada uma das partes recebidas. A propriedade readyState recebe o valor 4 (Loaded) e o evento onReadyStateChange é disparado. A parte carregada vai estar disponível em responseText, da mesma forma que em requisições normais.

Se o XMLHttpRequest estiver configurado para multipart, é importante que o servidor responda como multipart e vice-versa.

Servidor

No servidor é necessário enviar o cabeçalho HTTP para definir o tipo de resposta como multipart. Mas diferente das mensagens MIME, o tipo de conteúdo multipart no HTTP é multipart/x-mixed-replace. A partir daí basta respeitarmos a saída com os delimitadores.

<?php
set_time_limit(0);
    
header('Content-type: multipart/x-mixed-replace;boundary="delimitador"');
echo "--delimitador\n";
    
while( true ){
    echo "Content-type: text/plain\n\n";
    
    echo date("d/m/Y H:i:s"), "\n";
    
    echo "--delimitador\n";
    flush();
    
    sleep(1);
}

Ao acessar o script acima pelo navegador já é possível ver as partes sendo trocadas na tela (daí o tipo replace).

O time limit foi desabilitado para que o script fique em execução enquanto o cliente estiver conectado. Sem ele, pela configuração normal do PHP, o script daria timeout em 30 segundos.

O content-type principal (multipart/x-mixed-replace) foi enviado com a função header por fazer parte dos response headers da requisição HTTP. Já os content-type’s de cada mensagem são enviados como saída normal, pois fazem parte do conteúdo como um todo, e não dos cabeçalhos HTTP. Para diferenciar o cabeçalho do conteúdo em si, ele deve ser terminado com uma linha em branco (\n\n). Caso não seja necessário o envio de nenhum cabeçalho, é importante ter uma linha vazia entre o delimitador e o conteúdo.

Assim que cada parte é montada, é preciso ter certeza que ela será enviada ao cliente ao invés de ficar no buffer do PHP. Dependendo do seu ambiente, pode ser necessário o uso da função ob_flush() em conjunto com flush()^[4].

Problemas

Somente Gecko

Até o momento, a interpretação de multipart pelo XMLHttpRequest está disponível apenas em navegadores que utilizam a engine Gecko, como o Firefox, por exemplo. Para manter o código compatível com outros browsers é possível checar o suporte com if( xhr.multipart != null ) e implementar outra solução como contingência. Uma boa saída é utilizar multipart nos navegadores que o suportarem e long polling nos demais.

if( window.XMLHttpRequest ){
    var xhr = new XMLHttpRequest();
}else if( window.ActiveXObject ){
    var xhr = new ActiveXObject('Microsoft.XMLHTTP');
}
function iniciar(){
    xhr.abort();
    if( xhr.multipart != null ){
        xhr.multipart = true;
        xhr.open('GET', 'script-multipart.php?multipart', true);
    }else{
        xhr.open('GET', 'script-multipart.php', true);
    }
    xhr.onreadystatechange = ler;
    xhr.send(null);
}
function ler(){
    if( xhr.readyState == 4 ){
        if( xhr.status == 200 ){
            document.body.innerHTML = xhr.responseText;
        }
        if( ! xhr.multipart ){
            iniciar();
        }
    }
}
window.onload = iniciar;

<?php
set_time_limit(0);
if( isset($_GET['multipart']) ){
    header('Content-type: multipart/x-mixed-replace;boundary="delimitador"');
    echo "--delimitador\n";
}
while( true ){
    if( isset($_GET['multipart']) ){
        echo "Content-type: text/plain\n\n";
    }
 
    echo date("d/m/Y H:i:s"), "\n";
 
    if( isset($_GET['multipart']) ){
        echo "--delimitador\n";
        flush();
        sleep(1);
    }else{
        sleep(1);
        exit();
    }
}

Controle de falha

Nestes exemplos, o script nunca terminará a requisição e o navegador vai ficar esperando novas partes enquanto a página estiver aberta. Essa é realmente a idéia. Contudo, é possível que a execução do script ou a conexão com o servidor seja interrompida inesperadamente.

Como o navegador não recebeu a indicação do fim da resposta multipart (delimitador seguido de dois hífens), o XMLHttpRequest vai ficar esperando novas partes sem que haja qualquer aviso de erro ou timeout. Uma solução razoável é implementar o controle de timeout manualmente:

var xhr = new XMLHttpRequest();
var t;
function iniciar(){
    xhr.abort();
    xhr.multipart = true;
    xhr.open('GET', 'script-multipart.php', true);
    xhr.onreadystatechange = ler;
    xhr.send(null);
    contarTimeout();
}
function ler(){
    if( xhr.readyState == 4 && xhr.status == 200 ){
        contarTimeout();
        document.body.innerHTML = xhr.responseText;
    }
}
function contarTimeout(){
    clearTimeout(t);
    t = setTimeout(iniciar, 5000);
}
window.onload = iniciar();

FastCGI buffer

Um problema que não consegui resolver foi o buffer do FastCGI. Por mais que o script faça flush e ob_flush, parece que o FastCGI mantém um buffer intocável. Neste caso essa solução não funcionaria.

No meu host, eu tenho a alternativa de executar scripts diretamente como CGI. Ao invés de ter um arquivo com extensão .php, criei o script com extensão .cgi e coloquei #!/usr/bin/php na primeira linha. Esta solução funcionou para testes, mas em produção é melhor procurar outra saída, como utilizar mod_php ou até mesmo uma forma de desabilitar o buffer do FastCGI.

Chat em PHP

Eu já tinha publicado um Chat em PHP utilizando Long Polling^[5] e acabei reescrevendo parte dele para utilizar XMLHttpRequest com requisição multipart.

Assim como no último o exemplo, o Javascript faz o controle manual de timeout. Para evitar reconexões quando ninguém mandar mensagem por muito tempo, o servidor envia um ping de tempos em tempos para manter a conexão ativa. Em navegadores que não utilizam a engine Gecko, a solução de Long Polling é utilizada.

Código fonte:
http://code.google.com/p/chatildis/source/browse/trunk/chat-multipart.php?r=10

Script para download:
http://chatildis.googlecode.com/files/chat-multipart.php

Da mesma forma que o chat anterior, esta implementação ainda utiliza o MySQL com tabela na memória para repassar as mensagens para todos os clientes. Este método está longe do ideal. Talvez em uma próxima ocasião eu tente alguma coisa com threads e Observer Pattern.

Referências

1. An exploration of dynamic documents
2. Comet (programming)
3. Multipurpose Internet Mail Extensions (MIME), Multipart messages
4. PHP: flush – manual
5. Chat PHP com XHR Long Polling

Ontem fui tentar jogar Frets On Fire e recebi o erro Could not create GL Context.

O problema ocorreu porque a biblioteca libglx.so deveria apontar para o arquivo da Nvidia, no entanto o arquivo original do Xorg estava sendo usado. Isso deve ter acontecido por causa de alguma atualização do Xorg depois de já ter instalado o driver da Nvidia.

Pra não ter que instalar o driver da Nvidia de novo, fiz o seguinte:

root@olivia:~# cd /usr/lib/xorg/modules/extensions/
 
root@olivia:/usr/lib/xorg/modules/extensions/# ls -l
-rw-r--r-- 1 root root 19243 2008-08-02 18:44 libdbe.so
-rw-r--r-- 1 root root 40804 2008-08-02 18:44 libdri.so
-rw-r--r-- 1 root root 151848 2008-08-02 18:44 libextmod.so
-rw-r--r-- 1 root root 2487120 2008-08-02 18:44 libGLcore.so
-rw-r--r-- 1 root root 426657 2008-08-02 18:44 libglx.so
-rwxr-xr-x 1 root root 763656 2008-04-06 14:34 libglx.so.169.12
-rw-r--r-- 1 root root 28767 2008-08-02 18:44 librecord.so
-rw-r--r-- 1 root root 40153 2008-08-02 18:44 libxtrap.so
 
root@olivia:/usr/lib/xorg/modules/extensions/# mv libglx.so libglx.so.xorg
 
root@olivia:/usr/lib/xorg/modules/extensions/# ln -s $PWD/libglx.so.169.12 libglx.so
 
root@olivia:/usr/lib/xorg/modules/extensions/# ls -l
-rw-r--r-- 1 root root 19243 2008-08-02 18:44 libdbe.so
-rw-r--r-- 1 root root 40804 2008-08-02 18:44 libdri.so
-rw-r--r-- 1 root root 151848 2008-08-02 18:44 libextmod.so
-rw-r--r-- 1 root root 2487120 2008-08-02 18:44 libGLcore.so
lrwxrwxrwx 1 root root 16 2008-08-30 15:36 libglx.so -> libglx.so.169.12
-rwxr-xr-x 1 root root 763656 2008-04-06 14:34 libglx.so.169.12
-rw-r--r-- 1 root root 426657 2008-08-02 18:44 libglx.so.xorg
-rw-r--r-- 1 root root 28767 2008-08-02 18:44 librecord.so
-rw-r--r-- 1 root root 40153 2008-08-02 18:44 libxtrap.so
 

Agora sim o Xorg vai utilizar a extensão GLX da Nvidia e finalmente vou conseguir jogar Frets On Fire :)

Se o outro arquivo libglx.so com o número da versão do driver não existir, daí não tem jeito, tem que instalar o driver da Nvidia.

Pra evitar que isso ocorra na próxima atualização do Xorg, sugiro instalar o driver da Nvidia do jeito Debian.

Acabei de ter esta conversa rápida sobre o porquê de implementar Interface em classes quando se trabalha com orientação a objetos e achei bastante pertinente.

Resposta curta: Interface serve para garantir que o código que utiliza o objeto vai ter determinada funcionalidade disponível; não importa como o objeto vai fazer, contanto que possa fazer. É como contratar alguém com diploma.

Referências:

• http://www.php.net/language.oop5.interfaces
• http://pt.wikipedia.org/wiki/Interface_(programa%C3%A7%C3%A3o)
• http://java.sun.com/docs/books/tutorial/java/concepts/interface.html

[19:06:24] paaaaaaaaaa–agora tomou susto num foi????

estive pensando sobre interfaces…. sobre o conceito de interfaces..

[19:06:57] paaaaaaaaaa–agora tomou susto num foi????

no que diz respeito a você apenas deixar a assinatura do método, daí a classe que implementá-la coloca o código nos métodos..

[19:07:27] paaaaaaaaaa–agora tomou susto num foi????

a primeira impressão nos faz pensar que isso não é nada pragmático, não acha?

[19:08:19] diogo In Communist China, files share you!

http://www.rankmygf.com/

[19:08:27] paaaaaaaaaa–agora tomou susto num foi????

o que é isso?

[19:08:34] diogo In Communist China, files share you!

não sei o que é uma coisa pragmática

[19:08:38] diogo In Communist China, files share you!

um site pornô

[19:08:48] paaaaaaaaaa–agora tomou susto num foi????

o título parece bem baum….

[19:09:08] diogo In Communist China, files share you!

a idéia é legal

[19:09:22] paaaaaaaaaa–agora tomou susto num foi????

a idéia da interface?

[19:09:40] paaaaaaaaaa–agora tomou susto num foi????

de certo modo faz o programador digitar mais códigos..

[19:09:41] diogo In Communist China, files share you!

a idéia do site pornô.

[19:10:00] paaaaaaaaaa–agora tomou susto num foi????

ahh ta..

[19:10:04] diogo In Communist China, files share you!

as interfaces servem de contrato entre duas pontas.

[19:10:05] paaaaaaaaaa–agora tomou susto num foi????

achei que fosse da interface..

[19:10:13] diogo In Communist China, files share you!

também é interessante.

[19:10:33] diogo In Communist China, files share you!

em uma ponta você tem um código que precisa que o objeto tenha determinado método.

[19:10:44] diogo In Communist China, files share you!

na outra ponta você tem uma classe que implementa esse método.

[19:11:03] diogo In Communist China, files share you!

a classe então implementa a interface e algum outro lugar exige que o objeto implemente esta interface.

[19:11:20] diogo In Communist China, files share you!

esse é o propósito. não importa COMO o método faz o procedimento, contanto que o objeto saiba fazer.

[19:13:32] paaaaaaaaaa–agora tomou susto num foi????

eu sei como funciona o conceito… o que digo é que isso não parece pragmático, pois vou fazer uma interface que vai apenas me trazer a assinatura do método… na classe que estou implementando a interface terei que digitar tudo mesmo…. então!!!! não seria melhor digitar de vez sem implementar tal interface?

[19:14:52] diogo In Communist China, files share you!

se você programa sozinho objetos que só servem pra você, e se você só utiliza os seus próprios objetos e só tem 1 classe que implementa tal função, sim. aí você não precisa de interface.

[19:16:42] paaaaaaaaaa–agora tomou susto num foi????

mas mesmo com vários objetos não me parece pragmático pelo simples fato de termos que escrever o código em cada objeto que implementa a interface. imagine que temos 10 objetos e temos uma interface. ao implementar essa interface nos 10 objetos escrevemos o código 10 vezes..

[19:17:47] diogo In Communist China, files share you!

imagina que você tem uma classe que baixa arquivos. ela implementa um método public function baixar($url)

[19:18:11] diogo In Communist China, files share you!

imagina também que você tem uma outra classe que precisa baixar arquivos. ela tem um método que recebe a instância de um browser, que é um objeto que sabe baixar arquivos.

[19:18:55] diogo In Communist China, files share you!

então essa classe que precisa baixar arquivos tem um método public function setBrowser( MeuBrowser $browser ) e um pouco depois, nela mesma, é feito algo como $this->browser->baixar(“http://…”);

[19:19:17] diogo In Communist China, files share you!

só que amanhã você não tem mais só essa classe MeuBrowser. você tem também a classe BrowserDoDiogo.

[19:19:57] diogo In Communist China, files share you!

as duas classes têm o método baixar($url) e a sua classe que precisa baixar arquivos não se importa se é a classe MeuBrowser ou BrowserDoDiogo que está sendo usada. sua classe só precisa que o browser tenha o método para baixar arquivos.

[19:20:29] diogo In Communist China, files share you!

então você muda a assinatura da sua classe para setBrowser( IBrowser $browser ). e cria a interface IBrowser que vai exigir que as classes que a implementem tenham o método baixar($url).

[19:20:46] diogo In Communist China, files share you!

então as classes MeuBrowser e BrowserDoDiogo passam a implementar essa interface e todos ficam felizes.

[19:20:48] diogo In Communist China, files share you!

captou?

[19:22:25] paaaaaaaaaa–agora tomou susto num foi????

poxa captei sim sua idéia..

[19:22:26] paaaaaaaaaa–agora tomou susto num foi????

mas…

[19:23:52] paaaaaaaaaa–agora tomou susto num foi????

você poderia muito bem definir o método baixar nas classes MeuBrowser e BrowserDoDiogo sem precisar da interface…

[19:24:34] diogo In Communist China, files share you!

sim. mas aí a sua classe que precisa de um browser não ia ter como garantir que o objeto que ela recebe como browser realmente tem capacidade de baixar.

[19:25:25] diogo In Communist China, files share you!

lembre-se que essa idéia de Interface é de engenheiros heheh eles precisam de uma garantia de que as coisas funcionarão sem dar erro em tempo de execução.

[19:26:10] paaaaaaaaaa–agora tomou susto num foi????

mas pensando assim…

[19:27:08] paaaaaaaaaa–agora tomou susto num foi????

eu poso fazer as classes MeuBrowser e BrowserDoDiogo implementarem uma interface e essa interface, no caso IBrowser, teria um método baixar… correto?

[19:27:16] diogo In Communist China, files share you!

exatamente.

[19:28:18] paaaaaaaaaa–agora tomou susto num foi????

de qualquer forma eu iria implementar o código do método baixar() em MeuBrowser e em BrowserDoDiogo, ou seja, isso não iria garantir a integridade 100% de que o método saberia baixar…. seriam dois códigos diferentes

[19:29:11] diogo In Communist China, files share you!

sim, mas a responsabilidade da interface é garantir que a classe TEM a capacidade de executar determinada função e não COMO ela executará! ter dois códigos diferentes é realmente a idéia da interface.

[19:29:15] diogo In Communist China, files share you!

é como um diploma.

[19:31:01] diogo In Communist China, files share you!

no PHP ainda não tem como definir o retorno do método, mas em Java é praxe você garantir também o tipo de retorno, especializando ainda mais a Interface e diminuindo as chances de falha.

[19:31:49] paaaaaaaaaa–agora tomou susto num foi????

em Java tem como garantir o retorno do método?

[19:32:25] diogo In Communist China, files share you!

sim. o método precisaria, por exemplo, retornar sempre uma instância de MeuArquivo.

[19:34:16] paaaaaaaaaa–agora tomou susto num foi????

bom, em PHP é só você fazer um método que retorne um objeto, daí você teria um método retornando uma instância..

[19:34:52] diogo In Communist China, files share you!

sim. mas a interface não pode garantir isso. em Java a interface pode garantir o retorno, e se o método não retornar a instância corretamente, provavelmente nem compila.

[19:35:30] paaaaaaaaaa–agora tomou susto num foi????

tow ligado..

Esses dias surgiu a questão da melhor forma de notificar o usuário sobre alterações no servidor em tempo (quase) real, como novas mensagens de um chat, por exemplo.

A forma mais intuitiva pra mim seria fazer requisições XMLHttpRequest em pequenos intervalos, checando por mensagens mais novas que a última mensagem já recebida. Este método, entretanto, desperdiçaria muitas requisições se o intervalo fosse muito curto ou comprometeria a experiência do usuário se o intervalo fosse maior.

A idéia proposta é manter uma única conexão XHR aberta enquanto o servidor não responder com uma mensagem nova. Uma vez que exista mensagens novas, o cliente processa a resposta e em seguida cria uma nova conexão XHR que permanecerá aberta até a próxima resposta. Dessa forma o cliente fará no máximo 1 requisição por mensagem.

Depois eu acabei descobrindo que esta é a implementação de XMLHttpRequest long polling.

O código funciona da seguinte forma:

Ajax:
    url: 'chat.php?ultimo_id=' + ultimo_id
    success:
        processar retorno json
        guardar ultimo_id
    complete:
        executar requisição novamente
PHP:
    Loop infinito:
        consultar mensagens mais novas que ultimo_id
        se houver mensagens:
            escrever mensagens em json
            parar o loop para o cliente ler o json

Funcionou muito bem em rede local com 16 clientes, cada um enviando uma mensagem por segundo. As mensagens ficaram no MySQL numa tabela na memória com Query Cache habilitado e não tive problemas com processamento do banco, ficando sempre abaixo de 6%. O Apache também não sofreu sobrecarga, tendo no máximo 3% de CPU em cada um dos 3 processos.

Sem dúvida esta implementação tem menos overhead que requisições em pequenos intervalos. Melhor que isso somente a implementação de streaming com XMLHttpRequest, que não fecharia a conexão a cada mensagem nova, mas isso fica pra depois utilizando requisições multipart.

Código-fonte:
http://code.google.com/p/chatildis/source/browse/trunk/chat.php?r=7

Script para download:
http://chatildis.googlecode.com/files/chat.php

Sempre gostei de interfaces minimalistas, e uma coisa que estava me chateando ultimamente era o desperdício de espaço com a barra de título em algumas janelas que eu só utilizo maximizadas. Nada que o Devil’s Pie não resolva.

O Devil’s Pie funciona observando as janelas que são abertas e, pra cada janela que se encaixar em alguma regra predefinida, executa as ações desejadas.

Dentre as opções de ação, é possível maximizar, definir tamanho, colocar a janela em fullscreen, jogar para outra workspace, definir posição, entre outras coisas. O que me interessou foi poder utilizar o recurso undecorate para remover a window decoration, a borda com a barra de título.

O primeiro passo é instalá-lo:
# aptitude install devilspie

O Devil’s Pie lê todos os arquivos com extensão .ds localizados em ~/.devilspie/, então, sem seguida, cria-se um arquivo com as regras e ações.

~/.devilspie/fullscreen.ds
(if
    (and
        (or
            (is (window_class) "Firefox-bin")
            (is (window_class) "Xchat")
        )
        (contains (window_property "_NET_WM_STATE") "_NET_WM_STATE_MAXIMIZED_VERT")
        (contains (window_property "_NET_WM_STATE") "_NET_WM_STATE_MAXIMIZED_HORZ")
    )
    (begin
        (undecorate)
        (unmaximize)
        (maximize)
    )
)

Neste caso o script verifica se a janela é do Firefox ou Xchat e se estão maximizadas vertical e horizontalmente e, caso a janela se enquadre nestes critérios, a decoração é removida e a janela remaximizada.

As ações de unmaximize e maximize são necessárias porque após remover a decoração sobraria um espaço vazio.

Agora basta executar devilspie que as alterações serão feitas e, se for o caso, colocar o comando para ser executado ao iniciar o X.

Firefox maximizado ainda com a barra de título

Firefox maximizado sem borda com o Devil’s Pie

Uma forma de descobrir o window_name para utilizar na regra é criando um script qualquer, ~/.devilspie/debug.ds por exemplo, com a ação (debug). Ao executar o devilspie novamente, serão mostrados no terminal alguns detalhes das janelas.

Para conhecer outras regras e ações, recomendo este ótimo artigo sobre o Devil’s Pie.