Tag: desenvolvimento

Rails 2.0… RELEASED! Parte 2

12 de dezembro de 2007 às 23:50 | Carlos Júnior | ,

Continuando a série, vou falar de algumas outras novidades do Ruby on Rails 2.0 (ele não para, ele não para!). Mas de início tenho que falar de algo que acabou passando batido na primeira parte…

root

O Rails padronizou agora aquela rota que você acaba sempre (ou quase) incluindo em seus projetos, que mapeia a raiz do aplicativo (ou o home, index…). A forma padronizada agora é essa:

map.root :controller => "pages" # mapeia a action "index" do controller "pages"

ou

map.root :controller => "pages", :action => "show", :id => 10 # mapeia a action "show" do controller "pages" com o parâmetro id=10

Sessões em Cookies

As sessões no Rails 2.0 ficam agora totalmente em client side, ou seja, em cookies. Isso é bom pois dessa forma fica mais rápido e acabam as manutenções no tmp/sessions. Nas palavras do próprio DHH:

Esta configuração funciona bem se você segue as boas práticas e mantém o uso da sessão ao mínimo, como o caso comum de apenas guardar o user_id e o flash. Se, de qualquer forma, você está planejando guardar “códigos de lançamento nuclear” na sessão, guardar sessões no cookie é um mal negócio. Enquanto eles não podem ser forjados (então is_admin = true está ok), seu conteúdo podem ser vistos. Se isto é um problema para sua aplicação, você sempre pode voltar para o modo tradicional de guardar sessões.

Request Profiler

Chegou a salvação para aquela sua action que, como diria Lucas Petes, “chupa cana, assovia e bate palma”. Aquela action que faz um monte de coisas, e leva um bom tempo para executar… Request Profiler.

Com o Request Profiler você pode executar um profilling em um request. É assim:

$ cat login_session.rb
get_with_redirect '/'
say "GET / => #{path}"
post_with_redirect '/sessions', :username => 'john', :password => 'doe'
say "POST /sessions => #{path}"
$ ./script/performance/request -n 10 login_session.rb

Para quem não sabe, com o profiler você é capaz de saber exatamente qual parte do seu código está levando mais tempo para executar, com isso você pode focar suas atenções de forma a conseguir um melhor desempenho.

Mais performance no ActiveRecord

O pacote ActiveRecord ganhou milhares de fixes e várias melhoras. Uma que eu particularmente adorei é a Cached Query, que reconhece SQLs similares e retorna o resultado cacheado, assim:

>> User.find :all, :conditions => {:name => "a"}
>> User.find :all, :conditions => {:name => "a"}
olha o log!
  User Load (0.335079)   SELECT * FROM `users` WHERE (`users`.`name` = 'a')
  User Load (0.000363)   SELECT * FROM `users` WHERE (`users`.`name` = 'a') # viu o tempo?

Fixtures

Direto ao código…

  # groups.yml
  admins:
    name: admins
 
  # users.yml
  carlos:
    username: shopify
    password: secret
    group: admins # veja isso!!

Reparem 2 coisas: Você não precisa preencher os campos que já são de preenchimento automático (id, updated_at…). Você não precisa ficar guardando o ID que você deu para aquela outra fixture que é relacionada a que você está trabalhando agora, apenas o nome é suficiente.

Desserialização XML

Você já serializava um objeto em XML, agora você pode também fazer o caminho inverso:

>> u = User.new(:name => "Carlos")
=> #<user>
>> b = User.new.from_xml(u.to_xml)
=> #<user>
>> b
=> #<user>
</user></user></user>

Serialização JSON

A serialização em JSON mudou, repare:

Rails 1.2.6

>> User.new.to_json
=> "{attributes: {name: null,  updated_at: null, created_at: null}, new_record: true}"

Rails 2.0.1

>> User.new.to_json
=> "{\"name\": null, \"updated_at\": null, \"created_at\": null}"

No primeiro ele não serializa apenas as propriedades do usuário, mas sim o objeto ActiveRecord::Base, já no rails 2.0 ele passa a serializar exatamente igual a serialização XML, inclusive os parâmetros de :include e etc…

Menos gordura

Todos os acts_as_ALGUMACOISA foram movidos para seus próprios plugins, assim ./script/plugin install acts_as_ALUMACOISA deixa tudo normal. Outra coisa que mudou foi a postura com relação a bases de dados comerciais, todos foram movidos para seus gems. O Rails agora só trata com MySQL, SQLite e PostgreSQL. Para os bancos comerciais, gem install activerecord-BANCO-adapter (Ex.: activerecord-oracle-adapter).

