Compilando o LLVM como uma biblioteca no Mac OS X 10.6

January 15th, 2011 § 0 comments § permalink

Esses dias andei brincando um pouco com o projeto ruby-llvm, cujo propósito é criar bindings em Ruby para o LLVM usando o Ruby-FFI. Para aprender sobre o projeto, adicionei alguns testes para a funcionalidade já existente e corrigi alguns pequenos problemas.

Para fazer isso, eu precisei compilar a biblioteca compartilhada do LLVM, que na maioria das plataformas é algo trivial. De fato, normalmente só é necessário especificar o flag abaixo no script de configuração:

./configure --enabled-shared

Eu uso o brew, na verdade, mas o princípio é o mesmo:

brew install llvm --shared

Entretanto, a compilação acima, embora passe limpa no Mac OS X, resulta nos seguintes erros quando a biblioteca é carregada no Ruby-FFI:

dyld: loaded: /Users/<user>/llvm/2.8/lib/libLLVM-2.8.dylib
dyld: lazy symbol binding failed: Symbol not found: 
    __ZN4llvm2cl6Option11addArgumentEv
  Referenced from: /Users/<user>/llvm/2.8/lib/libLLVM-2.8.dylib
  Expected in: flat namespace

dyld: Symbol not found: __ZN4llvm2cl6Option11addArgumentEv
  Referenced from: /Users/<user>/llvm/2.8/lib/libLLVM-2.8.dylib
  Expected in: flat namespace

Trace/BPT trap

Depois de algumas investigações e uma troca de e-mails com Takanori Ishikawa, eu cheguei ao seguinte patch que resolve o problema e permite que o LLVM seja compilado limpa e corretamente como uma biblioteca compartilhada:

diff --git a/Makefile.rules b/Makefile.rules
index 9cff105..44d5b2d 100644
--- a/Makefile.rules
+++ b/Makefile.rules
@@ -497,7 +497,7 @@ ifeq ($(HOST_OS),Darwin)
   # Get "4" out of 10.4 for later pieces in the makefile.
   DARWIN_MAJVERS := $(shell echo $(DARWIN_VERSION)| sed -E
's/10.([0-9]).*/\1/')

-  SharedLinkOptions=-Wl,-flat_namespace -Wl,-undefined,suppress \
+  SharedLinkOptions=-Wl,-undefined,dynamic_lookup \
                     -dynamiclib
   ifneq ($(ARCH),ARM)
     SharedLinkOptions += -mmacosx-version-min=$(DARWIN_VERSION)

As opções acima mudam os namespaces para o padrão de dois níveis do OS X e a resolução de nomes para acontecer em tempo de execução.

Usar essas opções não parecer ter causado qualquer problema em outras partes do LLVM mas eu estou curioso para entender porque não são usadas por padrão pelo projeto, especialmente considerando que muitos outros projetos fazem justamente isso como descobri depois. De fato, as opções anteriores parecem ser um legado dos dias pré-10.3 do Mac OS X. De qualquer forma, fiz essa pergunta na lista LLVM-dev.

Enquanto isso, o patch funciona para mim. Também disponibilizei uma versão modificada para o brew. YMMV.

Sobre jedis, ninjas e samurais

January 8th, 2011 § 14 comments § permalink

Geeks de todos os tipos adoram se colocarem como os equivalentes tecnológicos de alguma sociedade guerreira–real ou imaginada–que exiba uma quantidade excessiva de coolness no dia-a-dia. Eu não posso culpar ninguém que faz isso porque eu também já fiz a mesma coisa muitas vezes.

É claro, eu nunca gostei tanto de Star Wars. Sendo um fã de Star Trek, eu sempre considerei Star Wars como algo que você superava quando crescia–bom para crianças, mas não para muito além disso (por favor, sem ameaças de morte, estou brincando–bem, nem tanto assim). Star Wars é fantasia e Star Trek é ciência. Claro, os Jedi são muito mais legais e eu preferiria andar com um sabre de luz do que com um phaser mas me dê um torpedo quântico qualquer dia ao invés de qualquer arma do Império ou da República.

E há sempre os samurais–aquela velha escola, valorosa, sempre envolvida em negócios por conta de honra, muitas vezes sem qualquer esperança de sucesso. De Seven Samurai a The Last Samurai–e não dá para esquecer os livros do Eiji Yoshikawa–nós ocidentais sempre admiramos a forma como esses guerreiros japoneses se conduziam, considerando o seu Caminho do Guerreiro como algo a aspirar.

Finalmente, há também os ninjas ou shinobi. Não muito populares hoje em dia, mas houve um tempo em que eram a febre entre a população mais jovem. Como os samurais, a arte deles também era baseada em princípios de honra e dever–embora, no seu auge, eles fosse mais equivalentes a guerrilhas ou equipes Black Ops do que o modelo mais Special Forces dos samurais.

Mas uma coisa que todas ordens tem em comum é que elas eram bem monásticas, baseadas em códigos estritos sobre como proceder, treinamentos estritos ao longo dos anos e especialmente, disciplina–em muitos casos, com o peso da honra coibindo qualquer relação além da com os companheiros de armas.

Como geeks geralmente gostamos de nos comparar essas ordens porque elas são, bem, fascinantes, e sempre estavam fazendo coisas além no normal, com seus procedimentos arcanos para lidar com situações acima do que uma pessoa normal poderia encontrar.

Mas há algo que é sempre esquecido sobre essas ordens–como mencionado acima, elas eram primariamente e acima de tudo sobre disciplina; sobre um modo de vida ordenado que permitia com que a pessoa se concentrasse no que realmente importava. Tanto o treinamento histórico e real dos samurais e shinobi quanto o imaginado, inspirado pelos anteriores, dos Jedi exigia um compromisso com a disciplina que supera qualquer outra coisa que a pessoa precisaria fazer no curso de sua existência como membro dessas ordens. E, acima de tudo, requeria compromissos entre o possível e desejado e o necessário.

O que me traz ao meu ponto.

Nos últimos quatro ou cinco anos, eu fui parte de quase dez times diferentes. Já vi equipes sucederem a falharam, se recuperaram e continuarem, se unirem e se tornaram grandes, acabarem e seguir com suas vidas. Em resumo, fui parte de um número enorme de situações em que pude participar ou observar como times interagem e fazem as coisas acontecerem.

E em todos esses anos, uma das coisas mais importantes que separou os times ruins ou medianos dos grandes times foi a disciplina, que geralmente a parte mais desprezada nos exemplos que os fãs desses grupos tentam emular quando escolhem seus heróis.

É um tanto irônico que pessoas professem gostar tanto de metodologias ágeis porque estas criam ordem do caos através de times auto-gerenciáveis–times que não precisam de muita direção para fazer e acontecer, times que não precisam ser monitorados continuamente para garantir que estão indo na direção certa–esqueçam de que gerar ordem do caos exige disciplina.

A verdade é que agilidade em times só acontecem naqueles que são disciplinados e que entendem o que se ganha e o que se perde quando um projeto tem que ser cumprido. Sim, agilidade tem tudo a ver com encarar mudanças mas isso só significa que você tem que conseguir trabalhar muito bem com seus pares e com a organização como tudo–entendendo o que está mudando e quais são os meio-termos a serem alcançados–para realizar seus objetivos. Mudança sem contexto, sem disciplina, só gera caos. E isso é que muitos parecem esquecer quando se encantam com o Scrum e suas disciplinas irmãs.

Eu estava falando com um amigo outro dia e estávamos discutindo o fato de que muitos programadores usam a desculpa do ADD para procrastinarem ou para justificar distrações. Geeks, ele estava dizendo, são notórios pela sua baixa capacidade de atenção.

