Thiago B. Negri

A primeira impressão é a que fica

2014-11-01T14:01:00.003-02:00

O velho ditado "a primeira impressão é a que fica" tem base científica.

Bruner e Potter (1964) realizaram um experimento simples com 89 pessoas: cada pessoa via uma imagem com qualidade indo de borrada até levemente desfocada. Ao final a pessoa tinha que tentar acertar o que era aquela imagem.

Foram formados nove grupos. Todos os grupos viram a mesma imagem final, o que mudava de um grupo para o outro era a qualidade inicial da imagem e o tempo de exposição. Quanto pior era a qualidade inicial, pior era a taxa de acerto do grupo.

A tabela acima indica a taxa de acerto de cada grupo, o grupo VB-FQ é o que recebeu a pior imagem inicial, MB-FQ o que recebeu uma imagem de qualidade média inicialmente e as pessoas que receberam a imagem com melhor qualidade inicialmente estão no grupo LB-FQ.

A diferença na taxa de acerto é gigante: o grupo que não viu a imagem ruim inicialmente acertou 72,9% das respostas, enquanto que o grupo que viu a imagem ruim acertou apenas 25%.

Uma hipótese pode ser o excesso de informação que levava o grupo a teorizar mais e por consequência errar mais. Para verificar isso fizeram mais uma rodada de maneira inversa: pessoas viram a imagem indo de levemente desfocada para borrada. Esse grupo não teve sua taxa de acerto prejudicada.

A explicação encontrada foi que independente da qualidade inicial da imagem, todas as pessoas, naturalmente, tentavam reconhecer o que estava ali. Era difícil as pessoas se desfazerem dessa impressão inicial, elas buscavam apenas confirmações de que a ideia original estava certa.

Temos a tendência de nos agarrar à uma ideia ou julgamento inicial sobre qualquer assunto. Desfazer essa ideia inicial é afirmar que estávamos errados, e isso parece ser difícil, mesmo que seja inconsciente.

O relatório publicado é curto, tem apenas uma página indicando como o experimento foi realizado e quais resultados foram obtidos. Está disponível aqui para quem quiser ler (em inglês): http://cvcl.mit.edu/SUNSeminar/brunerpotter1964.pdf

Somos todos porcos

2014-10-28T20:28:00.000-02:00

Acabei de ver a seguinte imagem compartilhada no Facebook:

Essa frase parece meio clichê e argumento de revoltadinho, mas não é.

Façamos um exercício mental sobre o ponto de vista do porco: ele vive em um local confinado e nunca teve contato com porcos livres. Tudo o que conhece e presencia todos os dias é que um ser humano vem alimentá-lo.

No começo o porco até pode ficar assustado e desconfiado do ser humano. Sem saber do motivo real por trás da alimentação, a confiança entre o porco e o ser humano aumenta a cada dia. Pois todo o conhecimento empírico dele indica que o ser humano é confiável.

Se desenhássemos um gráfico indicando o nível de confiança do porco para com o ser humano, ele estaria assim:

Neste exato ponto no tempo, não importa quão sofisticado seja o modelo matemático utilizado pelo porco, todos os indicadores numéricos indicarão que o ser humano é confiável. Logo, o porco votaria no ser humano para representá-lo, pois seria irracional dizer que o ser humano está mal-intencionado.

Até o momento em que o ser humano leva o porco para ser abatido. Neste momento o porco perde toda a confiança que ele havia construído para com o ser humano.

Infelizmente, para o porco já é tarde de mais.

Esta mudança repentina na linha de tendência é óbvia para nós, seres humanos que conhecemos o processo envolvido na criação do porco. Porém, este evento para o porco é conhecido como um "cisne negro": um evento imprevisto de alto impacto.

Ora, a imprevisibilidade depende do ponto de vista: o evento só é imprevisível para o porco, não para o ser humano. Tudo o que muda de um observador para o outro é o nível de informação sobre o processo envolvido: se o porco, mesmo sendo porco, tivesse a informação necessária, ele seria capaz de prever este evento e teria tentado se proteger de alguma forma.

A única forma de prevenção deste tipo de evento é o conhecimento. Portanto, tomemos cuidado com a mão que nos alimenta.

Leve este exercício mental para o cenário da política brasileira neste momento. Pare de acreditar que seu partido político é seu time de futebol, você não precisa mostrar para ninguém que seu partido é melhor ou menos pior do que outro. Ajuda a gerar informações que previnam os cisnes negros, independente do partido ou do político envolvido. É desta forma que ajudaremos a defender nossos vizinhos e a nós mesmos, não esqueça que todo mundo pode estar errado: tanto você quanto sua oposição.

Quer conhecer mais sobre cisnes negros? Recomendo a leitura do livro do Nassim Nicholas Taleb: The Black Swan, ou em português: A Lógica do Cisne Negro.

Unity3D, Bejeweled e Domain-driven design

2014-07-29T14:59:00.001-03:00

Estou trabalhando em um novo jogo ao estilo de Bejeweled. Estou feliz com a liberdade de organização do código que a engine Unity3D está permitindo. Nos meus primeiros contatos com a engine, achei que muita coisa teria que ser feita orientada à classe MonoBehaviour, mas isto não é verdade. Essa classe é necessária apenas como um ponto de cola entre qualquer código C# e os objetos da engine. Abaixo relato como comecei a codificação deste jogo e as mudanças que fiz na modelagem, antes disso deixo um vídeo de demonstração do estado atual do jogo:

Iniciei a construção criando um GameObject para cada entidade que identifiquei na mecânica do jogo:

Tabuleiro
Peça

O tabuleiro contém todas as peças associadas e é responsável por elas:

public class Board : MonoBehaviour {
  private GameObject[,] pieces;
  void Awake() {
    pieces = /* Initialize pieces */;
  }
}

O tipo da peça é definido por um MonoBehaviour associado que expõe uma enumeração para escolha:

public class Piece : MonoBehaviour {
  public PieceType Type;
}
public enum PieceType {
  Circle,
  Square,
  Star,
  Triangle,
  Hexagon,
  Polygon
}

Depois dessa definição das entidades que participam do jogo, comecei a codificar a lógica dentro dessas classes já existentes. Funcionou até certo ponto, mas alguns problemas começaram a surgir quando eu decidia colocar mais alguma funcionalidade. As classes se responsabilizavam por muitas atividades (e.g. respeitar as regras, cuidar de cada animação, tratar a entrada do usuário) e isto tornava difícil a codificação de algumas coisas, pois eu sempre tinha que manter tudo isso em meu mapa mental para evitar quebrar alguma coisa. Além disso, durante as animações o tabuleiro em memória as vezes ficava em um estado inconsistente, esperando o término de alguma animação para então criar uma outra peça. Este comportamento também contribuía com a dificuldade de manutenção deste modelo.

Já havia lido algumas coisas sobre Domain-driven design (DDD) e resolvi aplicar um pouco disto na construção deste jogo. O primeiro passo foi separar o meu core domain do restante, entendi que a mecânica do jogo é o domínio principal: se esta mecânica não estiver bem resolvida e a manutenção ou criação de novas funcionalidades neste domínio for difícil, estarei ferrado. Então fui criar classes deste domínio completamente separadas de qualquer outro conhecimento necessário para fazer o jogo funcionar, ignorei a existência da Unity3D neste momento.

Só visualizei uma entidade para este meu domínio: o tabuleiro. Não faz sentido a peça existir por si só, tudo que envolve peças sempre acontece dentro de um tabuleiro. Apesar de eu ainda ter uma classe separada para representar a peça e seu tipo, elas possuem um papel interno e só são acessadas através do tabuleiro. Minha modelagem ficou neste formato:

public class BoardPosition {
  public readonly int Row;
  public readonly int Column;
  public BoardPosition(int row, int column) {
    Row = row;
    Column = column;
  }
}

public class Board {
  private Piece[,] pieces;
  public Board() {
    pieces = /* Initialize pieces */;
  }

#region Queries
  public Piece PieceAt(BoardPosition p) { /* ... */ }
#endregion

#region Events
  public delegate void PieceCreatedDelegate(BoardPosition position, Piece piece);
  public event PieceCreatedDelegate PieceCreated;

  public delegate void PieceDestroyedDelegate(BoardPosition position);
  public event PieceDestroyedDelegate PieceDestroyed;

  public delegate void PieceMovedDelegate(BoardPosition from, BoardPosition to);
  public event PieceMovedDelegate PieceMoved;

  public delegate void PiecesSwappedDelegate(BoardPosition a, BoardPosition b);
  public event PiecesSwappedDelegate PiecesSwapped;
#endregion

#region Commands
  public void SwapPieces(BoardPosition a, BoardPosition b) {
    ...; // Swap pieces
    PiecesSwapped(a, b);
  }

  public void StepGameState() {
    ...; // Destroy pieces
    ...; // Move pieces
    ...; // Create pieces

    for (...) {
      PieceDestroyed(...);
    }
    for (...) {
      PieceMoved(...);
    }
    for (...) {
      PieceCreated(...);
    }
  }
#endregion
}

Desta forma, as classes responsáveis por apresentar o jogo de forma visual se registram para os eventos gerados pelo tabuleiro e atualizam a interface conforme necessidade.

public class BoardView : MonoBehaviour {
  private Board board;
  private GameObject[,] pieces;
  void Awake() {
    board = new Board();
    board.PieceCreated += HandlePieceCreated;
    board.PieceDestroyed += HandlePieceDestroyed;
    board.PieceMoved += HandlePieceMoved;
    board.PiecesSwapped += HandlePiecesSwapped;
    pieces = /* Initialize pieces based on 'board' */;
  }

  public void HandlePieceCreated(BoardPosition position, Piece piece) { /* ... */ }
  public void HandlePieceDestroyed(BoardPosition position) { /* ... */ }
  public void HandlePieceMoved(BoardPosition from, BoardPosition to) { /* ... */ }
  public void HandlePiecesSwapped(BoardPosition a, BoardPosition b) { /* ... */ }

  void Update() {
    board.Step();
    if (/* ... */) {
      board.SwapPieces(a, b);
    }
  }
}

O que senti de dificuldade neste formato foi sincronizar o modelo com a representação gráfica. Como o próprio modelo notifica seus interessados, sobra pouco espaço para o cliente decidir quando tratar cada evento. No meu caso, alguns eventos geram animações que precisam segurar outros eventos de acontecer, i.e. existe um sequenciamento temporal entre alguns eventos.

Decidi então alterar meu modelo para informar os eventos que ocorreram em cada comando executado ao invés de já causar a execução do código do listener:

#region Events
public interface BoardEvent {}
public class PieceCreated : BoardEvent { /* ... */ }
public class PieceDestroyed : BoardEvent { /* ... */ }
public class PieceMoved : BoardEvent { /* ... */ }
public class PiecesSwapped : BoardEvent { /* ... */ }
#endregion

#region Commands
public List<BoardEvent> SwapPieces(BoardPosition a, BoardPosition b) { /* ... */ }
public List<BoardEvent> StepGameState() { /* ... */ }
#endregion

Tudo o que mudou é que agora a interface precisa chamar os handlers sozinha e decidir quando tratar cada evento:

public class BoardView : MonoBehaviour {
  private List<BoardEvent> events;
  void Update() {
    if (events.Count < 1) { events = board.StepGameState(); }
    foreach (BoardEvent e in events) {
      if (CanHandleNow(e)) {
        Handle(e);
      }
    }
    // ...
    if (HandledEverything) { events.Clear(); }
  }
}

Ainda assim, o conceito de sequenciamento temporal não estava muito claro. Parecia que ele estava "flutuando no ar" e precisava ser fixado. Entendi que isto faz parte do domínio do meu problema e cada evento passou a ter um identificador de sequenciamento no tempo, cada BoardEvent tem um public int When() que informa o momento sequencial do tempo em que ele ocorreu.

public class Board {
  private int timeCounter;
  public List<BoardEvent> StepGameState() {
    ...; // Destroy pieces
    for (...) {
      events.add(new PieceDestroyed(timeCounter, ...));
    }
    if (eventHappened) { timeCounter++; }

    ...; // Move pieces
    for (...) {
      events.add(new PieceMoved(timeCounter, ...));
    }
    if (eventHappened) { timeCounter++; }

    ...; // Create pieces
    for (...) {
      events.add(new PieceCreated(timeCounter, ...));
    }
    if (eventHappened) { timeCounter++; }

    return events;
  }
}

