Arquivo do mês: maio 2014

SmallFBP: a Smalltalk framework for Flow-Based Programming – Part 2

filter

Ciência, arte e filosofia se vão fundindo tanto em mim que algum dia certamente vou parir um centauro – Nietzsche.

  1.  Introdução
  2. Flow-Base Programming
    1. Component
    2. Port
    3. Information Packet (IP)
    4. Connection
    5. Network
    6. Initial Information Packet (IIP)
  3. Exemplo: Filter
    1. OddFilter
    2. MaxNumberIIP
    3. Numbers
    4. Printer
    5. Filter GUI
  4. Portas automáticas
    1. Introdução
    2. Exemplo: Writer e Reader
    3. Usando displays com portas automáticas
    4. Usando portas automáticas no exemplo Filter
  5. Componentes compostos
    1. Introdução
    2. Subnet
    3. Composição
  6. Flow-Based Programming IDE
    1. Introdução
    2. Arquitetura
    3. Protótipo
  7. Flow-Based Programming IDE II
    1. Introdução
    2. Odd filter
  8. Flow-Based Programming IDE – III
    1. Introdução
    2. Writer e Reader

Flow-Base Programming

Flow-Based Programming envolve basicamente usar uma miríade componentes ativos (processos ou threads) que ficam esperando dados em suas portas de entrada, transformando os dados recebidos e enviando através de suas portas de saída. Cada componente só interage com suas portas de entrada e saída e dorme até que “batam a sua porta”. Isto é, quando há algum pacote para processar nas portas de entrada. Internamente pode delegar a subcomponentes “ouvir” cada porta. Subcomponentes e subnetwork podem representar um esquema de “bonecas russas”. A implementação interna pode ser baseada em componentes em várias camadas até atingir componentes atômicos, que são implementados sem o uso de outros componentes. Externamente os componentes são conectados numa rede que interliga suas portas de entrada e saída. Os sistemas desenvolvidos assim poderiam ser chamados de o laço eterno. Na verdade muitos laços.

Conceitos

Component

component

Componente (component) é um dos principais ingredientes em flow-based programming. É um módulo que fornece uma transformação/triagem de pacotes  recebidos de portas de entrada e que são enviados para portas de saída. Os pacotes não enviados são descartados explicitamente. Estas portas são utilizadas para ligar os componentes uns aos outros.

Um componente, ao ser criado, pode iniciar imediatamente um laço perene onde “escuta”, em estado “dormente” (sem consumir ciclos de CPU) as portas (waiting). Quando há pacotes enfileirados  numa porta de entrada o componente “acorda” (passando a consumir CPU) e eles são removidos repetidamente e enviados para portas de saída ou então são descartados explicitamente. Pacotes também podem ser gerados no componente e enviados para portas de saída.

Um componente pode conter componentes internos criados no seu interior mas não devem compartilhar componentes (instâncias).

As classes dos componentes são subclasses de Component. Component fornece alguns métodos de apoio e obriga o override do laço de execução. Veja abaixo algumas partes código:

component-class

O código em Smalltalk acima cria uma classe FBPComponent que servirá de superclasse para toda classe de componente. Na linha 2 são declaradas duas variáveis de instância. outputPorts se refere às portas de saída que serão armazenadas num dicionário (Instância da classe Dictionary). inputPorts também é um dicionário e se refere às portas de entrada do componente. Os dicionários (hash tables) permitem recuperar uma porta pelo seu nome. Dois métodos do componente são bastante usados na implementação do laço infinito nas subclasses: FBPComponente>>#send:to: FBPComponente>>#receiveFrom:.

send-to

O método tem dois parâmetros: o packet a ser enviado e o símbolo da porta de saída. Um exemplo de uso poderia ser:

using-send-to

O outro método é usado para receber pacotes numa porta:

receive-from

Exemplo de uso:

using-receive-from