Eu acho–e disse para ele–que o contrário é o correto. Os verdadeiros geeks são disciplinados o suficiente para manter o seu foco e continuar no que estão fazendo a despeito das distrações. Você precisa ser muito focado se quer depurar aquele heisenbug que está mantendo você acordado nas últimas 40 horas, fazendo com que seu servidor capote a cada hora e meia. Você precisa de disciplina para continuar afundando na documentação, indo e voltando para encontrar aquela informação elusiva de permitirá que você otimize a sua rotina para que ela rode em massas de dados enormes. E você precisa de um senso forte de direção para participar de um time sem controle gerencial direto em um ambiente que está mudando continuamente.

Em resumo, disciplina é o que separa os diletantes dos artesãos. É que faz as coisas acontecerem e que realmente cria grandes times. Não quer dizer que você tenha que ser um mala sobre horários, procedimentos ou qualquer coisa assim. Não significa que você não possa se divertir ou que tenha que seguir passos ordenados toda vez que vai fazer alguma coisa. Mas significa que você tem que praticar e pensar e se focar até que isso se torna uma segunda natureza, até que você se torne um mestre no que está fazendo.

E isso é o que ninjas e samurais e Jedi fazem. Eles não param, não correm quando a proverbial situação fica preta. Eles–você sabe–simplesmente vão lá e fazem, e fazem bem.

Fazendo aquilo com o Groupon

January 2nd, 2011 § 6 comments § permalink

Há uma grande discussão acontecendo agora sobre o modelo de negócios do Groupon. Depois que a empresa recusou a oferta de aquisição do Google, a pergunta que todo mundo está se fazendo é se os donos o Groupon são insanos ou brilhantes, tão confiantes no seu modelo de negócios e na habilidade do mesmo de ir além de qualquer oferta que o Google possa fazer–e isso depois da oferta ter sido dobrada duas vezes.

John Battelle é um dos que pensam que o Groupon fez a escolha certa. Ele escreve:

Good sources have told me that Groupon is growing at 50 percent a month, with a revenue run rate of nearly $2 billion a year (based on last month’s revenues). By next month, that run rate may well hit $2.7 billion. The month after that, should the growth continue, the run rate would clear $4 billion.

Battelle atribui isso a uma combinação de fatores: relacionamentos, localização e timing–veja o artigo para uma explicação maisprofundo do que torna o Groupon quase que irresistível para pequenos negócios. E como ele nota em seu artigo, a run-rate demonstrada até agora pelo Groupon é o triplo do que o próprio Google experimentou em seus anos iniciais.

Eu estava conversando com um amigo outro dia sobre compras coletivas e ele disse que o maior problema que afetaria e eventualmente mataria o modelo de negócios dessas empresas seria o churn, isto é, o fato de que muitas dessas ofertas estão criando problemas para os pequenos negócios usando a plataforma. De fato, há dezenas de histórias sobre pessoas sendo maltratadas porque chegaram com um cupom do Groupon ou equivalente local e o negócio em questão já estava irritado por estar perdendo dinheiro com esses clientes. Eu escutei várias dessas histórias em primeira mão e em muitos casos, os donos tinham calculado incorretamente o que podiam ou deveria oferecer e ficaram descontendes com a experiência com um todo, consequentemente se tornando menos e menos interessados em trabalhar novamente com compra coletiva.

Eu acredito que o churn que estamos vendo é somente uma conseqüência da forma como novos mercados funcionam. Se o Battelle está correto–e eu acredito que sim–o churn se tornará cada vez menor à medida que os negócios encontrem seus sweet spots no ecossistema. Eu não vejo porque, por exemplo, o Groupon não possa oferecer uma ferramenta que permita que os negócios entrem com alguns parâmetros e depois deduza o preço relativamente ideal para uma certa oferta. De fato, isso nunca vai ser exatamente precisa mas dará aos negócios usando a plataforma uma maneira de evitar os problemas mais extremos.

Em última instância, porém, eu acredito que o Groupon será bem sucedido porque está mudando a forma como as pessoas se relacionam com os negócios locais. Recentemente, falando com dois outros amigos, eles me contaram como os clones locais estão tendo um impacto em seus padrões de compra.

Um deles, divorciado, nos seus quarenta, disse que não janta fora mais a menos que tenha um cupom. Esses cupons o estão ajudando a aumentar o price point dos seus gastos e, consequentemente, melhorar os locais que ele pode freqüentar. Com a ajuda dos cupons, ele está indo para locais mais caros mais vezes por semana. Essa é uma mudança grande que está beneficiando o meu amigo e os pontos que ele gosta. Como os negócios estão se tornando mais cuidados e aumentando os gastos colaterais, como bebidas e outros–algo perfeitamente aceitável–isso faz com que o resultado seja proveitoso para todos envolvidos.

O outro amigo, com seus trinta anos, disse que que compras coletivas estavam na verdade ajudando que ele transasse mais. Ele é solteiro e está usando uma variedade de cupons–restaurantes, spas, roupas, pequenos itens–para impressionar e interessar mulheres. Ele ainda está usando uma quantidade considerável de dinheiro mas o Groupon e seus similares estão fazendo com que ele gaste esse dinheiro de forma mais eficiente em direção ao seu objetivo–que, sejamos sinceros, incluem no momento transar tantas vezes quanto possível no menor período de tempo. E é quase auto-evidente pela forma que mercados funcionam que qualquer coisa que ajude pessoas a conseguirem mais sexo–ou encontram qualquer medida de satisfação sexual–está em condições muito melhores de ser bem sucedido.

E aqui você tem o resumo final: pessoas estão fazendo mais sexo com o Groupon. E isso torna a sua posição mais forte ainda. Battelle está correto–do ponto de vista dos pequenos negócios–e meu amigo também está correto–do ponto de visto do consumido.

E dos dois modos, o Groupon vence.

Sobre linguagens de programação, desespero e raiva

November 16th, 2009 § 3 comments § permalink

Isso é lindo:

[T]he State of the End-User Environment / Programming Onion…

So, in a confluence of events, I have been lately looking at Scala and yesterday spent some time looking at Pike / Thompson / Google et. al.’s “Go” language for “systems programming.” And Guido halts Python syntactic evolution before the job is done…

And it fills me with despair and anger.

Language designers in general: You are IN THE WAY. Go here:

http://www.rebol.com/oneliners.html

…then do us all a favor and don’t resist the urge to fall on that wakizashi when your shame overcomes you.

Jeff Bone

Leia mais em [FoRK] Programming languages, operating systems, despair and anger. A sensação com Go foi exatamente a que eu tive: conceitos razoavelmente interessantes empacotados em uma sintaxe que só ajuda a piorar o que havia antes.

É claro que não há balas de prata, mas há de se pensar em algo que quebre o molde que estamos usando nas últimas décadas.

A prática de arquitetura

November 9th, 2009 § 9 comments § permalink

O Lucas Húngaro, que trabalhou comigo na WebCo, escreveu há poucos dias um artigo muito bom sobre a dificuldade de dissociar nomes e funções em projetos de software e sobre sua visão do processo de desenvolvimento e arquitetura. Desnecessário dizer, concordo essencialmente com tudo o que ele diz, com algumas pequenas ressalvas.

O leitor atento do blog deve estar se perguntando agora: mas, há menos de uma semana, você não disse que lidera uma equipe separada de arquitetura onde trabalha agora–isso não é uma contradição? Na verdade, não. Antes de responder a questão, porém, peço que o leitor me acompanhe por algumas considerações.

Como o Lucas menciona eu seu texto, o tópico de arquitetura de software é bastante controverso. De fato, ao longo das quase sete décadas desde que existe algum processo de desenvolvimento, nunca se chegou a um consenso sobre o que esse termo realmente significa. Ano após ano, novos artigos e livros são escritos para explicar o que se entende pela prática e metáforas abundam.

Eu não vou dizer que tenho a palavra final sobre o assunto, é claro. Nos últimos anos, entretanto, eu tenho pensado continuamente sobre o tema, especialmente como uma reflexão sobre o meu trabalho e cheguei a uma conclusão de que minha visão é bastante similar à advogada por Fred Brooks, com algumas pequenas diferenças que refletem minha experiência própria.