public class BoardView : MonoBehaviour {
  private int timeCounter;
  private List<BoardEvent> events;
  void Update() {
    if (events.Count < 1) { events = board.StepGameState(); }
    foreach (BoardEvent e in events) {
      if (e.When() == timeCounter) Handle(e);
      if (e.When() > timeCounter) {
        stillHasEventsToHandle = true;
        break;
      }
    }
    if (/*handledAnimationOfAllEventsOfMyTimeCounter*/) { 
      // Advance time perception of view
      timeCounter++;
    }
    if (!stillHasEventsToHandle) {
      events.Clear(); // Will step game state at next frame
    }
  }
}

Desta forma, tanto o modelo quanto a representação gráfica possuem um contador temporal e a própria representação se responsabiliza por sincronizar o tempo percebido pelo usuário da interface com o tempo percebido pelo modelo.

Até então o código está mais ou menos como foi listado acima, este modelo está atendendo bem até então. Ainda me sinto mal com um ponto: os commands do modelo sempre mantém o tabuleiro todo cheio, sem estados pela metade, porém o método de step faz no máximo uma iteração de eventos e checagem de colisões no tabuleiro, porém podem ocorrer novas colisões depois de mover e criar as peças. Apesar do tabuleiro nunca estar inconsistente, pode ser que sejam necessárias várias execuções de StepGameState até que o tabuleiro fique em um estado consolidado, sem nada a ser feito e aguardando entrada do usuário. Não queria fazer várias iterações em uma única chamada do step para não ter perigos de entupir a memória do jogo com eventos antes deles começarem a ser tratados pela interface. Nestas horas sinto falta da avaliação lazy do Haskell.

Ainda tenho alguns itens para adicionar nesta mecânica de jogo. Verei quais os problemas deste formato nos próximos dias e postarei novidades com as próximas mudanças. Sugestões também são bem vindas.

Turtlerise

2014-05-01T20:54:00.001-03:00

Olá, povo! É com grande orgulho que lanço minha segunda aplicação na Play Store.

Desta vez é um jogo para todos: Turtlerise.

O jogo tem uma mecânica simples: você precisa fazer com que uma tartaruga suba, quanto mais alto ela for, mais pontos você fará. Para fazê-la subir, você posiciona pedras para ela rebater. Alguns outros elementos fazem parte do jogo para deixá-lo mais interessante.

O gameplay é rápido e é para representar um desafio para os jogadores, fazer pontos não é tão fácil quanto parece!

O jogo está integrado ao Facebook, então é possível acompanhar um placar entre você e seus amigos para ver quem chega mais alto.

Links

Jogo na Play Store: https://play.google.com/store/apps/details?id=com.turtlecorp.turtlerise
Página do jogo no Facebook: https://www.facebook.com/turtlerise

Terceiro e ultimo dia de QConSP 2014

2014-04-14T22:16:00.000-03:00

Este post demorou um pouco para sair porque no ultimo dia do QCon meu notebook ficou sem bateria e o hotel não tinha nenhuma tomada no padrão novo, pode isso? Até tentei escrever o texto no aplicativo do Blogger no celular, mas acabei desistindo depois de perder o texto duas vezes. O dia logo após o término do QCon foi consumido pela viagem de volta para casa e uma confraternização; o dia subsequente foi consumido por um passeio turístico em outra cidade. Mas, finalmente estou em casa e, mesmo cansado, escrevo este post para nossa alegria.

O terceiro e ultimo dia do QConSP 2014 começou com a apresentação Introduction to Hadoop. Achei bem estranho uma keynote com "Introduction" no título. Acredito que ficou como keynote apenas por causa do palestrante: Todd Lipcon, um membro-fundador do Hadoop. Achei uma apresentação bem introdutória e não motivadora, logo não mereceria destaque como uma keynote. Na mesma lógica, não terá destaque neste post, até porque não tem muito o que falar mesmo. A parte memorável foi ver ele tentando fazer um notebook com Ubuntu e uma espécie de Fluxbox funcionar para projetar a apresentação. Deu dó. Depois de uns cinco minutos se batendo com a resolução, ele abriu uma máquina virtual com Windows XP para abrir a apresentação PPTX dele. Ha-ha. Mas daí a resolução não encaixou e ele se rendeu à utilizar um Macbook de um organizador.

Design-Driven Development & Context-Driven Experience

A segunda keynote do dia foi de um designer que trabalha na Prezi. Mostrou um pouco de história e do processo de desenvolvimento interno: iterativo e incremental. Parece que todo mundo reforça o modelo "fail fast, iterate".

Trouxe a tona um fato interessante: muita gente no evento estava usando Pebble Smartwatch e que as próximas tecnologias dominantes serão "vestíveis". Curiosamente isto combinou com um artigo que li no mesmo dia afirmando que o fundador do Evernote disse que "Apps Will Soon Be Obsolete".

O apresentador falou que é necessário pensar em três coisas a respeito da experiência do usuário para atender multi-dispositivos:

Consistente: A experiência deve ser consistente com o dispositivo sendo utilizado. Cada dispositivo terá uma maneira diferente de apresentar e de interagir com o usuário.
Contínua: A experiência deve ser contínua entre os dispositivos. Ele não deve ter que pensar toda vez que for mudar de dispositivo, e.g. ao começar a ler um livro no smartphone, ao pegar o tablet, o livro deve abrir na mesma página.
Complementar: A experiência de um dispositivo pode complementar a de outro. A experiência pode iniciar em um dispositivo, continuar em outro e terminar em um terceiro. Um complementando o outro, e.g. comprar um ticket pelo notebook e utilizar o smartphone como carteira virtual.

Track talks

Java 8 na prática, do Lambda às novas APIs: Mostrou novas APIs do Java 8 para tratamento de datas e como ficou a sintaxe das expressões lambdas. Achei a sintaxe e as APIs apresentadas bem agradáveis. Apesar de serem mudanças bem suaves, mostram que a linguagem está evoluindo.

Monadic Java: Functional Programming Patterns Applied: Detectou três monads na nova API do Java 8 e tentou explicar de forma simples o que é um monad. Achei a apresentação válida, mas a explicação de monad foi fraca, não sei se o apresentador conseguiu atingir o objetivo. Eu achei tranquilo porque já passei por algumas tentativas de implementar monads no Java, já presenciei os problemas relacionados ao sistema de tipos do Java em relação à isto, então a apresentação dele me pareceu bem entendível e palatável. De qualquer forma, a melhor explicação que eu vi sobre monads até hoje está no YouTube no vídeo Brian Beckman: Don't fear the Monad.

Falling in Love with APIs without divorcing legacy software: Apresentação falou do uso do Mulesoft para expor APIs de código legado. Foi uma apresentação agradável e bem animadora. O produto deles parece estar muito bom.

Multithreading e Java EE: pouca mudança no código e muita nos resultados: Mostrou a utilização da anotação @Asynchronous em JavaEE. JavaEE é uma coisa estranha: é um padrão despadronizado. Cada servidor faz de um jeito. Durante a apresentação ocorreram duas exceções completamente alienígenas, mas que o apresentador já conhecia, então ele resolveu rápido. Não gosto muito de coisas que acontecem de forma demasiadamente mágica, que dependem do contexto em questão.

Arquiteturas na nuvem com os custos sob controle: processando bilhões de páginas na AWS sem estourar o cartão: Contou como eles fazem para utilizar a infraestrutura da AWS sem gastar muito. Desenvolveram um sistema interno para otimizar a compra de máquinas por leilão (spot instances). Achei muito interessante. Comentaram que pretender abrir como open source, então fiquem ligados nas noticias da TailTarget.

FIM. Pois é, acabou. Assim, sem mais e nem menos. Quando saí da apresentação anterior, os patrocinadores já estavam se recolhendo e os nerds estavam indo embora. Ano passado teve um keynote no final que permitiu que a organização fizesse um breve discurso de encerramento. Este ano não teve isto, achei bem estranho e meio "tosco", podiam pelo menos ter dito "até mais, e obrigado pelos peixes", ou qualquer frase curta para deixar o pessoal brevemente empolgado e falando bem do evento.

Gostou dos posts que fiz sobre o QCon? Então adiciona meu blog nos teus feeds. Nem falei de Haskell nesse post, o que mostra que também posso ser um cara legal! Afinal, eu podia estar falando de Haskell, mas tô aqui pedindo sua assinatura... :)

Segundo dia de QConSP 2014

2014-04-10T20:31:00.000-03:00

O segundo dia de QConSP 2014 começou com duas keynotes fantásticas. O primeiro a falar foi um membro do Jet Propulsion Lab da NASA: Rob Witoff, seguido por Jarrod Overson, que trabalha na RIOT Games (a empresa por trás de League of Legends). Depois começaram as tracks com palestras simultâneas, escolhi participar das que tinham algum relacionamento direto com desenvolvimento. Post rápido!

Building a Data Science Program at NASA/JPL with Visual Analytics

O palestrante é um data scientist que trabalha na NASA. Fez uma analogia interessante, em resumo do que minha memória permite: "uma vasta porção do nosso universo é dark matter, que nós ainda não entendemos; da mesma forma os dados que nós temos e não entendemos são dark data; podemos ter muito conhecimento interessante escondido nos nossos silos de armazenamento de dados".

Ele elencou passos importantes para explorar a dark data:

Liberate data: consistem em liberar este dado escondido e torná-lo acessível. Eles fizeram muito nisso e tornaram vários dados acessíveis através de APIs Web públicas, i.e. torne fácil de acessar os dados, construa uma camada em cima deles, esqueça strings de conexão cabulosas para acessar os repositórios.
Enable engineers: torne possível que as pessoas possam interagir com os dados, que eles consigam fazer o que precisa ser feito: filtrar, combinar, analisar, etc.
Infuse data science: coloque data science em tudo isso, correlacione os dados, encontre padrões.
Innovate: agora você já tem tudo que precisa para inovar, então vá e inove! Mostre estes dados de formas diferentes e tire conclusões sobre eles, construa camadas em cima de camadas e continue inovando.

A NASA possui um negócio bem interessante chamado "innovation vacation" que consiste em tirar "férias" para inovação. Um profissional tem uma ideia; a ideia é boa; este profissional irá tirar "férias para inovação" para construir a ideia junto com o pessoal de inovação, são no máximo duas semanas em que a pessoal fica completamente isolada do resto da empresa: sem acesso a e-mails, sem reuniões, etc; o time do palestrante faz uma espécie de coaching deste profissional durante este período; este tempo possui três "marcos" fundamentais: alinhamento, demo e entrega, i.e. é feito um alinhamento inicial da ideia e das expectativas, depois de um certo trabalho é feito uma demonstração para ver se está indo no caminho certo e no final do ciclo é feita a entrega e fim, não há adiamentos ou prolongamentos.

Dois slides desta apresentação me deixaram muito feliz, que fala como funciona a parte de inovação da NASA e que apoiam o que escrevi no post sobre otimização prematura de negócio e com alguns comentários do post sobre o primeiro dia de QCon:

Fail fast. Iterate.
Run like a startup

Scaling League of Legends: managing culture, extreme complexity and 30 million active users

Achei que esta apresentação seria mais técnica, mas falou do problema de escalar pessoas, processos, etc. Comentou que o quê funciona no "pequeno" não funciona no "grande". A apresentação trouxe a Web como exemplo de algo que escalou muito bem e o apresentador afirma que ela escalou porque ela precisava escalar de um jeito ou de outro e podemos aprender com ela:

Ela precisa ser distribuída, pessoas do mundo inteiro irão acessar conteúdos espalhados por todo lugar.
Precisa ser assíncrona e levar em consideração timezones diferentes.
Todos são iguais, não importa se você tem doutorado ou ainda está no colégio, você tem o direito de ver e publicar conteúdo.

Ele relaciona estes pontos da Web para tornar uma empresa escalável: você precisa ter formas de comunicação assíncronas, reuniões não são escaláveis; você precisa ter uma maneira de colaboração, em que todos são ouvidos; você precisa lidar com times remotos; etc. (A parte em ênfase foi a que achei top da balada.)

Depois ele entrou mais em detalhes da parte Web, mostrando que ela passou a ser um target de compilação válido. Unity está compilando jogos para rodar na web; Asm.js está fazendo o Javascript ser mais nativo/rápido; Web Components estão aí; HTTP2.0 irá revolucionar a forma de trabalho. Achei interessante, pois depois relacionei isto com as demais apresentações e é notável de que tudo parece estar com uma perna nas tecnologias fundamentais para a Web (HTML, CSS, JS). O que me fez ver mais valor ainda em iniciativas como o Haste (compilador Haskell com target para Javascript).

Track talks

Vou tentar resumir as talks das tracks, pois não achei nenhuma que merecesse destaque.

Programação funcional reativa: Lidando com código assíncrono: Interessante, pelo menos ele falou que gosta de Haskell. Mostrou como funciona o RxJS, um framework com grande influência de FRP (Functional Reactive Programming) para Javascript.

