Arquivo do mês: junho 2014

Pedalentos

O QUE É PEDALENTOS

Pedalentos é uma filosofia.

Pedalentos é um estilo não competitivo de ciclismo.

Pedalentos é Cicloturismo Contemplativo; que consiste em pedalar sem pressa, sem hora marcada, onde o tempo é relativo e até mesmo as situações adversas se tornam engraçadas, transformando simples acontecimentos em raros momentos de contemplação do universo e celebração da vida.

http://pedalentos.wordpress.com/

Como Lobos Transformam Rios

Reintroduziram os lobos e os alces deixaram de frequentar os lugares onde eram mais vulneráveis aos lobos. O impacto ambiental do alces mudou. As florestas voltaram. Os rios melhoraram. Que maravilha! Onde está o lobo do alce-homem?  Seria a fome que nos espera no futuro quando o planeta se esgotar? Que lobo salvará a terra da sanha do alce -homem?

Chamem o lobo! O melhor amigo do homem…

Mudança de paradigma no desenvolvimento de software


O assunto que é o principal conteúdo deste post à primeira vista “chove no molhado” de velhas promessas da área de computação sobre desenvolvimento com componentes e de metodologias para uma aproximação com as áreas de negócio que possa resolver o gap de comunicação acusado por ambos os lados. Tanto o negócio quanto os desenvolvedores de aplicações para o negócio reclamam e inculpam o outro lado pelo fracasso flagrante em termos de cumprir o que promete dentro do orçamento e no prazo. A “Torre Eiffel”, cuja obra atendeu aos três itens citados, não existe para a Engenharia de Software (um nome bastante inadequado). O termo “Engenharia” na expressão Engenharia de Software é inadequado por não capturar bem o que significa desenvolver software. Um empregado da Dupont ficou admirado ao saber que havia uma perda de cerca de 50% no processo de desenvolver software. É como que para cada carro fabricado um tivesse que ser jogado fora numa indústria de automóveis. Não entendia como se podia ganhar dinheiro com um trabalho desses. Sorrisos amarelos à parte, foi-lhe explicado que os clientes já tinham uma margem de tolerância para isto aceitando que era assim mesmo. O que se segue está intimamente ligado ao que se chama de “crise de software”.

Há 40 anos um empregado da IBM do Canadá, John Paul Morrison, com formação em Antropologia, já tinha começado a endereçar o problema. Seus trabalhos com sistemas de simulação (GPSS) o inspiraram a levar suas reflexões sobre as dificuldades para desenvolver software em direção a uma mudança de paradigma. Esta mudança de paradigma tem duas faces. Uma para os desenvolvedores e outra, mais importante segundo Morrison, para o lado do negócio. Um dos sonhos daqueles que trabalhavam com simulação é ver os seus sistema se metamorfosearem em sistemas de controle também. Afinal a análise necessária para construir um sistema de simulação é mais do que suficiente para as necessidades de uma aplicação de controle. Mas na época ainda não havia os recursos computacionais e clareza a respeito de como fazer isto.

Hoje a tendência à paralelização da execução do software é uma realidade com praticamente todos os computadores sendo fabricados com mais de uma CPU (cores), com as técnicas de clusterização e também com a distribuição de execução por uma rede de computadores, já amplamente explorada por sistemas de Big Data. No entanto programar os computadores para explorar estes novos recursos não é fácil e muitas vezes exige que os profissionais sejam super programadores, um recurso raro e caro. Uma abordagem para contornar o problema é tornar a programação de sistemas paralelos mais segura e fácil para os programadores médios, menos raros e mais baratos. A quantidade de programadores nestas condições cria um exército com tamanho suficiente para atender as demandas do negócio. Os super programadores ficam para os desenvolvimentos especiais dos frameworks para os programadores médios usarem, entre outras coisas menos frequentes. No limite os programadores médios acabam fazendo tarefas acessíveis a qualquer “mortal” normal. Para exemplificar vamos pensar no que é comumente chamado de Lego Programming. Vamos imaginar um pai que comprou um kit para robótica para crianças da Lego e o entregou como um brinquedo sofisticado para seu filho ou filha que esteja no nivel educacional adequado para seguir as instruções. Preocupado com a eficácia de sua iniciativa educacional (era um engenheiro que queria incutir o gosto pela engenharia nos filhos) resolve examinar mais de perto o “brinquedo”. Primeiro se surpreende com o grau de sofisticação e o potencial de aplicações. Pensa que aquilo é inacessível para a idade e a maturidade dos filhos. Investigando mais verifica surpreso que foi capturado pela simplicidade conceitual que faz a coisa funcionar e se pega “brincando” com aquilo. Percebe então não só o potencial educacional do Lego Programming para seus filhos mas como aquilo poderia ser generalizado para apoiar um indústria onde o processo de desenvolvimento de software esteja “embarcado” no negócio de uma forma horizontal, e não da forma verticalizada atual.