Brooks, na palestra que assisti, propôs o seguinte postulado: “Não há tecnologias ingênuas no Ocidente”. O que ele quis dizer com isso é que em qualquer domínio de conhecimento, a faixa de conhecimento e habilidades exigidas é maior do que uma única pessoa pode dominar em um dado projeto.

Ele usou como exemplo o caso de fabricantes de shampoo que usam simulações do fluxo de fluidos viscosos para garantir que as lâminas misturadoras não separem a emulsão de camadas triplas do produto final; adicionalmente, ele também comentou sobre uma fábrica de bolos em que a receita do dia é modificada pela análise química dos ingredientes que chegam a cada dia na planta.

O fato é que esse tipo de especialização de engenharia é uma constante reconhecida mesmo por metodologias ágeis em que a multi-disciplinaridade das equipes é exigida como uma das premissas para o funcionamento do processo.

Por conta disso, Brooks chega à conclusão de que a única maneira de atingir algum nível de consistência e integridade no desenho arquitetural de um sistema é obter uma visão única de como as estruturas devem se comportar no seu nível mais alto: em outras palavras, criar a arquitetura de um sistema.

Em seu livro Computer Architecture: Concepts and Evolution (escrito em parceria com Gerrit A. Blaauw), Brooks define arquitetura de sistemas computacionais da seguinte forma:

The architecture of a computer system we define as the minimal set of properties that determine what programs will run and what results they will produce. The architecture is thus the system’s functional appearance to its immediate user, the conceptual structure and functional behavior as seen by one who programs in machine language.

Eu ressaltei the minimal set of properties porque isso representa uma dos grandes desentendimentos sobre o que arquitetura de software realmente significa e quais são os entregáveis da mesma. Como Brooks e Blaauw apontam, se arquitetura é o conjunto mínimo de propriedades de um sistema, existem outras coisas que, por definição não são arquiteturais e que ainda assim precisam existir para que a implementação suceda.

Nesse sentido, podemos fazer uma distinção bem clara entre a arquitetura e o design de um sistema para entender o desdobramento do projeto de um sistema qualquer. Enquanto a arquitetura existe mais no nível do mapeamento e organização fundamental de um sistema, como entendida através de seus componentes, os relacionamentos entre esses e sua distribuição em domínios de tempo, economia (sim, porque dinheiro também é arquitetura) e escala, o design está mais centrado no domínio de resolução de problemas e planejamento para implementação da solução.

Em outras palavras, a arquitetura é voltada a atingir necessidades de negócio através de blocos maiores de construção do sistema enquanto o design é a disseminação técnica desses objetivos em algoritmos, sub-sistemas e escolhas de implementação.

O que leva à conclusão, por parte de Brooks, e com a qual eu concordo, de que para que se consiga integridade conceitual e estrutural da arquitetura, a figura de um arquiteto-chefe é necessária. Isso é óbvio quando se pensa no negócio como um todo e seus desdobramentos em múltiplas responsabilidades, projetos, sistemas de sistemas e relacionamentos da construção do software em si.

Uma palavra-chave aqui que ajuda esclarecer a distinção aqui é grande porte. Por grande porte, eu quero dizer projetos com um escopo grande ou com grandes características de distribuição. Como Brooks mesmo elabora em seus textos e palestras, se o sistema é pequeno o suficiente, não é necessário que exista uma distinção entre arquitetura, design e implementação. Brooks, na verdade, vai além ao sugerir que o arquiteto e implementador sejam uma única pessoa. Para projetos de porte maior, entretanto, sem uma visão consistente é impossível conseguir a consistência necessária entre as partes.

O arquiteto de sistemas, em outras palavras, é alguém que é capaz de enxergar o projeto com um todo, necessariamente além do escopo de um time qualquer de implementação, mesmo quando o design que esse time está seguindo é auto-contido dentro das premissas daquele time e somente se comunica com externalidades através de protocolos e convenções arquiteturas definidas anteriormente.

Como um exemplo disso, em uma de suas palestras, Brooks menciona uma discussão que ele teve com a pessoal responsável pela arquitetura de sistemas do Global Positioning System (GPS). Esse arquiteto entendia que o sistema como um todo era baseada na interação complexa entre muitos componentes (satélites e outros) e que a moeda corrente entre esses sistema era tempo, dividido em micro-segundos. Ainda mais, o arquiteto via como sua responsabilidade garantir que cada processo conseguisse a fatia necessária de micro-segundos para sua operação–com, como Brooks colocou, bastante micro-segundos sobrando em seus bolsos para resgatar partes do sistema que estivessem em dificuldade.

E isso é o que realmente eu entendo por arquitetura de sistemas. Aos proponentes de arquitetura emergente–tão comum entre praticantes de metodologias ágeis–a implicação é clara: é simplesmente impossível que arquitetura nesse porte, dessa complexidade, venha algum dia a emergir de times separados, trabalhando em componentes próprios, com suas próprias necessidades. Primeiro, por conta da onipresente necessidade de integridade conceitual e, segundo, por conta da degradação de comunicação à medida que o sistema de torna mais complexo e decisões maiores são cristalizada em um conjunto de constraints e especificações–o que Brooks chama de style sheet do projeto.

Volto a Brooks aqui para afirmar o ponto de que um comitê não é um bom lugar para se buscar integridade arquitetural:

Textbook examples of design are almost always “way too simple,” said Brooks. In particular, they ignore the fact that complexity often forces designs to change halfway through, and these changes then involves many other changes. Finally, there is no substitute for “the dreariness of labour and the loneliness of thought”–even though it has been joked that committees are a place where people seek refuge from that.

O arquiteto de sistemas é, em última instância, como Brooks também coloca, um advogado do usuário. Ele advoga pelo usuário em termos funcionais, em termos econômicos, e em termos de escala. Como mostrado na citação acima, o arquiteto de sistemas representa a aparência funcional do sistema para seu usuário imediato, visto pela lente de alguém que programa em linguagem de máquina. E, sim, é um papel técnico.

Para citar Brooks mais uma vez:

Computer architecture, like other architecture, is the art of determining the needs of the user of a structure and then designing to meet those needs as effectively as possible within economic and technological constraints. Architecture must include engineering considerations, so that the design will be economical and feasible; but the emphasis in architecture is on the needs of the user, whereas in engineering the emphasis is on the needs of the fabricator.

Note a diferença em ênfase como colocada por Brooks: arquitetura enfatiza as necessidades do usuário enquanto engenharia enfatiza as necessidades do construtor.

As implicações são bastante óbvias e essencialmente respondem à questão da minha concordância com o que o Lucas disse e com o fato de que eu lidero uma equipe de arquitetura: as necessidades de desenvolvimento são completamente diferentes.

Tirando um exemplo da minha própria experiência, quando eu trabalhava na WebCo, tínhamos apenas dois produtos: Brasigo e BlogBlogs. Por mais complexos que ambos sistemas fossem, suas necessidades arquiteturais eram comparativamente pequenas. Da mesma forma, por mais similares que ambos fossem (aplicações escritas em Rails, virtualizadas, com gargalo em banco de dados, etc), havia poucas conexões arquiteturais para que a figura de um arquiteto-chefe fosse necessária.

E, de fato, pelo tamanho dos projetos, podíamos ter, sem problemas, a figura de um arquiteto em cada time, servindo como líder técnico, ponto focal em discussões entre produtos, alguém como senioridade o suficiente para fazer um papel de mentor para membros mais novos da equipe.

Esse não é o caso em minha posição atual, na Abril Digital. Não só a complexidade dos sistemas é maior, tanto em escala como em distribuição, como a relação entre eles é mais porosa e necessitando de coordenação. Construir um sistema de sistemas constituído de dezenas de sub-sistemas, cada um com suas necessidades, escopo e papel é fundamentalmente diferente de construir um único produto, com limites e condições bem específicos. Não estamos construindo algo do tamanho de um sistema de GPS, claro, mas estamos construindo coisas que possuem necessidades maiores que simplesmente as de um único escopo.

