Re: [Rails-core] Re: Feature feedback before working and pull request please..

[Richard Schneeman]

The OP was asking for feedback, I believe they've gotten it. If they want to 
discuss it further they can make a PR, and the discussion can be moved there. 
Thanks to all who participated, as a reminder there are 478 open issues and 172 
active and open pull requests that could use similar attention: 
https://github.com/rails/rails/issues?state=open. 

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)







-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] [Proposal] Team issuebusters

[Richard Schneeman]

Thanks Rafael, Prem, Ryan, Steve, Carlos and everyone else for all your hard 
work. Issues are much better than they were!

To everyone else...I just started taking a serious look at issues a few months 
ago and since then i've learned quite a bit about rails internals, an in-depth 
look into the pull request system. It's been incredibly rewarding and it will 
even help you find easy commits like this simple docs update: 
https://github.com/rails/rails/issues/3729. Even if you only look at one issue 
a day it can still be helpful to Rails and helpful to you. If you're interested 
in being a guniea-pig for a beta project, I've written a script that can email 
you an open issue from Rails once a day. If you would like more information 
message me directly richard[at]heroku.com, once I get some polish on the 
project I'll mail it out to the rest of the list.  

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)








On Tuesday, September 11, 2012 at 2:19 PM, Steve Klabnik wrote:

> I literally have read every open Rails issue and comment, and check twice a 
> day at least.
> 
> As many as you think are open now, you should see the number I close within a 
> few minutes of opening. ;)
> 
> I think there still could be a few more people with commit privileges, as 
> there are a ton of PRs open, an ultimately, fixing issues requires getting 
> code written and reviewed. It's certainly not too bad at the moment. It has 
> been much worse multiple times in the past. 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] [Proposal] Team issuebusters

[Richard Schneeman]

Even taking one new issue a day, you're guaranteed to find something to work on 
:)  

--  
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Tuesday, September 11, 2012 at 2:49 PM, Prem Sichanugrist wrote:

> Haha, maybe Andres, Maybe. Trust me, there was one time that I spend a whole 
> day trying to fix an issue, and still couldn't figure it out what's wrong 
> with it … I then had to drop it. (I'm not proficient on working with Active 
> Record stuff, tbh.)
>  
> But, I mean, if that easy tag really going to encourage new people to come 
> in, I don't mind doing it. However, I feel like if the issue is easy to fix 
> enough, people will tends to just send in a pull request with their fix 
> instead of just reporting a bug, since it's so easy nowadays with GitHub and 
> all the tools we have.
>  
> Oh boy, I don't want to take this one off topic, so I'll stop here for now. 
> Happy contributing people! :)
>  
> - Prem  
>  
> On Tuesday, September 11, 2012 at 2:42 PM, Andreas Arnold wrote:
>  
> > Maybe I just chose the wrong issues then... :)
> >  
> > I'm just mentioning it since, for example, Poltergeist marked a few issues 
> > as "easy" and has managed to get a few new people to contribute to it.
> >  
> > On Tue, Sep 11, 2012 at 8:38 PM, Prem Sichanugrist  > (mailto:sikand...@gmail.com)> wrote:
> > > … right, if you look hard enough, you'll find one that it's simple. :P
> > >  
> > > BTW, while I like the idea here, I don't think we really need a easy bake 
> > > oven for our issues. I remembered myself wanting to write a patch to 
> > > Rails, so I dove down Active Record source code, head first, trying to 
> > > fix something, and boy that was really fun. If they take issue as a 
> > > challenge, regardless if the issue is hard or easy, it's still fun. :)  
> > >  
> > > - Prem
> > >  
> > > On Tuesday, September 11, 2012 at 2:34 PM, Steve Klabnik wrote:
> > >  
> > > > At this point, it seems to me that there isn't a whole lot of 'simple'
> > > > bits to be fixed; most issues in a massive, years-old codebase are not
> > > > trivial.
> > > >  
> > > > That doesn't mean they don't exist...
> > > >  
> > > > --  
> > > > You received this message because you are subscribed to the Google 
> > > > Groups "Ruby on Rails: Core" group.
> > > > To post to this group, send email to rubyonrails-core@googlegroups.com 
> > > > (mailto:rubyonrails-core@googlegroups.com).
> > > > To unsubscribe from this group, send email to 
> > > > rubyonrails-core+unsubscr...@googlegroups.com 
> > > > (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> > > > For more options, visit this group at 
> > > > http://groups.google.com/group/rubyonrails-core?hl=en.
> > > >  
> > > >  
> > > >  
> > >  
> > >  
> > > --  
> > > You received this message because you are subscribed to the Google Groups 
> > > "Ruby on Rails: Core" group.
> > > To post to this group, send email to rubyonrails-core@googlegroups.com 
> > > (mailto:rubyonrails-core@googlegroups.com).
> > > To unsubscribe from this group, send email to 
> > > rubyonrails-core+unsubscr...@googlegroups.com 
> > > (mailto:rubyonrails-core%2bunsubscr...@googlegroups.com).
> > > For more options, visit this group at 
> > > http://groups.google.com/group/rubyonrails-core?hl=en.
> >  
> > --  
> > You received this message because you are subscribed to the Google Groups 
> > "Ruby on Rails: Core" group.
> > To post to this group, send email to rubyonrails-core@googlegroups.com 
> > (mailto:rubyonrails-core@googlegroups.com).
> > To unsubscribe from this group, send email to 
> > rubyonrails-core+unsubscr...@googlegroups.com 
> > (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> > For more options, visit this group at 
> > http://groups.google.com/group/rubyonrails-core?hl=en.
>  
> --  
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Re: Excessive redundant object allocation in AR

[Richard Schneeman]

Symbols are never garbage collected in Ruby. 

http://stackoverflow.com/questions/659755/ruby-symbols-are-not-garbage-collected-then-isnt-it-better-to-use-a-string
 

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Wednesday, September 12, 2012 at 11:00 AM, Gary Weaver wrote:

> Something that would work instead of a StringPool that is Ruby-ish is use of 
> symbols. Symbols are Ruby's answer to the StringPool. If things are stored as 
> symbols, you can work with them similarly as to what you would expect and 
> reduce # objects, e.g.
> 
> jruby-1.7.0.preview2 :008 > :error.object_id
>  => 2050 
> jruby-1.7.0.preview2 :009 > :error.object_id
>  => 2050 
> jruby-1.7.0.preview2 :010 > :error.to_s.chomp!('or').to_sym
>  => :err 
> jruby-1.7.0.preview2 :011 > :error.to_s.chomp!('or').to_sym.object_id
>  => 2052 
> jruby-1.7.0.preview2 :012 > :error.to_s.chomp!('or').to_sym.object_id
>  => 2052
> 
> So basically if everywhere in Rails documentation that referred to strings 
> instead specified constants, and if the method didn't support constants that 
> would be a good goal:
> http://guides.rubyonrails.org
> 
> But still, whenever you output a string to a log, it becomes a string. So, 
> you might be able to make some inroads by changes to Rails and related 
> documentation, but if Ruby "fixed it" instead via something like StringPool 
> (again- a major and breaking change), then you wouldn't have to worry about 
> wasting all that time on the Rails side.
> 
> In addition, many text editors and IDEs have different colors for Strings, so 
> that keys and values stand out better in examples like:
> 
> class Employee < ActiveRecord::Base
>   has_many :subordinates, :class_name => "Employee",
> :foreign_key => "manager_id"
>   belongs_to :manager, :class_name => "Employee"
> end
> 
> So, if you switch to all symbols, it is a little more monotone, colorwise. 
> However, if you switch to Ruby 1.9 key/value then you could color the key in 
> a: :b differently by the fact that it ends in a colon vs. starting with one. 
> Unfortunately, the existing default color schemes don't usually do that.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/rubyonrails-core/-/W-QsFXyc4cwJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Versioning of Views; Our Approach

[Richard Schneeman]

Seems the idea is :-1: from core. Won't be accepted. Thanks for the 
consideration, please move discussion to railscore-talk.  

--  
Richard  

Sent from the road


On Wednesday, September 19, 2012 at 11:32 PM, Pascal Hurni wrote:

> I would even go further on this case, have the web server extract the api 
> version and proxy to the correct app instance.
> Of course it may use a bit more server resources but the ease of deployment 
> and bug fixes (in each supported version) is so high, and no more 'if's ;-)
>  
> (Just thinking out loud)
>  
> Regards,
>  
> Le 20.09.12 04:51, Ben Willis a écrit :
> > I see your point Ryan, but if you have different code paths for different 
> > versions the 'if' logic has to go somewhere. Most of the other approaches 
> > will push the conditional into your routes file which makes it more 
> > difficult to dry your controller logic. Ideally you do not need to have 
> > these code paths at all and the only thing changing is the view of the 
> > payload.  
> >  
> > On Wed, Sep 19, 2012 at 6:28 PM, Ryan Bigg  > (mailto:radarliste...@gmail.com)> wrote:
> > > This seems a bit hacky. I don't like the idea of having conditionals in 
> > > your controller actions to determine different code paths. That feels a 
> > > bit like the olden days in PHP-land.  
> > >  
> > > On Thursday, 20 September 2012 at 2:26 AM, Jim Jones wrote:
> > >  
> > > > Thanks for the feedback guys.  
> > > >  
> > > > > In my experience, however, it's usually more than just the view that 
> > > > > changes between versions. The controller receives customizations as 
> > > > > well, sometimes.  Therefore, I think that versioning the views is not 
> > > > > a "majority case" and shouldn't be a core feature.  
> > > >  
> > > > Ryan, we've updated our samples to show how changes to your API logic 
> > > > (per version) can be accounted for in your controllers to ensure 
> > > > backwards/forwards compatibility :  
> > > >  
> > > > class PostsController < ApplicationController  
> > > >   def index
> > > > # shared code for all versions
> > > > @posts = Post.scoped
> > > >  
> > > > # version 3 or greated supports embedding post comments  
> > > > if requested_version >= 3
> > > >   @posts = @posts.includes(:comments)
> > > > end
> > > >   end
> > > > end
> > > >  
> > > > It's just a simple comparison against the view version.  
> > > >  
> > > > The beauty of the view based APIs is that they allow you to easily 
> > > > reuse your existing controller logic.  Separating of API logic into 
> > > > their own controllers doesn't have that advantage.  
> > > >  
> > > > So our solution covers both the controller, allowing you to make 
> > > > exceptions to ensure forwards/backwards compatibility by simply 
> > > > checking against the current version (please see our updated examples) 
> > > > and then the aforementioned view version with degradation support.  
> > > >  
> > > > Jim Jones  
> > > > http://www.github.com/aantix
> > > >  
> > > > On Sunday, September 16, 2012 1:46:34 PM UTC-7, mrloz wrote:  
> > > > > I just wanted to chime in a second.
> > > > >  
> > > > > I agree this versioning is a little niche.  
> > > > >  
> > > > > Is there, however, a neat public API in rails for gem authors to add 
> > > > > in lookup match parts for view lookup?  
> > > > >  
> > > > > I.e is it possible to register (:apiversion) into lookup paths and 
> > > > > have it be handled by my class (ApiVersionPathHandler). Similar to 
> > > > > the current .format and .locale stuff in view file names  
> > > > >  
> > > > > For me it might be about other things (regions, roles whatever my gem 
> > > > > wants to provide)  
> > > > >  
> > > > > I am under the impression that these parts are not open to extension 
> > > > > at present.  
> > > > >  
> > > > > Cheers
> > > > >  
> > > > > Sent from my iPhone  
> > > > >  
> > > > > On 16 Sep 2012, at 21:21, Ryan Bigg  wrote:
> > > > >  
> > > > > > [This email will arrive approx 15 hours after I've written it. 
> > > > > > Sorry if there's been talk on this post by that stage that I am 
> > > > > > "ignoring"]  
> > > > > >  
> > > > > > I'm not sure I can agree with such a feature being a part of Rails 
> > > > > > just yet. There is currently many different approaches to designing 
> > > > > > APIs with Rails, going from the very basic "render JSON" calls in 
> > > > > > the controllers, to rabl and (god forbid, only because the syntax 
> > > > > > is really ugly) JBuilder, to ActiveModel::Serializers and not to 
> > > > > > forget the new Rails::API gem thing that Santiago Pastorino and co 
> > > > > > are working on.  
> > > > > >  
> > > > > > My point is that there's all these different ways to do the design 
> > > > > > of the API and, besides the default render call, none of these are 
> > > > > > core Rails features. They're all external gems that offer their 
> > > > > > unique take on how to "properly" design an API.  
> > > > > >  
> > >

Re: [Rails-core] Re: Any rails experts able to offer some advice?

[Richard Schneeman]

When I have problems isolating behavior in tests, sometimes it can be useful to 
test more rather than less. If you are testing log output, use a dummy rails 
app inside of your test suite with dummy controller actions and hit it as a 
user would with capybara. Then you could route logs to stdout or a custom log 
object, or simply parse the log file in log/ to verify the correct strings are 
being written. While not as helpful for development as unit tests, this type of 
end-to-end testing is great for protecting against regressions and bugs.

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Wednesday, September 26, 2012 at 5:05 AM, Jeffrey Jones wrote:

> Ahoi Gary
> 
> Thanks for the info but the gem has already been created and the testing I 
> want to do is not obvious (to my mind anyway) so online "Getting started" 
> style stuff that I have found is not that useful..
> 
> This is why I was asking if an expert can offer some time to answer specific 
> questions I have and help my get my head around it.
> 
> On a site-note by hacking around I seem to have got the LogSubscriber tests 
> working, still no idea on how to do the rack logger tests though.
> 
> Cheers
> 
> Jeff 
> 
> 
> On 25/09/12 23:58, Gary Weaver wrote:
> > Not an expert, but since I have been kind of slack on testing recently, 
> > I'll try to get some karma by trying to help. First, you may want to ask on 
> > this list instead/too:
> > https://groups.google.com/forum/?fromgroups=#!forum/rubyonrails-talk
> > (Stackoverflow is also a good place to get Rails stuff answered for more 
> > specific questions.)
> > 
> > This was the thing for Rails 3.0:
> > https://github.com/josevalim/enginex
> > 
> > After that it became:
> > rails plugin new
> > 
> > In: http://guides.rubyonrails.org/plugins.html
> > 
> > > 1.2 Or generate a gemified plugin.
> > > 
> > > Writing your Rails plugin as a gem, rather than as a vendored plugin, 
> > > lets you share your plugin across different rails applications using 
> > > RubyGems and Bundler.
> > > 
> > > Rails 3.1 ships with a rails plugin new command which creates a skeleton 
> > > for developing any kind of Rails extension with the ability to run 
> > > integration tests using a dummy Rails application. See usage and options 
> > > by asking for help:
> > > $ rails plugin --help
> > 
> > This looks like it might help:
> > http://namick.tumblr.com/post/17663752365/how-to-create-a-gemified-plugin-with-rails-3-2-rspec
> > 
> > Rails initialization guide since you mentioned wanting to know the boot 
> > process, but sounds like you don't need it:
> > http://guides.rubyonrails.org/initialization.html
> > 
> > 
> > On Tuesday, September 25, 2012 1:00:38 AM UTC-4, Jeffrey Jones wrote: 
> > > Hello all. 
> > > 
> > > #1 I am working on a rails3 gem called Yarder 
> > > (https://github.com/rurounijones/yarder). The goal of this gem is to 
> > > replace the rails logging system with one that is JSON based rather than 
> > > string based. 
> > > 
> > > #2 To this end I also recently asked this list about making the 
> > > LogSubscribers subscriptions to ActiveRecord::Notifications configurable 
> > > and am looking at submitting a patch request. 
> > > 
> > > However for both of these I have rather run into a brick wall. 
> > > 
> > > #1 Yarder works (mostly, I have not finished or refactored and there are 
> > > probably bugs) but it has no tests. The reasons for this is that I 
> > > cannot get my head around how to test it (and how to set up the tests in 
> > > the first place ) and there aren't examples of this kind of stuff online 
> > > that I can see (rails own LogSubscriber tests use a lot of support files 
> > > specific to the rails gems which makes using them as a base less than 
> > > obvious) 
> > > 
> > > #2 For this I am just not exactly sure how to start (Both dev and test) 
> > > 
> > > I have spent the last week or so looking through the rails code-base and 
> > > testing setup to try and grok how to do the above but it is beyond me at 
> > > the moment. 
> > > 
> > > I don't suppose there is a altruistic rails expert out there who is 
> > > willing to spare some time (email, skype, whatever suits you best) to 
> > > help me get my head around the rails internals (mainly the boot process 
> > > and what to change for #2 plus setting up the tests) and

Re: [Rails-core] Re: Any rails experts able to offer some advice?

[Richard Schneeman]

Check out https://github.com/schneems/wicked  all of the tests are integration 
tests with capybara. If something is going to break it is going to break in a 
way the user would see it. You can see a variety of mixed 
unit/controller/integration tests in my OAuth provider gem 
https://github.com/opro/opro. 

You get a dummy Rails app for free when you initialize a new project using 
https://github.com/josevalim/enginex, I haven't tried with `rails plugin new` 
but I would expect you get something similar. This article should have some 
info on testing for you: 
http://coding.smashingmagazine.com/2011/06/23/a-guide-to-starting-your-own-rails-engine-gem/
 but it is a bit dated. 

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Wednesday, September 26, 2012 at 8:12 PM, Jeffrey Jones wrote:

> Hello Richard.
> 
> That makes sense, and it is the route I am looking at, but how does one boot 
> the dummy app and access it using (for example) capybara?
> 
> Most information and repositories I have seen online do unit testing against 
> the dummy app; I have not found any information on how to do full integration 
> tests against the dummy app.
> 
> I am suer I must be missing something obvious or have managed to miss an 
> obvious example repository to look at but I am not sure what (Hence the 
> missing it in the first place)
> 
> cheer
> 
> Jeff
> 
> 
> On 27/09/12 01:50, Richard Schneeman wrote:
> > When I have problems isolating behavior in tests, sometimes it can be 
> > useful to test more rather than less. If you are testing log output, use a 
> > dummy rails app inside of your test suite with dummy controller actions and 
> > hit it as a user would with capybara. Then you could route logs to stdout 
> > or a custom log object, or simply parse the log file in log/ to verify the 
> > correct strings are being written. While not as helpful for development as 
> > unit tests, this type of end-to-end testing is great for protecting against 
> > regressions and bugs. 
> > 
> > --  
> > Richard Schneeman
> > http://heroku.com
> > 
> > @schneems (http://twitter.com/schneems)
> > 
> > 
> > 
> > 
> > On Wednesday, September 26, 2012 at 5:05 AM, Jeffrey Jones wrote:
> > 
> > > Ahoi Gary
> > > 
> > > Thanks for the info but the gem has already been created and the testing 
> > > I want to do is not obvious (to my mind anyway) so online "Getting 
> > > started" style stuff that I have found is not that useful..
> > > 
> > > This is why I was asking if an expert can offer some time to answer 
> > > specific questions I have and help my get my head around it.
> > > 
> > > On a site-note by hacking around I seem to have got the LogSubscriber 
> > > tests working, still no idea on how to do the rack logger tests though.
> > > 
> > > Cheers
> > > 
> > > Jeff 
> > > 
> > > 
> > > On 25/09/12 23:58, Gary Weaver wrote:
> > > > Not an expert, but since I have been kind of slack on testing recently, 
> > > > I'll try to get some karma by trying to help. First, you may want to 
> > > > ask on this list instead/too:
> > > > https://groups.google.com/forum/?fromgroups=#!forum/rubyonrails-talk 
> > > > (https://groups.google.com/forum/?fromgroups=#%21forum/rubyonrails-talk)
> > > > (Stackoverflow is also a good place to get Rails stuff answered for 
> > > > more specific questions.)
> > > > 
> > > > This was the thing for Rails 3.0:
> > > > https://github.com/josevalim/enginex
> > > > 
> > > > After that it became:
> > > > rails plugin new
> > > > 
> > > > In: http://guides.rubyonrails.org/plugins.html
> > > > 
> > > > > 1.2 Or generate a gemified plugin.
> > > > > 
> > > > > Writing your Rails plugin as a gem, rather than as a vendored plugin, 
> > > > > lets you share your plugin across different rails applications using 
> > > > > RubyGems and Bundler.
> > > > > 
> > > > > Rails 3.1 ships with a rails plugin new command which creates a 
> > > > > skeleton for developing any kind of Rails extension with the ability 
> > > > > to run integration tests using a dummy Rails application. See usage 
> > > > > and options by asking for help:
> > > > > $ rails plugin --help
> > > > 
> > > > This looks like it might help:
> > > > http://namick.

Re: [Rails-core] gitignore - adding database.yml

[Richard Schneeman]

If you don't want to commit sensitive info to your database.yml file, don't use 
your database.yml file. Instead set an environment variable with 
DATABASE_URL=yourconnectionstring  

This is supported on Rails 4.0 as far as I know, if you run into problems 
message me, I'll be happy to take a look. 

In general ask yourself, "can I open source my project if I really wanted to 
right now without opening up a giant security flaw". If the answer is no, put 
whatever sensitive data opens that flaw into an environment variable and then 
have your ruby code read from that variable like: ENV["DATABASE_URL"]. 

In development i use Foreman and a .env file for sensitive credentials. In 
production you could use the same, put it in your bash files, or use config 
vars if you're using Heroku.

Related: http://www.12factor.net/config

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Friday, October 5, 2012 at 11:54 AM, Robert Evans wrote:

> It's a pretty common practice (and best practice) to not include your 
> config/database.yml file inside your git repo. I'd like to add 
> config/database.yml to the generated .gitignore file when creating a new 
> rails application. Any objects, concerns, etc. before I got submit a PR?
> 
> Thanks! 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/rubyonrails-core/-/g1IXETeCZEEJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] destroy callbacks race condition

[Richard Schneeman]

Can you write a public rails app that reproduces this issue? This behavior 
would be undesired and therefore a bug. If we can reproduce and attach that to 
an issue it could help the discussion.  

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Friday, October 12, 2012 at 7:53 AM, Brian Durand wrote:

> I've been looking into consistency problem with association counter caches 
> where the counter cache value in the database is not consistent with the 
> actual number of records in the association. What I've found is that it is 
> from a concurrency issue where two process try to destroy the same record at 
> the same time. Here is the pseudo SQL that is sent to the database when two 
> process are deleting at the same time:
> 
>   process_1 -> SELECT * FROM table WHERE id = 1
>   process_2 -> SELECT * FROM table WHERE id = 1
>   process_1 -> BEGIN
>   process_2 -> BEGIN
>   process_1 -> UPDATE parent_table SET counter_cache = 
> COALESCE(counter_cache, 0) - 1 WHERE id = 1
>   process_1 -> DELETE FROM table WHERE id = 1
>   process_1 -> COMMIT
>   process_2 -> UPDATE parent_table SET counter_cache = 
> COALESCE(counter_cache, 0) - 1 WHERE id = 1
>   process_2 -> DELETE FROM table WHERE id = 1
>   process_2 -> COMMIT
> 
> What happens is process_1 updates the counter cache and deletes the record. 
> Process_2 simply updates the counter cache because the record is already 
> deleted by the time it tries to delete it.
> 
> This is a pretty complicated issue and it touches more than just this one 
> test case. The problem being that all the before and after destroy callbacks 
> will be called regardless of if the record is actually destroyed. In the 
> particular case of the counter caches, I think it could be fixed by moving 
> the callback from a before_destroy to an after_destroy and adding a check in 
> ActiveRecord to only call after destroy callbacks if a row was actually 
> removed from the table.
> 
> In general I think it would be correct to make this general behavior so that 
> after_destroy callbacks are not called if no record was deleted. However, 
> that could affect quite a few things inside application code which could 
> potentially leave objects in an inconsistent state because an expected 
> callback was not called. I think the pending upgrade to Rails 4.0 might be a 
> good time to introduce such behavior since it's a major upgrade and as such 
> people should not be expecting applications to work 100% without some 
> alterations. This does not touch on the issue of before_destroy callbacks 
> which would not be able to check the status of the delete operation. This 
> could be handled with documentation stating that this is a known issue.
> 
> Another solution that would have less effect on current applications (but 
> also leave them more vulnerable to being in an inconsistent state) would be 
> to provide some sort of flag within the record that after_destroy callbacks 
> could check if they are persisting data or interacting with external systems. 
> Something like "row_deleted?" so that callbacks could be defined as:
> 
>   after_destroy :my_callback, :if => :row_deleted?
> 
> Thoughts? 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/rubyonrails-core/-/KnPOlQzxj2cJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Custom accept headers

[Richard Schneeman]

A. S 

-- 
Richard Schneeman
http://heroku.com
@schneems

Sent from the road


On Wednesday, October 31, 2012 at 6:37 AM, Christopher COCCHI-PERRIER wrote:

> Hi,
> 
> Currently I see many applications using custom accept headers for their API 
> versionning such as application/vnd.foo-v1+json or application/vnd.bar-3+xml. 
> But when Rails receive such an accept header, it cannot convert it to a 
> standart Mime::Type and thus causing problems errors when using `respond_to` 
> with :json or :xml.
> 
> And Mime::Type#register only allows to register string not regexp, so it is 
> not convenient when coming to versionning.
> 
> Shouldn't Rails coerce these new almost standart headers to application/json 
> and applicatioin/xml (for previous example) ?
> 
> If you think this should goes into Rails, I'd be happy to provide a pull 
> request.
> 
> Cheers, 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/rubyonrails-core/-/CubR52aCYWcJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Custom accept headers

[Richard Schneeman]

S w mill wxswcsswxe ce cxssxsqseaxqxxqs six desqssx. W ce cedsdc cx dA 

-- 
Richard Schneeman
http://heroku.com
@schneems

Sent from the road


On Wednesday, October 31, 2012 at 6:37 AM, Christopher COCCHI-PERRIER wrote:

> Hi,
> 
> Currently I see many applications using custom accept headers for their API 
> versionning such as application/vnd.foo-v1+json or application/vnd.bar-3+xml. 
> But when Rails receive such an accept header, it cannot convert it to a 
> standart Mime::Type and thus causing problems errors when using `respond_to` 
> with :json or :xml.
> 
> And Mime::Type#register only allows to register string not regexp, so it is 
> not convenient when coming to versionning.
> 
> Shouldn't Rails coerce these new almost standart headers to application/json 
> and applicatioin/xml (for previous example) ?
> 
> If you think this should goes into Rails, I'd be happy to provide a pull 
> request.
> 
> Cheers, 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/rubyonrails-core/-/CubR52aCYWcJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Custom accept headers

[Richard Schneeman]

Sorry about that... Pocket email. 

-- 
Richard Schneeman
http://heroku.com
@schneems

Sent from the road


On Wednesday, October 31, 2012 at 10:15 AM, Richard Schneeman wrote:

> S w mill wxswcsswxe ce cxssxsqseaxqxxqs six desqssx. W ce cedsdc cx 
> dA 
> 
> -- 
> Richard Schneeman
> http://heroku.com
> @schneems
> 
> Sent from the road
> 
> 
> On Wednesday, October 31, 2012 at 6:37 AM, Christopher COCCHI-PERRIER wrote:
> 
> > Hi,
> > 
> > Currently I see many applications using custom accept headers for their API 
> > versionning such as application/vnd.foo-v1+json or 
> > application/vnd.bar-3+xml. But when Rails receive such an accept header, it 
> > cannot convert it to a standart Mime::Type and thus causing problems errors 
> > when using `respond_to` with :json or :xml.
> > 
> > And Mime::Type#register only allows to register string not regexp, so it is 
> > not convenient when coming to versionning.
> > 
> > Shouldn't Rails coerce these new almost standart headers to 
> > application/json and applicatioin/xml (for previous example) ?
> > 
> > If you think this should goes into Rails, I'd be happy to provide a pull 
> > request.
> > 
> > Cheers, 
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "Ruby on Rails: Core" group.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msg/rubyonrails-core/-/CubR52aCYWcJ.
> > To post to this group, send email to rubyonrails-core@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > rubyonrails-core+unsubscr...@googlegroups.com.
> > For more options, visit this group at 
> > http://groups.google.com/group/rubyonrails-core?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Testing against ruby2

[Richard Schneeman]

This would be great to get set up. There are some issues with 2.0.0 preview1 on 
Travis right now though.   

--  
Richard Schneeman
http://heroku.com
@schneems

Sent from the road


On Thursday, November 15, 2012 at 4:02 PM, Rafael Mendonça França wrote:

> I think so, I have to check with travis-ci guys.
>  
> Rafael Mendonça França
> http://twitter.com/rafaelfranca
> https://github.com/rafaelfranca
>  
>  
>  
> On Thu, Nov 15, 2012 at 11:59 AM, Johnneylee Rollins 
> mailto:johnneylee.roll...@gmail.com)> wrote:
> > Is there a chance we could add ruby2 to the travis-ci config?
> >  
> > ~Spaceghost  
> >  
> > --  
> > You received this message because you are subscribed to the Google Groups 
> > "Ruby on Rails: Core" group.
> > To post to this group, send email to rubyonrails-core@googlegroups.com 
> > (mailto:rubyonrails-core@googlegroups.com).
> > To unsubscribe from this group, send email to 
> > rubyonrails-core+unsubscr...@googlegroups.com 
> > (mailto:rubyonrails-core%2bunsubscr...@googlegroups.com).
> > For more options, visit this group at 
> > http://groups.google.com/group/rubyonrails-core?hl=en.
>  
> --  
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Error in ActiveRecord::Associations::AliasTracker when using subquery

[Richard Schneeman]

Can you open up a github issue for this? Also include the active record code 
that was used to generate the error, please try with Active Record 3.2.9 to 
make sure the bug hasn't been fixed there already. Please re-write any custom 
active record methods such as `tagged_with` with the plain old active record, 
to clearly demonstrate how to reproduce the error with only active record. 


Github issues is the best place for bug reports.

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Sunday, December 23, 2012 at 8:22 AM, Manuel Meurer wrote:

> Hi all,
> 
> I encountered an error in ActiveRecord when using subqueries.
> 
> NoMethodError: undefined method `left' for :count:Symbol
> # 
> /Users/me/.rbenv/versions/1.9.3-p327-perf/lib/ruby/gems/1.9.1/gems/activerecord-3.2.6/lib/active_record/associations/alias_tracker.rb:64:in
>  `block in initial_count_for'
> 
> 
> (See the full stack trace here: https://gist.github.com/4363280)
> 
> This is the offending SQL query:
> 
> SELECT "taggable_models".* FROM (SELECT count("tags"."id") AS tags_count, 
> taggable_models.* FROM "taggable_models" INNER JOIN "taggings" ON 
> "taggings"."taggable_id" = "taggable_models"."id" AND 
> "taggings"."taggable_type" = 'TaggableModel' INNER JOIN "tags" ON "tags"."id" 
> = "taggings"."tag_id" WHERE "tags"."name" IN ('foo') GROUP BY 
> "taggable_models"."id", "taggable_models"."user_id", 
> "taggable_models"."name", "taggable_models"."type", "taggable_models"."foo" 
> ORDER BY tags_count desc) taggable_models
> 
> Can anyone see something crazy with this immediately?
> Is the "SELECT count("tags"."id") AS tags_count, taggable_models.* ..."-style 
> subquery bad in general?
> 
> (from https://github.com/bradphelan/rocket_tag/issues/47)
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/rubyonrails-core/-/DJupqZfGhe8J.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] AS core ext idea: Hash#transform_values

[Richard Schneeman]

Changes to AS are very intrusive since they modify classes, getting something 
into AS is probably the hardest of all the libraries included in Rails. It 
doesn't mean you shouldn't try. 

If you're interested and passionate about making this change, I suggest making 
a new branch adding in the extra code to AS including tests as you normally 
would any change, then in a separate commit to the same branch clean up one or 
more of the places where you think using #transform_values could have a huge 
impact. This way anyone can easily see the value of having this method included 
in the AS codebase.

Yay or nay? I would need to see an implementation and usage to make that call. 

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Monday, January 7, 2013 at 1:37 PM, Gosha Arinich wrote:

> Mapping hash keys and values is tricky in Ruby. Mapping a hash returns an 
> array, but we want a hash. Why bother coercing it every time?
> 
> To simplify that a bit, AS introduced Hash#transform_keys. I have noticed 
> Rails source base still uses a few tricks to map values of hashes in 
> different places. Additionally, applications built on top of Rails might 
> experience the need to map hash values as well.
> 
> That said, I propose to extend Hash to allow this, in manner similar to 
> #transform_keys:
> 
> > { a: 1, b: 2 }.transform_keys { |key| :"_#{key}" } # => { :_a => 1, :_b => 
> > 2 }
> > 
> > { a: 1, b: 2 }.transform_values { |val| val ** 2 } # => { :a => 1, :b => 4 }
> 
> Yay or nay? 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/rubyonrails-core/-/jE9nOBXywWkJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Should the secret_token.rb be added to the .gitignore?

[Richard Schneeman]

I've talked at length with developers in Heroku, we're interested in making the 
default security of new Rails apps better out of the box.  

I know there is a much larger discussion going on and I believe there are one 
or more people actively looking into the options. I would like to work with 
anyone interested in security to figure out a good workflow with Heroku. One 
option we discussed would be automatically setting the  a config var such as 
SECRET_TOKEN from the Heroku buildpack, so that it didn't matter if your source 
got exposed, they would need to get into your app as well.

Being able to set the token from an environment variable could also allow 
services to rotate the token without having to modify any files, or touch 
anything you've got in Git. Just a thought.

So again: feel free to ping me on twitter @schneems or in chat: 
richard.schnee...@gmail.com if you're working on security updates. I would like 
to help make the default experience secure and seamless. 

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Friday, January 11, 2013 at 5:29 AM, Rodrigo Rosenfeld Rosas wrote:

> b 

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Should the secret_token.rb be added to the .gitignore?

[Richard Schneeman]

Looks like can set ENV variables from Capistrano fairly trivially:  

http://craiccomputing.blogspot.com/2009/08/capistrano-and-environment-variables.html
 


API docs for Capistrano config:
http://rubydoc.info/github/capistrano/capistrano/master/Capistrano/Configuration/Actions/Invocation


-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Sunday, January 13, 2013 at 3:59 PM, Jay Feldblum wrote:

> Weston,
> 
> I see using environment variables as the interface to configure your 
> application as the anti-Microsoft. As the Unix. It is simple to implement in 
> both the infrastructure (if you are implementing your own) and in your 
> application. 
> 
> The convention is not not Heroku-specific; it is specific to any application 
> which follows the convention of being configured via environment variables, 
> including Heroku applications, 12factor-style applications, 
> CloudFoundry-compatible applications, etc., and any application willing to 
> add two lines of code and a line of whitespace (see below). 
> 
> I'm not sure what's available for Capistrano, but anything that could set up 
> environment variables in a YAML file and symlink the YAML file into the 
> application, so that the application could read it on boot, would be good. 
> 
> Rails could even help this along, by natively supporting reading a 
> config/environment.yml file with environment variables. The file would be 
> gitignored by default and Capistrano could symlink in a production 
> config/environment.yml file when deploying. But it's easy to extend your own 
> application to try to read config/environment.yml early in the boot phase on 
> your own. 
> 
> # require gems w/ bundler
> 
> # import environment variables
> environment_yml = File.expand_path("../environment.yml", __FILE__)
> ENV.update(YAML.load_file(environment_yml)) if 
> File.exist?(environment_yml)
> 
> # setup app config based on environment variables as necessary
> module MyApp
>   class Application < Rails::Application
> config.something = compute_something_from(ENV)
>   end
> end
> 
> Rails supporting a RAILS_SECRET_TOKEN environment variable natively in the 
> generated secret_token.rb (or some other way, as well as a corresponding 
> environment variable for the old token so that you can do zero-downtime, 
> zero-session-clearing, key-rotation) may help the situation with 
> secret-tokens in public repos going forward. Two lines of code, a symlinked 
> YAML file with Capistrano or a config var on Heroku, and it's done. 
> 
> Cheers,
> Jay
> 
> On Sun, Jan 13, 2013 at 3:51 PM, Weston Platter  (mailto:westonplat...@gmail.com)> wrote:
> > @schneems. @jay. Good ideas.
> > 
> > A fear that I have is that these conventions are Heroku specific, and not 
> > deployment agnostic. This feels enterprisely or Microsoft-ishy (or this 
> > feeling could be my own emotional baggage). 
> > 
> > To make this a Rails deployment convention and not just a Heroku, maybe 
> > make a capistrano equivalent to set the secret_token from a shell set 
> > variable? 
> > 
> > Thoughts?
> > 
> > 
> > 
> > On Saturday, January 12, 2013 11:29:54 AM UTC-6, Jay Feldblum wrote:
> > > Richard,
> > > 
> > > That's overall the way I would go too, with two changes.
> > > 
> > > 1. Name the environment variable RAILS_SECRET_TOKEN - i.e., prefixed with 
> > > RAILS_ - since an application may have many secret tokens unrelated to 
> > > session cookies. Environment variables related to a given library or 
> > > framework ought to be prefixed with the name of that library or 
> > > framework, such as RAILS_RELATIVE_URL_ROOT, to avoid easily-avoidable 
> > > conflicts and incompatibilities. 
> > > 
> > > 2. To support token rotation, there needs to be support for two tokens at 
> > > once: the current token and an old token. The old token, if it exists, 
> > > would be used to read session cookies in the HTTP request after the 
> > > attempt to read them with the current token fails, but the current token 
> > > would always be used to sign all session cookies in every HTTP response. 
> > > 
> > > Cheers,
> > > Jay
> > > 
> > > On Friday, January 11, 2013 3:18:14 PM UTC-5, richard schneeman wrote:
> > > > I've talked at length with developers in Heroku, we're interested in 
> > > > making the default security of new Rails apps better out of the box.  
> > > > 
> > > > I know there is a much larger discussion 

Re: [Rails-core] Problem with Bootstrap-SASS

[Richard Schneeman]

Please direct questions about Rails to Rails Talk: 
https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-talk (i see you 
already have) or to StackOverflow. This list is for the programmers who work on 
the framework itself. 

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Tuesday, January 22, 2013 at 11:07 PM, xscr...@gmail.com wrote:

> I've installed bootstrap-sass, and added an @import line in my css. Rails 
> won't find or serve up the bootstrap files. One error msg on the Mozilla 
> console says:
> 
>The stylesheet http://localhost:3000/assets/bootstrap was not loaded 
> because its MIME type, "application/javascript", is not "text/css".
> 
> Hmm. If I change the @import to say "bootstrap.css", bootstrap seems to load, 
> but things like carousel are undefined:
> 
> TypeError: jQuery(...).carousel is not a function
> 
> It seems like something is fundamentally broken with the bootstrap install, 
> but I have no idea what.
> 
> Where are the bootstrap files supposed to be loaded? On my system they're 
> squirreled away inside rvm somewhere. Correct?
> Is there a variable inside rails that describes the directories rails 
> searches for assets?
> 
> Any ideas?
> 
> Per 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/rubyonrails-core/-/TwCiHSfNZgEJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Object#tap_if and Object#tap_unless

[Richard Schneeman]

<% (users = account.users).any? && users.tap do |users| %>

Less pretty, still works.

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Friday, January 25, 2013 at 4:13 PM, Ngan wrote:

> The problem (I think) with that is that "#users" could be an expensive call 
> you only wish to make once.  And I don't want to get into memoizing...
> 
> <% account.expensive_call_for_users.any? && 
> account.expensive_call_for_users.tap ... %>
> 
> 
> On Friday, January 25, 2013 2:11:18 PM UTC-8, Godfrey Chan wrote:
> > Actually, on second thought, this would do exactly what you wanted, and 
> > It's Just Ruby (tm):
> > <% account.users.any? && account.users.tap do |users| %>
> > # ... <% end %>
> > 
> > 
> > 
> > On Fri, Jan 25, 2013 at 2:09 PM, Ngan  
> > wrote:
> > > Thank you Godfrey! This does solve 99% of my cases!
> > > 
> > > @Andrew Using if, the variable "users" is now available everywhere...I 
> > > only want it available in my block.
> > > 
> > > 
> > > On Friday, January 25, 2013 2:05:31 PM UTC-8, Godfrey Chan wrote:
> > > > Object#try takes a block. It'll probably take care of most simple cases 
> > > > for you:
> > > > 
> > > > <% account.owner.try do |user| %>  <% end %>
> > > > 
> > > > 
> > > > On Fri, Jan 25, 2013 at 1:17 PM, Ngan  wrote:
> > > > > I originally brought this up in: 
> > > > > https://github.com/rails/rails/issues/9067
> > > > > 
> > > > > 
> > > > > Rails paved the way for Object#tap and Object#try...I'd like to 
> > > > > propose Object#tap_if and its counterpart,Object#tap_unless.
> > > > > 
> > > > > 
> > > > > I've been following 37signals conventions of tapping variables in the 
> > > > > views:
> > > > > 
> > > > > <% account.owner.tap do |user| %> ... <% end %> 
> > > > > 
> > > > > But, I find myself having to do this a lot...
> > > > > 
> > > > > <% account.owner.tap do |user| %> <% if user %> ... <% end %> <% end 
> > > > > %> 
> > > > > 
> > > > > It would be great if we could do...
> > > > > 
> > > > > <% account.owner.tap_if(:present?) do |user| %> ... <% end %> <% 
> > > > > account.users.tap_if(:any?) do |user| %> ... <% end %> 
> > > > > 
> > > > > The block would only yield if the method evals to true.
> > > > > 
> > > > > 
> > > > > Carlos mentioned that you can add an "if account.owner.present?" at 
> > > > > the end...
> > > > > But there are times when the account.owner (or something else) call 
> > > > > is expensive and you don't want to call it twice. 
> > > > > 
> > > > > Any feedback would be much appreciated.  Thanks!
> > > > > 
> > > > > -- 
> > > > > You received this message because you are subscribed to the Google 
> > > > > Groups "Ruby on Rails: Core" group.
> > > > > To post to this group, send email to rubyonra...@googlegroups.com.
> > > > > To unsubscribe from this group, send email to 
> > > > > rubyonrails-co...@googlegroups.com.
> > > > > 
> > > > > Visit this group at 
> > > > > http://groups.google.com/group/rubyonrails-core?hl=en.
> > > > > For more options, visit https://groups.google.com/groups/opt_out.
> > > > >  
> > > > >  
> > > > 
> > > -- 
> > > You received this message because you are subscribed to the Google Groups 
> > > "Ruby on Rails: Core" group.
> > > To post to this group, send email to rubyonra...@googlegroups.com 
> > > (javascript:).
> > > To unsubscribe from this group, send email to 
> > > rubyonrails-co...@googlegroups.com (javascript:).
> > > Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> > > For more options, visit https://groups.google.com/groups/opt_out.
> > >  
> > >  
> > 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Rails-core] Re: Home page route instead of root?

[Richard Schneeman]

I've had similar questions from students, though I don't remember if any have 
specifically addressed it as `home`. What if we added the word "home" to the 
description of the root path that is included (and commented out) by default 
after `rails new`? If students don't read or ctrl-f for "home" in the default 
routes file, changing the name generated wouldn't help anyway. 

Adding aliases could be a can of worms, why not 'welcome' or 'core' or 'main' 
etc. This is a relatively trivial in the grand scheme of things to discuss, 
open up a PR (i would prefer documentation for now) and we can talk about it 
there. 

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Monday, March 11, 2013 at 11:11 AM, Ryan Bigg wrote:

> http://transitionculture.org/wp-content/uploads/bikeshed2.jpg
> 
> 
> On 11 March 2013 07:23, Apoorv Parijat  (mailto:apoorvpari...@gmail.com)> wrote:
> > For a domain, say "example.org (http://example.org)", you would call 
> > "example.org/ (http://example.org/)" as the "root" domain. The "root" 
> > domain points to the "home" page 
> > of the website. The idea of "root" should be made clear to students from 
> > the beginning.
> > 
> > I think, since "root" is not that obscure, we can just let it be ?
> > 
> > 
> > On Monday, 11 March 2013 04:12:38 UTC+5:30, Jeff Cohen wrote:
> > > Maybe it's just me, but I think "home" might be a better description than 
> > > "root".  Students ask me "how do I indicate which action is my home 
> > > page," not "how do I indicate which action is my root page."  If this 
> > > sounds appealing I can try to dig through the router code and see if I 
> > > can submit a PR in time for Rails 4, and make "home" an alias for "root". 
> > > 
> > > But if there's actually a good reason for keeping it as "root," let me 
> > > know and save me the effort :-)
> > > 
> > > Thanks!
> > > Jeff
> > > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "Ruby on Rails: Core" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to rubyonrails-core+unsubscr...@googlegroups.com 
> > (mailto:rubyonrails-core%2bunsubscr...@googlegroups.com).
> > To post to this group, send email to rubyonrails-core@googlegroups.com 
> > (mailto:rubyonrails-core@googlegroups.com).
> > Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >  
> >  
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Rails-core] Controller test session issue when using render

