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

[Chad Woolley]

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 <
avij...@gmail.com> 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.

Re: [Rails-core] Regarding JavaScript testing

[Chad Woolley]

Couple of data points:

We are moving to Elm for all our client code, so Karma or Mocha wouldn't
help us much, as we use elm-test.

Also, we have multiple bundles for different SPAs living within the same
Rails app, so I also wouldn't want to see the hardcoded assumption that all
tests have to be run as part of a single suite.

So, when considering a feature like this, it would be nice if it were
designed in some pluggable way that let you choose different test
frameworks and strategies, but still integrate well with built-in
webpack/etc support.

-- Chad

On Fri, Feb 24, 2017 at 10:22 AM, Rodrigo Rosenfeld Rosas <
rr.ro...@gmail.com> wrote:

> Great to hear that :) I'm looking forward to see some Mocha integration in
> Rails 5.2 ;)
>
> Cheers,
> Rodrigo.
>
>
> Em 23-02-2017 18:09, Rafael Mendonça França escreveu:
>
> Thank you for the feedback Rodrigo.
>
> I think it is worth to explore possibilities for JavaScript tests. I don’t
> see why Rails could not integrate better with the test ecosystem in the
> JavaScript community and I think it is a valuable direction to take. We
> didn’t included anything in this line in 5.1 because we didn’t have someone
> the champion this feature but we would be happy to have something for a
> next release.
>
> So, now that the ground base is set for better relationship with the
> JavaScript community it is just a matter of someone willing to explore how
> the test history will be.
>
> Looking forward to see what is coming on this front!
>
> On Thu, Feb 23, 2017 at 3:59 PM Rodrigo Rosenfeld Rosas <
> rr.ro...@gmail.com> wrote:
>
>> Hi, I was happy to read the new features for Rails 5.1 here:
>>
>> http://weblog.rubyonrails.org/2017/2/23/Rails-5-1-beta1/
>>
>> Specially as I have already been using webpack,npm and yarn for a while
>> (well, yarn just recently, of course) and I'm pretty happy with the
>> results. My main motivations were client-side performance improvements
>> and source-maps support, but there were many more reasons I chose
>> webpack as stated in the Goals section of this article:
>>
>> http://rosenfeld.herokuapp.com/en/articles/2016-02-29-
>> getting-an-spa-to-load-the-fastest-possible-way-and-how-
>> webpack-can-help-you
>>
>> As you can guess, I'm pretty happy with the direction Rails is taking as
>> an opinionated system (even though I'm moving towards a discrete system
>> I still see value in frameworks like Rails that are full featured and
>> opinionated, specially for new or small-sized applications).
>>
>> There's just one thing I found missing in this release notes and I don't
>> want to sound critical. It's the other way around. As I said, I'm pretty
>> happy with the direction Rails is taking, so this is a suggestion to
>> improve it further if someone is interested on working or discussing
>> this topic. I don't have time for that so if anyone is interested on
>> making it happen feel free to disregard this suggestion.
>>
>> I've been writing Single Page Applications since 2009 and even though
>> I've tried testing them through solutions such as Capybara (and similar
>> solutions for other languages such as Selenium) it doesn't really scale.
>> At some point I completely dropped Capybara because I found that those
>> specs were hardly executed since they were disabled by default because
>> they were simply too slow.
>>
>> I'm not saying adding Capybara to Rails was a bad idea. I do see value
>> in it and I'm happy Rails adds it by default. I'm just saying that I
>> feel like Rails isn't really aware of how SPA applications are developed
>> in the wide. While browser tests allow you to test JavaScript they are
>> not the only way. Using JavaScript test frameworks is what actually
>> enable SPA testing to succeed. Since Rails 5.1 is supporting SPA I think
>> it would be awesome if it also integrated some testing framework, maybe
>> on top of Karma.js, for fulfilling that purpose and stablishing good
>> practices just like it does for Ruby code.
>>
>> https://karma-runner.github.io/1.0/index.html
>>
>> Karma already exists for a while and looks like a mature solution to me,
>> and could be integrated to several JavaScript frameworks, and tests can
>> be run from the console, making it easier to integrate to CIs. Maybe
>> Rails could adopt some well known framework such as Jasmine or Mocha for
>> creating the stubs for new JS files.
>>
>> Well, this is just an idea. I use my own JS test framework in our
>> application, that's why I don't have a strong opinion on those test
>> runners mentioned above, but I had some experience with them and they
>> should be good enough for most applications.
>>
>> Once again, thanks a lot for this 5.1 release. It seems like Rails is
>> getting exciting again :)
>>
>> Best,
>>
>> 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 

[Rails-core] Re: Should you be able to override fixture_path for `rake db:fixtures:load`?

[Chad Woolley]

So, I finally realized I could accomplish this by setting
ENV['FIXTURES_PATH'], but it took me a while to realize this.

I submitted the following PR to make this "just work" for users of rspec +
fixtures.

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

Thanks,
-- Chad

On Thu, Nov 24, 2016 at 7:46 PM, Chad Woolley <thewoolley...@gmail.com>
wrote:

> I usually keep my fixtures in `spec/fixtures`.
>
> In order for `rake db:fixtures:load` to work, I've always had to symlink
> `test/fixtures` to point to `spec/fixtures`.
>
> I was trying to avoid this in a new Rails 5 project, but I could see any
> way to (even monkey patching `ActiveSupport::TestCase#fixture_path`
> didn't work).
>
> I realize rspec-rails allows you to set it via `config.fixture_path`, but
> this doesn't help when doing `db:fixtures:load`, which is dev env.
>
> Ideally, I'd like to do something like this in `config/development.rb`:
>
> ` config.active_record.fixture_path = "#{::Rails.root}/spec/fixtures"`
>
> Am I missing something obvious?  If not, what do you think about a patch
> to support the above line?
>
> Thanks,
> -- Chad
>

-- 
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.

[Rails-core] Should you be able to override fixture_path for `rake db:fixtures:load`?

[Chad Woolley]

I usually keep my fixtures in `spec/fixtures`.

In order for `rake db:fixtures:load` to work, I've always had to symlink
`test/fixtures` to point to `spec/fixtures`.

I was trying to avoid this in a new Rails 5 project, but I could see any
way to (even monkey patching `ActiveSupport::TestCase#fixture_path` didn't
work).

I realize rspec-rails allows you to set it via `config.fixture_path`, but
this doesn't help when doing `db:fixtures:load`, which is dev env.

Ideally, I'd like to do something like this in `config/development.rb`:

` config.active_record.fixture_path = "#{::Rails.root}/spec/fixtures"`

Am I missing something obvious?  If not, what do you think about a patch to
support the above line?

Thanks,
-- Chad

-- 
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] [Change Request - warning, controversial] Rename "belongs_to" to what it actually is

[Chad Woolley]

I agree.  I've been doing Rails for 10 years (and databases for going on
25)), and "belongs_to" has always been a cognitive blocker for me.

I wouldn't do away with "belongs_to", but making "has_key_for" aliases
sounds like a great idea, for people who want to write their code that way.

But, most likely this should be in a gem, probably not a lot of chance of
it making it into official Rails (I may be wrong, but I doubt it).

-- Chad

On Sat, Sep 24, 2016 at 2:01 AM, Richard McSharry 
wrote:

> Any framework that has convention over configuration has the the problem
> that newcomers have to learn the conventions.
>
> I think that one of the biggest stumbling blocks to new users of Rails is
> the way associations are described. Just look at the number of questions on
> this on SO. M-1 and 1-M and even M-1-M are really quite simple concepts,
> but the Rails naming of these relationships just serves to confuse.
>
> Here is a good definition that kind of gets at the root cause:
>
> > belongs_to and has_many do not describe either the ownership or the
> scope or the life cycles for the objects they relate. They may give that
> impression because 'belongs' implies ownership and responsibility, but they
> merely describe the references (the keys) between the objects.
>
> Even the [documentation](http://api.rubyonrails.org/classes/
> ActiveRecord/Associations/ClassMethods.html) states:
>
> > Associations are a set of macro-like class methods for tying objects
> together through foreign keys
>
> In that case isn't it easier if we called a spade a spade, and not a
> shovel? ;)
>
> Surely all the confusion would be cleared up by renaming `belongs_to`?
> This would lower the barrier to learning Rails, resulting in less mistakes,
> less time wasted asking and answering on SO, less discussions, less blogs
> -> overall a HUGE time saver for the community **over the long term**
> (against which you have to weigh the short-term pain of adopting the change
> of course).
>
> **Example 1 - one-to-one**
> ```ruby
> class Employee
>   has_one :salary
> end
> class Salary
>   has_key_for :employee
> end
> ```
>
> **Example 2 - one-to-many**
> ```ruby
> class Manager
>   has_many :employees
> end
> class Employee < ActiveRecord::Base
>   has_key_for :manager
> end
> ```
>
> **Example 3- M-1-M**
> ```ruby
> class Project
>   has_many :assignments
>   has_many :employees, through: :assignments
> end
>
> class Employee
>   has_many :assignments
>   has_many :projects, through: :assignments
> end
>
> class Assignment
>   has_key_for :employee
>   has_key_for :project
> end
> ```
>
> **Example 4 - Polymorphic**
> ```ruby
> class Address
>   has_key_for :addressable, :polymorphic => true
> end
>
> class Person
>   has_one :address, as: :addressable
> end
> ```
>
> I think this just leaves "has_and_belongs_to_many" which personally I have
> always hated. :)  Why not just use "has_many"? Since when you have an
> explicit join table for M-M, you use "through"...so if there is no
> "through" specified, we know it is a HABTM.
>
>
> --
> 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.

[Rails-core] Is there any reason #before_commit isn't documented?

[Chad Woolley]

Hi,

As you can see here:

https://github.com/rails/rails/blob/5-0-0/activerecord/lib/active_record/transactions.rb#L214

...there's no docs, and it's not mentioned in any of the guides.

Is this intentional, or an oversight?

Thanks,
-- Chad

-- 
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] [Proposal] [Feature Request] Make new rails apps rubocop compliant

[Chad Woolley]

That was one thought I had.  That would be the easiest first pass at a gem
that made the generators "compliant" - just make it add a rubocop config
that allowed the default generated rails code to pass.

On Mon, Jul 18, 2016 at 6:16 AM, Greg Navis  wrote:

> We can invert the problem and make rubocop support multiple styles. I
> think this would be a better idea community-wide as it'd enable more
> projects to use rubocop without having to reformat a significant part of
> their code bases.
>
> I'm curious what 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 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] [Proposal] [Feature Request] Make new rails apps rubocop compliant

[Chad Woolley]

Yes, I now see the points against including it are valid, but it would be
good to see a gem that overrides the generators to generate compliant apps.

On Sat, Jul 16, 2016 at 5:49 AM, Andrew Kaspick  wrote:

> Why can't a gem be created that contains  rubocop compliant generators and
> that is used? I see this as a slippery and unnecessary slope to be included
> directly in rails imo.
>
> On Jul 16, 2016 4:24 AM, "Xavier Noria"  wrote:
>
>> We are talking here about whether to add RuboCop by default to newly
>> generated apps. This would then extend to a discussion about the
>> configuration, whether to integrate with the test suite, etc.
>>
>> The answer, at least my answer, is that my experience says this is not
>> something I want to add as a dependency to new apps. And Rails should not
>> have as a goal to generate code that passes any particular set of RuboCop
>> rules, that would be sticking to one particular set of rules, and precisely
>> the only rules we have to follow are our own.
>>
>> In my view Rails has no business enforcing or pushing RuboCop. No saying
>> some people may love it, some companies may have it as a requirement, etc.
>> Not a statement about RuboCop in particular. I am talking from the point of
>> view of a maintainer that weights the impact on all the user base and the
>> derivations and believes it is not a good idea.
>>
>> Each project is free to depend on it, and if their chosen configuration
>> needs editing generated files... well, that's your choice!
>>
>> --
>> 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] Re: [Proposal] [Feature Request] Make new rails apps rubocop compliant

[Chad Woolley]

Re: "I don't use RuboCop in personal projects. In my consultant work some
clients do, some don't. Those that do have different configuration files
because no two Ruby teams have the same preferences"

This is a red herring.  Most of the Rubocop failures against the standard
Rubocop config are due to fairly non-controversial formatting stuff, like
using single quotes for non-interpolated strings.  Of course I have a
custom config like everyone else, but only for things I can't comply with,
e.g. some obscure formatting where I can't convince my editor's autoformat
to comply with.  But I've never overridden the rules that are violated in a
generated rails app.

If an existing person or team DOES use Rubocop, AND is in the habit of
generating new Rails projects, AND they somehow have a reason to change
these standard config rules, then it's completely reasonable to expect them
to fix it after generation.

But that should be a pretty rare case, and no reason to inflict the need to
edit every generated rails project on everyone else who DOES stick to a
mostly standard Rubocop config.

Thanks,
-- Chad

On Thu, Jul 14, 2016 at 1:19 AM, Gaoyong Pan  wrote:

> I like this idea. It would be nice newly generated rails app could pass
> the rubocop checking with its default configuration. I also suggest adding
> two more options to .rubocop.yml,
> TargetRubyVersion and Rails/Enabled: true. Together this makes them
> default configuration for new rails app rubocop config. Rails app
> developers can customize them per their own preferences later. In this way,
> everybody has a very good base to start on.
>
>
> On Monday, July 11, 2016 at 11:05:36 PM UTC+8, Amin Shah Gilani wrote:
>>
>> Initially raised on Github
>> :
>>
>> I understand that the project disallows cosmetic changes but:
>>
>>- Some projects follow stylistic rules (even rails does)
>>- Rubocop is quick to set up, and configure (even rails uses it)
>>- Rubocop is modular, you can enable, disable or even configure cops
>>- The best way to let devs tailor their lint compliance is by
>>generating code compliant with all the cops
>>- Currently, for initial generations, additional work is required in
>>new rails project to ensure lint compliance.
>>
>> If I could take the time to ensure rails new app generates a rubocop
>> compliant skeleton app, will the maintainers consider merging the code?
>>
>> This will essentially reduce the time it takes to scaffold a project and
>> would be a backwards compatible feature.
>>
>>
>> This could be extended to make sure all the code made by `rails generate`
>> is also lint compliant.
>>
>> --
> 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] [Feature Request] Force test schema to be up to date when running tests

[Chad Woolley]

