Recent Comments

Thanks for this. Just starting a new Rails 3 project and was going to look at Devise (to replace authlogic I've used previously.). So your timing is impecable...

Hm, I heard some guys were very opposed to Devise/Warden. The argument was that authentication should be on the model layer (like the user model), instead of being intercepted at the middleware level.

I'm curious what people think about this and if it might be a valid concern!

@dickstar, are you referring to acl9? I'm not a fan of that solution and prefer something like Declarative Authorization (episode 188) or CanCan (episode 190).

@elad, I only recommend nifty_authentication if you want a very minimal starting point and want to add most of the authentication from scratch without any external dependencies. The other solutions are quite complicated and sometimes writing from scratch is easier if you have very custom needs.

Authlogic is the next step up, where you are writing the controller and views from scratch but the authentication logic is handled for you. This is great if you want to customize that behavior extensively.

Devise is the full stack which means it does most of the work for you. It provides many features such as password resetting which you don't see in the others. If you want a really complete solution and don't need to customize it extensively then this is a good way to go.

Thanks for putting the spotlight on Devise.

I put together a Rails 2.3 example app (with a walk-through tutorial) that shows how to set up Devise with subdomains: http://github.com/fortuity/subdomain-authentication (click above for the link). For anyone who needs a quick start for blog-style subdomains in Rails.

Thanks Ryan, This screencast is very useful as always..

Can you please advise which one to use when:
1. nifty_authentication (yours)
2. Authlogic
3. Devise

I don't mind creating my own logic for Authlogic, you show us how to do that in chapter 160 :), just looking for the best solution out there, what would you use?
many thanks...

That's awesome, exactly what I needed! Thanks Mr. B!

Thank you.
May you introudce the access control plugin?
Because there are so many authentication solutions now. But no easily operated access control to use.
Always need to use keyboard. Is there any good UI for access control without typing?

Pretty nice ... I liked this one

I can't agree with Fabiano that backward compatibility stimulates the production of outdated code; but I must say I'm impressed if he is able to remove those performance-degrading conditional statements from his Rails code.

Already in Rails making good authentication is really easy But I think with Devise plugin. authentication is became more easy..

Thanks for the episode I will need to update some parts of my blog post in (Spanish). http://www.boliviaonrails.com/2010/04/05/como-usar-devise-con-rails-3/

I've used Devise once pre-1.0 and am using it again with the current version. (Currently on a Rails 2.3.5 application) and I must say it is one of my favorite authentication solutions. It's easy to understand and set up, plus it provides most of the common real world solutions out of the box in the form of modules, so *most* of the time you're practically done with the base setup and all you need to do is style the views. Also good to note is that it supports other ORM's as well, not just ActiveRecord, and you can build your own custom modules if needed.

Definitely recommend to try out this authentication solution if you need one!

First of all, thank you for the screen cast.

I tried in my machine and I had to change the user_name for smtp_settings in the initializer to include the domain name, e.g. from "railscasts" to "railscasts@railscasts.com", in order for an e-mail to be sent from my GoogleApp e-mail account.

I don't know if this problem happened to anybody. But I thought I just post the finding here.

Cool episode! This would get me confused for a while :P

About backwards compatibility, I see it as good for 2 things: Stimulation to produce outdated code, and some more IFs in the code, adding up to a slow platform.
I simply trust Rails team, great work guys. And since it is O.S. just add your local path :)

Another great one. Thanks for all you do!

@Luis: yes "rm -r .ext/rdoc" followed by "make install".

@Roel

You didn't include the important line which should be just above where you started cutting. If you saw the same message I had it said it could not find yaml.h, "please install libyaml". So go ahead and install libyaml :-) (and libyaml-devel, if that's a different package)

Does anyone have a solution to the ".ext/rdoc already exists" problem?

When I try to install ruby-head using RVM i get the following error message:

run with --debug for full backtrace
make: *** [rdoc] Error 1
[2010-04-10 14:22:10] make
uh-oh! RDoc had a problem:

Directory .ext/rdoc already exists, but it looks like it
isn't an RDoc directory. Because RDoc doesn't want to risk
destroying any of your existing files, you'll need to
specify a different output directory name (using the
--op <dir> option).

Any idea what can be going wrong? And how do I specify rvm to install without RDOC?

Thanks.

i'm late on this is great episode..

I think this is broken in rails 3. Something to do with how how the new fields are getting linked to with the helper method.

