February 18th, 2010 § 0
Incômodo, um balanço arriado,
uma lasca na mão, um caco de vidro no pé.
Subindo pela garganta,
o sangue quente, a alma talhada.
Um grito contido,
a voz que reluta em sair.
Não me enxerga?
Não me vê?
Vou berrar pelos cantos da terra,
aquilo que só eu posso perceber.
Se ninguém mais entender,
a culpa é de quem?
January 26th, 2010 § 7
Hoje é 13 de junho de 2078. Quase esqueci do dia em particular, mas já se vão cem anos desde que meu avô paterno nasceu. Faz um certo tempo desde que ele morreu e ainda eu sinto muita saudade dele. Sempre vou sentir.
Meu avô paterno era um otimista tecnológico nato. Para alguém que considerava ficção científica seu gênero favorito de leitura isso não é de se espantar. Ele ainda viveu para ver muitos dos sonhos da ficção científica realizado e tenho certeza de que teria adorado as mudanças que ainda estão acontecendo.
Meu avô não era um cara que gostava de ficar contando histórias sobre o passado sentado com os netos. Ele gostava de contar histórias sobre o futuro, sobre o que já existia e sobre o que aquilo poderia virar. Eu me lembro de ficar horas sentado no chão da sala enquanto ele falava sobre autores e mais autores, séries e filmes de ficção e como aquilo que esperamos é ao mesmo tempo tão pouco e tão excessivo.
Um das coisas em que meu avô não acreditava era na Singularidade Tecnológica–o momento em que a tecnologia se expandiria além do que a humanidade como um todo fosse capaz de entender e manipular. Não porque era um homem religioso–ele era–mas porque acreditava que alguma coisa aconteceria antes que permitiria ao próprio homem o controle próprio da tecnologia em qualquer escala necessária. Em outras palavras, a tecnologia cresceria junto com a próprio humanidade. Até o momento, isso é o que parece estar acontecendo. Eu ainda não me decidi sobre a Singularidade, mas gosto da visão do meu avô.
Se ele estivesse aqui, ele provavelmente entenderia a maioria da tecnologia que é usada no dia-a-dia, mesmo que o uso pleno do que vem natualmente para nós lhe escapasse. Tecnologia, afinal de contas, é uma habilidade adquirida e cada geração enfrenta seus problemas de adaptação. Não duvido nada que um filho ou um neto poderão escrever a mesma coisa de mim um dia.
É claro que toda tecnologia tem seu preço e isso continua válido. Ainda estamos bem longe de uma solução para o clima, por exemplo, mesmo com toda a parafernália de seqüestro de carbono que já foi desenvolvida. As tempestades e disfunções climáticas ainda estão piorando e eu fico pensando nas obras de Kim Stanley Robinson e Peter Hamilton. De onde estamos hoje para a corrente do Golfo parar ou algo com as tempestades armada se tornarem reais não é uma distância muito grande. Acho que vamos conseguir escapar do pior, mas vai ser pouco.
Por outro lado, com ambientes consensuais de trabalho, dois grandes problemas já se foram e seus resultados já estão se fazendo notar. O trânsito agora existe quase que exclusivamente por conta de lazer e de mão de obra que precisa de local. Mas o efeito de bilhões de pessoas que não precisam mais ir para o trabalho todo o dia pode dobrar alguns balanços em nosso favor. Depois que provaram que P=NP, não foi muito difícil desenvolver um sistema automatizado emergente para cuidar de tudo. A mesma coisa para a quantidade enorme de prédios que existiam somente para servirem de um ponto comum de trabalho. Seria difícil para a maioria das pessoas nascidas há cem anos atrás imaginar isso, é claro.
Se meu avô estivesse aqui, talvez a mudança que mais lhe teria interessado seria convergência final de dispositivos. Ele não viveu para ver o fim do celular, televisão, rádio, computadores, notebooks, tablets, coisas que eram tão comuns quando ele estava no auge de sua carreira mas provavelmente teria se sentido relativamente confortável com um implante inscape e com os primeiros protótipos de HUDs. Tudo sobre o que um de seus autores favoritos, Charles Stross, falava e escrevia nos idos dos anos 20.
É, eu sinto falta de meu avô. Gostaria que ele estivesse aqui para compartilhar as próximas grandes mudanças. Mas não importa: eu sei que a imaginação foi suficiente. Espero que a minha seja também.
January 22nd, 2010 § 0
Dezembro foi mês de final de trabalho e começo de férias e confesso que fiquei com preguiça depois de alguns dias na moleza. Enfim, isso deveria ter sido postado no ano passado, mas para não deixar passar batido. O resultado do mês foi o seguinte:
Nos livros, comecei o mês com Managing Humans, de Michael Lopps. Lopps é muito conhecido pelo seu blog Rands in Repose e o livro é um compilação de textos publicados no mesmo durante alguns anos. Eu leio o blog há algum tempo já e considero Lopps um dos melhores escritores no estilo. Além da clareza e atualidade do temas, Lopps consegue destilar seu conhecimento com humor e maestria, deixando o leitor sempre querendo um pouco mais.
Managing Humans é, em primeira instância um livro sobre gerência, mas não gerência no sentido de “mandar” em outras pessoas–antes, é uma visão de relacionamento, habilidades e construção de carreira baseados em quinze anos de experiência do autor. Apesar de voltado especialmente para engenheiros de software, os conselhos servem para qualquer pessoa, seja gerido ou gestor (o que é, de um ponto de vista bem prático, o caso de praticamente todos nós). Como Lopps diz na introdução, a mensagem primária do livro é: “Don’t be a prick”. Recomendado em todos os sentidos.
O livro seguinte do mês foi The Silmarillion, o conhecido épico mitológico de J. R. R. Tolkien. Eu já lera o livro algumas vezes antes, emprestado, e, depois de comprá-lo finalmente, decidi por mais uma leitura. Ainda permanece o meu preferido entre os trabalhos do Professor. O senso de mito, de estória se desenrolando ao longo dos milênios e de perda é tão forte que é impossível não se impressionar.
Para terminar o mês, li os dois primeiros livros da trilogia The Night’s Dawn Trilogy, do Peter Hamilton (The Reality Dysfunction e The Neutronium Alchemist). Hamilton é um dos que eu inclui em minhas leituras essenciais de ficção científica no ano passado e essa trilogia é um dos seus primeiros trabalhos.
Os livros contam da humanidade do século vinte e sete, divididos em duas grandes correntes: edenistas, com sua tecnologia biológica e baseada em inteligências artificiais com cultura unificada e, até certo ponto, utópica; e os adamistas, os humanos “normais”, usuários de tecnologia não-orgânica baseada em nanotecnologia.
As duas culturas convivem em paz, habitando os cerca de 900 planetas colonizados pela humanidade em uma organização conhecida com a Confederação, com algum contato alienígena no meio, até que uma ruptura no tecido da realidade libera algo desconhecido que ameaça não só a Confederação mas a própria definição do que é ser humano e do que representam a vida e a morte.
Como nos livros de Hamilton que já li, a estória é enorme e envolve dezenas de personagens primários, secundários e terciários com múltiplos temas permeando a narrativa. O autor cria um mundo verossímil e complexo tanto em termos da descrição das múltiplas facções e divisões da humanidade como na tecnologia descrita. Fiquei especialmente encantado com os voidhawks, naves estelares orgânicas sencientes unidas a seus capitães via uma tecnologia orgânica chamada de afinidade e capazes de navegação FTL.
Os livros–três calhamaços, por sinal–exploram, como é comum nos trabalhos de Hamilton, o fato de que, apesar de toda tecnologia, ainda permanecemos essencialmente a mesma espécie, com suas falhas, aspirações e forças. Essa exploração não é isenta de falhas–o final é um enorme, embora preparado, deus ex machina–e o estilo é deficitário em relação aos seus trabalhos posteriores. Mesmo assim, ainda vale a pena a leitura.
Nos filmes, comecei o mês vendo The Jane Austen Book Club. Alguém me recomendou o filme como sendo um comédia romântica decente envolvendo ficção científica e Jane Austen–dois temas que eu gosto. Com a esposa, me anime a ver e gostei. Não é muito diferente do usual em comédias românticas mas é divertido o suficiente. Depois descobri que é baseado em um livro do mesmo nome por um autor que, entre outras coisas, escreve ficção científica. Destaque especial para as obras de Ursula Le Guin que são um plot point.
Depois disso foi a vez de Okuriburo (lançado do Brasil como A Partida). O filme conta a estória de um recém-desempregado músico japonês que decide volta à sua pequena cidade natal em busca de um novo começo. Ao chegar à cidade, responde um classificado para um emprego que acredita ser em uma agência de viagens e descobre que, na verdade, é para ser um profissional que prepara pessoas para o enterro (para a partida). À medida em que ele começa encontrar sentido em seu trabalho e sua vida, começa a perder seus amigos e mesmo sua esposa que desprezam o trabalho. O filme é belíssimo, profundo e cômico ao mesmo tempo, explorando a vida, suas alegrias e tristezas. Confesso que ri e chorei durante quase o filme todo. Recomendo completamente.
Na seqüência, assisti Pandorum. Descobri quase por acaso durante minhas tradicionais andanças por listas de discussão de ficção científica. O filme conta a estória de dois membros da tripulação de uma nave generacional humana em meio à sua viagem para colonizar um planeta distante. Os dois tripulantes acordam para o seu turno de trabalho encontrando uma nave abandonada e às beiras de um colapso sistêmico. Tentando descobrir o que está acontecendo, encontram algo aterrorizador. A estória é clássica e contada em inúmeros filmes e foi um fracasso de público mas tem suas boas qualidades. Gostei das variações sobre o tema, focando mais nos personagens do que na situação em si e nas conseqüências dos problemas da nave. A fotografia também é muito boa e o final foi bastante satisfatório. Vale a pena para fãs do gênero.
Depois disso foi a vez de Avatar. Como todo mundo já deve ter visto a essa altura do campeonato, vou me limitar a algumas impressões básicas. Sim, a estória é batida e já contada milhares de vezes, mas não são todas elas? Já se disse que só existem algumas estórias básicas e o mérito está em como se conta. Isso é algo que acredito que Cameron consegui, contando a mesma estória de uma forma feita nova pela tecnologia e pela beleza da arte do filme. Gostei especialmente do cuidado dado aos detalhes científicos do filme e, se Cameron escorrega em alguns pontos, acerta mais ainda. Fica uma sensação de que o roteiro original era bem melhor, mas isso é algo que também pode ser corrigido em parte com uma versão do diretor. Se Lucas pode, Cameron também.
Depois foi a vez de Crank 2 e Gamer. Os dois filmes são escritos e dirigidos pela mesma dupla e são essencialmente a mesma estória fraca recheada de ação contínua e sem sentido mesclada entre cenas de sexo e violência gratuitos. Eu gosto tanto de Gerard Butler quanto de Jason Statham, muito em parte pela capacidade que os dois possuem de auto-ironia mas os filmes são definitivamente descartáveis.
New Moon, 17 Again, Push e Thick as Thieves foram programas de pré-Natal–suportáveis mas algumas poucas horas perdidas. No caso do último, nem a presença de Antonio Banderas e Morgan Freeman consegue ajudar. Aliás, Banderas parece que se especializou no papel agente da lei genérico infiltrado no últimos anos. Haja paciência.
No próximo mês, mais livros, filmes e passeios.
January 21st, 2010 § 2
O céu está daquela cor outra vez. Cor de céu de fim de ano, um vermelho pálido como a cor das coisas que se vão. E não é de se admirar: dez anos já, dez anos desde o início de um milênio que prometia muito mas só trouxe mais do mesmo.
Você vê: neste ano, perdemos pouco mais perdemos o suficiente para enxergar que não há tanta coisa assim à nossa frente. Meu Deus, Brittany Murphy morreu domingo passado. Ela só tinha trinta dois anos–eu tenho trinta e um. E morreu também Michael Jackson. Eu não gostava de sua música. Eu tinha, sim, pena de sua conturbada e desperdiçada vida. Tão desperdiçada que seus olhos contavam, cantavam toda uma não-história para quem quisesse escutar. E nós o considerávamos imortal, mesmo assim.
Mas é fim de ano outra vez. Fim de um ano de muito pouco para lembrar além do massacrante mover dos nefastos mecanismos do dia-a-dia. Zeus do alto do Olimpo olhando para os pobres mortais, seus irmãos sorrindo diante do plano que traçaram para aqueles que nada conhecem. Maldito sejam os deuses.
E, sim, é fim de ano mais uma vez. Que finde em paz. Em jazz e em blues. Notas em uma guitarra fosca, quase desafinada. Blind Lemon Jefferson cantando “Backwater rising”, an end of year blues.
December 28th, 2009 § 3
Estou de férias, depois de um mês final intenso de trabalho, o que significa que o blog está meio abandonado nesses últimos dias do ano. Mesmo assim, decidi manter pelo menos a tradição dos balanços culturais mensais para terminar o ano e começar 2010 com novos textos que estou escrevendo entre um passeio e outro.
Novembro foi um mês regular, com o seguinte resultado:
Nos livros, comecei o mês com The Accidental Time Machine, do Joe Haldeman. Embora Haldeman seja bem famoso por seus trabalhos anteriores, esse é apenas o segundo dos seus livros que leio–ambos sendo produções mais recentes. Como eu tinha escrito anteriormente, também, The Accidental Time Machine é um homenagem cheia de humor e bem embasada cientificamente de todas estórias de viagem do tempo que já foram escritas. Quando um assistente de pesquisa do MIT chamado Matthew Fuller inventa sem querer uma máquina de viajar no tempo e descobre que ela somente vai para o futuro, ele se vê jogado para longe de sua época e envolvido cada vez mais em situações que não pode controlar. A leitura é rápida–o livro é quase uma noveleta–mas demonstra o talento de Haldeman em criar situações críveis com pouco esforço.
Segui o mês lendo Numerati, do Stephen Baker. O objetivo do livro é falar sobre como a matemática está sendo empregada para processar quantidades enormes de dados, modificando como vários campos e áreas de atuação humana funcionam, incluindo medicina, compras, segurança, saúde e mesmo relacionamentos. Um dos focos primários do livro é a Internet, é claro, e como os traços que deixamos na mesma são parte desses dados e como isso pode ajudar ou, em alguns casos, piorar a forma como vivemos e vemos o mundo.
A premissa do livro é interessante mas ele cai no mesmo problema de muitos outros livros sobre assuntos similares publicados nos últimos dois ou três anos: essencialmente, o livro é um artigo longo que foi transformado em uma obra impressa pelo expediente de clonar e adaptar o mesmo tópico vez após vez. Todos os capítulos do livro possuem exatamente a mesma estrutura: um, o campo X está produzindo quantidade enormes de dados; dois, nesse campo X, matemáticos estão usando os dados para tentar entender melhor o mesmo; três, no campo X, a matemática ainda não é suficiente para fazer o que esses pesquisadores querem; quatro, um dia a matemática vai ser; e assim por diante. Funciona para o primeiro capítulo, mas deixa os demais bem tediosos.
Fechei o mês lendo Saturn’s Children, do Charles Stross. Como já mencionei aqui várias vezes, Stross é um dos meus autores favoritos e seus livros raramente decepcionam. Saturn’s Children é sua space opera mais recente, contando sobre um futuro em que a espécie humana se tornou extinta e o Sistema Solar foi colonizado pelos andróides que serviam a humanidade antes de sua saída do palco cósmico. O livro segue Freya Nakamichi-47, uma bishōjo ginóide, que acaba se indispondo com a aristocracia cibernética e é forçada a se envolver com uma corporação de couriers para conseguir escapar se seus perseguidores, descobrindo no processo uma conspiração para controlar a sociedade andróide.
Como todo Stross, o livro é recheado de conceitos exuberantemente futuristas e possui uma estória interessante. Entretanto, ao contrário de seus trabalhos anteriores, senti uma certa necessidade de exagerar na exploração da sociedade andróide–que, obviamente, é fundamentalmente diferente da nossa sociedade e, como em todo trabalho de ficção científica, difícil de precisar–e também uma certa dificuldade em manter o balanço entre explicar e esconder a conspiração para não deixar a estória vazia. Stross sucede em contar a estória bem, mas acaba tendo que correr no final e explicar mais do que o necessário. Bom, mas não seu melhor trabalho.
Nos filmes, comecei o mês com Battlestar Galactica: The Plan, um filme feito após o fim de série que se propõe a contar um pouco mais sobre os motivos dos cylons em exterminar a humanidade. O filme superpõe cenas retiradas da série, para contextualização, com material novo exclusivamente do ponto de vista dos vários modelos dos cylons. O material novo é focado bastante nas especulações e motivações de dois Number Ones (Cavil) que se vêem em espectros opostos do pensamento cylon. Interessante, e com algumas boas cenas, mas dificilmente acrescenta algo ao que a série tinha mostrado.
Depois disso, foi a vez de 2012. Previsivelmente, o filme é bem descerebrado e só conta pelos efeitos especiais que dominam 90% das cenas. Vale a pena ser visto como um filme de desastre para acabar com todos filmes de desastre–e diverte nesse aspecto–mas só por isso mesmo.
Na seqüência, vi Law Abiding Citizen. Esse era um dos filmes do ano que eu estava esperando com bastante expectativa pela possibilidade de ser um novo Se7en, ou seja, perturbador mas sublime em contar uma estória violenta em que todas as pontas de encontram. Infelizmente, após um começo bom mostra-se incapaz de manter qualquer coerência e termina em um final ridículo e sem sentido, contrariando o resto do filme. Desapontou.
Os três filmes restantes foram Ghosts of Girlfriends Past (um tentativa de parodiar Dickens romanticamente), He’s Just Not That Into You e The Accidental Husband, parte da cota mensal de filmes românticos escolhidos pela esposa. Como ela mesmo comentou após um deles: não valem o DVD em que estão sendo distribuídos.
December 3rd, 2009 § 1
Outubro foi um mês um pouco mais produtivo do que setembro para minhas leituras. O resultado do mês foi o seguinte:
Comecei o mês lendo The Anubis Gates, por Tim Powers. Powers é um autor que consegue pegar idéias incrivelmente díspares e transformar em uma obra de arte. Eu não vou me alongar muito já que fiz uma resenha mais detalhada no mês retrasado, mas deixo a minha recomendação de leitura para fãs de fantasia e ficção histórica.
Continuei o mês lendo o volume oito da série Caballo de Troya do J. J. Benítez. Apesar do pesares e da fama ou infâmia dos livros, eu gostei muito dos quatro primeiros volumes, e acho que o Benítez conta uma boa estória quando quer. Infelizmente, os volumes mais recentes não estão à altura dos anteriores e representa mais uma tentativa à la Paulo Coelho de recolher o máximo de uma série que já deu o que tinha que dar. Benítez, inclusive, adotou a estratégia bizarra de terminar os livros em um cliffhanger sem sentido bem no meio de uma cena que continua no próximo livro. O resultado é frustrante para qualquer leitor, é claro. Como sou insistente, é bem possível que eu continue a ler a série pelo menos para ver até onde a coisa vai dar. Mas, se você não começou, evite.
Na seqüência, li Permanence, do Karl Schroeder. Já tinha lido dois de seus livros anteriores–Ventus e Lady of Mazes–que se passam dentro de universos com características bem similares e gostei muito da sua mistura de space opera com o pós-humanismo. Permanence é a estória de um jovem que encontra um artefato alienígena–uma grande nave generacional desabitada, capaz de abrigar múltiplas espécies–que promete respostas transformadoras para a sua civilização e precisa lidar com as conseqüências disso ao mesmo tempo que se liberta do seu passado. Em uma galáxia dividida entre mundos halo e mundos iluminados–estes últimos locais onde viagens em velocidade maior do que a luz é possível e governados por uma economia tirânica–o artefato promete uma resposta para a continuidade da humanidade.
Finalmente, li To Your Scattered Bodies Go, de Philip José Farmer. O livro é o primeiro de uma série chamada Riverworld que descreve um planeta distante tanto no espaço quanto do tempo da Terra consistindo basicamente de um rio incrivelmente longo nas margens do qual toda a humanidade que já existiu desde os primórdios da Neolítico até o século vinte é ressuscitada simultaneamente e misturada. Neste primeiro livro, essencialmente seguimos um grupo centrado em Sir Richard Francis Burton, explorando os eventos logo após a ressurreição e a tentativa por parte desse grupo de entender o que está acontecendo. O livro é bastante divertido–especialmente pelo caráter cômico de diferentes culturas interagindo em um ambiente novo e hostil onde convenções sociais são derrubada a toda instante–mas termina de forma mais abrupta sem revelar muito sobre o mundo e sobre os motivos por trás da relocação da humanidade. Gostei o suficiente para querer ler os demais livros.
Nos filmes, comecei o mês vendo o incrível District 9, sobre o qual falei um pouco anteriormente. Não vou me alongar mais a não ser para me repetir ao dizer que este foi o melhor filme do ano e tem tudo para se transformar em um clássico do gênero de ficção científica.
Na seqüência, assisti novamente Watchmen. Vi a primeira vez em condições menos do que ideais e foi bom assistir novamente e perceber que continuei gostando tanto quanto da primeira vez. A adaptação realmente ficou muito boa e se há algum infidelidade à estória original isso não detrai da qualidade da obra.
Continuei vendo State of Play, um thriller policial bem fraco com Russell Crowe e Ben Affleck, lidando com a morte da amante de um congressista americano e a investigação da mesma por parte da polícia e um jornalista. O filme é um remake de uma série da BBC que, pelas indicações do IMDB, é bem melhor do que sua revisão.
O penúltimo filme do mês foi Surrogates, uma adaptação com Bruce Willis e Radha Mitchell de quadrinhos do mesmo nome contando sobre um mundo em que todos humanos usam corpos artificiais para interagirem com o mundo real. Esses corpos, perfeitos e robóticos, conseguem passar todas as sensações para o seu usuário e são uma forma perfeita de proteção, inviolável e seguros. Quando alguém começa a exterminar esses substitutos, o personagem policial de Willis pega o caso e descobre que há algo maior em progresso. O filme é bem interessante em seus questionamentos e o final, se relativamente fraco, termina o filme de maneira decente. Recomendado.
Para terminar o mês, asssisti Duplicity, uma divertida comédia com Clive Owen e Julia Roberts sobre dois agentes secretos que decidem agir em conjunto para dar um golpe em seus clientes. A dinâmica dos dois atores principais–que eu já tinha admirado em Closer–é muito boa e funciona muito bem ao longo de todo o filme. O final é diferente do usual e foi bem satisfatório.
No próximo mês, bons livros e filmes ruins. 
November 28th, 2009 § 1
Hoje, sábado de sol, está acontecendo o Dev In Sampa, um evento de desenvolvedores para desenvolvedores. Se você não conseguiu participar por algum motivo, pode acompanhar um pouco pelo livestream do evento–as palestras estão excelentes. Mas não se preocupe, as palestras estão sendo filmadas também e serão disponibilizadas após o evento.
Eu participei falando sobre a criação de linguagens de programação e para os que já querem ver alguma coisa, segue abaixo a apresentação do SlideShare:
O repositório da toy language que eu criei para demonstração já está disponível também no GitHub. Só não espere muito do código já que ele foi produzido em pouco tempo em madrugadas disponíveis.
Para o resto, a caixa de comentários está aberta.
November 16th, 2009 § 3
Isso é lindo:
[T]he State of the End-User Environment / Programming Onion…
So, in a confluence of events, I have been lately looking at Scala and yesterday spent some time looking at Pike / Thompson / Google et. al.’s “Go” language for “systems programming.” And Guido halts Python syntactic evolution before the job is done…
And it fills me with despair and anger.
Language designers in general: You are IN THE WAY. Go here:
http://www.rebol.com/oneliners.html
…then do us all a favor and don’t resist the urge to fall on that wakizashi when your shame overcomes you.
Leia mais em [FoRK] Programming languages, operating systems, despair and anger. A sensação com Go foi exatamente a que eu tive: conceitos razoavelmente interessantes empacotados em uma sintaxe que só ajuda a piorar o que havia antes.
É claro que não há balas de prata, mas há de se pensar em algo que quebre o molde que estamos usando nas últimas décadas.
November 11th, 2009 § 7
Um amigo de Belo Horizonte me consultou esses dias sobre uma questão fundamental para a aplicação que ele está planejando começar a escrever nos próximos dias: framework de programação usar (e por extensão, qual linguagem)?
Como minha experiência nos últimos tempos tem sido confessadamente restrita a Rails e alguns experimentos em outros, resolvi apelar para a caridade dos meus leitores. Qual framework você usaria para seu próximo projeto?
Esse meu amigo não tem problemas com linguagens de programação em si. De fato, a não ser que seja algo tão esotérico quando Haskell ou Erlang, ele é capaz de se familiarizar com uma linguagem ou framework em alguns dias.
Obviamente, não posso dar muitos detalhes sobre a aplicação, mas dá para dizer que o objetivo é escalar gradualmente. Ela não precisar começar escalando para o mundo inteiro, mas um caminho seria bom. Um outro detalhe nesse aspecto é que a aplicação é comparativamente particionada: um usuário terá acesso a alguns itens e compartilhará esse acesso com algumas dezenas ou centenas de pessoas. Esses itens possuem moldes variáveis e seriam bom ter flexibilidade na criação do mesmos.
Finalmente, hospedagem é uma questão também. Não necessariamente preço, mas facilidade. Linode é uma opção mas preferivelmente algo que possa ser colocado em alguma coisa pequena e ir escalando conforme a necessidade, no estilo do Heroku (o que limitaria a Rails, claro). Python parece uma boa opção, mas ele precisa de evidências.
E aí, alguém anima a ajudar um pobre compadre em armas? 
November 9th, 2009 § 9
O Lucas Húngaro, que trabalhou comigo na WebCo, escreveu há poucos dias um artigo muito bom sobre a dificuldade de dissociar nomes e funções em projetos de software e sobre sua visão do processo de desenvolvimento e arquitetura. Desnecessário dizer, concordo essencialmente com tudo o que ele diz, com algumas pequenas ressalvas.
O leitor atento do blog deve estar se perguntando agora: mas, há menos de uma semana, você não disse que lidera uma equipe separada de arquitetura onde trabalha agora–isso não é uma contradição? Na verdade, não. Antes de responder a questão, porém, peço que o leitor me acompanhe por algumas considerações.
Como o Lucas menciona eu seu texto, o tópico de arquitetura de software é bastante controverso. De fato, ao longo das quase sete décadas desde que existe algum processo de desenvolvimento, nunca se chegou a um consenso sobre o que esse termo realmente significa. Ano após ano, novos artigos e livros são escritos para explicar o que se entende pela prática e metáforas abundam.
Eu não vou dizer que tenho a palavra final sobre o assunto, é claro. Nos últimos anos, entretanto, eu tenho pensado continuamente sobre o tema, especialmente como uma reflexão sobre o meu trabalho e cheguei a uma conclusão de que minha visão é bastante similar à advogada por Fred Brooks, com algumas pequenas diferenças que refletem minha experiência própria.
Brooks, na palestra que assisti, propôs o seguinte postulado: “Não há tecnologias ingênuas no Ocidente”. O que ele quis dizer com isso é que em qualquer domínio de conhecimento, a faixa de conhecimento e habilidades exigidas é maior do que uma única pessoa pode dominar em um dado projeto.
Ele usou como exemplo o caso de fabricantes de shampoo que usam simulações do fluxo de fluidos viscosos para garantir que as lâminas misturadoras não separem a emulsão de camadas triplas do produto final; adicionalmente, ele também comentou sobre uma fábrica de bolos em que a receita do dia é modificada pela análise química dos ingredientes que chegam a cada dia na planta.
O fato é que esse tipo de especialização de engenharia é uma constante reconhecida mesmo por metodologias ágeis em que a multi-disciplinaridade das equipes é exigida como uma das premissas para o funcionamento do processo.
Por conta disso, Brooks chega à conclusão de que a única maneira de atingir algum nível de consistência e integridade no desenho arquitetural de um sistema é obter uma visão única de como as estruturas devem se comportar no seu nível mais alto: em outras palavras, criar a arquitetura de um sistema.
Em seu livro Computer Architecture: Concepts and Evolution (escrito em parceria com Gerrit A. Blaauw), Brooks define arquitetura de sistemas computacionais da seguinte forma:
The architecture of a computer system we define as the minimal set of properties that determine what programs will run and what results they will produce. The architecture is thus the system’s functional appearance to its immediate user, the conceptual structure and functional behavior as seen by one who programs in machine language.
Eu ressaltei the minimal set of properties porque isso representa uma dos grandes desentendimentos sobre o que arquitetura de software realmente significa e quais são os entregáveis da mesma. Como Brooks e Blaauw apontam, se arquitetura é o conjunto mínimo de propriedades de um sistema, existem outras coisas que, por definição não são arquiteturais e que ainda assim precisam existir para que a implementação suceda.
Nesse sentido, podemos fazer uma distinção bem clara entre a arquitetura e o design de um sistema para entender o desdobramento do projeto de um sistema qualquer. Enquanto a arquitetura existe mais no nível do mapeamento e organização fundamental de um sistema, como entendida através de seus componentes, os relacionamentos entre esses e sua distribuição em domínios de tempo, economia (sim, porque dinheiro também é arquitetura) e escala, o design está mais centrado no domínio de resolução de problemas e planejamento para implementação da solução.
Em outras palavras, a arquitetura é voltada a atingir necessidades de negócio através de blocos maiores de construção do sistema enquanto o design é a disseminação técnica desses objetivos em algoritmos, sub-sistemas e escolhas de implementação.
O que leva à conclusão, por parte de Brooks, e com a qual eu concordo, de que para que se consiga integridade conceitual e estrutural da arquitetura, a figura de um arquiteto-chefe é necessária. Isso é óbvio quando se pensa no negócio como um todo e seus desdobramentos em múltiplas responsabilidades, projetos, sistemas de sistemas e relacionamentos da construção do software em si.
Uma palavra-chave aqui que ajuda esclarecer a distinção aqui é grande porte. Por grande porte, eu quero dizer projetos com um escopo grande ou com grandes características de distribuição. Como Brooks mesmo elabora em seus textos e palestras, se o sistema é pequeno o suficiente, não é necessário que exista uma distinção entre arquitetura, design e implementação. Brooks, na verdade, vai além ao sugerir que o arquiteto e implementador sejam uma única pessoa. Para projetos de porte maior, entretanto, sem uma visão consistente é impossível conseguir a consistência necessária entre as partes.
O arquiteto de sistemas, em outras palavras, é alguém que é capaz de enxergar o projeto com um todo, necessariamente além do escopo de um time qualquer de implementação, mesmo quando o design que esse time está seguindo é auto-contido dentro das premissas daquele time e somente se comunica com externalidades através de protocolos e convenções arquiteturas definidas anteriormente.
Como um exemplo disso, em uma de suas palestras, Brooks menciona uma discussão que ele teve com a pessoal responsável pela arquitetura de sistemas do Global Positioning System (GPS). Esse arquiteto entendia que o sistema como um todo era baseada na interação complexa entre muitos componentes (satélites e outros) e que a moeda corrente entre esses sistema era tempo, dividido em micro-segundos. Ainda mais, o arquiteto via como sua responsabilidade garantir que cada processo conseguisse a fatia necessária de micro-segundos para sua operação–com, como Brooks colocou, bastante micro-segundos sobrando em seus bolsos para resgatar partes do sistema que estivessem em dificuldade.
E isso é o que realmente eu entendo por arquitetura de sistemas. Aos proponentes de arquitetura emergente–tão comum entre praticantes de metodologias ágeis–a implicação é clara: é simplesmente impossível que arquitetura nesse porte, dessa complexidade, venha algum dia a emergir de times separados, trabalhando em componentes próprios, com suas próprias necessidades. Primeiro, por conta da onipresente necessidade de integridade conceitual e, segundo, por conta da degradação de comunicação à medida que o sistema de torna mais complexo e decisões maiores são cristalizada em um conjunto de constraints e especificações–o que Brooks chama de style sheet do projeto.
Volto a Brooks aqui para afirmar o ponto de que um comitê não é um bom lugar para se buscar integridade arquitetural:
Textbook examples of design are almost always “way too simple,” said Brooks. In particular, they ignore the fact that complexity often forces designs to change halfway through, and these changes then involves many other changes. Finally, there is no substitute for “the dreariness of labour and the loneliness of thought”–even though it has been joked that committees are a place where people seek refuge from that.
O arquiteto de sistemas é, em última instância, como Brooks também coloca, um advogado do usuário. Ele advoga pelo usuário em termos funcionais, em termos econômicos, e em termos de escala. Como mostrado na citação acima, o arquiteto de sistemas representa a aparência funcional do sistema para seu usuário imediato, visto pela lente de alguém que programa em linguagem de máquina. E, sim, é um papel técnico.
Para citar Brooks mais uma vez:
Computer architecture, like other architecture, is the art of determining the needs of the user of a structure and then designing to meet those needs as effectively as possible within economic and technological constraints. Architecture must include engineering considerations, so that the design will be economical and feasible; but the emphasis in architecture is on the needs of the user, whereas in engineering the emphasis is on the needs of the fabricator.
Note a diferença em ênfase como colocada por Brooks: arquitetura enfatiza as necessidades do usuário enquanto engenharia enfatiza as necessidades do construtor.
As implicações são bastante óbvias e essencialmente respondem à questão da minha concordância com o que o Lucas disse e com o fato de que eu lidero uma equipe de arquitetura: as necessidades de desenvolvimento são completamente diferentes.
Tirando um exemplo da minha própria experiência, quando eu trabalhava na WebCo, tínhamos apenas dois produtos: Brasigo e BlogBlogs. Por mais complexos que ambos sistemas fossem, suas necessidades arquiteturais eram comparativamente pequenas. Da mesma forma, por mais similares que ambos fossem (aplicações escritas em Rails, virtualizadas, com gargalo em banco de dados, etc), havia poucas conexões arquiteturais para que a figura de um arquiteto-chefe fosse necessária.
E, de fato, pelo tamanho dos projetos, podíamos ter, sem problemas, a figura de um arquiteto em cada time, servindo como líder técnico, ponto focal em discussões entre produtos, alguém como senioridade o suficiente para fazer um papel de mentor para membros mais novos da equipe.
Esse não é o caso em minha posição atual, na Abril Digital. Não só a complexidade dos sistemas é maior, tanto em escala como em distribuição, como a relação entre eles é mais porosa e necessitando de coordenação. Construir um sistema de sistemas constituído de dezenas de sub-sistemas, cada um com suas necessidades, escopo e papel é fundamentalmente diferente de construir um único produto, com limites e condições bem específicos. Não estamos construindo algo do tamanho de um sistema de GPS, claro, mas estamos construindo coisas que possuem necessidades maiores que simplesmente as de um único escopo.
Por conta disso, surge a necessidade de arquitetura como uma colaboração de papéis empregando arquitetos de sistemas e arquitetos de software (chamados de tech leaders internamente) para chegar a um design final coerente.
Isso é ainda mais fundamental em projetos terceirizados que, em um ponto ou outro, precisam se encaixar em nossa infra-estrutura e arquitetura em múltiplos times e instâncias de sistemas. Uma equipe dedicada serve para ajudar nessa coordenação, oferecendo visões do problema. O gap arquitetural é assim resolvido já que existe uma rodovia arquitetural contendo épicos que guiam a quebra de sistemas nas partes necessárias.
Dessa quebra nascem preocupações que podem ser traduzidas no design emergente em cada equipe, contribuindo ao final, para o retorno ao pool arquitetural de conceitos e implementações feitas no ato de descoberta que é o processo de desenvolvimento.
Eu acredito nessa colaboração de papéis como essencial para garantir a agilidade. Citando um dos artigos de Martin Fowler:
This kind of architect must be very aware of what’s going on in the project, looking out for important issues and tackling them before they become a serious problem. When I see an architect like this, the most noticeable part of the work is the intense collaboration. In the morning, the architect programs with a developer, trying to harvest some common locking code. In the afternoon, the architect participates in a requirements session, helping explain to the requirements people the technical consequences of some of their ideas in non-technical terms–such as development costs.
Nesse artigo, Fowler usa uma versão limitada do que Brooks diz para definir um tipo de arquiteto não desejável. E Fowler está correto: usar o argumento de Brooks simplesmente para suportar alguém que simplesmente “toma as decisões mais importantes” não faz sentido.
Isso tudo que foi dito anteriormente não significa, também, que essa arquitetura de sistemas não possa falhar. Ela falha, sim, e algumas vezes catastroficamente. E, na maioria das vezes, a falha pode ser rastreada para decisões que foram tomadas em pontos errados do processo por problemas de comunicação ou de definição de escopo resultado em design inconsistente pelo qual ninguém quer tomar a responsabilidade. A falha, nesse caso, é de todos envolvidos no processo.
Para resumir toda a conversa, considerando que esse texto acabou quase se tornando um ensaio, eu concordo com o Lucas: cada time deve ter o seu arquiteto. Mas acredito também que, para projetos com maior escopo, deve existir um nível mais alto de arquitetura–e por mais alto aqui não quero dizer em termos de uma elite ou de conhecimento mas simplesmente um papel que defina o que é mais alto simplesmente porque tecnicamente, alguém define que esse é o nível mais alto necessário.
Esse arquiteto, dentro do time, é um desenvolvedor sênior capaz de fazer decisões de design em colaboração com seus pares, praticar a mentoria, planejar e executar escolhas de implementação, atuando em conjunto com um time de arquitetos de sistemas que está preocupado com o todo e que não tenta, de forma alguma, forçar decisões de implementação ou design, que busca embasar suas decisões pela velha métrica do running code and rough consensus, que pratica código diariamente pelos meios necessários.
O que significa, essencialmente, que a arquitetura não tem que ser fechada no começo e permanecer imutável depois disso. Ao contrário, precisa evoluir como qualquer outra parte do sistema na percepção do que funciona e do que não funciona. Como Kent Beck diz:
The process of building architecture should have lots of feedback built in and it should be kept simple, because extra elements in the architecture introduce instability and unpredictability. The big difference from current practice is that: “I would stop apologizing for architecting this way,” he says
Espero com esses monte de palavras ter clarificado um pouco a visão do que andei escrevendo aqui nos últimos tempos. Obrigado ao Lucas por fornecer a oportunidade de uma discussão boa como essa–espero que ela continue, por sinal.
Aos leitores que tiveram paciência de chegar até esse ponto, quais são suas visões e comentários sobre o assunto? A caixa de comentários lhes espera impacientemente.
