Re: [Rails-core] [Feature Request] Force minimal unit in number_to_human_size

[Kerri Miller]

How about "unit" instead of "minimal"?

-k-

On Sat, Sep 20, 2014 at 9:46 PM, Damian Nowak  wrote:

> I'd want to show "0 MB" instead of "0 Bytes" when presenting the space and
> memory used by virtual machines in VirtKick .
> It doesn't make big sense to be that byte or kilobyte-specific in that.
> Please provide feedback and  let me know if you want me to implement it in
> NumberToHumanSizeConverter.
>
> number_to_human_size(123, minimal: :mb) # => 0 MB
> number_to_human_size(1234, minimal: :mb) # => 0 MB
> number_to_human_size(12345, minimal: :mb) # => 0.01 MB
> number_to_human_size(123456, minimal: :mb) # => 0.12 MB
> number_to_human_size(1234567, minimal: :mb) # => 1.18 MB
> number_to_human_size(1234567890, minimal: :mb) # => 1.15 GB
> number_to_human_size(1234567890123, minimal: :mb) # => 1.12 TB
>
> (Assumed the default precision of 2)
>
>
> Damian
>
> --
> 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] proposal: deprecate save() in favor of save!()

[Kerri Miller]

OP - Would it clarify the issue in your mind if

"Saves the model."

were changed to

"Attempts to save the model."

-k-


On Tue, Jun 23, 2015 at 7:36 AM, Jason Fleetwood-Boldt  wrote:

> Generally nearly all of the Jr. devs I work with know this, this is very
> basic to the early learning process of working with Rails.
>
> Most code I see uses the* if @foo.save … else … end* style in almost all
> cases and does flow control based on the return value of save.
>
> -Jason
>
>
>
> On Jun 22, 2015, at 5:39 PM, Ryan Bigg  wrote:
>
> Changing this method's name reeks of bikeshedding.
>
> Any one with more than a day's worth of Rails experience knows the
> difference between these two methods and how to use them.
>
> In my experience, the return value for save is almost always checked.
>
> If we deprecate save and then have only save!, you would be encouraging
> the use of exceptions as flow control and that's well-known as a coding
> smell.
>
>
>
> On 23 Jun 2015, at 00:27, Rafael Mendonça França 
> wrote:
>
> I think the documentation is very clear about this:
>
> Saves the model.
> If the model is new a record gets created in the database, otherwise the 
> existing record gets updated.
> By default, save always run validations. If any of them fail the action is 
> cancelled and save returns false.
>
> If it is not we should fix the documentation but for me it is not a good
> idea to rename save to try_save. The Rails conventions for bang methods
> are clear.
> ​
>
>
> On Mon, Jun 22, 2015 at 11:24 AM pseidemann  wrote:
>
>> hello,
>>
>> currently in rails you have two methods to save a record: `save` and
>> `save!`.
>> I think `save` is often used wrong because the return value is not always
>> checked.
>> even the documentation is not very clear about the subtle different about
>> the two methods. for `save` the first sentence is:
>> > Saves the model.
>>
>> it's not clearly mentioned there that it will _not_ save the model at all
>> when validation fails. so developers will introduce bugs when not always
>> checking for the return value e.g. in delayed job methods or in rake tasks
>> (or maybe even in controllers).
>>
>> my proposal would be to deprecate the usage of `save` and introduce a new
>> method called `try_save` which has the same implementation as the old
>> `save` method. this would make the implementation and the usage of the
>> saving method more clear.
>>
>> what do you think?
>>
>> ---
>>
>> post transferred from https://github.com/rails/rails/issues/20662
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to rubyonrails-core+unsubscr...@googlegroups.com.
>> To post to this group, send email to rubyonrails-core@googlegroups.com.
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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] rake stats

[Kerri Miller]

:+1: -- I don't know of any technical reason why not.

-k-

On Wed, Jul 22, 2015 at 8:37 AM, Kevin Deisz  wrote:

> Is there a reason that rake tasks are not part of rake stats? We have a
> lot of different rake tasks and I'd like to have them show up in our
> statistics so we can monitor as they grow/change. I'd be happy to submit a
> PR for this if it would be accepted.
>
> --
> *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.
>

-- 
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] Magic number in tests

[Kerri Miller]

I could see an argument made for making it a constant in the _test_
(EXPECTED_MAX_PASSWORD_LENGTH), which at least would document /why/ the
number is being used.