Yes, it's so.

More soon…Please share your own thoughts!

Thanks a lot Ryan for all your hard work! This web site is really inspiring for many people and slowly but surely becomes "Ruby on Rails encyclopedia"!

Could you give a screencast on receiving email using Rails ? or could you point me to a good resource on the web where I could get this information. Thanks.

Great Cast! Thanks :)
I have the same problem @Ronald stated (http://pastie.org/221873).
The simplest workaround I found was config.cache_classes=true.
Is there another way to use Models in development?

I'm loving the Rails 3 with all it's new features, but I'm having problem with the ruby process literally EATING memory. With each request the process grows with perhaps 10 mb. Does anyone know why this is? Working on a Mac and a SQLite DB.

I get this error using rvm:

mark@macpro:~# rvm install ruby-head
Installing Ruby from source to: /Users/mark/.rvm/rubies/ruby-head
Running autoconf
Configuring ruby-head, this may take a while depending on your cpu(s)...
Compiling ruby-head, this may take a while, depending on your cpu(s)...
Installing ruby-head
Installation of ruby-head is complete.
Updating rubygems for /Users/mark/.rvm/gems/ruby-head@global
Updating rubygems for /Users/mark/.rvm/gems/ruby-head
Installing gems for ruby-head.
Installing rdoc
Installing
Error running '/Users/mark/.rvm/rubies/ruby-head/bin/gem install --no-rdoc --no-ri ', please check /Users/mark/.rvm/log/ruby-head/gems.install*.log
Installing rake
Installing
Error running '/Users/mark/.rvm/rubies/ruby-head/bin/gem install --no-rdoc --no-ri ', please check /Users/mark/.rvm/log/ruby-head/gems.install*.log
Installation of gems for ruby-head is complete.

@Adam try putting title in single quotes

:reject_if => lambda { |a| a['title'].blank? }

Thanks Ryan. When this change showed up in Rails master just a little bit before beta 2 I was sort of wondering what the proper form (no pun intended) would be, now, for those of us writing helper methods.

This confirms the direction I was going with my collection_check_boxes FormBuilder mixin, since I'm not outputting any extra content, just yielding a specific object to the block, more like fields_for than form_for.

Great video (as they all are).

I ended up using ultraviolet since I love the textmate themes anyway (I'm actually a Emacs+Mac guy myself). My blog isn't moved over from Wordpress to my own custom software yet, but once it is it's going to use ultraviolet.

Just so others know, Heroku has the required libraries for Ultraviolet already installed which make using it a snap :)

http://mxkelsin.heroku.com/2010/04/01/installing-ultraviolet-on-my-mac/

Well, I don't know where you find the time to get to grips with all the new functionality that's going on and I really ought to say thank you as your Railscasts have saved my bacon many times.

I am a little dissapointed and rather pleased at the same time with this new form functionality.

I've been looking forward to Rails introducing form inheritance and I had an incling that Rails 3 mught just be the time this ws done but alas it seems to be not the case. I believe this is a major oversight in Rails particularly when everything else is an object. The pleasing thing is to see the view helpers becoming more friendly and intuitive to use but they are still not a substitute for form inheritance.

Thankyou for your massive contributions to the Rails community

James

Kevin--

It took me a little bit to wrap my mind around the changes in Ben Alman's JavaScript, but in the end it turns out to be similar in length and complexity.

Here's a clean interpretation of the pagination.js using jQuery-BBQ: http://gist.github.com/358429

how do you set the id of linked pages loaded in by jqtouch via ajax? for each transition, jqtouch loads in the page successively as:

<div class="current slide in " id="page-3">
<div class="current slide in " id="page-8">
<div class="current slide in " id="page-13">

thanks,
mark

The URL Utils example described in the screencast seems so much simpler than attempting to implement similar features using the jQuery BBQ and jQuery urlInternal plugins - am I missing something or has this project taken a step backwards?

What happened to #capture helper method ? What is the difference of it and new #with_output_buffer ?

So as of Rails 3.beta2 most of this code fails out. Since Javascript has gone the unobtrusive route, the HTML included in the link is gone. Has anyone found a solution to this? I'm just starting to fool around with it.

a railscast about authentication in rails 3 would be really nice.

Despite my vow of silence, I just want to reply to a couple of (good) points.

@Ashley I agree that full backward compatibility may be inappropriate for a major release, but I should have thought that such a major element of MVC should at least have an easy migration path, or a long-lasting "compatibility mode". It seems to me that either would be relatively easy; and ideally, should be integrated into the official Rails releases, rather than waiting/hoping for one (or more) individuals in the community to chuck in such tools or plugins.
I also take your point on the ability to stick with 2.x, but I don't really believe that fixes and minor releases are going to be abundant in the coming years.
I also get your comment that this "product" is driven by developers who want to move quickly (of whom I am an avid member); but development is - like it or not - but a minor part of the lifecycle, and we must always have an eye to the legacy we are leaving.

Drupal does no gurantee backward compatibility. If you want to lead by innovating, sometimes you have to sacrifice legacy. We always do that.

I think it is a positive step by Rails community to carry a vision to have backward compatibility where possible only if it does not slow down innovation.

@Steve D: Why is full backwards compatibility important in a major release? Rails 2.x isn't going anywhere, it's feature packed, and if necessary will receive security updates for the foreseeable future — Rails 3 won't make 2.x any less awesome! I can see many production Rails 2.x apps never needing to be upgraded.

What makes Rails great is it *isn't* an enterprise framework, it's driven on innovation by developers who like to move fast. Let's not bog that down with specs and red tape.

@Andy: you can easily do this with haml.

="string" == <%= "string" %>
-"string" == <& "string" %>

This cast came just in time. I was getting duplicate output due to yields that I had in the helpers. The cast pointed me in the right direction and was able to solve the problem quickly. Thanks.

This fundamental change in the handling of ERB makes for better streamlined helper code. It's a good design improvement. Although it potentially breaks legacy code, it's well worth it.

@anon Yes I understand the constraints; but the drivers of Rails 3 have put an extraordinary amount of effort into the new framework. I'm just a bit disappointed, that having created a game-changing technology, they have not put (in my opinion) enough thought into the time and resources their "adherents" have expended in developing businesses/sites which follow their lead.

To an old man, this seems IBM/Microsoft ish rather than community-sensitive progress.

I shall now be silent, as I'm sure I'm offending the majority.

@Steve Yes, that would be ideal. Unfortunately, the Rails team and open source does not have the funding of MS or Sun/Oracle. While I agree the Rails team should make each version backwards compatible, I think framework innovation would be slowed. Rails 3 is a major version so expect it to have breaking changes.

Further to my comments, as someone who has seen (and worked in) the dramatic expansion of IT from the 70s (IBM), through the 80s and 90s (Microsoft), and the 21st century (Microsoft/Apple/Open Source), I am concerned that new releases of established frameworks/products will require upgrading in a way which requires expensive in-house/consultany effort which would not be otherwise necessary.

Cannot some bright chap in the Rails community (I'm too thick) produce a plugin which emulates backward compatibility in this area; or at least a migration tool which identifies and converts heretic syntax to its new spiritual home?

@Ryan, I think that this is a "big" update - unless I have been putting too much of my effort into views.

It is a fact that every developer has had to understand the difference between Ruby code which returned content, and Ruby code which affected the logical flow of content within the view.

This change seems to alter the syntax for the sake of some new paradigm, whilst still retaining the anomaly of the "cache" facility.

I cannot see why the backward compatibility cannot be guaranteed for the foreseeable future.

As to your point about other scenarios, I can't think of any, but unless you're using extensive JQuery (or javascript), I believe that views are a fundamental resource of any Rails application.

I shall still watch your impeccable Railscasts despite my pique on this issue with Rails 3!

@Andy, great question. I don't use HAML regularly so I haven't researched it yet. I'm guessing the HAML library will need to be updated to handle this as well.

@Slobodan, Thanks for pointing this out. I hope beta3 will soon be released with these version fixes.

@Steve, what specifically do you not like about this update?

Regarding backward compatibility. Leaving out the equal sign still works in Rails 3 but it is deprecated. So if you are building an engine that has views which need to be compatible with both Rails 2 and Rails 3 then it's best to not use the equal sign for now.

I'm not certain in what other scenarios you'll need backwards compatibility.

PS: I notice you didn't talk about backwards compatibility.

This change would be ridiculous - is it an April Fool thing? What about legacy code?

I've always followed your brilliant exemplars of the practical effects of release changes, but this time I find it hard to believe it; I will go and check on the release notes - which I've never felt necessary to do before.