Ah. My problems may be that I don't generate that test helper by default,
and thus the call never makes it into my rspec setup.

Is this your issue Ryan?  If so maybe you can confirm that the rspec
generator properly adds this support, and if not, add it.

-- Chad

El martes, 28 de junio de 2016, Rafael Mendonça França <
rafaelmfra...@gmail.com> escribió:

> Automatic test schema maintainance is a feature of Rails since 4.1
> http://guides.rubyonrails.org/4_1_release_notes.html#railties-notable-changes
>
> On Tue, Jun 28, 2016 at 5:32 PM Chad Woolley <thewoolley...@gmail.com
> <javascript:_e(%7B%7D,'cvml','thewoolley...@gmail.com');>> wrote:
>
>> +1, this is one of a few things that doesn't "work out of the box" for
>> databases in real-world usage.  I always end up having some version of a
>> custom "db:prepare" which does extra necessary things for my apps.
>>
>> FYI, this thread is somewhat related, in that it's also about confusion
>> about the behavior of the 'test' environment (and also unaddressed):
>> https://groups.google.com/forum/#!searchin/rubyonrails-core/environment$20agnostic/rubyonrails-core/kqKoJHcQu9U/xx9J2BLOBgAJ
>>
>> -- Chad
>>
>> On Tue, Jun 28, 2016 at 11:26 AM, Ryan Jones <
>> ryan.michael.jo...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','ryan.michael.jo...@gmail.com');>> wrote:
>>
>>> Every so often I'll run a test suite and it will have a large number of
>>> failures. After debugging it's normally something as simple as the test
>>> schema being out of date. I then run bin/rake db:test:prepare and
>>> everything is fine.
>>>
>>> If I run my development environment and my schema is out of date, it
>>> throws an error and forces me to run bin/rake db:migrate. Should we be
>>> doing the same thing when we're running tests? Or at the very least maybe
>>> throwing a warning that the test schema is 'out of date'?
>>>
>>> On one of the first apps I was building (a few years ago) I remember
>>> spending a few hours tracking down why my test was failing. I was new to
>>> 'TDD' and I thought it was something I was doing wrong. I called a friend
>>> and he asked 'did you run db:test:prepare?' and that solved my problem. I
>>> don't run into this issue as much anymore, but I think it might prevent
>>> some frustration by new rails users.
>>>
>>> I'm trying to think of why we wouldn't be doing this and my mind is
>>> coming up blank. Let me know your thoughts!
>>>
>>> Thanks,
>>> Ryan
>>>
>>>
>>> --
>>> 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
>>> <javascript:_e(%7B%7D,'cvml','rubyonrails-core%2bunsubscr...@googlegroups.com');>
>>> .
>>> To post to this group, send email to rubyonrails-core@googlegroups.com
>>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','rubyonrails-core%2bunsubscr...@googlegroups.com');>
>> .
>> To post to this group, send email to rubyonrails-core@googlegroups.com
>> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','rubyonrails-core%2bunsubscr...@googlegroups.com');>
> .
> To post to this group, send email to rubyonrails-core@googlegroups.com
> <javascript:_e(%7B%7D,'cvml','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] [Feature Request] Force test schema to be up to date when running tests

[Chad Woolley]

+1, this is one of a few things that doesn't "work out of the box" for
databases in real-world usage.  I always end up having some version of a
custom "db:prepare" which does extra necessary things for my apps.

FYI, this thread is somewhat related, in that it's also about confusion
about the behavior of the 'test' environment (and also unaddressed):
https://groups.google.com/forum/#!searchin/rubyonrails-core/environment$20agnostic/rubyonrails-core/kqKoJHcQu9U/xx9J2BLOBgAJ

-- Chad

On Tue, Jun 28, 2016 at 11:26 AM, Ryan Jones 
wrote:

> Every so often I'll run a test suite and it will have a large number of
> failures. After debugging it's normally something as simple as the test
> schema being out of date. I then run bin/rake db:test:prepare and
> everything is fine.
>
> If I run my development environment and my schema is out of date, it
> throws an error and forces me to run bin/rake db:migrate. Should we be
> doing the same thing when we're running tests? Or at the very least maybe
> throwing a warning that the test schema is 'out of date'?
>
> On one of the first apps I was building (a few years ago) I remember
> spending a few hours tracking down why my test was failing. I was new to
> 'TDD' and I thought it was something I was doing wrong. I called a friend
> and he asked 'did you run db:test:prepare?' and that solved my problem. I
> don't run into this issue as much anymore, but I think it might prevent
> some frustration by new rails users.
>
> I'm trying to think of why we wouldn't be doing this and my mind is coming
> up blank. Let me know your thoughts!
>
> Thanks,
> Ryan
>
>
> --
> 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] An environment agnostic Rails application

[Chad Woolley]

+1 on at least discussing what can be done about this.

The dev-env-switching-to-test thing has caused me lots of headaches over
the years, including in areas other than the db handling mentioned here -
the most recent coincidentally being today.

Another way to think of the problem is that on local dev environments, you
default to "development" whenever you run rake or start up the app, but
it's normal practice for CI environments to hardcode their container
environments to "test".

That sets up a built-in opportunity for problems due to different behavior
on CI than on local dev boxes - especially for any config value that is
different between dev/test env, but is persisted (e.g. setting environment
variables) between the Rakefile invocation and the test helper switching
the ENV to test.

When you get more complex apps and situations, e.g. Procfiles for various
environments which start multiple processes, and nested scripts/rake
tasks/test suites, especially ones like cucumber/integration that need to
precompile assets on the fly but maybe not start up services, it can be
hard to sort out what config values came from where, and why.

The 12-factor app guidelines (http://12factor.net/config) are correct in
saying that you should try to be environment agnostic, but also valid
criticism of its omissions/vagueness/hand-waviness in this area:
http://cloudfactor.io/factor/three/

I'm not sure what the fix is, but in general moving away from fixed
"environments" to more granular config values seems good.

This could look something like:
* Deprecating the use of Rails.env and RAILS_ENV
* Assuming that development is no different than any other non-test
environment, move all config settings from generated development.rb to be
conditional/commented entries in application.rb, and allow/require people
to override them as appropriate for their current environment.  E.g.
* Likewise requiring test- specific code or libraries that currently rely
on setting/checking test environment to instead directly read or set
granular Rails configuration values.

For example, people or libraries could set env vars (just examples, but you
get the idea) RAILS_EAGER_LOAD or RAILS_ACTION_CONTROLLER_PERFORM_CACHING
before app startup to override any defaults in application.rb, and
(admittedly hard, alotofwork, or impossible in some cases) libraries could
also override values on the fly after initialization as appropriate.

That would be a big change with lots of ripples, but definitely a move in
the right direction in an increasingly cloud-native 12-factor-ish world.

Thanks,
-- Chad

On Sun, Jan 10, 2016 at 10:50 PM, Vladyslav Hesal  wrote:

> Although this thread started to me from the single bug (unexpected
> "feature") I want to address the issue more widely.
>
> There is a methodology (approach) to develop portable, scalable and
> maintainable web-services called "The Twelve-Factor App". On of it's
> "factors" is the environment agnostic approach to configuration (although
> it is not called so explicitly in the document, I think this two words
> expresses the sense): http://12factor.net/config
>
> It is almost possible to be environment agnostic with Rails. But there are
> some issues.
> The issue I mentioned is this:
> https://github.com/rails/rails/blob/3ba176d0a07728e9505609967b518d85129bff24/activerecord/lib/active_record/tasks/database_tasks.rb#L282
> And here is some consequences:
> https://github.com/laserlemon/figaro/issues/225
>
> Rails tries to be in two environments in a single run. It looks bad. It's
> surprising. It prevents effective environment management (homogeneous
> config applicable to any environment).
>
> What do you about environment agnostic approach and about it implicit
> support by Rails (e.g. everything works if you doesn't mention any
> environment enywhere in your project)?
>
> --
> 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] Re: Scaffold Generator Woes

[Chad Woolley]

Hi Duta,

I think this ship sailed about four years ago, and in general it's not good
mailing list etiquette to reply to very old threads.

But you were nice and well intentioned, so I moderated this through.  Have
a nice year too.

-- Chad

On Sun, Jan 3, 2016 at 8:16 PM, Duta Ksp  wrote:

> Hello Friends,
>
> I am, Nyoman, a new bie from Bali, Indonesia.
>
> For me, nothing is wrong to have scaffold. Why?
>
> 1. By having the scaffold, I have a 'mirror' where I can see the flow of
> how the framework is working.
> 2. When I try to do the same manually, I can easily see my mistakes of
> what made my app error.
>
> So now it depends on the peoples themselves. If they are serious to learn
> and understand about the framework, then they will dig it into the deepest
> possible.
> If they want just to have a fun, then let they do it.
> You know, sometimes, people will learn further because it the beginning
> the framework gave him a good impression. Just like a man met good and
> beautiful girl...he..
>
> This is based on my personal learning experience, as what I am doing right
> now...
>
> I wish every one of us to have good time during this year and have good
> learning of ROR...
>
> Good luck..
>
>
>
>
> On Friday, March 9, 2012 at 1:30:39 AM UTC+7, Ryan Bigg wrote:
>>
>> Hello friends,
>>
>> It's been fun having the scaffold generator exist as a part of Rails
>> since The Beginning Of Time, but I think its time is now up. It has been
>> abused time and time again, and most often leads to confusion amongst
>> people who are new to Rails.
>>
>> This confusion happens when a user first generates a scaffold and sees
>> that it is good. They can perform CRUD actions on a resource using one
>> command?! WOW!
>>
>> Then they try to modify the scaffold and run into problems. First of all:
>> how do they add an action to the controller? Do they need to run another
>> command? How do they then define a route for that action? A template?
>>
>> If they were to *not* use the scaffold generator from the beginning, I
>> believe they would have less confusion. They would know how to add another
>> action to the controller and a template for that action because this would
>> be how they're doing it from the start. Learning how to define a route for
>> a new action in the controller is something easily learnable by reading the
>> routing guide.
>>
>> I think that we can fix this problem in one of two ways, the latter more
>> extreme than the first one.
>>
>> The first way is that we *completely change the Getting Started Guide to
>> simply *mention* the scaffold generator*, but then show people the
>> "correct" way of generating a controller (rails g controller) and adding
>> actions to it one by one, adding a model as its needed, and using similar
>> practices to how you would do it in the "real world".
>>
>> The second way, and sorry if this sounds a little extreme, is to *completely
>> remove the scaffold generator from the core of Rails* itself. This means
>> that there wouldn't even be the option to run the scaffold generator for
>> newbies. You could then extract this out into a gem if you *really* wanted
>> people to have the option for it. However, if this path was taken it should
>> be made clear that this is not the "sanctioned" way to create controllers.
>>
>> 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 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] Re: Scaffold Generator Woes

[Chad Woolley]

And apparently google groups no longer provides the 'reject with comment'
moderation option, which is why I handled like this.  If any other group
mods know how to you can still do that, please let me know...

-- Chad

On Sun, Jan 3, 2016 at 10:19 PM, Chad Woolley <thewoolley...@gmail.com>
wrote:

> Hi Duta,
>
> I think this ship sailed about four years ago, and in general it's not
> good mailing list etiquette to reply to very old threads.
>
> But you were nice and well intentioned, so I moderated this through.  Have
> a nice year too.
>
> -- Chad
>
> On Sun, Jan 3, 2016 at 8:16 PM, Duta Ksp <duta...@gmail.com> wrote:
>
>> Hello Friends,
>>
>> I am, Nyoman, a new bie from Bali, Indonesia.
>>
>> For me, nothing is wrong to have scaffold. Why?
>>
>> 1. By having the scaffold, I have a 'mirror' where I can see the flow of
>> how the framework is working.
>> 2. When I try to do the same manually, I can easily see my mistakes of
>> what made my app error.
>>
>> So now it depends on the peoples themselves. If they are serious to learn
>> and understand about the framework, then they will dig it into the deepest
>> possible.
>> If they want just to have a fun, then let they do it.
>> You know, sometimes, people will learn further because it the beginning
>> the framework gave him a good impression. Just like a man met good and
>> beautiful girl...he..
>>
>> This is based on my personal learning experience, as what I am doing
>> right now...
>>
>> I wish every one of us to have good time during this year and have good
>> learning of ROR...
>>
>> Good luck..
>>
>>
>>
>>
>> On Friday, March 9, 2012 at 1:30:39 AM UTC+7, Ryan Bigg wrote:
>>>
>>> Hello friends,
>>>
>>> It's been fun having the scaffold generator exist as a part of Rails
>>> since The Beginning Of Time, but I think its time is now up. It has been
>>> abused time and time again, and most often leads to confusion amongst
>>> people who are new to Rails.
>>>
>>> This confusion happens when a user first generates a scaffold and sees
>>> that it is good. They can perform CRUD actions on a resource using one
>>> command?! WOW!
>>>
>>> Then they try to modify the scaffold and run into problems. First of
>>> all: how do they add an action to the controller? Do they need to run
>>> another command? How do they then define a route for that action? A
>>> template?
>>>
>>> If they were to *not* use the scaffold generator from the beginning, I
>>> believe they would have less confusion. They would know how to add another
>>> action to the controller and a template for that action because this would
>>> be how they're doing it from the start. Learning how to define a route for
>>> a new action in the controller is something easily learnable by reading the
>>> routing guide.
>>>
>>> I think that we can fix this problem in one of two ways, the latter more
>>> extreme than the first one.
>>>
>>> The first way is that we *completely change the Getting Started Guide
>>> to simply *mention* the scaffold generator*, but then show people the
>>> "correct" way of generating a controller (rails g controller) and adding
>>> actions to it one by one, adding a model as its needed, and using similar
>>> practices to how you would do it in the "real world".
>>>
>>> The second way, and sorry if this sounds a little extreme, is to *completely
>>> remove the scaffold generator from the core of Rails* itself. This
>>> means that there wouldn't even be the option to run the scaffold generator
>>> for newbies. You could then extract this out into a gem if you *really*
>>> wanted people to have the option for it. However, if this path was taken it
>>> should be made clear that this is not the "sanctioned" way to create
>>> controllers.
>>>
>>> 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 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] Tuyển Ruby, Perl, Python

[Chad Woolley]

