A questão girava em torno de 1 chance em 100 de algo acontecer. A declaração por si só já afirma quais as chances de acerto, mas, em média, quantas tentativas realmente são necessárias pra tirar a sorte grande?

Eu achava que uma média não existia. Diferentes amostragens apontariam diferentes resultados, sem que fosse possível determinar com precisão a média de tentativas até conseguir um acerto.

Lawrence achava que não, que a média seria a metade do número de opções. Isto é, ao jogar um dado de 6 lados, seriam necessárias, em média, outras 3 jogadas pra conseguir tirar o mesmo lado.

Apostamos então que sortearíamos um número de 1 a 100 e calcularíamos a quantidade de vezes para achar o mesmo número, repetindo o cálculo 100.000 vezes para então tirar a média. Se a média ficasse na metade, entre 45 e 55 vezes, Lawrence ganharia a aposta. Qualquer outro resultado a vitória seria minha.

Assim que voltamos do almoço, preparamos o seguinte script:

Para nossa surpressa, o resultado foi 100.

Consistentemente, a quantidade média de tentativas para acertar um número dentro de um conjunto é o tamanho do próprio conjunto.

Logo que viu o resultado, Lawrence repensou sua aposta e concordou que realmente faz todo sentido, perdera por pura distração. Já eu estou sem entender até agora, realmente achava que não seria possível ter uma média fiel. Afinal, 1 chance em 100 pode ocorrer de primeira ou levar mil vezes pra acontecer.

Fizemos outros testes com conjuntos menores e maiores e o resultado era sempre 100% a quantidade de possibilidades, com apenas alguns décimos de diferença.

O curioso é que essa média é atingida rapidamente, nem precisa dos 100.000 testes, como demonstrado no gráfico abaixo.

Mas isso considerando a média aritmética, que é facilmente desequilibrada quando um teste azarado leva muito tempo para encontrar o número sorteado. Se considerarmos a moda dos resultados, ou seja, a quantidade de vezes tentadas mais observada, o gráfico fica mais favorável pro apostador.

Olhando por esse lado, sinto-me na obrigação de devolver os R$ 5 que ganhei. Até porque ele ainda acertou ao sugerir que o resultado seria previsível, enquanto eu insistia que seria sempre aleatório.

Devo declará-lo vencedor ou aposta é aposta?

Até então, os métodos para testar funcionalidades eram derivados da classe que o teste deve estender. Sendo assim, para acessá-los, utilizava-se $this->métodoParaTestarAlgo(). Um caso de teste ficava assim:

O novo recurso sugeria incluir um script que definia todas essas funções de teste como globais, de forma que não precisariam mais ser utilizadas no objeto $this, e sim diretamente:

Uma das reações que surgiram nos comentários foi que esse recurso polui o escopo global, e existe uma regra santa que diz que isso não deve ser feito.

Na prática, o problema real é que o projeto que está sendo testado, alguma biblioteca dependente ou o próprio PHP também poderia definir funções globais com o mesmo nome, o que causaria problemas. No caso das bibliotecas não há muito o que falar, mas imagino que alguém que é contra o uso dessas funções globais no PHPUnit não teria funções globais no próprio projeto. Argumento válido, de qualquer forma.

O que mais me incomodou, na verdade, foram argumentos que davam a entender que os testes devem ser orientados a objetos, porque orientação a objetos é uma boa prática. Amém.

O problema é que esses métodos não são “orientados” ao “objeto”, no sentido literal do termo, e pra mim isso faz toda diferença – é basicamente o que distingue o certo do errado, o bem do mal, o Mestre dos Magos do Vingador, O Ryu do M. Bison, o Jacob do Monstro de Fumaça… Isso me levou a pensar que alguns autores imaginam que colocar funções numa classe e chamá-las com $this é uma boa prática por si só.

Analisando a classe PHPUnit_Framework_TestCase, ela estende a classe PHPUnit_Framework_Assert (que é onde os métodos de teste são definidos), apenas para permitir o uso destes através do $this. Aí que mora a raiz do problema.

Na verdade, TestCase não é um Assert, e a regra santa que proibe funções globais também diz que estende-se uma classe quando se tem um subtipo dela, e não quando se quer apenas aproveitar o funcionamento.

Para reafirmar este argumento, todo os métodos da classe Assert são estáticos. Isto é, o objeto $this não é utilizado em nenhum momento.