Foi isto aproximadamete o que aconteceu com Morrison. Só que a partir da sua experiência com sistemas de simulação. O que propôs na verdade é uma mudança de paradigma para o desenvolvimento de software que escapa do modelo Von Neumann. E implementou num banco, uma das instituições mais rigorosas em relação à confiabilidade e segurança de suas aplicações, além de serem instituições bastante reguladas. Morrison inventou algo cujo nome, Flow-Based Programming, é bem despretensioso mas cujas repercussões agora estão em ressurgimento, 40 anos após a sua invenção.

Flow-Based Programming tem uma simplicidade que, paradoxalmente, alavanca o seu poder. Os excertos abaixo são de uma série de artigos que estou escrevendo:

“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. É uma linguagem com que o pessoal de negócio que 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. (…) Em Flow-Based Programming o vocabulário também é limitado: Component, Connection, Packet (Information Packet – IP), e Port. (…) 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. (…)  Flow-Based Programming pode iniciar uma era de sucesso na direção da criação de um mercado de componentes de prateleira, na aproximação dos usuários ao desenvolvimento ativo de sistemas para atender os seus negócios e melhor aproveitamento da infra-estrutura de paralelismo que está despontando cada vez mais. A reutilização de componentes “técnicos”, desenvolvidos pelos profissionais de TI bem como daqueles desenvolvidos pelo negócio deve alavancar uma produtividade nunca vista antes. A reutilização de componentes de negócio sempre foi o calcanhar de Aquiles da indústria de software. Reutilizar widgets da interface com o usuário são bem previsíveis mas entender quais são os “átomos” do negócio (que são os componentes mais reutilizáveis, em princípio) e mesmo os componentes mais complexos, que somente os experts em cada área seriam capazes de detectar, é uma tarefa bem difícil. E se eles puderem “por a mão na massa” com uma linguagem visual e componentes disponíveis para serem conectados os sistemas poderiam evoluir de forma rápida e adaptativa às mudanças nos cenários dos negócios. Uma forma exploratória e menos rígida será gerada pelas novas facilidades no desenvolvimento de sistemas com base em protótipos que se tornam “adultos” (Morrison), que não são jogados fora violando a teoria dos protótipos feitos com “arame preso com chicletes”. Embora isto esteja mudando recentemente. O mundo do software é mais plástico do que o mundo físico ou do hardware. Um modelo de um carro feito de cerâmica ou plástico esculpido para ser testado no túnel de vento não pode depois circular nas ruas, mas um modelo em software é análogo ao que pode ser imaginado numa história de ficção científica em que o escritor faz a cerâmica se transmutar em metal.” (SmallFBP: a Smalltalk framework for Flow-Based Programming in Crab Log)

Uma das consequências de um modelo de componentes tem impacto direto no modelo de contratação de serviços de desenvolvimento de software. O uso de fábricas de software pode ser feito de forma mais eficaz e com menos dependência. Os métodos ágeis podem ser praticados pela empresa contratante utilizando componentes encomendados às fábricas. Às fábricas não seriam encomendados projetos de desenvolvimento mas apenas componentes com determinadas especificações. No limite alguns componentes com prazos críticos de entrega poderiam ser solicitados a fábricas concorrentes  com um bonus para quem entregasse primeiro. A empresa contratante não precisaria abandonar as sua práticas ágeis no desenvolvimento de sistemas em que pequenas equipes sejam suficientes (O desenvolvimento com equipes reduzidas é de eficácia tão flagrante para alguns projetos que o departamento de defesa do governo dos E.U.A. até estabeleceu uma lei que impões o seu uso na maioria dos casos, a menos de exceções bem específicas).

