Em agosto, a Plataforma Tecnologia esteve presente de Norte ao Sul do Brasil. Nada mais, nada menos que 7.000 km foram percorridos, cinco palestras, quatro eventos e menos horas de sono de todo nosso time. Mas….. valeram cada segundo e centavo investidos!

Esse post é um agregado de todas essas palestras com os respectivos slides (os vídeos serão adicionados assim que eles tornarem disponíveis). Então vamos lá!

Oxente Rails – 05 e 06 de Agosto (Natal)

O Oxente Rails foi espetacular! Não há dúvidas de que valeu o esforço que fizemos para levar boa parte do nosso time (Carlos Antônio, Fabio Yamate, Hugo Baraúna, eu (José Valim) e Vinícius Baggio) e em patrocinar o evento. Aproveitamos o espaço para agradecer o pessoal da Tink! por nos convidar para dar duas palestras e pela organização do evento, que foi impecável. Nos vemos novamente no ano que vem!

Bem, a primeira apresentação foi a minha e falei sobre algumas das ferramentas Open Source da Plataforma Tec (Devise, Simple Form e Responders):

Logo em seguida, o Hugo Baraúna falou sobre Project Rescue (um dos nossos serviços) e contou como fazemos para salvar projetos à beira de precipícios. Veja nos slides abaixo.

Além de um excelente evento, a cidade de Natal também reserva diversas surpresas. Um dia após o evento, nós e um pessoal da comunidade Rails fomos visitar as dunas e nos divertimos bastante. Valeu NATAL!

WhyDay – 19 de Agosto (São Paulo)

Após retornarmos de Natal, fui convidado a falar um pouco sobre Open Source e contribuições no Rails em comemoração ao WhyDay. Seguem os slides.

Update (feito no dia 30/ago): a InfoQ publicou o vídeo da apresentação.

A palestra foi bastante descontraída e logo após nós hackeamos um pouco:

Valeu @rafaelrosafu pelo convite!

RS on Rails – 21 de Agosto (Porto Alegre)

Mas enquanto nós nos divertiamos no WhyDay aqui em São Paulo, o Carlos Antônio estava terminando a sua palestra para o RS on Rails. A palestra contemplou diversas novidades do Rails 3 como o Bundler, ARel, ActiveModel, entre outras.

Na foto abaixo, parece que o Carlos é político em campanha eleitoral. Mas na verdade ele só está dizendo que o Router é 100% compatível com Rack. Confira toda apresentação nos slides.

Valeu @felipebcabral pela organização do RS on Rails e pelo convite! Ano que vem queremos mais! =D

The Developers Conference – 21 de Agosto (São Paulo)

Enfim, após poucas horas da apresentação do Carlos Antônio em Porto Alegre, lá estava eu apresentando outra palestra sobre Rails 3 no The Developers Conference. O interessante é que as duas apresentações se complementam. No TDC, falei sobre generators e a API de notificações, enquanto que no RS on Rails o Carlos Antônio falou sobre Unobtrusive Javascript e XSS Protection. Vale a pena conferir as duas apresentações.

Encerrando

Agosto foi um mês bem intenso, repleto de eventos bem organizados e com conteúdo muito interessante. Tanto é verdade que nós não conseguimos participar de todos eventos que gostaríamos. Mas posso dizer que estamos contentes em ver como a comunidade Ruby e Rails está crescendo de forma bastante saudável aqui no Brasil. Parabéns a todos que estavam presentes nestes eventos, como espectadores ou organizadores. Valeu comunidade Rails!

Nos vemos em Outubro no RubyConf! E não esqueçam de conferir outras palestras da Plataforma Tec no Slideshare.

Posted in Português | 1 Comment »

A couple weeks ago we finally released Devise 1.1 which is fully-compatible with Rails 3! Not only that, we’ve been working with Rails 3 since the first betas and several features were added along the way! Let’s take a look at those, some architectural changes and see how Devise 1.1 and Rails 3 will change how you handle authentication.

Pretty URLs with Metal

A common complaint in Devise 1.0 (for Rails 2.3) was, in order to know which message to show to the user when sign in failed, we had to pass a parameter in the URL as in /users/sign_in?unauthenticated=true while one would expect us to simply use flash messages. This happened because the redirection was done not from inside a controller, but a Rack application set up in Warden (a Rack authentication framework Devise relies on) and we could not access flash messages from it.

However, since Rails 3 moved several responsibilities to the Rack layer, including flash messages, we can easily access flash messages from any Rack application, allowing us to remove the parameter from the URL! Even more, Rails 3 provides small, fast, bare bone controllers through ActionController::Metal, which we used in Devise to clean and speed up the code considerably.

Locking goodness

The lockable module in Devise also went through a major overhaul. Previously, it already supported :unlock_strategy as option, allowing you to specify if the user could be automatically unlocked after a time period, through an e-mail token or both. Now, it also supports :none as option, meaning that all unlocking should be done manually.

Even more, there is a new option called :lock_strategy, that allows you to specify whether the lock happens only manually or after an amount of invalid sign in attempts.

HTTP Authentication on by default