Sorry too quick on the moderate button :(

On Monday, August 17, 2015, Nhung Hoang hoangnhung.h...@gmail.com wrote:

 Bên mình đang cần tuyển 3 vị trí Ruby, Perl, Python
 Quyền lợi :
 - Mức lương: Từ 400$ trở lên. Thỏa thuận theo trình độ.
 - Cơ hội tiếp xúc, làm việc trực tiếp với khách hàng người Anh và Mỹ.
 - Cơ hội công tác tại nước ngoài
 - Nơi làm việc: Hà Nội
 1. Perl
 Số lượng: 3
 Yêu cầu:
 - Có kinh nghiệm lập trình Perl ( tối thiểu 6 tháng và sẽ được đào tạo
 thêm sau khi trúng tuyển; Thành thạo MySQL, Git
 - Am hiểu về HTML5, Javascript

 2. Ruby On Rails
 Số lượng: 2
 Yêu cầu:
 - Có 1 năm kinh nghiệm lập trình Ruby, có kiến thức tốt về Database
 - Thành thạo HTML/CSS/JavaScrips, jQuery

 3. Python
 Số lượng: 2
 Yêu cầu:
 - Thành thạo lập trình Python và Standard Library Python
 - Có tư duy logic tốt, có khả năng tìm giải pháp và xử lý bài toán nhanh
 - Có kinh nghiệm về Ruby là một lợi thế

 Các bạn quan tâm có thể gửi Cv về h...@dcv.vn
 javascript:_e(%7B%7D,'cvml','h...@dcv.vn'); hoặc liên hệ 04.629 7

 --
 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
 javascript:_e(%7B%7D,'cvml','rubyonrails-core%2bunsubscr...@googlegroups.com');
 .
 To post to this group, send email to rubyonrails-core@googlegroups.com
 javascript:_e(%7B%7D,'cvml','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: Schema.rb table and column order

[Chad Woolley]

+1 on allowing control over formatting, there's been many times over the
years on various projects when schema.rb has flapped for spurious reasons,
it would have been good to have had control over it.

-- Chad

On Tue, May 19, 2015 at 6:46 AM, Randy Parker randy.j.par...@gmail.com
wrote:

 +1 on a DIY format.  And I wouldn't justify it strictly on source control:
 I'd like it for other reasons too.
 Maybe a config/schema_format.rb ?

 On Tue, May 19, 2015 at 9:19 AM, Kevin Deisz kevin.de...@gmail.com
 wrote:

 With all of these threads about schema.rb format - would it just be
 easier to allow you to specify your own formatter? Have something that
 responds to format_for(table, columns) or something to that effect? The
 issue here is that everyone is going to want something different from that
 file.

 On Tue, May 19, 2015 at 8:16 AM, Matias Korhonen korhonen.m...@gmail.com
  wrote:

 How about some sort of normalize_schema option that could be turned off
 if required? I can't imagine that all that many developers are taking
 advantage of specific column ordering. For one thing, PostgreSQL
 doesn't allow you to reorder columns
 https://wiki.postgresql.org/wiki/Alter_column_position (without going
 to a whole lot of trouble).

 The constant non-meaningful changes to the schema.rb file seem like a
 distraction that end up masking what might be important changes.

 Anyone on the Rails Core team want to chime in whether a PR like this
 might be accepted?


 — Matias


 On Saturday, 17 January 2015 12:01:52 UTC+2, vesan wrote:

 When multiple people are working on a single Rails codebase and they
 add migrations with new columns (or tables) and run the migrations in
 different order there is a problem with schema.rb. After this every time
 migrations are run the columns swap places if the previous version of the
 schema.rb file has been commited by the other developer who did run the
 migrations in different order.

 Because of this the developers have to discard the lines where columns
 swap places to keep the source control clean. Could this be fixed by
 putting the tables and columns on schema.rb in alphabetical order? Or are
 people relying on the database's order of the tables and columns?

 It seems you could implement it by sticking `.sort_by(:name)` to
 https://github.com/rails/rails/blob/3f96b6973b82ad17e443dd1d21be05996fb6fbf0/activerecord/lib/active_record/schema_dumper.rb#L134

 – Vesa Vänskä
 ve...@vesavanska.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 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.




 --
 *Kevin D. Deisz*
 *TrialNetworks* - part of DrugDev
 Software Developer
 383 Elliot Street, Suite G
 Newton, MA 02464
 +1 617.952.4071 x134 (office)
 +1 703.615.0396 (mobile)
 kde...@trialnetworks.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 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.




 --
 http://mobiledyne.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 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] Web Framework Comparison Benchmarks

[Chad Woolley]

Thanks for sharing.

Not directly related to rails core, but kind of interesting so I moderated
it through...

-- Chad

On Sun, Apr 5, 2015 at 5:50 AM, Darren Daly archery...@gmail.com wrote:

 Hi all,

 For my final year project I have been comparing web frameworks to get
 performance benchmarks that others can then use when deciding upon a web
 framework. The idea is simple; first you build the same simple applications
 in another web framework and then use the tests that I provide. You then
 compare your results against my benchmarks to help in making a decision on
 your chosen web framework. I started out with 3 web frameworks; Ruby on
 Rails, Chicago Boss and Flask. I chose Rails because of its status as the
 go to web framework, Boss because of its fast growing popularity and
 because of its Erlang implementation and finally Flask because it is very
 different to the first two in that it is a bare bones web
 micro-framework. The findings are interesting and can be seen here:
 http://web-framework-comparison.blogspot.ie/2015/04/benchmarks-i-am-final-year-student-in.html

 Thanks for taking the time to read this and hopefully it might be of some
 benefit.

 Darren Daly.

 --
 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] Rails coding convention for cloud.

[Chad Woolley]

This list is for discussion of internal development of Rails itself, not
for general questions on Rails development - see the rubyonrails-talk
list for that.

Having said that, see http://12factor.net/ for more info on your question.

Good luck,
-- Chad

On Mon, Mar 16, 2015 at 10:58 PM, Pradeep S pradi.s...@gmail.com wrote:

 Is there any specific coding standard for developing rails application to
 cloud.

 --
 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] Moderation backlog

[Chad Woolley]

Sorry, there were some messages awaiting moderation from 2/24, but I didn't
see any group admin notifications until today.  Maybe something fell
through the Google-cracks...  I'll try to check manually for a while in
case it happens again.

--Chad

-- 
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] ROR Newby

[Chad Woolley]

Hi Nicole,

Also, you can check a group's About to find out the rules for posting, if
the group admins have specified any.  E.g.:

https://groups.google.com/forum/#!aboutgroup/rubyonrails-core

Good luck!

-- Chad



On Fri, Oct 24, 2014 at 9:19 AM, Nicolas Cavigneaux n...@bounga.org wrote:


 Le 24 oct. 2014 à 17:42, Nicole Morales nmorale...@gmail.com a écrit :

  Hi all
  Im trying to track conflicts in Event Dates. So Im basically checking if
 event dates overlap
  This is the code my boss helped me with however its showing records as
 overlapping when there is no conflict. Any ideas?
 

 Hi Nicole,

 you're not on the mailing list dedicated to help people with using RoR or
 with their code. This mailing list is about Rails core development,
 enhancing it, not using it.

 You should ask your question on
 https://groups.google.com/forum/#!forum/rubyonrails-talk.
 --
 Nicolas Cavigneaux
 http://www.bounga.org
 http://www.cavigneaux.net

 --
 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] Failed TravisCI builds because test run exceeds 50 minutes

[Chad Woolley]

Sounds like a great idea, just make sure it doesn't break the build locally.

For bonus points make the number of parallel builds configurable.
For extra bonus points, make the parallelization work locally as well as
Travis.

-- Chad

On Wed, Oct 22, 2014 at 9:22 AM, Tu Hoang saidre...@gmail.com wrote:

 I raised this issue via Github (here
 https://github.com/rails/rails/issues/17358) and got informed by
 rafaelfranca that it's better to do this via the mailing list. Sorry,
 Rafael; and thank you as well :-).

 A few https://travis-ci.org/rails/rails/builds/38633209 builds
 https://travis-ci.org/rails/rails/builds/38715540 have been marked as
 Error because (most of the time) their `GEM=railties, ruby=1.9.3` test
 suites exceed 50 minutes.

 My suggestion is we split this particular test suite into two parallel
 builds (by giving each build a number of test folders
 http://docs.travis-ci.com/user/speeding-up-the-build/) so that
 hopefully each build runs for about 25 minutes, which goes along with its
 `ruby=2.0.0`, `ruby=2.1`, `ruby=ruby-head` counterparts.

 I'm still keen on this suggestion though. It:

 - reduces build time
 - prevents repetitive (and expensive) builds, caused by slow Rubygems or
 Bundler API

 WDYT?

 --
 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: reality of fixtures as a default?

[Chad Woolley]

This list is for rails core discussion, so this question is probably better
suited for rubyonrails-talk.

But I'll answer anyway (it would be great to get something like
fixture_builder into Rails someday, none of the alternatives are good IMO):

I use factories + fixtures via https://github.com/rdy/fixture_builder

As for mutually exclusive datasets, depending on your app, maybe they can
co-exist in the same fixture set.  E.g., have them be separate accounts
or projects.

If not, you can pass flags into fixture_builder to tell it which set of
fixtures to build.

-- Chad


On Wed, Aug 6, 2014 at 5:16 AM, Pruss Wan pruss...@gmail.com wrote:

 Hi,

 Is there anybody out there who is really using fixtures exclusively? And
 if so, how do you deal with scenarios when there is a need for multiple
 fixture sets? (datasets that are mutually exclusive) Or is that the part
 where the more popular factories come in?

 For those who are wondering why I even bother, I am in a situation where I
 have plenty of real data to test and debug with, and if these could be
 extracted to fixtures which are maintainable, there might be some value in
 this approach for integration tests.


 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/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: make capitalization optional in *humanize*

[Chad Woolley]

+1, I was just wishing for this last week :)


On Wed, Nov 6, 2013 at 10:45 AM, Xavier Noria f...@hashref.com wrote:

 Sounds good to me.

 The documentation would say if +capitalize+ is true, with true in
 regular font. Please update the AS guide as well if you are so kind.

  --
 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 4 Logger #silence method

[Chad Woolley]

#squelch  ???


On Mon, May 6, 2013 at 10:55 PM, laise a.y.chernen...@gmail.com wrote:

 Issue:

 It breaks compatibility with old good Log4r and default ::Logger. I found
 that issue today while trying to setup custom logger. The cause is the new
 ActiveSupport::Logger#silence method, which is called by ActiveRecord
 pending migration checker.

 Another issue is that the Kernel has its own #silence method which is
 called instead of ActiveSupport::Logger#silence (when ::Logger used). Seem
 like names conflict.

  --
 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] AOP in Rails

[Chad Woolley]

Can you give an example of how you would implement this?


On Fri, Apr 5, 2013 at 11:19 PM, Bakhtiyor Homidov bakhtiyo...@gmail.comwrote:

 Why doesn't Rails use aspect-oriented programming? e.g. for loggers

 --
 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] Digest for rubyonrails-core@googlegroups.com - 4 Messages in 3 Topics

[Chad Woolley]

Removed from group...

-- Chad

On Fri, Dec 14, 2012 at 5:01 AM, Peta Ward peterwardhowl...@gmail.com wrote:
 This is a delivery failure notification message indicating that
 an email you sent could not be delivered. The problem appears to be :
 -- Recipient email server rejected the message

 This condition occurred after 1 attempt(s) to deliver over
 a period of 0 hour(s).

 If you sent the email to multiple recipients, you will receive one
 of these messages for each one which failed delivery,  otherwise
 they have been sent.

 On 14 Dec 2012, at 11:59, rubyonrails-core@googlegroups.com wrote:

   Today's Topic Summary
 Group: http://groups.google.com/group/rubyonrails-core/topics
   •   Proposal: ActionController class methods, all procs get 
 evaluated [2 Updates]
   •   Should render collection: @items have a cache option so that 
 read_multi can be utilized? [1 Update]
   •   Digest for rubyonrails-core@googlegroups.com - 1 Message in 1 
 Topic [1 Update]
  Proposal: ActionController class methods, all procs get evaluated
   •   Scott Carleton carleton.sc...@gmail.com Dec 13 09:35AM -0800
   •
   •   Specifically looking at action_cache in Rails.3.2 stable right 
 now.
   •
   •   It currently will evaluate procs given to the layout or 
 cache_path as can beseen 
 herehttps://github.com/rails/rails/blob/3-2-stable/actionpack/lib/action_controller/caching/actions.rb#L135.
   •
   •
   •   I'm working on a library where I'd like to tag my caches so 
 that I can
   •   expire sets of keys easily. It would appear that something 
 such as
   •
   •   caches_action :show, tag: Proc.new { post_#{params[:id]} }
   •
   •   would evaluate to the tag to post_1, post_2 etc but it 
 doesn't. It
   •   wouldn't take much to modify the filter method linked above to 
 evaluate
   •   all procs passed in as options. I'm going to make a pull 
 request unless
   •   there are any objections.
   •
   •   Rafael Mendonça França rafaelmfra...@gmail.com Dec 13 
 06:28PM -0300
   •
   •   Action cache was extracted from Rails and it is not part of 
 the framework
   •   anymore.
   •
   •   Rafael Mendonça França
   •   http://twitter.com/rafaelfranca
   •   https://github.com/rafaelfranca
   •
   •
   •
   •
  Should render collection: @items have a cache option so that read_multi can 
 be utilized?
   •   nate n...@inventric.com Dec 13 08:21AM -0800
   •
   •   I released a gem yesterday
   •
   •   https://github.com/n8/multi_fetch_fragments
   •
   •   that adds this syntax on rendering a collection of partials:
   •
   •   %= render partial: 'item', collection: @items, cache: true %
   •
   •
   •   And then the gem uses Rails read_multi to fetch any cached 
 fragments of
   •   this partial. It can be a pretty big speed boost instead of 
 fetching from
   •   Memcached sequentially. One guy saw a 93% improvement on an 
 action of his
   •   that was simply rendering out 25 items.
   •
   •   Some folks have been asking me to post to this list to see if 
 this is
   •   something that I should write a pull request for against Rails 
 to become a
   •   standard feature?
   •
   •   -Nate
   •
  Digest for rubyonrails-core@googlegroups.com - 1 Message in 1 Topic
   •   Peta Ward peterwardhowl...@gmail.com Dec 13 12:45PM
   •
   •   This is a delivery failure notification message indicating that
   •   an email you sent could not be delivered. The problem appears 
 to be :
   •   -- Recipient email server rejected the message
   •
   •   This condition occurred after 1 attempt(s) to deliver over
   •   a period of 0 hour(s).
   •
   •   If you sent the email to multiple recipients, you will receive 
 one
   •   of these messages for each one which failed delivery, otherwise
   •   they have been sent.
   •
   •
 You received this message because you are subscribed to the Google Group 
 rubyonrails-core.
 You can post via email.
 To unsubscribe from this 
 group, send an empty message.
 For more options, visit this group.

 --
 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 

Re: [Rails-core] Generating new project creates a few files with bad syntax Rails 3.2.1

[Chad Woolley]

M is the mute thread shortcut in gmail:

http://support.google.com/mail/bin/answer.py?hl=enanswer=47787

Don't feed the trolls.

-- 
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] Fixing the CHANGELOG