JavaScript Funcional: Bem didática e boa abordagem, porém muito introdutório, aproveitei pouco, exceto por ter conhecido o link FunctionalTalks.org.

Uma startup em Scala: Dos patterns à produção: Muita introdução, mais do mesmo. Ver código Scala sempre me dá vontade de vomitar. É verborrágico de mais. O pessoal se gaba do type-system, mas o negócio leva décadas para compilar. Me gusta Haskell, great type system, great compilation time.

C# e C++/CX - O que há de novo nas linguagens para suportar o desenvolvimento de aplicações modernas: Esta trouxe uma visão legal da unificação que a Microsoft está fazendo em suas quatro plataformas: Smartphone, Tablet, Desktop e XBox. A interoperabilidade que ela está fazendo me pareceu fantástica: código C++/CX chamado de Javascript e vice-versa, C# no meio, novos conceitos de "aplicações modernas".

Building a Cloud IDE you might not hate: the Orion experience and beyond: Comentou sobre a construção da IDE na nuvem chamada Orion e mostrou alguns concorrentes, nada muito interessante até o momento, apenas mostra que existe um movimento forte de várias empresas e iniciativas da comunidade para uma IDE na nuvem.

Primeiro dia de QConSP 2014

2014-04-09T20:38:00.003-03:00

Hoje foi o primeiro dia do evento QConSP 2014. Vou tentar resumir minhas percepções sobre este primeiro dia de evento. O dia foi composto de dois tutoriais: um de manhã e um a tarde e finalizava com três apresentações curtas (short-talks). Elaborei este post de forma rápida, desculpe se o texto está difícil de entender.

Iniciando com Continuous Delivery

O primeiro tutorial que participei falava sobre entrega contínua (Continuous Delivery). Algo que já estou estudando e tentando praticar, porém até agora somente em provas de conceito e testes, nada colocado em produção de fato. Decidi participar deste tutorial para ver se conseguia conectar com as minhas experiências.

Quanto mais estudo sobre arquitetura orientada a serviços, integração contínua e entrega contínua mais percebo que são assuntos cada vez mais consolidados e todos eles se resumem basicamente em atitude. Que inclusive foi algo comentado pelos palestrantes Fabricio Leoti e Rodrigo Russo. Não existe uma bala de prata para a "nova indústria de software", o que existem são profissionais com atitude comprometidos em fazer algo funcionar; profissionais que estão acima de crenças e de seus próprios egos; o novo profissional de software deve fazer o melhor possível para integrar várias ferramentas de mercado em seu favor, sempre buscando eliminar sua própria existência como uma necessidade para a empresa, i.e. automatizar e tornar mais eficientes todos os processos para que fique livre para explorar coisas mais interessantes e que tragam valor para a corporação.

Este novo modelo de trabalho está se tornando cada vez mais forte. O que percebo é que é uma questão de tempo: quem não se adaptar, não conseguirá captar e reter os melhores profissionais e consequentemente, com o tempo, não conseguirá mais entregar valor para seus clientes, que procurarão fornecedores que acompanhem o novo ritmo do mundo. A entrega contínua faz parte desse novo mundo: todos que querem se manter atualizados precisam aprender e se adaptar.

Para obter a entrega contínua é preciso disciplina: é preciso ter processos de provisionamento automatizados e um processo de integração contínua funcionando 100%. A preparação deve ser feita na parte cultural da equipe: todos precisam querer e buscar este nível de excelência.

Acredito que as partes deste tutorial que mais podem contribuir com meu trabalho atualmente são:

Todos devem ser responsabilizados por tudo: a qualidade não é responsabilidade só do time de testes; a evolução do produto não é só responsabilidade do gerente de produto; o erro não é responsabilidade só do time de desenvolvimento. Todos precisam se sentir envolvidos e donos do produto final. É como se a equipe se tornasse uma startup: todos comemorarão com os sucessos e todos sofrerão com os fracassos.
Uma funcionalidade só é considerada "entregue" quando ela está em produção e em uso pelos clientes. Pensando bem, não sei como não cheguei nesta conclusão por conta própria. É um pensamento completamente razoável e com sentido. Na verdade, pensar de outra forma é que não faz o menor sentido: como você pode considerar uma funcionalidade como "entregue" se não tem ninguém usando? Frases como "está pronto, só faltam os testes" ou "está pronto, só falta jogar para produção" não fazem o menor sentido!

NoSQL Aplicado

Compareci neste tutorial para ver na prática as aplicações de bases NoSQL. Estou começando a trabalhar um pouco com o MongoDB, mas sempre ouço falar bem do Cassandra, HBase, etc. Gostaria de aproveitar este tempo para ver as aplicações destes diferentes bancos para evitar ter que passar por processos de tentativa e erro ou grandes sessões de leitura para poder decidir qual banco utilizar para cada situação.

Confesso que me decepcionei com a apresentação. Ela se resumiu em apresentar as bases NoSQL e um pouco da arquitetura interna delas. Coisas que são relativamente fáceis de buscar na internet e que eu já tinha uma noção básica. No final das contas, o conteúdo apresentado não me fez saber melhor qual base utilizar em cada situação e não vi nenhuma aplicação do NoSQL, i.e. "aplicado" só no título do tutorial.

Mas, apesar de não satisfazer minhas expectativas, foi possível aproveitar um pouco do conteúdo do tutorial. O mais relevante para mim na verdade ficou como tarefa de casa: aprender ZooKeeper.

Short-talks

As apresentações curtas que assisti foram "Hadoop: Mãos à massa!", "Cassandra no Desenvolvimento de Serviços para Apps Mobile" e "Play, do zero ao deploy em 20 minutos". Mas estas tiveram o mesmo problema que ocorreu na edição de 2013 do evento: o tempo é curto de mais! Todos os apresentadores estouraram o tempo. Mesmo se não tivessem estourado, o conteúdo passado sempre é demasiadamente superficial.

Os palestrantes foram ótimos, todos os três. A de Hadoop utilizou humor, a de Cassandra trouxe um caso do mundo real e a do Play foi direta ao ponto. Mas são apresentações que só servem para despertar o interesse do ouvinte. Como eu já tinha visto da história de Hadoop no tutorial de NoSQL, foi meio repetitivo; a de Cassandra conseguiu ter mais "NoSQL Aplicado" do que o tutorial, mas como foi muito rápido só ficou como aprendizado: "é possível começar um serviço com base relacional e trocar por um NoSQL depois", que vai de encontro com o que escrevi no post passado sobre otimização precoce; a última que falou do Play Framework despertou um interesse muito saudável, vou procurar saber mais sobre ele por algumas propriedades dele que brilharam aos meus olhos, principalmente static checking.

Organização

Este ano o evento está muito melhor organizado. O evento está acontecendo no WTC SP que possui um espaço muito melhor do que o local do ano passado. O credenciamento foi bem tranquilo, apesar de que só recebi a credencial à tarde, mas porque a compra do dia de tutoriais foi feita em cima da hora (ontem). As pausas com café entre as apresentações também estão mais generosas e com uma distribuição melhor pelo local, em nenhum momento senti falta de suco, café, água e alimentação.

Comentários

Alguns pensamentos que passaram pela minha cabeça hoje durante o evento:

Com o crescimento de bases NoSQL e de BigData, o papel exclusivo de um administrador de banco de dados parece estar perdendo força. Juntando com a entrega contínua, em que todo mundo se responsabiliza por tudo, os desenvolvedores precisam pensar em como o dado será lido antes de armazená-lo, precisa entender da topologia de onde ficarão os dados e etc. Será que faz sentido ainda ter um papel exclusivo para isto?
Entrega contínua significa metodologia ágil. Não sei como colocar um processo cascata que faz entrega contínua. Já é difícil fazer com que todos se sintam responsáveis pelo produto em uma metodologia tradicional.
O número de apresentações sobre programação funcional cresceu do ano passado para cá. Mas não sei se todos estão preparados para esta mudança. Teve um tutorial exclusivo de Clojure este ano, gostaria de ter participado, mas a de entrega contínua pareceu mais fácil de "aplicar na vida real". Por mais que eu seja um entusiasta de Haskell e querer que a programação funcional se torne mainstream, parece que ainda há uma barreira natural para que isto aconteça. Ouvi comentários de que "programação orientada à funções era estranho". De certa forma não tiro razão destes comentários, ouvi que a apresentação de "Lambdas em Java" falou de estruturas persistentes e deu como exemplo a da estrutura de árvore, que é "modafoca" para entender. Acho que isto é uma falha dos entusiastas das linguagens funcionais: nós ficamos tão empolgados com as inúmeras "qualidades" deste modelo, que atravessamos tudo e tentamos passar todo conhecimento em uma única apresentação.

Otimização prematura: não é apenas sobre código

2014-04-07T22:01:00.000-03:00

Quando falamos sobre desempenho, não devemos olhar apenas para desempenho da execução de código. Existem mais tipos que devemos prestar atenção, como tempo para mercado, tempo de desenvolvimento e processos. Na verdade, não devemos olhar qualquer uma destas medidas de desempenho de uma única perspectiva. Penso que todas estas medidas se unificam para constituir um único valor de desempenho de negócio.

Existem muitas coisas que podem desacelerar seu negócio, e se você tiver um negócio devagar, será difícil acompanhar o ritmo de seus concorrentes. A partir do momento que você vê que algumas áreas da sua empresa podem estar te atrasando, você pode sentir-se tentado a adicionar indicadores de desempenho em cada passo, tentando espremer todo valor possível de cada parte do seu processo. Isto pode trazer um monte de novos problemas, seu negócio pode ser visto como um sistema complexo e ele irá se adaptar para mostrar bons resultados mesmo em cenários caóticos. [1]

Então, para evitar ficar maluco com indicadores para todos os lados, você decide evitar gargalos desde o princípio. Para cada coisa nova que você precisa entregar, começará uma rotina de planejamento preciso, escolhendo entre uma infinidade de fornecedores, tecnologias e unicórnios para evitar a todo custo ter um novo gargalo no futuro. Isto é o que gosto de chamar de otimização prematura de desempenho de negócio.

De forma simples: você não pode ter um negócio se você não tiver um negócio. Como você pode saber de todos os eventos futuros que irão impactar na decisão que você toma hoje? Você não pode. Não estou dizendo que planejar é errado ou uma Coisa Ruim™. O que eu realmente quero é evitar perder energia em coisas que não farão a menor diferença. Você pode gastar um ano inteiro escolhendo entre maçãs e laranjas, e no final ser esmagado por algum maluco brincando com tecnologias esquisitas. Por quê? Porque ele não estava preocupado com gargalos futuros. Ele estava realmente tentando fazer algo legal, e ele fez isto enquanto você estava discutindo em intermináveis reuniões sem propósito.

Você sempre está escolhendo entre medidas de desempenho. Por exemplo, todo mundo está falando a respeito de arquitetura orientada a serviços (SOA), mas o que isso significa em termos de negócio? Significa uma troca entre desempenho de execução de código e outros benefícios para o negócio como um todo, como crescimento descentralizado e entrega contínua. Ou, você pode olhar nas diferenças entre os modelos da App Store da Apple e a Play Store do Google. Existe uma troca gigantesca entre garantia de qualidade e tempo de mercado entre estes dois jogadores: um oferece a seus clientes (donos de smartphones), aplicativos com qualidade assegurada; o outro oferece a seus clientes (usuários do sistema operacional), tempo para lançamento ao mercado acelerado para seus aplicativos.

A grande questão realmente é: o quê você está tentando entregar ao seu cliente? Você está tentando entregar software sobre tempo ou valor sobre tempo? Eu aposto que a maioria de vocês estão tentando entregar valor sobre tempo, então por quê se preocupar com otimização prematura de tecnologias ou processos? Deixe que as coisas ruins morram por si só: falhar rápido é dezenas de vezes melhor do que não fazer nada. E deixe que as coisas boas te acompanhem para onde você quer ir.

Não gaste seu tempo adivinhando o futuro, abrace a incerteza da vida: você não pode prever como um sistema complexo irá se comportar, você não pode saber como seus sistemas, serviços ou seja lá o que você esteja fazendo, irão se comportar no mundo real. Coloque eles para funcionar, receba as reclamações e ajuste o que for preciso (ou jogue tudo fora), isto é um processo constante. [2]

Comece a medir quanto você está entregando em determinado tempo e pare de planejar tanto. Seu objetivo final é entregar coisas. O mundo não poderia se importar menos com o que você consegue fazer, ele só se importa com o que você faz.

Referências

Complex Systems and Key Performance Indicators - Márcio Geovani Jasinski
Complaint-Driven Development - Jeff Atwood

Infectado por exceções

2013-08-05T16:29:00.000-03:00

