System of Systems e os Sistema Complexo Adaptativos /ou: Arquitetura (Quase) Caótica...

No último post eu descrevi como estamos pensando a plataforma de publicação e gerenciamento de conteúdo na Abril Digital e como o conceito de System of Systems (SoS) se aplica. Neste post quero discutir algumas características de um SoS.

Toda vez que penso nos conceitos de System of Systems (SoS), me vem a mente a imagem de uma grande revoada, aquela formação no ar por um monte de pássaros voando aparentemente sem rumo, que é caótica e concisa ao mesmo tempo. O que isso tem a ver com o SoS? Veremos...

O interessante sobre as revoadas é saber que os pássaros não têm um chefe dizendo para onde ir. Porém, o grupo se orienta no ar de forma organizada. Mas como isso é possível? O que acontece é que cada pássaro segue 3 regras básicas: evitar bater em um vizinhos ou obstáculos, alinhar vôo para coincidir com os vizinhos e voar uma distância média entre os vizinhos. Assim, um fenômeno emerge e temos a revoada. Ou seja, o que vemos é algo que parece ser criado, mas na verdade aquilo se manifesta daquela forma.

Será que conseguimos criar regras básicas para os sistemas e assim criar um SoS que se manifeste moldando as necessidade de negócio? Essa foi a pergunta que me fiz a alguns meses atrás e neste post estão algumas evidencias teóricas e práticas que dão suporte a idéia.

O fenômeno da revoada é estudado como um Sistema Complexo Adaptativo (Complex Adaptive System ou CAS), assim como outros sistemas complexos, que vão da economia a física, passando pela formação do cérebro ou a um time de scrum, "complexos no sentido de que são diversos e feitos de múltiplos elementos interconectados, e adaptativos porque têm a capacidade de mudar e aprender com experiências passadas". É aqui que o SoS se assemelha a revoada: diverso, interconectado e evolui.

Será isso mesmo? Vamos olhar o SoS através da idéia de um CAS e ver se conseguimos observar algumas propriedades semelhantes:

Emergência: Ao invés de ser prevista ou controlada, os agentes do sistema interagem de forma aparentemente aleatória. De todos esses padrões emergem interações que informa o comportamento dos agentes dentro do sistema e do comportamento do próprio sistema. Não há nenhum grande plano e o resultado apenas surge como resultado dos agentes seguirem algumas simples regras locais.

Mas o SoS não tem um grande plano? Não deve estar alinhado com a estratégia da empresa? Essa é a principal caracterisca que emerge! Ela não é controlada diretamente, assim como você não manda todos os pássaros voarem para um lado ou para outro. No entanto, acredito eu, existem mecanismos para direcionar essas características (veremos mais abaixo).

Além disso, como cada sistema é independente no SoS, eu não ficaria surpreso se um novo sistema criasse algo completamente novo, algo que simplesmente surge, emerge, juntando informações e funcionalidades de vários outros sistemas.

Co-evolução: Todos os sistemas existem dentro de seu próprio ambiente e eles também fazem parte desse ambiente. Portanto, conforme seu ambiente muda, eles precisam mudar para garantir melhor ajuste. Mas porque eles fazem parte do seu ambiente, quando eles mudam, mudam o seu ambiente também, e como ele mudou eles precisam mudar novamente, e assim por diante como um processo constante.

No SoS, isso é sutil. Imagine que um sistema foi alterado e agora ele aceita maior número de requisições. Isso vai fazer com que outros sistemas se conectem a ele e assim, alterando a configuração do SoS todo. O SoS ganha essa nova formação, que acaba por interferir em como os outros sistemas se conectam e assim por diante.

Poderíamos extrapolar para um outro exemplo, em que alguém do time de um sistema X foi trabalhar em um outro sistema ou saiu da empresa, deixando a evolução do primeiro mais lenta. Isso influencia não só no sistema X, mas também em como os outros times vêem aquele sistema, fazendo tomarem decisões se vão ou não conectar a ele. Novamente, a evolução de um sistema influenciou o conjunto que influenciou os sistemas e assim infinitamente...