Olhando pelo aspecto da orientação a objetos, a classe TestCase não deveria estender Assert. Só que isso implicaria em chamar a função estaticamente com PHPUnit_Framework_Assert::assertEquals() ao invés de simplesmente $this->assertEquals(). Ter os métodos no objeto do caso de teste foi apenas uma praticidade, e não uma decisão de design.

Isso é resultado da forma como o PHP funciona, especialmente porque não havia outra forma de agrupar funções se não por classes. Em Perl, por exemplo, seria bastante válido ter o pacote PHPUnit::Framework::Assert exportando todas as funções que poderiam então ser chamadas diretamente pelo nome. Mas mesmo com o recurso recente de namespaces, não seria a mesma coisa em PHP, já que funções não são importadas. Se bem que não parece tão ruim fazer use PHPUnit\Framework\Assert e chamar com Assert\equals(). Tá, é ruim, mas faz mais sentido que estender Assert.

Se alguém achar acoplado demais ter as chamadas estáticas, existem outras saídas quanto a isso. Até porque, escrever seu teste estendendo TestCase que estende Assert é igualmente acoplado. Você poderia, claro, estender outra classe que sobrescrevesse a lógica dos testes, mas seria necessário alterar a herança de todos os casos de teste, e ainda assim continuaria não tendo sentido em relação a TestCase não ser um tipo de Assert.

Pensando em baixo acoplamento, eu criaria uma interface Assert que deveria ter sua implementação injetada no caso de teste, de forma que as chamadas ficassem $this->assert->equals(), sem a necessidade de estender apenas para aproveitar o funcionamento. E já que estamos em uma linguagem dinâmica, seria possível inclusive que o objeto que implementa Assert disponibilizasse outros métodos de teste.

Além disso, existe um contador de testes estático na classe Assert, então fica até mais flexível que passe a ser um objeto instanciado reaproveitado em todos os casos de teste.

Outro argumento que li nos comentários foi sugerindo o uso de fluent interfaces; assim, as chamadas ficariam $this->assertEquals()->assertEquals(), economizando o $this do segundo teste em diante. Pra mim, é outro exemplo de vício da linguagem. As chamadas encadeadas, nesse caso, seriam utilizadas para esconder um problema que não deveria existir: as chamadas serem orientadas ao objeto – quando na verdade não são. Sem contar que hoje a classe é totalmente estática, então envolver $this no retorno para suprir a interface fluente parece fora de cogitação.

De qualquer forma, todos esses meus comentários são apenas uma reflexão superficial de como somos influenciados por características da linguagem. A estrutura do PHPUnit é excelente, com ou sem funções globais, que são apenas detalhes da implementação.

Com esse resultado eu pude identificar todas as tabelas que têm a coluna id_pessoa e buscar pelo registro que eu viria a apagar da tabela principal.

Contudo, algumas tabelas referenciavam a pessoa mas utilizavam outro nome na coluna, como na tabela mensagem em que as colunas chamavam-se id_remetente e id_destinatario. Sendo assim, foi melhor buscar pela constraint em si, independente do nome da coluna:

Como eu já havia consultado as tabelas com colunas id_pessoa, acabei acrescentando o critério AND cl1.column_name != ‘ID_PESSOA’ para que retornasse apenas as constraints com a coluna com nome diferente apontando para a coluna id da tabela pessoa.

Infelizmente, tive que fazer as duas consultas separadamente, pois, tratando-se de um sistema legado, nem todas as referências tinham constraints. Agora, se alguma tabela fazia referência com uma coluna com nome diferente de id_pessoa e também não tinha constraint, já era :)

Se quiser, faça também um select na view DICT para saber tudo que tem disponível para consulta.

Observe que no ORDER BY foi utilizada a comparação da coluna uf com o texto RJ. Como o resultado desta operação é 1 para verdadeiro e 0 para falso e foi utilizada ordem decrescente, o Rio de Janeiro aparece no topo.

Também é possível ordenar todo um conjunto, como no caso de querer as regiões numa ordem específica:

Neste caso foi utilizada a função FIELD do MySQL. Para cada regiao é retornada sua posição na lista, então para Sudeste retorna 1, para Sul retorna 2, e assim por diante. Caso alguma região tivesse ficado de fora, receberia o valor 0, daí nesse caso bastaria controlar com ASC ou DESC se as não especificadas devem aparecer antes ou depois das outras.