Por conta disso, surge a necessidade de arquitetura como uma colaboração de papéis empregando arquitetos de sistemas e arquitetos de software (chamados de tech leaders internamente) para chegar a um design final coerente.

Isso é ainda mais fundamental em projetos terceirizados que, em um ponto ou outro, precisam se encaixar em nossa infra-estrutura e arquitetura em múltiplos times e instâncias de sistemas. Uma equipe dedicada serve para ajudar nessa coordenação, oferecendo visões do problema. O gap arquitetural é assim resolvido já que existe uma rodovia arquitetural contendo épicos que guiam a quebra de sistemas nas partes necessárias.

Dessa quebra nascem preocupações que podem ser traduzidas no design emergente em cada equipe, contribuindo ao final, para o retorno ao pool arquitetural de conceitos e implementações feitas no ato de descoberta que é o processo de desenvolvimento.

Eu acredito nessa colaboração de papéis como essencial para garantir a agilidade. Citando um dos artigos de Martin Fowler:

This kind of architect must be very aware of what’s going on in the project, looking out for important issues and tackling them before they become a serious problem. When I see an architect like this, the most noticeable part of the work is the intense collaboration. In the morning, the architect programs with a developer, trying to harvest some common locking code. In the afternoon, the architect participates in a requirements session, helping explain to the requirements people the technical consequences of some of their ideas in non-technical terms–such as development costs.

Nesse artigo, Fowler usa uma versão limitada do que Brooks diz para definir um tipo de arquiteto não desejável. E Fowler está correto: usar o argumento de Brooks simplesmente para suportar alguém que simplesmente “toma as decisões mais importantes” não faz sentido.

Isso tudo que foi dito anteriormente não significa, também, que essa arquitetura de sistemas não possa falhar. Ela falha, sim, e algumas vezes catastroficamente. E, na maioria das vezes, a falha pode ser rastreada para decisões que foram tomadas em pontos errados do processo por problemas de comunicação ou de definição de escopo resultado em design inconsistente pelo qual ninguém quer tomar a responsabilidade. A falha, nesse caso, é de todos envolvidos no processo.

Para resumir toda a conversa, considerando que esse texto acabou quase se tornando um ensaio, eu concordo com o Lucas: cada time deve ter o seu arquiteto. Mas acredito também que, para projetos com maior escopo, deve existir um nível mais alto de arquitetura–e por mais alto aqui não quero dizer em termos de uma elite ou de conhecimento mas simplesmente um papel que defina o que é mais alto simplesmente porque tecnicamente, alguém define que esse é o nível mais alto necessário.

Esse arquiteto, dentro do time, é um desenvolvedor sênior capaz de fazer decisões de design em colaboração com seus pares, praticar a mentoria, planejar e executar escolhas de implementação, atuando em conjunto com um time de arquitetos de sistemas que está preocupado com o todo e que não tenta, de forma alguma, forçar decisões de implementação ou design, que busca embasar suas decisões pela velha métrica do running code and rough consensus, que pratica código diariamente pelos meios necessários.

O que significa, essencialmente, que a arquitetura não tem que ser fechada no começo e permanecer imutável depois disso. Ao contrário, precisa evoluir como qualquer outra parte do sistema na percepção do que funciona e do que não funciona. Como Kent Beck diz:

The process of building architecture should have lots of feedback built in and it should be kept simple, because extra elements in the architecture introduce instability and unpredictability. The big difference from current practice is that: “I would stop apologizing for architecting this way,” he says

Espero com esses monte de palavras ter clarificado um pouco a visão do que andei escrevendo aqui nos últimos tempos. Obrigado ao Lucas por fornecer a oportunidade de uma discussão boa como essa–espero que ela continue, por sinal.

Aos leitores que tiveram paciência de chegar até esse ponto, quais são suas visões e comentários sobre o assunto? A caixa de comentários lhes espera impacientemente. :-)

O gap arquitetural

November 3rd, 2009 § 0 comments § permalink

Desde que comecei a trabalhar com uma forma ou outra de metodologias ágeis, um dos assuntos que sempre me causou reflexão foi a questão de como lidar com arquitetura em um ambiente ágil. Obviamente, eu não sou o único que se questiona sobre isso: a discussão em torno de Big Design Up Front é tão velha quando a própria indústria. Existe uma polarização imensa sobre o assunto e é bem raro encontrar alguém que tenha desenvolvido alguma idéia que se encaixe no meio do caminho.

De fato, proponentes de metodologias ágeis geralmente gravitam em torno do que se comumente denomina design emergente, ou seja, a criação e concepção de conceitos arquiteturais–especialmente os não funcionais–ao longo do processo de amadurecimento da própria solução.

Duas coisas me levaram a repensar sobre o assunto nos últimos dias.

A primeira foi participar de uma palestra dada por ninguém menos do que Fred Brooks. Brooks é um dos autores mais influentes sobre a questão de arquitetura e design e eu sempre tive uma concordância forte com seus pontos de vista, especialmente no que tangem à necessidade de centralização de arquitetura como fonte de integridade conceitual em uma solução. O Mítico Homem-Mês toca profundamente nesse questão–de fato o livro pode ser considerado uma coleção de ensaios em torno desse tema–e Brooks sempre volta-se para essa necessidade de design arquitetural prévio para garantir soluções sólidas.

A segunda coisa que me levou a pensar sobre o assunto foi um tweet de Brian Foote, reportando da OOPSLA:

When we extol the benefits of architecture emerging in agile, we are really saying developers are better architects than Architects. #oopsla

Foote, conhecido pelo seu trabalho com Joseph Yoder, Big Ball of Mud, em que descreve a estruturação impensada de sistemas resultando em algo impossível de manter e impossível de se confiar, está correto em sua avaliação.

É claro que, nesse ponto, muita gente deve estar pensando que eu sou um elitista, que, de uma forma ou outra, considero arquitetos melhores do que desenvolvedores. Meu cargo atual pode até dar a entender isso–sou um gerente de arquitetura e engenharia de software na empresa onde trabalho–mas esse não é caso.

De fato, se eu tivesse hoje que me descrever em um currículo, eu teria bastante dificuldade de me conceituar em uma categoria qualquer. Eu poderia colocar que sou um desenvolvedor, já que faço isso. Também poderia colocar que sou um arquiteto, igualmente válido para o que faço. Poderia recorrer aos tradicionais programador ou analista de sistemas. A verdade é que sou tudo isso.

Para mim, um arquiteto não é alguém que atingiu um estado de santificação tal que pode abandonar os conturbados e lamacentos meandros da programação e recolher-se em sua torre de marfim para dispensar sua sabedoria sobre as massas menos iluminadas. Antes, tenho certeza de que a maioria dos meus colegas que se descrevem como arquitetos concordariam que arquitetura é mais uma questão de atuação e experiência do que de grau ou de talento nato. Eu não trabalharia com um desenvolvedor que não fosse capaz de responder por sua arquitetura e também não trabalharia com um arquiteto incapaz de codificar um algoritmo qualquer. Tentar extrair uma coisa da outra seria uma violação das premissas.

Voltando ao ponto, é justamente aí que entra a figura que Brooks descreve, o arquiteto-chefe que, por experiência, treinamento e sensibilidade adquiridos na prática, é capaz de guiar um sistema à integridade conceitual necessária para o seu bom desenvolvimento.

O que resolve, finalmente, para mim, a questão de emergência em metodologias ágeis. Eu acredito que, sim, deve haver arquitetura propriamente dita em qualquer projeto, mesmo os que subscrevem a metodologias ágeis e acho que isso nunca esteve fora da visão dos criadores das mesmas. Antes, essa é uma visão equivocada do que deve ou não emergir dentro das mesmas, que é a solução em si.