Sub ideal: Um CAS não precisa ser perfeito para que prospere dentro do seu ambiente. Uma vez que um CAS atinge o estado de ser bom o suficiente, ele trocará eficiência por maior eficácia.

Pensar que um SoS não vai atingir seu estado máximo é perturbador. Mas quando se entende a complexidade de uma empresa, em todos os seus aspectos, o ótimo é inimigo do bom. Ter um SoS que evolua até chegar em seu estado quase perfeito é um grande conforto na verdade. Esperar que ele troque eficiência por eficácia é mais confortante ainda.

Variedade: Quanto maior a variedade dentro do sistema, mais forte ele é. Sistemas adaptativos complexos dependem de ambigüidade, paradoxo e contradições para criar novas possibilidades.

Não vejo problema, por exemplo, em ter dois ou mais sistemas com a mesma responsabilidade, mas que se diferenciam nos requisitos. Que ganhe o melhor! O SoS vai atrair um para o centro e o outro será expurgado. Ou não! Talvez os dois façam sentido e ganhem um número de conexões semelhantes um do outro. Assim como a evolução das espécies, só se consegue a evolução do SoS quando existe variedade.

Para estimular a variedade, não há regras explícitas (pelo menos do ponto de vista de arquitetura de sistemas) em como cada sistema deve ser construído, seja a linguagens, tecnologias ou design interno da aplicação. O importante é que o sistema se comporte bem dentro do SoS (ex.: se comunique usando HTTP e Atom/Hypermedia).

Auto-organização: Não existe uma hierarquia de comando e controle em um CAS. Não há planejamento ou gestão, mas há uma constante reorganização para encontrar o melhor ajuste com o ambiente.

O exemplo acima é válido aqui também. Quem diz se o sistema é bom ou não para o SoS é o próprio SoS. O modo dele expressar isso é a através de conexões que um sistema faz a outro sistema. Quanto mais conexões ele receber, melhor é o sistema para o SoS.

Conectividade: As maneiras pelas quais os agentes em um sistema se ligam e se relacionam entre si é fundamental para a sobrevivência do sistema, pois é a partir dessas conexões que os padrões são formados e o feedback disseminado. As relações entre os agentes são geralmente mais importante do que os próprios agentes.

Uma arquitetura baseada em serviços (SOA) tradicional não tem essa característica fundamental, que é a navegação entre os sistemas de forma transparente. No nosso caso estamos apostando no conceito de Hypermedia, no protocolo HTTP e no formato Atom para realizar essas conexões. As conexões são tão importantes para nós que estamos gastando um tempo considerável nesse problema.

Regras simples: CAS não são complicados. Os padrões emergentes podem ter uma rica variedade, mas, como em um caleidoscópio, as regras que regem a função do sistema são bastante simples.

Será que conseguiremos definir essas regras ou elas aparecerão como resultado da interação dos sistemas? A ser respondido. No entanto, acredito que parte da manipulação do comportamento emergente está aqui, ou seja, na definição prematura das regras. Assim, se as regras estiverem alinhadas com os conceitos básicos do negócio, o SoS não tem outra escapatória a não ser emergir com as características esperadas. Um desafio é definir as regras básicas de forma que elas também possam evoluir.

Sistemas Aninhados: A maioria dos sistemas está aninhados dentro de outros sistemas e muitos sistemas são sistemas de sistemas menores.

É normal que um time médio (de 6 ou 8 devs) designado para implementar um "módulo" do SoS implementem alguns sistemas/serviços, ao invés de apenas um, criando um subsistema dentro do SoS. Observar o que acontece nesses subsistemas é importante, pois talvez ali as regras do SoS não estão sendo aplicadas ou evoluções dessas regras apareçam.