Claro que é menos custoso ordenar por uma coluna já processada, mas às vezes essa forma quebra um galhão :)

Considerando o esquema e os dados como demonstrados na imagem abaixo, descobrir a maior quantidade de vezes que uma música de cada banda foi executada é bastante simples:

O problema fica um pouco mais curioso quando queremos todo o registro de cada música, e não apenas o valor calculado de determinada coluna.

Intuitivamente, talvez alguém sugira incluir os outros campos na query, mas os resultados estarão incorretos:

Observe que os valores não batem. Não é Martyr of the Free World que tem 28 execuções; nem Lord of the Flies que tem 9 execuções, e assim por diante. Os valores são imprevisíveis e não representam o registro com o valor mostrado na coluna do MAX(plays).

A solução pode ser dada de algumas formas diferentes no MySQL.

Subquery dependente

Uma solução simples é filtrar as músicas onde a coluna plays tenha o valor máximo de plays daquele artista, do método mais tradicional possível:

E o resultado é obtido como esperado:

Todavia, com um número grande de artistas a consulta ficará ineficiente, já que a subquery é processada para cada artista, retornando o MAX(plays) correspondente que então é utilizado para filtrar as músicas com este número de execuções.

Tabela derivada

Para não ter que calcular a subquery para cada artista, podemos calcular todos os MAX(plays) em uma query na cláusula FROM e fazer um relacionamento com o resultado, como se fosse uma tabela normal:

O resultado é o mesmo, mas neste caso a consulta é mais eficiente, pois o MySQL calcula todos os MAX(plays) em memória uma única vez e depois apenas relaciona os registros.

Otimizando no caso de MIN() e MAX()

O próprio manual do MySQL dá uma outra dica interessante quando o objetivo é pegar todo o registro com maior valor em determinada coluna.

A técnica utiliza LEFT JOIN na mesma tabela com critérios de ser o mesmo artista e ter o número de execuções maior do que o registro da tabela original.

Ao final, a consulta retorna apenas os registros que não foram relacionados (valor NULL no LEFT JOIN), que são os registros sem nenhum outro com número de execuções maior – ou seja, os que a coluna plays é na verdade MAX(plays) daquele artista.

Esta fica sendo então a forma mais eficiente de recuperar o registro com maior valor em determinada coluna, já que não é necessário nenhum tipo de subquery e nem mesmo GROUP BY. E se quiser o menor valor, basta trocar o sinal.

A dica não vale, entretanto, para outras funções de agregação, como AVG() para média. Neste caso não tem jeito senão com subquery.

Referências

• The Rows Holding the Group-wise Maximum of a Certain Column
• Optimizing queries with EXPLAIN

Ao ler um artigo desses, saiba quem está falando e para quem está falando. Você se encaixa no perfil de se dar ao luxo de não ter uma certificação?

Analisando um dos argumentos mais comuns dos manifestantes, está o fato de que você não gostaria de trabalhar para uma empresa que valoriza certificação. Uma empresa que provavelmente tem uma área de recursos humanos que vai contratar você como recurso e não como o artista tecnológico que você é, onde você trabalhará de 8 às 17 e terá que preencher relatórios semanalmente para gerentes que não escrevem em blogs.

Esse quadro diabólico geralmente está pintado junto ao seu herói, a falácia de Equipes Ágeis e empresas supostamente bacanas de se trabalhar, como Ggl^* ou outras tantas modernas que avaliam o candidato tecnicamente, e não baseadas nas suas certificações e diplomas. Aqui no Brasil, dependendo do seu nicho, talvez você já tenha ouvido falar de como é legal trabalhar na Glb.com^* e que lá os gerentes de TI não dão valor a certificação.

Ao ler um artigo desses, o profissional concorda com os argumentos por estar cansado de ser tratado como recurso em um ambiente corporativo e por ser óbvio o fato das certificações serem criadas por empresas de tecnologia a fim de ganharem mais dinheiro e terem mais valor no mercado. Sem contar quando o profissional conhece alguém certificado que não é tão bom quanto ele, que não tem certificação. O profissional se sente enganado e decide que o melhor é aderir a essa pseudo-anarquia, já que os que o fizeram estão tão felizes nos seus blogs e empregos maravilhosos.

Mas antes de dizer não a essa conspiração dos diplomas, sugiro que você reflita sobre quem você é. Você realmente acha que vai conseguir uma vaga nessas empresas bacanas?