Bom, acho que é só por hoje… aguardem o próximo artigo da série! See yo!

Comentários desativados

Rails 2.0… RELEASED! Parte 1

7 de dezembro de 2007 às 17:59 | Carlos Júnior | ,

update: a versão release é 2.0.1, e não 2.0 apenas.

Ufa! Chegou o dia a hora! Acaba de ser anunciado por DHH o release do Rails 2.0… os desenvolvedores Rails mais antenados (e que não gostam de deprecation warnings) não terão grandes problemas na migração, pois desde o último release da 1.x.x já haviam warnings avisando de todos os métodos que estavam obsoletos.

O Rails 2.0 vem para facilitar ainda mais a vida dos desenvolvedores. Idéias novas e antigas, muito mais leve e limpo (sem gordura). Muito que antes estava no core do Rails agora é apenas um plugin, um dos casos mais clássicos é a substituição do ActionWebService pelo ActiveResource (uma opção por padronizar o uso do REST em detrimento ao SOAP).

Vamos ao que há de novo:

Sexy migrations (ou como queira chamar)

As migrations ficam mais fáceis e ágeis com este novo recurso:
Ao invés de:

t.column :first_name, :string
t.column :last_name, :string

Temos:

t.string :first_name, :last_name

namespaces nas rotas

já pensou?

map.namespace(:admin) do |admin|
  admin.resources :users
end

Este pequeno bloco de código mapeia aquele seu controller Admin::UsersController como um recurso, onde você tem admin_user_url, admin_users_url, …

Convenção em controllers que são recursos REST

Agora da para reaproveitar (sem gambiarra) um controller (resource) em vários contextos. Isso se deve a uma convenção de que todo controller que será um resource agora está no plural. Então…

map.resources :users # /users => UsersController#index
map.resources :groups, :has_many => :users # /groups/1/users => UsersController#index

Multiview

Agora a view é associada ao renderizador e ao formato, ou seja, index.rhtml agora é index.html.erb, onde html é o formato e ERB é o renderizador. index.erb (sem o formato) é que tem a mesma template para todos os formatos. index.atom.builder utiliza o Builder, este formato antes seria index.rxml. Desta forma uma view é mapeada diretamente para o formato requerido no Request.

URLs made easy

Se temos um map.resources :users, então link_to(@user.name, @user), mapeia para a URL direta do @user, ou seja, /user/:id. O mesmo para form_for(@user) e redirect_to(@user), e tudo mais que usa a magnífica construção de URL do rails.

Autenticação HTTP

O novo módulo de autenticação HTTP ajuda bastante em vários aspectos. Tanto para eliminar uma tela de login simples, quanto para autenticação quando se está sendo acessado via API RESTful.

def auth
  authenticate_or_request_with_http_basic do |username, password|
    if user = User.auth(username, password)
      set_current_user(user)
      return true
    else
      return false
    end
  end
end

Mais segurança

Rails 2.0 melhora a segurança tendo habilitado como padrão uma proteção contra ataques XSS e CSRF. Rails 2.0 também adiciona o suporte a HTTP-only cookies (que não podem ser acessados via JavaScript), estes serão usados na proteção citada anteriormente nos browsers que já o suportam.

Exceções

Finalmente! Hehehe, esta é boa. Agora você pode tratar exceções em todo controller (independente da action) e em controllers filhos de forma única.

class ApplicationController < ActionController::Base
  rescue_from ActiveRecord::RecordNotFound, :with => :not_found
 
  def not_found
    render :template => "errors/not_found"
  end
end

Este código renderiza uma template única de “not found” para sempre que tentar procurar um registro que não existe, em todos os controllers filhos de ApplicationController.

AtomFeedHelper

Um helper para o Builder para construção de atom em um jeito mais rubista… Veja se não é fácil…

Em um index.atom.builder

  atom_feed do |feed|
    feed.title("Thinking About Something")
    feed.updated((@posts.first.created_at))
 
    for post in @posts
      feed.entry(post) do |entry|
        entry.title(post.title)
        entry.content(post.body, :type => 'html')
 
        entry.author do |author|
          author.name(post.author_name)
        end
      end
    end
  end

Fonte: weblog.rubyonrails.org

Case – Site da Milk-it

22 de outubro de 2007 às 18:07 | Michel Filipe | , , , , ,

