Autor: Carlos Júnior

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.

2 Comentários »
Compartilhe

Novo no Rails Edge: Suporte simples a “Conditional-Get” (ETags)

14 de agosto de 2008 às 02:24 | Carlos Júnior | ,

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!

1 Comentário »
Compartilhe

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!

Comente! »
Compartilhe

Processamento de imagens com Qt – Parte II

26 de maio de 2008 às 02:49 | Carlos Júnior | , ,

Bom, apenas para deixar vocês a par do que foi feito após aquele post. Continuei meu belo trabalho e hoje resolvi colocá-lo no Github[1], quem sabe ele não cresce e mais pessoas adicionam novos recursos para ajudar outras a entrar na área de Processamento de Imagens Digitais (PID)?

Quando comecei a fazer o trabalho eu tinha muita informação sobre processamento de imagens, mas pouca coisa em C++ (na verdade a linguagem fui eu quem escolhi, causei minha própria coceira). O pouco que encontrei nesta linguagem não era lá realmente funcional (apenas classes isoladas e etc.).

Quem quiser adicionar filtros, mesmo que simples (média, mediana, etc), é só fazer o fork e me comunicar sobre as mudanças ou então gerar um patch e me enviar.

O que realmente está precisando ser feito:

  • Fazer o espectro de Fourier funcionar direito (a transformada está correta, a inversa ídem);
  • Temporada de caça aos memory leaks! Achei vários e já tratei de corrigir, porém após alguns filtros ele consome muita memória e precisamos fechar e abrir novamente se quisermos nossos recursos de volta.
  • Adicionar recursos para trabalhar com imagens coloridas (como o trabalho era para trabalhar com imagens em escala de cinza, apenas isso foi feito) – quando a imagem é colorida, nós a convertemos para escala de cinza;

Abraços!

[1] http://github.com/xjunior/blind-chameleon/tree

Comente! »
Compartilhe

Histórico da linha de comando

21 de abril de 2008 às 15:27 | Carlos Júnior | ,

Seguindo o post do Luke Franci:

$ history 1000 | awk '{a[$2]++}END{for(i in a){print a[i] " " i}}' | sort -rn | head
110 vi
65 rake
43 gcc
40 ls
40 cd
24 rm
24 ./mc
18 thin
18 svn
15 su

Faça o teste e poste nos comentários ou em seu blog!

5 Comentários »
Compartilhe
« Posts mais antigos