In Devise 2.3, you may remember that we had a module called :http_authenticable along with :database_authenticatable and :token_authenticatable. While all three worked great, it was confusing that all HTTP authentication features were built on top of the database authentication and it was not possible to do HTTP authentication using a token unless we created a forth module called :http_token_authenticatable. We quickly noticed this could be improved by providing a better design and better abstract Devise authentication strategies.

And that is what happened in Devise 1.1. Now both database and token authentication work through HTTP with no extra work and the http authenticatable module was deprecated. Besides, if you are creating a new strategy on your own, you get both authentication through parameters (form) and HTTP with no extra work!

Routing customizations

We built Devise to be a full stack solution with customization in mind. In Devise 1.1, the customization abilities from Devise were taken to the next level. Now the devise_for method in routes accepts to extra options: :skip and :controllers. The first one allows you to skip the routes generation for a given controller/module in case you want to define them on your own, while the second allows you to change the router to point to a given controller in your application, like Users::ConfirmationsController instead of Devise’s internal controller.

Talking about Devise’s internal controller, Devise 1.1 namespaced all controllers classes, so now we have Devise::ConfirmationsController instead of ConfirmationsController.

Another limitation removed from Devise in this new version is related to URLs customizations. In prior versions, Devise used the URL to retrieve which scope is being accessed. That said, if you were accessing “/users/sign_in”, Devise had to inspect this URL and find the “/users” bit to specify the current scope is “users”. The same happened to “/admin/sign_in”.

This had a huge impact in URL customization, because if you wanted to have an URL like “/some_prefix/users/sign_in”, you had to tell Devise you were appending a prefix. Things could get even uglier if you wanted to prepend dynamic prefixes like “/:locale”.

In Devise 1.1, we use the new contraints API and Rack capabilities from the new router to specify which scope to use. So, instead of inspecting the URL, Devise retrieves the user from the request’s env hash as request.env["devise.mapping"].

For all the routes generated by devise_for, Devise automatically sets this value in the env hash. However, if you are creating your own routes, you need to set it manually using the constraints API:

constraints lambda { |r| r.env["devise.mapping"] = Devise.mappings[:user] } do
  # Add a custom sign in route for user sign in
  get "/sign_in", :to => "devise/sessions"
end

Of course, since this is rather a common pattern, we encapsulated it in a nice API:

devise_scope :user do
  # Add a custom sign in route for user sign in
  get "/sign_in", :to => "devise/sessions"
end

You can simply give a block to devise_for as well and get the same result:

devise_for :users do
  # Add a custom sign in route for user sign in
  get "/sign_in", :to => "devise/sessions"
end

All the routes specified in the block have higher priority than the ones generated by devise_for.

Awesomeness pack

The last feature we want to discuss is also a routing customization, but we decided to leave it up for last because it shows all the potential coming with Rails 3 and Devise 1.1.

In Devise 1.1, we added the ability to require authentication for a given url in the router, besides the existing before filters in controllers. This allow us to easily require authentication for third party rack application without a need to hack into them. Kisko Labs posted an interesting case where you can use Devise to require authentication to a Resque application in very few lines of code:

authenticate :admin do
  mount Resque::Server.new, :at => "/resque"
end

Devise simply uses the constraints API discussed above, allowing the request to continue only if the user is already authenticated. Otherwise, it redirects the admin to the sign page managed by Devise inside your Rails application. Indeed, when you have Rack, Rails 3 and Devise 1.1 playing along, great things can be accomplished quite easily!

There are several other features, bug fixes and deprecations included in this release, we invite you to check the CHANGELOG and take a look at them!

And we are happy to say this is not all, there is much more to come in Devise 1.2, including OAuth2 support which is already added in the master branch. Enjoy!

Tags: authentication, devise, rails 3
Posted in English | 4 Comments »

Pois é pessoal, estamos há somente dois dias do Oxente Rails 2010 e nós da Plataforma Tecnologia já estamos na expectativa para embarcar para Natal!

@cantoniodasilva, @fabioyamate, @hugobarauna, @josevalim e @vinibaggio já estão com as malas prontas para aproveitar os dois dias de palestras sobre Ruby, Rails, agilidade e empreendorismo. Certamente será uma grande oportunidade para re-encontrarmos todo o pessoal da comunidade Rails e não poderíamos perder essa!

Aliás, gostaria de parabenizar o Paulo Fagiani pela excelente organização do Oxente Rails. Parabéns!

Mas falando em palestras… quero convidá-los a assitir as apresentações do José Valim e do Hugo Baraúna que ocorrerão lá no Oxente Rails. Serão dois assuntos:

DRY – Don’t Repeat Yourself (José Valim)
As nossas ferramentas open source desempenham um papel importante no ganho de produtividade do nosso dia-a-dia. Nesta palestra, José Valim apresentará os nossos principais plugins e como cada um deles se integra ao Rails 3.

Project Rescue – Salvando projetos à beira do precipício (Hugo Baraúna)
Hugo Baraúna contará uma história de horror (real) e explicará como o nosso processo de Project Rescue pode mudar o rumo de um projeto quase perdido para um final feliz.

Pessoal, aproveitem o evento ao máximo e nos procurem para conversar e discutir sobre Ruby, Rails e desenvolvimento de software. Mas não se esqueçam que a praia e água de coco também fazem parte da programação, hein?!

Posted in Português | Comments Off