Um incômodo similar ao que ocorreu ao empregado da DuPont sobre a ineficiência do desenvolvimento de software nas bases atuais acontece comigo também. É facil perceber o paralelo com o que acontece no desenvolvimento de hardware e como o modelo é produtivo apesar da plasticidade do hardware não ser a mesma do software. No entanto imitar a rigidez do hardware, que força o sua reutilização, pode ser benéfico para o desenvolvimento de software. Os métodos de engenharia, que já provaram sua eficácia até agora, poderiam ser aplicados ao desenvolvimento de sistemas usando o novo paradigma. Morrison cita o paper On the Architectural Requirements of an Engineered System, de Nate P. Edwards, que não recebeu muita atenção no domínio de software devido ao seu background ser preponderantemente em hardware, onde ele estabelece as características fundamentais de um sistema modularizado e orientado à reutilização. O engenheiro de sistemas é estimulado a usar pacotes prontos e só construir algo novo se for estritamente necessário e vantajoso economicamente. O paper cita explicitamente a qualidade única em um sistema de desenvolvimento de software que é engineered:

The idea of applying engineering principles and practices to data processing systems and programming has been around since hardware engineers began to do programming in the 1950’s. With one exception, I am aware of no example of software system which exhibits most, if not all of the essentials of the engineering approach.This one exception is the Advanced Modular Programming System “AMPS” [N.A.: Precursor de Flow-Based Programming] invented by J. P. Morrison of IBM. It is specially notable in that it uses fully independent modules and configurable architecture principles.” (Architectural system requirements for data processing in On the Architectural Requirements of an Engineered System)

Voltando ao tema da adequação do termo Engenharia de Software muito já foi escrito a respeito. Martin Fowler em The New Methodology discute como os métodos ágeis são uma solução para o desenvolvimento de software. Há até uma distinção entre os métodos ágeis, que promovem a produtividade em pequenas equipes tais como o Scrum e o Kan Ban, e os princípios do XP (Extreme Programming), estes últimos rotulados como dentro do tema “engenharia de software”. Uma arquitetura “engineered”, como parece ser o caso de flow-based programming ou outras técnicas de uso de componentes não são consideradas como alavancadoras da produtividade mas apenas como arquieturas alternativas sem nenhuma qualidade intrínseca para resolver as dificuldades atualmente enfrentadas. O método da força bruta, agora não mais colocando mais programadores mas reduzindo o escopo e as equipes e aplicando uma política draconiana de controle da persecução das tarefas é preconizado. Acredito que flow-based programming vai engendrar uma drástica revisão de todo este cenário.

Livro A Dieta Da Mente (Grain Brain, traduzido)

Comprei e estou lendo. Reforça bem o que já é propugnado pela dieta paleo.

A sinopse do livro já dá o tom:

“Prepare-se para descobrir a verdade sobre os efeitos do trigo, do açúcar e dos carboidratos sobre o seu cérebro. Em “A Dieta da Mente”, David Perlmutter apresenta uma descoberta que há muito tempo tem sido escondida pela literatura médica: os carboidratos podem destruir seu cérebro. Até mesmo aqueles considerados “saudáveis”, como os grãos integrais, podem causar demência, déficit de atenção, epilepsia, ansiedade, enxaquecas, depressão, redução da libido e muito mais. Inovador e oportuno, “A Dieta da Mente” mostra que o destino do seu cérebro não está na sua genética. Está naquilo que você come. Misturando pesquisas de ponta e histórias reais de transformação, David Perlmutter explica por que uma dieta rica em “gorduras boas” é ideal para o corpo e poderá fazê-lo emagrecer sem voltar a engordar. O revolucionário programa de quatro semanas proposto neste livro aponta o caminho para se manter o cérebro saudável, vibrante e aguçado — sem medicamentos. Com recomendações fáceis de seguir, receitas deliciosas e metas semanais, o plano de ação de Perlmutter prova que você pode assumir o controle de seus genes, recuperar o bem-estar e manter a saúde e a vitalidade por toda a vida.” (no Blog do Dr. Souto)

