Antes que mandem um tijolo em mim, deixo claro que a intenção deste post é apenas de fazer uma brincadeira com as projeções de futuro que foram feitas pelos dois diretores.

Spielberg de fato constrói uma ficção científica mais popular, com mais ação e aventura, mas nem por isso menos embasada ou mal amarrada — De Volta para o Futuro é uma das provas. Stanley Kubrick veio primeiro. Quebrou tabus em “Lolita”, fez mágica em “2001″, brincou com fogo sem se queimar em “Dr. Fantástico” (Dr. Strangelove).

De volta para o Futuro II (1989), Casa dos McFly, 2015

Quais destas coisas já são tecnologicamente possíveis em 2010? Exceto o hidratador de comida e o flutuador de gente, todas. É obvio que não foi esta a intenção do filme, mas quais são economicamente viáveis? Identificação biométrica, TV enorme de tela plana, projeção na parede, aparelhos de fax (!) de tamanho reduzido, videoconferência na tv, óculos-telefone, etc. Não temos tudo isso em nossas casas porque ainda é caro, porque já surgiram soluções melhores ou simplesmente porque não são coisas tão úteis assim. O mais importante: não há internet nessa projeção. A Web ainda estava para ser inventada em 89.

2001: Uma Odisséia no Espaço (1968), Missão a Júpiter

Hmmm, eles tem tablets/TVs como as que começam a surgir no mercado. Mas… e quanto ao reconhecimento perfeito de voz, inteligência artificial aprimoradíssima, telas com widgets de monitoramento e uma missão tripulada a Júpiter? Arthur C. Clarke e Stanley Kubrick nos superestimaram. Muito pouco do que é mostrado no filme é possível de ser feito hoje — muito menos em 2001. Quantos anos ainda levaremos? E se conseguirmos, o que será viável e o que será engolido por outras tecnologias melhores?

No próximo post vou resgatar alguns vídeos de empresas sobre o futuro que foram apresentados no ano passado. Até que ponto as previsões são afetadas pelas últimas tecnologias emergentes? Algumas já nascem mortas e fora do mercado?

A explosão das formas de interação

17 de janeiro de 2010 às 22:17 | Lucas Petes
Já sonhei muito com um desse

Já sonhei muito com um desse

Vimos ao longo dos anos 90 (anos 80 nos países desenvolvidos) o grande salto da informática na vida das pessoas. Empresas passaram pelo processo mágico da “informatização”, cursos surgiram em todas as esquinas, grandes varejistas passaram a exibir as máquinas em suas prateleiras em meio aos videocassetes e televisores. O sucesso comercial da Web serviu para inclinar ainda mais essa curva. Por uma questão de evolução, softwares mais completos, amadurecimento da tecnologia e obsolescência programada havia a concorrência por computadores cada vez mais potentes e equipados – kit multimídia, placa 3D e Pentium MMX são termos que já devem ter feito parte da sua vida.

Os anos 2000 trouxeram a popularização do celular e quase tudo girava em torno da palavra convergência. Serviços aglutinados em “combos”, aparelhos de MP3, MP4, MP15MP40, celulares canivetes-suíços-pós-modernos.

No final da década, lançamentos importantes e a apresentação de tecnologias revolucionárias – ou a combinação perfeita de algumas já disponíveis – prometem para os próximos anos uma explosão das formas com que o homem poderá interagir com a máquina e com os seus semelhantes.

Muitas vezes a indústria é ansiosa e fica na expectativa de pegar o bonde andando e conseguir faturar algum dinheiro às custas do hype. Não falo só da indústria de bens de consumo duráveis, mas me refiro a qualquer coisa que gere algum barulho e consiga a atenção das pessoas. Afinal de contas, é isso o que importa. Houve um tempo em que todo cliente pedia um efeito morph na sua nova campanha de TV. Qual era o motivo?. Quantos aparelhos de celular com o form factor “flip” existiam antes do StarTAC? Quantos aparelhos de celular com o form factor… erhh… iPhone existiam antes do dito cujo? Quantos funcionam direito? Quantos são os genéricos?

Segundo a Apple, houve uns quatro anos de pesquisa antes da apresentação do iPhone, em janeiro de 2007. Muito mais impressionante na época do que hoje talvez possa parecer, o aparelho oferece uma integração de altíssimo nível entre software e hardware: é impensável um sem o outro. Mais do que um aparelho legal e uma mina de dinheiro, o iPhone trazia consigo uma nova forma de interação: o multi-toque, aplicado de maneira simples, madura e intuitiva.

LG Prada 2

LG Prada