Olá a todos! Tomei a iniciativa de criar uma “coluna” no blog para contar as histórias dos cases da Milk-it. Vou começar a coluna contando a história do nosso próprio site.

Muitos aqui não sabem, mas a Milk-it ficou um ano sem site. Não tínhamos condições de parar algum projeto para nos dedicar somente ao nosso site, e ainda não temos, mas é com isso que entra a parte interessante. Eu, Lucas e Carlos sabíamos que uma empresa de tecnologia sem site é equivalente a um cavaleiro sem cavalo – me perdoe a analogia hehe. Pensando assim, resolvemos aproveitar a semana em que um projeto estava em homologação e decidimos botar a “mão na massa”. Uma semana é muito pouco? Sim, também achamos, mas conseguimos!

1ª Etapa – Elaboração das telas

Esboço das telas do site da Milk-itPor sorte o Lucas havia elaborado uma idéia de layout para o site em suas horas vagas. Isto facilitou muito o nosso trabalho por conta do tempo que tínhamos disponível, porque não precisávamos passar pelo famoso ócio criativo.

Aqui na Milk-it temos um quadro branco que serve para rabiscarmos idéias e tarefas, então fizemos uma reunião para definir os elementos que vão ter nas telas e os fluxos delas. A imagem ao lado mostra o esboço que fizemos – a qualidade da foto está ruim, porque foi tirada de um celular. Se reparar, vai ver que o site segue os fluxos de telas desse esboço apesar das seções não serem as mesmas.

2ª Etapa – Corte do layout e os textos do site

Esboço dos textos do site da Milk-itNesta etapa dividimos o trabalho em duas partes: O Lucas cortou o layout, eu e o Carlos produzimos os textos. A imagem ao lado mostra como era feita (Google Docs) a produção dos textos. O Lucas finalizou rapidamente o corte do layout e começou a ajudar na produção dos textos. Com todo o conteúdo produzido mandamos para a nossa redatora freelancer, que também concluiu o trabalho em poucas horas.

3ª Etapa – Integração do layout com o Rails

Essa parte foi a mais fácil! Só precisou do Lucas trabalhando sob demanda para o Carlos. Em menos de 1 dia de trabalho foi tudo concluído. Claro, como um bom admirador não poderia deixar de dizer que o Rails ajudou demais o nosso trabalho.

Apesar das “mil maravilhas”, eu e o Carlos tivemos uma pequena discussão: “Usar a página de busca do Google ou a API do Yahoo para fazer as buscas no site?”. Eu, focando sempre em simplicidade, queria usar a página de busca do Google e o Carlos a API do Yahoo. O Carlos acabou me convencendo que iria desenvolver rapidamente e iria ficar muito mais bonita. Tenho que tomar cuidado, acho que sou um fanático por simplicidade… Hehehe!

Apesar de existir a 4ª etapa, foi nessa etapa que lançamos o site e concluímos uma semana de trabalho.

4ª Etapa – Correção dos bugs

Para quem já leu o Getting Real (37Signals) e/ou A Catedral e o Bazar (Eric Raymond) sabe que é melhor lançar uma versão Beta e continuar melhorando, do que lançar uma versão Release e deixar parada. Você acaba moldando naturalmente o software para atender aquilo que ele realmente se propõe, sem funcionalidades X,Y,Z que ninguém usa. Corrigimos alguns bugs que aconteciam na renderização de alguns browsers – minha raiva pelo IE só aumenta -, melhoramos algumas páginas e implementamos alguns detalhes no site.

Já estamos com algumas alterações para fazer no site. Estamos planejando para ver se “aquela semana” aparece. E quero deixar claro que o desenvolvimento do site não acabou e que precisamos da ajuda de vocês para deixa-lo da melhor forma possível. Então, para sugestões, bugs e críticas utilize o nosso contato.

Comentários desativados

Da web para o desktop: Mozilla XULRunner e Adobe AIR

22 de outubro de 2007 às 15:22 | Lucas Petes | , , ,

Diversas aplicações têm aparecido para desktop baseadas em tecnologias originalmente desenvolvidas para web. As vantagens?

Multiplataforma: Windows? Linux? Mac? A aplicação será a mesma. Absolutamente a mesma. – a não ser que você não queira isto. Não há a preocupação de desenvolver a interface do seu software em Cocoa, em GTK, Qt ou seja-lá-qual-for-a-biblioteca-de-interface-gráfica.

Recursos: As plataformas trazem consigo recursos e suporte a tecnologias que você levaria anos se fosse implementar sozinho.