Como um método arcano de codificação usado em um banco em 1970 poderia salvar a sanidade de desenvolvedores

Abaixo segue uma tradução livre do artigo How An Arcane Coding Method From 1970s Banking Software Could Save The Sanity Of Web Developers Everywhere.

Quarenta anos atrás, um banco canadense foi pioneiro em um novo tipo de sistema de computador que permitiu que não-programadores ajudassem a escrever código. O paradigma era tão perturbador que foi ignorado por cientistas da computação por décadas. Mas, como as aplicações web estão cada vez mais complexas, e o desenvolvimento web se tornando cada vez mais estressante, “flow-based programming” pode estar de volta à vida de uma forma intensa.

Por 


Programadores web de hoje lidam com problemas que as pessoas antes nunca tiveram que lidar. Eles estão construindo UIs complexas, fazendo malabarismos com um monte de APIs e executando vários processos ao mesmo tempo. Todas estas tarefas exigem dominar o fluxo de dados entre os componentes do aplicativo em tempo real, algo com que mesmo os desenvolvedores mais avançados travam uma batalha.

Por que as coisas não podem ser mais fáceis? A maioria das técnicas de programação modernas descendem de um paradigma de computação de 60 anos de idade, que estipula, entre outras coisas, que todos os programas devem executar um passo de cada vez – que não é bom para lidar com várias tarefas ao mesmo tempo. Mas não há nenhuma razão para que tenha que ser assim. Muitos cientistas da computação inventaram técnicas de programação alternativas que tentam resolver estes problemas, apenas para serem rejeitadas por um establishment desconfortável ao ter que pensar sobre a programação de forma diferente. Felizmente, o dogma que existe hoje está morrendo.

Dan Tocchini, CEO de uma startup chamada The Grid, é parte de uma nova geração de programadores que cresceu lutando com programação multithread complexa,  I/O assíncrona e fontes quase ilimitadas de dados de centenas de APIs modernas. Ele acredita que ressuscitar um velho paradigma da década de 1970 pode ser a solução.

A solução não é “mais programadores”

Na década de 1970, um banco canadense servindo 5 milhões de clientes implementou um novo tipo sistema de computador usando uma novo e pouco conhecido paradigma de desenvolvimento de software chamado “flow-based programming” (FBP). O software foi um sucesso, principalmente porque permitiu ao banco construir aplicações funcionais com gráficos fáceis de visualizar dos dados que fluem entre os componentes, algo que não-desenvolvedores poderiam entender. Os novos aplicativos eram tão fáceis de manter que alguns deles estão sendo usados ​​ainda 40 anos depois, e FBP ainda não vingou porque a maioria dos programadores no momento resistem à adoção do novo paradigma.

Uma das razões porque os programadores não se entusiasmam com FBP é que ele requer uma nova forma de pensar o desenvolvimento. Aplicativos tradicionais são mais fáceis de quebrar quando eles se tornam maiores e mais complexos. A solução usual para este problema é lançar mais desenvolvedores no projeto e usar as estratégias de implantação cuidadosas como integração contínua para evitar coisas quebrando. Muitos dos desenvolvedores confiam na abordagem de força bruta, mas ela não escala.

“O que precisamos não é de mais programadores. O que nós precisamos é permitir que não-programadores participem do processo de criação, e não apenas o processo de ideação”, diz Kenneth Kan, CTO de uma empresa chamada Pixbi e um recém-convertido de flow-based programming. “Ao invés de fazermos os seres humanos pensarem como máquinas, é hora de fazer as máquinas capazes de pensar mais como nós.”

Paradigmas de programação tradicionais forçam os programadores a pensar um passo de cada vez e combinar o trabalho real feito por um aplicativo, o programa, com a ordem em que ele é executado, sua lógica ou fluxo. O resultado é que os aplicativos se tornam rapidamente desorganizados emaranhados de código que dependem uns dos outros. Se você quiser alterar a ordem de uma seqüência de eventos, é necessário reescrever tudo o que depende deles. E boa sorte em conseguir qualquer pessoa, até mesmo um outro desenvolvedor, para compreendê-lo.

