The Seaside Bookshelf, Redux

February 18th, 2008 § 0 comments § permalink

Para quem se interessou pela aplicação Seaside que eu estou desenvolvendo, eu completei uma pequena atualização para otimizar o sistema. Com as pequenas atualizações efetuadas, o sistema agora roda em uma velocidade aceitável mesmo no servidor pequeno onde está e não está mais usando nada em memória.

Por causa das otimizações, o código agora está mudando algumas classes básicas do Magritte e por isso os dois pacotes são necessários para rodar o sistema corretamente.

O código está abaixo:

O próximo passo é migrar o sistema para Couch DB e ver o que acontece.

The Seaside Bookshelf

February 13th, 2008 § 4 comments § permalink

Para quem tem curiosidade de saber como é uma aplicação Seaside depois de ler tanto sobre o assunto aqui, estou disponibilizando o código inicial de um experimento meu: um pequeno sistema para guardar informações sobre os livros que estou lendo, quero ler ou já li.

A propósito, antes que alguém pergunte, já passo minhas desculpas ao Caffo pela cópia explícita do formato que ele usa. É claro que a dele é bem mais bonita–e bem mais rápida no momento.

Alguns pontos sobre o código que está rodando no servidor como demonstração:

  • Essa é uma versão alpha. Não espere sutilezas no código;
  • O aplicativo depende de uma instância do OODBMS GOODS. Os dados dessa instância podem ser configurados na própria aplicação;
  • O login é uma gambiarra terrível. Eu comecei a fazer um sistema de usuário, fiquei com preguiça e fixei em um único usuário embora o modelo esteja lá para suporte futuro;
  • A versão no servidor é lenta, muito lenta. Eu não estou usando nenhuma das técnicas usuais de deployment e o servidor onde a aplicação está é muito pequeno;
  • A aplicação está armazenando quase tudo em memória no momento e gerando os thumbnails on-the-fly, o que piora as coisas;
  • O código é específico do Squeak.

Dito isso, o sistema ilustra o fluxo básico de uma aplicação Seaside e o uso de Magritte para a modelagem de objetos. Com isso dá para ter uma idéia de como o Seaside diferente dos demais frameworks Web.

O código pode ser obtido nos endereços abaixo:

Para quem quer aprender como configurar uma VM Squeak para rodar os exemplos, em fiz um screencast sobre o assunto há um tempo atrás. Para uma imagem base, eu recomendo a Squeak-Web do Damien Cassou. Com ela, basta carregar o GOODS.

Dúvidas, sugestões, críticas e indicações veladas (ou explícitas) de como o código é péssimo podem ser feitos na área de comentários.

Atualização: Para configurar o GOODS sob o Linux, o processo é simples:

  1. Baixe e descompacte o código da última versão.
  2. Rode ./config no diretório para gerar o Makefile do sistema.
  3. Rode make para compilar
  4. Se necessário, ajuste Makefile.usr para indicar os caminhos de instalação que você deseja.
  5. Rode sudo make install para instalar

O arquivo de configuração que eu estou usando é o seguinte (bookshelf.cfg):

1
0:127.0.0.1:9081

O arquivo de opções do banco é o seguinte (bookshelf.srv):

server.admin_telnet_port="127.0.0.1:8081"

Para rodar, algo como o seguinte, onde bookshelf é o arquivo bookshelf.cfg:

sudo /opt/local/bin/goodsrv bookshelf &

Depuração: Patologia forense versus medicina, uma analogia

December 3rd, 2007 § 5 comments § permalink

Há alguns meses atrás, um programador Ruby chamado Giles Bowkett publicou um texto um tanto ou quanto provocador com o título: Debugger Support Considered Harmful.

O grosso do argumento era que Ruby não precisa de um depurador porque possui testes automatizados. Desnecessário dizer, o texto provocou repostas inflamadas de vários outros programadores dizendo que Bowkett não sabia nem o que estava falando quanto mais o que um depurador era.