À beira do caos: Teoria da Complexidade não é o mesmo que a Teoria do Caos, que é derivada da matemática. Mas o caos tem um lugar na Teoria da Complexidade em que os sistemas existem em um espectro que vai do equilíbrio para o caos. Um sistema em equilíbrio não tem a dinâmica interna que lhe permita responder ao seu ambiente e vai lentamente (ou rapidamente) morrer. Um sistema em caos deixa de funcionar como um sistema. O estado mais produtivo de se estar é à beira do caos, onde há máxima variedade e criatividade, levando a novas possibilidades.

Do ponto de vista de SoS, o caos deve ser administrado de forma a não extrapolar as expectativas e recursos da empresa. Isso não quer dizer que ele não deva existir! Evitar coisas como ESB, middlewares de governança ou qualquer forma de gerenciamento centralizado é uma maneira do SoS a evoluir e a se auto-organizar.

Fronteiras: A auto-organização implica que o sistema está rodeada por uma fronteira que o contém. Esta condição define o "auto" (self) que será desenvolvido durante o processo de auto-organização. [G. Eoyang & D.J. Conway, 1999]

A fronteira do SoS é definida quando se sabe o que é esperado dele do ponto de vista de negócio. Sem essa definição não existe como o SoS se auto-organizar, já que não existe o "auto". Além disso, é da definição da fronteira que será possível pensar as regras básicas, que deverão levar em conta até onde o sistema vai e onde é que ele termina.

Já gastamos um bom tempo definindo as fronteiras com as pessoas de negócio. Agora, o meu papel junto aos outros arquitetos da plataforma está na definição da comunicação dos sistemas e na definição das regras simples. Esperamos com essas definições criar uma terra fértil para os sistemas do SoS, deixando espaço para que eles cresçam e dêem frutos. Estamos regando diariamente!

Ah! Pensar arquitetura dessa forma traz implicações com as áreas de Infra-estrutura, Desenvolvimento e Scrum Office. Parte dessas implicações já apareceu e foram ou estão sendo resolvidas num trabalho em conjunto muito bacana e com idéias tão legais quanto. They got it!

System of Systems, REST, Hypermedia e HATEOAS /ou: Um dia na vida de um integrador de sistemas...

Há alguns meses fui chamado, junto com o Julio, para revisar a arquitetura da nossa plataforma de publicação e gerenciamento de conteúdo, que é responsável desde a criação de sites até a autorização de usuários e busca de conteúdo pelos editores. Resumindo (muito) a história, encontramos alguns sistemas monolíticos que represavam os requisitos de uma empresa formada por muitas unidades de negócio com necessidades variadas, muitas vezes até conflitantes. Se a lei de Conway é inevitável, tentar trapaceá-la não foi uma boa idéia. O modelo monolítico estava na nossa mira e pronto para ser derrubado.

Precisávamos de um modelo distribuído, com sistemas menores, de baixo acoplamento e alta coesão (já tinha ouvido falar que outros estavam indo nessa direção). O Julio cunhou o termo "System of Systems" e todos entenderam a idéia de uma forma geral. Um sistema que é formado por outros sistemas, onde um requisito de negócio era dissolvido em requisitos menores para sistemas menores, mas que juntos criavam a funcionalidade que o negócio esperava.

Mas isso não é um modelo de desenvolvimento baseado em componentes tão popular nos anos 90 ou um nome diferente pra Web-services? Quase. Sim, existe um trabalho de separação de interesses (separation of concerns), assim como nos componentes e em WS. Porém, diferente dos componentes ou WS, não tínhamos o protocolo comum entre os sistemas, como nos componentes distribuídos (SOAP, CORBA, DCOM, etc). Precisávamos de um protocolo que pudesse acolher nossos requisitos:

• Distribuído e descentralizador
• Escalabilidade: lidamos com milhões de requisições/dia. Escalar é preciso!
• Tolerante a falhas: não queremos deixar de mostrar uma página para o internauta só porque um dos sistemas esta fora. E sim, eles ficam fora.
• Fracamente acoplados: quanto menos souber de suas dependências e dos que dependem dele, mais utilizado e fácil de evoluir é um sistema.
• Facilidade de implementação: trabalhamos com diferentes linguagens e tecnologias. Protocolos abertos, com uma boa base de usuários e libs estáveis é essencial.
• BASE (Basically Available, Soft state, Eventually consistent): privilegiamos a disponibilidade sobre a consistência dos dados (assim como um sistema para web deve ser)
• Relacionamento entre recursos: queríamos criar uma rede de sistemas, quase caótica (do ponto de vista de governança) e sem repositório central. Pra isso, a informação sobre a relação entre recursos deveria existir no protocolo de comunicação entre os sistemas e ser entendida por qualquer sistema da plataforma.