“Ele só se tornou uma bagunça do c*@#$%ˆ&. Era simplesmente incontrolável”, diz Tocchini sobre o projeto pesadelo que o levou a procurar novas soluções. Sua empresa está ocupada ressuscitando flow-based programming com o framework chamado NoFlo, uma implementação do FBP para NodeJS.

De acordo com Tocchini, gerenciar a base de código em expansão do front-end do framework MVC em JavaScript que ele estava usando ficou totalmente insustentável a medida acrescentava mais recursos, aumentando a complexidade dos componentes até que levou uma semana apenas para fazer pequenas mudanças. Mudar para flow-based programming lhe permitiu concentrar em componentes individuais, e entender os gargalos visualmente.


“O workflow de “colar” os componentes, eu adoro isto. Isto parece muito melhor”, diz ele. “Você não tem esses tipos de momentos brutais e se tiver, é porque você conectou as coisas erradamente. Seu spaghetti parece spaghetti, certo?”

Desenvolvimento de software não é uma realização individual

“Isto não é ‘sentido’ como programação”, diz Kan. Através de NoFlo, ele se tornou um convertido ao processo de desenvolvimento com FBP. “Trata-se de soluções sem muita codificação. Enquanto a programação web continuar a ser uma festa somente para os hackers, FBP não terá espaço para crescer.”

J. Paul Morrison, o criador de flow-based programming, tem uma opinião um pouco diferente. Ele não acha que precisamos de menos programadores, mas que a programação vai se tornar mainstream assim que os desenvolvedores derem o lugar para um novo tipo de arquiteto de aplicativos.

“Há dois papéis: Há construtor de componentes, que tem que ter experiência em uma determinada área de programação, e há aquele os coloca juntos”, explica Morrison. “E são duas habilidades diferentes.”

Se NoFlo for bem sucedido, poderá anunciar um novo paradigma de programação web. Imagine um mundo onde qualquer pessoa pode entender e construir aplicações web, e os desenvolvedores podem se concentrar na programação de componentes eficientes para serem colocado para funcionar por esta nova classe de arquitetos de aplicativos. De certa forma, esta é a mesma promessa que o movimento “aprender a codificar”, que quer ensinar todo mundo a ser um programador. Apenas que sem a programação.

Como um paradigma brilhante foi enterrado pela história

FBP parece que poderia ser a solução para muitos problemas de desenvolvimento modernos. É naturalmente paralelizável, o que ajuda os programadores a lidar com múltiplas tarefas simultâneas, e UIs complexas baseadas em partes físicas. Porque ele se presta à visualização, as aplicações flow-based são fáceis para o crescente número de stakeholders não-técnicos ​​em produtos possam entender. Então, por que demorou tanto tempo para ter êxito?

Morrison descobriu flow-based programming uma década antes de construir o software para o banco, enquanto trabalhava como engenheiro na IBM. Ele estava em Montreal experimentando com simulação discreta de carros em movimento através de postos de gasolina, quando ocorreu-lhe que as mesmas técnicas utilizadas na modelagem discreta poderiam ser aplicadas ao desenvolvimento de software.

“Eu disse, ‘E se pudéssemos ter alguns processos distintos que sendo executados ao mesmo tempo, com dados passando por eles?'”, Lembra Morrison. “‘O quanto isso seria difícil se a programação fosse com dados de negócios, em vez de carros?” Eu desenhei algumas figuras e de repente surgiu este belo componente que faria uma grande parte da programação mais reutilizável. ”

A idéia de modelar aplicativos como grafos de dados em movimento entre os blocos de código independentes, reutilizáveis ​​não era novo. Na verdade, Morrison admite que ele teve a idéia de suas experiências trabalhando com sistemas de computação baseados em cartão logo no início onde você pode literalmente ver pilhas de cartões que transportam dados em movimento para adiante e para trás na sala de máquinas. O que era novo sobre a abordagem foi aplicá-lo à arquitetura Von Neumann, a base de todo o projeto do computador moderno.