As mensagens #next e #nextPut: que aparecem nas implementações dos métodos acima correspondem a métodos para manipular a estrutura de dados que representa uma fila. #next retorna o primeiro pacote da fila e o remove. #nextPut: coloca o pacote no final da fila. A fila representa a conexão e é o único objeto que é compartilhado entre dois componentes (um para cada conexão). Este modelo é comumente chamado de producer-consumer problem.

Nota: Os tratamentos de erros serão omitidos para tornar o código mais legível exceto quando o foco for o próprio tratamento de erros.

Port

ports   As portas (ports) podem ser de entrada (input port) ou de saída (output port). representam as extremidades de uma conexão (connection). As portas de um mesmo componente devem ter nomes distintos. As portas são identificadas com símbolos do Smalltalk (symbol). Um symbol é uma forma econômica de usar strings que tem uma única instância e são reutilizadas sem necessidade de duplicar o uso da memória como pode acontecer com strings. #IN e #OUT são exemplos de símbolos.

Na implementação atual não existe algo como uma classe Port da qual as portas sejam instâncias. No tópico Connection abaixo a implementação do conceito fica clara. Em uma versão futura caso se necessite uma semântica em que a existência de uma classe Port facilite as coisas ela pode ser introduzida.

Information Packet (IP)

Os pacotes (packets) são as unidades de informação (IP – Information Packet) que são processadas no interior dos componentes, recebidas nas portas de entrada ou descartados explicitamente. Podem também carregar programas (pattern strategy) ou serem visitantes (pattern visitor). Quando carregando informação é recomendado que sejam imutáveis (immutable) e impossíveis de serem copiados (unclonable) em alguns casos. Pacotes podem ser criados internamente para serem enviados através das portas de saída.

A implementação de IP é feita através de uma classe FBPInformationPacket:

IP-class

A propriedade content de um InformationPacket referencia o conteúdo de dados carregado pelo packet.

O método de criação requer que o contéudo seja fornecido:

IP-creation

Um exemplo de uso pode ser visto abaixo:

using-IP-creation

O código acima cria um packet que irá transportar o número inteiro 10. Um pacote pode, em princípio, transportar qualquer objeto.

Connection

connection As conexões (connections) são a únicas ligações entre os componentes. São unidirecionais e formam uma rede com os componentes (network) que pode ser vista como um grafo direto (direct graph). Nada mais são do que filas (queue ou FIFO – First In First Out) com capacidade limitada (bounded buffer). Enviar um pacote para a porta de saída equivale a colocá-lo no final da fila. Receber um pacote de uma porta de entrada equivale a retirá-lo do início da fila. O processo/thread do componente fica bloqueado (com a execução suspensa – suspended) quando tenta receber um pacote de uma porta de entrada acoplada a uma fila vazia ou quando tenta enviar um pacote para uma porta de saída acoplada a uma fila no limite da capacidade. Os processos/threads são acordados (resume) quando as filas deixam de ser vazias ou se tornam ocupadas aquém da capacidade máxima. Isto acontece quando no outro extremo da conexão um pacote é enviado ou recebido a depender porta em questão ser de entrada ou de saída.

Network

filter-diagram

A rede (network) é composta de componentes (nós de um grafo) e conexões (arestas de um grafo). Pode ser representada por um grafo direto (direct graph), onde as arestas são unidirecionais, isto é, os pacotes fluem sempre numa mesma direção em cada aresta. A rede é configurada conectando-se uma porta de saída de um componente a uma porta de entrada de outro componente. Uma conexão não pode ter suas extremidades no mesmo componente. Várias conexões de saída de um componente podem ser conectadas a uma mesma porta de entrada de outro componente mas o inverso não pode ser feito (uma porta de saída conectada a várias portas de entrada de outro componente) pois implicaria numa repetição do envio de um pacote pela mesma porta. Um pacote enviado não deve ser mais usado num componente (afinal ele deu “tchau”e saiu pela porta). Várias regras limitadoras são impostas como disciplina de programação (em alguns casos travas podem ser programadas ) visando imitar o que ocorre com os objetos no mundo físico e permitir uma raciocínio mais intuitivo sobre a correção das implementações. A implementação no estágio corrente consta de uma classe Network com um método para instalar uma conexão.