[Chad Woolley]

+1 on considering git-notes.  Seems to solve the root problems cleanly.

On Thursday, November 17, 2011, Josh Susser j...@hasmanythrough.com wrote:
 I suggest using git-notes to mark commits for the CHANGELOG. Metadata FTW!
 Not all changes are worth mentioning in the CHANGELOG. But with
git-notes, you can annotate commits with additional comments after the
commit is made. You can tag commits that you want in the CHANGELOG and then
assemble the CHANGELOG by a script in any fashion you want. You can even
see these notes on GitHub:
 https://github.com/blog/707-git-notes-display
 I don't know if you'd want to just tag the commits or add extra
information for the CHANGELOG entry, but I'm sure the core team can figure
out how they want to manage that.
 --
 Josh Susser
 http://blog.hasmanythrough.com

 On Thursday, November 17, 2011 at 10:25 AM, Aaron Patterson wrote:

 We need to do something about our changelogs. First I will explain the
 problem, then I will propose a couple solutions.
 When we make a change, that change should be committed to the master
 branch. Ideally, that change would also include an entry in the
 CHANGELOG file. If it's a bugfix, we'll propagate the change up to each
 release branch (3-0-stable, 3-1-stable, etc).
 We have headings in each CHANGELOG. The heading is a version of rails,
 and all entries below each heading are supposed to be changes in that
 particular version.
 This causes a huge problem when backporting. Let's say we commit
 a bugfix to master. At the time of commit, we're not sure if it will be
 backported, so we add an entry under the current 3.2 heading. Later we
 decide it should be backported. Now we have to merge the commit to the
 release branch, then add another commit to master moving the changelog
 entry underneath the 3.1.x heading.
 We can also have the problem in the opposite direction. Say we need to
 revert a change on the release branch and move the commit back to the
 3.2 release. Now we must make another commit on master to fix the
 location of changelog comment.
 I think this way of changelog management is not only very cumbersome,
 but also very error prone. There are many ways that we can lose
 changelog entries, or simply have them in the wrong place.
 I think there are a couple ways to solve this problem, but we (the core
 team) need to agree on it.
 1) Remove the version headings from the CHANGELOG and simply keep
 entries in a reverse chronological order. This is how we keep
 changelogs in ruby-core[1].
 Actual changelog entries for a particular release can be determined via
 git diff and the release tags.
 Upsides are that it's easy to merge and easy to revert. The downside is
 that we need to include a timestamp and agree on a timezone that we use
 for the changelog entries. Vim and Emacs handle this automatically.
 2) Just remove the CHANGELOG file all together. We can generate a
 changelog via `git log` on release of rails. The upside is that we
 don't need to worry about updating the changelog. The downside is that
 we put the burden on the release manager to assemble a changelog at
 release time. Another alternative could be to just not release a
 changelog at all and ask users to read the git log between tags.
 Anyway, these are my thoughts. Input is definitely welcome, but I
 really think this is something we need to change.
 --
 Aaron Patterson
 http://tenderlovemaking.com/

 --
 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] Javascript is now a first-class code citizen - Really?!

[Chad Woolley]

On Thu, Sep 1, 2011 at 6:40 AM, Michael Breen hard...@gmail.com wrote:
 Rails doesn't really ship with any testing framework. It defaults to what's
 in Ruby core, which is Test/Unit  in 1.8 and MiniTest in 1.9.

* Rails ships with Ruby test generators (because testing is good)
* Rails ships with Javascript/Coffeescript generators
* There's no Javascript testing framework in Ruby core, nor Rails.
(testing is only good for Ruby code?)

One of Rails' many opinionated innovations as a framework was that
testing is good, everyone should do it by default, so test code is
included/generated by the framework.  I believe it should be just as
opinionated about Javascript testing.

As Rodrigo said, it doesn't matter which framework is used (although
Jasmine is nice and iterates/improves upon several earlier tools). The
important thing is to send the message that Javascript can and should
be tested.

-- Chad

-- 
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] Javascript is now a first-class code citizen - Really?!

[Chad Woolley]

On Thu, Sep 1, 2011 at 7:46 AM, Everton Moreth everton.mor...@gmail.com wrote:
 I agree with Rodrigo, it should be optional, but when the Rails Community
 takes its choice in supporting anything, it gets attention, people start to
 use it, and even the framework itself gets better.

 Also, we really should ease the new developers life in pointing which
 framework to use when starting with rails and choosing the test frameworks.

A few relevant links:

http://pivotallabs.com/users/mgehard/blog/articles/1683-using-jasmine-to-test-coffeescript-in-a-rails-3-1-app
http://pivotallabs.com/users/jdean/blog/articles/1778
http://gilesbowkett.blogspot.com/2011/08/tdd-in-javascript-no-excuses.html

-- 
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.

Spammers getting past moderate-first-post setting (was: [Rails-core] Earn $1000-$2500 per month)

[Chad Woolley]

OK, another spammer who joined May 27th, and have their posting
allowed flag turned on without ever having a first post moderated.

Unless some other list admin is going and flipping this bit in the
groups management console (anyone???), this looks like spammers have
found some exploit in google groups to get past the
moderate-first-post setting.

Other new posters are definitely still getting moderated, I just
approved one this morning.

Sorry, I don't have time to look into it.  I'll just keep banning them...

*shrug?*

-- Chad

On Tue, Jun 7, 2011 at 2:14 AM, roseanje...@rediffmail.com
roseanje...@rediffmail.com wrote:
 Earn $1000-$2500 per month

-- 
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] Earn $1000-$2500 per month

[Chad Woolley]

No idea how this spammer got their moderate-first-post bit turned off.
 I didn't do it, and doubt any other group admin did.  They only
joined on May 24th.  Google Groups fail or exploit?

Anyway, banned now...

On Fri, Jun 3, 2011 at 11:21 PM, Steve Schwartz st...@alfajango.com wrote:
 That's not rails core... it's php.

 -Steve
 @jangosteve
 On Jun 4, 2011, at 2:15 AM, rose wrote:

 Earn $1000-$2500 per month
 If you Register your name
 You Get Sign-up bonus $5
   AND
 Get $.20 cent for each referral.
 Further details
 
 http://www.earnbyforex.com/index.php?id=35678365
 

 --
 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.


-- 
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: Rails Download Instructions Include Unnecessary Step for Ruby 1.9+

[Chad Woolley]

Dunno who let her through first post moderation (not I), but she's
banned now.  Sorry for the inconvenience.

On Tue, Jan 18, 2011 at 3:38 PM, Ryan Bigg radarliste...@gmail.com wrote:
 Lori, whilst we appreciate the offer of jobs greatly, this is not the
 correct thread or even message board to post it into. Please do not hijack
 other people's threads.
 You will have better luck by posting it to the
 http://groups.google.com/group/rubyonrails-talk mailing list instead.

 --
 Ryan Bigg

 On Wednesday, 19 January 2011 at 2:33 AM, Lori Kingman wrote:

 I have about 75 Ruby Roles open in Washington DC and NYC if anyone is
 interested, please forward your resume or send me an email and I will
 forward the job description to you!

 Craig Stuntz wrote:

 I originally posted this to Rails Talk; someone there suggested I move
 it here.

 The instructions here http://rubyonrails.org/download say:

 1. Download + install Ruby.
 2. Download + install gems. - NB: Unnecessary for Ruby 1.9+ as it
 already includes RubyGems
 3. gem install rails.

 Step 2 errored on my Win7 machine after installing Ruby 1.9.2 in step
 1. Turns out it wasn't necessary at all.

 I'd like to propose a change in the wording of step 2. It currently
 says:



 RubyGems is the standard Ruby package manager. It's similar to apt-get,
 emerge, and other OS package managers.
 Download
 (extract, then run ruby setup.rb)


 I think it should say:



 RubyGems is the standard Ruby package manager. It's similar to apt-get,
 emerge, and other OS package managers.
 RubyGems is included in Ruby 1.9 and higher. For other versions:
 Download
 (extract, then run ruby setup.rb)


 -Craig

 --
 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.



 --
 Lori Kingman
 Pencom Systems Incorporated
 1375 Broadway, 6th Floor
 New York, NY  10018
 646-300-8949 - Ph
 732-239-8829 - Cell
 l...@pencom.com
 www.pencom.com

 --
 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.


-- 
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] Free shipping,high qualtity replica watches and Lowest price replica watches

[Chad Woolley]

On Sun, Nov 21, 2010 at 3:49 AM, www.watchcs.com fr...@126.com wrote:
 divspan style=FONT-SIZE: 7.5pt; COLOR: #494949a href=http://
 www.eclone8118.com/replica watch fake/a|a href=http://

Sorry about that.  That spammer had lain dormant since joining Jun 23
2007.  Somehow this got past the first post moderation, which usually
prevents spam from ever hitting the list.

-- 
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-c...@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] -j parameter to select vendor javascript library when starting new Rails app

[Chad Woolley]

On Sat, Sep 11, 2010 at 6:03 PM, Ryan Bigg radarliste...@gmail.com wrote:
 I don't see what lighthouse offers that github issues doesn't.

Search that actually works?

-- 
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-c...@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] Making ActiveSupport::Cache consistent

[Chad Woolley]

On Saturday, April 24, 2010, Brian Durand br...@embellishedvisions.com wrote:
 This I'm not so sold on,  expires in is a memcached implementation
 specific feature and adding it to all the other cache stores simply
 seems to add overhead for very little gain.  No one is seriously going
 to be using MemoryStore or FileStore in production and wanting to use
 :expires_in.  What was it you needed this for?

 Mostly what I wanted was for the caches to be consistent. I think
 having caches support a time to live on write is a pretty fundamental
 feature of a cache because otherwise you are stuck needing to know
 what every cache entry is so you can expire it when necessary. For a
 small site on a single server, I think MemoryStore or FileStore could
 be a perfectly viable option.

Yes.  Native file cache let you have caching for a simple site, and
eliminate the need to even have a web server.

+1 on the race ttl too

-- Chad

-- 
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-c...@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: [Rails] Ruby Summer of Code Project

[Chad Woolley]

On Tue, Apr 20, 2010 at 10:33 AM, Federico Builes
federico.bui...@gmail.com wrote:
 Hi,

 As part of my Ruby SOC proposals I'm thinking of working in the CI
 idea posted in http://wiki.rubyonrails.org/rubysoc/2010/ideas

 Ideally, I'd like to do a two step proposal: first one would be
 writing custom CI tool tailored specifically for Rails where we can
 see more relevant information. The second one would be providing a way
 for users to push their results upstream to get more data about
 different environments.

 I'd like to know what you guys think of this, and what features do you
 think this system in order to make it worth the time and money
 efforts.

Hi Federico,

I am actively working on a complete redesign of the official Rails CI
environment, primarily to more easily meet these goals (many
platforms/environments, one-click setup for casual rails hackers,
good reporting).

This may or may not be a good pick for RSOC. I could always use help -
but this particular task has large scope, and a need for long-term
involvement and maintenance (to which I am committed).  So, I'm not
sure if this is something that could be completed as a RSOC task,
since it will be a continually evolving project.

In any case, I'd love to discuss my plans and review what I've already
completed.  If you are interested in Rails CI, for RSOC or not, please
email me.

Thanks,
-- Chad

-- 
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-c...@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] Ruby Summer of Code Project

[Chad Woolley]

On Tue, Apr 20, 2010 at 2:56 PM, Jeremy Kemper jer...@bitsweat.net wrote:
 Hey Federico,

 Have you tried the performance test suite built in to Rails apps?

 You write performance tests in the style of integration tests then
 `rake test:benchmark` or `rake test:profile`.

 The benchmark task benches each performance test and saves the results
 in a CSV file with info about your environment, the git revision, etc.

 So you can do simple CI with a git commit hook or a cron job, then
 check the CSV for regressions and improvements.

 I think improving the tools here would make a great project, as would
 sharing results from open-source apps tested on different platforms
 and hardware.

 Good luck!
 jeremy

Hi Jeremy,

Yes, good points.  I've already talked with Federico offline.  I
believe his original interest was in improving the rails test suite
itself, and allowing collaboration and submission of results by users.

I think it is mostly orthogonal to the problem I'm tackling - which is
to have a performant, stable, easily reproducible production CI
environment which runs the main build script
(http://github.com/rails/rails/blob/master/ci/ci_build.rb) against the
major interpreters.

I don't want to make the production CI environment any more
complicated than necessary - and adding the variable of user-submitted
input from random environments would definitely complicate things.
It's hard enough to get most people to care about the failing CI at
all - we need to keep it simple, stable, and reproducible.  That's why
I'm taking the approach of a Rails CI AMI which anyone can run on EC2,
and the generation of that AMI will also be completely automated.
That hopefully eliminates any possibility of non-reproducible build
failures, which are the bane of any CI system.  I've said
reproducible four times, so you get my point :)

However, as long as any improvements/innovations in this area (rake
tasks, additional/alternative test/benchmark scripts to ci_build.rb,
etc) conform to basic conventions - stdout/stderr, generated csv/html
flat file artifacts, and proper return codes - there's no reason we
can't integrate it into the main CI environment (or any other CI
environment) in the future.  Even if it isn't integrated, the
information gathered can drive improvements to the main test suite or
build script.  However, I'd prefer avoid calling this work CI or
lumping it into the CI effort, for the reasons mentioned above, and
also because it would be more user driven than continuous.  In
fact, I've already updated the wiki to say Crowdsourced Rails
environment compatibility metrics instead of continuous integration.

Thanks,
-- Chad

-- 
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-c...@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: Mountable Apps Status

[Chad Woolley]

