Programando Pedro

Uma das Pesquisas no Laboratório investiga o uso de C++ moderno (inicialmente 2011, agora 2014) na definição de programas bare metal. Nosso interesse geral está em aplicações de I/O e um dos nossos interesses específicos está em aplicações tipo "dispositivo criptográfico". Ao retornar para esta Pesquisa, resolvemos atualizar nossas ferramentas para obter uma implementação completa do C++ 2014. Nossa motivação foi o lançamento do GCC 5.1 que inclui suporte completo para esta nova especificação. Nosso objetivo é estudar aplicações para BIOS, UEFI, Multiboot 1 e 2 e outras "máquinas" similares emuladas com qemu. Estamos construindo programas para arquitetura i686-pc-elf . Nosso ambiente de desenvolvimento é Fedora 21 64 bits, onde as ferramentas tem arquitura alvo x86_64-redhat-linux . Apesar de x86_64 e i686 serem "compatíveis", nesse tipo de projeto é necessário um cross toolchain. Precisamos basicamente de um cross binutils e um cross g++. Existem di...

Já é a segunda vez que uso este método simples para funções "once". std::atomic initialized = false; void initialize () {    if (initialized.exchange(true)) return;    // do initialization only once } // reentrant, safe to call from async threads void api (int foo, int bar) {    initialize();    // do interesting stuff }

Hoje, mais uma vez, resolvi um problema de projeto virando o jogo de cabeça para baixo. Pretendo refazer este artigo no futuro com uns diagramas mais legais; por enquanto segue apenas o texto para não ficar esquecido. Um sistema extensível exibe padrões conhecidos; por toda parte vemos sistemas de "plugins". Imaginando nosso sistema com "plugins", vemos um elemento Central e diversos elementos Adicionais que podem ser inseridos e removidos do sistema à vontade. O elemento Central é um só e há vários Adicionais ligados ao Central. Extraindo dessa imagem uma imagem conceitual, vemos o tipo Central em relação com o tipo Adicional, onde Adicional tem multiplicidade zero ou mais. Partindo daqui para uma imagem comportamental, vemos o que acontece quando inserimos o Adicional. Ou tentamos ver. O que acontece? Quem faz o quê? Vamos supor que estamos criando tudo isso com um servidor de aplicação J2EE. Nesse ambiente, os módulos, quando iniciados, sofrem (1) inj...

É uma pequeneza mas eu gostaria muito que as linguagens da família do C permitissem retornar void quando a função retorna void . Escrever da forma a seguir me aborrece. public class Foo  {    public void log (String msg) { }    public void bar (String x, String y) { }    public void bar (String x)    {      if (x == null)      {        log("x was null");        return;      }      bar(x, "default");    } } Eu ficaria mais feliz escrevendo assim: public class Foo  {    public void log (String msg) { }    public void bar (String x, String y) { }    public void bar (String x)    {      if (x == null) return log("x was null");      bar(x, "default");     } }

Acabei de realizar quão similar é o J2EE e o Plan 9 quando observados pela lente da arquitetura de componentes: no Plan 9, o sistema de arquivos é tão capaz quanto o JNDI no J2EE. Um componente no qual eu estou trabalhando agora depende de um componente de banco de dados e de um componente de correio eletrônico. O modo de ligação entre esses componentes se dá através de JNDI: meu componente faz referência aos nomes "dataSource" e "mailSession" no seu contexto local de nomes. Na configuração do componente em uma instalação, esses nomes locais são ligados aos nomes globais que o administrador preparou para oferecer as dependências. É claro que tanto o meu componente quanto suas dependências mantém um contrato entre si, na forma das interfaces java EntityManager e Session. No Plan 9, meu componente seria um programa que faz referência a dois arquivos no seu file system -- um arquivo que repr...

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...