O código abaixo conecta os componentes em um exemplo que será usado mais adiante e será melhor explicado depois. Por agora é bem provável que a sua intuição esteja certa sobre o que ele faz graças a excelente legibilidade do Smalltalk que permite escrever código na forma de uma DSL facilmente.

network-config

Initial Information Packet (IIP)

filter-diagram

IIP é um componente (preliminarmente pelo menos). Mas possui só portas de saída. É usado para iniciar valores geralmente de configuração. O diagrama no topo dos post omite os IIP. Acima mostramos o diagrama completo (o mesmo já mostrado no tópico Network).   O diagrama acima é base de um dos exemplos que será mostrado em posts futuros e então os detalhes serão explicitados.

As redes (networks) de componentes cujas figuras aparecem neste post já foram esboçadas no paper On the Architectural Requirements of an Engineered System, de Nate Edwards. O diagrama mostra as conexões como filas e lembra um pouco um sistema hidráulico com lugares (as filas) para acúmulo de fluido e os componentes como se fossem válvulas. Veja a sugestiva figura abaixo:

nate-edwards-paper-fig-6

Pinóquio no Fantástico de 25/5/2014

Um programa que dá o que pensar…

SmallFBP: a Smalltalk framework for Flow-Based Programming

filter

Ciência, arte e filosofia se vão fundindo tanto em mim que algum dia certamente vou parir um centauro – Nietzsche.

  1.  Introdução
  2. Flow-Base Programming
    1. Component
    2. Port
    3. Information Packet (IP)
    4. Connection
    5. Network
    6. Initial Information Packet (IIP)
  3. Exemplo: Filter  
    1. OddFilter
    2. Numbers
    3. MaxNumberIIP
    4. Printer
    5. Dropper
  4. Portas automáticas
    1. Introdução
    2. Exemplo: Writer e Reader
    3. Usando displays com portas automáticas
    4. Usando portas automáticas no exemplo Filter
  5. Componentes compostos
    1. Introdução
    2. Subnet
    3. Composição
  6. Flow-Based Programming IDE
    1. Introdução
    2. Arquitetura
    3. Protótipo
  7. Flow-Based Programming IDE II
    1. Introdução
    2. Odd filter
  8. Flow-Based Programming IDE – III
    1. Introdução
    2. Writer e Reader

Introdução

Panta rhei (Panta rhei) – Tudo flui.
Heráclito

A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it.

Max Planck

Há algum tempo li que Javascript seria a linguagem do futuro. Recentemente fui investigar isto (por causa de uma prévia experimentação com o CouchDB que usa Javascript para programar as funções map e reduce) e comecei a ler e experimentar com o Javascript (aproveitei meus dias de “minguinho” quebrado). Antes ficava resistente por achar chato ter que ficar inserindo código numa página HTML para testá-lo. Lendo sobre o Node JS acabei me convencendo que a sua CLI seria uma boa opção para testar o Javascript sem ter também que lidar com a DOM do web browser. Lendo o livro Node In Action, no capítulo que aborda as dificuldades de sequenciar ou coordenar ações assíncronas no Node, ao ler sobre os vários frameworks que auxiliam nesta tarefa me deparei com o NoFlo JS.

Quando vi aquilo e li um pouco sobre Flow-Based Programming pensei “é agora que vou parir um centauro!”. Mantida a adequada distância do ilustre filósofo, agora sendo comemorado nos seus 170 anos, lembrei logo das minhas frustradas tentativas (por falta de tempo e motivação) de codificar algo em Smalltalk (minha plataforma preferida para prototipagem rápida e pesquisas em Engenharia de Software – como testemunham alguns posts neste blog) em relação à Hexagonal ou Onion Arquitecture. A idéia de programação com componentes reutilizáveis generalizados, promessa acalentada no advento das linguagens orientadas a objeto mas parcialmente cumprida, pareceu encontrar um caminho promissor – digo isto mas me lembrando que John Paul Morrison, da IBM do Canadá, criou o conceito há mais de 40 anos e usou com sucesso num banco (há um comentário dele relatando como a IBM não fez questão de patentear o conceito de alguma forma. Veja a citação abaixo.). CORBA, SOA e afins trilharam ou tentam trilhar ainda esta senda no meio de abissais complicações.