On Mon, Mar 15, 2010 at 8:41 AM, Patrick Peak pea...@gmail.com wrote:
 A. Copy the static files from the gems into the public directory of
 the project, which can allow the web server to handle serving them.
 (BrowserCMS does this).

I dislike the copying files approach, it seems confusing and error-prone.

 B. Have the plugin/gem serve the static assets from the gem through
 rails. (There are some plugins that do this whose names I can't
 remember).

This seems best, especially if this is below the rails caching
layer, so that they can still be cached on filesystem/memcached/etc
and served via webserver, even though they are being 'read' from
in-place plugin/gem files via ruby code.

 C. Do something fancy with symlinks (if the OS supports them).

Sounds like a bad idea too.  We should try to be platform-agnostic if
at all possible, which it is.

-- Chad

-- 
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-c...@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] some love for migrations

[Chad Woolley]

On Sun, Mar 7, 2010 at 4:54 PM, Josh Susser j...@hasmanythrough.com wrote:
 I have a semi-grand plan for some changes to migrations.

+1 on all points.

I reviewed rails.lighthouseapp.com/projects/8994/tickets/2058, and
your solutions seem to cover all bases (someone speak up if it
doesn't).  I especially like the part where you don't copy files to
the app, I always thought that sounded crazy.

Referencing the engines' migration versions in a manually-created
migration makes sense.  You want to have a single timeline for your
app's migrations, as described in this comment:
https://rails.lighthouseapp.com/projects/8994/tickets/2058#ticket-2058-28
(good analysis even though it recommends the file-copy approach).
Plus, manual creation can always be changed to automatic in the future
with higher-level abstractions.

pre-3.0 is also the right time to add fundamental changes like this,
so please post the ticket in this thread once you have a patch ready.

-- Chad

-- 
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-c...@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] some love for migrations

[Chad Woolley]

On Sun, Mar 7, 2010 at 6:49 PM, Jeremy Kemper jer...@bitsweat.net wrote:
 I have a plugin with migrations for its own database. I want those to
 run and be managed in their own universe. This works well today using
 our existing tools: just override the connection class method on the
 migration.

Even if a plugin/engine manages its own database, and has nothing to
do with your app's database, it still operates within the context of
your app and your app's timeline (you explicitly upgrade the code, you
monkey patch it, etc).  Otherwise, if it has nothing to do with your
app, it is a separate app in itself, and should be managed
independently.  But since it *is* in the context of your app, it makes
sense to explicitly manage the plugin's migrations within the timeline
of your app's migrations.  You need to have explicit control over this
timeline, for all the reasons Josh mentioned in his response.

The migrations API should definitely support either approach - running
an engine's migrations as a standalone app, or invoking them in the
context of a parent app's migration timeline - and I hope Josh's patch
takes this into account.  This allows for the greatest flexibility,
but we must support both.

-- Chad

-- 
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-c...@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] Why is ActiveResource::Base.site a class variable?

[Chad Woolley]

On Sun, Dec 13, 2009 at 4:40 PM, Yehuda Katz wyc...@gmail.com wrote:
 Long-term, we want to try to get away from using global state like
 this as much as possible, but fixing it can sometimes open a thorny
 can of worms. Koz's solution, paired with a mutex or thread-local (for
 threadsafe scenarios) is a good workaround for now.

Any updates on this?  Has any progress been made on making
ActiveResource thread-safe (either in Rails 3 or in plugins/forks)?

Thanks,
-- Chad

-- 
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-c...@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: Rails 3 : basic routes

[Chad Woolley]

On Mon, Feb 15, 2010 at 7:48 PM, Yehuda Katz wyc...@gmail.com wrote:
 The catch-all route let to a series of faulty patterns such a
 hide_action and verification. At it's core, the router is the
 appropriate place to limit request that go onto the controllers.

Agreed.  Many a 2.x production app spews exceptions about being hit
with invalid routes, with no easy way to stop it.  It'll be great if
there's an easy convention to prevent this.

 In this case, removing the default route  allows us to simplify the
 explanation of how you should go about hiding actions or
 restricting an action to GET.

Does this updated simplified explanation exist yet?

Thanks,
-- Chad

-- 
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-c...@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: The state of mountable apps

[Chad Woolley]

On Sun, Feb 7, 2010 at 9:43 PM, Anuj Dutta dutta.a...@googlemail.com wrote:
 Check this out as well, by Jose Valim:

 https://gist.github.com/9fcf658fc4f559b97c2c

 It gives a good introduction and a brief insight into how Railtie, Engine,
 Application fits together in Rails3.

That's a great writeup with lots of examples.  Good job, Jose...

-- Chad

-- 
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-c...@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] Page caching different formats for same action?

[Chad Woolley]

If I have an action which can render multiple formats (e.g. html, js,
rss), is it possible to page-cache all of these formats?

I can't see how to do it with 'caches_page'.  It looks like you can
only override 'page_cache_extension' at the class level:

http://github.com/rails/rails/blob/master/actionpack/lib/action_controller/caching/pages.rb#L49

I'd like to dynamically tie the page_cache_extension to my format
somehow.  Is this possible?

Thanks,
-- Chad

-- 
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-c...@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: CI Server for Rails

[Chad Woolley]

On Wed, Jan 13, 2010 at 11:55 AM, Anuj Dutta dutta.a...@googlemail.com wrote:
 Hello all,

 Has anyone tried installing and running the CI server for their local fork
 of Rails? I have just been trying to do that and for one think the
 instructions are poor and dated and must be updated since all new Rails 3 is
 in the town.

 I had a word with Chad Woolley (thewoolleyman) who did the initial cinabox
 scripts to install the cruisecontrol.rb on your own server but since the
 different versions of Linux require different scripts, he has decided to
 rewrite the entire process in Chef to ensure stability and robustness.
 Here's the repo: http://github.com/thewoolleyman/cichef . I would like to
 rewrite the entire CI setup process and make it as automated as possible but
 would need suggestions and help from the community.

Hi,

That's the wrong repo.  Here's where the latest stuff I'm actually
running on ci.rubyonrails.org lives:

http://github.com/thewoolleyman/rails/tree/ci

However, this is outdated.  My main goal was to make the process
easily repeatable (for people like you) - you run a single command on
a blank server, and you end up with a working rails CI server. So I
spent a lot of effort on creating supporting tools like bootstrap_ruby
and cinabox - and got pretty close - the current servers were set up
using this approach.

Unfortunately, I realized this approach isn't very maintainable or
easily supported cross-platform.

So, my current plan is to scrap it all and redo it all in Chef.  The
repo for that is here:  http://github.com/thewoolleyman/cichef  - as
you can see, I've made zero progress on that, mainly because the
current machines are cranking along ok, and I'm still bootstrapping my
Chef knowledge.

Help with this is very welcome.  The goal is still to make it easily
reproducible with a single command, as the current setup (almost) is.
So, fork http://github.com/thewoolleyman/cichef and start helping out
if you want.

Thanks!
-- Chad
-- 
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-c...@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: CI Server for Rails

[Chad Woolley]

On Wed, Jan 13, 2010 at 1:34 PM, Anuj Dutta dutta.a...@googlemail.com wrote:
 Thanks for the correct. Well, I have started looking into Chef and really
 got no where with it :o( but I will keep trying.

No, I apologize - I didn't read your email closely enough - you had it right.

Anyway, the point is, it should all be rewritten in Chef to be easy
and repeatable, and any help is welcome...

Thanks!
-- Chad
-- 
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-c...@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: CI Server for Rails

[Chad Woolley]

On Wed, Jan 13, 2010 at 1:44 PM, Anuj Dutta dutta.a...@googlemail.com wrote:
 No problem. Yeah, it should be easily repeatable and extensible. I will keep
 an eye on the repository.

To be more clear, here's all you need to do with my current setup:

http://github.com/thewoolleyman/rails/blob/ci/ci/README.markdown

All you do is wget a script and run it with appropriate env vars
options, then you end up with a fully working rails CI server for the
specified ruby interpreter and rails branch.

I want the Chef-based solution to be that easy.  Chef gurus, please
give me examples!

-- Chad
-- 
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-c...@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] Help needed with failed tests while running Rails test suite

[Chad Woolley]

On Wed, Dec 30, 2009 at 7:37 PM, Mike Gunderloy larkw...@gmail.com wrote:
 And indeed, if you check http://ci.rubyonrails.org/ you can see that Rails 
 builds are pretty hit-or-miss on master right now.

 Mike

Yeah.  The Core team has been bugging me to send campfire
notifications so they are more aware of breakages, but we're still
(slowly) trying to get the campfire notifier plugin for CCRB working.
Hope to hack it some New Year's Eve.

I also notice the 1.9 build server is down, I'll look into that (as
soon as my son is off my laptop where my ssh key is).

-- Chad

--

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-c...@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] Ruby Debug (ruby-debug)

[Chad Woolley]

This list is for discussion of Rails internal development, not general
ruby questions.

Having said that, check out the 'cat' (catchpoint) functionality in
ruby-debug...

On Wed, Dec 2, 2009 at 10:44 AM, RubyNewbie calvinanhngu...@gmail.com wrote:
 Question:
 I was wondering if there was a way to instruct the ruby debug
 framework to stop/break/freeze on any error so I can investigate the
 call stack to diagnose the problem?

 Background:
 I am using 'ruby-debug' and know that I can insert breakpoints with
 the debugger() method call in my code.  I have run into errors within
 unexpected callbacks and often have no idea why the code traversed
 that path.  Because I don't understand the code path it's hard to know
 where to put the breakpoint to troubleshoot the problem.

 - Thanks in advance.

 --

 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-c...@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-c...@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] Why is ActiveResource::Base.site a class variable?

[Chad Woolley]

On Sun, Dec 13, 2009 at 4:40 PM, Yehuda Katz wyc...@gmail.com wrote:
 Long-term, we want to try to get away from using global state like
 this as much as possible, but fixing it can sometimes open a thorny
 can of worms. Koz's solution, paired with a mutex or thread-local (for
 threadsafe scenarios) is a good workaround for now.

What's the can of worms?  Just thread safety?

How about this approach (suggested by Adam Milligan):

class ActiveResource::Base
  def self.connect(current_site)
old_site = site
begin
  self.site = current_site
  connection(:refresh)
  yield
ensure
  self.site = old_site
end
  end
end

This would also need to be made threadsafe, but isn't it essentially
the same thing Koz suggested, without a dependency on DelayedJob?

-- Chad

--

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-c...@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] Why is ActiveResource::Base.site a class variable?

[Chad Woolley]

This causes problems in the following scenario:

1. You use ActiveResource to post data to an external site using
subdomains for individual accounts (e.g. Lighthouse)
2. You want your app to allow multiple users to do this (register
their Lighthouse account/URI to automatically push their data from
your app to Lighthouse).

There's no way I can see to support this other than creating a
separate (dynamically named) class for each user/site.

Questions:
* Is there a reason it can't/shouldn't be an instance variable?
* If there is a good reason, are there any workarounds or third-party
alternatives which don't have this limitation (other than directly
handling the HTTP calls)?

Thanks,
-- Chad

--

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-c...@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] ActionMailer with Mail gem - It is here

[Chad Woolley]

On Mon, Nov 23, 2009 at 4:29 PM, Mikel Lindsaar raasd...@gmail.com wrote:
 So I just updated the mail gem to 1.3.0 and against my fork of actionmailer
 at github/mikel/rails, ActionMailer now passes all tests in MRI 1.8.6, 1.8.7
 and 1.9.1

Now how about JRuby? ;)

--

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-c...@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: RAILS_ENV hardcoded in too many places

[Chad Woolley]