Porque o autor do tal artigo rebelde se parece com você apenas ao concordar que certificado não significa bom profissional. Mas você parou pra pensar no que ele, que é contra certificação, teve que fazer pra conseguir um bom emprego? Você tem feito o mesmo? Aliás, você parou pra pensar se ele é certificado? Porque muitos – e eu digo MUITOS! – dos que têm postado artigos contra certificação são, ironicamente, certificados em diversas tecnologias e metodologias, atendem a diversos workshops, fazem diversos cursos… E mesmo os que, de fato, não têm nenhum vínculo com a máfia dos selos geralmente são ícones na área e já conseguem provar capacidade de outras formas.

E você? Você é líder ou pelo menos participante de alguma grande comunidade open source? Você é referência como solucionador de bugs nos maiores softwares do mercado? Você é autor de tecnologias que outras pessoas dependem? As pessoas reconhecem você em palestras? É brilhante ou tem pelo menos um portfolio impressionante?

Sinceramente, a maioria de nós não. Somos anônimos e só queremos um emprego, e nessas horas uma certificação pesa muito quando o RH da empresa chata vai escolher os currículos pra entrevista.

Então, ao invés de fechar os olhos e achar que está sendo malandro, pare e pense no que é melhor pra você. Claro que se você preferir se tornar um popstar da galerinha nerd, ótimo, vai conseguir o tal emprego bacana. Mas enquanto isso, fica esperto!

_{* empresas fictícias já que não respondo por nenhuma das que ouvi falar}

O problema ocorre da seguinte forma:

1 – usuário autentica no site alvo normalmente

Imagine o funcionário chegando para trabalhar ou alguém em casa acessando seu site favorito.

Entra com login e senha e deixa autenticado.

2 – link malicioso

O usuário continua navegando até acessar um link preparado especialmente para explorar o sistema onde a vítima também está logada.

Neste caso, é imprescindível que o malfeitor conheça o funcionamento do sistema, o que não é difícil tratando-se de um sistema open source, algum ex-funcionário ou simplesmente alguém no mesmo sistema querendo se passar por outro usuário.

3 – página redireciona para sistema protegido

A página acessada pela vítima na verdade redireciona para o alvo. Algo como:

E não precisa ser um redirecionamento simples. Geralmente as ações são feitas apenas por POST, então um formulário com um submit automático também é utilizado.

4 – ação realizada sem intenção do usuário

Uma vez feita a requisição pelo navegador, as credenciais do usuário serão utilizadas, fazendo parecer que foi realmente o usuário que executou a ação.

Solução? Bem, você pode utilizar tokens.

Tokens para evitar CSRF

A idéia do token é criar uma chave no momento que a forma de acesso é oferecida e checar esta chave onde a ação é realizada.

Por exemplo, ao mostrar um formulário, uma chave qualquer é gerada (no controller ou alguma classe de formulários) e guardada na sessão:

Essa mesma chave é passada para sua view e incluída no formulário como um campo oculto:

Desta forma, será possível checar se a chave guardada na sessão é a mesma submetida pelo formulário:

Caso a chave esteja incorreta, notifique o usuário e mostre o formulário novamente (já preenchido, pra não ter que digitar tudo de novo). Observe que em nenhum momento a mensagem sugere que o usuário está tentando alguma fraude, até porque ele nunca faria algo do tipo contra ele mesmo.

No caso da chave ser válida e a ação ser executada, é importante limpar o token para exigir que o formulário seja acessado novamente e o ciclo recomece:

Essa técnica leva em conta que o usuário primeiro acessa o formulário para depois submeter para o script que executa a ação, além de assumir que não é possível ler o conteúdo do input hidden com o token através de outro site, contando com a segurança do navegador neste ponto.

E sem querer, os tokens garantem ainda que a ação não será executada duas vezes caso o usuário clique em Atualizar ou Voltar e depois Avançar do navegador, já que o token resubmetido não existirá mais na sessão.

Se os formulários no sistema são gerados através de uma infraestrutura organizada, plugar uma validação de tokens é provavelmente transparente. Neste caso vale a pena pensar também numa forma de permitir vários formulários abertos (separando a sessão por formulário) ou até mesmo várias instâncias de um mesmo formulário, se isso for um requisito.

A implementação fica com você :)

Um problema ao só checar o referer