The idea was so obvious that IBM declined to patent the new approach, calling it “much more like a law of nature” than a new invention, according to Morrison. Instead, the company published FBP as a technical disclosure bulletin, effectively making it public domain. And yet, except for a few rare applications like the Canadian bank, it never really caught on.

How An Arcane Coding Method From 1970s Banking Software Could Save The Sanity Of Web Developers Everywhere

John Paul Morrison, em seu livro sobre Flow-Based Programming, comenta sobre sua visão a respeito das técnicas de prototipação. Como eu gosto de prototipação em Engenharia de Software (por isso gosto do Smalltalk) resolvi traduzir o trecho que coloco abaixo:

A prototipagem rápida e a idéia relacionada de desenvolvimento iterativo foram ( e ainda são) outro entusiasmo dos meus. A prototipagem rápida é um processo de redução das incertezas no processo de desenvolvimento , tentando coisas. Eu acredito que qualquer coisa sobre a qual você não tem certeza deveria ser um protótipo: algoritmos complexos, hardware não familiares,estruturas de bases de dados, interfaces humanas ( especialmente! ), e assim por diante. Eu acredito que esta técnica se tornará ainda mais importante em poucas décadas à medida que nos movemos para ambientes cada vez mais complexos. Aqui, novamente, teremos que modificar ou até mesmo abandonar as velhas metodologias. O livro de 1993 de Dave Olson, “Explorando Chaos: Lucrando com sobre a realidade do desenvolvimento de software” (Exploiting Chaos: Cashing in
on the Realities of Software Development
) , descreve uma série de abordagens para combinar desenvolvimento iterativo com marcos para obter o melhor dos dois mundos, além de algumas fascinante digressões em novos conceitos de caos e “atratores estranhos”. Há alguns atratores muito estranhos em nosso negócio! Eu também acreditava há algum tempo que a maioria dos protótipos não deve apenas ser jogado fora depois de terem servido o seu propósito . Um protótipo deve ser capaz de se tornar “adulto”, passo a passo, e um sistema completo. Uma vez que a importância de protótipos é que reduzem incerteza, reescrever aplicações em uma linguagem diferente é susceptível de trazer um monte [de incerteza] de volta!

Flow-Based Programming lembra fortemente o conceito de Lego Programming. E também o Actor Model – que foi no que se baseou a implementação inicial do Smalltalk onde os objetos eram ativos (processos ou threads para cada objeto) e não passivos como agora é usual. A linguagem Linda – piadas a parte sobre ser uma homenagem a Linda Lovelace, a primeira programadora e filha de Lord Byron, ou aquela do filme Deep Throat – é citada por Morrison como bem próxima, conceitualmente, do Flow-Based Programming. Programas de simulação em geral, e em particular o Modelica, também usam abordagem similar.

Não se influencie pela palavra programming no título deste post. O conceito de Flow-Based Programming é bem abrangente e, na verdade, pode ser mapeado perfeitamente nas linguagens usuais de descrição de processos de forma bidirecional, eu diria. Flow-Based Programming é um conceito arquitetural anti-Von Neumann que pode usar ambientes existentes onde o paralelismo de processos já é a tônica como os pipes dos sistemas UNIX (NextFlow) ou mesmo interpretar os diagramas de fluxo do BPM (Esta impressão fica bem nítida ao ver o vídeo Morphic BPM) como Flow-Based Programming embora com um drill-down limitado em relação às possibilidades do negócio chegar próximo ao “chão de fábrica”, digamos assim, atapetados, metaforicamente, de componentes atômicos. Flow-Based Programming é uma linguagem com que o pessoal de negócio, que já entende de processos, vai ter uma empatia imediata. John Paul Morrison propõe que os usuários vão projetar os sistemas com os blocos que os programadores vão construir conforme uma especificação dada a eles pelo pessoal de negócio. Cita claramente o sonho do Legoland Programming. A idéia de tornar a programação mais palatável para leigos já teve várias abordagens e uma delas que pode ser bem atrativa para crianças é o Scratch, desenvolvido para o Squeak (uma versão do Smalltalk originada na Apple e na Disney – por isso o colorido). O projeto de fluxogramas, abandonados pelos programadores que preferem ler textos, é bastante popular no negócio para a descrição de processos em detalhes envolvendo pontos de decisão, bifurcações etc.