Arquitetura, por definição, é algo que precisa ser feito antes até um certo ponto, mesmo que depois sofra as mudanças necessárias por sua própria evolução gradual. Ela não pode ser estática–exceto em circunstâncias especiais que normalmente quase nenhum desenvolvedor encontrará ao longo de sua carreira–mas também não pode ser completamente ad hoc já que isso seria pouco mais do que pensar apenas no que está imediatamente adiante, sem se preocupar com os temas maiores que podem afetar o trabalho.

Em última instância, a arquitetura então não é necessariamente emergente: a solução o é. E por solução aqui, eu entendo o conjunto completo representado pelo produto, sua arquitetura, seu desenvolvimento e sua transição em produção. A responsabilidade de um arquiteto é traduzir o backlog, ou seja qual for seu equivalente, em temas conceituais que possuem integridade em conjunto e que levam a um desenvolvimento das características do software a seu tempo e com as suas necessidades atendidas.

Esse é um gap que fica claro na maior parte da discussão sobre arquitetura e metodologias ágeis e que precisa ser tratado mais freqüentemente pela literatura e seus proponentes.

Para finalizar, essa é apenas uma visão rápida do que tenho pensado nos últimos tempos sobre o assunto. Espero ter deixado minha visão um pouco mais clara do que estava em discussões passadas aqui no blog. Como sempre, comentários e discussões adicionais são sempre bem-vindos.

Sinergia Arquitetural

October 27th, 2009 § 3 comments § permalink

syn•er•gy |ˈsinərjē|
noun
the interaction or cooperation of two or more organizations, substances, or other agents to produce a combined effect greater than the sum of their separate effects

— Apple’s Mac OS X Dictionary

A definição acima não é muito padrão mas expressa bem o conceito em que a palavra é entendida hoje em dia. Sinergia vem do grego sunergos, que literalmente significa trabalhar em conjunto.

Em inglês, a palavra data de cerca de 1650, e tinha um sentido bastante medicinal, podendo indicar tanto a ação cooperativa entre dois ou mais músculos do corpo para a realização de um esforço ou a ação combinada de medicamentos ou drogas para criar um estímulo maior no paciente.

O Wikitionary define sinergia também com o “comportamento de um sistema que não pode ser previsto pelo comportamento de suas partes”, o que é uma definição bastante interessante e diversa do sentido necessariamente positivo que a palavra ganhou nas últimas décadas.

De fato, sinergia hoje em dia é considerada uma buzzword, uma palavra sem significado para indicar a vontade de que algum esforço conjunto qualquer resulte em mais lucro, para qualquer valor de lucro, do que um esforço individual das partes envolvidas–a palavra-chave na mudança de definição aqui sendo “vontade” versus o efeito real.

No meu trabalho com arquitetura de software, entretanto, sinergia é algo que faz sentido naturalmente no desenho de sistemas. De fato, sistemas de sistemas tender a exibir isso de uma forma quase que óbvio já que não é possível desenhar os mesmos de outra forma. Não é sem motivo que a página na Wikipedia que explica o conceito usa sinergismo, uma variação de sinergia para explicar a motivação primária desse objetivo. O Unix é um exemplo bem óbvio disso e algumas pessoas chegam a se referir a isso como o Tao do Unix pelo fato de que as peças se encaixam com tal perfeição que é impossível pensar em trabalhar de outra forma.

Sistemas de sistemas fazem sentido em praticamente qualquer situação em que a complexidade das partes individuais torne o sistema final potencialmente (e exponencialmente) difícil de ser descrito de maneira consistente.

Essa é uma das razões, inclusive, pela qual as pessoas se decepcionam tanto com frameworks como Rails ou Django quando precisam de expandir aplicações já existentes para níveis maiores de complementaridade ou escalabilidade. Frameworks fechados simplesmente não exibem esse tipo de sinergia integral necessária para garantir que os princípios aplicáveis em aplicações menores sejam os mesmos de aplicações maiores. O resultado é que, essencialmente, todos esses princípios são violados à medida que o sistema precisa crescer resultando em um entendimento completamente diferente do que se desejava a princípio. Funciona, mas sem elegância ou beleza.

A despeito do significado amortecido, uma reflexão cuidadosa sobre sinergia e sua aplicabilidade ao desenho de sistemas faria bem a qualquer desenvolvedor ou arquiteto de sistemas. Sapir-Whorf sendo fraca ou não, um entendimento real é impossível se o vocabulário natural é desprezado.

Fred Brooks sobre colaboração

October 22nd, 2009 § 2 comments § permalink

Ontem, cortesia da Caelum, tive oportunidade de ver Fred Brooks falar sobre desenvolvimento, arquitetura de sistemas e colaboração entre times.

O evento, lançamento da tradução brasileira de seu trabalho mais famoso–O Mítico Homem-Mês–contou com várias outras palestras e uma sessão de Q&A com Brooks mas, infelizmente, só pude participar dos quarenta ou cinqüenta minutos que ele passou discorrendo sobre o assunto. Mesmo assim, foi muito bom ver o velho professor–ele está com quase 80 anos atualmente–falando sobre assuntos que eram relevantes em 1975, quando o livro foi impresso pela primeira vez, e que ainda são relevantes hoje, quase 40 anos depois.

O Mítico Homem-Mês é um livro que qualquer pessoa que desenvolve ou gerencia algum processo de desenvolvimento de software deveria ler. Apesar da ironia do próprio Brooks ao dizer que seu livro é como uma Bíblia de Engenharia de Software, porque “todo mundo lê mas ninguém faz nada sobre o assunto”, o livro permanece uma influência seminal entre todos os trabalhos que foram feitos no campo nos últimos 30 anos, especialmente entre os responsáveis por grande parte das metodologias de desenvolvimento que são usadas atualmente.

Um dos pontos interessantes da palestra–e algo que que só tem um conhecimento superficial do livro não notaria–é que Brooks possui uma visão particular de desenvolvimento que vai muito contra o que se fala hoje em termos de desenvolvimento “ágil”. Um dos exemplos engraçados disso foi quando um dos participantes, ao final da palestra, perguntou o que ele pensava sobre o papel da arquitetura e design colaborativos dentro de um time ágil–um time de Scrum, digamos. Brooks declarou enfaticamente, em resposta à insistência do participante, que, sem um arquiteto-chefe, nada que fosse feito teria a consistência–a integridade conceitual, por assim dizer–necessária para o bom desenvolvimento do software.

Falando sobre colaboração, Brooks apontou o papel do trabalho solo de grandes artistas e realizadores como essencial para a criação de obras duradouras. Mesmo no contexto de colaboração, ele diz, as maiores equipes raramente passam de uma colaboração complementar entre duas pessoas. Mais do que isso resulta em difusão da integridade conceitual da obra em face a desafios maiores.

Inclusive, comparando com o modelo de colaboração de projetos de código livre ou aberto, Brooks aponta o fato de que, nesses projetos, os construtores e clientes geralmente são os mesmos e isso torna o desenvolvimento algo completamente diferente. Há integridade conceitual, sim, não do sistema como um todo mas de suas partes. Isso pode realmente ser comprovado de maneira fácil do desenvolvimento dos grandes projetos como o Linux onde uma pessoa retém a visão intelectual mais profunda do desenvolvimento e onde as partes são íntegras entre si por via de convenções–style sheets de desenvolvimento, como Brooks denomina o processo.

Em suma, a visão de Brooks é refrescante em tempos em que metodologias ágeis estão em voga em uma compreensão real do que elas representam. É bom ver alguém que pensou exaustivamente sobre o assunto–e que está pronto para lançar mais um livro sobre suas reflexões ao longo dos anos–mostrar o que realmente importa no desenvolvimento. Raros são os times e empresas que possuem maturidade para ver as coisas dessa forma.

Minha única tristeza na participação do evento foi não ter podido pedir a Brooks para autografar meu exemplar–que repousa em Belo Horizonte à espera de uma mudança futura para São Paulo.

Treetop: Implementando Brainfuck

October 1st, 2009 § 1 comment § permalink

Introdução