Foco: Você se preocupa em trabalhar com o que sabe fazer de melhor. Menos stress, curva de aprendizado razoável, prazos determináveis e dentro da realidade.

Instalação/Desinstalação: Ah, isso os dois também suportam nativamente.

XULRunner

O XUL (pronúncia zúl) é uma linguagem de marcação, semelhante ao DHTML e foi desenvolvido para suportar aplicações do projeto Mozilla. Projetos como o Firefox e o Thunderbird possuem suas interfaces construídas em XUL e outras tecnologias, tais como CSS (apresentação/tema), Javascript (comportamento), DTD (principalmente para a internacionalização) e RDF (descrição do conteúdo).

É relativamente fácil a construção de uma aplicação em XUL para quem está acostumado a codificar HTML. Além disso há uma separação entre a interface e a lógica do software. Uma aplicação cuja interface fosse construída em XUL poderia rodar em Firefox ou qualquer outro navegador baseado no Gecko.

O XULRunner dispensa o browser. Ele é um pacote de execução que permite rodar aplicações XUL+XPCOM standalone. Isto significa que um software que se utiliza desta plataforma pode suportar extensões, temas, plugins, vários protocolos e diversas outras configurações que o Firefox e o Thunderbird suportam.

Exemplos de belos softwares desenvolvidos em XULRunner são o famoso Joost e o emergente Songbird.

Adobe AIR

Batizado inicialmente com o nome de Apollo, o AIR permite portar aplicações Flex, Flash e HTML/JS via engine WebKit (iniciada com o KHTML + modificações da Apple para o Safari + trabalho da comunidade) para o desktop.

O instalador possui 9mb e está disponível no site da Adobe. Uma vez instalado, é capaz de ler os arquivos “.air” das aplicações e instalá-los.

De exemplo, deixo o kuler, o Adobe Media Player e o Ebay Desktop

O ponto mais polêmico no uso do XULRunner ou do AIR é que para cada aplicação é instalada uma nova instância do XULRunner, enquanto que o AIR, é instalado somente uma vez. A principal desvantagem de se ter múltiplas instâncias é o uso de espaço em disco aumentado e a descentralização das atualizações da plataforma. No entanto, você não correria o risco de atualizar o pacote de execução e algumas das suas aplicações instaladas não serem mais compatíveis, o que representaria mais dor de cabeça para o desenvolvedor de cada aplicação.

Comentários desativados

A importância do design

2 de outubro de 2007 às 12:40 | Michel Filipe | , , , , ,

MonitorSei que para muitos vai ser bem estranho escutar de um programador que “design é tão importante no software tanto quanto o código”, mas isso é uma realidade para mim. O que eu digo não é baseado em teorias de livros, mas sim na prática do dia-a-dia e nas reuniões com os clientes. Já tive a oportunidade de ver e até participar de projetos que eram uma verdadeira gambiarra em forma de software, mas que por conta do design o cliente nem se dava conta dos vários bugs que existiam. Posso até estar sendo muito radical em dizer que o fluxo de informações na camada de interface (front-end) é na maioria das vezes mais importante que na camada de modelo e controle, mas é nessa realidade que a Milk-it vive atualmente.

É fácil observar várias empresas/projetos que estão crescendo de forma assustadora e que investem muito em design. Um grande exemplo é a Apple que monta computadores usando hardware normal, mas a forma como os monta os torna muito mais interessantes. O sistema operacional da Apple, Mac OS, se baseia na plataforma Unix (assim como o Linux) e faz uso do Cups e do Samba (e o Linux também), mas porque o Mac OS tem fama de ser mais fácil de operar que o Linux? Por conta do investimento da Apple no desenvolvimento de uma interface para se comunicar com tais softwares. Outro exemplo mais atual é o IBM Lotus Symphony, que é baseado no OpenOffice e está se tornando um sucesso tão rapidamente, entre outros motivos, por dispor de uma interface melhor que a do projeto de origem.

Estou levantando a bandeira do design, mas a minha praia é análise, gerência e programação. Apesar de não saber muita coisa sobre design, eu consegui enxergar o grande valor que um bom projeto de design pode agregar a um software. Não vou virar designer gráfico, de produto ou web, mas vou sempre valorizar e aprender cada vez mais sobre o assunto. Espero que este post possa fazer com que você reflita sobre como o design pode melhorar o seu software, ao invés de se preocupar somente com if, while, each, var, for, i++ ou achar que um software é bonito só porque ele funciona.