Estávamos de olho no REST e parecia o caminho natural, mesmo com suas limitações. Sabíamos que é natural fazer CRUD com o REST, mas e o restante? Um sistema não é formado apenas por CRUD dos dados. Existem perguntas complexas que um sistema deve responder, começando por uma busca de uma palavra num texto até cálculos ou transformações de dados específicos de negócio. RPC? Talvez...

Nessa época caiu na minha mão (via @Dimas) a apresentação "REST in Practice - A Tutorial on Web-based Services", do Jim Webber, Savas Parastatidis e Ian Robinson, nomes que já tinha ouvido falar ao pesquisar sobre SOA e REST. Numa primeira visita, eu pensei que a apresentação era sobre a história das tentativas de Web-services e seus formatos para depois exaltar o quão bom o REST é. Na segunda olhada, com mais cuidado (afinal são 302 slides), me chamou a atenção o conjunto dos conceitos de REST com Hypermedia, HTTP como o protocolo de aplicação, Atom e como tudo isso deveria ser a base para uma arquitetura de um sistema distribuído. Afinal, isso tinha dado certo uma vez: a web funciona assim! Aliás, se olhar os requisitos da nossa plataforma ali em cima, vai ver que a semelhança é grande. Ou seja, parecia que eu tinha encontrado o que estava procurando.

Hypermedia é um conceito que foi citado como parte fundamental do REST no doutorado de Roy Fielding (foi neste trabalho que o termo REST apareceu), mas que foi esquecido no meio do caminho. O foco dado foi exclusivamente sobre o recurso, porém, ao esquecer o conceito de hypermedia, deixou-se de lado como conhecer e navegar nesses recursos.

Utilizar o HTTP como protocolo de aplicação e não apenas como protocolo de transporte (discussão antiga do pessoal do SOAP vs REST) já era algo que desejávamos, mas ao olhar o HTTP de perto, encontramos muito mais do que GET, POST, PUT e o DELETE. Ao entender os verbos, os códigos de retorno e os media types, tem-se um protocolo muito mais complexo e pronto para sistemas distribuídos.

E quando menos se esperava, eis que um padrão XML aparece na nossa frente: Atom. Ali no Atom é que se encontram as ferramentas para tornar o hypermedia viável entre sistemas, pois o conceito de links faz parte do padrão.

Parecia que tínhamos encontrado o que queríamos. Bom, pelo menos no campo teórico... Ao tentarmos implementar, esbarramos em alguns problemas com as libs que dão suporte a esses conceitos. Por exemplo, a especificação Atom dá suporte a uma série de features que não encontramos implementadas em nenhuma lib (Ruby ou Java) e que seriam importantes para nós. E se o HTTP é completo (e, como disse antes, complexo) ao dar suporte a sistemas distribuídos, por outro lado as libs acabam escondendo informações ou bagunçando a idéia do protocolo na tentativa de simplificá-lo.

Para nossa sorte, encontramos o Guilherme Silveira, que já estava envolvido nas discussões sobre REST, Hypermedia e HATEOAS (Hypermedia as the Engine of Application State) e estava implementando o Restfulie, uma lib que busca o REST no seu conceito original, ou seja, com os conceitos de hypermedia e transição de estado, além de ser amigável com o protocolo HTTP em toda sua complexidade.

A história ainda não terminou. Na verdade está apenas no início. Estamos começando a implementar esses conceitos nos novos sistemas, refatorando os antigos sistemas monolíticos para sistemas menores, e ainda começamos a ajudar o Guilherme na evolução do Restfulie. Temos um longo caminho pela frente na construção da nova plataforma, que vai inclusive colocar todas essas idéias a prova. Porém, mais do que nunca, acredito que estamos no caminho certo.

