Programando Pedro

Recentemente surgiu a necessidade para um web service  para upload  de arquivos. Uma aplicação de HTTP com GET e PUT seria suficiente. Lendo uns artigos por aí, encontrei novamente esse discurso: "aplicações J2EE não devem escrever em arquivos". O fundamento do discurso está no fato de um componente para um ambiente gerenciado programar o ambiente gerenciado e não o sistema operacional, de modo que não deve fazer suposições sobre coisas como threads  ou arquivos. Os detalhes do argumento, porém, são péssimos. Dizer -- o componente não deve usar arquivos porque se a implantação ocorre em um cluster  os dados não serão vistos com consistência -- é uma falácia. Se você implantará o componente em um cluster  usará um sistema de arquivos compartilhado. O erro implícito nessa "sabedoria" seria igualmente cometido por um administrador de cluster  que usasse um banco de dados independente para cada nó.

Este ano estamos iniciando nossa convivência com sistemas interativos via web e escolhemos o Google Web Toolkit para nos apoiar, convictos em jamais usar pré-processamento de HTML no servidor. Enquanto este toolkit (na versão 2.4) nos pareceu desde o início uma coisa totalmente excelente, uma preocupação se manteve firme: o ciclo de desenvolvimento ótimo do GWT exige o uso do DevMode. O DevMode do GWT é um truque excelente que permite ao desenvolvedor usar um depurador Java para rastrar a execução do programa que roda no user agent . Como GWT é fundamentalmente um compilador de Java para Javascript, depurar o código-fonte de produção seria no mínimo desagradável. A configuração padrão do DevMode (na versão 2.4) inclui o web container Jetty para servir o HTML, JS, CSS, Servlets e tudo o mais que compõe o programa. O Jetty é um container simples e não inclui, entre outras coisas, uma implementação de JPA ou EJB. Ora, como este projeto pode permanecer confortável? Eventualmen...

E se a interface do sistema de arquivos focasse primeiro nos arquivos e depois nos nomes, e não o contrário? Ao invés de criar um arquivo com nome tal, os programas primeiro criam arquivos, da mesma forma como alocam memória, e posteriormente criam ligações desse arquivo para locais na árvore de nomes. Um programa que criasse um arquivo mas nunca criasse ligações teria um arquivo temporário fatalmente destruído após o término do programa. Uma referência válida para o arquivo em um programa adquire o arquivo e portanto ele não pode ser destruído; transmitir essa referência a outro programa por interprocess communication  se torna uma forma de object remoting  paralela a shared memory . Isto evidenciaria melhor a distinção no sistema de arquivos entre os arquivos propriamente ditos e os nomes; no Unix, entre os inodes  e os paths . A interface de arquivos e a interfaces de nós na árvore seria logicamente associada porém claramente distinta. Esta distinção é útil a...

Cometi pela milionésima vez o mesmo erro e deixo este artículo na tentativa de impedir a próxima: não, não interessa se a operação overlapped diz que completou imediatamente, haverá uma completion packet esperando na completion port . Apenas ignore.

Chegou, então, a hora de ressuscitar um programa desenvolvido pelo fundador da empresa em um inominável sistema UNIX rodando em i386 no passado remoto. O programa, cujo sistema de construção permitia a configuração para inúmeras variantes do UNIX de então, permaneceu compilável com mínimas modificações até o Fedora 17. Impressionante. Infelizmente, ao executar o programa, segmentation fault a torto e a direito. Com a ajuda de um debugger , alcançamos a seguinte iteração, simplificada para este artigo: for (int i = 0; i < name_list_size; ++i) {   p = (char *) getenv(name_list[i]);   if (p != NULL)     if (*p != NULL)       strcpy(value_list[i], name_list[i]); } Simples, certo? O programa levantava SIGSEGV ao avaliar a expressão *p . Como é possível? Certamente getenv retorna um endereço válido ou NULL . Certamente p não é NULL quando avalia-se *p . Qual é o tipo de p ? char * p . Por acaso o programa está s...

 Um dos objetivos da próxima iteração no meu projeto atual é quebrar o sistema em mais pedaços, e levantar os pedaços um nível de abstração até componentes COM. Uma das consequências é substituir diversas ligações mais estáticas e torná-las ligações mais dinâmicas através do COM. Tipicamente, um programa usuário de um componente COM, escrito para o Visual Studio, usará a diretiva #import para incluir na unidade de tradução C++ as declarações necessárias. Isso implica que o componente deve estar instalado na máquina que constrói o programa. O que fazer quando o componente em questão está no mesmo lote de construção que o programa usuário? A solução inicial é criar uma dependência de construção tal que o componente seja sempre construído primeiro, e usar um post-build event ao projeto do componente para registrá-lo no sistema. Desse modo, na construção do programa, o ambiente estará correto. Eu considero este arranjo prejudicial. Minha melhor razão é esta: o servidor de const...

Investigando oportunidades para otimizar um componente, experimentei definir métodos que não solicitam dados (em arrays etc.) como argumentos mas sim instâncias de IStream , e me deparei com um problema interessante: interoperabilidade com .NET. Usar componentes COM em programas .NET não é particularmente difícil; no Visual Studio, é possível adicionar componentes COM como referências no projeto. Se o componente for capaz de Automation, é possível usar a ferramenta tlbimp.exe para gerar manualmente um callable wrapper para o componente, que, se eu entendi as coisas corretamente, não precisa ser distribuído com a aplicação. Porém, todos os métodos que eu aprendi tem essa peculiaridade: eles parecem assumir que um componente não usa interfaces definidas por outros componentes -- como, por exemplo, declarando parâmetros com tipo IStream , uma interface definida pelo sistema. Pelo método do callable wrapper , a ferramenta assume que as interfaces mencionadas integram o componente...