Continuando a série sobre Treetop, é hora de brincar um pouco mais com todos os conceitos envolvidos e implementar uma linguagem Turing-complete.

Para não complicar as coisas, vamos usar uma linguagem bem simples, que demonstre os conceitos e não fique presa em detalhes de sintaxes. Brainfuck, apesar do nome, é uma boa escolha. Extremamente minimalista–possui somente oito comandos usando oito símbolos–permite uma implementação rápida e ao mesmo tempo permite brincar com os vários conceitos que estamos vendo. Tudo bem, eu admito que ela é um Turing tarpit mas serve com uma base interessante para esse artigo.

Brainfuck consiste em oito comandos, como mencionado acima, que manipulam um espaço de células de memória. Um ponteiro de instrução é definido para a primeira instrução e os comandos manipulam esse ponteiro para executar as várias instruções. Como cada comando é um simples símbolo, a ambigüidade da gramática é nula. Qualquer outro símbolo dentro do programa é ignorado e pode ser usado como uma comentário.

Os comandos da linguagem são:

  • >, incrementa o ponteiro de dados;
  • <, decrementa o ponteiro de dados;
  • +, incrementa o byte apontado pelo ponteiro de dados;
  • -, decrementa o byte apontado pelo ponteiro de dados;
  • ., escreve o valor do byte apontado pelo ponteiro de dados;
  • ., lê um byte e armazena no endereço apontado pelo ponteiro de dados;
  • [, se o byte no endereço atual do ponteiro de dados é zero, pula para frente até o próximo comando ];
  • ], se o byte no endereço atual do ponteiro de dados não é zero, pula para trás até o próximo comando [.

Reconhecendo a linguagem

Vamos olhar então como ficaria a gramática da linguagem:

grammar Brainfuck

  rule program
    instruction*
  end
  
  rule instruction
    loop / 
    simple /
    comment
  end
  
  rule loop
    '[' instructions:instruction* ']'
  end
  
  rule simple
    '>' /
    '<' /
    '+' /
    '-' /
    ',' / 
    '.'
  end
  
  rule comment
    [^\[\]><+-,.]
  end
  
end

A descrição da gramática é simples:

  • Um programa é uma série de zero ou mais instruções;
  • Uma instruções pode ser composta--ou seja, um loop, denotado pelos comandos [ e ]--, uma instrução simples, ou um comentário (que é qualquer caractere que não seja uma instrução);
  • Dentro de um loop, podem existir zero ou mais instruções.

Podemos ver que a gramática funciona executando comandos como abaixo:

>> require "rubygems"
=> false
>> require "treetop"
=> true
>> require "brainfuck"
=> true
>> p = BrainfuckParser.new
=> #
>> p.parse("><+-[]")
=> SyntaxNode offset=0, "><+-[]":
  SyntaxNode offset=0, ">"
  SyntaxNode offset=1, "<"
  SyntaxNode offset=2, "+"
  SyntaxNode offset=3, "-"
  SyntaxNode+Loop0 offset=4, "[]":
    SyntaxNode offset=4, "["
    SyntaxNode offset=5, ""
    SyntaxNode offset=5, "]"

Note que os comentários também são marcados por nós sintáticos, já que estamos processando os mesmos. Obviamente, quando da interpretação do programa, precisaremos eliminá-los.

Criando uma árvore sintática

A partir da gramática, o nosso objetivo é criar uma árvore manipulável, eliminando comentários, agrupando instruções de loop e preparando um ambiente para a execução em si.

Podemos usar a mesma técnica que usamos nos artigos anteriores.

Primeiro, definimos uma representação sintática. O arquivo brainfuck_ast.rb ficaria assim inicialmente:

class Program
  
  attr_reader :instructions
  
  def initialize(instructions)
    @instructions = instructions
  end
  
end

class Instruction
  
  attr_reader :command
  
  def initialize(command)
    @command = command
  end
  
end

class Loop
  
  attr_reader :instructions
  
  def initialize(instructions)
    @instructions = instructions
  end
  
end

Efetivamente, precisamos somente de três tipos de nós: o programa em si, para servir como um container inicial do ambiente, instruções simples e loops.

A seguir precisamos reconhecer isso em nossa gramática. Mostrando a gramática adaptada em um único passo, teríamos algo assim:

grammar Brainfuck

  rule program
    instruction* <ProgramPredicate>
  end
  
  rule instruction
    loop / 
    simple /
    comment
  end
  
  rule loop
    '[' instructions:instruction* ']' <LoopPredicate>
  end
  
  rule simple
    '>' <InstructionPredicate> /
    '<' <InstructionPredicate> /
    '+' <InstructionPredicate> /
    '-' <InstructionPredicate> /
    ',' <InstructionPredicate> / 
    '.' <InstructionPredicate>
  end
  
  rule comment
    [^\[\]><+-,.] <CommentPredicate>
  end
  
end

E finalmente, o arquivo contendo as extensões, brainfuck_ext.rb, ficaria assim:

module Common
  
  def build_elements(elements)
    elements.
      select { |element| element.respond_to?(:build) }.
      collect { |element| element.build }
  end
  
end

module ProgramPredicate
  
  include Common
  
  def build
    Program.new(build_elements(elements))
  end
  
end

module LoopPredicate
  
  include Common
  
  def build
    Loop.new(build_elements(instructions.elements))
  end
  
end

module InstructionPredicate
  
  def build
    Instruction.new(text_value)
  end
  
end

module CommentPredicate
  
end

No código acima, primeiro definimos um módulo comum que pode ser incluído em outros e possui um método que seleciona instruções que podem ser utilizadas. Depois definimos módulos para o que precisamos processar. E finalmente ignoramos os comentários.

Interpretando

Agora precisamos converter o código acima em um interpretador. A implementação é trivial e vamos acompanhá-la passo a passo, escrevendo o arquivo brainfuck_int.rb, que conterá o interpretador:

class BrainfuckInterpreter
  
  def initialize(commands)
    @ast = BrainfuckParser.new.parse(commands).build
  end
    
end

Esse método inicializa o interpretador recebendo uma série de comandos na forma de uma string e construindo uma árvore sintática final da mesma.

O próximo passo é começar a execução em si. Um interpretador Brainfuck deve inicialmente alocar um espaço de memória para execução e inicializar o ponteiro de instruções. Em seguida, deve seguir de instrução em instrução, rodando o comando em questão. O método que faz isso é o seguinte:

class BrainfuckInterpreter
  
  def initialize(commands)
    @ast = BrainfuckParser.new.parse(commands).build
  end
    
  def execute
    @addresses = [0] * 3000
    @pointer = 0
    execute_ast_node(@ast)
  end
    
end

Esse método inicializa o espaço de instruções e o ponteiro e em seguida chama a execução de um nó da árvore. Embora esse nó sempre seja um nó do tipo Program, o método está preparado para executar qualquer instrução.

Na seqüência, está a implementação do método execute_ast_node:

class BrainfuckInterpreter
  
  def initialize(commands)
    @ast = BrainfuckParser.new.parse(commands).build
  end
    
  def execute
    @addresses = [0] * 3000
    @pointer = 0
    execute_ast_node(@ast)
  end
  
  protected
  
  def execute_ast_node(ast)
    send("execute_" + ast.class.name.downcase, ast)
  end
    
end

O método é simplesmente um dispatch para o método apropriado para lidar com o tipo de nó em si.

O nó program é o que possui a implementação mais simples. Com o mesmo representa somente uma lista de instruções, a execução consiste em nada mais do que rodar essa lista, pedindo a execução de cada nó filho. A implementação fica, então, como mostrado abaixo:

class BrainfuckInterpreter
  
  def initialize(commands)
    @ast = BrainfuckParser.new.parse(commands).build
  end
    
  def execute
    @addresses = [0] * 3000
    @pointer = 0
    execute_ast_node(@ast)
  end
  
  protected
  
  def execute_ast_node(ast)
    send("execute_" + ast.class.name.downcase, ast)
  end
  
  def execute_program(ast)
    ast.instructions.each { |instruction| execute_ast_node(instruction) }
  end
    
end

A implementação dos nós instruction é igualmente simples:

class BrainfuckInterpreter
  
  def initialize(commands)
    @ast = BrainfuckParser.new.parse(commands).build
  end
    
  def execute
    @addresses = [0] * 3000
    @pointer = 0
    execute_ast_node(@ast)
  end
  
  protected
  
  def execute_ast_node(ast)
    send("execute_" + ast.class.name.downcase, ast)
  end
  
  def execute_program(ast)
    ast.instructions.each { |instruction| execute_ast_node(instruction) }
  end
  
  def execute_instruction(ast)
    case ast.command
    when '>'
      @pointer += 1
    when '<'
      @pointer -= 1      
    when '+'
      @addresses[@pointer] += 1
    when '-'
      @addresses[@pointer] -= 1      
    when ','
      @addresses[@pointer] = STDIN.getc
    when '.'
      STDOUT.print @addresses[@pointer].chr
    end
  end
    
end

Para cada instrução, executamos a instrução correspondente. As duas primeiras simplesmente movem o ponteiro de instrução--não estamos aqui, executando qualquer tipo de testes para evitar instruções inválidas. A duas instruções seguintes não movem o ponteiro de dados e simplesmente manipulam o dado que está no endereço especificado. Finalmente, as demais instruções lêem um byte da entrada padrão para o endereço atual ou emitem o byte atual para a saída padrão.

Finalmente, temos a implementação de um loop que também é trivial:

class BrainfuckInterpreter
  
  def initialize(commands)
    @ast = BrainfuckParser.new.parse(commands).build
  end
    
  def execute
    @addresses = [0] * 3000
    @pointer = 0
    execute_ast_node(@ast)
  end
  
  protected
  
  def execute_ast_node(ast)
    send("execute_" + ast.class.name.downcase, ast)
  end
  
  def execute_program(ast)
    ast.instructions.each { |instruction| execute_ast_node(instruction) }
  end
  
  def execute_instruction(ast)
    case ast.command
    when '>'
      @pointer += 1
    when '<'
      @pointer -= 1      
    when '+'
      @addresses[@pointer] += 1
    when '-'
      @addresses[@pointer] -= 1      
    when ','
      @addresses[@pointer] = STDIN.getc
    when '.'
      STDOUT.print @addresses[@pointer].chr
    end
  end
  
  def execute_loop(ast)
    while @addresses[@pointer] != 0
      ast.instructions.each { |instruction| execute_ast_node(instruction) }
    end
  end
  
    
end

A implementação simplesmente verifica se o endereço atual contém um valor nulo e caso contrário continua a execução das instruções aninhadas. Isso é o mesmo que pular para frente a para trás nos operadores [ e ].

Para completar o quadro e facilitar a execução, podemos incluir métodos auxiliares:

class BrainfuckInterpreter
  
  def initialize(commands)
    @ast = BrainfuckParser.new.parse(commands).build
  end
    
  def execute
    @addresses = [0] * 3000
    @pointer = 0
    execute_ast_node(@ast)
  end
  
  def self.run(commands)
    BrainfuckInterpreter.new(commands).execute
  end

  def self.run_file(file)
    BrainfuckInterpreter.new(File.readlines(file).join).execute
  end
  
  
  protected
  
  def execute_ast_node(ast)
    send("execute_" + ast.class.name.downcase, ast)
  end
  
  def execute_program(ast)
    ast.instructions.each { |instruction| execute_ast_node(instruction) }
  end
  
  def execute_instruction(ast)
    case ast.command
    when '>'
      @pointer += 1
    when '<'
      @pointer -= 1      
    when '+'
      @addresses[@pointer] += 1
    when '-'
      @addresses[@pointer] -= 1      
    when ','
      @addresses[@pointer] = STDIN.getc
    when '.'
      STDOUT.print @addresses[@pointer].chr
    end
  end
  
  def execute_loop(ast)
    while @addresses[@pointer] != 0
      ast.instructions.each { |instruction| execute_ast_node(instruction) }
    end
  end
    
end

E com isso, podemos testar um programa. Abra um novo arquivo chamado brainfuck_test.rb e introduza o seguinte código:

require "rubygems"
require "treetop"
require "brainfuck"
require "brainfuckext"
require "brainfuckast"
require "brainfuck_int"

code = <<-EOF +++ +++ +++ + initialize counter (cell #0) to 10 [ use loop to set the next four cells to 70/100/30/10 > +++ +++ + add 7 to cell #1 > +++ +++ +++ + add 10 to cell #2 > +++ add 3 to cell #3 > + add 1 to cell #4 <<< < - decrement counter (cell #0) ]
>++ . print 'H' >+. print 'e' +++ +++ +. print 'l' . print 'l' +++ . print 'o' >++ . print ' ' <<+ +++ +++ +++ +++ ++. print 'W' >. print 'o' +++ . print 'r' --- --- . print 'l' --- --- --. print 'd' >+. print '!' >. print '\n' EOF

BrainfuckInterpreter.run(code)

O código está "comentado" (lembre-se que comandos não reconhecidos são ignorados). Se você rodar o programa agora, obterá o resultado desejado:

~$ ruby brainfuck_test.rb 
Hello World!

Pronto! Você agora possui um interpretador funcional--embora seriamente lento e incrivelmente complexo de se programar--de uma linguagem computacionalmente completa, capaz de realizar qualquer tarefa que você deseje executar.

Um outro teste interessante é rodar o código que imprime a canção 99 bottles of beer on the wall, cuja versão em Brainfuck é um pesadelo. Você verá que, embora lento, o código consegue imprimir as linhas com relativa facilidade.

Comparando a velocidade de uma versão Ruby e uma versão Brainfuck da canção temos os resultados (Ruby 1.9; iMac 2.8Ghz recente rodando Snow Leopard):

~$ time 99.bf
  real  0m0.679s
  user  0m0.586s
  sys   0m0.045s
  
~$ time 99.rb
  real  0m0.016s
  user  0m0.006s
  sys   0m0.006s

Digamos que imprimir caracteres um a um não é uma forma eficiente de se trabalhar. Obviamente, double dispatching também não é uma técnica boa em todos os casos e vai adicionar um certo overhead em troca de flexibilidade. Mas, mesmo removendo o tempo de carga do Ruby, não haveria tantas melhoras no programa.

Conclusão

Como esse artigo vimos como fazer a cadeia completa de implementação, incluindo a implementação de um interpretador funcional. Mesmo que a implementação seja bem simples, as lições são as mesmas para qualquer outra linguagem e o limite está mais na sintaxe e semântica do que nas técnicas em si. Um exercício para o leitor é implementar um otimizador para Brainfuck que agrupe instruções iguais e efetue as operações em uma única passagem. Aqui, é claro, cabe uma aviso: implementações de linguagens generalizadas de programação obviamente precisam de muito mais do que isso para funcionar bem. O Treetop oferece uma conveniência quando velocidade máxima de execução não é o desejado e sim velocidade de implementação.

Com isso encerramos essa série sobre Treetop. Eventualmente, é possível que eu escreva um artigo sobre a implementação de uma linguagem menos minimalista, mas no momento não há tempo para isso. Espero que o tempo gasto lendo esses artigos tenha sido proveitoso.

Nota: Para ver a série completa, siga a categoria Treetop deste blog.

Treetop: Depuração

September 30th, 2009 § 0 comments § permalink

Introdução

Continuando a série sobre Treetop, o objetivo desse artigo é falar um pouco sobre a depuração de gramáticas. Muitas vezes, o mecanismo de verificação do que a gramática está esperando, ilustrado no primeiro artigo, não é suficiente para identificar porque um reconhecimento está faltando–especialmente quando a gramática se torna mais complexa.

Parte da depuração consiste, na verdade, em tentar evitar erros mais primários. Outra parte consiste em usar alguns mecanismos para identificar problemas quando os erros primários já foram removidos. Falaremos de cada um deles na seqüência.

Evitando erros comuns

Um detalhe que deixei de fora no primeiro artigo é que uma PEG representa um parser descendente recursivo. E uma das fraquezas desse tipo de parser é que eles não são capazes de lidar com recursividade à esquerda.

Por exemplo, veja a regra abaixo:

string-of-a := string-of-a 'a' | 'a'

A lógica dita que isso deveria reconhecer uma seqüência de caracteres “a”. Na prática, isso não acontecer porque a regra está escrita de tal forma que para reconhecer a produção “string-of-a” seria necessário reconhecer “string-of-a” em seguida, o que leva, necessariamente, a recursividade infinita.

Existem packrat parsers que são capazes de lidar com isso mas não é o caso do Treetop. Existem técnicas formais para lidar com isso mas geralmente a melhor opção é criar uma regra que faça o processamento indireto do que se precisar e, com alguma criatividade, reescrever o necessário em uma fase posterior.

Para ilustrar ainda mais o ponto, veja a gramática abaixo que é uma variação da que estamos usando.

value := [0-9]+ / '(' expression ')'
product := expression (('*' / '/') expression)*
sum := expression (('+' / '-') expression)*
expression := product / sum / value

O problema com esse é que para saber o que é uma expressão, precisamos saber o que é um produto. Mas, para saber um produto, precisamos também saber o que é uma expressão.

A solução é simples:

expression := sum
sum := product (('+' / '-')) product)*
product := value (('*' / '/')) value)*
value := number / '(' expression ')'
number := [0-9]+