Escalabilidade de web sites /ou: Como é que eles conseguem?

Depois de 6 meses de pesquisa, estou disponibilizando aqui o meu trabalho sobre escalabilidade de web sites que fiz para o meu curso de Pós-graduação.

Apresento no trabalho a análise das arquiteturas de web sites que estão entre os principais sites da internet. Tentei identificar o que faz, do ponto de vista de arquitetura de software, com que eles consigam atender um número muito alto de usuários.

Ai vai: pesquisa e a apresentação

A estrutura empresarial e a qualidade de software /ou: Galera não tá se falando direito...

Esta cada vez mais claro que o desenvolvimento de software é mais do que uma atividade entre pessoas e computadores: é uma atividade social antes de tudo. É social pois depende de comunicação para acontecer.

Dentro de uma empresa a comunicação entre as pessoas passa por hierarquias, processos, etc. que quanto mais complexos, maior serão os ruídos. Ou seja, a qualidade da entrega é extremamente afetada pela estrutura organizacional (Mythical Man Month). Não só a qualidade é afetada mas também a própria entrega toma forma dessa estrutura (Conway's law). Lembra do Waterfall, RUP, XP-SCRUM, etc.? No fundo todos esses processos tentam atacar o problema de comunicação entre os membros de um projeto, seja usando os fantasmagóricos documentos de levantamento, os enigmáticos diagramas UMLs, continuos integration, daily team meetings e afins.

Mas se a qualidade de um software é influenciada pela organização (e como ela gerencia a comunicação), como medir ou prever essa qualidade? Qual métrica organizacional usar para saber se um software vai ser bem construído? Mas e as outras métricas de software (quantidade de linhas de código, cobertura de teste, complexidade ciclomática)? Elas são boas? Afinal, se a organização influencia tanto assim na qualidade da entrega, essas métricas não fazem muito sentido, certo?

Na tentativa de responder a essas perguntas, o ótimo paper "The Influence of Organizational Structure On Software Quality: An Empirical Case Study" estudou as métricas de software e as organizacionais do desenvolvimento do Windows Vista. Eles analisaram dados do controle de versão (libs, quantidade de updates, etc.), adicionaram dados dos funcionários (hierarquias, quantidade de pessoas no time, tempo de empresa, promoções, etc.) e dados de bugs do Vista depois da entrega. Analisando tudo isso (aprox. 50 milhões de linha de código, milhares de pessoas e muitos bugs!), foi possível mostrar que as métricas organizacionais são mais eficientes que as métricas de software (84% contra 79%, no melhor caso) em prever a qualidade do software entregue.

Lembrando que essa é a primeira pesquisa nesse sentido e talvez os números só se apliquem nesse cenário, mas ainda assim reforça (agora com números) o que antes só se tinha a impressão.

Isso que dizer que na próxima vez que você for fazer um check-in no seu source control, pode aparecer uma janela te perguntando qual seu cargo, quem é seu chefe e quantas pessoas tem na sua equipe e, depois do "ok", a IDE vai te mostrar as partes do código que tem uma grande chance de dar erro. Não porque tem muitos IFs ou o teste não passou por ali, mas porque a "galera não tá se falando direito".

RefList Cache /ou: Piece of cake!

Quem já usou cache para uma aplicação web sabe: o que no começo parece simple, é mais complicada do que parece.

Um dos maiores problemas de cache é a invalidação. Quando invalidar? Onde invalidar?

Vou contar a história do projeto que participei a um ano atrás, o Gostei.com, onde o uso de memcached é extenso. Tínhamos o seguinte problema: um mesmo post pode aparecer em várias listas, sendo que estas listas poderiam ter ordenações e filtros diferentes. Mas se o post sofresse alguma alteração, como um novo voto, o número de votos tinha que ser igual em todas as listas.

A primeira abordagem foi um pouco ingênua: serializar e guardar no cache a lista inteira (List<Post>), incluindo o post junto. O problema é que a quantidade de votos de um post pertence a classe Post, tínhamos uma quantidade de votos diferente em cada lista (lista diversão-mais_votados e todos-mais_recentes, por exemplo) para o mesmo post. Era impossível saber em quais listas aquele post foi cacheado.

A solução foi usar o que chamamos de RefList Cache. Ao invés de guardar a lista com os posts, cacheamos a lista com os IDs dos posts (List<Guid>) e para cada post existe apenas um lugar no cache (uma key única). Assim, quando um post sofrer alguma alteração, basta atualizar invalidar o cache em um único lugar. Graças a um recurso do memcached (get_multi), é possível ter o RefList e todos os item com apenas duas chamadas.





Piece of cake! Quer dizer... nem tanto. Ainda tem um problema. Nada garante que todos os IDs da RefList vão estar no cache. O que fazer? Um dos recursos da lib que criamos é o conceito de hierarquia de repositório, onde é possível dizer a ordem dos locais onde a lib vai procurar pelo dado (Local Cache, Memcached, DB). Por exemplo, caso metade dos posts estiver no cache, a lib vai tentar pegar a outra metade no banco.

Aqui tem uma apresentação que ajuda a explicar a idéia: PPT.

Sweet! :)