Devido ao matemático John Von Neumann, de Princeton, o projeto de computadores substituiu os sistemas de cartão de controle de programa que Morrison trabalhou por computadores que podem armazenar instruções na memória. Ele especifica, entre outras coisas, que essas instruções devem passar da memória para a CPU uma “palavra” de cada vez, uma restrição que obriga os programadores a escrever linhas de código que são executados um de cada vez, em grande parte, na ordem de escrita.

O conceito flow-based de Morrison efetivamente reconstruiu a abordagem anteriormente de controle por programa, onde os dados são encaminhados em fluxos de e para aplicativos construídos de propósito, no topo da arquitetura Von Neumann. Isso permite que os programadores escrevam funções individuais que executam um passo de cada vez, mas rotear os dados entre estas funções de forma assíncrona e ao mesmo tempo usando um grafo de definição de rede. De acordo com Morrison, flow-based programming é uma melhoria em relação a outras abordagens, pois permite que os programadores construam componentes reutilizáveis ​​que podem ser integrados em qualquer aplicação, e por causa disto lhes permite visualizar as aplicações.

“Ele conta com as habilidades visuais dos seres humanos. Em vez de fazer resmas de texto, você pode desenhar figuras”, explica Morrison. “Nós costumávamos fazer estes diagramas em enormes folhas de papel, e a coisa interessante sobre isso foi que você poderia anotá-los e eles iriam receber todas as “orelhas” e as pessoas iriam desenhar cartoons sobre eles e os comentários e você poderia colocar informações descritivas sobre eles. Então, você poderia basicamente transformá-los em definições de rede de flow-based programming“.

A idéia era tão óbvia que a IBM se recusou a patentear a nova abordagem, chamando-a “muito mais como uma lei da natureza” do que uma nova invenção, de acordo com Morrison. Em vez disso, a empresa publicou FBP como um boletim de divulgação técnica (technical disclosure bulletin), efetivamente tornando-a de domínio público. E, no entanto, com exceção de algumas aplicações raras como o banco canadense, ela nunca realmente despontou.

De acordo com Morrison, a falha da FBP em decolar foi causada em parte por sua incapacidade de fazer marketing adequadamente da abordagem, e em parte pelo paradigma de programação que já havia se formado em torno de arquitetura Von Neumann, que ele compara com os paradigmas científicos descritos por Thomas Kuhn em seu inovador livro A Estrutura das Revoluções Científicas (The Structure of Scientific Revolutions).

“Você tem um computador que pode fazer qualquer coisa, e uma coisa de cada vez, e isso é um paradigma tão poderoso, ninguém vê qualquer problema com isso, qualquer necessidade de se chegar a algo diferente”, diz Morrison. “Todos os programas eram laços dentro de laços dentro de laços. Se você tivesse um problema, lhe foi dito que você só pensou nele o suficiente. Não era problema do computador ou problema da arquitetura, era um problema seu.”

O livro de Kuhn sobre as revoluções científicas inclui uma famosa citação do físico Max Planck sobre o que realmente faz com que haja mudanças de paradigma:

Uma nova verdade científica não triunfa convencendo seus oponentes e fazendo-os ver a luz, mas sim porque seus oponentes eventualmente morrem, e uma nova geração cresce que é familiar com ela.

Quarenta e cinco anos se passaram desde Morrison descobriu FBP, e os programadores que trabalharam durante o início da era Von Neumann estão morrendo. Em seu lugar, uma nova geração de programadores frustrados com as deficiências dos paradigmas tradicionais está se tronando adulta e estão dispostos a tentar algo novo.

Como as pessoas estão redescobrindo Flow-Based Programming

Tocchini tropeçou FBP quase por acidente, quando viu alguns designers no Facebook usando a ferramenta Quartz Composer tool, da Apple, para criar mockup de aplicações para o iOS em vez de Photoshop. Embora a abordagem flow-based, como descrita por Morrison nunca pegou totalmente, alguns conceitos flow-based acabaram por fazer o seu caminho nas comunidades de nicho de desenvolvimento, como o desenvolvimento de jogos e de composição de filme, onde as ferramentas de fluxo semelhantes são usados ​​para modelar interações físicas. Flow-based programming é especialmente útil para estas aplicações, porque a modelagem física realista requer execução de múltiplas equações simultaneamente. Para ajudar os designers de aplicativos fazem uso do novo Core Image e Core Video advanced graphical APIs que foram introduzidas no OS X 10.4 “Tiger”, a Apple incluiu a ferramenta de mockup Quartz Composer no kit de desenvolvimento de software em 2005.