On Tue, Oct 13, 2009 at 9:53 AM, Mislav Marohnić
mislav.maroh...@gmail.com wrote:
 The default value for RAILS_ENV is set to development in initializer.rb,
 which is loaded right after boot.rb has determined the boot strategy.
 I created a config/preinitializer.rb which was supposed to provide another
 default value for RAILS_ENV (staging or production, depending on the
 host), but it doesn't work in all cases. Specifically, commands executed by
 console, dbconsole, runner and server scripts all set RAILS_ENV to
 development as default and ruins my preinitializer idea since these
 scripts happen before the actual initialization phase.
 The workaround right now is to hardcode the RAILS_ENV value in
 preinitializer.rb without respecting the ENV[RAILS_ENV] variable, but that
 disables the possiblity that I actually start the app in some custom
 environment other than what I wanted to hardcode for this host.
 What I would like to do is remove the development default from
 script/console, script/runner and script/server (removing it from
 dbconsole is not possible since it doesn't load the environment) and
 unless anyone can find an objection to this, I will be posting a patch.

+1

Also, the default generated test_helper hardcodes RAILS_ENV to test
(or used to, I didn't check master).  I guess that's the best place,
but thought I'd mention it in case it is relevant to your patch.

-- Chad

--~--~-~--~~~---~--~~
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: ActiveRecord tests failing with Ruby 1.9

[Chad Woolley]

On Fri, Oct 9, 2009 at 7:57 PM, Liping Huang liping.huang2...@gmail.com wrote:
 sqlite3 can't run on ruby1.9.

It is running on 1.9 on the CI box, for the 2.3 branch:

http://mri19.ci.rubyonrails.org:/builds/rails-2-3-stable-ruby-1-9-1

...and master:

http://mri19.ci.rubyonrails.org:/builds/rails-master-ruby-1-9-1

-- Chad

--~--~-~--~~~---~--~~
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: ActiveRecord tests failing with Ruby 1.9

[Chad Woolley]

Running geminstaller against ci/geminstaller.yml should install
correct versions.  Bundler is a great way to manage this, but not in
use on 2-3 branch and not fully in use on master, so geminstaller is
what the rails ci boxes still use.

Sorry for top post, on iPhone

On Thursday, October 8, 2009, Rick richard.t.ll...@gmail.com wrote:

 got that right - gem update mocha went 0.9.5 - 0.9.8

 test_mysql:
 2112 tests, 6813 assertions, 0 failures, 0 errors, 0 pendings, 0
 omissions, 0 notifications

 test_postgresql:
 2128 tests, 6952 assertions, 0 failures, 0 errors, 0 pendings, 0
 omissions, 0 notifications

 test_sqlite3:
 2072 tests, 6746 assertions, 0 failures, 0 errors, 0 pendings, 0
 omissions, 0 notifications

 thanks

 On Oct 8, 10:11 am, Mateo Murphy mateo.mur...@gmail.com wrote:
 Those are moccha methods, it would seem like that gem isn't being
 included or isn't working properly

 On 2009-10-08, at 9:59, Rick richard.t.ll...@gmail.com wrote:



  I've recently updated to Rails 2.3.4 which I run under both Ruby
  1.8.7p173 and 1.9.1p243.  I also built both postgresql and mysql from
  source and installed these with a current sqlite3.  The relevant
  adapter gems are current.

  I'm seeing errors and failures with the active record tests under ruby
  1.9 for all 3 db's that appear to have more to do with the test
  environment than the individual adapters or underlying db code.

  Summary lines for the different dbs are:

  sqlite3:
  2072 tests, 6621 assertions, 1 failures, 86 errors, 0 pendings, 0
  omissions, 0 notifications

  mysql:
  2112 tests, 6688 assertions, 1 failures, 86 errors, 0 pendings, 0
  omissions, 0 notifications

  postgresql:
  2128 tests, 6825 assertions, 2 failures, 87 errors, 0 pendings, 0
  omissions, 0 notifications

  The errors all report on undefined method.  Three methods are
  identified with the greatest number being 'expects' followed by 'with'
  and 'stub'.  These errors do not occur under Ruby 1.8

  Any thoughts?
 


--~--~-~--~~~---~--~~
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: activeresource: rake test: undefined method `mock' `expects' `any_instance'

[Chad Woolley]

On Wed, Oct 7, 2009 at 1:55 AM, James Mead jamesmea...@gmail.com wrote:
 This is likely to be due to using Mocha = 0.9.6 when Mocha is being
 loaded *before* Test::Unit.

 You need to make sure you are loading Mocha *after* Test::Unit. There
 are a number of ways of achieving this depending on how you are using
 Mocha.

This should Just Work with the standard rake tasks to run the rails
tests.  If it doesn't in some environments, we should try to fix it.
Please follow up on this thread with any potential improvements to the
Rails test suite, rake tasks, or test documentation

--~--~-~--~~~---~--~~
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: activeresource: rake test: undefined method `mock' `expects' `any_instance'

[Chad Woolley]

On Tue, Oct 6, 2009 at 4:00 PM, Philippe Creux pcr...@gmail.com wrote:
 I have few patches for active resource I would like to publish but I
 can't get the test suite passing.

 In: rails/activeresource (2-3-stable)
 Running: rake test
 Got the following:
  1) Error:
 test_exists_without_http_mock(BaseTest):
 NoMethodError: undefined method `any_instance' for
 ActiveResource::Connection:Class
    ./test/base_test.rb:986:in `test_exists_without_http_mock'

  2) Error:
 test_accept_http_header(ConnectionTest):
 NoMethodError: undefined method `mock' for #ConnectionTest:
 0x7f4c3e0e5010
    ./test/connection_test.rb:203:in `test_accept_http_header'

  3) Error:
 test_ssl_error(ConnectionTest):
 NoMethodError: undefined method `expects' for
 #ActiveResource::Connection:0x7f4c3e260840
    ./test/connection_test.rb:223:in `test_ssl_error'

  4) Error:
 test_timeout(ConnectionTest):
 NoMethodError: undefined method `mock' for #ConnectionTest:
 0x7f4c3e0e49a8
    ./test/connection_test.rb:185:in `test_timeout'

 It would be great if someone could help me. :)

These look familiar but I can't remember what caused them.  Maybe
related to mocha?  The 2-3 branch is passing on the CI box
(ci.rubyonrails.org), so you can try the following:

* Check your environment against the CI environment (all environment
info is printed at the bottom of the build logs).  If anything is
different (ruby version, installed gems, etc), try making it match.
Especially mocha.  Run GemInstaller against ci/geminstaller.yml to
automatically install required gems.
* Check the history of the 2-3 branch CI builds, see if any of them
have this failure
* Check ci/ci_setup_notes.txt against your setup (although these are
getting outdated, latest setup scripts are in my master branch at
thewoolleyman)
* see if you can get it working on a different box, if so, see why it
passes there.

--~--~-~--~~~---~--~~
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: down migrations could be stored in db?

[Chad Woolley]

On Wed, Sep 9, 2009 at 5:03 AM, Chris c...@hapgoods.com wrote:

 I see sublime elegance in having the DB store the DDL to revert
 migrations.  I haven't worked with large teams in years, but I see the
 dilemma Steven is addressing:

 The common DB is at Rev N
 User (or branch) A migrates common DB up to Rev N + 1
 User (or branch) B is checked out and expects common DB to be at Rev
 N.
 Result: User/branch B is stuck: code to rollback the DB to Rev N
 exists only in User/branch A.

In this case, I would say that user (or branch) B should not be
running outdated code against the 'common' database at Rev N +1.  The
+1 migration probably had some associated code changes to support the
schema changes, and if user/branch B does not have that code yet, they
shouldn't be running against that database.  Either use a separate
database, or cherry-pick the migration and associated changes from
branch A.  I think the concept of a common DB is the root problem
here.  Each developer should have their own DB in development, and in
demo/staging/production, you should only be running a single branch
(preferably a tag of a green CI build) against the DB at any given
time.

-- Chad

--~--~-~--~~~---~--~~
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: down migrations could be stored in db?

[Chad Woolley]

On Wed, Sep 9, 2009 at 4:02 PM, Rick DeNatale rick.denat...@gmail.com wrote:
 My normal practice when writing migrations which depend on model code
 is to put a migration specific model clase in the migration file
 itself, scoped inside the migration.  The model mimics a subset of the
 one in app/models including only necessary attribute declarations and
 methods.

Great idea, 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 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: Long CruiseControl notifications are irritating ...

[Chad Woolley]

On Sat, Sep 5, 2009 at 6:15 AM, Eloy Duran eloy.de.en...@gmail.com wrote:
 I liked the idea of sending the email to the commit author, as Hudson
 apparently does as described by Joris. And as I do share concerns
 about the robustness of the Rails code, I wrote a patch for
 CruiseControl to be able to do the same: 
 http://github.com/alloy/cruisecontrol.rb/commit/b2be91d12db74d0ac0b8f2d1427453c7f2482470

Thanks Eloy, but I'm not sure that awareness of the broken build is
the root problem here.  This patch looks useful - can you package it
up as a ticket at
https://cruisecontrolrb.lighthouseapp.com/projects/9150-cruise-control-rb?

 CC doesn't run on
 1.8.7, which is what I have

I just fixed 1.8.7 support in master branch and it is working for me.
Please report any bugs you find at the CCRB lighthouse...

Thanks!
-- Chad

--~--~-~--~~~---~--~~
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: Long CruiseControl notifications are irritating ...

[Chad Woolley]

On Fri, Sep 4, 2009 at 7:11 AM, Eloy Duran eloy.de.en...@gmail.com wrote:
 I wouldn't be bothered by these CI emails if we'd see one every now
 and then. But nowadays, it seems like every other build is broken.
 That's the real problem here.

Thanks for the feedback, everyone.  FWIW, this is not new, build
failures used to go to this list [1]

However, not fixing the build promptly is a problem, and one of the
reasons I wanted to reinstate notifications to this list.

On a large/distributed project like Rails - especially one where many
people run the master branch live in their projects - I believe there
are exactly three appropriate responses to a broken build, in order of
decreasing desirability:

1. Fix the failing tests, ASAP
2. Roll back the change which broke the tests, ASAP
3. Comment/disable the failing tests, ASAP

Any other response to a broken build is wrong and lazy, and leads to
broken windows [2].  See my longer rant here: [3]

Now, it is FINE for the build to go red once in a while, especially
for an open source project like Rails.  It is not reasonable to expect
the core team to run the full suite before every checkin, on every
supported database and Ruby interpreter.  That would be a waste of
their valuable time and effort, and is why we set up CI to do it
automatically.

However, LEAVING the build red is NOT fine.  Spamming the list and
annoying people is just a symptom of the real problem, which is not
promptly resolving a broken build.  Fixing the symptom by hiding the
problem (sending failure emails to a separate list) is
counterproductive, and only exacerbates the broken-window effect.

Anyway, I've disabled the notifications for now, and the core team has
the ability to disable them anytime they want as well [4].  I didn't
disable them because people complained, but because we just got a new
suite of servers donated to set up an awesome, multi-branch,
multi-interpreter Rails CI environment (thanks EngineYard!), and I
have to complete that migration/setup.

[1] 
http://groups.google.com/group/rubyonrails-core/browse_thread/thread/2b610e77506812c0#
[2] http://www.pragprog.com/the-pragmatic-programmer/extracts/software-entropy
[3] 
http://pivots.pivotallabs.com/users/chad/blog/articles/484-how-you-can-learn-to-stop-worrying-and-love-continous-integration
[4] http://github.com/rails/rails/blob/master/ci/cruise_config.rb#L4

--~--~-~--~~~---~--~~
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: Long CruiseControl notifications are irritating ...

[Chad Woolley]

On Fri, Sep 4, 2009 at 11:27 AM, Czarek cezary.bagin...@gmail.com wrote:
 Perhaps a timeout within which the build should be fixed? I mean it
 doesn't take hours for CI to detect the problem. And then mail if fix
 doesn't come in time.

That's a good idea.  How about this:

1. The first three red builds notify only the core team members (at
the undisclosed location where they congregate)
2. After three red builds (more than enough chances to fix the test,
revert the change, or comment the test), this list starts getting the
failure emails.

Three is arbitrary, it could be more...

 I don't believe committers will want to create and subscribe to a
 separate list. And this is *their* mailing list. Then again, the rest
 of us may want to know if we should pull or not.

The core team applied the patch to send notifications to this list,
and can disable them anytime they want.

If the rails core list isn't a place to see and find out about
failures in the rails build, what is?  If people are hacking on rails
(which IS the topic of this list), then they probably want to know if
a test failure they see locally is their fault or actually broken in
the official build.

If you don't want to see the notifications, set up a filter, it should
take you less than a minute.  The subject lines always have
[CruiseControl] in them.  If you can't set up a filter, you are either
lazy or need to learn how to use a real email client.  Or just ignore
them (']' in gmail), which takes me about .5 seconds.

-- Chad

--~--~-~--~~~---~--~~
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: Long CruiseControl notifications are irritating ...

[Chad Woolley]

On Thu, Sep 3, 2009 at 10:02 AM, Czarek cezary.bagin...@gmail.com wrote:

 Am I overreacting or is anyone else a tiny bit annoyed by the size of
 these emails? If you're mobile with a GSM card out of UTMS range , you
 have around 4-8kB/s, and 70kB per mail is a noticeable wait.

 The summary at the top is fine, but I propose a link to the build details.
 If someone is interested in the gory details, they can open the link in
 a browser.

 Forget about me if this is too much of a hassle.


I'm sorry.  Here's some options:

1. Filter these mails so you never see them (should be easy with Gmail)
2. Make it so.  CruiseControl.rb is open source, and may even have this
feature already, and all the CI config is in the rails repo.  However, I
think some people may like seeing the error output inline.
3. Help fix the build :)

-- Chad

--~--~-~--~~~---~--~~
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: [CruiseControl] rails build f61dc0e failed

[Chad Woolley]

On Thu, Sep 3, 2009 at 12:13 PM, John Pignata john.pign...@gmail.comwrote:

 It looks like this last test failure just won't pass on CI as it is
 running 1.8.6, from the code:

  # This is broken in 1.8.6 (not supported in Rails 3.0) because the
 cache uses a Hash
  # key. Since Ruby 1.8.6 implements Hash#hash using the hash's
 object_id, it will never
  # successfully get a cache hit here.
  def test_template_changes_are_not_reflected_with_cached_templates

 What to do? Upgrade to 1.8.7? Get some kind of multi-ruby CI going?


Yeah, core team says 186 is now unsupported.  I've disabled the emails until
I upgrade the server (I already have another 187 CI box running, just need
to make sure all the latest is green under that environment).

And yes, we are working on a multi-interpreter CI - it is well underway.
Stay tuned :)

-- Chad

--~--~-~--~~~---~--~~
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: [CruiseControl] rails build a79790e failed

[Chad Woolley]

On Mon, Aug 31, 2009 at 9:19 PM, Ryan Bigg (Radar)
radarliste...@gmail.comwrote:

 PUBLIC HUMILIATION!!!


Hehe, this one is because the gem didn't propogate yet.  But now we know it
works  Beware!

-- Chad

--~--~-~--~~~---~--~~
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: [CruiseControl] rails build a79790e.2 failed

[Chad Woolley]

On Mon, Aug 31, 2009 at 10:06 PM, thewoolley...@gmail.com wrote:


 The build failed.

 CHANGES
 ---
 Build was manually requested.



The Build Now button is tempting, but there's no need to click it.  It
will build automatically on the next commit :)

--~--~-~--~~~---~--~~
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: SQLite2 version in CI?

[Chad Woolley]

On Fri, May 22, 2009 at 4:24 PM, Jason King smathy.w...@gmail.com wrote:

 Can someone tell me which version of sqlite is used on the CI
 machine?  (Or, even better, how to find out?)

 I'm seeing what looks like a bug in my 2.8.17 for the
 last_insert_rowid() function with the high PKey IDs that the test
 fixtures receive.

2 and 3.  Look at the environment info output at the end of the build log.

--~--~-~--~~~---~--~~
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: SQLite2 version in CI?

[Chad Woolley]

On Fri, May 22, 2009 at 4:37 PM, Jason King smathy.w...@gmail.com wrote:
 So now I'm confused, because my test fails with the same versions of
 SQLite2 and same sqlite-ruby gem as the CI machine.  I can reproduce
 the bug in last_insert_rowid() directly in SQLite2 (by using those
 large ids) so I have to conclude that the CI machine is not generating
 the same large ids.

 Maybe this is a rake version issue, my rake is 0.8.4 and the CI's is
 0.8.3.  Is rake the thing that generates those big fixture ids?  More
 digging (unless someone who is still reading knows :)

If you want to temporarily add a build pointing at your repo for debug
purposes, I can do it.  Contact me offline...

-- Chad

--~--~-~--~~~---~--~~
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] CI build fix

[Chad Woolley]

I believe this:

https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/2686-fix-ci-build-patch-fix-eager-association-test-related-to-different-ordering-on-sqlite

fixes the only (current) build failure for master branch:

http://ci.rubyonrails.org/builds/rails

-- Chad