On Tue, Jan 9, 2018 at 11:37 AM, Kasper Timm Hansen 
wrote:

> I’m -1 on changing that. I think the constant 72 is used directly such
> that tests will fail if anybody changes MAX_PASSWORD_LENGTH_ALLOWED.
>
> With your change in, a later change to MAX_PASSWORD_LENGTH_ALLOWED by some
> other contributor wouldn’t make any tests fail.
>
> Since that constant isn’t meant to change without us thinking more about
> it, I’d say we keep the code as is.
>
> Thanks for starting to contribute!
>
> Den 9. jan. 2018 kl. 09.56 skrev artur.belja...@internet.ee:
>
> Magic number 72 is used many times throughout the tests, which is actually
> present under ActiveModel::SecurePassword::MAX_PASSWORD_LENGTH_ALLOWED
> constant. I propose to replace that magic number either by the constant or
> method call.
>
> I have never contributed to such large open source project as Rails.
> Please let me know your thoughts.
>
>
>
> https://github.com/rails/rails/blob/master/activemodel/
> test/cases/secure_password_test.rb
> https://github.com/rails/rails/blob/ff657e73f0b61a7e224a9f158467ed
> 2ec915bd9b/activemodel/lib/active_model/secure_password.rb
>
> --
> 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.
>
>
> --
> Kasper
>
> --
> 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] Magic number in tests

[Kerri Miller]

Not to "well actually" myself but another option might be to use
MAX_PASSWORD_LENGTH_ALLOWED
as the OP suggested, but have an explicit test for
MAX_PASSWORD_LENGTH_ALLOWED=72..
which might actually be a better approach, since it'll isolate the exact
defect case (MAX_PASSWORD_LENGTH_ALLOWED != 72) rather than have it be
implied by a well-named-but-oddly-disconnected constant.

// Kerri

On Wed, Jan 10, 2018 at 3:19 PM,  wrote:

> I would be happy to do this!
>
>
> On Tuesday, January 9, 2018 at 10:30:41 PM UTC+2, Kasper Timm Hansen wrote:
>>
>> Yep, we could do that 👍
>>
>> Den 9. jan. 2018 kl. 12.39 skrev Kerri Miller :
>>
>> I could see an argument made for making it a constant in the _test_
>> (EXPECTED_MAX_PASSWORD_LENGTH), which at least would document /why/ the
>> number is being used.
>>
>> On Tue, Jan 9, 2018 at 11:37 AM, Kasper Timm Hansen 
>> wrote:
>>
>>> I’m -1 on changing that. I think the constant 72 is used directly such
>>> that tests will fail if anybody changes MAX_PASSWORD_LENGTH_ALLOWED.
>>>
>>> With your change in, a later change to MAX_PASSWORD_LENGTH_ALLOWED by
>>> some other contributor wouldn’t make any tests fail.
>>>
>>> Since that constant isn’t meant to change without us thinking more about
>>> it, I’d say we keep the code as is.
>>>
>>> Thanks for starting to contribute!
>>>
>>> Den 9. jan. 2018 kl. 09.56 skrev artur.b...@internet.ee:
>>>
>>> Magic number 72 is used many times throughout the tests, which is
>>> actually present under 
>>> ActiveModel::SecurePassword::MAX_PASSWORD_LENGTH_ALLOWED
>>> constant. I propose to replace that magic number either by the constant or
>>> method call.
>>>
>>> I have never contributed to such large open source project as Rails.
>>> Please let me know your thoughts.
>>>
>>>
>>>
>>> https://github.com/rails/rails/blob/master/activemodel/test/
>>> cases/secure_password_test.rb
>>> https://github.com/rails/rails/blob/ff657e73f0b61a7e224a9f15
>>> 8467ed2ec915bd9b/activemodel/lib/active_model/secure_password.rb
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Ruby on Rails: Core" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to rubyonrails-co...@googlegroups.com.
>>> To post to this group, send email to rubyonra...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/rubyonrails-core.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> Kasper
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Ruby on Rails: Core" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to rubyonrails-co...@googlegroups.com.
>>> To post to this group, send email to rubyonra...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/rubyonrails-core.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to rubyonrails-co...@googlegroups.com.
>> To post to this group, send email to rubyonra...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> Kasper
>>
>> --
> 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.