Stil 2009 /ou: Huge Burgers!

E eu estive no Stil 2009. Quatro dias intensos de apresentações e workshops acadêmicos sobre computação lingüística (justo Eu, que nunca fui um grande expert na segunda área, como alguns leitores desse blog já notaram).

Como não sou pesquisador nem professor, fui de xereta para entender melhor o que é essa tal "computação lingüística" e ver onde estamos em relação a pesquisas aqui no Brasil. Afinal onde eu trabalho produz muito texto e não é difícil pensar em coisas interessantes que se pode fazer com todo esse texto.

Como podia-se esperar, assisti trabalhos/apresentações excelentes e também trabalhos menores, porém, no geral, me agradou bastante. Conheci bastante gente e pude aprender mais sobre o tema. Aquele livro que fica na minha mesa já não me assusta tanto assim.

Uma coisa chamou bastante a minha atenção: eu era a única pessoa representando uma empresa! Eram mais de 100 pessoas e só uma delas (Yo!) tinha interesses não acadêmicos no que estava sendo apresentado. Existe uma distância entre a academia e as empresas? Não preciso nem comentar...

No mais, São Carlos não tem lá muita coisa pra fazer e, talvez por isso, muito simpática. Ah.. vale destacar o tradicional lanche do interior (#huge #WTF!?!).

Como estatística pode enganar júris /ou: Deixa pra quem sabe...

Nossa racionalização do incerto é no mínimo falha. Este vídeo mostra como profissionais não qualificados em lidar com os números estatísticos são levados a tirar conclusões erradas sendo algumas delas com graves conseqüências.

Diagram.Net on Mono /ou: No Linux também rola...

Depois de descobrir um bug no compilador do Mono C#, mudar algumas linhas de código aqui e ali, consegui fazer o Diagram.Net rodar no Linux. Cool!

Local Solr /ou: Don't give up!

It seems that Patrick is going to give up! Patrick: DON'T GIVE UP!

If there is anything we can do to help, please, let us know!

Distribuindo Processamento 2 /ou: Mais um pra lista de estudos...

Hoje assisti o video Functions + Messages + Concurrency = Erlang. Eu sabia que Erlang era uma linguagem desenvolvida para processamento paralelo (entre outras coisas). Mas o que eu não sabia era que é possível ter também processamento distribuído! Fazendo download do último release agora!

Distribuindo Processamento /ou: fica ai a dica…

Tenho acompanhado com certo afinco três tecnologias: PLINQ, CUDA e HADOOP. O meu interesse existe pois todas essas tecnologias são de alguma forma uma solução para o processamento paralelo. Afinal, como processar toda a montanha de dados que nos circula (tema mais do que recorrente neste blog)?

Essas tecnologias usam abordagens diferentes para distribuir o processamento: PLINQ: CPUs locais; CUDA: GPUs; e HADOOP: SERVERs (CPUs distribuídas).

O PLINQ (e sua infra-estrutura) tenta usar os processadores disponíveis em uma CPU (normalmente de 2 a 8) para realizar o processamento paralelo.

Outra forma de processar dados é utilizando a GPU do seu computador (e você pensou que ela servia só para games?). CUDA é a arquitetura criada pela NVidia que auxilia a distribuição do processamento entre esses pequenos processadores (norma lmente 128!).

Já o Hadoop auxilia distribuir o processamento entre muitos computadores. E eles podem ser muitos!

O interessante em estudar essas tecnologias é que os conceitos (particionamento, shared resources, locks, etc.) são válidos para os três cenários. E muito dos problemas também são os mesmos. Acho que o principal é a dificuldade em abstrair o fato de existir o processamento paralelo.

Bom, para os interessados em processamento distribuído, paralelo, cloud, grid e afins, fica ai a dica de estudo.

Numerati na Publicidade /ou: Miracle Banana Diet

Via TheNumerati.Net

The Unreasonable Effectiveness of Data /ou: O caos é bom

Na mesma linha do The End of Theory: The Data Deluge Makes the Scientific Method Obsolete, o artigo The Unreasonable Effectiveness of Data destaca principalmente como uma grande quantidade de dados pode ajudar na computação linguística.

Do artigo:

Eugene Wigner’s article “The Unreasonable Effectiveness of Mathematics in the Natural Sciences” examines why so much of physics can be neatly explained with simple mathematical formulas such as f = ma or e = mc2. Meanwhile, sciences that involve human beings rather than elementary particles have proven more resistant to elegant mathematics. Economists suffer from physics envy over their inability to neatly model human behavior. An informal, incomplete grammar of the English language runs over 1,700 pages. Perhaps when it comes to natural language processing and related fields, we’re doomed to complex theories that will never have the elegance of physics equations. But if that’s so, we should stop acting as if our goal is to author extremely elegant theories, and instead embrace complexity and make use of the best ally we have: the unreasonable effectiveness of data.

...

The first lesson of Web-scale learning is to use available large-scale data rather than hoping for annotated data that isn’t available.

Value pela dica Daniel!

Dados /ou: Ainda não o suficiente

Recentemente tenho postado sobre a montanha de dados que temos na nossa frente e não sabemos o que fazer com ela.

Mas parece que não temos dados suficiente ainda!

Segundo Tim Berners-Lee, criador da WWW, os dados estão presos e o que temos hoje é difícil de ser obtido, formato em documento, ou está escondido. Ele pede que liberem esses dados de forma "crua" o mais rápido possível. Ai vai o vídeo que ele fez para o TED 2009:

[OFFTOPIC] Sociedade do Automóvel

Este blog defende a idéia de que há vida após o carro, principalmente aqui em São Paulo. Enquanto um outro blog não sai, aqui vai uma dica legal sobre o assunto:

Sociedade do Automóvel


O movimento para utilização de bicicleta como alternativa ao carro é bem forte, com dezenas de blogs, e bacana por um lado. Porém acredito que não seja a única solução. Vou tentar encontrar mais informações sobre isso e, quem sabe, montar um blog no futuro. Mais alguem interessado?

Dados /ou: Sobrevivendo ao dilúvio

Coisa rápida. Apenas para reforçar os últimos posts.

Olha a capa da ACM Communications de Dezembro/2008: Surviving the Data Deluge

Estatística /ou: Os novos Samurais

Quem acompanha este blog deve ter percebido que o assunto desenvolvimento tem saído de cena aos poucos e outros temas tem tomado seu lugar: data mining, inteligência coletiva, web 2.0, etc.

Motivo: desenvolvimento é um problema resolvido.

Chegamos num estágio que as atuais metodologias e técnicas conseguem atingir a raiz do problema de desenvolvimento de software, por motivos que deixarei pra um futuro post, mas, resumidamente: afinal entregamos com qualidade, sempre!

E apesar de ainda termos infinitas discussões sobre TDD, BDD, XP, SCRUM, etc., vemos que o cliente (Product Owner, por exemplo) já está muito contente com o resultado. Novamente, afinal, entregamos com qualidade!

Sim, ainda temos que quebrar a cabeça em criar uma abstração do problema real e colocar essa coisa pra rodar. Mas depois fazer isso muitas vezes, convenhamos, fica chato... e não importa se isso é traduzido para LISP, C#, Haskell ou JScript.

Bom... o que um cientista da computação faz com um problema resolvido? Encontra outro problema!

O problema que me propus a resolver (pretensioso, claro!) é: geramos uma quantidade de dados enorme pelas infinitas aplicações que desenvolvemos. O que fazemos com isso? Atualmente estamos olhando para uma montanha de dados de tamanho colossal. Mas não conseguimos encontrar muita coisa ali. Olhamos.... E olhamos mais um pouco.... E nada aparece.

O que será que podemos fazer com esse monte de "nada"?

O que estou vendo acontecer é que sai a era do exato, bit e bytes, zeros e uns, e entra a era da estatística, da probabilidade, da aceitação da falta de exatidão...

Será? Bom... se você ainda tem alguma dúvida, dá uma olhada nesse trecho de post do blog oficial do Google:

Hal Varian likes to say that the sexy job in the next ten years will be statisticians. After all, who would have guessed that computer engineers would be the cool job of the 90s? When every business has free and ubiquitous data, the ability to understand it and extract value from it becomes the complimentary scarce factor. It leads to intelligence, and the intelligent business is the successful business, regardless of its size. Data is the sword of the 21st century, those who wield it well, the Samurai.

Estou longe de ser um Samurai, mas já estou fazendo aula de japonês.

Crise mundial e o Desemprego /ou: A ocasião faz o ladrão

Programming Interviews Exposed: Secrets to Landing Your Next Job, 2nd

Se um programador der preferência por ler um livro como este ao invés de ler um livro técnico, algo não está certo na carreira dessa pessoa. Seja com crise ou sem crise.

The Numerati /ou: Rastros digitais

Comprar no supermercado, assistir ao canal digital, navegar pela internet, enviar um e-mail, pagar uma compra com seu cartão ou criar um post no seu blog. Ações sem muita importância, certo? Afinal de contas, que importância tem aquele molho especial que você comprou pra tentar na salada nova? Infelizmente, esse molho e o padrão de escrita de seus posts e os canais de TV que você assiste coincidem com o comportamento dos 89% dos terroristas conhecidos. Você agora é vigiado e talvez passe um tempo em salas de interrogatórios tentando explicar porque comprou aquele maldito molho.

O exemplo é exagerado, eu sei, mas é apenas para mostrar que hoje em dia qualquer “ação digital” que fazemos deixa um rastro que pode ser computada e assim achar padrões para os mais diversificados propósitos.

Mostrar o que está sendo feito com esses dados e o que ainda está por vir é intenção do livro The Numerati.

Um livro leve, que não tem a pretensão de explicar a matemática, estatística e os algoritmos por trás do mundo de mineração de dados, mas sim mostrar onde e como essa ciência está sendo aplicada. Trabalho, compras, política, internet, segurança e terrorismo, saúde e relacionamento são os principais tópicos, estudados um por um, apresentam detalhes que não sabíamos antes e que só os números e a computação podem nos mostrar.

Isso acaba levantando questões sobre privacidade, legalidade e até onde o seu molho especial diz algo sobre você.

Recomendo a leitura.

Como a mente funciona /ou: 4 bilhões de registradores

Quando um autor cita num mesmo livro Isaac Asimov, Charles Darwin, Alan Turing e Richard Dawkins para explicar o funcionamento da mente humana, aprende-se acidentalmente alguma coisa sobre nosso cérebro e como ele funciona.

Para quem ainda não leu "Como a mente funciona", fica aqui a forte recomendação.

João e Ciça, obrigado novamente pelo presente!