Um segundo ponto é utilizar apropriadamente operadores de lookahead para ajudar a remover ambigüidades da gramática. O uso dos mesmos é especialmente necessário por conta do modo como o operador de escolha ordenada trabalha. Como a segunda opção somente é considerada caso a primeira falhe, algumas vezes é necessário especificar cenários de falha na primeira para forçar a segunda a acontecer.

Suponha, por exemplo, que você tenha a seguinte gramática:

expression := numeric_expression / string_expression
numeric_expression := identifier ('+' identifier)*
string_expression := identifier ('||' identifier)*
identifier := [a-z]+

O problema dessa gramática é que a regra string_expression jamais será reconhecida. O que acontece é que para tentar descobrir se uma expressão é numérica, o parser precisa encontrar um identificador. Quando isso acontece, como a regra numeric_expression já possui um reconhecimento parcial, o parser tenta então encontrar o terminal +. Se isso não acontece–porque há um terminal ||–o parser aborta por não ter como seguir naquela regra.

Uma solução simples para resolver a ambigüidade é olhar para a frente e somente dizer que algo é uma expressão numérica se o identificador não for seguido por um operador que atue sobre strings. A gramática ficaria assim então:

expression := numeric_expression / string_expression
numeric_expression := identifier !'||' ('+' identifier)*
string_expression := identifier ('||' identifier)*
identifier := [a-z]+