Acredito que códigos infectados por exceções sejam ruins. Imagine o seguinte código inofensivo:

public static Foo newFoo(int bar) {
  switch (bar) {
    case 1: 
      return new FooOne();

    case 2: 
      return new FooTwo();

    default: 
      throw new IllegalArgumentException("invalid bar code: " + bar);
  }
}

Você utiliza ele no meio da sua regra de negócio, com a maior tranquilidade. O código compila e tudo:

public static List<BazFoo> getAllBazFoo() {
  List<BazFoo> result = new ArrayList<>();
  List<Baz> allBaz = BazDAO.getAllBaz();
  for (Baz baz : allBaz) {
    int id = baz.getId();
    int bar = baz.getBar();
    Foo foo = Foo.newFoo(bar);
    BazFoo e = new BazFoo(id, foo);
    result.add(e);
  }
  return result;
}

O problema é que a chamada Foo.newFoo(bar) pode lançar um IllegalArgumentException e quando isto ocorrer você não terá pista nenhuma de qual Baz está com a informação inválida.

Para tratar isto e tornar a mensagem mais útil, temos que lembrar de adicionar um try/catch no código:

public static List<BazFoo> getAllBazFoo() {
  List<BazFoo> result = new ArrayList<>();
  List<Baz> allBaz = BazDAO.getAllBaz();
  for (Baz baz : allBaz) {
    int id = baz.getId();
    int bar = baz.getBar();
    Foo foo;
    try {
      foo = Foo.newFoo(bar);
    } catch (IllegalArgumentException e) {
      throw new IllegalArgumentException("invalid baz: " + id, e);
    }
    BazFoo e = new BazFoo(id, foo);
    result.add(e);
  }
  return result;
}

Adicione várias camadas de abstração à sua aplicação e pronto: espagueti sabor excepcional. Ao adicionar exceção em algum ponto, você terá que revisar toda a pilha de abstrações que você tem e garantir que a exceção não faça mal a ninguém e que tenha uma mensagem útil para futuras manutenções.

Haskell resolve boa parte da necessidade de exceções com retornos que simbolizam falhas, e.g. Maybe e Either, e o uso de Monad elimina a necessidade de verificar os retornos a cada passo.

Porém, ainda existem exceções em Haskell, por quê? Não consigo entender o motivo para preferir exceções ao invés de retornos especiais. Em quais situações usar exceções é melhor? Mais me parecem um goto modernizado.

Livro: Code Simplicity

2013-07-06T16:52:00.000-03:00

Acabei de ler o livro "Code Simplicity: The Fundamentals of Software" (em português: "As Leis Fundamentais do Projeto de Software").

O autor tenta criar uma ciência em cima do desenvolvimento de software. São cerca de 90 páginas que falam sobre detalhes importantes desta engenharia sem mostrar nenhuma linha de código.

Entre os assuntos citados pelo autor, o que mais me impressionou foi a fórmula do custo de uma alteração em um software.

Esta fórmula, quando aplicada ao tempo, deixa claro que o valor futuro e o custo da manutenção de uma alteração tem um peso muito maior do que o custo e o valor imediato gerado por uma alteração. Pois com o passar do tempo, o valor investido para manter a funcionalidade supera muito o valor investido inicialmente para codificá-la. Não vou entrar em muitos detalhes, se ficou curioso: vá ler o livro.

Foi uma leitura muito prazerosa. Apenas fico triste pois cheguei neste livro por um acaso, não recebi nenhuma indicação. Meu sentimento é que se tivesse lido este livro antes, teria poupado boa parte das frustrações que vivi nestes anos como desenvolvedor. As explicações detalhadas do autor parece que se encaixam perfeitamente com os sentimentos e realizações que presenciei escrevendo e mantendo código.

Deixo aqui minha indicação para todos que trabalham na área de software: você precisa ler este livro! Independente de ser desenvolvedor ou não, você terá uma base muito melhor para tomar decisões que afetam o seu produto.

Se você já leu, deixe seus comentários sobre o que achou.

Cantinho da Criança

2013-06-12T00:22:00.000-03:00

Está pronto e publicado no Google Play o jogo infantil Cantinho da Criança!

O objetivo do jogo é ajudar crianças a reconhecer algumas coisas do dia-a-dia, auxiliando no aprendizado e no desenvolvimento. Indicado para crianças de 0 a 3 anos.

Colocamos imagens bem coloridas e uma música bem animada para ensinar e divertir ao mesmo tempo.

Se tiver filhos nessa faixa etária, não deixe de conferir: Google Play - Apps by Haeres

Abrace Android

2013-06-05T20:21:00.000-03:00

Já faz um tempo que não escrevo neste blog. As minhas aventuranças no mundo Haskell pararam um pouco depois do último post que fiz ("C, C++, Java, Haskell?").

Dediquei um bom pedaço deste tempo ausente para tentar fazer um jogo em C. Tive um bom começo: fiz um personagem se movimentar, pular e colidir com outros objetos. Comecei a perceber onde estava me metendo quando estas perguntas surgiram na minha mente:

Como vou distribuir meu jogo?
Como vou lançar uma atualização?
Como vou comercializar?

Neste momento estava com uma conexão carinhosa com o projeto e foi difícil aceitar que estas dificuldades poderiam ser maiores do que meu esforço disponível. Passada esta fase de aceitação, decidi que precisava tirar todas estas preocupações da cabeça para conseguir me dedicar ao desenvolvimento do jogo. Para isto precisava de uma plataforma que me oferecesse todos os itens que coloquei na lista acima.

Escolhi a plataforma Android por conseguir acesso a um ambiente de desenvolvimento de forma mais fácil, pois poderia continuar utilizando meu notebook rodando Windows para programar e realizar testes no meu celular Samsung Galaxy 5. Sem chance de investir em um ambiente para iOS no momento.

Para garantir que a plataforma atendia a todos os itens que listei acima, fiz o processo do começo ao fim:

Criei um aplicativo de exemplo
Testei no meu celular
Publiquei o aplicativo (Como vou distribuir meu jogo?)
Alterei algumas coisas e lancei atualizações para ele (Como vou lançar uma atualização?)
Criei uma versão free com propagandas e uma paga sem propagandas (Como vou comercializar?)

O resultado disto tudo foi muito agradável. Agora não me restam dúvidas sobre o ambiente Android, basta continuar meu aprendizado na plataforma e o desenvolvimento do projeto em paralelo. Espero que em breve eu consiga postar no blog um link para o resultado do projeto publicado. :)

C, C++, Haskell, Java?

2013-01-20T20:40:00.000-02:00

Estou empolgado e agoniado com meu aprendizado sobre OpenGL. Ao mesmo tempo em que aprender OpenGL me deixa muito satisfeito, também me deixa inquieto: dediquei muito tempo aprendendo Haskell e fui envolvido de uma forma a gostar muito da linguagem e da comunidade. Porém, fazer algo em OpenGL se mostrou muito difícil e até mesmo solitário. Existem pouquíssimos materiais sobre isso e a maioria deles estão obsoletos.

Tive que largar Haskell por um tempo e religar os neurônios da linguagem C para aprender o fluxo das versões mais modernas do OpenGL, com shaders e buffer objects. O motivo foi simples: não consegui fazer nada funcionar em Haskell e não tive certeza se a culpa era minha ou das bibliotecas que utilizava.

Pois bem, fazer uma câmera se movimentar em um mundo 3D em C também não foi nada fácil. Mas com a abundância de material, consegui deixar funcionando de uma forma que me deixou bem satisfeito.

Decidi então voltar para Haskell e aplicar este conhecimento que acabei de conquistar.

Que trabalheira! Fazer tudo se encaixar da maneira certa e com os tipos corretos me fez suar algumas camisas. Se não fosse tão teimoso, não teria conseguido. Tive que trocar o pacote OpenGL pelo OpenGLRaw pois o pacote OpenGL não tem binding para "glUniformMatrix*"; também troquei o GLFW pelo GLFW-b porque o primeiro dependia do pacote OpenGL.

Recentemente li um artigo no InfoQ questionando se a linguagem C ainda era útil. Me fez pensar em muita coisa, inclusive em abandonar definitivamente Haskell e voltar às origens: ponteiros, gerenciamento de memória manual, strings cabulosas, ...

Talvez seja porque sou muito novo neste mundo, mas me sinto meio improdutivo programando em Haskell. A impressão que tenho é que, a menos que seja algo muito bem consolidado e utilizado por muitas pessoas da comunidade, muito tempo será gasto atrás de bibliotecas que normalmente são apenas um binding para uma escrita em C. Quando não for isto, só para ter uma breve ideia do que a API de uma biblioteca faz, acabo lendo alguns papers relembrando o que são Functors e Monads (para entender Arrows acho que vou precisar comprar um livro!).

Entender ponteiros e gerenciamento de memória em C também foi difícil. Mas naquela época eu era um jovenzinho no mundo da programação, meu conhecimento era muito limitado, se baseava muito em bater no código até que ele fizesse o que eu queria. Agora não consigo mais aceitar fazer alguma coisa sem entender o que estou fazendo.

Eu lembro que tive bons motivos para trocar C por Java. Depois de passar um tempo utilizando Java, vejo também as partes negativas da linguagem. Meu trabalho de conclusão da graduação foi dedicado a evidenciar os motivos desta troca e do futuro promissor de linguagens como Haskell.

No final das contas, acredito que esta pseudo-decepção acontece com toda linguagem em que você dedica bastante tempo para aprendê-la. A propaganda e os primeiros passos são maravilhosos. Parece que você descobriu um novo mundo onde todos são ricos e podem desfrutar de todas as coisas boas. Com o tempo você percebe que não é bem assim: cada escolha que a linguagem fez significa pontos positivos e negativos para nós usuários. Foi assim com C, Python, Java e agora com Haskell.

Java escolheu uma abordagem orientada a objetos: mesmo que seja uma função estática ou uma variável global, será necessária a roupagem de uma classe para acomodar este código. Haskell escolheu o funcional puro: mesmo operações que envolvam I/O recebem a roupagem de um monad.

Não que isto seja ruim. A utilização de monads para modelar computação sequencial foi uma grande descoberta que proporcionou a criação de inúmeras soluções. Estas escolhas trazem pontos positivos e negativos. Só devemos ter cuidado com o purismo extremo para não criar aberrações (e.g. Singleton).

Enfim, estou agoniado pois não sei o que escolher:

C me parece flexível mas com as complexidades que não quero ter. C11 parece solucionar algumas coisas (e.g. <threads.h>), mas o GCC ainda não suporta;
Sou bem produtivo em Java mas o overhead obrigatório e a necessidade de ter uma JVM me irritam profundamente;
C++ ainda é uma incógnita para mim, se for para ir neste nível ainda prefiro utilizar C. Java já me fez ver os motivos para dizer não à O.O. Por outro lado, boa parte de quem utilizava C está indo para C++, inclusive o GCC está utilizando C++. As bibliotecas disponíveis para C++ também pesam bastante (e.g. GLM, Boost);
Haskell é minha linguagem da vez mas está começando a me incomodar um pouco, sentimento de improdutividade me deixa muito tenso. Talvez precise dedicar mais tempo para que isto passe. Não sei se este esforço irá valer a pena ou poderia ser melhor aproveitado aprimorando meus conhecimentos em outra linguagem.

A diferença de desempenho entre C e Haskell não me preocupa muito, pois não vou escovar bits para ter um bom desempenho tão cedo.

No final das contas, a opinião mais correta sempre é: depende do projeto, escolha a melhor linguagem para o seu projeto. Pois bem, não tenho projeto nenhum, mas quero me aprofundar no desenvolvimento de jogos.

E agora?

DuDuHoX com som: OpenAL

2013-01-09T11:11:00.000-02:00

Trabalhar no DuDuHoX está cada vez mais difícil. Já pensei em desistir em alguns problemas que tive, seja com código ou com bibliotecas.

Colocar animação no jogo foi muito complicado. Porque o motor do jogo não tem estados intermediários em que o personagem está indo de uma casa para outra. O estado do jogo só permite que o personagem ocupe uma casa e não metade de uma e metade de outra.

Minha solução para isto foi colocar a informação de animação no código da interface gráfica (OpenGL). Após pressionar alguma tecla que movimente o personagem, o motor do jogo já estará no estado novo completo, mas a interface não aceitará mais nenhuma entrada enquanto não terminar de exibir a animação de movimentação.

Outro grande problema que tive foi quando decidi colocar sons no jogo. Meus objetivos são: música de fundo e sons posicionais. A biblioteca que achei para isto foi a OpenAL. Ela é feita em C mas existe o pacote Haskell que faz o binding.