Outra forma de evitar esta vulnerabilidade é checar o referer (SIC) – o endereço enviado pelo navegador da página que originou o acesso. No PHP o valor está disponível na variável $_SERVER['HTTP_REFERER'].

O próprio manual sugere que esta variável não é muito confiável, pois pode não ser enviada ou ser trocada pelo usuário. Neste assunto não faz tanta diferença, já que o facínora não teria a possibilidade de alterar esta configuração na vítima.

Checando essa variável é possível permitir ações vindas apenas do seu próprio domínio, gerando uma mensagem de erro caso alguém em outro site clique em um botão que submeta para o seu. Inclusive, o próprio servidor web pode tratar isso, sem ter que mexer na aplicação.

Esta técnica, no entanto, não previne que alguém no próprio site faça algum outro usuário executar uma ação.

Se a ação for permitida por GET fica ainda mais fácil. Se o site permitir que usuários postem imagens, mesmo que por BBcode, o resultado é catastrófico, pois não é necessário nem clicar em nada, apenas visitar uma página comum, como um fórum, por exemplo:

O navegador vai fazer uma requisição GET para carregar uma imagem na url que na verdade é o script que adiciona o engraçadinho como amigo. Aparecerá a imagem quebrada, mas se o script não exigir POST e houver checagem apenas de referer, sem token, o sistema será explorado.

Caso todas as ações sejam executadas apenas pelo método POST (na verdade, qualquer um diferente de GET), o perigo é menor checando só o referer, já que seria necessário pelo menos um formulário manipulado no próprio site para ter sucesso no ataque. Ou javascript, mas aí existiriam problemas mais graves.

Então fica a dica: implemente uma arquitetura ou um framework em que seja transparente utilizar tokens para validar formulários.

• a home foi criada sem criptografia e já está bastante cheia, não vale a pena ter que refazê-la;
• poucos arquivos precisam de proteção, então não justifica ter toda a partição criptografada;
• a home fica acessível se o notebook estiver em uso, então prefiro montar e desmontar um diretório protegido e torcer para não ser roubado nesse meio tempo.

O EncFS funciona como uma camada entre o diretório no disco e o diretório onde ocorre a montagem com seus arquivos acessíveis, criptografando tanto o nome quanto o conteúdo ao salvar, e descriptografando ao ler.

Se você é nerd e acha isso interessante, leia sobre o módulo FUSE, que permite a criação de um sistema de arquivos virtual definido pelo seu programa.

Instale o EncFS (como root):

Adicione o seu usuário ao grupo do FUSE (como root):

Crie o diretório criptografado:

O diretório ~/.crypt é onde ficam os arquivos e diretórios criptografados, e ~/crypt é onde você vai acessar os arquivos normalmente, ao montar com o encfs.

Talvez seja interessante utilizar um nome mais discreto pra que passe desapercebido por alguém que liste o conteúdo do seu diretório pessoal.

Na primeira chamada é realizada a configuração. Fiz conforme respondido abaixo:

Em seguida é necessário digitar a senha de acesso, e pronto.

Pode ser que ocorra mensagem de permissão negada no FUSE:

Isso porque o grupo foi adicionado e a sessão ainda não foi atualizada. Tente o seguinte com o seu nome de usuário:

Para acessar o diretório criptografado:

Nesse momento a senha de acesso é pedida; trate de não esquecer, pois não é possível recuperá-la.

E para desmontar quando terminar de usar:

Repare que dentro do diretório criptografado ~/.crypt foi criado o arquivo .encfs6.xml. Guarde-o com sua própria vida, pois sem ele você não conseguirá mais acessar o diretório protegido.

E é isso. Talvez alguém argumente que pode não ser totalmente seguro no caso de um estudo direcionado, mas já é um alívio no caso de um roubo aleatório do equipamento.

O primeiro passo foi conseguir conectar a entrada e saída da aplicação com o servidor web, e é o que segue relatado abaixo.

Biblioteca do FastCGI

Em um ambiente mais alto nível, como PHP com mod_php, é natural que a saída seja pelo servidor web até um browser e que exista alguma interface para acesso aos dados de entrada.

Felizmente, utilizando a API do FastCGI essa comunicação não é nada trabalhosa.

Para instalar a biblioteca de desenvolvimento no Debian:

E para utilizá-la no programa C++:

A alteração do buffer de saída teria que ser feita também para os buffers de entrada e erro, tão logo estes forem necessários.