Dos aparelhos que vieram depois – LG Prada, HTCs diversos, Palm Pré – quantos efetivamente conseguiram fazer um bom uso da tecnologia de [multi]toque? Quantos a usaram apenas por conta do hype, como uma perfumaria cara e dispensável?

Pensando em Web, aposto uma licença do Ubuntu como você não consegue reunir 5 exemplos realmente bons do uso de Realidade Aumentada em Flash, mesmo se for profissional da área. Conseguiu? E 10 exemplos? Conseguiram de fato promover uma interação rica e sem desconfortos para o usuário? Confesso que conheço bem poucos, e os melhores nem são em Flash.

Microsoft Surface, Reactable, DS, Wii, Project Natal, IdeaPad U1 e Kindle. Invenções, inovações, melhores implementações de tecnologias já existentes, respostas aos concorrentes, frankensteins ou apenas testes de buzz?

Inovar sempre foi a melhor forma de estar na frente, mas encher os olhos com uma nova forma de interação não quer dizer muita coisa se não for bem empregada. Vamos combinar que não é lá muito legal ficar com o braço estendido pra frente. Pegar o bonde do hype andando e não entender por que ele anda é ainda mais imperdoável.

É bem provável que a próxima década seja marcada pela multiplicação das formas de interação: desenvolvidas por muitos, bem aplicadas por poucos e competentes vencedores. Atrás destes, o caos dos concorrentes. A ficha demora a cair. A incredulidade também faz parte. Quantos anos foram necessários para a indústria entender e aprender a lidar com o mouse?(1) Até a consolidação, muita água ainda precisa passar por debaixo da ponte.

Falando nisso, o tablet da Apple vem aí. Entre os diferenciais prometidos, está uma nova forma de interação. Mais uma virada de mercado? Os outros players do mercado vão ficar mais uma vez com o sorvete na testa?

(1) Há registros de um “mouse” militar de 1952. Aquele outro de madeira, mais conhecido, data de 1964. Apesar das boas intenções da Xerox em 81, uma implementação mais madura (e mais vendida) foi a do Macintosh, em 1984. (via Wikipedia)

Rails =~ /Merb/

23 de dezembro de 2008 às 23:29 | Carlos Júnior

“Anh?” É, eu também fiz essa cara que você está fazendo quando li o artigo do blog oficial do rails. Mas é isso mesmo:

Rails 3.0 é a próxima major version, e englobará nada menos que o (seu antes arqui-rival) Merb. Não só isso, Merb+Rails serão juntos o Rails 3.0. E os preparativos já começaram! wycats já é parte do Rails Core Team, o plano de ação já foi feito e o Merb já até tem uma página especial no site oficial do rails.

Para quem não conhece (Sério? Você precisa atualizar seus feeds…), Merb é um outro grande framework Ruby, que tem como princípios desde o seu nascimento ser rápido, 100% modularizado e Thread-safe. A forma de se desenvolver no Merb é bastante parecida com Rails (como era de se imaginar), porém com algumas particularidades. Leia mais no site oficial do Merb.

O que isso trará de bom para o Rails

Em primeiro lugar a fusão trará para o Rails a política de liberdade do Merb. No Merb, você não é obrigado a usar DataMapper (o ORM padrão), ou obrigado a usar ERb (para renderizar a view) e etc, eles são apenas padrões sugeridos, o que não acontece no Rails, onde você precisa fazer uma forcinha para mudar estes padrões. No Rails 3.0 esta abordagem de liberdade também fará parte de nossas vidas, sendo simplificado o uso de DataMapper e Sequel.

Desta forma, teremos um “rails-core”, assim como o merb-core, que será o rails sem nenhum módulo. De qualquer forma, ainda haverá um pacote “rails” que nos trará toda a pilha de módulos do rails.

Otimizações na performance do Rails será um outro benefício que este merge nos trará. O Merb tem muitas partes do Rails reescritas com melhorias de performance que também serão parte do Rails 3.0.

No Merb, os plugins tem uma API fixa, o que significa que os plugins escritos não quebram a cada nova versão do framework. Esta linha de pensamento será trazida para o Rails 3, aumentando ainda mais nossa gama de plugins e  a facilidade de manter o desenvolvimento de um.

A base de usuários… ahh, a base de usuários… :D O Rails contará agora com praticamente todos os desenvolvedores Ruby disponíveis como sua base até por que, coincidência ou não, desde o dia 17/12/08 já poderemos usar o Sinatra de forma fácil dentro de uma aplicação Rails (ainda edge, futura 2.3).

Nas palavras do próprio Yehuda Katz, de forma geral, olharão para o Merb e trarão para o Rails o que ele tiver de melhor e ainda faltar ao Rails.

A migração