--~--~-~--~~~---~--~~
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] Fwd: [CruiseControl] rails build 01d7acd fixed

[Chad Woolley]

Yay :)


-- Forwarded message --
From:  thewoolleyman+rail...@gmail.com
Date: Sun, May 17, 2009 at 1:06 PM
Subject: [CruiseControl] rails build 01d7acd fixed
To: thewoolley...@gmail.com


The build has been fixed.

CHANGES
---
Revision ...01d7acd committed by Joshua Peek j...@joshpeek.com on
2009-05-17 19:42:36

   Fix reset_session with ActiveRecord store [#2200 state:resolved]

 .../test/activerecord/active_record_store_test.rb  |    6 +++---
 activerecord/lib/active_record/session_store.rb    |   10 +-
 2 files changed, 12 insertions(+), 4 deletions(-)



See http://ci.rubyonrails.org/builds/rails/01d7acd for details.

--~--~-~--~~~---~--~~
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: Edge Rails not working!

[Chad Woolley]

On Tue, Apr 28, 2009 at 2:51 AM, Michael Koziarski
mich...@koziarski.com wrote:
 Some of us are having problems running vendored edge Rails.

 Edge rails is likely to be a rough ride for a while until the
 refactoring for 3.0 slows down.  You should probably track 2-3-stable
 instead.

The CI build for edge is green:

http://ci.rubyonrails.org/

If you are having problems, please submit a patch with a failing test
that illustrates the problem.

Also, I just added the 2-3-stable branch to CI (which is green, yay!)

-- Chad

--~--~-~--~~~---~--~~
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: [Ruby on Rails #1642] HasOneThroughAssociation should not be a child of HasManyThroughAssociation

[Chad Woolley]

On Wed, Apr 22, 2009 at 10:51 AM, Pratik pratikn...@gmail.com wrote:

 Which problem is it solving for you ? Do you see any performance gains
 that I'm missing ? Do you believe if this is making any code easier to
 understand ? Could you please provide failing tests which are to be
 fixed by the refactoring in question ?

I believe that Adam already addresses many of these points in his original post:

This inheritance relationship has already caused its share of bugs, as
mentioned by commenters on the ticket.  I fixed two here:
http://rails.lighthouseapp.com/projects/8994/tickets/895-has_one-through-errors.
More importantly, the added complexity created by importing all of the
collection logic and interface into a non-collection association class
just adds to rigidity and potential for odd bugs in the future.

It is hard to write a failing test for bugs that don't exist, but the
existence of prior already-fixed bugs should be considered as a
motivation for doing the refactor.

Furthermore, the existence of bugs isn't normally the primary
motivation for refactoring - but they are a symptom of a needed
refactoring.  Complex, hard-to-understand code is a direct motivation
for refactoring, which I think is the point here.

-- Chad

--~--~-~--~~~---~--~~
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: Tests and the Rails 3 effort

[Chad Woolley]

On Thu, Apr 16, 2009 at 9:03 AM, Yehuda Katz wyc...@gmail.com wrote:
 2.3 application. We're obviously not done yet (by any stretch), but if
 you go through the new_base specs, I think you'll be pleased with our
 thoroughness.

 I'd be happy to answer any other questions you might have.

I'd like to see the CI build kept green through these efforts:

http://ci.rubyonrails.org/builds/rails

Is that feasible, or are things in transition and you are planning to
getting back to green at some future point?

Thanks,
-- Chad

--~--~-~--~~~---~--~~
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: Tests and the Rails 3 effort

[Chad Woolley]

On Fri, Apr 17, 2009 at 1:09 AM, Chad Woolley thewoolley...@gmail.com wrote:
 I'd like to see the CI build kept green through these efforts:

 http://ci.rubyonrails.org/builds/rails

Ah, it is green again.  Nice :)

-- Chad

--~--~-~--~~~---~--~~
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: Improving Testing in rails and ruby as a probable GSOC project

[Chad Woolley]

On Sun, Mar 29, 2009 at 12:13 PM, kaluza_klein abhassar...@gmail.com wrote:
        One of the ideas implemented to a certain extent and suggested
 is by brynary to parallelize testing and using bonjour for auto
 discovery of test servers.

Shared test server farms are a lot of work and effort to get right.  I
was just discussing this with someone yesterday.  This is even more so
in the ruby world, where the environment can be really touchy (a wrong
gem version and everything can fall apart, unless you vendor your
entire world or lock down every dependency version, neither of which
are very practical - and this isn't even considering native dependency
versions such as imagemagick, browser versions, etc, etc).

Before going down this road, you should carefully weigh the costs of
dedicated test hardware (which is very fixed, especially with cloud
computing) against the engineering labor to maintain reliable shared
test servers, and all of the associated environment-management issues.
 Are you really going to save money, effort, complexity, and time in
the long run?

-- Chad

--~--~-~--~~~---~--~~
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: Plugin migrations - simplest approach

[Chad Woolley]

On Thu, Mar 12, 2009 at 9:10 AM, Tekin Suleyman te...@tekin.co.uk wrote:
 This looks good to me, much neater than having separate tables or extra
 columns to maintain migrations from plugins.I think it's perfectly
 reasonable to expect a user of a plugin to copy the migrations that creates
 the models to their db/migrations directory.

Unnecessarily copying a file from a plugin seems wrong.  Referencing
plugin migrations from your app (as Desert does) seems right.

-- Chad

--~--~-~--~~~---~--~~
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: Testing to prevent regression

[Chad Woolley]

On Tue, Feb 24, 2009 at 12:41 PM, Manfred Stienstra manf...@gmail.com wrote:
 My first intuition is to spawn new Rails process from a test and see
 if it behaves the way it should. I'll try to free up some time
 tomorrow to give it a try.

The tricky part of this would be to ensure that the spawned
environment is identical to the current environment.  For example,
environment/rake variables, ruby interpreter being used, etc, etc.

-- Chad

--~--~-~--~~~---~--~~
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: Railties tests

[Chad Woolley]

On Tue, Feb 10, 2009 at 4:46 PM, Nick Hoffman n...@deadorange.com wrote:

 Are the Railties tests current and passing at the moment? I ask
 because I found an old thread saying that they're neglected [1], but I
 can't find any recent discussions.
 -Nick

 [1] http://tinyurl.com/acuhkr

Well, SOME of them are running and passing as of right now.  See
http://ci.rubyonrails.org/builds/rails , open Build Log, and search
for RailTies.  Look in /ci/ci_setup_notes.txt for a procedure to
reproduce a working test environment.

-- Chad

--~--~-~--~~~---~--~~
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: Make rake gems:build respect Rails.env

[Chad Woolley]

On Sun, Jan 25, 2009 at 9:08 AM, Josh Susser j...@hasmanythrough.com wrote:

 This is a good improvement, but I dislike that building gems loads the
 environment at all.  If something in your environment file uses a
 class defined in a gem, you get a circular dependency where you need
 the gem you're trying to build in order to build gems at all.  Seems
 like the only way out of this is to move the config.gem stuff into a
 separate file that can be used during the environment booting/
 initialization, or for building gems without the environment.

Exactly.  I expounded upon this at mind-numbing length in this ticket:

http://rails.lighthouseapp.com/projects/8994/tickets/59-when-loading-a-plugin-via-rubygems-rake-tasks-aren-t-included

Summary:

1. Bottom line, the config.gems logic should be completely decoupled
from environment, and invokable from preinitializer.rb.  Anything else
will be subject to circular dependencies.

2. Obligatory mention of GemInstaller, which does exactly this, very
successfully, for many production apps, and predates config.gems (and
is the reason I wrote the preinitializer.rb patch)

Thanks
-- Chad

--~--~-~--~~~---~--~~
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: Integrity for CI instead of CC.rb?

[Chad Woolley]

2009/1/14 Mike Gaffney mr.ga...@gmail.com:
 We've been looking at switching to integrity as well. One of the major
 benefits I see at the moment is that integrity would likely be more willing
 to accept features.

We are running the ci.rubyonrails.org off my ccrb GitHub branch, and
it's possible that ThoughtWorks would add some committers.  I don't
think that's a big concern long term.


 On a separate note, I think it would be beneficial to have an easy, built in
 way to run YOUR app against edge or latest of a given branch (like
 2.2-stable). I think this would do 2 things:
 1) Encourage more people to have their apps in CI
 2) Cause people to see changes in the core that affect their apps. This
 would get more, and more immediate feedback to the core team about commits.

Yep, this would be great, and I've put a lot of thought into how to do
this.  We (my employer) already do this on our internal projects - we
have the ability to automatically run against multiple rails versions
or edge without modifying source/unfreezing/refreezing/etc.

As I mentioned before, this can be as easy as creating an new ccrb
project with the desired rails version in the ccrb project name - e.g:
'rails_rel_2.1.0', 'rails_rel_2.2.0', 'rails_rel_edge' (although we
don't do edge yet).  You can hack the cruise.rake to incorporate this
into the build, and leverage GemInstaller to activate the appropriate
rails gem via config/preinitializer.rb.  Here's a live example where I
use this approach [1] to test GemInstaller against multiple RubyGems
versions [2].  Here is a gist showing the same approach for a rails
app [3].  Note again that there would be no
editing/freezing/unfreezing/installing/uninstalling involved to
continuously test against multiple versions - running CI against a new
version is a simple as creating the ccrb project with the appropriate
name.

Even cooler would be extending this to plugins and gems - ensuring
that your app works against the edge of not only rails, but all the
plugins and gems you are using.  That way, you can be very proactive
about dealing with breaking changes (or sending them patches which do
things in a different way that doesn't break you).

However, this involves a much more involved infrastructure of
automatically building gems whenever source is changed, which is also
a great place to leverage CI.  I've discussed this some with Koz in
the past - automatically building a nightly rails gem which would
facilitate the approach I mentioned above.  You could use git
submodules/piston/braid/giternal to accomplish the same thing with
frozen edge rails/plugins, which is why I asked how Integrity handled
this.

[1] http://geminstaller.rubyforge.org/svn/trunk/cruise_config.rb
[2] http://ci.thewoolleyweb.com/
[3] http://gist.github.com/47004

Thanks,
-- Chad

--~--~-~--~~~---~--~~
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: Integrity for CI instead of CC.rb?

[Chad Woolley]

On Tue, Jan 13, 2009 at 9:05 PM, Jeremy McAnally
jeremymcana...@gmail.com wrote:

 Hey guys and gals,
 I suggested that perhaps we should use Integrity
 (http://github.com/foca/integrity) for the CI for Rails rather than
 CC.rb.  DHH said he was all for it, but I should bring it before you
 all before he made a decision.

I'm open minded.  As Koz said, I've done most of the work myself, with
some help from Mike Gunderloy.  We (my company) use ccrb mostly by
default, because it used to be the only mature, fully-featured CI
server in Ruby.  Apparently that isn't the case anymore, which is a
Good Thing!

If using Integrity means that more people will be on board with
supporting CI (which primarily means making sure Rails Core applies
patches to keep it green), then I'm in favor of it.  There are a few
things that ccrb does have going for it that I wouldn't want to lose,
though - I'll mention those later.

I also wrote Cinabox
(http://github.com/thewoolleyman/cinabox/tree/master) which makes it
almost a complete no-brainer to set up ccrb on a clean Ubuntu distro
(just two scripts and everything is running, including a working init
script)


 So, here's why I like Integrity:
  1. It needs less hacking to do interesting things.  For example,
 multiruby support would be dead simple to setup, which is something we
 really need.

Is this really any easier than ccrb?  Once you have the multiple
interpreters installed (with multiruby or something like cinabox's
bootstrap_ruby script, that's another discussion), most of the work is
kicking off the build with the proper environment.  As Integrity's
homepage says: as long as your build process can be run from an
unix-y environment and it returns a zero status code for success and
non-zero for failure, then integrity works for you.

For the rails build, this is just ci_build.rb
(http://github.com/rails/rails/blob/9bcf01b23c25e640da7908ac8b1b49fbf7d2e51a/ci/ci_build.rb)
-  it doesn't matter what CI tool you use to invoke it, as long as you
can pass some env or param to indicate the interpreter to use.  I've
hacked ccrb build scripts to dynamically take this from the ccrb
project name via env var, which is a slick way to do it.  That (plus
GemInstaller) is how I handle dynamically building against multiple
rails gem versions without modifying any source code or re-freezing.

  2. Adding different sorts of notifiers to it is really easy.  Being
 able to dump CI reports into IRC, Campfire, etc. without a lot of
 hassle would be awesome.

CCRB is also fairly extensible, and it's all Ruby, so it is a wash in
terms of feasability.  However, if Integrity already has all these
working and mostly bug-free, then that is a plus.

  3. It's really lightweight.

This is actually pretty compelling.  CCRB is in rails, and it loads
the rails env for each builder, which is a significant memory overhead
on low-memory servers running several builds.


 There are a number of other reasons I prefer it, but these hit the
 main technical ones.  The others are mostly opinion. :)

 What do you all think?

Here's the things that I'd like to confirm before I commit to it:

* A working debian-based init script that is shipped with the project.
 By working, I mean it works seamlessly on reboots, on killed servers
(no stale pids - e.g. mongrel cluster not mongrel), and standard
start-stop-restart.  Cinabox + ccrb handles all this automatically -
e.g. just run setup_ci.rb and all the init script is working.  Full
disclosure, the stale pid problem still isn't fixed in ccrb's init
script if the mongrel is killed.

* Updated docs in rails
(http://github.com/rails/rails/blob/9bcf01b23c25e640da7908ac8b1b49fbf7d2e51a/ci/ci_setup_notes.txt)
that explain exactly how to set up integrity.  Preferably, this will
be by adding an integrity flavor to cinabox - currently the
ruby/ccrb server setup in the previous doc is one line:  Use cinabox
to perform rest of ruby/ccrb setup:, which consists of naught but
downloading cinabox and running two command line scripts.

* Git support:  Is git support rock solid?  How about for multiple
non-master branches?  Because it took a lot of hacking from various
people to get all the known bugs out of ccrb's git support.

* How about git submodules/piston/braid/giternal?  Specifically, can
it automatically trigger a build based on changes in a
submodule/pistonized/braidified/giternal?  This is completely
unrelated to the Rails build, but something that would make me really
want to switch to Integrity for my other CI projects :)

* I want to be disciplined about having EVERYTHING repeatable on a
clean Ubuntu server via /ci/ci_setup_notes.txt.  In other words, I
DON'T want to take the approach of hacking and manually installing
crap on the CI server and nobody knows what is running or how.  I want
to be able to completely blow away the server and have it back up and
running by following the ci_setup_notes.txt exactly.  This lets other
people reproduce the rails CI environment on 

[Rails-core] Re: tzinfo-0.3.11 bundled with activesupport-2.1.2 is incomplete

[Chad Woolley]

On Tue, Nov 18, 2008 at 8:57 AM, Geoff B [EMAIL PROTECTED] wrote:


 Adam and Chad -- curious to know if this setup would work for you:


I was just bikeshedding about the dubiousness of bundling a hacked version
of a dependency gem in another gem, and adding code manage the resulting
problems.  I didn't actually have a personal problem (with tzinfo).  Thanks,
though :)

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] Re: tzinfo-0.3.11 bundled with activesupport-2.1.2 is incomplete

[Chad Woolley]

On Thu, Nov 13, 2008 at 12:25 PM, Adam Greene [EMAIL PROTECTED] wrote:

 If I'm the only one who was bit by this issue, then so be it.  But if
 it keeps coming up, putting the full gem (with the extra 2.6 megs and
 hundreds of files; yes it is a beast!) into vendor/ doesn't seem to be
 all that bad, in this day and age of broadband ;)


It isn't just the download bandwidth, it's moving around and storing that
extra 2.6 meg for every checkout, branch, deployment, release, and backup
for every rails app, everywhere, forever, not to mention the few extra
split-seconds on every full-project search.  CPU, diskspace and bandwidth
are cheap, but not infinite, and it adds up when you think of it that way.
That's why I prefer to freeze nothing ;)

-- Chad

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] Re: tzinfo-0.3.11 bundled with activesupport-2.1.2 is incomplete

[Chad Woolley]

On Tue, Nov 11, 2008 at 7:27 AM, Geoff B [EMAIL PROTECTED] wrote:


 Adam,

 The bundled tzinfo is a slimmed-down version that only includes the
 classes and zone definitions necessary to support
 ActiveSupport::TimeZone. This chops ~2.8MB from the size of tzinfo,
 and hundreds of files, so it seems worth it.


Why does it need to be bundled rather than be a normal gem dependency?

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] Re: tzinfo-0.3.11 bundled with activesupport-2.1.2 is incomplete