Mas, nem tudo é tão bonito. Instalar a biblioteca OpenAL no Windows foi um tremendo caos. Foi uma tarde inteira tentando fazer isto. Quando finalmente consegui instalar, percebi que também iria precisar da biblioteca ALUT. Esta não foi tão difícil de instalar, porém, ocorriam erros de link durante a compilação. Felizmente encontrei um bug reportado para o GHC que tratava exatamente do meu problema: Ticket 1243. Depois de aplicar o patch, tudo funcionou.

Fiz uma música no OpenMPT, desenhei o personagem no GIMP e coloquei tudo dentro do jogo.

Apesar das dificuldades, estou muito feliz com resultado que estou obtendo em fazer o DuDuHoX em Haskell. Decidi gravar um gameplay com o CamStudio e compartilhar com vocês através do YouTube:

OpenGL em Haskell

2012-12-31T11:17:00.001-02:00

Continuo trabalhando no DuDuHoX.

A primeira interface do jogo é em console. Utiliza o pacote System.Console.ANSI. Funciona muito bem em Linux e Mac OS, apenas no Windows tem um pequeno problema de buffer, forçando com que o jogador tenha que apertar enter após cada jogada.

Esta semana decidi fazer uma nova interface para o jogo: com gráficos e sem o problema de buffer do console do Windows.

Primeiramente tentei utilizar SDL, pois foi ela que utilizei para fazer DuDuRoX em C. Infelizmente, não tive sucesso nenhum, nem mesmo consegui fazer um exemplo compilar.

Pensei em utilizar diretamente OpenGL para o gráfico, mas não sabia o que utilizar para gerenciar a entrada do usuário (apertar de teclas). Já vi reclamações a respeito de OpenGL/GLUT. Foi então que depois de algumas pesquisas conheci o GLFW, um biblioteca C open-source que fazia tudo que eu precisava, e o mais importante: existe o pacote GLFW para Haskell que faz o binding.

Depois de algumas horas aprendendo OpenGL e GLFW para Haskell, o resultado é este:

Já está jogável com esta interface, porém a versão console possui mais funcionalidades. Então, para as próximas semanas, vou tentar passar todas as funcionalidades da versão console para a versão gráfica e adicionar algumas texturas bacanas. A lista de coisas a fazer e todo o código está disponível no GitHub: https://github.com/thiago-negri/DuDuHoX.

Feliz 2013!

Programação funcional pura e útil

2012-08-15T21:42:00.000-03:00

Acho que todos os programadores acostumados com o modelo imperativo ficam espantados em imaginar quão maluco é o modelo funcional puro. Afinal, como podemos fazer qualquer coisa útil sem gerar efeitos colaterais? Sem imprimir no console? Sem abrir uma tela? Sem gerar logs? Sem alterar variáveis? OMG.

Este também foi um espanto meu ao conhecer Haskell e por uma feliz insistência descobri que o problema está na cabeça do programador e não no modelo funcional puro.

Diferenças

Viver muito tempo no contexto das linguagens imperativas acabou modelando minha forma de pensar em uma maneira sequêncial. Eu sempre precisei dizer como fazer cada passo da computação, quais estados manter, quais variáveis alterar, quando retornar um valor, etc.

Enquanto que no mundo funcional puro, fui obrigado a pensar em uma maneira de transformação de dados. Ao invés de pensar em como fazer cada etapa, preciso pensar como transformar um dado em outro, i.e. como extrair a representação que quero a partir do dado que tenho.

Os exemplos clássicos para demonstrar esta diferença envolve a manipulação de listas.

Exemplo #1

Para calcular a somatória no estilo imperativo, é necessário pensar no controle sobre o estado da soma atual, que deve ser acumulado durante a iteração da lista.

int sum(int[] list) {
  int result = 0;
  for (int i : list)
    result += i;
  return result;
}

Do outro lado, no mundo funcional, é necessário pensar em como transformar uma lista em um único número que represente a soma de todos os elementos, i.e. a soma de uma lista vazia sempre será zero e a soma de qualquer outra lista é definida pelo seu primeiro valor acrescentado da soma do restante da lista.

sum [] = 0
sum (x:xs) = x + sum xs

Exemplo #2

Já em um exemplo um pouco mais complexo, em que precisamos manter duas listas no mundo imperativo, uma de entrada e outra de saída, precisamos incluir o controle sobre o índice de cada lista, para evitar erros de indexação.

String[] toText(int[] list) {
    String[] result = new String[list.length];
    for (int i = 0; i < list.length; ++i)
        result[i] = Integer.toString(list[i]);
    return result;
}

Enquanto que o mesmo exemplo no mundo funcional continua simples como a somatória da lista, a única diferença é que ao invés de transformarmos a lista utilizando a adição, utilizamos o próprio construtor de listas (representado pelo operador ':').

toText [] = []
toText (x:xs) = show x : toText xs

Motivação

Para demonstrar que o modelo funcional puro pode fazer muitas coisas além dos exemplos clássicos, de uma forma que considero bonita e com vantagens gratuitas, escrevo este post.

Calculadora

Hoje vamos criar uma calculadora em Haskell. Todo o código será puro, sem nenhum tipo de efeito colateral, incluindo uma DSL para escrever testes, o próprio executor dos testes e dois transformadores de cenários de teste, um para escrever o teste no formato de texto e outro para escrever o mesmo teste no formato de um JUnit.

Formato dos testes

Primeiramente, definimos o formato em que os testes serão escritos. Neste caso, será uma sequência de ações e validações:

data TestSequence =
    Do Action TestSequence
  | Check Assertion TestSequence
  | Done

Com esta estrutura de dados, os testes poderão ser escritos neste formato:

test =
  Do a.
  Do b.
  Do c.
  Check d$
  Done

A necessidade de ter o "Done" no final do teste me incomoda. Para evitar que precise escrever isto, indicarei que os testes sempre terminem de forma aberta, i.e. permitindo continuar a sequência:

type Test = TestSequence -> TestSequence

Agora podemos escrever o teste da seguinte forma:

test =
  Do a.
  Do b.
  Do c.
  Check d

Para mim, já está classificada como uma DSL funcional para testes.

O único tipo de ação disponível na calculadora é o de apertar seus botões e a única validação será a verificação do seu display. Os botões disponíveis são os padrões de uma calculadora.

data Action =
    Press Button

data Assertion =
    DisplayHasNumber Int

data Button =
    Zero
  | One
  | Two
  | Three
  | Four
  | Five
  | Six
  | Seven
  | Eight
  | Nine
  | Plus
  | Minus
  | Times
  | Divide
  | Equals
  | Clear
    deriving (Show)

Primeiro teste

O primeiro passo está pronto. Já temos uma DSL para testes compilando. Hora de escrever nosso primeiro teste, que também já compila:

sample :: Test
sample =
    Do (Press One).
    Do (Press Plus).
    Do (Press One).
    Do (Press Equals).
    Check (DisplayHasNumber 2).

    Do (Press Clear).
    Check (DisplayHasNumber 0).

    Do (Press Two).
    Do (Press Zero).
    Check (DisplayHasNumber 20).
    Do (Press Divide).
    Do (Press Two).
    Check (DisplayHasNumber 2).
    Do (Press Equals).
    Check (DisplayHasNumber 10)

Transformadores do teste

Como nosso teste está escrito na forma de uma estrutura de dados, isto nos dá muitas possibilidades para tratamento do caso de teste. Para facilitar as transformações desta estrutura, definimos uma função que aplica uma função genérica a cada passo do teste e agrupa os resultados em uma lista:

unroll :: (TestSequence -> a) -> Test -> [a]
unroll f t = g (t Done)
  where g Done = [f Done]
        g v@(Do _ next) = f v : g next
        g v@(Check _ next) = f v : g next

Teste -> Texto

Podemos processar o teste e gerar uma saída textual do cenário:

prettyPrint :: Test -> String
prettyPrint = unlines . unroll prettyPrintTestSequence

prettyPrintTestSequence :: TestSequence -> String
prettyPrintTestSequence s =
    case s of
      Done              -> "end"
      Do action _       -> prettyPrintAction action
      Check assertion _ -> prettyPrintAssertion assertion

prettyPrintAction :: Action -> String
prettyPrintAction (Press button) = 
    "press " ++ prettyPrintButton button

prettyPrintButton :: Button -> String
prettyPrintButton = map toLower . show

prettyPrintAssertion :: Assertion -> String
prettyPrintAssertion (DisplayHasNumber number) = 
    "the display should be showing the number " ++ 
    show number

Testando no GHCi:

\> putStr $ prettyPrint sample
press one
press plus
press one
press equals
the display should be showing the number 2
press clear
the display should be showing the number 0
press two
press zero
the display should be showing the number 20
press divide
press two
the display should be showing the number 2
press equals
the display should be showing the number 10
end

Teste -> JUnit

Também podemos gerar casos de teste para uma possível solução Java da nossa calculadora:

generateJUnit :: Test -> String
generateJUnit = 
    ("@Test\npublic void test() {\n" ++) . 
    unlines .
    unroll generateJUnitTestSequence

generateJUnitTestSequence :: TestSequence -> String
generateJUnitTestSequence s =
    case s of
      Done      -> "}"
      Do a _    -> generateJUnitAction a
      Check a _ -> generateJUnitAssertion a

generateJUnitAction :: Action -> String
generateJUnitAction (Press b) =
    generateJUnitButton b ++ ".press();"

generateJUnitButton :: Button -> String
generateJUnitButton b = "getButton" ++ show b ++ "()"

generateJUnitAssertion :: Assertion -> String
generateJUnitAssertion (DisplayHasNumber n) =
    "assertEquals(" ++ show n ++ ", getDisplayNumber());"

Testando no GHCi:

\> putStr $ generateJUnit sample
@Test
public void test() {
getButtonOne().press();
getButtonPlus().press();
getButtonOne().press();
getButtonEquals().press();
assertEquals(2, getDisplayNumber());
getButtonClear().press();
assertEquals(0, getDisplayNumber());
getButtonTwo().press();
getButtonZero().press();
assertEquals(20, getDisplayNumber());
getButtonDivide().press();
getButtonTwo().press();
assertEquals(2, getDisplayNumber());
getButtonEquals().press();
assertEquals(10, getDisplayNumber());
}

Teste de fato

E claro, também podemos utilizar nosso teste no formato de uma estrutura de dados para realmente testar uma calculadora:

data TestResult =
    Ok
  | Failed FailureMessage

type FailureMessage = String

instance Show TestResult where
    show Ok = "Test passed"
    show (Failed m) = "Test failed: " ++ m

checkTest :: Test -> TestResult
checkTest t = 
    evalState 
    (threadCheckState . unroll checkTestSequence $ t)
    mkCalculator

threadCheckState :: [State Calculator TestResult] ->
                    State Calculator TestResult 
threadCheckState = go 0
  where go _ [] = return Ok
        go n (x:xs) = x >>= (f n xs)
        f n xs Ok = go (n + 1) xs
        f n _ (Failed m) = 
          return . Failed $
            "Step " ++ show n ++ ". " ++ m

checkTestSequence :: TestSequence -> 
                     State Calculator TestResult
checkTestSequence Done = return Ok
checkTestSequence (Do a _) = checkAction a
checkTestSequence (Check a _) = checkAssertion a

checkAction :: Action -> State Calculator TestResult
checkAction (Press b) = do
    modify $ pressButton b 
    return Ok

checkAssertion :: Assertion -> State Calculator TestResult
checkAssertion (DisplayHasNumber n) =
    get >>= \c ->
      if displayNumber c == n
        then return Ok
        else return . Failed $ 
          "Wrong number in display, should be " ++
          show n ++ " but was " ++ show (displayNumber c)

O coração da calculadora

Finalmente, para que o testador-de-fato compile, precisamos definir uma primeira versão da nossa calculadora. Aqui você poderia tentar criar sua própria implementação. Cheguei neste código para atender ao cenário do teste:

data Calculator = Calculator {
    displayNumber :: Int
  , operation :: Maybe (Int -> Int -> Int)
  , savedNumber :: Int
  }

pressButton :: Button -> Calculator -> Calculator
pressButton b =
  case b of
    Zero    -> appendNumber 0
    One     -> appendNumber 1
    Two     -> appendNumber 2
    Three   -> appendNumber 3
    Four    -> appendNumber 4
    Five    -> appendNumber 5
    Six     -> appendNumber 6
    Seven   -> appendNumber 7
    Eight   -> appendNumber 8
    Nine    -> appendNumber 9
    Plus    -> saveOperation (+)
    Minus   -> saveOperation (-)
    Times   -> saveOperation (*)
    Divide  -> saveOperation div
    Equals  -> performOperation
    Clear   -> clear