A migração promete não ser penosa. Segundo o post de anúncio do merge, migrar um aplicativo Rails 2 para Rails 3 será relativamente ‘tranquilo’, assim como migrar aplicações Merb para Rails 3.

Quem mantém aplicações Merb não precisa se preocupar, já a versão atual do Merb continuará sendo mantida com bugfixes e pequenas alterações já previstas. Daí pra frente, tudo será Rails 3.0.

O Carlos Brando vem fazendo um excelente trabalho em trazer para nós as novidades do Rails Edge (no caso, o 2.2). Mas ao me deparar com esta atualização não pude me conter em blogar sobre. Na verdade, apenas traduzir o artigo do Ryan.

———–

Conditional-gets são uma facilidade da especificação do HTTP que fornece um método de os servidores we comunicarem aos brosers que a resposta para a requisição GET não mudou desde a última requisição e que o cache do browser pode ser usado com segurança.

Eles funcionam usando os cabeçalhos HTTP_IF_NONE_MATCH e HTTP_IF_MODIFIED_SINCE para passar para frente e para trás um identificador único do conteúdo e o timestamp de quando o conteúdo foi modificado pela última vez. Se o browser fizer a requisição onde o identificador do conteúdo (etag) ou a data da última modificação bater com a versão do servidor então o servidor precisa apenas enviar de volta uma resposta vazia com um status de “não modificado” (304).

É do servidor (nós) a responsabilidade de olhar a data da última modificação e o cabeçalho if-none-match e determinar quando ou não enviar a resposta completa (com a renderização da página, por exemplo). Com este novo suporte a conditional-get no rails, isto se torna uma tarefa muito fácil:

class ArticlesController < ApplicationController
    def show
        @article = Article.find(params[:id])
 
        # Define o cabeçalho da resposta para refletir exatamente
        # o estado do objeto requisitado
        response.last_modified = @article.published_at.utc
        response.etag = @article
 
        # Se o estado da requisição é o mesmo do estado no servidor
        # então sabemos que não precisamos enviar todo o resultado
        if request.fresh?(response)
          head :not_modified
        else
          respond_to do |wants|
            # normal response processing
          end
        end
    end
end

O valor do etag é calculado para você com o metodo setter etag=. Tudo que você tem que fazer é prover um único objeto ou array de objetos que definem de forma única a identificação desta requisição. Neste exemplo o artigo por si mesmo contém toda a informação que identifica o estado desta requisição. De qualquer forma, você pode precisar de usar mais de uma chave em seu aplicativo. Como para uma requisição específica para cada usuário:

response.etag = [@article, current_user]

O método request.fresh?(response) é quem dirá a você se a requisição casa com o valor de last-modified-since ou if-none-match da resposta que está sendo enviada. Se sim, você pode evitar de responder todo o conteúdo e economizar alguma (ou muita!) banda.

Também é possível você evitar de acessar o banco de dados se seu aplicativo trata com páginas completamente estáticas armazenadas no banco de dados (isso é raro):

class ArticlesController < ApplicationController
    def show
        # Se o artigo não muda, o etag pode se basear apenas em
        # ítems que temos na requisição
        response.etag = [:article, params[:id]]
 
        # Se o estado da requisição é o mesmo do servidor
        # podemos evitar também de acessar o banco de dados
        if request.fresh?(response)
          head :not_modified
        else
          @article = Article.find(params[:id])
          respond_to do |wants|
            ...
          end
        end
    end
end

Então, seja um bom cidadão e faça suas requisições compatíveis com conditional-get. Isto é a coisa certa a ser feita – e melhoram também a performance de seus programas.

—-

Vale notar, que você pode também usar estes cabeçalhos para acessar webservices (principalmente os feitos em Rails agora :D ) fazendo requisição de XML, se você, por exemplo, estiver guardando os dados que você acessou e guardar a data em que isto foi feito, assim você economisa ainda mais banda!

Rails DataBrowser no rubyforge!

7 de junho de 2008 às 17:39 | Carlos Júnior

Agora você também pode instalar o Rails DataBrowser via RubyGems!

update 25/06/08: o site do Rails DataBrowser mudou! Abandonamos o uso do Trac, e agora estamos com o Redmine. Então acesse redmine.milk-it.net/projects

Acabei de publicar a gem no RubyForge, e esta será atualizada constantemente assim como o plugin!

Bom, para installar:

gem install databrowser

Para usar:

require 'data_browser'
ActionController::Routing::Routes.draw do |map|
  # your routes
  map.databrowser
end

Ou, se você está usando Rails >= 2.1, ao invés de fazer o require no routes.rb, adicione esta linha em seu environment.rb

  config.gem "databrowser", :lib => "data_browser"

Espero que gostem!