[Richard Schneeman]

If you can reproduce this problem in a new app open an issue on rails/rails. If 
you cannot, I suggest posting a question on Stack Overflow.  

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Friday, March 15, 2013 at 9:21 AM, Fabio Kreusch wrote:

> I'm using Rails 3.2.12, and I have a spec similar to this:
> 
> # Spec
> before do
>   post :create
> end
> 
> it { session[:order_id].should be_nil }
> 
> # Controller
> def create
>   ...
>   
>   session[:order_id] = nil
> end
> 
> Now, that spec passes/fails depending on the controller redirecting or 
> rendering:
> 
> Passes: redirect_to root_path
> Fails: render :create
> 
> Is this an expected behavior? 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Rails-core] ActiveRecord should eager load the parent record when fetching a relation Edit

[Richard Schneeman]

This could potentially cause performance problems with apps that were not built 
expecting this behavior. We want to stay away from features that are _too_ 
magical. If anything I would make the behavior "opt in" by specifying some flag 
in the model like: 

belongs_to :user, eager_load: true

Or as a separate method

eager_load_parent!

If this is a feature you would like, I suggest you turn it into a Gem and get 
real world usage and feedback from the community. 

-- 
Richard Schneeman
http://heroku.com
@schneems

Sent from the road


On Saturday, March 23, 2013 at 9:51 AM, Adrien Siami wrote:

> Hi guys,
> 
> I created a ticket about this issue on the github repository but I was told 
> it's not a bug, so here I am !
> 
> The link to the closed issue : https://github.com/rails/rails/issues/9886
> 
> The link to the example repository : 
> https://github.com/Intrepidd/eager-loading-parent
> 
> I'd love to submit a pull request for that but I'm very new in the rails edge 
> world.
> 
> What do you think ?  
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Rails-core] How to resolve gem dependencies?

[Richard Schneeman]

This would be a better question for Stack Overflow (http://stackoverflow.com). 
This list is reserved for discussion of new features for  people building the 
Rails framework.  

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Wednesday, March 27, 2013 at 7:48 AM, Chris Edwards wrote:

> Hi,
> 
> I've just touched the surface of rails & ruby and I'm wondering what the 
> steps would be to resolve this;
> 
> Fetching gem metadata from https://rubygems.org/.
> Fetching gem metadata from https://rubygems.org/..
> Resolving dependencies...
> Bundler could not find compatible versions for gem "jquery-rails":
>   In Gemfile:
> refinerycms (>= 2.0.10) ruby depends on
>   jquery-rails (~> 2.0.0) ruby
> 
> spree (>= 1.3.1) ruby depends on
>   jquery-rails (2.2.0)
> 
> 
> 
> I'd like to use refinerycms and spree at the same time by the jquery-rails 
> versions get in the way. I really dont want to downgrade what Spree is 
> capable of.. Any way I can force refinerycms to use jquery-rails 2.2.0?
> 
> Thanks
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Rails-core] undefined method 'sanitize_limit' for #

[Richard Schneeman]

This list is reserved for discussion of the upcoming release of Rails and it's 
contributors. For general bugs and questions please ask this question on stack 
overflow or post to 
https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-talk 

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Thursday, March 28, 2013 at 5:50 AM, Tanmay Baid wrote:

> I am trying to upgrate rails from 3.0 to 3.1, while updating rails version I 
> am getting following error
> 
> rake aborted!
> undefined method `sanitize_limit' for #
> /some_package/lib/ruby/gems/1.8/gems/activerecord-3.1.12/lib/active_record/relation.rb:460:in
>  `method_missing'
> /some_package/lib/ruby/gems/1.8/gems/activerecord-3.1.12/lib/active_record/relation/query_methods.rb:208:in
>  `build_arel'
> /some_package/lib/ruby/gems/1.8/gems/activerecord-3.1.12/lib/active_record/relation/query_methods.rb:196:in
>  `arel'
> /some_package/lib/ruby/gems/1.8/gems/activerecord-3.1.12/lib/active_record/relation.rb:112:in
>  `to_a'
> /some_package/lib/ruby/gems/1.8/gems/activerecord-3.1.12/lib/active_record/relation/finder_methods.rb:376:in
>  `find_first'
> /some_package/lib/ruby/gems/1.8/gems/activerecord-3.1.12/lib/active_record/relation/finder_methods.rb:122:in
>  `first'
> 
> Error is occurred at the execution of following statement:
> test = where(search_column_name => attributes[search_column_name]).first
> 
> I found following solution on internet:
> https://github.com/rails/rails/issues/1974
> 
> Hence updated to:
> test = where(search_column_name => 
> attributes[search_column_name]).all.to_a.first
> 
> ...and this statement started working fine.
> 
> But, find_by_name() is still failing with the same error.
> for eg. the below statement is not always working.
> test_lookup = find_by_identifier(lookup_str) || find_by_name(lookup_str) || 
> find_by_abbreviation(lookup_str)
> 
> statement is called under a function, defined in a model:
> def self.lookup(lookup_str)
>   return nil if lookup_str.blank?
>   test_lookup = find_by_identifier(lookup_str) || find_by_name(lookup_str) || 
> find_by_abbreviation(lookup_str)
>   return test_lookup if test_lookup.present?
> end
> 
> It throws following error:
> rake aborted!
> undefined method `sanitize_limit' for #
> /some_package/lib/ruby/gems/1.8/gems/activerecord-3.1.12/lib/active_record/relation.rb:460:in
>  `method_missing'
> /some_package/lib/ruby/gems/1.8/gems/activerecord-3.1.12/lib/active_record/relation/query_methods.rb:208:in
>  `build_arel'
> /some_package/lib/ruby/gems/1.8/gems/activerecord-3.1.12/lib/active_record/relation/query_methods.rb:196:in
>  `arel'
> /some_package/lib/ruby/gems/1.8/gems/activerecord-3.1.12/lib/active_record/relation.rb:112:in
>  `to_a'
> /some_package/lib/ruby/gems/1.8/gems/activerecord-3.1.12/lib/active_record/relation/finder_methods.rb:376:in
>  `find_first'
> /some_package/lib/ruby/gems/1.8/gems/activerecord-3.1.12/lib/active_record/relation/finder_methods.rb:122:in
>  `first'
> /some_package/lib/ruby/gems/1.8/gems/activerecord-3.1.12/lib/active_record/relation/finder_methods.rb:263:in
>  `send'
> /some_package/lib/ruby/gems/1.8/gems/activerecord-3.1.12/lib/active_record/relation/finder_methods.rb:263:in
>  `find_by_attributes'
> /some_package/lib/ruby/gems/1.8/gems/activerecord-3.1.12/lib/active_record/base.rb:1074:in
>  `send'
> /some_package/lib/ruby/gems/1.8/gems/activerecord-3.1.12/lib/active_record/base.rb:1074:in
>  `method_missing'
> 
> What should be the alternative for find_by_name() [i.e. 
> find_by_attribute()]???
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Rails-core] ActionMailer configuration API

[Richard Schneeman]

Storing configuration in your git repository is not the greatest thing on 
earth: http://www.12factor.net/config 

At least by pulling it from code it becomes very easy to assign to ENV 
Variables.  

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Sunday, May 5, 2013 at 8:04 PM, Amiel Martin wrote:

> I chose to make ActionMailer like ActiveRecord because I think that more 
> people know ActiveRecord's configuration. However, if there is something 
> about the way ActionMailer is configured that is desired, then ActiveRecord's 
> configuration could also be changed (although it seems like it would be 
> harder to change and deprecate ActiveRecord configuration).
> 

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Rails-core] Issue triage & process

[Richard Schneeman]

I encourage people to volunteer to look at tickets. Get one a day in your 
inbox: 

http://www.codetriage.com/rails/rails 

If you want people to look at your pull requests and issues the best way to 
start is to look over other people's.

You are the community.

-- 
Richard Schneeman
http://heroku.com
@schneems

Sent from the road


On Thursday, June 13, 2013 at 2:49 PM, Steve Klabnik wrote:

> I personally read each and every single comment, pull request, and issue.
> 
> That said, I can't always help, so when I can't, I don't say anything.
> 
> There isn't really a process, as almost nobody is actually paid to
> work on Rails. People do the work when they feel like it and however
> much they feel like it, and everyone has their own process.
> 
> That said, of course, we do make sure that there aren't known
> regressions in releases, things like that.
> 
> > As a community member, what can I do to help?
> 
> Ask for reproductions on issues that don't have them, writing
> reproductions is even better. Verify that older bugs haven't gotten
> 'accidentally' fixed and are still an issue. Write patches for bugs
> that are open.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 


-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Rails-core] Pull requests on Github

[Richard Schneeman]

Maybe you can get together a local bug fixing support group that meets once 
every other week and pairs on existing open issues. Active record should be a 
ripe target.

If you want to pay someone to work on Rails full time, just start doing it. 
Find a company that will hire a full time open source-er (maybe you) and have 
them work with pull requests and issues. In time if their work is valuable they 
will be given commit access. If not, don't continue to pay them.

If you want to be on rails core then start acting like you're in rails core. 
Fix bugs, comment on pull requests, submit docs, and develop a rapport with the 
core team.  

Another option is to reach out to those with commit who freelance. Maybe you 
can hire them at their rate to work more on Rails.

The key here is to try things today. If they work out then tell everyone about 
your successes and maybe they can be repeated. If not, keep trying till you 
find something that does.

Raphael is correct. The team is coming off of a major release and the issues 
will get better. It still doesn't stop you from making an effort today.  

--  
Richard Schneeman
http://www.codetriage.com
@schneems

Sent from the road


On Thursday, July 18, 2013 at 6:48 AM, Rafael Mendonça França wrote:

> I don't think we need to do something. If you look at projects with same size 
> of Rails or closer you will see we are very active.
>  
> We just released a major feature and, well, I think we deserve some kind of 
> rest. When we need to work you will see that issue page decreasing like 
> crazy.  
>  
> Rafael Mendonça França
> http://twitter.com/rafaelfranca
> https://github.com/rafaelfranca
>  
>  
> On Thu, Jul 18, 2013 at 7:54 AM, "Marc Schütz"  (mailto:schue...@gmx.net)> wrote:
> > Thanks for the responses so far. This certainly wasn't meant to criticize 
> > the people who work on Rails and put in a lot of their free time.
> >  
> > It's just that, quite obviously, for whatever reasons, the Rails team isn't 
> > able to keep up with the large number of pull requests (and bug reports 
> > anyway). It seems Andrew Vit also talked about this about a month ago, 
> > which I hadn't seen before I posted.
> >  
> > It was suggested in Andrew's thread and in this one to triage bugs and help 
> > reviewing. However, while this might be useful, I don't think lack of 
> > reviewing is the real problem.
> >  
> > I took a closer look at the open PR's on page 4 (i.e. to avoid the really 
> > new ones). Of these, there are:
> >  
> > New features:   5
> > Refactoring:7
> > Bug fixes: 11
> > Documentation:  2
> > Total: 25
> >  
> > With votes from the community: 2
> > With comm. feedback/suggestions:   8
> > Open questions for submitter/WIP:  6
> > Feedback from core team:  12
> >  
> > This means that for most PRs, there has already been some kind of 
> > review/feedback from either the community or the core team (i.e. those that 
> > I think are members). "Open questions/WIP" are those where the submitter 
> > still needs to do something. There are some others with open questions, but 
> > these are waiting for feedback from the core team. Many of the PR's end 
> > with someone requesting a specific team members opinion, after which 
> > nothing happens.
> >  
> > So... I'd like to ask again, what can be done? Give more people commit 
> > access? Funding for some core team members to be able to dedicate more time 
> > to Rails development? Maybe a better way to prioritize PR's, as Andrew 
> > suggested? Make it easier to decide which features are desired? Other 
> > options?
> >  
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Ruby on Rails: Core" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to rubyonrails-core+unsubscr...@googlegroups.com 
> > (mailto:rubyonrails-core%2bunsubscr...@googlegroups.com).
> > To post to this group, send email to rubyonrails-core@googlegroups.com 
> > (mailto:rubyonrails-core@googlegroups.com).
> > Visit this group at http://groups.google.com/group/rubyonrails-core.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >  
> >  
>  
> --  
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send e

Re: [Rails-core] Setup of rails repo for contribution and existing failing tests

[richard schneeman]

If you have failing tests locally but they are passing on Travis make sure
your master branch is at the same commit of the one Travis ran against.
Sometimes failures do get pushed to master, though they're (hopefully)
fixed quickly, and you may have forked or cloned while master was actually
failing. I like adding an `upstream` remote to my git config `git config
-e` so I can quickly grab the latest from rails/rails master  `git pull
--rebase upstream master`.

All tests should be passing, make sure you haven't accidentally added
anything to the files, also make sure to always run tests with `bundle
exec`. After that it may be something setup with your environment, maybe
try re-installing rubies, and/or ruby gems. Try it on a friends or
co-workers computer to see if you get a failure there, then try to figure
out the differences in environment.

Worst case scenario if you cannot get that one single test passing and you
want to contribute first run the tests against unchanged master (as you
already did) and make note of failing tests. Then make your change in a
 branch, and re-run tests. If no additional tests fail it is likely safe to
make a PR. Pull requests get tested against travis, so you will see if it
fails on CI.

Happy bug fixing,
Richard Schneeman
@schneems



On Fri, Aug 16, 2013 at 5:39 AM, Pawel Janiak wrote:

> I have 2  questions for anyone that contributes to Rails.
>
>
>1. How have you setup your bash output to have colors when running the
>full test suite for easy parsing of red/green/yellow of the suite?
>2. If you run the suite and there are failing tests, is that expected
>from time to time? https://travis-ci.org/rails/rails shows a green
>build but in this instance I get a failure on:
>
>*actionpack/test/controller/render_test.rb:1465*
>
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Rails-core] Rails Guides Idea: Links to relevant API pages

[richard schneeman]

:heart: love this idea.


On Wed, Sep 18, 2013 at 2:26 AM, Xavier Noria  wrote:

> This is a good proposal.
>
> We would need a helper to generate the subdomain depending on whether we
> are generating edge or stable guides.
>
> Also, your idea is related to the new API home page that I have in mind.
> The home page I envision has a similar purpose than your site, an index
> with links to the main topics. The API home page is no longer the Rails
> README to be able to do that. If you'd like to work on something like this
> it would be awesome.
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Rails-core] Re: New Contributor

[richard schneeman]

Thanks for the slide deck, I hadn't seen that before.

For bugs to fix and general issues I recommend
http://www.codetriage.com/rails/rails (though I wrote the original version
of it)

You could also start with documentation, find gaps in the methods already
documented in Rails or in the Rails guides. Maybe find a bunch of methods
documented in a file and find one with missing an example.

For finding things to fix I keep a pretty informal "pain journal" and
whenever I do something in Ruby/Rails that was painful or not intuitive the
first time I make a note of it. If I see others have the same pain, i'll
try to dig in and find a way to fix it or make it better. Working with
beginner groups like Railsgirls helps find pain points fairly easily.

While technical in nature, this talk walks through a PR I made in Rails,
how I broke down the problem and eventually submitted a PR video:
http://www.youtube.com/watch?v=Zd2oUU4qDnY slides:
https://speakerdeck.com/schneems/dissecting-ruby-with-ruby.

--
Richard Schneeman


On Sat, Sep 21, 2013 at 1:09 PM, Kyle Rippey  wrote:

> Hi Lee,
>
> I attended a good talk at RailsConf 2013 which inspired me to start
> contributing to Rails as well. It gives some good guidance on where to
> start and what to expect during the process.
>
> Video: http://www.youtube.com/watch?v=UEB6H8jAzIg
> Slides:
> https://speakerdeck.com/markmcspadden/railsconf-2013-your-first-rails-pull-request
>
> As far as specific things to start working on, I'm sure others on here
> will be able to offer better guidance than I can.
>
> Kyle
>
>
>
> On Saturday, September 21, 2013 8:50:37 AM UTC-7, Lee Hampton wrote:
>>
>> Hey guys,
>>
>> I'm an NYC based rails developer, and I'm interested in getting into
>> contributing to the Rails code base. Just diving right in can be a little
>> bit scary, so if anyone is willing to give me some guidance on good first
>> bugs to tackle or features they need help with, I'd be eternally grateful!
>>
>> Best,
>>
>> Lee
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Rails-core] Re: rails server should optionally log to console the full exception stack trace

[richard schneeman]

It could be useful, cannot auto accept the idea without code. Potentially I 
would want to configure this via ENV var.

—
Sent from Mailbox for iPhone

On Mon, Nov 18, 2013 at 2:27 PM, Alex  wrote:

> So, would this, in principle, be good to add?
> On Thursday, November 14, 2013 4:15:57 AM UTC-5, Alex wrote:
>>
>> AFAICT, it's not possible to force this currently.
>>
>> Frequently the application trace is inadequate and you need the full trace 
>> to get to the bottom of the problem.  For example, let's say your layout 
>> template calls non application (3rd party gem) code which raises.  The 
>> application trace will consist of a single entry, the template being 
>> rendered.
>>
>>
>> actionpack-4.0.1/lib/action_dispatch/middleware/debug_exceptions.rb
>> ___
>> def log_error(env, wrapper)
>>   logger = logger(env)
>>   return unless logger
>>
>>   exception = wrapper.exception
>>
>>   trace = wrapper.application_trace
>>   trace = wrapper.framework_trace if trace.empty?
>>
>>   ActiveSupport::Deprecation.silence do
>> message = "\n#{exception.class} (#{exception.message}):\n"
>> message << exception.annoted_source_code.to_s if 
>> exception.respond_to?(:annoted_source_code)
>> message << "  " << trace.join("\n  ")
>> logger.fatal("#{message}\n\n")
>>   end
>> end
>> ___
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Rails-core] #find_in_batches should support returning Active Relations as well as arrays

[richard schneeman]

Seems good, but could be a bit odd to work with. Most people will have
written code that expects an Array. It seems like an AR relation behaves
exactly like an array (not sure if there are known caveats here). If there
aren't any major caveats, and there's no speed degradation and all tests
pass, I say go for it.


On Tue, Dec 3, 2013 at 11:27 AM, Chris Saunders <
christopher.saund...@jadedpixel.com> wrote:

> I was directed here from the rails repo.
>
> Currently find_in_batches converts all relations into 
> arrays
>  before
> yielding to the block.
>
> It would be nice if we could just work with relations (which are lazy if I
> can recall correctly) and allow the consumer to manipulate data as deemed
> fit. This will also allow some operations to be performed in batches (i.e.
> staggeringupdate_all) instead of needing to recreate the set.
>
> Looking at the code it shouldn't be hard to implement, and I don't mind
> working on the patch. I just wanted to get feedback on this before I go
> ahead and write up the code.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Rails-core] Is it possible to serialize the "query builder data" part of ActiveRecord::Relation

[richard schneeman]

No clue how to do this, this would be a better question for stack overflow
or rubyonrails-talk group. Providing an example of what you're truing to
achieve would help. Please re-post this question to either of those places.


On Tue, Dec 3, 2013 at 12:40 PM, Anton Kuzmin wrote:

> Is it possible to serialize the "query builder data" part of
> ActiveRecord::Relation and use it later to query the database with exactly
> the same query?
>
> to_sql is not suitable
>
> My task is to have reload a div that contains a list of records got from
> DB. It can be taken from DB via simple search, detailed search, via
> selecting a category, selecting an item in category, so I thought that the
> simplest way is to store serialized and encrypted query data inside a div,
> which can be used to refresh itself.
>
> Maybe there is an alternative way I don't know of?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Rails-core] UrlHelper: Extracting url_for to separate module

[richard schneeman]

Do you have a PR you could send over? I'm taking the silence here as either
a :+1: or people have no idea what you're talking about.

Cleaning up url_for is a pretty huge task. By putting it into a module are
you suggesting that a user would need to manually include it? I'm not sure
how one excludes a module if it has already been included.

A subclass should have no idea about how a superclass would consume its
methods, so the behavior you're describing should be fixed provided there's
not huge performance problems or massive backwards breakage.


On Sun, Dec 15, 2013 at 4:27 PM, Nick Sutterer  wrote:

> The UrlHelper#url_for method introduced in Rails 4 causes serious trouble
> for our gems Cells + Apotomo: #url_helper assumes that it is later
> overwritten by the real #url_for. While this works in standard setups, it
> fails when you have cells or widgets in engines.
>
> I find this assumption a bit dangerous and sketchy. In the long-term we
> should just have one #url_for method that does exactly what it is supposed
> to do and that doesn't assume it is overwritten at some later point.
>
> For now, I suggest we extract #url_for into a separate helper that can be
> explicitely excluded.
>
> module UrlForHelper
>>   def url_for
>> end
>>
>> module UrlHelper
>>   include UrlForHelper
>>
>>   def link_to
>>   ..
>> end
>>
>
> Does anyone see a problem with that?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Rails-core] X-Runtime header doesn't seem to be reliable

[richard schneeman]

This functionality does not come from Rails, but rather Rack::Runtime (
http://guides.rubyonrails.org/configuring.html#configuring-middleware) you
can see the middleware here:
https://github.com/rack/rack/blob/master/lib/rack/runtime.rb. It looks
pretty simple, i'm not sure if it is streaming aware.

For different latencies regarding assets, i'm guessing that chrome is
perhaps doing some caching? How much latency do you get when you hit that
CSS from a new incognito window?

>From my understanding rendering as a stream won't make the whole page load
faster, it will just send elements to the browser as soon as they are ready
so the HTTP request would still take just as long, but the end user sees
content sooner and the browser has more time to parse and fetch CSS/JS/etc.
Perhaps chrome is measuring the request time?


On Wed, Feb 19, 2014 at 8:42 AM, Rodrigo Rosenfeld Rosas  wrote:

> As far as I understand, Rails uses a middleware by default that will send
> the total time spent on a request in the Rails side in the X-Runtime HTTP
> header.
>
> But it doesn't seem to be reliable in the sense that when I perform a
> request against http://localhost:3000/ (development environment, tested
> with both Puma and Webrick), I get 10ms of latency when serving some CSS
> assets but 109ms of latency for the index page. When I look at the header
> for the same request, I get "X-Runtime: 0.034849".
>
> Here's how it reports the timing in the server logs:
>
> Completed 200 OK in 22ms (Views: 1.4ms | Sequel: 13.2ms)
>   Rendered search/_fields_finder.html.erb (0.0ms)
>   Rendered search/_left_pane.html.erb (0.7ms)
>   Rendered search/_index.html.erb (8.9ms)
>   Rendered transactions/_list.html.erb (0.0ms)
>   Rendered search/_saved_searches_dialogs.html.erb (0.2ms)
>   Rendered search/_saved.html.erb (0.5ms)
>   Rendered main/_change_log.html.erb (0.1ms)
>   Rendered main/_glossary.html.erb (0.0ms)
>   Rendered themes/default/_footer.html.erb (0.1ms)
>   Rendered main/index.html.erb within layouts/main (70.5ms)
>
> This happens because I'm using "render stream: true" in that action, but
> I'd expect the latency to be reduced when looking at the Chrome reported
> timing, but it doesn't matter if I render with "stream: true" or not, the
> latency reported by Chrome is always about 100ms.
>
> Am I missing something?
>
> Thanks in advance,
> Rodrigo.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Rails-core] X-Runtime header doesn't seem to be reliable

[richard schneeman]

I didn't know you could turn off caching in chrome. I'll have to take a
better look into their dev tools. Once you figure this out, it could make a
nice blog post on how to use front end + backend analytics to debug and
speed up performance problems.


On Wed, Feb 19, 2014 at 12:02 PM, Rodrigo Rosenfeld Rosas <
rr.ro...@gmail.com> wrote:

>  On 19-02-2014 13:44, richard schneeman wrote:
>
> This functionality does not come from Rails, but rather Rack::Runtime (
> http://guides.rubyonrails.org/configuring.html#configuring-middleware)
> you can see the middleware here:
> https://github.com/rack/rack/blob/master/lib/rack/runtime.rb. It looks
> pretty simple, i'm not sure if it is streaming aware.
>
>  For different latencies regarding assets, i'm guessing that chrome is
> perhaps doing some caching? How much latency do you get when you hit that
> CSS from a new incognito window?
>
>
> I don't need an incognito window to force skipping any caching, I just
> check "Disable cache (while DevTools is open)". I did that and I can see
> from the Network pane that the response status was 200, and it took 16ms of
> latency + 30ms of "Receiving" time for a JS asset.
>
> What I mean is that most probably the web server (Puma, Webrick) is not
> the cause for such a big latency... So maybe there's something more
> happening that is not registered by that middleware and I'd like to know if
> there's anyway I could understand what else it could be and if I'm able to
> optimize it...
>
> Just in case you're curious, I tested it in an incognito window and the
> result is the same as disabling cache.
>
>
>   From my understanding rendering as a stream won't make the whole page
> load faster, it will just send elements to the browser as soon as they are
> ready so the HTTP request would still take just as long, but the end user
> sees content sooner and the browser has more time to parse and fetch
> CSS/JS/etc. Perhaps chrome is measuring the request time?
>
>
> I understand that and that's exactly my intention. I want Chrome to
> download the assets while the page is loading but I see that it won't
> download them until the page finishes loading, which makes sense since I
> get about 3ms of "Receiving" time. What I mean is that rendering with
> "stream: true" is not helping at all and it makes no difference if I use
> normal rendering (except for this bug I reported yesterday:
> https://github.com/rails/rails/issues/14093)
>
> Chrome reports me all timings separately: "Blocking", "Sending", "Waiting"
> and "Receiving". The waiting part is taking 99% of the total time. Do you
> get different results?
>
> I have even included this in one of my partials:
>
>   <% sleep 1 -%>
>
> Guess what: "Waiting: 1.1s"
>
> So, I guess the problem is that streaming doesn't seem to be working
> actually.
>
> Now that I figured this out, I'll try to reproduce in a separate
> application and if I can, I'll report another bug for template streaming
> rendering.
>
> Thank you for helping, Richard.
>
> Cheers,
> Rodrigo.
>
>
>
>
> On Wed, Feb 19, 2014 at 8:42 AM, Rodrigo Rosenfeld Rosas <
> rr.ro...@gmail.com> wrote:
>
>> As far as I understand, Rails uses a middleware by default that will send
>> the total time spent on a request in the Rails side in the X-Runtime HTTP
>> header.
>>
>> But it doesn't seem to be reliable in the sense that when I perform a
>> request against http://localhost:3000/ (development environment, tested
>> with both Puma and Webrick), I get 10ms of latency when serving some CSS
>> assets but 109ms of latency for the index page. When I look at the header
>> for the same request, I get "X-Runtime: 0.034849".
>>
>> Here's how it reports the timing in the server logs:
>>
>> Completed 200 OK in 22ms (Views: 1.4ms | Sequel: 13.2ms)
>>   Rendered search/_fields_finder.html.erb (0.0ms)
>>   Rendered search/_left_pane.html.erb (0.7ms)
>>   Rendered search/_index.html.erb (8.9ms)
>>   Rendered transactions/_list.html.erb (0.0ms)
>>   Rendered search/_saved_searches_dialogs.html.erb (0.2ms)
>>   Rendered search/_saved.html.erb (0.5ms)
>>   Rendered main/_change_log.html.erb (0.1ms)
>>   Rendered main/_glossary.html.erb (0.0ms)
>>   Rendered themes/default/_footer.html.erb (0.1ms)
>>   Rendered main/index.html.erb within layouts/main (70.5ms)
>>
>> This happens because I'm using "render stream: true" in that action, but
>> I'd expect the latency t

Re: [Rails-core] Proposal: Dynamic secret_tokens

[richard schneeman]

I would rather have the system accept multiple tokens at one time so you can 
rotate them on a production server. This is easily something you could set up 
via cron and if an attacker gets a token it would only be valid for hours 
instead of days/months.


Heroku would love to rotate your tokens for you but right now we can't. When 
you serve a page and then change a token then any forms that page submits will 
be invalid to the next server with the new token.

—
Richard Schneeman

On Sat, Mar 29, 2014 at 8:24 AM, Bert Goethals 
wrote:

> Valid point. However, security is never a 100%. 
> I do think that N secret tokens is a "safer" situation than just one. 
> Also note, that any future tenants would be safe from "remembering" the base 
> token. 
> I'll give this a shot this weekend. 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] smart eager loading and caching

[richard schneeman]

There's a ton of magic in active record as is. If you have ideas on a big 
change like the one you are suggesting, you should fork active record and get 
it working to get feedback. After that it's worth discussing.


If you really want to help here, take a look at open issues tagged with active 
record and see if you can solve them. AR has the most issues open by far.






—
Richard Schneeman

On Sat, May 17, 2014 at 6:38 PM, Lawrence Wu 
wrote:

> I'd like to deprecate methods like includes and eager_load in Rails since I 
> think it is possible to automatically detect when they are needed. Ideally 
> the developer could know very little about how databases work and still get 
> very efficient queries using just the ORM. What do other people think?
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] Feature Request: Remove or replace *_path helpers for mailers

[richard schneeman]

 Here's a change in behavior I would love on the mailers.

## Backstory

When you send an email, you'll likely need links. Those links must be the
full path i.e. 'http://example.com/foo' instead of relative (just '/foo').
Unfortunately most devs are so used to using the *_path helpers, they use
them in emails by mistake.

I made this mistake recently with http://www.codetriage.com, here's the PR
that fixes it (https://github.com/codetriage/codetriage/pull/257). The sad
part is I didn't realize there was a problem until a user got an email and
couldn't click on a link. Then they had to be nice enough to report it. If
your business is running on Rails, this may take days. I've been doing this
for years, and it still happens to me.


## Feature

Here's what I would like to see happen. Either raise an exception when
*_path helpers are used in a mail template so my tests would have caught
it, or likely just have *_path helpers resolve to the full URL by default.
What do you think?


--
Richard Schneeman

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Feature Request: Remove or replace *_path helpers for mailers

[richard schneeman]

Are there any valid uses for *_path in an email? Can you do reference links
with ID elements in an email? We could make it configurable. Default it to
non-hair-pulling behavior, but allow anyone with a legitimate `*_path` use
to preserve functionality.

```
config.action_mailer.path_helper_behavior = :raise
config.action_mailer.path_helper_behavior = :url
config.action_mailer.path_helper_behavior = :make_me_lose_users_or_money #
i.e. current behavior
```

--
Richard Schneeman


On Thu, Jun 12, 2014 at 2:31 PM, Xavier Noria  wrote:

> On Thu, Jun 12, 2014 at 8:07 PM, Florian Thomas 
> wrote:
>
> I’m in support of this as well.
>> As a solution i would prefer to resolve the full URL by default. Raising
>> an exception seems to me a bit like rails telling the programmer „I know
>> what you’re intending, and we both know the solution but you have to fix it
>> on your own."
>>
>
> Breaking the strong expectation that *_path generates a path is dubious to
> me. Too clever, the API is kind of cheating in my mind.
>
> I've been thinking about it and my only conclusion by now is that we agree
> there's something to do here, but see cons in all proposals so far :).
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Feature Request: Remove or replace *_path helpers for mailers

[richard schneeman]

Nope it wouldn't. Rendering the emails don't currently raise errors, so
your tests will still pass. The only way to find out is to actually get the
email and click on it. Even if you look at it in mail_view you get the
right URL generated as the relative path will work.

Right now it's all just :(


On Tue, Jun 17, 2014 at 6:30 PM, Andrew Kaspick  wrote:

> Slight aside, but wouldn't a simple test case catch such an issue?
> Whether that be an actual mailer test or reviewing a generated email?
>  On Jun 17, 2014 6:14 PM, "richard schneeman" 
> wrote:
>
>> Are there any valid uses for *_path in an email? Can you do reference
>> links with ID elements in an email? We could make it configurable. Default
>> it to non-hair-pulling behavior, but allow anyone with a legitimate
>> `*_path` use to preserve functionality.
>>
>> ```
>> config.action_mailer.path_helper_behavior = :raise
>> config.action_mailer.path_helper_behavior = :url
>> config.action_mailer.path_helper_behavior = :make_me_lose_users_or_money
>> # i.e. current behavior
>> ```
>>
>> --
>> Richard Schneeman
>>
>>
>> On Thu, Jun 12, 2014 at 2:31 PM, Xavier Noria  wrote:
>>
>>> On Thu, Jun 12, 2014 at 8:07 PM, Florian Thomas 
>>> wrote:
>>>
>>> I’m in support of this as well.
>>>> As a solution i would prefer to resolve the full URL by default.
>>>> Raising an exception seems to me a bit like rails telling the programmer „I
>>>> know what you’re intending, and we both know the solution but you have to
>>>> fix it on your own."
>>>>
>>>
>>> Breaking the strong expectation that *_path generates a path is dubious
>>> to me. Too clever, the API is kind of cheating in my mind.
>>>
>>> I've been thinking about it and my only conclusion by now is that we
>>> agree there's something to do here, but see cons in all proposals so far :).
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Ruby on Rails: Core" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to rubyonrails-core+unsubscr...@googlegroups.com.
>>> To post to this group, send email to rubyonrails-core@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to rubyonrails-core+unsubscr...@googlegroups.com.
>> To post to this group, send email to rubyonrails-core@googlegroups.com.
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Feature Request: Remove or replace *_path helpers for mailers

[richard schneeman]

If we go down this route, the error message should be crystal clear:

"The method `user_path` cannot be used in a mailer as relative links in
emails do not work. Use `user_url` instead"

Also need to make sure that it raises when rendered with mail_view.


On Wed, Jun 18, 2014 at 4:11 AM, Adam Piotrowski 
wrote:

> Nice idea in my opinion.
>
>
> 2014-06-18 11:08 GMT+02:00 Prem Sichanugrist :
>
> I like that. Let's deprecate *_path in Mailer in 4.2 and remove in 5.0
>>
>> -Prem
>>
>> On Jun 18, 2014, at 3:33 AM, Xavier Noria  wrote:
>>
>> I cannot think of a valid use case for *_path in mailer views, so after
>> thinking about it I personally would be inclined to remove them.
>>
>> People cannot upgrade and have their mailers crashing in production, so I
>> think we have no option but to go through a deprecation cycle.
>>
>> If someone had a rare need to generate a path and the helpers were gone,
>> they could still opt-in via *_url(only_path: true), which is something
>> we could document in small font :).
>>
>> The mailer guide would need to reflect these changes.
>>
>> What do you think?
>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to rubyonrails-core+unsubscr...@googlegroups.com.
>> To post to this group, send email to rubyonrails-core@googlegroups.com.
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to rubyonrails-core+unsubscr...@googlegroups.com.
>> To post to this group, send email to rubyonrails-core@googlegroups.com.
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Feature Request: Remove or replace *_path helpers for mailers

[richard schneeman]

Here's the working PR for those interested in following along:
https://github.com/rails/rails/pull/15840


On Wed, Jun 18, 2014 at 1:40 PM, Xavier Noria  wrote:

> I have never checked it myself (could be cargo culting), but my
> understanding has always been that using the BASE tag is not a good
> practice for portable HTML emails. See for example:
>
> http://stackoverflow.com/questions/14611225/html-base-tag-in-email
>
> I personally believe preventing *_path calls that are plain wrong and a
> common gotcha outweights supporting this edge-case that can still be
> accomplished with only_path: true.
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Feature Request: Remove or replace *_path helpers for mailers

[richard schneeman]

Thanks for the review and thanks to Sean, he did most of the driving on the
initial pair. Happy to have this in :D

--
Richard Schneeman
@schneems <https://twitter.com/schneems>



On Wed, Jul 30, 2014 at 5:27 PM, Xavier Noria  wrote:

> Merged. Thanks a lot Richard! <3
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Multiple Asset Hosts

[richard schneeman]

*## On Perf Changes*

Any performance improvements that have wide implications such as this, need
to be benchmarked before they could be merged.

It's not enough to do the research, we would need actual experimental proof
that it works, provides a significant speed boost to justify the extra code
costs and doesn't have any major downsides.

If you add a new feature, it has to be tested. If you do a perf change, it
needs to be benchmarked. It's not good enough to shoot in the dark

*## On multiple asset hosts*

You can do this today. Rails accepts a proc for the asset_host that you can
use to randomize an asset host however...

I looked into this extensively in the last 6 months and the general
consensus is that it doesn't help much, and even then it can make
performance slower. Most connections are fast these days, but the overhead
in making new connections is still there. Basically the browser doesn't
know that www.domain and www1.domain are the same and must connect
separately. The result can be a slower page render.

Go ask igrigorik, he knows this stuff backwards and forwards (browser
behavior and speed). Here's two good articles

https://insouciant.org/tech/network-congestion-and-web-browsing/
http://perf.fail/post/96104709544/zealous-sharding-hurts-etsy-performance


*## However*

If you feel strongly, go test it. Build up repeatable benchmarks and
instructions for others to run them. Don't take my word on this, test it.



On Fri, Oct 31, 2014 at 10:33 AM, Sebastian Korfmann <
korfmann.sebast...@gmail.com> wrote:

> Hey there,
>
> I've been wondering if the assumption of four asset hosts for the sake of
> speed improvements is still valid.
>
> Rails documentation about asset hosts:
>
> Browsers typically open at most two simultaneous connections to a single
>> host, which means your assets often have to wait for other assets to finish
>> downloading. You can alleviate this by using a %d wildcard in the
>> asset_host. For example, “assets%d.example.com”. If that wildcard is
>> present Rails distributes asset requests among the corresponding four hosts
>> “assets0.example.com”, …, “assets3.example.com”. With this trick
>> browsers will open eight simultaneous connections rather than two
>
>
> According to this (http://www.browserscope.org/?category=network),
> browsers are supporting typically 6 - 8 simultaneous connections per host
> nowadays. However, there's an average max connection limit of 2 times of
> that.
>
> Would it make sense to adjust the behaviour to generate only two asset
> hosts by default?
>
> Cheers,
>
> Sebastian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Make assets precompilation unnecessary

[richard schneeman]

> pushed to a CDN which the apps use for an asset host

I recommend not doing this. You can set up your CDN to "pull" instead which
is much more sane and less error prone:
https://devcenter.heroku.com/articles/using-amazon-cloudfront-cdn. Source:
hundreds of Heroku support tickets.

>  assets precompilation is really boring, slow and even complicated

Agreed, however your solution only moves the slow, complicated, boringness
to the realm of your users; it doesn't get rid of them. Now instead of you
having to wait for your assets to precompile before an app is deployed,
your users have to wait for assets to be compiled the first time they hit a
page. If you think 30 seconds is a long time to wait for compilation on
push, how do you think a user will feel about a 30 second long request to
your homepage?

On Mon, Nov 24, 2014 at 7:27 AM, Ken Collins  wrote:

> And another reason for pre-compilation is that it can happen on district
> asset host boxes or even be pushed to a CDN which the apps use for an asset
> host.
>
>  - Ken
>
>
> On November 24, 2014 at 10:09:54 AM, James Coleman (jtc...@gmail.com)
> wrote:
>
> The reason for asset precompilation in production environments isn't just
> caching and speed on the first request, it's also that you don't want to
> have to have a JS environment (e.g. TheRubyRacer) in production.
>
> 2014-11-23 18:32 GMT-05:00 Bráulio Bhavamitra :
>
>>  Hello all,
>>
>> For me, assets precompilation is really boring, slow and even complicated
>> as additional configuration is necessary.
>>
>> That is why I've made a live asset compilation so that on the first
>> request the assets get compiled and put on the static asset path
>> (public/assets), just like rake assets:precompile do, so that on the next
>> request it is going to be served by Nginx.
>>
>> Please comment on the idea. GEM source code at
>> https://github.com/coletivoEITA/assets_live_compile
>>
>> cheers,
>>
>> bráulio
>>
>>
>>  --
>>  "Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
>> ideologia. Morra por sua ideologia" P.R. Sarkar
>>
>> EITA - Educação, Informação e Tecnologias para Autogestão
>> http://cirandas.net/brauliobo
>> http://eita.org.br
>>
>> "Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu
>> lar e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
>> Mente Macrocósmica, e todas as entidades estão sendo criadas, preservadas e
>> destruídas nas fases de extroversão e introversão do fluxo imaginativo
>> cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
>> naquele momento, essa pessoa é a única proprietária daquilo que ela
>> imagina, e ninguém mais. Quando um ser humano criado mentalmente caminha
>> por um milharal também imaginado, a pessoa imaginada não é a propriedade
>> desse milharal, pois ele pertence ao indivíduo que o está imaginando. Este
>> universo foi criado na imaginação de Brahma, a Entidade Suprema, por isso
>> a propriedade deste universo é de Brahma, e não dos microcosmos que também
>> foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
>> mutável ou imutável, pertence a um indivíduo em particular; tudo é o
>> patrimônio comum de todos."
>> Restante do texto em
>> http://cirandas.net/brauliobo/blog/a-problematica-de-hoje-em-dia
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to rubyonrails-core+unsubscr...@googlegroups.com.
>> To post to this group, send email to rubyonrails-core@googlegroups.com.
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.

Re: [Rails-core] Make assets precompilation unnecessary

[richard schneeman]

> Serving in milliseconds

This is because sprockets doesn't generate hashes, remove whitespace,
compress javascript, or compile all JS to one file.

If you don't need any of those things then don't use the asset pipeline,
store your assets in `/public` and serve them individually.

> Likely because you do not have an asset/sprockets cache configured.
> http://blog.alexmaccaw.com/faster-deploys

If you are deploying to Heroku

DO NOT USE http://blog.alexmaccaw.com/faster-deploys on Rails 3
DO NOT USE http://blog.alexmaccaw.com/faster-deploys on Rails 3
DO NOT USE http://blog.alexmaccaw.com/faster-deploys on Rails 3
DO NOT USE http://blog.alexmaccaw.com/faster-deploys on Rails 3
DO NOT USE http://blog.alexmaccaw.com/faster-deploys on Rails 3

For the love of god and all that is holy. It will break your application,
maybe not today, maybe not tomorrow, but eventually. If you missed it:

DO NOT USE http://blog.alexmaccaw.com/faster-deploys on Rails 3

This is because Rails 3 has issues with caching and elements __may__ not be
cleared properly. If you're deploying Rails 4 assets on Heroku we cache
these for you and the double caching actually SLOWS down your application.



2014-11-24 11:04 GMT-06:00 Bráulio Bhavamitra :

> Hello Ken,
>
> This is not good enough as the rails server is going to be reached for
> each asset request. You want nginx or another server to serve assets.
>
> cheers,
> bráulio
>
> On Mon, Nov 24, 2014 at 2:00 PM, Ken Collins 
> wrote:
>
>>
>> Likely because you do not have an asset/sprockets cache configured.
>> http://blog.alexmaccaw.com/faster-deploys
>>
>> On November 24, 2014 at 11:58:40 AM, Jonathan Lozinski (
>> jonathan.lozin...@gmail.com) wrote:
>>
>> It's interesting that you mention that. In development mode (with debug
>> assets off) the consolidated assets build and serve in milliseconds. I'm
>> still unsure as to why the asset pre-compile takes so long.
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to rubyonrails-core+unsubscr...@googlegroups.com.
>> To post to this group, send email to rubyonrails-core@googlegroups.com.
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> "Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
> ideologia. Morra por sua ideologia" P.R. Sarkar
>
> EITA - Educação, Informação e Tecnologias para Autogestão
> http://cirandas.net/brauliobo
> http://eita.org.br
>
> "Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu
> lar e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
> Mente Macrocósmica, e todas as entidades estão sendo criadas, preservadas e
> destruídas nas fases de extroversão e introversão do fluxo imaginativo
> cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
> naquele momento, essa pessoa é a única proprietária daquilo que ela
> imagina, e ninguém mais. Quando um ser humano criado mentalmente caminha
> por um milharal também imaginado, a pessoa imaginada não é a propriedade
> desse milharal, pois ele pertence ao indivíduo que o está imaginando. Este
> universo foi criado na imaginação de Brahma, a Entidade Suprema, por isso
> a propriedade deste universo é de Brahma, e não dos microcosmos que também
> foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
> mutável ou imutável, pertence a um indivíduo em particular; tudo é o
> patrimônio comum de todos."
> Restante do texto em
> http://cirandas.net/brauliobo/blog/a-problematica-de-hoje-em-dia
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Changing welcome#index page in the new Rails applications

[richard schneeman]

:+1: I can dig it.

How about adding a link to the routing page while we're at it.

--
Richard Schneeman

On Wed, Nov 26, 2014 at 9:04 PM, Ryan Bigg  wrote:

> Looks good to me. I would hide the box on the right by default. Please
> submit a PR for it :)
>
>
>
> On Thu, Nov 27, 2014 at 2:03 PM, Islam Wazery  wrote:
>
>>  I am proposing to change the style of the index page
>> <https://github.com/rails/rails/blob/08754f12e65a9ec79633a605e986d0f1ffa4b251/railties/lib/rails/templates/rails/welcome/index.html.erb>
>> of the newly created Rails applications to something like this:
>>
>>
>> <https://dl.dropboxusercontent.com/u/71605080/Screen%20Shot%202014-11-26%20at%207.13.10%20PM%20copy.png>
>> Is that suitable, so I can issue a PR with it or no?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to rubyonrails-core+unsubscr...@googlegroups.com.
>> To post to this group, send email to rubyonrails-core@googlegroups.com.
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] .html_safe is ambiguous and should be renamed

[richard schneeman]

Two things.




1) Re-naming is an inherently bikeshed-ing prone task.

2) Use data to make better arguments.




Are there stack overflow posts, or blog posts, or any kinds of numbers where we 
can point to people actually mis-using this? I agree that the name is 
ambiguous, however i'm pretty sure i've never seen a student mis-use it.




Deprecations aren't taken lightly as even if it is "a simple find and replace" 
it adds a barrier to upgrading that all add up. Not saying we should never 
deprecate, but we should be careful we're deprecating things that have high 
impact/value. Numbers can help. 




Also not saying that these problems don't exist if we can't find evidence of 
them, merely that they might not be as impactful.


---Richard Schneeman


http://www.schneems.com

On Wed, Feb 4, 2015 at 6:06 PM, Pedro Nascimento 
wrote:

> Rails is supposed to be developer-friendly AFAICT, so if the name is indeed
> misleading and makes people assume this feature is meant for something
> else, we should probably rename it specially given there's a major version
> being worked on.
> On Wed, Feb 4, 2015 at 4:08 PM, Nicolas Cavigneaux  wrote:
>>
>> Le 4 févr. 2015 à 12:00, Magne  a écrit :
>>
>> > I ran into a situation with .html_safe when communicating with a fellow
>> programmer, and discovered that the method name isn't as clear as desired.
>> >
>> > .html_safe does not mean "please make this html safe", it's the opposite
>> - it is you the programmer telling rails that "this string is html safe,
>> promise!"
>> >
>> > This can be confused by programmers, and hence be a potential security
>> risk. A programmer should be able to read the name of a method and
>> unambiguously be able to predict what it does, precisely.
>>
>> Every Rails developer, even beginners should be aware of #html_safe and
>> how it works since Rails escapes all strings by default. If the developer
>> wants to use #html_safe then there are two possibility:
>>
>> - he do wants to mark the string as safe so he searched how to do it and
>> found #html_safe. Everything is OK.
>> - he saw #html_safe somewhere, didn’t even try to see if strings are
>> already escaped or not, didn’t even read the API doc for #html_safe. He was
>> just like « Ok I’m going to put this everywhere to secure my code ! »
>>
>> This second developer is dumb… Sorry. It means he didn’t even read any doc
>> or the Rails guide. Don’t let him touch your code until he knows some basis!
>>
>> I think even a beginner should be aware that Rails escapes strings for
>> you. If he isn’t aware of that he needs some training or at least to have
>> some read.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to rubyonrails-core+unsubscr...@googlegroups.com.
>> To post to this group, send email to rubyonrails-core@googlegroups.com.
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Add Access-Control support to ActionDispatch::Static

[richard schneeman]

I'm pro letting people configure arbitrary headers for serving assets. I think 
we should bake support for this in Rails.




On a side note I really dislike asset_sync


https://gist.github.com/schneems/9374188  




—
Sent from Mailbox

On Sun, Feb 22, 2015 at 7:31 PM, Yuki Nishijima 
wrote:

> Hi,
> Has anyone thought about adding Access-Control headers for assets? Right
> now, I use asset_sync gem to send all assets to an S3 bucket after
> asset:precompile and use CloudFront to serve them, where the 3S bucket has
> Access-Control settings.
> But if ActionDispatch::Static automatically (or with a proper config) puts
> the Access-Control headers for us, then there is no need to set it up and
> we can just change CloudFront to point directly to the Rails app.
> Let me know what you think. Thanks for your time!
> Thanks,
> Yuki
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Re: Forking and CoW are killing my machine when running GC

[richard schneeman]

As mohamed mentioned, this forum isn't for general debugging but rather for 
people talking about developing the core of Rails. It's not an appropriate 
place for bug reports. If you think you found a bug in the way Ruby uses fork, 
I would try to reproduce it with a minimal ruby script and without rails.





The behavior you're describing is unusual, and i've not seen it before. If 
before you fork and your app uses 100mb of ram, then after you fork it should 
use more ram but still be less than double, something probably around 180 or 
150mb of ram total. If you're seeing double the ram, its likely that your 
application code is doing something to modify or create many objects. I would 
recommend looking into allocation_tracer gem or memory_profiler gem to see 
where new objects are being created after you fork, maybe derailed_benchmarks 
however that isn't set up to run with a forking server.




Hope that helps, please re-post to another list, you can let us know the link 
after you do so we can followup if anyone is interested.


---Richard Schneeman


http://www.schneems.com

On Thu, Apr 30, 2015 at 10:37 AM, Thomas Kalmus 
wrote:

> Small update. I have played with the GC and have run several tests. I 
> manage to solve the problem by disabling the GC with GC.disable, but then 
> my memory gets filled with garbages. I have also disabled hugepages on 
> linux and no effects. Finally I've played with some of the parameters of 
> the GC like the heap size, and reducing its activity to 0 (GC.count) but no 
> changes. Every test have been performed on the same machine with the same 
> parameters.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Would "rails generate config" be a useful feature?

[richard schneeman]

I'm :-1: on all file based YML config. :+1: on env based config.


Either way, I would suggest writing it up as a gem to get some real world 
feedback.


---Richard Schneeman


http://www.schneems.com

On Tue, May 5, 2015 at 1:00 PM, Kyle Rippey  wrote:

> I was considering creating a pull request to add this functionality, but 
> just wanted to get some thoughts on the idea first.
> Basically, since Rails 4 added the handy config_for() functionality to 
> support loading custom yml files from the config directory, I thought it 
> would be nice if we had a generator to compliment it.
> Here's an example:
> "rails config facebook app_id app_secret" will create config/facebook.yml 
> (if it doesn't already exist) with the keys stubbed out for each 
> environment:
> development:
>   app_id: <%= ENV["FACEBOOK_APP_ID"] %>
>   app_secret: <%= ENV["FACEBOOK_APP_SECRET"] %>
> test:
>   app_id: <%= ENV["FACEBOOK_APP_ID"] %>
>   app_secret: <%= ENV["FACEBOOK_APP_SECRET"] %>
> # Do not keep production secrets in the repository,
> # instead read values from the environment.
> production:
>   app_id: <%= ENV["FACEBOOK_APP_ID"] %>
>   app_secret: <%= ENV["FACEBOOK_APP_SECRET"] %>
> I think this could be handy, but also help reinforce the idea that secret 
> values should not be stored in a repository.
> Thoughts?
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Migration::CheckPending does not respect Rails.application.paths['db/migrate']

[richard schneeman]

I wrote that code. Can you give me a PR with tests? Mention @schneems



—
Sent from Mailbox

On Sun, May 24, 2015 at 2:09 PM, Sam Pierson 
wrote:

> I have discovered that unlike the other parts of the migrations system, the 
> Migration::CheckPending Rack module does not respect 
> `Rails.application.paths['db/migrate']`.
> All the rake-driven migrations code benefits from: 
> active_record/railties/databases.rake#L6 
> 
> ActiveRecord::Migrator.migrations_paths = ActiveRecord::Tasks::DatabaseTasks
> .migrations_paths
> DatabaseTasks.migration_paths returns the value of 
> Rails.application.paths['db/migrate'].
> However Migration::CheckPending does not benefit from this.
> I've been experimenting with ways to fix it, for example this works:
> class CheckPending
>   def initialize(app)
> ...
> if defined? Rails
>   ActiveRecord::Migrator.migrations_paths = Rails.application.paths[
> 'db/migrate'].to_a 
> end
>   end
> Does this look like a viable solution?
> Is it something that might ever get merged in?
> This is a somewhat unusual situation.  I'm doing some experiments on 
> engines/apps, attempting to change their relationships to each other, and 
> discovered this when I moved the migrations folder.
> Should I spin up a PR?
> Thanks for your consideration,
> -Sam.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Error pages are really just static assets. Why not make them part of the asset pipeline?

[richard schneeman]

I think it means people don't feel strongly about it one way or the other. It's 
good because no one hates the idea.




I personally would love to have fully dynamic error pages that could use my 
`_header.html.erb` and `_footer.html.erb` so when I make a change to one I 
don't have to copy it over to the error page, the problem is if you have an 
error in your error page then everything breaks.




To help mitigate this I wanted to introduce the concepts of multiple error 
fallback pages, but it went nowhere https://github.com/rails/rails/pull/8425 I 
closed it due to lack of interest.




Some changes are better debated as a PR. It sounds like this one might depend 
heavily on the implementation. Go ahead and give it a shot. Even if it isn't 
merged, you'll learn plenty about Rails internals :)


---Richard Schneeman


http://www.schneems.com

On Fri, Jul 31, 2015 at 9:05 AM, null  wrote:

> https://github.com/rails/sprockets-rails/issues/49 (which is locked so no 
> further discussion is possible there) debates whether asset precompile 
> should create a non-digest version of the assets.
> There are a few valid use cases for this, and I do not have solutions for 
> all of them, but I just thought of a solution to one--static error pages.
> @pelargir, in some of the first comments on the issue 
> (https://github.com/rails/sprockets-rails/issues/49#issuecomment-20529994, 
> https://github.com/rails/sprockets-rails/issues/49#issuecomment-20531267), 
> stated the issue:
>> Removing generation of non-digest files also makes is impossible to have 
> static 404 error pages that use the same images, JS, and CSS as the 
> remainder of the site (without making duplicate non-digest copies of those 
> files in /public). But then I end up with two copies of the same file in my 
> app.
>> Am I supposed to copy the precompiled file into /public and remove the 
> fingerprint from the filename? So then, if I change the file in the future, 
> I have to precompile, copy, and rename all over again?
> My idea is to make the static error pages part of the asset pipeline. 
>  Instead of generating public/500.html, public/404.html, etc, a new rails 
> app should generate app/assets/html/500.en.html.erb, 
> app/assets/html/404.en.html.erb, 
> etc.  "app/assets/html/*"  should by default be included in 
> config.assets.precompile (which I believe it is anyway since it's in 
> app/assets and the extension is neither .css or .js).
> There are 2 places where the behavior would be significantly different than 
> of all other assets, so things would get a little tricky here:
> 1) Unlike other assets, these would need to be precompiled in the context 
> of a layout.  This could be either the same application layout as the rest 
> of the application (app/views/layouts/application.html.erb ), or the "rails 
> new" generator could create a separate 
> app/assets/html/error_layout.en.html.erb (which itself should be excluded 
> from precompiled).  Telling sprockets when to compile in the context of a 
> layout could be tricky, but an alternative is just to code that into the 
> view.  Below is an example from an existing project of mine.  It's in HAML, 
> not ERB, but still illustrates the point:
> # app/assets/html/500.en.html
> - layout = Rails.root.join("app", "assets", "html", 
> "error_layout.en.haml")
> = Haml::Engine.new(File.read layout).render do
>   %h5 We're sorry, but something went wrong.
>   %p Our developers are working on it.
> 2) Error pages currently live in public, but with this approach, they would 
> end up in public/assets, and would have digests in their file names.  So we 
> would need to change 
> https://github.com/rails/rails/blob/v4.2.3/actionpack/lib/action_dispatch/middleware/public_exceptions.rb#L44
>  
> to look in "public/assets" and use the appropriate digests, and add a 
> Depracation warning (that shows up in development environment) if the error 
> pages are found in "public".
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Integrate Parse Cloud with Rails 4 App

[richard schneeman]

Try posting to https://groups.google.com/forum/#!forum/rubyonrails-talk or to 
stack overflow. This list is for developers who are working on building the 
rails library, not for developers who are building things with rails. 





---Richard Schneeman


http://www.schneems.com

On Sun, Aug 9, 2015 at 10:45 AM, Mansi Shah  wrote:

> Hello,
> I am working as Rails developer since last one year. I am new to Parse 
> Cloud.
> I want to implement Parse cloud by using its REST API through "
> *parse-ruby-client*" gem.
> I have tried to implement with Rails App, but I am not having working app 
> as simple Rails app, as there is no Model Ruby file is created & my code is 
> also increased.
> I have tried "parse-resource" and "parseModel" gems, which works same as "
> *ActiveRecord*" of Rails, but not able to implement it.
> Can you please suggest me that should I use Parse as BaaS with Rails 4 app 
> or any other good alternative?
> If I use Parse, I am not able to use many of the useful gems of Rails which 
> relay on Model.rb file.
> I also found many of the things in Parse for Ruby is in development, also 
> not able to find proper tutorial for ROR with Parse.
> Please give your suggestions.
> Thank you.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] String Allocation and Memory Bloat in ActiveRecord Objects

[richard schneeman]

I appreciate people pointing out slow spots. I'm not the most quallified to 
speak about AR but I'll try to help with the proposed patch. You can get a bit 
more speed by taking out the hash lookup:



```ruby

require 'benchmark/ips'




var = "world".freeze

hash = { var => "hello #{var}".freeze}




Benchmark.ips do |x|

  x.report("hash    ") { hash[var] }

  x.report("compare ") { var == "world".freeze ? "hello world".freeze : "hello 
#{var}" }

  x.report("static  ") { "hello world".freeze }

  x.report("none    ") { "hello #{var}" }

end

```




Gives you:







```

Calculating -

            hash        90.986k i/100ms

            compare     98.282k i/100ms

            static     103.704k i/100ms

            none        90.593k i/100ms

-

            hash          4.567M (±19.0%) i/s -     22.201M

            compare       5.441M (±13.7%) i/s -     26.831M

            static        7.160M (±22.9%) i/s -     34.222M

            none          3.215M (±14.8%) i/s -     15.763M

```




The hash also introduces the possibility of a memory leak, if there's only two 
values that ever hit that method, we're fine, but at that rate we could  
optimize those two string paths since it would be faster. If somehow arbitrary 
data from a user supplied `params` gets in there, then the hash could quickly 
take up memory until your app crashes. It might not happen today, but maybe in 
the future new functionality gets added that exposes this method to a public 
API and then we're toast. 




Thanks for the benchmarking and for the patch. If you make a PR to 
github.com/rails/rails we can talk about it more, ping me @schneems. We can 
also have someone with more AR experience take a look. 














---Richard Schneeman


http://www.schneems.com

On Sun, Aug 23, 2015 at 9:39 AM, null  wrote:

> Hello,
> I've been trying to track-down a pretty significant memory bloat issue with 
> ActiveRecord objects. Running some generic experiments e.g. an empty model 
> with 6 enum_fields, created_at, updated_at - and fetching 72000 of these 
> with ActiveRecord from a Postgres Database allocates approximately 120mb of 
> memory or (1747 bytes per object) - measured using Instruments.On the other 
> hand fetching the same 72000 objects into a list of hashes directly with 
> Ruby-PG is only about 10mb of memory.
> One particular thing I found which was surprising is that enum is not any 
> more efficient than string. This appears to be because the Postgresql 
> Adapter for ActiveRecord uses TypeMapAllString on the RubyPG level and than 
> performs all of the TypeMapping in Ruby. 
> <https://github.com/rails/rails/blob/master/activerecord%2Flib%2Factive_record%2Fconnection_adapters%2Fpostgresql%2Fdatabase_statements.rb#L168>
>   
> <https://github.com/rails/rails/blob/master/activerecord%2Flib%2Factive_record%2Fconnection_adapters%2Fpostgresql%2Fdatabase_statements.rb#L168>This
>  
> seems to be grossly inefficient since Ruby-PG has support for both basic 
> and custom type-mapping on the C-level.Here is some notable output from the 
> memory_profiler gem - this is for *only* 729 objects.
> 1617  "0"
> 1458  /Users/user_name/.rvm/gems/ruby-2.2.2/gems/activerecord-4.2.3/lib/
> active_record/connection_adapters/postgresql/database_statements.rb:169
> 159  /Users/user_name/.rvm/gems/ruby-2.2.2/gems/activerecord-4.2.3/lib/
> active_record/connection_adapters/postgresql/oid/type_map_initializer.rb:
> 161459  "2"
> 1459  /Users/user_name/.rvm/gems/ruby-2.2.2/gems/activerecord-4.2.3/lib/
> active_record/connection_adapters/postgresql/database_statements.rb:1691459 
>  "1"
> 1459  /Users/user_name/.rvm/gems/ruby-2.2.2/gems/activerecord-4.2.3/lib/
> active_record/connection_adapters/postgresql/database_statements.rb:169729  
> "_initialize_callbacks"
> 729  /Users/user_name/.rvm/gems/ruby-2.2.2/gems/activesupport-4.2.3/lib/
> active_support/callbacks.rb:81729  "_find_callbacks"
> 729  /Users/user_name/.rvm/gems/ruby-2.2.2/gems/activesupport-4.2.3/lib/
> active_support/callbacks.rb:81729  "initialize"
> 729  /Users/user_name/.rvm/gems/ruby-2.2.2/gems/activesupport-4.2.3/lib/
> active_support/callbacks.rb:81729  "find"
> 729  /Users/user_name/.rvm/gems/ruby-2.2.2/gems/activesupport-4.2.3/lib/
> active_support/callbacks.rb:81505  "\n"
> 262  /Users/user_name/.rvm/gems/ruby-2.2.2/gems/activerecord-4.2.3/lib/
> active_record/relation.rb:17
> 87  /Users/user_name/.rvm/gems/ruby-2.2.2/gems/activerecord-4.2.3/lib/
> active_record/relation/delegation.rb:15
> 42  /Users/user_nam

Re: [Rails-core] Feature suggestion: Use symbols internally with HashWithIndifferentAccess

[richard schneeman]

In 2.2 the speed of symbols and strings are much closer:




```


require 'benchmark/ips'




hash = {}




Benchmark.ips do |x|

  x.report("symbol ") { hash[:symbol] }

  x.report("string ") { hash["string"]}

end

```




Gives us




```


Calculating -

             symbol    130.247k i/100ms

             string    123.185k i/100ms

-

             symbol       7.795M (±14.2%) i/s -     38.162M

             string       7.532M (±16.7%) i/s -     36.216M



```







If you want your HWIA to be faster, use strings instead of symbols. Check out 
http://www.sitepoint.com/unraveling-string-key-performance-ruby-2-2/ and scroll 
down to the part about Ruby 2.2













---Richard Schneeman


http://www.schneems.com

On Sun, Aug 23, 2015 at 8:23 PM, Rafael Mendonça França
 wrote:

> Thank you for the suggestion? Could you explain what advantages this change
> will bring? I think we can change but it is a backward incompatible change
> and we really a good reason to do so.
> On Sun, Aug 23, 2015, 11:39 Leslie Hoare  wrote:
>> Currently HashWithIndifferentAccess stores using string keys, and any
>> symbols passed in get converted to strings. As I understand it, this was
>> due to the fact that in earlier versions of Ruby, symbols would not get
>> garbage collected and would thus stick around for the lifetime of the
>> process.
>>
>> With Rails 5, and its minimum version requirement of Ruby 2.2.1, I don't
>> believe this to be an issue anymore, and symbols perform better as Hash
>> keys.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to rubyonrails-core+unsubscr...@googlegroups.com.
>> To post to this group, send email to rubyonrails-core@googlegroups.com.
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] String Allocation and Memory Bloat in ActiveRecord Objects

[richard schneeman]

You're correct, it wouldn't work without the hash. I didn't grok the patch 
until it was in front of me on github. Thank


---Richard Schneeman


http://www.schneems.com

On Mon, Aug 24, 2015 at 7:16 PM, null  wrote:

> Hello Richard,
> Thanks for the response. Unfortunately I'm not sure how it's possible to do 
> this without the Hash look-up. For example one might imagine adding
> something like this to ActiveSupport::Callbacks (which would prevent more 
> than one string from being permanently allocated):
> @@_current_kind = nil
> 
> def get_frozen_callback(kind)
>   if @@_current_kind == kind
> @@_current_callback
>   else
> @@_current_kind = kind
> @@_current_callback = "_#{kind}_callbacks".freeze
>   end
> end
> The problem is that this is what a typical run actually looks like:
> [1] pry(main)> Symbolie.all.to_a
> in #run_callbacks -- self: 
> #, 
> kind: checkout
>   Symbolie Load (2.6ms)  SELECT "symbolies".* FROM "symbolies"
> in #run_callbacks -- self: #, kind: find
> in #run_callbacks -- self: #, kind: initialize
> in #run_callbacks -- self: #, kind: find
> in #run_callbacks -- self: #, kind: initialize
> in #run_callbacks -- self: #, kind: find
> in #run_callbacks -- self: #, kind: initialize
> in #run_callbacks -- self: #, kind: find
> in #run_callbacks -- self: #, kind: initialize
> in #run_callbacks -- self: #, kind: find
> in #run_callbacks -- self: #, kind: initialize
> in #run_callbacks -- self: #, kind: find
> in #run_callbacks -- self: #, kind: initialize
> in #run_callbacks -- self: #, kind: find
> # etc.
> The objects are initialized sequentially so without a hash the strings will 
> still have to be allocated and deallocated on a per-object basis - since as 
> far as I understand (I may be mistaken here?) it is not useful to freeze a 
> dynamically-generated string in Ruby without storing the reference e.g.
> [2] pry(main)> "hello world".freeze.object_id
> => 70185328616580
> [3] pry(main)> "hello world".freeze.object_id
> => 70185328616580
> [4] pry(main)> var = "world"
> => "world"
> [5] pry(main)> "hello #{var}".freeze.object_id
> => 70185328477560
> [6] pry(main)> "hello #{var}".freeze.object_id
> => 70185328139100
> I think for all normal applications the memory use from the hash is 
> entirely marginal (about the same as a previous_changes on a single AR 
> object) and since all objects will re-use these calls it doesn't make a lot 
> of sense to clear.Actually I think even if the plan was to clear, it may be 
> quite difficult to do so - since callbacks are an ActiveSupport concern 
> they should be generally usable without AR (in theory?) -- meaning that any 
> class which extends the concern and calls the define_callbacks and 
> run_callbacks methods should be capable of using them correctly. Perhaps an 
> alternative would be to make the string freezing behaviour specific to the 
> ActiveRecord extension of ActiveSupport callbacks, and guaranteeing that 
> the callbacks hash is cleared after all callbacks are run (it would need to 
> have transactional not object based context) and may be little messy and 
> I'm really not sure clearing 10-30 strings from memory (potentially only 
> until the next callback cycle re-allocates them) would justify that. 
> I will make a pull request on github as per your suggestion. 
> - Alex
> On Sunday, August 23, 2015 at 11:47:35 PM UTC+8, richard schneeman wrote:
>>
>> I appreciate people pointing out slow spots. I'm not the most quallified 
>> to speak about AR but I'll try to help with the proposed patch. You can get 
>> a bit more speed by taking out the hash lookup:
>>
>> ```ruby
>> require 'benchmark/ips'
>>
>> var = "world".freeze
>> hash = { var => "hello #{var}".freeze}
>>
>> Benchmark.ips do |x|
>>   x.report("hash") { hash[var] }
>>   x.report("compare ") { var == "world".freeze ? "hello world".freeze : 
>> "hello #{var}" }
>>   x.report("static  ") { "hello world".freeze }
>>   x.report("none") { "hello #{var}" }
>> end
>> ```
>>
>> Gives you:
>>
>>
>> ```
>> Calculating -
>> hash90.986k i/100ms
>> compare 98.282k i/100ms
>> static 103.704k i/100ms
>> none90.593k i/100ms
>> --

Re: [Rails-core] Ruby on Rails Contribution

[richard schneeman]

Try out these services to help you find places to contribute.



http://www.codetriage.com/rails/railshttp://www.docsdoctor.org/rails/rails










—
Sent from Mailbox

On Thu, Sep 17, 2015 at 11:43 PM, Chirag Aggarwal 
wrote:

> Hi, I want to contribute in Ruby on Rails. Could someone point me to a 
> beginner bug?
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] ActiveRecord connection pool management

[richard . schneeman]

We run into problems with connection pools on Heroku.




In Postgres a connection is very expensive. The cheap/free plans on Heroku 
Postgres all have very small connection limits. The hobby plan is limited to 20 
connections https://devcenter.heroku.com/articles/heroku-postgres-plans.




Some people will build really small rack apps that use active record, and want 
to max out their processes/threads. It's not that common but it happens.




More commonly people don't know about this behavior and get 
ActiveRecord::ConnectionTimeoutError because they're using default Puma which 
is set to 16 threads and default AR which is set to 5 connections. I wrote 
these docs to help people understand the connection requirements of AR 
https://devcenter.heroku.com/articles/concurrency-and-database-connections





Our larger customers end up hitting our max conneciton limit of our 
"production" plans which is 500 connections. They end up having to run 
PgBouncer which does per machine connection multiplexing 
https://devcenter.heroku.com/articles/concurrency-and-database-connections#limit-connections-with-pgbouncer
 








---Richard Schneeman


http://www.schneems.com

On Thu, Oct 1, 2015 at 9:45 AM, Matt Jones  wrote:

> If the concern is long-running threads holding DB connections they don't
> need, wouldn't a simpler solution be to explicitly return connections to
> the pool (via release_connection) before doing a long-running non-DB
> operation? Checking out and back in on most operations seems like
> optimizing for that uncommon case at a runtime cost for the common one.
> --Matt Jones
> On Thu, Oct 1, 2015 at 4:25 AM, Xavier Noria  wrote:
>> The only time I've seen one connection per thread being an issue was in
>> one app that ran many processes and it started to reach the connection
>> limit of their db server in traffic peaks. Even in that scenario,
>> contention is also a risk if you reduce the pool.
>>
>> Other than the mental image that you're using less resources (at the price
>> of contention), I am not sure there is going to be any significant
>> practical win. It could be, I am not saying it wouldn't (I have not done
>> your study), but at first sight the cost/benefit is not clear to me in
>> practical terms.
>>
>> Regarding transactions, #execute is public AR interface, and
>>
>> AR::Base.connection.execute('START TRANSACTION')
>>
>> is valid AR code, I am not sure if drivers know the connection is in a
>> transaction and have API to check, but #transaction_open? returns false as
>> of this writing. Why would anybody do that? I don't know, maybe because
>> they are writing a heavy SQL oriented script and doing that manually feels
>> natural... it doesn't matter, it can be done.
>>
>> Another practical point is that when a connection is checked out the
>> connection pool tests if it is alive issuing for example SELECT 1. That
>> would mean that if a request performs today 200 queries, they would become
>> 400 queries. I don't know if the alive check could be rethought to run less
>> frequently, but it probably should to avoid that 2x.
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to rubyonrails-core+unsubscr...@googlegroups.com.
>> To post to this group, send email to rubyonrails-core@googlegroups.com.
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] ActionCable using Postgres listen/notify

[richard schneeman]

On a plane right now and can't really dig in but the subject interests me. If 
you're interested I have an ultra simple gem that uses AR for listen/notify in 
PG https://github.com/schneems/hey_you

---
Richard Schneeman
http://www.schneems.com




On Sun, Dec 20, 2015 at 1:15 PM -0800, "Sean Linsley" 
 wrote:










Hi there,

The contributing guide suggests to write up feature requests on this 
out-of-the-way mailing list, and I couldn't find a ticket or a blog post around 
using Postgres listen/notify with ActionCable (in fact the only thing I could 
find was: https://twitter.com/guilleiguaran/status/590526076536938496), so here 
I am.

Are there any objections to adding this?

Here's an implementation I wrote with the Tubesock gem: 
https://gist.github.com/seanlinsley/775e9d934128b62ace8c

Sean Linsley






-- 

You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.

To post to this group, send email to rubyonrails-core@googlegroups.com.

Visit this group at https://groups.google.com/group/rubyonrails-core.

For more options, visit https://groups.google.com/d/optout.






-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] ActionCable using Postgres listen/notify

[richard schneeman]

We could create a PG channel that listens for a "disconnect" event perhaps.

---
Richard Schneeman
http://www.schneems.com




On Mon, Dec 21, 2015 at 8:57 AM -0800, "Sean Linsley" 
 wrote:










Well, there’s a seemingly intractable problem: the current implementation 
allows you to disconnect all websockets for a given user. My implementation 
doesn’t provide a way to do that since each Rails server instance creates its 
own thread to listen for messages & notify the websockets it knows about.
https://github.com/rails/rails/blob/c3989819ea/actioncable/lib/action_cable/remote_connections.rb#L12
Hmm, perhaps it could be worked around by having each listener disconnect all 
websockets it knows about that match the given user.
Sean Linsley
On Dec 20, 2015, at 7:47 PM, Sean Linsley  wrote:
Hey Richard, in the time between when this post was submitted and when it was 
approved for the mailing list, I made some progress reading through the 
existing implementation. There are some notes on the Twitter thread: 
https://twitter.com/seanlinsley/status/678654835982524416
The most important point is that the current code seems to create a new Redis 
connection for every websocket. It seems like Redis can handle that (the 
default max is 10k), but Postgres definitely can’t. My gist worked around that 
by creating a single thread to listen for new events, and trigger notifications 
to everyone that’s listening. It’d be quite difficult to keep the current 
approach and also support Postgres.
Thanks for the link to your repo. Reading through, I discovered that there’s a 
`raw_connection` method! Much better than accessing the instance variable like 
I was doing ^^’
I also refactored my gist, turning the one 20 line method into two 10 line 
methods. Though I haven’t actually tested that it still works ¯\_(ツ)_/¯

Sean Linsley
On Dec 20, 2015, at 4:20 PM, richard schneeman  
wrote:
On a plane right now and can't really dig in but the subject interests me. If 
you're interested I have an ultra simple gem that uses AR for listen/notify in 
PG https://github.com/schneems/hey_you

---
Richard Schneeman
http://www.schneems.com




On Sun, Dec 20, 2015 at 1:15 PM -0800, "Sean Linsley" 
 wrote:










Hi there,

The contributing guide suggests to write up feature requests on this 
out-of-the-way mailing list, and I couldn't find a ticket or a blog post around 
using Postgres listen/notify with ActionCable (in fact the only thing I could 
find was: https://twitter.com/guilleiguaran/status/590526076536938496), so here 
I am.

Are there any objections to adding this?

Here's an implementation I wrote with the Tubesock gem: 
https://gist.github.com/seanlinsley/775e9d934128b62ace8c

Sean Linsley









-- 

You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.

To post to this group, send email to rubyonrails-core@googlegroups.com.

Visit this group at https://groups.google.com/group/rubyonrails-core.

For more options, visit https://groups.google.com/d/optout.






-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Warn when submitting hashes with same key as string and symbol to AR methods?

[richard schneeman]

It's going to be really expensive to check that on every call. Maybe it could 
be a good feature for a gem you only use in development.

---
Richard Schneeman
http://www.schneems.com




On Thu, Mar 24, 2016 at 4:22 PM -0700, "Andrew Selder" 
 wrote:










Andrew,

I agree they shouldn’t happen in the first place, but unfortunately 
they crop up in the real world, you get a hash from a JSON object and 
mix that with some params, and you might do this without even realizing 
it.

This is why I propose that AR spit out a warning message (perhaps 
upgraded to an error in future versions) if this happens.

Andrew

On 24 Mar 2016, at 16:09, Andrew Kaspick wrote:

> I'd label this purely as undefined behavior and such cases shouldn't 
> occur
> in the first place.
>
> On Thu, Mar 24, 2016 at 6:59 PM, Andrew Selder 
> 
> wrote:
>
>> Hi all,
>>
>> After we got bit by it a couple times recently, I was thinking of
>> submitting a PR for ActiveRecord that would issue a warning if you 
>> submit a
>> hash containing the same key as both a symbol and a string to any of 
>> the AR
>> construction methods (create, new, update_attributes, etc…) . As 
>> far as I
>> can tell, the behavior when this happens in undefined (and change 
>> between
>> Rails 3 and 4 for example).
>>
>> For example:
>>
>> attr = { ‘a’ => 123, :a => 456 }
>> ARModel.create!(attr)
>>
>> In Rails 3, you’ll get an object with the ‘a’ attributes set to 
>> 456, in
>> Rails 4, you’ll get 123.
>>
>> I think this kind of things is almost always unintentional and worth 
>> a
>> warning.
>>
>> I’ll be happy to code this up and submit it if people think it 
>> would be
>> useful and accepted.
>>
>> Please let me know your thoughts and feedback.
>>
>> Thanks,
>>
>> Andrew
>>
>> --
>> You received this message because you are subscribed to the Google 
>> Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, 
>> send an
>> email to rubyonrails-core+unsubscr...@googlegroups.com.
>> To post to this group, send email to 
>> rubyonrails-core@googlegroups.com.
>> Visit this group at https://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> -- 
> You received this message because you are subscribed to the Google 
> Groups "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to 
> rubyonrails-core@googlegroups.com.
> Visit this group at https://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.





-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Warn when submitting hashes with same key as string and symbol to AR methods?

[richard schneeman]

> Perhaps controlled by a config variable (a la the old whiny_nils)? 

I would prefer not. We are way overloaded with config options. Those options 
aren't free, adding each feature behind a config flag requires maintenance and 
support. Instead have bundler be your config flag. If it's important enough to 
add to Rails Core, it should be important enough to make its own gem. If that 
gem is so insanely wildly downloaded that everyone uses it then maybe we can 
consider adding it as a configuration option. 


-- 
Richard Schneeman
http://schneems.com


On March 24, 2016 at 6:46:36 PM, Andrew Selder (andrew.sel...@gmail.com) wrote:

Perhaps controlled by a config variable (a la the 
old whiny_nils)? 

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Partial model validation

[richard schneeman]

I Not sure if you saw or not, I have docs for how to cobble this together with 
existing pieces. 
https://github.com/schneems/wicked/wiki/Building-Partial-Objects-Step-by-Step


-- 
Richard Schneeman
http://schneems.com


On May 25, 2016 at 1:54:53 AM, thomas sevestre (t...@tcare.fr) wrote:

The context param is ok for some cases, ie for implementing a state machine 
like the business logic of an order.

But in my opinion the model should not change wether it is edited in a single 
form or in a wizard. You should not need to edit the model when you move an 
input field from a view to anther... This should be handled in the controller. 
With the proposed patch :

    def uptade
  ...
      my_object.assign_attributes(params)
      my_object.save(partial_validation: params.keys)
  ...
    end

Done !

Let me know if you are interested with a PR


Le mercredi 25 mai 2016 00:44:01 UTC+2, Andrew Kaspick a écrit :
You can use the context param or a "form object" if you only need to do partial 
validations.

On Tue, May 24, 2016 at 12:12 PM, thomas sevestre  wrote:
Hello,

I've been looking for a solution to perform partial validation of a model.
This is often an issue when you have multiple forms to fill a single model (ie 
with wicked wizard gem).
They are multiple complicated solutions on the web but it would be fairly easy 
to implement inside the validation framework.

I can provide a patch if interested.

This could be the API:

    my_object.save(partial_validation: array_of_attributes_to_validate)

The modified functions of active_record/validations (on branch 4.2)

    def valid?(context = nil, partial_validation = nil)
  context ||= (new_record? ? :create : :update)
  output = super(context)
  if partial_validation
    (errors.keys - partial_validation).each do |attr|
  errors.delete(attr)
    end
  end
  errors.empty? && output
    end

    def perform_validations(options={}) # :nodoc:
  options[:validate] == false || valid?(options[:context], 
options[:partial_validation].map(&:to_sym))
    end

Let me know if interested

Regards,
Thomas
--
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-co...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Inconsistency in use of user_name and username

[richard schneeman]

Would need to change everywhere that it's being called, add a deprecation and 
work with both values for now.

Looks like `:username` is found more often in the codebase 334 times compared 
to `user_name` coming in at 231.

-- 
Richard Schneeman
http://schneems.com


On June 22, 2016 at 1:17:16 PM, Koen Punt (koenp...@gmail.com) wrote:

At first it appeared to me in the smtp settings, the username has to be 
specified as "user_name", but the comment in the source is naming it "username".


* :user_name - If your mail server requires
authentication, set the username in this setting.

https://github.com/rails/rails/blob/master/actionmailer/lib/action_mailer/base.rb#L382

And doing a search on "user_name" and "username" in the repository both give 
quite some results.

I think making this consistent could make things more clear, and makes typing 
configuration possible, instead of copy-pasting.

--
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Alternative proposal to prevent destructive actions on production databases

[richard schneeman]

The `ar_internal_metadata` is tiny. I wouldn't consider it database pollution 
any more than the schema migration table. It's actually much smaller.

> Rails should check if the configuration of the connection that is being used 
>is the same as the one in the list of "protected_environments"

This doesn't handle the case where you pull down your production configuration 
and put it in your `development` group because you wanted to debug something 
locally that required production data. People do this. It doesn't handle the 
case where people are using DATABASE_URL but don't have it specified in their 
`config/database.yml`.

If we switched from storing the data anywhere but _in_ the database we run the 
risk of mistakes. I didn't want a feature that required you be extra careful to 
be safe, I wanted a system where you're safe(r) even when you're not being 
careful.

I appreciate thinking about alternate implementation ideas. In this case 
optimizing to remove ar_internal_metadata table is not a very worthwhile 
endeavor in my opinion.

-- 
Richard Schneeman
http://schneems.com


On July 8, 2016 at 9:15:59 AM, Fernando Tapia Rico (fertap...@gmail.com) wrote:

ar_internal_metadata

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] 4.2.x release schedule

[richard schneeman]

For a release there needs to be need. I.e. we won't just release the same code 
over and over, there needs to be meaningful patches. It also takes coordination 
and human power. Releasing is a non-trivial task. You can always use `github: 
'rails/rails', branch: '4.2'` in your gemfile if you need more recent than 
whatever is currently released. If there is a HUGE patch that has been in 
master that you really really want then you need to help raise awareness. You 
could reply to the commit or PR where the patch was introduced, you could post 
on this list. 

-- 
Richard Schneeman
http://schneems.com


On September 7, 2016 at 7:44:45 AM, James Coleman (jtc...@gmail.com) wrote:

What is the process for determining when to release the next in the 4.2 series 
(4.2.8)? Is there a generally expected timeframe between releases? Or is it 
waiting on specific fixes?

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] [Feature] Add support HashWithIndifferentAccess to Hash#extract!

[richard schneeman]

HashWithIndifferentAccess is EXTREMELY expensive. For some background I did a 
write up on Hashie, another object that inherits from Hash 
http://www.schneems.com/2014/12/15/hashie-considered-harmful.html

Several of the problems that apply to hashie also apply to HWIA. Basically any 
subclass of Hash is going to be slow. Here's an issue I opened in Rack which is 
closer to HWIA https://github.com/rack/rack/issues/738.

-- 
Richard Schneeman
http://schneems.com


On September 22, 2016 at 8:37:32 AM, Andrey Molchanov (neod...@gmail.com) wrote:

Hello there!
I propose to add support for class objects HashWithIndifferentAccess to method 
Hash#extract!:
before:
def extract!(*keys)
  keys.each_with_object(self.class.new) { |key, result| result[key] = 
delete(key) if has_key?(key) }
end
after:
def extract!(*keys)
  keys.map! { |key| convert_key(key) } if respond_to?(:convert_key, true)
  keys.each_with_object(self.class.new) { |key, result| result[key] = 
delete(key) if has_key?(key) }
end
Thanks! 
--
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Suggestion for a new Rails environment that can be used exclusively for automation testing of functional/system tests

[richard schneeman]

I highly recommend against "custom" environments.

I disagree with using environments for configuration (such as database 
connections), they should be used for behavior.

Here's a thing I wrote about the problems you can get into by solving problems 
by creating new "env" types: 
https://devcenter.heroku.com/articles/deploying-to-a-custom-rails-environment

While i'm talking about "staging" as an env, I think it's generally applicable 
to any non development/production/test environments. 

I also don't think the problem you're trying to solve with a custom environment 
is fully formed. I've not found a need for a custom test like environment.

-- 
Richard Schneeman
http://schneems.com


On March 1, 2017 at 7:36:22 AM, Chad Woolley (thewoolley...@gmail.com) wrote:

See also this thread:

https://groups.google.com/d/topic/rubyonrails-core/kqKoJHcQu9U/discussion

...wherein is discussed (without any official response from core contributors) 
many of the warts and limitations of RAILS_ENV in a modern, cloud-native-y, 
12-factor-y world.

-- Chad

On Mon, Feb 27, 2017 at 6:15 AM, Vijay Raghavan Aravamudhan  
wrote:
With the latest merge into the master branch of this 
https://github.com/rails/rails/pull/26703, it seems that the core framework is 
heading in a direction where functional/system tests are also being accepted in 
a more formal way. If this is the case, imo, it would make sense to also have a 
RAILS_ENV that is separate from the ubiquitous 'test' env. In all my RoR 
projects where we have written automated functional tests using some framework, 
we have had to duplicate 'test' into something else. Would the community think 
that such a formalization makes sense?

tx,
Vijay
--
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Suggestion for a new Rails environment that can be used exclusively for automation testing of functional/system tests

[richard schneeman]

hat article and 
adding a warning to buildpack deploys I saw a significant drop in the number of 
support tickets opened on the platform. At one point is was the largest cause 
of customer tickets. I acknowledge separating behavior (RAILS_ENV) and config 
on non-heroku platforms is harder because the infrastructure for env-vars isn't 
as easy, but the benefits are no different.

-- 
Richard Schneeman
http://schneems.com


On March 2, 2017 at 2:34:38 PM, Dieter Späth (dieter.spa...@gmx.de) wrote:

To me environment variables make only sense for secret things, config options 
which change often or options you want to be able to change without a 
redeployment.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Suggestion for a new Rails environment that can be used exclusively for automation testing of functional/system tests

[richard schneeman]

I think I lost you on my example of running the RAILS_ENV=production code 
locally & why it was safer without production config info checked in. 

In my case I'm using a `.env` file and already have all the creds I need for 
local development i.e.  stripe API token and AWS etc. They're all set for my 
own personal development account. When I want to profile the __behavior__ of a 
production app, it is super safe for me to use `RAILS_ENV=production` locally 
and be 100% confident that i'm not going to send out emails or blow away a 
production memcache because it's using the exact same __configuration__ as my 
development environment. When someone has all that info checked in as soon as 
they use `RAILS_ENV=production` then the app is a live loaded gun.

As you mentioned this technique doesn't protect against the case where you ssh 
into your production box by accident and run a bad command. But neither does 
relying on someone to remember to run `RAILS_ENV=staging`, sure it might catch 
a slip up or two, but I guarantee if you rely on this, one day someone will 
forget that preface and tears will be made. It's also why we should potentially 
build in safe guards for the really dangerous components, like dropping 
databases.

If you always have to remember to do something i.e. you always have to remember 
to preface every command with RAILS_ENV=staging, then it's insecure by default. 
If you're requiring the user to do the right thing 100% of the time, over the 
long run you'll always lose. Almost all major incidents and security breaches 
have a human component. My desire is to mitigate this as much as possible.

> Furthor more (realy opinionated meaning, can be realy wrong) I think most of 
>your tickets came from RoR starters and not long term Rails users.

These tickets came all types of customers. They came from some of our largest 
customers who have been running on the platform longer than I have worked there 
and new developers on free accounts. Every developer is capable of making a 
mistake. I'm not trying to pull rank here with my "i've been doing this for X 
long" i'm saying that i've seen A LOT of developers and apps make this mistake. 
This isn't an idea i'm pulling out of my butt here. At one point this was the 
largest ticket producer by a fair margin. After I introduced the article and 
added a warning, they've mostly disappeared  I've heard basically no complaint 
or pushback of the concept from people who have done this. It's not so much an 
"opinion", that can be "really wrong", as it is a hypothesis that i've tested 
on hundreds-of-thousands/millions of rails apps and gotten a lot of positive 
confirmation on.

This isn't an issue of "good" developers and "bad" developers. Here is a case 
of a huge outage caused by presumably someone who knows what they did yet made 
a mistake https://aws.amazon.com/message/41926/. The mitigation strategy is to 
make it so that doing the wrong thing is harder. Everyone regardless of skill 
or familiarity with a tool is a bad developer when they're tired or angry or 
drunk. So it's better to design for the "bad developer" case 100% of the time 
because it's a reality we all face.

I built in code to explicitly protect people from dropping their production 
databases. Not because "only new developers do it" but because when anyone does 
it, regardless of how often...the results are catastrophic. Even if a problem 
is "easy to debug" if someone "knows what they're doing" it's not good enough 
if the problem could have been prevented via automation or code in the first 
place. Time is money and hours spent debugging when a issue could have been 
prevented entirely is, not ideal.

> For instance you can't generate config file during deployment or do other 
>stuff.

Tell me what you want to do on Heroku and I can tell you how it's possible. If 
you needed to generate files I would hook into the `rake assets:precompile` 
call. 

> For instance I have an env STAGING_DB... and PROD_DB ... . Within my staging 
>environment PROD_ is not set and my staging server has no connection to my 
>production systems.

Great, this is what i'm talking about. Your staging or development server 
should not be __capable__ of accessing any sensitive 3rd party services tied to 
production. If you check them into your app, then they're accessible. You're 
doing what i'm advocating here. I don't care about how you store the 
information i.e. put it in an env var or some other configuration management 
toolchain, just whatever you do don't put all your secrets in your app and 
check them in to your source control and make them available to all running 
instances of your app.

-- 
Richard Schneeman
http

Re: [Rails-core] Feature Request: Save page HTML when system test fails

[richard schneeman]

I would like that as an option.

---
Schneems
https://www.schneems.com

From: rubyonrails-core@googlegroups.com  on 
behalf of Marc Riera Casals 
Sent: Wednesday, January 24, 2018 4:16:00 AM
To: Ruby on Rails: Core
Subject: [Rails-core] Feature Request: Save page HTML when system test fails

Hi all!

I read in the contributing guide that feature requests should be posted here:

https://github.com/rails/rails/blob/master/CONTRIBUTING.md#do-you-intend-to-add-a-new-feature-or-change-an-existing-one

I've been searching and I haven't found this being asked already, so here it 
goes. I see the system tests save a screenshot when a test fails, which is 
super useful, but sometimes it's be good to have the rendered HTML too.

Is this feasible? Does this sound reasonable?

Thanks!

--
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to 
rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Feedback for https://github.com/rails/rails/pull/37246

[richard schneeman]

As somewhat of a self-plug, for those of you who are looking for more
feedback on your PRs and Issues, you can help be part of the solution by
signing up to triage and provide feedback on issues
https://www.codetriage.com/rails/rails.

On Tue, Oct 8, 2019 at 1:26 AM Sushant Mittal  wrote:

> Hello Rails
>
> I created a PR some 20 days ago and never received feedback.
>
> PR: https://github.com/rails/rails/pull/37246
>
> Please look into that.
>
> Thanks
> Sushant
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rubyonrails-core/1098fe56-7d37-409d-a8ae-14b0a56d2dd4%40googlegroups.com
> <https://groups.google.com/d/msgid/rubyonrails-core/1098fe56-7d37-409d-a8ae-14b0a56d2dd4%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
Richard Schneeman
https://www.schneems.com

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rubyonrails-core/CAFA5uRP%2B-%2BzS1PkAyxp%2BWvA0t8B9RLEPVFRUOJKGv-3B1N%3DwVg%40mail.gmail.com.

Re: [Rails-core] [Rails 6] Bug in caching key generation when working with active record collections?

[richard schneeman]

Sounds like a bug. Can you move into an issue?



On Thu, Oct 24, 2019 at 7:52 PM Marc Köhlbrugge 
wrote:

> I'm running into a problem when using fragment caching with active record
> collections.
>
> Rails 6 uses a combination of collection.cache_key and
> collection.cache_version to determine whether a fragment cache is fresh or
> not. However, there is a scenario where the collection might change while
> collection.cache_key and collection.cache_version stay the same.
>
> It happens when you use a limit on the collection and then destroy one of
> those records, as long as it's not the most recent one. This way
> collection.cache_key will stay the same, because the query does not change.
> And collection.cache_version will stay the same as well, because the
> collection count will remain unchanged as does the maximum updated_at
> timestamp of the most recent record.
>
> I've build a sample app for demonstration purposes:
>
> https://github.com/marckohlbrugge/rails-6-collection-caching-bug
>
> The readme describes a way to reproduce the issue via the website itself,
> or the Rails console.
>
> Would this be considered a bug or expected behavior? Are there any known
> work arounds?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rubyonrails-core/4cc0ae69-c736-48d0-bd84-8b3f44dc879d%40googlegroups.com
> <https://groups.google.com/d/msgid/rubyonrails-core/4cc0ae69-c736-48d0-bd84-8b3f44dc879d%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
-- 
Richard Schneeman
https://www.schneems.com

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rubyonrails-core/CAFA5uRNRZQh2PiZ5uNoiBcbz5oj11FJhOurjJLmfwPkP%3D7Bo%3DA%40mail.gmail.com.

Re: [Rails-core] Proposal to run spell check on GItHub Actions

[richard schneeman]

As someone who has commit to the project merging in spelling corrections
takes almost no time. I don't think getting fewer of these PRs would be a
huge net win (others with commit might disagree). As an occasional writer
of features and docs, it would be nice to get feedback right away that I
had made an error, but I find spell checking for technical documentation to
be very error-prone. I usually turn it off for my editors due to the sheer
volume of false spelling flags. If we did adopt some kind of a spell
checker I would want it to be more for information purposes than as a hard
blocker. If the accuracy looks good then we could eventually make it
mandatory.


On Sun, Oct 27, 2019 at 9:20 AM Masafumi Okura 
wrote:

> Hi,
>
> This is a proposal related to
>  https://groups.google.com/d/msg/rubyonrails-core/o3wWBsTSbxU/s9X6pJHDBwAJ
> <https://groups.google.com/d/msg/rubyonrails-core/o3wWBsTSbxU/s9X6pJHDBwAJ>
>
> I see many Pull Requests fixing typos in documents. This can be done
> mostly automatically by machines.
> I found there's a good tool to find misspells.
> https://github.com/client9/misspell
> If we can run this tool on CI, we can reduce the number of Pull Requests
> just fixing typos.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rubyonrails-core/cd70b713-02a1-4812-b6f8-01dbdfa7ce01%40googlegroups.com
> <https://groups.google.com/d/msgid/rubyonrails-core/cd70b713-02a1-4812-b6f8-01dbdfa7ce01%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
Richard Schneeman
https://www.schneems.com

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rubyonrails-core/CAFA5uROEnnq4XTURgA%2BRVLr6Vf2v%2B-Ugvsf9sxfZQeEYQNX5sA%40mail.gmail.com.

Re: [Rails-core] [Rails 6] Bug in caching key generation when working with active record collections?

[richard schneeman]

 be removed.
>>>>
>>>> I believe modifying the compute_cache_version method defined in
>>>> activerecord/lib/active_record/relation.rb
>>>> <https://github.com/rails/rails/blob/master/activerecord/lib/active_record/relation.rb>
>>>> is the way to go about this.
>>>>
>>>> Marc, please let me know if you intend to submit a pull request. While
>>>> I'm not on the Rails team, I'd be happy to offer any assistance and lobby
>>>> for implementing a fix. (If you're not interested in submitting a PR, I'd
>>>> be excited to pick this up myself.)
>>>>
>>>> On Sun, Oct 27, 2019 at 10:41 AM Marc Köhlbrugge <
>>>> marckohlbru...@gmail.com> wrote:
>>>>
>>>>> 👍 https://github.com/rails/rails/issues/37555
>>>>>
>>>>> I did find a few similar issues, but they all got marked as stale
>>>>>
>>>>> https://github.com/rails/rails/issues/34408
>>>>> https://github.com/rails/rails/issues/31996
>>>>> https://github.com/rails/rails/issues/34093
>>>>>
>>>>> I'm surprised this doesn't appear to be a bigger problem. Perhaps I'm
>>>>> not supposed to fragment cache my paginated results. Using collection
>>>>> caching (`render collection: @posts, cached: true`) might be performant
>>>>> enough.
>>>>>
>>>>> On Sunday, October 27, 2019 at 2:55:18 PM UTC+1, richard schneeman
>>>>> wrote:
>>>>>>
>>>>>> Sounds like a bug. Can you move into an issue?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Oct 24, 2019 at 7:52 PM Marc Köhlbrugge <
>>>>>> h...@marckohlbrugge.com> wrote:
>>>>>>
>>>>>>> I'm running into a problem when using fragment caching with active
>>>>>>> record collections.
>>>>>>>
>>>>>>> Rails 6 uses a combination of collection.cache_key and
>>>>>>> collection.cache_version to determine whether a fragment cache is fresh 
>>>>>>> or
>>>>>>> not. However, there is a scenario where the collection might change 
>>>>>>> while
>>>>>>> collection.cache_key and collection.cache_version stay the same.
>>>>>>>
>>>>>>> It happens when you use a limit on the collection and then destroy
>>>>>>> one of those records, as long as it's not the most recent one. This way
>>>>>>> collection.cache_key will stay the same, because the query does not 
>>>>>>> change.
>>>>>>> And collection.cache_version will stay the same as well, because the
>>>>>>> collection count will remain unchanged as does the maximum updated_at
>>>>>>> timestamp of the most recent record.
>>>>>>>
>>>>>>> I've build a sample app for demonstration purposes:
>>>>>>>
>>>>>>> https://github.com/marckohlbrugge/rails-6-collection-caching-bug
>>>>>>>
>>>>>>> The readme describes a way to reproduce the issue via the website
>>>>>>> itself, or the Rails console.
>>>>>>>
>>>>>>> Would this be considered a bug or expected behavior? Are there any
>>>>>>> known work arounds?
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "Ruby on Rails: Core" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to rubyonra...@googlegroups.com.
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/d/msgid/rubyonrails-core/4cc0ae69-c736-48d0-bd84-8b3f44dc879d%40googlegroups.com
>>>>>>> <https://groups.google.com/d/msgid/rubyonrails-core/4cc0ae69-c736-48d0-bd84-8b3f44dc879d%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>> .
>>>>>>>
>>>>>> --
>>>>>> Richard Schneeman
>>>>>> https://www.schneems.com
>>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>

Re: [Rails-core] [Feature] Add whitelist for forgery_protection_origin_check

[richard schneeman]

I think currently encouraged terminology is “acceptlist” and “denylist”.

One option to gauging interest is to release as a gem. If it gets traction
then it makes a good case for making a first class feature, if not...you
can still use it.

On Wed, Jan 22, 2020 at 4:45 PM Joey Paris  wrote:

> Currently, the forgery_protection_origin_check is a boolean option that
> either only validates the origin is the same as the base_url or validates
> nothing at all. I like the idea of adding something
> like forgery_protection_origin_whitelist that contains an array of (regex)
> strings of approved origin domains. This whitelist check should only be
> tested if forgery_protection_origin_check is set to true, and it should
> probably always include the base_url.
>
> I should be able to add this in myself, I just want to make sure there's
> enough community support for this addition before putting the time into it.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rubyonrails-core/d29dd38c-fd2a-473e-9403-d0bf159e7107%40googlegroups.com
> <https://groups.google.com/d/msgid/rubyonrails-core/d29dd38c-fd2a-473e-9403-d0bf159e7107%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
-- 
Richard Schneeman
https://www.schneems.com

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rubyonrails-core/CAFA5uRMG14cveqYcJ5z1_VUeA30Sv7S-nrTYQYeSYBgkEBifhA%40mail.gmail.com.

Re: [Rails-core] We are moving to https://discuss.rubyonrails.org/

[richard schneeman]

Thanks Sam!

On Wed, Mar 25, 2020 at 9:55 PM Sam Saffron  wrote:

> Hi There,
>
> The Rails team has decided to migrate all the talk, docs and core Google
> groups to  https://discuss.rubyonrails.org/.
>
> Starting from can you post any core discussion there. If you are having
> any trouble finding your bearings I will be watching closely and do my best
> to help out!
>
> The theme used on the forum is open source and accepts contributions
> https://github.com/rails/discourse-rubyonrails-theme
>
> See you on the forum! We will be locking this group shortly and migrating
> the final missing posts over to the new home.
>
>
> Sam
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rubyonrails-core/9b2b822c-80fe-4bac-b012-7fe79be05e84%40googlegroups.com
> <https://groups.google.com/d/msgid/rubyonrails-core/9b2b822c-80fe-4bac-b012-7fe79be05e84%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
-- 
Richard Schneeman
https://www.schneems.com
he/him

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rubyonrails-core/CAFA5uRN4eGs27j0%3DJj7FD56%3D%3Dq6%2BnhvMXwLg%3DbhpuCa71UUAnQ%40mail.gmail.com.

[Rails-core] How to Run the ActiveRecord Test Suite

[richard schneeman]

When I run the unmodified ActiveRecord Test suite I get failures/
errors that look like it expects external network connections. Is
there an easy way to set up all of the tables needed in all the
different data stores to run these tests successfully?

`Errors running test_mysql, test_mysql2, test_sqlite3,
test_postgresql`

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

[Rails-core] Re: How to Run the ActiveRecord Test Suite

[richard schneeman]

Thanks Sergey, don't know how i missed the all caps file in the base
directory, guess i expected that info to be in the readme.

I got my tests to run and even better...to pass! Thanks again for the
help & Happy Holidays.

On Dec 23, 2:10 pm, Sergey Nartimov  wrote:
> Here is described how to run 
> testshttps://github.com/rails/rails/blob/master/activerecord/RUNNING_UNIT_...
>
> On Fri, Dec 23, 2011 at 7:41 PM, richard schneeman

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

[Rails-core] Pull Request: Notify A User they Have Pending Migrations On Specific Exceptions

[richard schneeman]

I wrote a pull request to inform developers that they have pending
migrations and should run `rake db:migrate` whenever they get a
NoMethodError or UnknownAttributeError on an AR object and their
database isn't migrated to the last version.

I've gotten several community members to comment, but I would like
some feedback from the Rails team:

https://github.com/rails/rails/pull/4165

Thanks for your time.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

[Rails-core] Re: Scaffold Generator Woes

[richard schneeman]

Anecdotally I can remember a few times I was glad, scaffolds existed
like when teaching Rails classes to beginners, and having them excited
to get started so quickly. I can also remember more than a few times I
regretted using a scaffold after having to heavily remove or modify
most of the code it generated. Rather than lean on either of these
sets of experiences, is there some way we can test and validate that
this would make using rails for beginners easier in the long run?
Serious question. I'll be happy to A/B test-teach this to a group of
students if we could come up with some reliable way of measuring
success.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

[Rails-core] AR Objects saved with Errors

[richard schneeman]

If I remember correctly, adding an error to an AR object's attribute
or :base previously prevented the object from being saved. This is not
the current behavior of Active Record.

user = User.last
user.errors.add :name, "name doesn't rhyme with orange"
user.valid? # => true
user.save   # => true

user = User.last
user.errors.add :base, "my unique error"
user.valid? # => true
user.save   # => true


Is that an intentional change, or an accidental one? Would a patch
preventing objects with errors from saving be considered?

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

[Rails-core] Re: On handling staging servers

[richard schneeman]

DHH once said the major advancement that Rails provided was empty folders, 
just a standard place to put things. Any app I go to, I can immediately 
find the assets, models, etc. In the same vein, I would support shipping 
with a staging environment. In my ideal world there would be a way to 
inherit production settings into my staging env, where I could just 
over-ride them as needed (with a different DB by default). 

I was introduced to the concepts of test/develop/prod environments as I was 
learning Rails. I think that was a good thing. Now that i'm teaching Rails, 
I make sure to introduce students to the concept since it is so useful. I 
agree that we can go overboard by providing a million default environments 
out of the gate and that would be bad. Though most good Rails applications 
i've seen have had a staging environment and server set up, and I believe 
that vanilla Rails should promote good practices. 

I also agree that configuration shouldn't be stored in source at all, and 
for those in the thread asking why that is, I think 12factor covers it 
fairly well http://www.12factor.net/config . I personally like to keep any 
of my server access tokens, secrets, and connection strings in environment 
variables, but there are still elements that I set inside of the config 
files. It would be killer to move Rails towards a source-control-less 
configuration setup. Even then, I would support having some support for a 
staging environment out of the gate. 

Getting outside of implementation, what are the downsides from 
users/maintainers to having this functionality in `rails new` ? 

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/rubyonrails-core/-/Qm_kZxGPsEcJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Attribute query methods and semantics

[Richard Schneeman]

I'm -1 on a has_* method

If we want to kill ? on non boolean attributes we should encourage standard 
@post.url.blank? and @post.url.present? be used instead. The originally 
proposed change makes sense to me. The question mark character adds nice 
semantics to boolean attributes. I agree it's not clear what exactly that would 
do on non-boolean attributes. Removing the questionable methods would help 
decrease the method count. 

Does anyone really need to use: @post.id? 

-- 
Richard Schneeman
@schneems (http://twitter.com/schneems)





On Thursday, May 31, 2012 at 3:28 PM, Jeremy Walker wrote:

> 
> 
> On 31 May 2012 14:23, Sam Oliver  (mailto:s...@samoliver.com)> wrote:
> > On Thu, May 31, 2012 at 2:12 PM, James B. Byrne  > (mailto:byrn...@harte-lyne.ca)> wrote:
> > > 
> > > > I would generate attribute query methods only for boolean attributes.
> > > 
> > > I am not sure that I understand your point, but in Ruby anything that
> > > is neither nil nor false is true.  Thus returning the url string, if
> > > not nil, is the same as saying that it is true but also allows access
> > > to the actual data without having to send another message.
> > 
> > I think Max's point is that "post.visible?" could be read as "post is 
> > visible?" but "post is url?" carries a different meaning. 
> 
> Maybe have query methods for boolean attributes and prefixed query methods 
> for not. e.g.
> post.visible?
> post.has_url?
> 
> Or maybe leave the currently methods as they are, but add new prefixed 
> methods, with different prefixes for boolean methods, e.g.
> post.is_visible?
> post.has_url?
>  
> > 
> > Sam
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "Ruby on Rails: Core" group.
> > To post to this group, send email to rubyonrails-core@googlegroups.com 
> > (mailto:rubyonrails-core@googlegroups.com).
> > To unsubscribe from this group, send email to 
> > rubyonrails-core+unsubscr...@googlegroups.com 
> > (mailto:rubyonrails-core%2bunsubscr...@googlegroups.com).
> > For more options, visit this group at 
> > http://groups.google.com/group/rubyonrails-core?hl=en.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] How to access an engine's method from main application?

[Richard Schneeman]

Hey Al, 

This list is used for talking about Rails internals for people who are 
contributing to the Rails framework directly. You will need to post this 
question to another list. Spree maintains a page with community support links 
http://spreecommerce.com/community or you can try posting to 
http://stackoverflow.com. Glad that you're using Rails, hope you find an 
answer.  

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Thursday, June 21, 2012 at 3:12 PM, A L wrote:

> Hi,
> 
> I'm not sure if this is the right place to post this, but please redirect me 
> if I'm posting this in the wrong place.
> 
> I'm trying to use a method defined in an engine's library, specifically it is 
> the current_order method from the Spree::Core 
> engine: 
> https://github.com/spree/spree/blob/master/core/lib/spree/core/current_order.rb
>  
> 
> In my view, I've tried 
> 
> Spree::Core::CurrentOrder.
> current_order 
> 
> Using just "current_order" in development works fine though, but not 
> in production. 
> 
> So then I've tried to require it in my views file like this: 
> 
> require 'spree/core/current_order' 
> 
> I've also tried permutations of these other solutions: 
> 
> http://stackoverflow.com/questions/11124447/how-to-incorporate-rails-engine-applicationcontroller-methods-in-a-main-app
>  
> 
> http://stackoverflow.com/questions/7323327/a-way-to-add-before-filter-from-engine-to-application/
>  
> 
> http://stackoverflow.com/questions/8797690/rails-3-1-better-way-to-expose-an-engines-helper-within-the-client-app
>  
> 
> But I've lost track of what I actually did. 
> 
> Can someone please point me in the right direction? Maybe I 
> implemented the solutions in the above links incorrectly? 
> 
> This is the error I'm getting in production: 
> 
> 2012-06-21T09:59:08+00:00 app[web.1 (http://web.1)]: 
> ActionView::Template::Error 
> (undefined method `current_order' for 
> Spree::Core::CurrentOrder:Module): 
> 
> If I comment out the lines of code with current_order, everything 
> works in production. 
> 
> I'm thinking it's the way things are loaded in production? But this is 
> the first time I'm trying to deploy so I don't quite understand the 
> differences between development and production.   I'm not sure if it matters, 
> but I'm deploying on Heroku.
> 
> Thanks in advance! 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/rubyonrails-core/-/SXr427-hIlAJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] suggestion for changed behaviour of non-block version of unscoped activerecord queires