Na maioria dos casos, isso é tudo o que você precisa para resolver a situação. Uma outra alternativa, é claro, é condensar as duas expressões, já que elas são essencialmente equivalentes, e fazer a diferenciação semântica em uma fase posterior (na análise semântica, mais ao ponto).

Um terceiro ponto é saber distinguir bem os separadores necessários para reconhecimento dos terminais. Em muitos casos, o modo mais simples é ideal. Algumas vezes, entretanto, é preciso usar alguma sofisticação. Para ilustrar, usando um exemplo da própria documentação do Treetop, teríamos algo como:

rule end_keyword
  'end' ![a-zA-Z0-9_]
end

Essa regra reconhece uma palavra chave end em uma linguagem em que palavras chaves podem ser seguidas por pontuação qualquer mas não por caracteres alfanuméricos.

Representações gráficas

Em muitos casos, é interessante visualizar o que o Treetop está reconhecendo. Para isso, uma característica interessante do mesmo adicionada em versões recentes é a habilidade de gerar um arquivo para o Graphviz. O uso é bem simples.

>> require "treetop"
=> true
>> require "simple_math"
=> true
>> p = SimpleMathParser.new
=> #
>> p.parse("1+2*3-(4/5)").write_dot_file("results")
=> nil

O resultado é um arquivo results.dot que pode ser processado em uma imagem como no exemplo abaixo:

~$ dot -Tpng results.dot > results.png

A imagem final ficaria assim:

Parsing 1+2*3-(4/5)

Essa é uma maneira fácil de ver como o Treetop reconhecer a sintaxe de maneira mais básica.

Capturando a execução

Uma última forma de capturar o resultado da execução é interceptar as chamadas do parser gerado pelo Treetop. Essa é a forma menos confiável porque depende do conhecimento da estrutura interna do Treetop, que pode mudar a qualquer momento. Apesar disso, mesmo com adaptações necessárias de quando em quando, é uma boa forma de saber o que o Treetop está fazendo por trás das cenas.

A primeira coisa a fazer é gerar o arquivo do parser em si:

~$ tt simple_math.rb

Isso gera o parser em sua forma final, ao invés de compilá-lo cada vez que o require é feito.

A partir disso, é possível construir sobre os módulos que o Treetop gerou. Existe um módulo default com o nome que foi dado a gramática–no nosso caso, esse módulo é o SimpleMath. Em um arquivo simplemathdebug.rb, poderíamos ter o seguinte código:

require "treetop"
require "simple_math"

module SimpleMath
  
  def __depth
    @__depth ||= 0
  end
  
  def __inc_depth
    @__depth = __depth + 1
  end

  def __dec_depth
    @__depth = __depth - 1
  end
  
end

SimpleMath.instance_methods.each do |method|
  
  next unless method =~ /^_nt_(.*)$/
  
  rule = $1
  
  SimpleMath.send(:alias_method, ("_old" + method).to_sym, method.to_sym)
  
  SimpleMath.send(:define_method, method.to_sym) do
    puts (" " * __depth) + rule
    __inc_depth
    result = send("_old" + method)
    __dec_depth
    result
  end  
  
end

O que o código acima faz é interceptar as chamadas aos métodos que começam com _nt_, que são os métodos que efetivamente implementam o reconhecimento de produções e rastrear a profundidade em que estão sendo chamados para exibir a ordem em que as mesmas foram feitos.

Veja um exemplo de chamada:

>> require "simple_math_debug"
=> true
>> p = SimpleMathParser.new
=> #
>> p.parse("1+2*3")
expression
 term
  factor
   number
  factor
 expression
  term
   factor
    number
   term
    factor
     number
    factor
  term
=> SyntaxNode+Expression0 offset=0, "1+2*3" (expression,term):
  SyntaxNode offset=0, "1":
    SyntaxNode offset=0, "1"
  SyntaxNode offset=1, "+"
  SyntaxNode+Term0 offset=2, "2*3" (factor,term):
    SyntaxNode offset=2, "2":
      SyntaxNode offset=2, "2"
    SyntaxNode offset=3, "*"
    SyntaxNode offset=4, "3":
      SyntaxNode offset=4, "3"
>> p.parse("1+")
expression
 term
  factor
   number
  factor
 expression
  term
   factor
    number
   factor
  term
 term

Essa é uma maneira simples de saber o que está acontecendo e de ver se há falhas no reconhecimento específico de alguma regra. Como algumas regras podem ser bem complexas em sua implementação, esse tipo de estratégia permite uma visualização das entradas e saídas dos métodos.

Conclusão

Embora o Treetop seja relativamente simples em sua implementação, em alguns momentos é preciso quebrar a abstração e olhar o que está sob o código externalizado. As técnicas acima podem ajudar a resolver problemas comuns que vão surgir durante a implementação de uma linguagem qualquer.

No próximo artigo, um bônus: uma linguagem Turing-complete implementada usando o Treetop para análise sintática.

Nota: Para seguir a série completa, siga a categoria Treetop deste blog.

Where Am I?

You are currently browsing entries tagged with Tecnologia at Superfície Reflexiva.