Sign in through GitHub

Please read for an updated status on RailsCasts:

Learn more or hide this

Javi's Profile

GitHub User: javierv

Comments by Javi

Avatar

This is great! Does anyone know about similar gems for Open Document?

Avatar

Hi, Ryan. Just an observation.

At 5:45 you say something about not letting bad guys know if an email is already registered.

I've heard many people arguing that and many sites implementing it. My experience so far:

  • It confuses legitimate users who mistype their email addresses.
  • It's useless against bad guys.

Why is it useless? Because on every site I've tried, you can just try to register with a given email address and it gives an error saying "email already registered" if it is.

Avatar

The design looks better, and playing the video from the browser is nice.

Just a criticism: I don't like the tabs for comments and show notes.

Sometimes I'd like to see the show notes while I'm writing a comment (maybe I'm commenting something about them). Now, I lose the contents of my comment if I click the "show notes" tab.

Another thing I use a lot is using the browser-search to look for a word in both the comments and the show notes. Now it doesn't work.

Looking forward for more Rails 3.1 episodes. Thanks!

Avatar

Very interesting subject! Websockets are definitely in my TODO list.

Ryan, could you please add the link to async_sinatra & others to the show notes?

Thanks!

Avatar

I've tried a similar thing (without decent_exposure) and I find it a bit confusing sometimes. For example, when you have an edit action where you can edit any article, and a show action where only certain articles can be accessed.

Then you end up calling things like "public_article" in the view (similar to Ryan's example in the cast). That means there's some coupling between the view and the responsibility to decide whether an article can be accessed in a certain action or not.

So far I'm not used to it and prefer the approach where the view receives an article and doesn't care about where it came from, but I'll give it another try sometime.

Avatar

@1239: Check out episode 167 for an example of doing something similar. Maybe you could combine all these ideas to get what you want.

Avatar

Really nice interface.

I've also used a couple more jQuery solutions for multiple selection:

* Bsmselect: https://github.com/vicb/bsmSelect
* Multi select: https://github.com/michael/multiselect/

These two solutions have advantages over tokeninput:

* No need to change server code, nor to implement any search actions.
* They work without javascript as well, just as a normal multiple select.

On the other hand, it looks to me tokeninput is very user friendly. That gives me an idea to combine the advantages of both worlds...

Thanks!

Avatar

You might want to still use transactions for any other tests (that way they're faster).

Something like this would work:

  config.use_transactional_fixtures = false

  config.before(:suite) do
    DatabaseCleaner.strategy = :transaction
    DatabaseCleaner.clean_with(:truncation)
  end

  config.before(:each) do
    if example.metadata[:js]
      DatabaseCleaner.strategy = :truncation
    else
      DatabaseCleaner.start
    end
  end

  config.after(:each) do
    DatabaseCleaner.clean
    if example.metadata[:js]
      DatabaseCleaner.strategy = :transaction
    end
  end

Avatar

I've been using both Paper Trail and Vestal Versions for this kind of things.

I've found Paper Trail to be more complete, and with many convenient methods such as "next", as you show. Another point is that it seems to be more actively mantained.

But I prefer Vestal Versions philosophy of storing the current version when you update a record (Paper Trail stores the previous one on an update). That way the current version can easily be managed with all the rest in features such as wiki-like history and comparison.

And you actually can delete old versions with Vestal Versions. Vestal Versions recovers previous versions based on differences with the current one, so deleting old ones doesn't hurt a bit either.