Controvérsias à parte, Giles Bowkett reconheceu depois que a terminologia era inadequada, embora não tenha reconhecido a principal falha no seu argumento. Por mais que se diga que testes são preventivos–e realmente o são–o pouco uso que se fazer de um depurador em Ruby se deve, com certeza, ao fato de que até pouco tempo atrás, o suporte ao mesmo era péssimo. Eu já conversei com dezenas de programadores Rails, por exemplo, e para tarefas em que o depurador é necessário, abunda a típica técnica de depuração que o pessoal do ASP costuma chamar de Response.Write debugging.

O fato é que um testes são, em última instância, verificadores de especificação. Não tem e nunca tiveram o propósito de ajudar um programador a identificar erros esdrúxulos escondidos no meio do código.

Um programador experiente introduz cerca de um bug a cada dez linhas de código, seja qual a linguagem ou ambiente que estiver usando de acordo com o que é possível observar na maioria dos projetos. Um teste pode e geralmente revela esses bugs e um programador experiente, na maioria das vezes, consegue identificar o problema com uma única olhada no código. Quando maior a experiência, maior a chance de que uma mera verificação do código em questão revele o problema.

Entretanto, há momentos em que o problema está escondido e é necessário passar o código linha por linha e acompanhar dezenas de variáveis em busca do defeito. Nesses casos, um teste é absolutamente inútil. Mesmo que o teste seja ajustado para lidar com pedaços ainda menores do código, certas condições não aparecerão a menos que o código seja testado item por item.

A falta de um depurador nesse momento vai simplesmente fazer com que o programador introduza artefatos como impressão de variáveis, comentários de partes do código e em geral use estratégias inferiores que poderiam ser resolvidas com um suporte um pouco melhor do ambiente de desenvolvimento. Infelizmente, linguagens de scripting sofrem um pouco mais com isso e, quanto mais seu uso se intensifica, mais o problema se torna claro.

Na seqüência de comentários resultantes do texto do Bowkett, uma das respostas mais interessantes foi de James Robertson, evangelista do Cincom Smalltalk.

Em sua resposta, Robertson compara o depurador existente na maioria das linguagens a um patologista forense. O depurador faz o papel de um CSI investigando a cena do crimeapós o fato tentando descobrir o que matou a vítima. Por outro lado, o depurador sofisticado de uma linguagem como Smalltalk é mais parecido com um médico, tratando um paciente anestesiado e resolvendo seu problema enquanto o mesmo ainda está vivo.

Qualquer um que tenha trabalhado com o depurador do Smalltalk sabe que a analogia é muito própria. Durante o desenvolvimento de uma aplicação Seaside, por exemplo, o processo mais comum de depuração é o seguinte:

  1. Um teste é desenvolvido para a funcionalidade
  2. O teste é rodado
  3. O teste falha e mostra onde o problema ocorreu
  4. O código em questão (que pode até não existir ainda) é mostrado no depurador
  5. O código é corrigido (ou criado, incluindo declaração de classes, variáveis, etc)
  6. A execução é reiniciada
  7. O teste passa

Se há um problema durante a execução da página, o processo é similar:

  1. A página mostra o erro e oferece um link para o depurador
  2. O link é clicado e o depurador se abre na imagem em execução
  3. O código é corrigido
  4. A página é continuada
  5. A página termina de executar, já com o novo código, como se nada houvesse acontecido

O depurador, então, é parte integral do processo de desenvolvimento e, na verdade, não deveria ser chamado de depurador. É mais um explorador do estado do código atual, visto dinamicamente.

Qualquer mudança feita durante a depuração se propaga pelo ambiente todo instantaneamente. Da mesma forma, se um erro acontece durante a depuração, um novo depurador é aberto com as mesmas propriedades. Corrigido o novo problema, a execução retorna ao depurador inicial e o processo continua daí. Não existem coisas como loops infinitos ou necessidade de reiniciar uma página ou código para testar a correção de um problema. Como Robertson coloca no final de seu texto, é uma questão de pedir ao sistema para se explicar sobre o que está acontecendo.