appendNumber :: Int -> Calculator -> Calculator
appendNumber i c = 
  c { 
    displayNumber = (displayNumber c) * 10 + i 
  }

saveOperation :: (Int -> Int -> Int) -> 
                 Calculator -> Calculator
saveOperation f c = 
  c { 
    savedNumber = (displayNumber c)
  , displayNumber = 0
  , operation = Just f
  }

performOperation :: Calculator -> Calculator
performOperation c = 
  c { 
    savedNumber = newNumber
  , displayNumber = newNumber 
  }
  where newNumber = 
          case (operation c) of
            Nothing -> displayNumber c
            Just f  -> let a = savedNumber c
                           b = displayNumber c 
                        in
                           f a b

clear :: Calculator -> Calculator
clear = const mkCalculator

mkCalculator :: Calculator
mkCalculator = 
  Calculator { 
    displayNumber = 0
  , operation = Nothing
  , savedNumber = 0
  }

Testando a calculadora

Agora podemos executar o testador-de-fato contra nossa calculadora no GHCi. Vamos experimentar:

\> checkTest sample
Test passed

Isto significa que nossa calculadora está atendendo ao cenário de teste. Para garantir que o teste capture um comportamento que não corresponda ao cenário de teste, podemos introduzir um erro: alteramos o valor da multiplicação na função "appendNumber" de "10" para "100". Se rodarmos novamente o teste, teremos este resultado:

\> checkTest sample
Test failed: Step 9. Wrong number in display, should be 20 but was 200

Magavilha.

Conclusão

Construímos um código básico de uma calculadora funcionando que atende ao especificado no cenário de teste. Agora basta adicionarmos novos testes e continuar incrementando nossa calculadora, parecido com um TDD. Tudo isto foi feito de uma forma 100% pura, sem depender de nada que envolva IO, estado, variáveis ou logs.

Além do benefício de podermos fazer qualquer tipo de transformação nos cenários de teste, também podemos rodar quantas transformações e quantos testes quisermos de forma paralela, pois tanto o teste quanto a calculadora são thread-safe pelo simples fato de serem escritos de forma pura.

Conseguimos fazer tudo isto em míseras 251 linhas de código ou 5635 caracteres, incluindo comentários e linhas em branco. Quantas classes e/ou linhas seriam necessárias para contemplar todas as funcionalidades e seguranças demonstradas neste post na sua linguagem imperativa favorita?

Espero que este post sirva para inspirar vossas mentes a pensar "fora-da-caixa" do mundo imperativo. Existem muitas vantagens em aprender uma linguagem funcional pura, mesmo que você utilize linguagens imperativas para trabalhar.

O código inteiro está disponível no GitHub: https://gist.github.com/3354394. Para testar, é só baixar o código e carregar no GHCi.

Exemplos reais

Apenas para finalizar, alguns exemplos de aplicativos reais em uso desenvolvidos em Haskell:

Compilador Haskell: The Glasgow Haskell Compiler (GHC)
Frameworks para desenvolvimento web: Yesod, Happstack
Gerenciador de janelas do X: XMonad
Gerenciador de fontes com um conceito novo (teoria de patches): Darcs
Entre outros...

Criando um jogo de labirinto em Haskell

2012-08-12T19:40:00.000-03:00

Quando eu estava aprendendo a programar em C, eu fiz vários pequenos projetos para colocar meu conhecimento à prova.

É muito bom olhar estes códigos antigos e perceber que aprendi muito nestes anos. Também é prazeroso ver que mesmo sem conhecer quase nada, consegui fazer muitas coisas divertidas.

Uma das primeiras coisas que fiz em C, foi um jogo de labirinto para terminal do Windows. Fiquei inacreditavelmente feliz e me achando muito inteligente por conseguir fazer um jogo assim.

Após algum tempo já programando, depois de conhecer a biblioteca SDL para criar jogos gráficos em C, o joguinho de labirinto chegou na sua terceira versão: DuDuRoX.

Como agora estou aprendendo Haskell e quero manter a tradição, irei criar um novo DuDuRoX nesta linguagem: DuDuHoX. Notem a pequena variação no nome demonstrando minha imensa criatividade.

Quem quiser acompanhar o progresso e fazer comentários, todo o código está disponível no GitHub (link no parágrafo acima).

Bastantes coisas já estão funcionando, até já é possível jogar. Quem quiser experimentar, é só baixar a plataforma Haskell, fazer um clone do repositório, executar o comando cabal install na pasta do jogo e ele estará disponível no seu terminal como "DuDuHoX".

Quem quiser dar uma olhada em códigos antigos, meus primeiros passos na programação estão postados no site Viva O Linux:

Jogo da Velha com GOTO: Primeiro código que coloco no site e o primeiro comentário foi muito encorajador: "quem usa goto vai para o inferno".
Jogo da Velha sem GOTO: Quero ver alguém me mandar pro inferno agora... hahaha
Jogo da Velha com I.A. invencível (console): I.A. com força bruta.
Jogo da Velha com I.A. invencível (gráfico): Primeiros contatos com SDL.
Agenda telefônica: Primeiros contatos com alocação dinâmica de memória.

Alguns códigos mais "avançados", acabei não compartilhando, porém tenho eles salvos no meu computador, se alguém se interessar posso compartilhar também:

MultiMines: Jogo de campo minado.
HChess: Jogo de xadrez.
ObjectDetector: Tratador de imagem para realçar as bordas de objetos.
LConv: Conversor de "linguagens", a partir de uma pseudo-linguagem, o usuário conseguia definir regras de criptografia e aplicar a textos.
GATesting: Algoritmo genético para encontrar qualquer formula matemática que trouxesse como resultado o valor informado.

O futuro da programação

2012-07-14T13:53:00.000-03:00

Postado originalmente em Seniortec.

De acordo com o índice TIOBE, em 1996 a linguagem de programação mais utilizada era C. Apenas dez anos mais tarde, em 2006, Java passou a ocupar o primeiro lugar. Por quê?

Com o baixo custo e o fácil acesso a grandes quantidades de memória, a transição de C para Java foi um reflexo natural dos programadores em busca de maneiras mais fáceis de gerenciar este recurso que crescia de maneira muito rápida.

Novamente estamos passando por uma quebra no paradigma computacional. A busca incansável por maior quantidade de ciclos é deixada de lado e da lugar à busca por paralelismo de operações e quantidade de núcleos de processamento.

As linguagens atuais estão preparadas para estas mudanças? Java ainda é bom o suficiente para manter sua hegemonia? Perguntas como estas começam a aparecer em artigos, fóruns, apresentações e congressos de nossa área.

Juntamente com estas perguntas, começa a surgir um interesse súbito por linguagens funcionais, como mostra a mensagem deste mês do índice TIOBE:

"Last month we asked ourselves the question what language could become the next big new programming language. We suggested several candidates such as Scala, Erlang and Clojure. Clearly, the new thing was expected to come from the functional programming field. A functional language not explicitly mentioned was Haskell. And this month it was Haskell that jumped from #35 to #25. Looking at the TIOBE trend graph of Haskell (starting in 2003) it shows a constant rise, with peaks in 2006, 2010 and now in 2012. This certainly sounds promising."

Todo este interesse não é preciosismo de alguns estudiosos. O paradigma funcional puro soluciona de uma forma muito suave a maioria dos problemas encontrados quando tratamos de assuntos de importância fundamental para esta nova arquitetura computacional: concorrência, paralelismo e escalabilidade.

A linguagem Haskell, por exemplo, oferece:

Estruturas de dados persistentes: seguras para ambientes concorrentes.
Operações que envolvem I/O são discriminadas de forma estática pelo sistema de tipos, o que gera uma cultura que preza pela pureza das bibliotecas. Garantindo escalabilidade de forma natural.
Operações que envolvem I/O são modeladas dentro de um conceito puro (Monad), permitindo composição, backtracking, computação não determinística, etc.
Polimorfismo aberto permite uma consolidação de uma única biblioteca e conceito, mesmo que construído de forma incompleta no primeiro release.
Avaliação preguiçosa possibilita um melhor gerenciamento do processamento e localidade em ambientes com escalabilidade.
Multiparadigmas para concorrência e paralelismo: locks, memória transacional, mensageria, filas, tópicos, paralelismo grátis com balanceamento de carga automático e threads baratas.

É fácil notar que Java já percebeu sua deficiência e busca soluções com as liberações novas. Neste ano será feita a liberação do Java 8 com suporte a mecanismos funcionais (projeto Lambda). A Apache decidiu não esperar pela nova versão e já têm a biblioteca Functor para tentar suprir estas necessidades. Assim também fez o Google com adições funcionais à biblioteca Guava.

Para a JVM já existem algumas linguagens tentando manter a plataforma aderente ao novo modelo de computação, por exemplo: Clojure, Groovy e Scala.

E você, está se preparando? Se você ainda não experimentou nenhuma linguagem funcional, te aconselho a ir logo conhecer o que este paradigma oferece. Seguindo o paradoxo de Blub, o ideal é começar com uma linguagem funcional pura, como Haskell, antes de avaliar linguagens como Scala que são híbridas e oferecem o paradigma tradicional.

Haskell Chat

2012-05-15T22:21:00.001-03:00

Este post apresentará um programa simples de bate-papo por Telnet na linguagem Haskell.

Este programa servirá como um servidor de bate-papo, bastando que as pessoas conectem nele para que possam trocar mensagens entre si. As pessoas não precisarão conhecer onde os outros participantes do bate-papo estão na rede, o servidor se encarregará de redirecionar cada mensagem. Ele atuará parecido com um roteador.

As informações trafegadas na rede serão texto puro, tanto do cliente quanto do servidor, sendo assim não é necessário um cliente especial para utilização do serviço de bate-papo. Os clientes poderão se conectar ao servidor utilizando o Telnet.

Cabeçalho

Nosso servidor de bate-papo será um módulo Haskell projetado para rodar como um aplicativo O nome deste módulo será Main:

module Main(main) where

Imports

Para que o bate-papo funcione e possamos enviar informações pela rede, precisamos de acesso à camada de rede do sistema operacional:

import Network

Além disto, precisaremos utilizar controles sobre efeitos colaterais para que possamos atender mais de um usuário ao mesmo tempo:

import System.IO
import Control.Monad
import Control.Concurrent

Para que nosso servidor não ﬁque apenas como um mediador de mensagens, faremos alguns tratamentos aos textos recebidos pelos usuários, por exemplo a utilização de alguns comandos, para isto precisaremos manipular Strings, que nada mais são do que listas de caracteres:

import Data.List

Tipos

Para controlar as informações que serão armazenadas e trafegadas. Iremos deﬁnir alguns tipos para nos ajudar a realizar este controle.

Mensagens

As mensagens trocadas entre usuários nada mais são do que Strings, então esta será nossa deﬁnição de mensagem:

type Message = String

Usuários

Será necessário dinstinguir quem mandou cada mensagem para saber para quem repassar cada mensagem, evitando que o próprio usuário receba sua própria mensagem e para que o bate-papo faça sentido.

Para isto precisaremos de um tipo que represente um usuário do bate-papo e que seja possível compará-lo com outros usuários. Este usuário será identiﬁcado por um nome e, para que seja possível distinguir usuários com o mesmo nome, por um identiﬁcador único.

data ChatUser = ChatUser { 
    userId :: Int, 
    username :: String }
        deriving Eq

Mensagens de bate-papo

A mensagem que recebemos pela rede é texto puro, mas precisamos associá-la ao usuário que fez o envio. Por isto temos um tipo que vincula uma mensagem a um usuário.

data ChatMessage =
    ChatMessage { 
        messageFrom :: ChatUser, 
        messageText :: Message }

E, para que seja possível notiﬁcar sobre a entrada ou saída de algum usuário, iremos declarar também outros dois tipo de mensagens do bate-papo: as mensagens de saída e as mensagens de entrada. As mensagens de saída poderão ter algum texto de despedida do usuário.

| QuitMessage { 
        messageFrom :: ChatUser,
        messageText :: Message }
    | JoinMessage {
        messageFrom :: ChatUser }

Instâncias

Como o servidor irá transmitir apenas texto puro, ao receber uma mensagem de um usuário e repassá-la a outro, será necessário exibir o usuário que enviou a mensagem de forma textual. Para isto declaramos uma instância de Show para nosso tipo ChatUser:

instance Show ChatUser where
    show (ChatUser uid name) = 
        name ++ "(" ++ show uid ++ ")"

Também será necessário trafegar os diferentes tipos de mensagens na forma de texto puro pela rede:

instance Show ChatMessage where
    show (ChatMessage user message) =
        show user ++ ": " ++ message
    show (QuitMessage user message)
        | null message =
            "! " ++ show user ++ " saiu."
        | otherwise =
            "! " ++ show user ++ " saiu: " ++ message
    show (JoinMessage user) =
        "! " ++ show user ++ " entrou."