Tocchini amou a ideia de criação de protótipos ao vivo, especialmente porque UIs para aplicações web estão se tornando mais complexa e implementação de mais interações com base em física, mas queria dar um passo adiante.

“Um dos problemas é que [N.T.: os protótipos] tem de ser reconstruídos”, diz Tocchini. “É puramente prototipagem. Como está você tem sair do Quartz Composer [N.T.: e reconstruir]. Não há nenhuma razão porque você não poderia ter um produto final em pleno funcionamento com ele.”.

Assim, juntou-se com Henri Bergius, o criador do NoFlo, e começou a portar aplicativos de sua empresa a partir de seu antigo framework MVC para o novo paradigma.

A interface de programação NoFlo

NoFlo funciona ligando componentes  CommonJS com um grafo, especificado em JSON. Ele também inclui uma linguagem específica de domínio que permite aos desenvolvedores incorporar gráficos em aplicações existentes. Tem sido disponibilizada durante dois anos e tem uma pequena base de usuários devotados que ajudaram Tocchini e Bergius construir 250 componentes.

Como a implementação FBP original de Morrison, no entanto, não tem se tornado comum, especialmente em comparação com os frameworks tradicionais Node-based como Meteor ou SailsJS. Tocchini e Bergius acreditam que a NoFlo está faltando um componente-chave: uma interface.

Para facilitar a construção de uma interface para seu framework, Tocchini e Bergius lançaram recentemente uma Kickstarter campanha para financiar o desenvolvimento de uma interface do usuário para NoFlo. A campanha arrecadou US $ 80.000 a US $ 100.000 em apenas seis dias, sinalizando que o interesse em FBP está crescendo.

Um dos principais benefícios de flow-based programming é que leva a lógica de controle para fora do programa principal e, em abstrai-lo em um gráfico de rede que qualquer um, mesmo aqueles sem experiência de programação, podem entender. Imagine um programa como um gráfico de “caixas-pretas”, com entradas e saídas conectadas por fios que representam fluxos de dados. Entenderam? Parabéns, você construiu um programa.

Isto levará aos desenvolvedores desistirem um pouco da “sensação” e do controle sobre a programação que descreve Kan se FBP tiver sucesso. Mas de certa forma, a promessa de FBP é o sonho de qualquer programador. Em vez de lutar para fazer os stakeholders ​​compreenderem porque a adição de um novo recurso que requer a leitura de mais uma API simultaneamente é difícil, imagine se eles poderiam simplesmente ver e entender. Em vez de lidar com pedaços de ligação e peças de seus aplicativos, você pode deixar isso para as pessoas que o usam, e se concentrar apenas em fazer as coisas funcionarem.


 

GABE STEIN

Gabe Stein é um contribuidor da Co.Labs especializado em história da ciência da computação, publishing e futurologia. Antes de se tornar um colaborador, Gabe foi o residente “News Hacker” e um editor da Co.Labs. Antes disso, ele trabalhou no Google e OgilvyAction em Nova York. Ele ama falar com você sobre o futuro de tudo no Twitter.

Continue

Salvador Dali no CCBB até 22 de setembro

salvador-dali-no-ccbb

De quarta a segunda, das 9 às 21h.

Ver mais detalhes em:

Fomos na exposição eu, Iane, Mateus e Iasmin ao meio-dia de 20/6/2014. Depois almoçamos na Toca do Baiacu.

Fotografei os textos no início da exposição para poder ler depois e um dos quadros:

texto-dali-1

texto-dali-2

texto-dali-3

quadro-dali-mitra

 

Ursos berlinenses em Copa

urso-africa-do-sul

 

Este urso representando a África do Sul, que está no Leme junto com muitos outros, foi o que achei mais bonito, com sua cor ocre lembrando a poeira das savanas e os animais, formando um padrão muito interessante.

O urso que achei bem ousado: o da Holanda. Veja abaixo:

urso-berlinense-da-holanda

Vivre l’amour.