Abaixo, a título de ilustração, coloco imagens de sistemas que já embutem programação visual de fluxos de dados de forma similar a Flow-Based Programming (e são fonte de inspiração para aqueles que estão redescobrindo o conceito, como ocorreu em relação ao Quartz Composer e o NoFlo). Mas o insight sobre usar isto como arcabouço para desenvolver software numa nova proposta de arquitetura, apesar de não ser inédito, ainda precisa “pegar”.

Lego Programming

Quartz Composer

Modelica

NoFlo

Uma coisa que Flow-Based Programming tem em comum com o Smalltalk é uma parcimônia de conceitos que servem de blocos de construção para sistemas complexos. Esta economia tem conseqüência direta na produtividade porque incentiva a experimentação e libera a criatividade. Combinar coisas simples e bem comportadas (previsíveis) é mais fácil que combinar coisas complexas. Em Smalltalk tudo é objeto. Objetos, obviamente, classes, mensagens, closures (blocks) são objetos. Smalltalk foi consequência da idéia de especificar uma linguagem de programação em uma única página. E não foi com letras miúdas.

The second bet had even more surprising results. I had expected that the new Smalltalk would be an iconic language and would take at least two years to invent, but fate intervened. One day, in a typical PARC hallway bullsession, Ted Kaeh;er, Dan Ingalls, and I were standing around talking about programming languages. The subject pf power came up and the two of them wondered how large a language one would have to make to get great power. With as much panache as I could muster, asserted that you could define the “most powerful language in the world” in “a page of code.” They said, “Put up or shut up.”

THE EARLY HISTORY OF SMALLTALK

A linguagem Smalltalk tem apenas seis palavras chaves: true, false, nil,self, super, e thisContextE os objetos só se comunicam por mensagens que acionam métodos. Em Flow-Based Programming o vocabulário também é limitado: Component, Connection, Packet (Information Packet – IP), e Port. A implementação usando object-oriented programming usa uma classe cujas instâncias das subclasses (os componentes) são objetos que executam um laço infinito e só se comunicam com exterior através de suas portas (Ports) de entrada e saída. As portas estão nas extremidades da conexões (Connections) interligando os componentes. Os  pacotes (Packets) circulam numa única direção (de uma porta de saída de um componente para uma porta de entrada de um componente distinto). Cada componente é uma thread (ou processo) que “acorda” quando há pacotes a processar nas portas de entrada e “dormem” em caso contrário. Em relação aos pacotes um componente só pode fazer três coisas: criar, destruir ou enviar os pacotes por uma porta de saída. E os componentes ou são atômicos ou compostos de outros componentes configurados em uma rede interna que os conecta. Um modelo simples assim é extremamente palatável aos usuários e encorajam o Lego Programming. O poder de uma tal abstração é tremendo e está gerando um frisson na Internet. Vamos ilustrar uma possibilidade a título de exercício. A figura abaixo é bastante conhecida no mundo dos analistas e projetistas de processo. Vou usá-la para ilustrar uma possibilidade de uso conceitual na implementação dos componentes.

Imagine o componente abaixo com quatro tipos de portas: três de entrada e uma saída.

idef0

As portas Inputs e outputs dispensam comentários. Mas o que são as outras duas? Podemos imaginar que constraints pode ser implementado como uma porta que vai ser usada para configurar o componente para atender restrições. As restrições podem ser “injetadas” nesta porta (ou conjunto de portas) em forma de um componente ou de uma especificação a ser instanciada no ambiente interno do componente. Infra structure representa o que o componente precisa para executar. Novamente, podem ser bibliotecas encapsuladas em um componente ou pacote a serem instanciadas no ambiente interno do componente.