Em uma aplicação web verdadeira, este programa funcionaria como front controller, distribuindo as requisições para as classes responsáveis.

Para compilar é preciso ainda linkar a biblioteca do FastCGI:

Iniciando o processo

O programa compilado é capaz de receber requisições através da API do FastCGI, mas para isso ele precisa ser iniciado e conectado a um Unix Socket ou porta TCP.

O próprio FastCGI dispõe de um utilitário para esta tarefa chamado cgi-fcgi. No Debian ele é instalado pelo pacote libfcgi0ldbl, que já deve estar instalado como dependência da libfcgi-dev.

Antes de executar o utilitário, é importante ter certeza que o usuário tem permissão de execução no binário do programa compilado e que o usuário do servidor web (www-data no Debian) terá acesso ao arquivo de socket criado.

É uma boa idéia também que o processo seja executado com o usuário do servidor web para não expor a segurança do sistema, da mesma forma como funciona linguagens de script que rodam no Apache, por exemplo.

Então para iniciar o processo:

O comando utiliza o usuário do servidor web para iniciar o processo (www-data), criando o socket no caminho /tmp/hello.sock e assumindo que o binário do programa compilado está no diretório atual.

Observe ainda que esta etapa de criar a comunicação por socket ou porta TCP é referente a qualquer serviço FastCGI, como no caso do Rails, Django ou até mesmo PHP, que gerenciam os processos sem utilizar o utilitário acima.

Configurando o Nginx

Uma vez criado o socket é necessário que um servidor web disponibilize o serviço por HTTP.

Com o uso da biblioteca do FastCGI, qualquer servidor web compatível pode ser utilizado, como Apache, Lighttpd, IIS, e nesse caso, o Nginx.

Para instalá-lo no Debian:

Caso já exista um servidor web instalado, talvez você queira remover a configuração do site padrão do Nginx que também utiliza a porta 80:

E para configurar o programa criado, crie o seguinte arquivo de configuração em /etc/nginx/sites-enabled/hello:

Em seguida, reinicie o Nginx:

E como a configuração foi na porta 8800, basta acessar http://localhost:8800 e pronto :)

Próximos passos

Agora que o programa já está na web, o próximo passo é achar as bibliotecas necessárias para uma aplicação web completa.

Interface com HTTP

Para simplificar a comunicação com o protocolo HTTP, o projeto Cgicc provê uma boa API para acessar os parâmetros GET e POST, upload de arquivos e cookies, além de métodos para renderizar HTML da feiosa forma antiga.

Templates

Na saída de dados o ideal mesmo continua sendo algum template engine, especialmente porque recompilar o programa a cada mudança de layout seria um caos. Existem algumas opções como ClearSilver, CTemplate ou CTPP, sendo este último o mais parecido com o que se tem hoje em dia em outras linguagens.

Sessão

Para sessão não cheguei a procurar nenhuma biblioteca, até porque com acesso ao cookie para controle do SID e acesso a um backend como Memcached, a implementação é bastante simples.

Banco de dados

Em relaçao a ORM eu não cheguei a me preocupar, já que minhas experiências com C++ provavelmente serão muito breves, mas parece que são poucas as opções.

Nos testes que fiz, utilizei diretamente a API do MySQL.

Framework

E para os que buscam um framework completo, existe o Wt. Não cheguei a testar mas parece bastante ativo.

No final das contas

Mesmo parecendo extremamente absurdo utilizar C++ na web, os únicos problemas numa empreitada dessas seriam falta de profissionais, falta de portabilidade e falta de bibliotecas, sendo esta última a mais preocupante. Na complexidade de código, parece bastante viável.

Contudo, pra quem precisa de performance, e eu diria que esse seria o maior motivo para utilizar C++, provavelmente todo mundo concordaria que Java é uma melhor opção, já que não apresenta os problemas citados acima. Exceto, claro, em um ambiente com recursos limitados como em desenvolvimento para embarcados.

De qualquer forma, vou deixar alguns programas pessoais em C++/FastCGI rodando localmente e ver no que vai dar. É impressionante para um nerd a velocidade de resposta com tão pouco uso de memória :)

Pensar nesses if’s nas reuniões de requisito era um caos, tanto para os programadores quanto para os gerentes de TI, já sabendo a dificuldade de manutenção. Sem contar a decepção do usuário que tinha que trabalhar com um sistema engessado quando a solicitação não podia ser atendida.