[Richard Schneeman]

The current state of default scopes now is broken (for me). I have tried using 
them many times but they always end up being more trouble then they are worth.  

One of the biggest shortcomings I've had is the inability to remove just the 
default scope from the relation as sreid mentioned. 

Unscoped does what it says. It removes all scopes from the relation. It would 
be nice to have another method that only nullified default scope. Something 
like 'custom_scope'. Not sure if that's quite the same intent as th OP, but if 
included it would be cause enough for me to try default scopes again. 

-- 
Richard Schneeman
http://heroku.com
@schneems

Sent from the road


On Monday, July 2, 2012 at 11:44 AM, sreid wrote:

> I previously raised a rails issue about the use of unscoped in activerecord 
> queries : https://github.com/rails/rails/issues/2145.
> 
> It now appears that the current behaviour is actually as documented in the 
> source comments, so my request is really for a feature change rather than a 
> bug fix, and I've been directed here.
> 
> The issue is that using unscoped to override a default scope in a query such 
> as : @user.orders.unscoped.order(...) returns all orders for all users, not 
> just for @user. 
> 
> The source code comment for unscoped recommends using the block version of 
> the above e,g, Orders.unscoped do @user.orders.order(...) end instead, and 
> says that the non block form of unscoped "does not work".
> I think this is unintuitive, and inconsistent. Returning all records 
> (ignoring all other specified query conditions) seems wrong. Unscoped should 
> just mean "without the default scope". The current behaviour could 
> accidentally lead to security issues such as one user seeing all users data.
> Could the non-block version either be deprecated; return an error; or 
> (ideally) be corrected ?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/rubyonrails-core/-/WfKJFwGGRBMJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] URL ID

[Richard Schneeman]

Agreed,  If you want custom slugs use something like 
https://github.com/norman/friendly_id and then you can just forego the id in 
the url all together.


On Monday, July 9, 2012 at 1:18 AM, Ryan Bigg wrote:

> Very limited use-case. Can't see the point of it. 
> 
> -1 
> 
> On Monday, 9 July 2012 at 3:58 PM, angelo capilleri wrote:
> 
> > Many users try to overwrite the to_param method of AR to add more
> > expressivness and value of Seo to the url using something like the
> > following:
> > 
> > def to_param
> > id.to_s + title. parameterize + '-' + author. parameterize
> > end
> > 
> > That generate url like that:
> > 
> > http://host/books/10-goodbook-guest
> > 
> > The id passed to AR is '100-goodbook-guest' that type_casted to
> > integer in a trasparent way it will became 100.
> > 
> > My proposal is to permit to read also url like the following
> > 
> > http://host/books/goodbook-guest-10
> > 
> > In other words, the id string passed to AR could have integer at the
> > begining or end of itself
> > 
> > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "Ruby on Rails: Core" group.
> > To post to this group, send email to rubyonrails-core@googlegroups.com 
> > (mailto:rubyonrails-core@googlegroups.com).
> > To unsubscribe from this group, send email to 
> > rubyonrails-core+unsubscr...@googlegroups.com 
> > (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> > For more options, visit this group at 
> > http://groups.google.com/group/rubyonrails-core?hl=en.
> > 
> > 
> > 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Extending controllers and models of Rails 3.2+ Engines

[Richard Schneeman]

For extending models (and controller methods) I use concerns:

https://github.com/schneems/wicked/tree/master/lib/wicked/controller/concerns

Then you can include them in other classes or modules in your repo.

https://github.com/schneems/wicked/blob/master/lib/wicked/wizard.rb


Then you can let your user know to add an `include` statement in the readme.

https://github.com/schneems/wicked

class AfterSignupController < ApplicationController include Wicked::Wizard 
Some people like to automatically add methods to ActiveRecord::Base or other 
similar classes, this allows them to have a dsl like `acts_as_tree` but this 
just pollutes the available methods, and makes me have to remember unneeded dsl 
when we ruby already has this type of behavior included with `include`


If you want to add methods directly to the ApplicationController of an app you 
can add a application_controller_helper.rb

https://github.com/schneems/opro/tree/master/lib/opro/controllers

You need to include it 

require 'opro/controllers/application_controller_helper'

then you can define a helper method for it:

  def self.include_helpers(scope)
ActiveSupport.on_load(:action_controller) do
  include scope::ApplicationControllerHelper if 
defined?(scope::ApplicationControllerHelper)
end
  end



and finally in your engine:


initializer "opro.include_helpers" do
  Opro.include_helpers(Opro::Controllers)
end




For extending controllers like devise i've done this:

https://github.com/schneems/opro/blob/master/lib/opro/rails/routes.rb

You use the user supplied controller or fall back to a default view. 


Digging in the devise source as well can be tremendously valuable, though 
slightly daunting the first time or two. Let me know if you have some 
questions. 



-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Thursday, July 12, 2012 at 2:12 PM, Weston Platter wrote:

> Is there a "Rails Way" way for extending models and controllers of rails 
> engines?
> 
> The docs have TODO notes with no content for extending controllers and models 
> (see 5.2 and 5.3 http://guides.rubyonrails.org/engines.html).
> 
> If there's preferred method, I would love to use it and I'll update the docs. 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/rubyonrails-core/-/q7XpeRAheHkJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] perform_deliveries to be set per email / interceptors should he able to stop delivery

[Richard Schneeman]

Having the ability to easily comply to CAN-spam and other email legislation 
without having to add an if clause to _everywhere_ you are sending out email 
would be nice.  

Looks like you can already do something like this a mail interceptor: 
http://stackoverflow.com/questions/8594626/how-to-add-a-before-filter-in-usermailer-which-checks-if-it-is-ok-to-mail-a-user,
 though the OP never responded whether that works or not.  



--  
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Thursday, July 19, 2012 at 10:43 AM, Thibaut Barrère wrote:

> Hi,
>  
> I met the same need (eg: to avoid sending any email until the user is
> "confirmed" for instance) but did not implement anything yet.
>  
> I would probably just create a custom_mail method to be used in place
> of mail, which would decide based on your logic if mail must be called
> or not.
>  
> That said having a "global" hook to stop delivery could be useful too.
>  
> Just a thought!
>  
> -- Thibaut
>  
> --  
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.
>  
>  


-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Re: perform_deliveries to be set per email / interceptors should he able to stop delivery

[Richard Schneeman]

This conversation is diverting from the original. 

The question was whether a patch for this functionality would be useful, I 
personally would find it useful. And on that front we're done. 

If you want to talk about alternate implementations using existing Rails 
functionality please move the conversation over to Rails-Talk list. If you have 
questions or need advice cc/ me in a pull request.  

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Friday, July 20, 2012 at 8:57 AM, Matthew Johnston wrote:

> Try looking into a state machine. When the user confirms, then send an email. 
> It's really easy to think about
> 
> (guest) -- #confirm --> (confirming) -- #finished --> (active)
> 
> before_transition :on => :confirm, :do => :send_confirmation_email
> 
> Then do some magic on the confirmation side that triggers the #finished event.
> 
> Hope this helps
> 
> On Thursday, July 19, 2012 7:37:42 AM UTC-5, Aditya wrote:
> > 
> > It would be nice to have mail interceptor be able to modify the message to 
> > prevent delivery. Alternatively it would be nice to also prevent delivery 
> > in the mailer itself.
> > 
> > 
> > The use cases are as follows:
> > 
> > User is unsubscribed and you really want to prevent emails being sent to 
> > such users.
> > User has a guest account with a temp internal email address, which you do 
> > not want to send emails to.
> > The email content may be spammy and you want to prevent that delivery.
> > 
> > 
> > As such you could do each by wrapping more code around the 
> > MyMailer.mail_action(args)/.deliver pattern but it gets repetitive quickly.
> > 
> > 
> > This is not environment specific which is already handled very well in 
> > Rails since ages, this is more transactional. If we can already do this 
> > easily, feel free to point me to the right direction. Happy to send patch 
> > in due time if this is acceptable.
> > 
> > 
> > Possible routes i'm thinking are to add options to mail itself 
> > (:perform_delivery => determine_delivery(args)) and/or adding ability to 
> > prevent delivery from interceptor.
> > 
> > 
> > Suggestions/Ideas?
> > 
> > 
> > /cc @mikel (https://github.com/mikel) @josevalim 
> > (https://github.com/josevalim) @spastorino (https://github.com/spastorino)
> > 
> > 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/rubyonrails-core/-/lxnPH9Phqn4J.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

[Rails-core] Add an option to not create/drop a table in a given environment

[Richard Schneeman]

I'm trying to get some issues either closed or some hard TODO's attached. I'm 
looking at this issue and wanted to bring it up to the group:

https://github.com/rails/rails/issues/2899#issuecomment-7257057


Problem:

Production database differs from test environment.

Workaround:

Add conditionals to migrations, something like:

if Rails.env.test?
…

Problem with the workaround:

Now the schema we save is different for different environments.



The suggested fix in the issue would be to let our create and drop table 
commands be aware of the environment. I've not worked with the schema writing 
code before, so I'm not sure the scope involved in such a request.

If you have an opinion about this issue, or care to look into it. Please reply: 
https://github.com/rails/rails/issues/2899#issuecomment-7257057


--  
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)



-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Using the :layout option when calling render @variable

[Richard Schneeman]

Thomas, 

It would be easier for the core team if you could fork the 
https://github.com/rails/rails repo, make your change in your own repo and then 
submit a pull request with similar information (why you made the change, why 
you think others will want it, do the tests pass, did you add tests, etc.).

Once the pull request has been made core team members and the general public 
can comment on your code and the changes on github. 

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Thursday, July 26, 2012 at 9:27 AM, Thomas Walther wrote:

> Hey everybody,
> I wanted to use the :layout option when calling render @variable (where 
> @variable is some ActiveRecord class instance with a corresponding 
> variables/_variable.html.erb partial view), but as far as I know, Rails 
> doesn't support this.
> 
> Here's a quick patch that allows to use the :layout function:
> 
> In partial_renderer.rb, add the following elsif block:
>   if !block && (layout = @options[:layout])
> layout = find_template(layout)
>   elsif !block && (layout = @locals[:layout])
> layout = find_template(layout)
>   end
> 
> 
> I attached a patch so you don't have to paste the two lines manually. I'm 
> looking forward to your comments, and would love to see this merged in Rails 
> 3.2.7, if possible.
> 
> Best,
> Thomas
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/rubyonrails-core/-/03a0JWgAXSEJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.
> 
> Attachments: 
> - rails_use_layout_with_render_variable.patch
> 


-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Feature request: allow formats with dot in resourceful routing, like '/users.xml.zip'

[Richard Schneeman]

You can already do something like this: 

In your routes:

  get "foo(.:format)(.:compression)" => "foo#index"


Then in your controller:

respond_to do |format|
  format.xml do
if params[:compression] == "zip"
  render ...
else
  render ...
end
  end
end



That being said a format of csv.zip is not `csv` since it is zipped and it is 
not purely `zip` since that gives no indication of the actual contents of the 
file. Having some kind of built in support for this would be expected by me if 
I was trying this out for the first time. 

Though if we were to add this feature I would expect it to be greedy so if you 
visit `foo.csv.zip` it would first look for a `csv.zip` format and if that was 
not found, it would look for a `csv` format as a backup. I haven't checked into 
the implementation implications. If it is simple to implement with no 
performance impact I would be :+1: otherwise it's not enough of a win as you 
can already do something like this (as above). 

If someone implements this cc/ me on the PR and I'll be happy to comment.

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Saturday, August 4, 2012 at 1:24 PM, Alexey wrote:

> On Saturday, August 4, 2012 8:09:16 PM UTC+2, Farski wrote:
> > I'm having a hard time thinking of use cases for this outside of zip or 
> > other archive/compression formats. In the case of user/1.xml.zip, likely 
> > you'd want an existing users_controller#show that returns xml to continue 
> > to operate as it currently does, but you'd want the result to be zipped. If 
> > there aren't lot (any?) of other situations where stack formatting is used, 
> > perhaps this would be better handled outside the scope of rails; let it 
> > keep doing what it's doing and maybe check the request URL for compression 
> > in rack on the way in and do the compression on the way out. If there are 
> > more general uses of this, it's still unlikely that you'd want a single 
> > controller action to handle both creating the xml and zipping it if 
> > necessary. 
> > 
> 
> 
> Maybe "csv.zip" or "pdf.zip" make better sense.
> I can of course define formats "csv_zip" and "pdf_zip" and use them, but i 
> would prefer "csv.zip" and "pdf.zip".
> 
> - Alexey. 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/rubyonrails-core/-/nvcKZqSESFAJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] Only-Except, not_nil?

[Richard Schneeman]

Not sure what you are talking about on number 1. For number 2 use  

Object#blank?

And 

Object#present? 

-- 
Richard Schneeman
http://heroku.com
@schneems

Sent from the road


On Wednesday, August 15, 2012 at 9:13 AM, kuraga wrote:

> Good day!
> 
> I can't find two tiny features in Rails that are necessary in my mind. I'm 
> sorry if I'm not right. Thanks for attention!
> 
> 1. Only-Except filter method. Such as in `before_filter`. This feature is 
> used really often. But I found no method for this in ActiveSupport...
> 
> 2. Is `Object#not_nil?` logical, isn't it? It will replace
> (not obj.nil?) ? something_main_and_important : 'no'
> to (beautiful)
> obj.not_nil? ? something_main_and_important : 'no'
> 
> Amn't I right?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/rubyonrails-core/-/_94RRSbD13gJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.
> 
> 


-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Re: [Rails-core] [error] rake db:create

[Richard Schneeman]

This list is for developers building Rails and discussion of Rails features, 
please ask this question on Stack Overflow or on Rails Talk google group: 
https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-talk.

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Thursday, August 16, 2012 at 7:39 AM, rails-guy wrote:

> i try run this command
> 
> but appear this error someone can help me?
> 
> see the error: http://paste.ideaslabs.com/show/IFSSXASQyM
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/rubyonrails-core/-/XRxX9RXunsYJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com 
> (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscr...@googlegroups.com 
> (mailto:rubyonrails-core+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.
> 
> 


-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.