Nesse sentido, não há comparação entre os depuradores comuns, seja do Ruby ou do C# ou o que você quiser. A diferença é grande demais para ser considerada. E dizer que testes resolvem esse problema é a mesma coisa que dizer que você pode resolver problemas de código escrevendo documentação. A arrogância e a incompreensão simplesmente se tornam auto-evidentes.

Screencast: Configurando um ambiente para o Seaside

September 4th, 2007 § 11 comments § permalink

A pedidos, gravei um screencast mostrando como fazer a configuração básica de um ambiente Squeak e como começar o desenvolvimento com o Seaside.

Você pode baixar em dois formatos:

É um vídeo bem básico, mas acredito que ajuda um pouco no sentido de pelo menos indicar o proverbial caminho das pedras para o desenvolvimento Seaside.

Peço desculpas antecipadas por qualquer erro grosseiro verbal, mental ou similar no vídeo: ja atribuo a culpa antecipada ao horário. E antes que alguém pergunte, sim, o som ficou baixo–aumente um pouco para conseguir escutar.

Quaisquer dúvidas, fiquem à vontade para postar nesta entrada e eu tentarei responder.

Palestra Seaside disponível

September 3rd, 2007 § 4 comments § permalink

A gravação da palestra que eu dei no último sábado sobre Seaside já está disponível no site da e-Genial. No momento, você pode baixar a apresentação em formato SWF, mas logo ela estará disponível também via streaming.

Se você assistiu a palestra e tem alguma dúvida, fique à vontade para usar esta entrada como área de perguntas. Prometo tentar responder todas, embora talvez não imediatamente.

Palestra sobre Seaside no sábado

August 29th, 2007 § 2 comments § permalink

Só para lembrar os interessados, a palestra que eu vou dar sobre Seaside acontece no sábado próximo às 14h:30 (horário oficial).

Como mencionado anteriormente, a mesma será feita usando a estrutura do TreinaTom e basta acessar o site do evento do dia para entrar no ambiente.

Vídeos da maratona de palestras

August 23rd, 2007 § 3 comments § permalink

Os vídeos da maratona de palestras promovidas pela e-Genial no sábado passado já estão disponíveis para download e streaming direto.

São oito palestras diferentes com aproximadamente uma hora de duração com tópicos bem diversos e interessantes. Vale a pena dar uma conferida.

Palestra de linguagens de programação hoje

August 18th, 2007 § 1 comment § permalink

Só lembrando os interessados, a palestra sobre linguagens de programação que eu vou dar no ciclo de palestras da e-Genial é hoje.

Syx

August 14th, 2007 § 7 comments § permalink

Descobri hoje uma nova implementação do Smalltalk chamada Syx. O projeto parece estar bem avançado, rodando em várias plataformas e com uma implementação bem completa do padrão Smalltalk-80.

Pelo que deu para perceber do que está documento do site, o foco principal é a simplificação do Smalltalk para desenvolvimento com scripting e integração com o sistema operacional. Esse é um foco muito bom na minha opinião, porque é geralmente a maior limitação das demais implementações. E com o fim do Dolphin Smalltalk, a melhor implementação Windows anterior, um espaço ficou vazio.

Outro ponto interessante, percebido nos scripting é que já há uma preocupação com a possibilidade de construção de interfaces gráficas de uma maneira mais tradicional. Isso é muito importante para a disseminação de qualquer linguagem de programação.

No geral, parece um esforço organizado e ativo. Se o projeto continuar, vai ser um bom ganho para a comunidade de linguagens dinâmicas.

Mind-boggling…

July 20th, 2007 § 2 comments § permalink

Este é um dos motivos pelos quais Smalltalk estará sempre à frente do seu tempo. Completamente mind-boggling

Where Am I?

You are currently browsing the Smalltalk category at Superfície Reflexiva.