Mas de uns tempos pra cá, a abordagem das soluções tem mudado.

Vou tentar relatar resumidamente como tratamos uma dessas solicitações de forma que não parecesse uma gambiarra e facilitasse a manutenção, possibilitando novas lógicas sem acrescentar complexidade.

Imagino que ninguém vai se enquadrar no mesmo caso que o nosso, mas acho que a técnica pode ser útil em qualquer situação.

A realidade

Como parte de um sistema de gestão acadêmica, o relatório de desempenho escolar deve exibir os alunos da turma, suas notas em todas as avaliações do curso e a nota final de cada um deles.

Por longos anos, a nota final do aluno se resumia à média ponderada das notas de todas as suas avaliações.

Um exemplo de código simplificado para cálculo da média ponderada seria algo assim:

O requisito

Certo dia, a coordenação decidiu que determinado curso não utilizaria média ponderada para atribuir a nota final do aluno, uma vez que a proposta pedagógica do curso era diferente.

Seis meses depois, com o curso já sendo concluído, a TI foi avisada que o sistema precisaria ser alterado.

Para simplificar o exemplo aqui, vamos assumir que a nota final do aluno deste curso, e somente no caso deste curso, devesse ser apenas sua melhor nota, e não a média das avaliações.

A idéia então é que SE for ESTE curso, utiliza a melhor nota, SENÃO calcula a média ponderada.

Implementar uma condição ali mesmo, e possíveis outras no futuro, deixaria esse trecho do código extremamente sujo, difícil de manter e mais chato para ser testado.

A solução então foi abstrair a lógica em uma interface de cálculo de nota final, de forma que este trecho do código não precisasse se importar com a implementação.

O mesmo código acima passou a ficar assim:

Ou seja, a classe que trata o desempenho escolar passa a receber um objeto que calcula a nota final, dada a grade e o aluno. Estamos delegando a responsabilidade.

A implementação

O primeiro passo para tornar isso possível, na perspectiva de orientação a objetos, é definir a interface de cálculo da nota final:

Com essa interface, o objeto responsável por calcular a nota final deve implementar o método getNotaFinal, que recebe a grade e o aluno em questão, exatamente como utilizamos no código anterior.

Para receber o objeto já instanciado, nossa classe de desempenho escolar passa a ter:

Em seguida, criamos as implementações concretas, começando pelo código que foi removido no passo anterior:

E depois a forma nova de calcular a nota final:

E pronto, as duas lógicas estão separadas em classes simples, fáceis de entender à primeira vista e fáceis de serem testadas com testes unitários e mock objects.

Fabricando o objeto correto

Fica faltando, entretanto, uma forma de determinar qual curso utiliza qual lógica de cálculo.

Voltando ao código legado, isso seria feito à base de if ( $codi_cur == ‘VS’ ), else; mas queremos nos livrar desse tipo de solução e tornar o sistema mais plugável, sem precisar de gambiarra para implementações futuras.

Na implementação que fizemos, uma classe ficou responsável por receber o curso, instanciar e retornar o objeto correto, que em seguida era injetado onde precisamos, de forma que o script final ficasse assim:

Para identificar o objeto correto, criamos uma tabela no banco de dados com as classes que existem para cálculo de nota final e alteramos a tabela de cursos, para ter uma dessas classes associadas.

Considerando o uso de algum ORM, a idéia da classe é a seguinte:

Na prática, este código até poderia ficar direto no desempenho escolar, que é onde o objeto é utilizado, mas seria responsabilidade demais para a classe. Desta forma cada pequeno pedaço tem sua responsabilidade.

A tabela com as classes foi algo como:

E a alteração na tabela de curso:

Feito isso, bastou configurar todos os cursos já existentes como média ponderada (que é como funcionava antes) e o curso novo com a classe de melhor nota.

Por último, a interface para cadastro de cursos foi alterada e agora tem uma opção para selecionar a forma que a nota final é calculada.

Caso um dia o pedagógico invente outra lógica de cálculo, basta criar a classe, inserir na tabela e configurar o curso pelo próprio sistema.

Moral da história

• Delegar lógicas diferentes para classes especializadas;
• Tornar configurável a escolha da lógica;
• Carregar as classes dinamicamente;
• Injetar a implementação concreta onde apenas a interface é esperada.

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!

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 :)

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.

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.

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.