Quando vi que a minha licença médica já estava terminando e o meu tempo livre prestes a escassear corri e comecei a codificar furiosamente no Pharo Smalltalk obtendo uma primeira versão funcional em poucos dias – graças à incrível produtividade auxiliada pelo IDE do Smalltalk, especificamente do Pharo 3 – nova versão que comecei a experimentar. Esta saga, recheada de entusiasmo, pretendo relatar aqui nesta série de posts. Farei isto em paralelo com a construção gradual do código em Smalltalk. Enquanto isto larguei um pouco o Javascript. Smalltalk is a drug!

Nota: No meu afã de implementar logo um protótipo não tive tempo de ler as discussões e polêmicas sobre a melhor forma de implementar cada conceito. Nos trabalhos futuros pretendo corrigir algumas coisas e implementar outras que foram omitidas.


Ciclo de palestras sobre Nietzsche no Rio

Programação:

20/05 (terça-feira), às 18h30

Nietzsche: filósofo, educador, escritor

Rosa Dias e Rafael Haddock-Lobo

21/05 (quarta-feira), às 18h30

Nietzsche: criação e escritura

Juliana Lira Sampaio e Alexandre Marques Cabral

22/05 (quinta-feira), às 18h30

Nietzsche: filosofia trágica e perspectivismo

Renato Nunes Bittencourt e Bernardo Oliveira

23/05 (sexta-feira), às 18h30

Nietzsche: ensino e linguagem extramoral

Walter Omar Kohan e Charles Feitosa

Ciclo de palestras Nietzsche 170 anos: Filósofo, Educador, Escritor

Local: Caixa Cultural Rio de Janeiro Cinema 2

Endereço: Av. Almirante Barroso, 25, Centro (Metrô: Estação Carioca)

Telefone: (21) 3980-3815

Datas: 20 a 23 de maio de 2014 (de terça-feira a sexta-feira)

Horário: 18h30

Classificação: livre

Lotação: 80 lugares (mais 3 para cadeirantes)

Serão distribuídas senhas uma hora antes do início das palestras

Acesso para pessoas com deficiência


 

O paradigma francês e o paradoxo americano

O Dr, Souto cita um artigo de um cardiologista gaúcho, O Dr. Flávio José Kanter, no qual este cunhou a interessante frase:

Não é preciso olhar os franceses como paradoxais. Podemos aprender o que há de bom em seus hábitos, desvendar seus segredos. Quem sabe, seja hora de entender que não é paradoxo, e sim paradigma francês?

Talvez seja mais interessante pensar que há um “paradoxo americano”. Que apesar de toda a recomendação “abalizada” sobre nutrição com ênfase nos carboidratos os americanos estão engordando e engordando o mundo com a exportação do “american food way of life”.


7 Mentiras sobre Nutrição que estão a tornar as pessoas mais gordas e doentes

Functional Performance Training

Aproveitando o impulso dado pelo Dr. Jonny Bowden e a revisão que tenho vindo a efectuar na área da nutrição, acho importante dar a conhecer os principais mitos que temos sido levados a acreditar em relação à forma como comemos e que nunca questionamos. Este artigo tem basicamente dois objetivos: o primeiro é explicar de uma forma geral e compreensiva as razões pelas quais estamos mais gordos e doentes, e o segundo é fazer as pessoas pensar e questionar as escolhas que fazem todos os dias quando comem. Não sou especialista em nutrição e por esse motivo tudo o que aqui partilho está referenciado por pessoas que se dedicam ao estudo dessa temática. Também não sou nenhuma testemunha de jeová tentando mostrar o caminho do Bem. Sou apenas alguém com um particular interesse nesta área que acredita profundamente naquela célebre frase “somos o que comemos” e que acha que a…

Ver o post original 5.953 mais palavras

Custom Elements defining new elements in HTML

Table of Contents

http://www.html5rocks.com/en/tutorials/webcomponents/customelements/