[Chad Woolley]

On Tue, Nov 11, 2008 at 4:57 PM, Geoff B [EMAIL PROTECTED] wrote:


 On Nov 11, 2:02 pm, Chad Woolley [EMAIL PROTECTED] wrote:
  Why does it need to be bundled rather than be a normal gem dependency?

 By bundling tzinfo, everything works out of the box -- if you freeze
 rails into vendor, you can then deploy anywhere, even on boxes that
 don't have rails or tzinfo installed.


Right, but why is tzinfo special?  Because it is the only non-rails
dependency for rails itself.  Seems like the root cause of the problem is
that rails freeze command is broken, because it does not freeze the entire
dependency graph of rails, which includes tzinfo.  Instead, the rails freeze
command should freeze whatever version of the tzinfo gem is specified by the
current version of activesupport.  Then, you get all the benefits and no
problems:

1. Rails is not packaging a hacked version of tzinfo
2. Since tzinfo is not bundled, you don't need to use a hacked smaller
version, you can just depend on the real gem
3. People who want to manage tzinfo via gems using whatever version they
want can do so (which is the original bug report here)
4. People who want to freeze rails will automatically get the real, correct
version of tzinfo frozen as well - and shouldn't care if this is big,
because people who freeze gems will have ginormous apps regardless...

-- Chad

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] Re: Version Numbers for the RC Release

[Chad Woolley]

On Thu, Oct 23, 2008 at 4:53 AM, Michael Koziarski [EMAIL PROTECTED]wrote:

 * 2.2.0 for RC1
 * 2.2.0.N for RCN
 * 2.2.1 for Final 2.2 release


+1

It might be more consistent to make RC1 be 2.2.0.1, but this is fine.

The basic idea is that 2.1 is not 2.2.  If people want to stay on 2.1, or do
a version check (for backward compatibility code in a plugin, for example),
they can do checks like this =2.1.0, and not pick up any RC or release
version =2.2.0

For more info on this topic, see the rubygems manual and ZenSpider's post:

http://www.rubygems.org/read/chapter/16

http://blog.zenspider.com/2008/10/rubygems-howto-preventing-cata.html

Thanks!
-- Chad

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] Re: config.gem and Rake tasks

[Chad Woolley]

On Fri, Oct 17, 2008 at 7:58 AM, Damian Janowski
[EMAIL PROTECTED]wrote:


 Hey all,

 So currently there's no way to automatically get Rake tasks from your
 config.gems.

 Issue and discussion here:
 http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/59

 If we do this, then I guess we could just load that initializer (if it
 exists) passing a config object and figure out which gems are
 installed and then add their rails/tasks to Rake.

 Thoughts?


I just put a big comment on the ticket with my thoughts.

Basically, I think preinitializer.rb should be used to activate gems,
whether that is manually via the 'gem' method, through some call to an
initialization-decoupled version of the config.gems code, or some third
party tool like GemInstaller.

The rails initialization code should be structured (if it is not already) to
process the loaded gems, init files, rake tasks, etc that are already on the
load path, regardless of how they got there (it can be any method as long as
it is called from preinitializer.rb before any initialization happens).

Thanks,
-- Chad

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] Re: missing config.gem

[Chad Woolley]

On Sat, Sep 20, 2008 at 8:46 PM, Blake Watters [EMAIL PROTECTED] wrote:
 If the optional gem is common, why not a config.optional_gem method? Covers
 all bases explicitly and succinctly.

This was discussed in a recent thread.  Rubygems already provides a
way to flag development gems.  Aside from that, any determiniation of
optional is developer-, platform- or environment- specific, and is
best handled with custom code in the environment file(s).  In any of
these cases, you would need some custom code anyway to determine
whether the non-development optional dependency is actually required
or not (inclusion in a specific environment file rather than
environment.rb, platform check, env var check, etc).  So, if you need
custom code anyway, just write your own conditional to not even
execute the optional config.gem call.  No need for a separate method.

-- Chad

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] Re: coercions of blank strings to boolean and integer values

[Chad Woolley]

On Tue, Aug 19, 2008 at 4:58 AM, Chris Cruft [EMAIL PROTECTED] wrote:
 Putting the burden on ActiveRecord to massage the crap it is handed
 into something meaningful seems out
 of place.  Why not fix the problem at the source and get
 ActionController to return meaningful values from empty form fields?

I agree.  This follows the guideline of validate early, which is
generally a good one.

Also, it makes sense to handle it early if you were to use another
persistence layer.  This is a UI-layer problem, solve it close to the
UI.

-- Chad

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] Re: wiki.rubyonrails.org

[Chad Woolley]

On Thu, Jul 17, 2008 at 8:37 PM, Jeremy McAnally
[EMAIL PROTECTED] wrote:
 If you know of a mythical large group of people who want to write
 docs, then please whip them into a documentation fury and unleash them
 upon Rails.

These people have a lot of time on their hands, go ask for volunteers
on Pradiptas Rolodex (yes, I was on the original email):

http://blog.reverberate.org/2008/07/17/416-random-people-with-ror-on-their-resume-reply-all-reverse-flash-mob/

-- Chad

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] Re: config.gem implementation

[Chad Woolley]

On Mon, Jul 7, 2008 at 1:20 PM, Dan Manges [EMAIL PROTECTED] wrote:
 Thoughts?

Use GemInstalller from config/preinitializer.rb and I believe all
these problems go away (let me know if they don't, and feel free to
ask/open bugs).

-- Chad

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

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

[Chad Woolley]

On Fri, Jul 4, 2008 at 10:39 PM, zilkey [EMAIL PROTECTED] wrote:

 I think loading the environment with db:create and db:drop is
 unnecessary.  I've run into scenarios where a plugin does some
 initialization based on the database and raises exceptions if there is
 no database (ultrasphinx and acts_as_ferret are two that come to
 mind).

+1 on this comment, and I don't think this should be considered a
plugin design flaw.

This thread is like deja vu of the database.yml vs. environment config thread.

I still believe that any *external* dependencies or resources
(databases, gems) should get special treatment.  In other words, if
there is a dependency which is external to the app, any rails
provisions for  managing it should not be dependent on the app
initializing first.  Otherwise, it's a chicken and egg problem.
That's why db:create should not depend on the app initializing, and
also (shameless plug) why I'd prefer the GemInstaller (which has
standalone as well as integrated invocation options) over config.gems
for managing gems, including the Rails gem(s) itself :)

-- Chad

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] Re: Problem with generated tests

[Chad Woolley]

On Tue, Jun 24, 2008 at 7:21 AM, Rob Sanheim [EMAIL PROTECTED] wrote:
 Great, only three places to check for core discussion now!
 Lighthouse, github, and here. ;)

Well, a ticket system and a mailing list are pretty traditional for
Open Source projects.

But using your SCM as a messaging platform?  Come on, that's taking
the social networking thing too far...  I pray that I never see the
official Twitter channel for an open source project I care about,
because I ain't going there...

-- Chad

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] Re: Out with database.yml

[Chad Woolley]

On Thu, Jun 12, 2008 at 3:47 AM, Rick Olson [EMAIL PROTECTED] wrote:
 In a similar vein: last night at the Baltimore ruby group, John
 Trupiano suggested some way of merging the yml files from the
 geminstaller gem with Rails' gem configurations.

I've wanted to provide a non-YAML config option for GemInstaller for a
while, but it is down on the priority list.  And, as pointed out, if
the config is in Ruby (as it is with config.gems), then it's still
easy to parse a YAML file (such as geminstaller.yml) to generate that
config.  That's probably the best approach to support what John
wanted, and would be cool to have in Rails by default (patch
someone?!?)

After reading this thread, I'm convinced that both Ruby and YAML
config should be supported (so I retract my -1 if that will be the
case).  All-ruby config is cool and nice, but for metadata describing
external dependencies (Gems, Databases), there should be a
STANDARDIZED, easily parsable, non-Ruby format supported as well.

So, I hope Rails still natively supports the old YAML format after
this patch, to support old tutorials, and to provide a standardized
option when it is needed, such as Rails parsing geminstaller.yml if it
exists, or a hosting company parsing geminstaller.yml or database.yml
to auto-configure whatever...

Also, I still don't think either option is DRY-er than the other,
because YAML supports reuse, as was just pointed out.

-- Chad

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] Re: Out with database.yml

[Chad Woolley]

On Thu, Jun 12, 2008 at 7:45 AM, John Trupiano [EMAIL PROTECTED] wrote:
 This is, in fact, the same idea Rick mentioned that I proposed.  I
 suggested moving gem configuration out into a YAML file (or at least
 adding a hook for this).  Why?  Because then capistrano could read in
 that file and ensure that deployment environments have the proper
 versions of gems, etc.  In other words, I could stop a sure-to-fail
 deployment before I actually re-deploy.  (There's a lot more to this,
 but not so much core-related)  I had proposed a config extension along
 the lines of:

 config.gem_file config/gems.yml

Totally off topic at this point, sorry, but anyway...

John and I hacked on this a bit this morning.  The conclusion is that
there is no reason to do what he said above.  GemInstaller.autogem
already does everything you want if you desire to manage your gems
from YAML.  See:

http://geminstaller.rubyforge.org/faq.html#rails_config_gems
http://geminstaller.rubyforge.org/documentation/tutorials.html#integrating_geminstaller_into_ruby_on_rails

Thanks!
-- Chad

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] Re: Out with database.yml

[Chad Woolley]

On Thu, Jun 12, 2008 at 1:25 PM, Adam Keys [EMAIL PROTECTED] wrote:
 It seems there are a lot of deployment-time concerns here. Would it
 help if there was a Rake task to dump database.yml for a given
 environment?

This ALMOST sounds like a good idea, but this really would be non-DRY,
in a dangerous way.  Is the database.yml I dumped (or someone else
dumped) up-to-date? How do I know?  When do I re-dump? Who re-dumps?

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] Re: Where is the ActiveRecord Oracle Adapter with 2.1?

[Chad Woolley]

On Thu, Jun 12, 2008 at 1:23 PM, SandroDS [EMAIL PROTECTED] wrote:

 In a different box:

 rm -rf ~/.gem

 gem --version
 1.1.1

 sudo gem install activerecord-oracle-adapter --source 
 http://gems.rubyonrails.org
 ERROR: could not find activerecord-oracle-adapter locally or in a repository

 What gives?

Run the prior commands as sudo.  Root  has a different ~/.gem.

Also, try gem list --remote --source source gem name, on some
different boxes, as non-root, after deleting ~/.gem

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] Re: Out with database.yml

[Chad Woolley]

On Wed, Jun 11, 2008 at 5:58 PM, Matt Palmer [EMAIL PROTECTED] wrote:
 If anything, this patch is anti-DRY because it locks up the database config
 in a place that can only be read by Rails.  If you've got anything other
 than Rails that wants to talk to the database (cron jobs, other apps,
 whatever) YAML is a far better way to store your credentials than a chunk of
 Rails code (it's not even plain Ruby, because you need umpteen lines of
 scaffolding to evaluate it and get the values out of it).  Practically
 anything can parse YAML, nothing except Rails can parse Rails.

-1

I agree.  We have utilities which parse database.yml for rake tasks
and other batch jobs.  An example (which we use on a daily basis) is a
utility to automatically pull and import a production database to the
local dev database, for easy testing against production data.

database.yml is metadata about an external resource.  It makes sense
to put that metadata in a DRY, easily-parsable format which can be
used by things other than the Rails app itself.

As the previous poster mentioned, I can imagine this approach making
life harder for many rails hosting providers as well.  I don't think
this is a good approach to encourage or propogate.

-- Chad

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---

[Rails-core] Re: Out with database.yml

[Chad Woolley]

On Wed, Jun 11, 2008 at 6:22 PM, Scott Bronson [EMAIL PROTECTED] wrote:
 And it's just as easy to store your database config in XML, CSV, LDAP,
 or another database.  Your deployment options are wide open.  Really,
 this patch frees the database config.  Where's the downside?

Because then it is nonstandard (again, making it hard for hosting
companies to provide standardized auto-deployment).

Convention over configuration.

-- Chad

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~--~~~~--~~--~--~---