Main

Porta de comunicação

Nosso bate-papo tem como principal objetivo funcionar via Telnet, então para isto faremos com que o servidor escute na porta 23, que é a porta padrão utilizada pelo Telnet.

port :: PortID
port = PortNumber 23

Identificação dos usuários

O identiﬁcador único de cada usuário será determinado pela ordem de chegada no servidor, i.e. o primeiro usuário terá o identiﬁcador 1, o segundo terá o identiﬁcador 2, e assim por diante.

Suportando múltiplos usuários

Para que nosso servidor não ﬁque travado lidando com apenas um usuário, iremos criar Threads para lidar com cada usuário de forma concorrente.

Ao receber uma mensagem de um usuário, a Thread responsável por aquela conexão terá que repassar esta informação às demais, para isto utilizaremos um canal de envio e recebimento de mensagens que será compartilhado entre todas as Threads.

Este canal funciona como um tópico, quando alguém escreve nele, todos que estiverem escutando irão receber a mensagem. Assim será possível que a Thread lidando com outro usuário receba esta mensagem através deste canal de comunicação e repasse ao cliente.

Porém, se utilizarmos apenas uma Thread por cliente, esta só teria a chance de ler deste canal de comunicação depois do cliente enviar alguma mensagem. Pois a Thread ficaria bloqueada esperando por uma escrita no Socket.

Para evitar este problema, serão utilizadas duas Threads por cliente: uma responsável pelo recebimento de mensagens e outra responsável pelo envio.

Main

Nosso servidor iniciará deﬁnindo o número inicial de conexões (userCount), criando um canal de comunicação (chan), abrindo um Socket para escutar na porta deﬁnida anteriormente (socket) e aguardando conexões.

main :: IO ()
main = withSocketsDo $ do
         let userCount = 0
         chan <- newChan
         socket <- listenOn port
         handleConnections socket userCount chan

Aceitando conexões

Ao receber uma conexão, precisamos manter o handle para realizar a leitura e escrita de mensagens. Desligamos o buffer para que as mensagens sejam trocadas em tempo real.

Após deﬁnida a conexão, precisamos liberar nosso servidor para que possa atender outros usuários, então será criado um processo concorrente que atenderá esta conexão. O identiﬁcador único do usuário será deﬁnido no processo principal para evitar que dois usuários tenham o mesmo identiﬁcador.

handleConnections :: Socket -> 
                     Int -> 
                     Chan ChatMessage ->
                     IO ()
handleConnections socket userCount chan = do
    (socketHandle, _, _) <- accept socket
    hSetBuffering socketHandle NoBuffering
    let nextUser = (userCount + 1)
    _ <- forkIO $
      handleUserConnection chan socketHandle nextUser
    handleConnections socket nextUserNumber chan

Atendendo uma conexão

Para iniciar o atendimento à uma conexão, precisamos inicialmente do nome do usuário.

handleUserConnection :: Chan ChatMessage ->
                        Handle ->
                        Int ->
                        IO ()
handleUserConnection chan socketHandle userNumber = do
    name <- readUsername socketHandle

Com o nome do usuário e o identificador único fornecido pelo processo principal do servidor, conseguimos definir o usuário desta conexão e enviar uma mensagem ao canal de comunicação informando que o usuário entrou no bate-papo.

let thisUser = ChatUser userNumber name
    broadcast chan $ JoinMessage thisUser

Para que este usuário comece a receber as mensagens do bate-papo, criamos uma Thread separada para efetuar a leitura do canal de comunicação:

chanReader <- dupChan chan
    readerThread <- forkIO $
      startReader chanReader socketHandle thisUser

Este processo irá efetuar a escrita do canal de comunicação a partir das mensagens recebidas pelo Socket do cliente. O resultado deste processo, será uma mensagem de saída do usuário, caso ele deixe alguma. Caso ele desconecte sem deixar nenhuma mensagem, a exceção será capturada e convertida em uma mensagem vazia de despedida do usuário.

quitMessage <- (startSender chan 
                            socketHandle thisUser)
                            `catch` (\_ -> return "")

Com a mensagem de despedida em mãos, informamos os demais usuários que este deixou o bate-papo. Encerramos a Thread responsável por fazer a leitura do canal de comunicação e fechamos a conexão com o cliente:

broadcast chan $ QuitMessage thisUser quitMessage
    killThread readerThread
    hClose socketHandle

Recebendo o nome do usuário

Para receber o nome do usuário, apenas enviamos uma mensagem pedindo que ele informe seu nome e fazemos a leitura do Socket:

readUsername :: Handle -> IO String
readUsername socketHandle = do
    hPutStr socketHandle "Informe seu nome: "
    readLine $ socketHandle

Recebendo mensagens do canal de comunicação

O processo responsável por receber as mensagens do canal de comunicação só será encerrado com a desconexão do usuário, então ele sempre deve estar lendo do canal e publicando ao usuário. O próprio usuário irá enviar mensagens para o canal de comunicação, para evitar que ele receba mensagens dele mesmo, é aplicado um filtro para que só sejam exibidas mensagens de usuários diferentes dele.

startReader :: Chan ChatMessage ->
               Handle ->
               ChatUser ->
               IO ()
startReader chanReader socketHandle thisUser =
    forever $ do
        message <- readChan chanReader
        when ((messageFrom message) /= thisUser) $
            display message socketHandle

Enviando mensagens ao canal de comunicação

O processo responsável por enviar mensagens ao canal de comunicação deverá terminar de alguma forma. Seja por desconexão do usuário ou por uma mensagem de despedida do mesmo.

Para que o usuário saia do bate-papo, basta que ele envie uma mensagem iniciando com /quit seguido de sua mensagem de despedida. As demais mensagens recebidas do usuário serão repassadas ao canal de comunicação e não encerrarão o processo.

startSender :: Chan ChatMessage ->
               Handle ->
               ChatUser ->
               IO String
startSender chan socketHandle thisUser = do
    line <- readLine socketHandle
    if "/quit" `isPrefixOf` line
        then return . dropWhile (== ' ') $ drop 5 line
        else do
             broadcast chan $
                 ChatMessage thisUser line
             startSender chan socketHandle thisUser

Utilitários

Notificando os processos responsáveis por cada usuário

Para enviar uma mensagem a todos os usuários, basta realizar uma escrita no canal de comunicação.

broadcast :: Chan ChatMessage -> ChatMessage -> IO ()
broadcast = writeChan

Enviando mensagens para um usuário

Para enviar uma mensagem a um usuário, escrevemos a mensagem no Socket seguida de uma quebra de linha no formato Windows, para que a utilização via Telnet seja agradável.

display :: ChatMessage -> Handle -> IO ()
display message socketHandle = do
    hPutStr socketHandle (show message ++ "\r\n")
    hFlush socketHandle

Lendo mensagens de um usuário

Para ler uma mensagem do usuário, lemos uma linha do Socket e removemos o retorno do carro, para que ﬁque apenas a mensagem escrita por ele.

readLine :: Handle -> IO String
readLine = liftM (filter (/= '\r')) . hGetLine

Código completo

O código completo está disponível no GitHub com a descrição Sample telnet chat in Haskell.

Sobrevivente.run()

2012-04-03T22:07:00.000-03:00

Como sobreviver sem repetição de código no reino dos substantivos?

O que fazer quando encontramos código deste tipo:

A.java

Button button = new Button("Limpar");
button.addActionListener(new ActionListener() {
  public void performAction() {
    if (foo) {
      askConfirmation();
      bar.clear();
    }
  }
});

B.java

Button button = new Button("Limpar");
  button.addActionListener(new ActionListener() {
    public void performAction() {
      if (bacon) {
        askConfirmation();
        eggs.clear();
      }
    }
});

C.java

Button button = new Button("Limpar");
button.addActionListener(new ActionListener() {
  public void performAction() {
    if (baz) {
      askConfirmation();
      spam.clear();
    }
  }
});

Meu jeito é criar um verbo disfarçado de substantivo que leva consigo a ação que eu quero:

interface MagicClearWord {
  boolean isDirty();
  void clear();
}
class MagicClearWordExecutor implements ActionListener {
  private final MagicClearWord e;
  MagicClearWordExecutor(MagicClearWord e) {
    this.e = e;
  }
  public void performAction() {
    if (e.isDirty()) {
      askConfirmation();
      e.clear();
    }
  }
}

E depois utilizar como se fosse um "substantivo anônimo" (~~#nonsense~~):

A.java

Button button = new Button("Limpar");
button.addActionListener(new MagicClearWordExecutor(
  new MagicClearWord() {
    public boolean isDirty() {
      return foo;
    }
    public void clear() {
      bar.clear();
    }
  })
);

B.java

Button button = new Button("Limpar");
button.addActionListener(new MagicClearWordExecutor(
  new MagicClearWord() {
    public boolean isDirty() {
      return bacon;
    }
    public void clear() {
      eggs.clear();
    }
  })
);

C.java

Button button = new Button("Limpar");
button.addActionListener(new MagicClearWordExecutor(
  new MagicClearWord() {
    public boolean isDirty() {
      return baz;
    }
    public void clear() {
      spam.clear();
    }
  })
);

Ainda assim os substantivos e seus amigos gulosos comem seu tempo e seu espaço em disco com tanta palavra vazia. Parece que estamos presos mesmo.

Oh God, why?

Almoço grátis de paralelismo em Haskell

2012-03-13T21:12:00.000-03:00

Hoje irei exagerar um pouco e verificar o quão grátis é o almoço de paralelismo servido pelo ecossistema Haskell.

Para fins de estudo, irei criar um algoritmo bastante simples e ideal para utilizar paralelismo: duas funções distintas com cargas de trabalho parecidas que não possuem dependência entre si.

Uma destas funções calculará qual é o menor valor de uma lista e a outra calculará o maior valor. Sendo assim, as duas precisarão consultar todos os elementos da lista e fazer a mesma quantidade de comparações. Os dois valores serão somados e impressos ao usuário:

module Main where

import Data.List (foldl1')

main = print result
  where result = a + b
        a = foldl1' min list
        b = foldl1' max list
        list = [1..19999999]

Compilei o código com ghc -rtsopts e executei ele com +RTS -s para verificar como ele se comportou:

20000000
     803,172,764 bytes allocated in the heap
     860,135,516 bytes copied during GC
     233,464,876 bytes maximum residency (9 sample(s))
      30,086,296 bytes maximum slop
             483 MB total memory in use (0 MB lost due to fragmentation)

  Generation 0:  1523 collections,     0 parallel,  0.80s,  0.97s elapsed
  Generation 1:     9 collections,     0 parallel,  0.92s,  1.30s elapsed

  INIT  time    0.00s  (  0.00s elapsed)
  MUT   time    0.90s  (  0.98s elapsed)
  GC    time    1.72s  (  2.27s elapsed)
  EXIT  time    0.00s  (  0.00s elapsed)
  Total time    2.62s  (  3.25s elapsed)

  %GC time      65.5%  (69.8% elapsed)

  Alloc rate    887,674,003 bytes per MUT second

  Productivity  34.5% of total user, 27.8% of total elapsed

Esta saída significa que o programa levou 3,25 segundos para executar e ocupou 483 MB de memória. Um valor um tanto absurdo para algo que deveria ser simples e rápido em Haskell. O problema do algoritmo é que durante o cálculo do valor mínimo, o coletor de lixo não coleta os itens já passados pois o cálculo do valor máximo possui referência para o inicio da lista.

Para resolver o problema é possível gerar listas diferentes, uma para cada cálculo na forma de uma função constante:

module Main where

import Data.List (foldl1')

main = print result
  where result = a + b
        a = foldl1' min $ list ()
        b = foldl1' max $ list ()
        list _ = [1..19999999]

Esta versão termina em 1,6 segundos e consome apenas 1 MB de memória. Atenção: se o programa for compilado com -O2, o GHC irá otimizar a declaração de função deixando a referencia para a lista no lugar e o programa continuará a usar os 483 MB de memória.

Este é o momento de refatorar o algoritmo para evitar duplicidade de código. Para um programa deste tamanho, acredito que normalmente não é feito, porém para que a transição para a utilização de paralelismo fique mais suave, é um passo necessário:

module Main where

import Data.List (foldl1')
import Control.Arrow ((&&&))

main = print result
  where result = (+) `uncurry` constMinMax list
        list _ = [1..19999999]

(.:) f g a b = f a (g b)
constApp = ($ ())
constMinMax = constMinList &&& constMaxList
constFold = foldl1' .: constApp
constMinList = constFold min
constMaxList = constFold max

O resultado e o tempo do algoritmo continuam os mesmos. Agora como tornamos este algoritmo preparado para rodar em paralelo? Simples: trocamos a utilização da função uncurry por parUncurry:

module Main where

import Data.List (foldl1')
import Control.Arrow ((&&&))
import Control.Parallel (par, pseq)

main = print result
  where result = (+) `parUncurry` constMinMax list
        list _ = [1..19999999]

(.:) f g a b = f a (g b)
constApp = ($ ())
constMinMax = constMinList &&& constMaxList
constFold = foldl1' .: constApp
constMinList = constFold min
constMaxList = constFold max
parUncurry f (a, b) = a `par` b `pseq` f a b

Adicionamos à compilação do programa o argumento -threaded e para executar utilizamos +RTS -s -N2 para que o programa utilize duas threads do sistema operacional. O resultado:

20000000
   1,606,300,044 bytes allocated in the heap
          74,364 bytes copied during GC
          28,352 bytes maximum residency (1 sample(s))
          24,896 bytes maximum slop
               2 MB total memory in use (0 MB lost due to fragmentation)

  Generation 0:  1566 collections,  1565 parallel,  0.06s,  0.02s elapsed
  Generation 1:     1 collections,     1 parallel,  0.00s,  0.00s elapsed

  Parallel GC work balance: 1.79 (15355 / 8588, ideal 2)

                        MUT time (elapsed)       GC time  (elapsed)
  Task  0 (worker) :    0.00s    (  0.81s)       0.00s    (  0.00s)
  Task  1 (worker) :    0.75s    (  0.81s)       0.06s    (  0.01s)
  Task  2 (bound)  :    0.83s    (  0.81s)       0.00s    (  0.00s)
  Task  3 (worker) :    0.00s    (  0.00s)       0.00s    (  0.00s)

  SPARKS: 1 (1 converted, 0 pruned)

  INIT  time    0.00s  (  0.00s elapsed)
  MUT   time    1.58s  (  0.81s elapsed)
  GC    time    0.06s  (  0.02s elapsed)
  EXIT  time    0.00s  (  0.00s elapsed)
  Total time    1.64s  (  0.83s elapsed)

  %GC time       3.8%  (1.9% elapsed)

  Alloc rate    1,019,478,198 bytes per MUT second

  Productivity  96.2% of total user, 189.6% of total elapsed

gc_alloc_block_sync: 78
whitehole_spin: 0
gen[0].sync_large_objects: 0
gen[1].sync_large_objects: 0

Conseguimos reduzir o tempo de execução para 0,83 segundos: a metade do tempo da versão sequencial. Tudo isto com a mudança de uma chamada (partindo do principio de que o programa está bem escrito).

Qual seria o tamanho da mudança necessária na linguagem que você utiliza hoje para ter este mesmo ganho de desempenho?

Apesar do exemplo deste post ser levemente exagerado, este tipo de ganho com apenas uma mudança é algo real em Haskell. A apresentação The Future is Parallel, and the Future of Parallel is Declarative feita por Simon Peyton Jones dá exemplos de aplicações que se beneficiaram deste paralelismo grátis.

Convenções e obrigações

2012-03-02T22:18:00.000-03:00

Aviso. Este post apenas levanta algumas questões sem oferecer nenhuma resposta, apenas sugestões.

Na programação orientada a objetos, os principios SOLID são bem difundidos. São cinco principios reunindo boas práticas em forma de convenções que tornam a programação orientada a objetos melhor, porém não são exigências do paradigma, i.e. os principios melhoram a vida e deveriam ser aplicados, mas não existe maneira de assegurar que eles foram. São eles:

Single responsibility principle (SRP): Cada classe deve ter apenas uma responsabilidade e apenas uma razão para que ela sofra mudanças.
Open/closed principle (OCP): As classes devem estar abertas para extensão e fechadas para modificações. Funcionalidades são adicionadas ao sistema através de código novo e não através de modificações de código existente.
Liskov substitution principle (LSP): Uma classe só pode ser subclasse de outra se o funcionamento do código que utilize esta hierarquia não for alterado ao substituir uma pela outra. Isto é, se uma função depende de uma coleção de objetos, não importa se o argumento é uma lista ou uma árvore, o resultado deve ser o mesmo.
Interface segregation principle (ISP): Contratos devem ser resumidos, funções devem depender de contratos que reflitam apenas sua necessidade e nada mais. Vários contratos pequenos são melhores do que um alguns contratos grandes.
Dependency inversion principle (DIP): Métodos devem depender de contratos e não de tipos concretos.

Além destes existe um principio que vale para todos os paradigmas: "Don't repeat yourself" (DRY). O nome deste é bem intuitivo: não repita código.

Apesar de todas estas convenções serem boas, todas elas possuem a mesma falha: são convenções. Convenções são facilmente esquecidas, postergadas e até mesmo ignoradas. Nem todos os programadores possuem o mesmo nível de apreço pelo código produzido. O respeito a cada uma das convenções é medido de forma qualitativa e não quantitativa. Não existe fornecimento de segurança apenas utilizando convenções.

Esta falta de segurança resulta em dividas técnicas para as bases de código. O sistema inteiro vira um espagueti, quanto mais o código é trabalhado, mais enrolado ele fica.

Assim como utilizamos equipamentos de segurança para garantir a integridade de algum objeto ou entidade, por que não asseguramos a integridade de nossas bases de código? Fábricas de software asseguram a integridade do ambiente de trabalho utilizando catracas, cancelas, guaritas, etc. Mas utilizam o quê para assegurar a integridade do seu produto (código)? Sistemas de controle de versão apenas garantem a versão atual do seu sistema caso uma cagada colossal aconteça em uma versão futura.

Dividas técnicas custam caro no fechamento das contas: quanto mais espagueti o código está, mais tempo e empenho serão gastos para novas funcionalidades e correções. Então por quê não previnimos isto de alguma forma? Como poderíamos prevenir?

Recentemente li o artigo Why Concatenative Programming Matters de Jon Purdy e notei a ligação direta entre o paradigma de programação concatenativa e o principio DRY. Pelo fato da programação concatenativa ser livre de contexto, é possível eliminar todo código duplicado com um simples find/replace. Sendo assim, este é o paradigma de programação ideal para que o principio DRY seja aplicado. É possível que o próprio compilador dê sugestões para eliminar ou obrigue a eliminação de repetições no código, garantindo um código melhor para todos.

Com a leitura do artigo de Jon Purdy, comecei a ponderar sobre as questões lançadas neste post e percebi que as type classes da linguagem Haskell se encaixam como uma solução brilhante para OCP. Elas permitem que contratos sejam definidos de forma aberta, aceitando extensões de forma fácil e com garantia em tempo de compilação (nada de monkey patching).

Se olharmos as type classes, podemos perceber que elas sempre abstraem um único tipo de dado e suas funções. Garantindo coesão de código e o cumprimento da convenção ISP, pois cada type class se restringe a um tipo de operação.

A linguagem Haskell possui inferencia de tipos, o que permite que o compilador produza assinaturas dos tipos mais abstratos possíveis, garantindo o cumprimento da DIP de forma automática.

Sobre a LSP, acredito que linguagens como Coq podem garantir o cumprimento desta convenção. Porém, não me aventurei muito sobre este tipo de linguagem ainda, então não posso garantir. Mas vale a pena dar uma verificada no assunto.

tl;dr Convenções podem ser checadas de forma estática:

DRY: Concatenative programming.
OCP & ISP: Haskell type classes.
DIP: Haskell type inference.
LSP: Coq.

Levando o conhecimento de Haskell para Java

2012-02-29T21:01:00.000-03:00

Resgatando o blog e trocando um pouco o tema para falar sobre programação.

Existem muitos tutoriais sobre orientação a objetos e desenvolvimento orientado por testes (TDD) pela internet. Grande parte se utiliza de um exemplo simples: uma calculadora.

Para desenvolver a calculadora, demonstram o poder do polimorfismo construindo abstrações sobre operações binárias e a utilidade do TDD através de uma programação incremental.

Neste post tentarei extender este exemplo de calculadora, porém focando em outro ponto do problema: a interação com o usuário.

Os exemplos estão na linguagem orientada a objetos mais utilizada do planeta: Java.

Programa: Calculadora para terminal.
Requisito: Ler cálculos no formato "2 + 2" e informar o usuário sobre o resultado do cálculo: "4".
Problema: Como testar a interação com o usuário?

Por ser um programa feito para rodar em terminal, utilizaremos System.in e System.out para interagir com o usuário. Porém, se amarrarmos o algoritmo de cálculo diretamente à estes recursos, ficará muito difícil e não-produtivo criar e manter testes para este sistema.

Algo importante que aprendi com a linguagem Haskell é a de separar o código em áreas puras e impuras. Uma área de código pura é um conjunto de funções que dependem apenas de seus argumentos e só produzem um resultado, i.e. funções que não alteram nenhuma informação e dependem apenas de seus argumentos. A área de código impura é aquela composta pelas demais funções que dependem de I/O, alterações na memória, banco de dados, etc.

A linguagem Haskell faz um trabalho incrível para assegurar que esta distinção seja mantida pelos programadores através do seu sistema de tipos que diferenciam funções puras e funções impuras. Nas linguagens tradicionais, como Java, não existe esta distinção: todo pedaço de código tem a liberdade de ser impuro. Desta forma, os programadores devem sempre prestar atenção para o que cada parte do código está executando.

Para separar a parte "pura" e "impura" da nossa calculadora, precisamos primeiro identificar quais funções pertencem a cada parte.

Toda a parte de código que realiza o cálculo pode se encaixar perfeitamente na área de código pura, afinal são apenas representações para funções matemáticas, que são puras por definição.

Por outro lado, a parte que faz a interação com o usuário é impura, pois altera informações que vão além de seu alcance em termos de código: imprime caracteres no terminal, e recebe informações que vão além de seus argumentos: teclas pressionadas pelo usuário.

A parte impura do código é muito difícil de ser testada e por isto deve ser mantida reduzida e de forma controlada, que faça apenas o necessário para o funcionamento. No caso da calculadora para terminal, a parte impura é apenas interação com o usuário no seguinte formato:

Usuário digita um texto.
Programa responde com outro texto.
Volte para 1.

Esta interação é abstrata o suficiente para ser totalmente separada da parte que realiza o processamento. Por exemplo, o seguinte código encapsularia toda a parte impura da nossa calculadora:

public interface Programa {
  String processar(String entrada);
}

public class InteracaoTerminal {
  public void interagir(Programa programa) {
    Scanner s = new Scanner(System.in);
    while (true) {
      String entrada = s.nextLine();
      String saida = programa.processar(entrada);
      System.out.println(saida);
    }
  }
}

Desta forma a interface Programa é 100% testavel, por exemplo:

assertEquals("4", programa.processar("2 + 2"));
assertEquals("6", programa.processar("2 + 2 * 2"));

Além de testavel, a implementação da nossa calculadora apenas manipulará Strings, sem dependência direta com o System. Isto significa que poderemos aproveitar o código em outros lugares, quem sabe utilizar o mesmo código para duas interfaces diferentes: uma interage com o usuário através de um terminal e outra através de um aplicativo gráfico.

A abstração colocada como exemplo tem uma limitação: cada interação com o usuário é feita através de uma linha de entrada e uma linha de saída. Deixo como exercício aprimorar esta abstração para que seja possível ter mais de uma linha de entrada e mais de uma linha como saída de uma única interação. Se você conhece Haskell, poderá se basear na função interact, e se você não conhece: Aprender Haskell será um grande bem para você!

Mendigos...

2009-02-11T11:25:00.001-02:00

Por que o mendigo é mendigo?
Desde quanto ele é mendigo?
Tornou-se mendigo ou sempre foi?
De onde vem o mendigo?
Onde estão seus pais?
Escolheu ser mendigo?
É bom ser mendigo?
Mendigo tem mais liberdade que nós?
Até quanto posso justificar minha falta de vida pela aquisição de bens materiais?
Quem vive mais, eu ou o mendigo?
Será que não sou também um mendigo?
Por que eu não sou um mendigo?
Eu escolhi não ser um mendigo?
Escolheram por mim?
O que me torna diferente do mendigo?
Eu precisei me esforçar para não ser um mendigo?
Quem sou eu para julgar o que não vivi?

Equilibrio

2009-02-01T19:56:00.000-02:00

Se 1 ganha, 1 perde.
Se 2 ganham, 2 perdem.
Se tudo ganha, tudo perde.
Se nada ganha, nada perde.
Quem não ganha, não faz outro perder.
Quem perde, faz outro ganhar.

Ganhar, ganhar, ganhar, ganhar...
Fazer perder, fazer perder, fazer perder, fazer perder...

O que você quer?