One of my favorite aspects of Ruby is how easy it is to write in a functional programming style, and including the scan operation would expand the number of use cases covered by functional methods.

I think this is the crux of the issue. Because #inject needs to evaluate every element in order to return a meaningful value, it can't be partially evaluated. The "scan" operation allows for partial evaluation.

You just blew my mind Marc-André. My code just went from idiotic to idiomatic.

A new class for containing value objects: it is somewhat similar to Struct (and reuses some of the implementation internally), but is intended to be immutable, and have more modern and cleaner API.

Time.new('2023-01-29 00:29:30') # => 2023-01-29 00:29:30 +0200

The method name is generated by replacing spaces with underscores. The result does not need to be a valid Ruby identifier though — the name may contain punctuation characters, etc. That's because in Ruby technically any string may be a method name. This may require use of define_method and send calls to function properly, but formally there's little restriction on the name.

Ruby 2.5+ If your substring is at the beginning of in the end of a string, then Ruby 2.5 has introduced the methods for this: delete_prefix for removing a substring from the beginning of the string delete_suffix for removing a substring from the end of the string

args: [:parent, :ransacker_args] do |parent, args|

Making MoneySerializer reloadable would be confusing, because reloading an edited version would have no effect on that class object stored in Active Job.

There, the module object stored in MyDecoration by the time the initializer runs becomes an ancestor of ActionController::Base, and reloading MyDecoration is pointless, it won't affect that ancestor chain.

I’ve heard-suggested that ActiveSupport, which does a ton of monkey-patching of core classes, would make potentially-nice refinements. I don’t hold this opinion strongly, but I disagree with that idea. A big value proposition of ActiveSupport is that it is “omnipresent” and sets a new baseline for ruby behaviors - as such, being global really makes the most sense. I don’t know that anyone would be pleased to sprinkle using ActiveSupport in all their files that use it - they don’t even want to THINK about the fact that they’re using it.

Let’s check out what the refinement approach looks like and why I consider it the best way to implement conversion wrappers.

under the name “conversion functions.” These exist in Ruby’s standard library - for example Array() is one that you’re likely to see in real code.

in the 10 years since they have been a part of Ruby, real life usages are astonishingly rare.

why not allow block forwarding without capturing: foo(&) foo(1, 2, &)

You can do an Nth root by raising to a fractional power. For example, the 4th root of 625 is 5. (BigDecimal(625)**(1.0/4.0)).to_f # => 5.0

Grape API

inline(:C)

When you call 'foo' in Ruby, what you're actually doing is sending a message to its owner: "please call your method 'foo'". You just can't get a direct hold on functions in Ruby in the way you can in Python; they're slippery and elusive. You can only see them as though shadows on a cave wall; you can only reference them through strings/symbols that happen to be their name. Try and think of every method call 'object.foo(args)' you do in Ruby as the equivalent of this in Python: 'object.getattribute('foo')(args)'.

def document(f): def wrap(x): print "I am going to square", x f(x) return wrap @document def square(x): print math.pow(x, 2) square(5)

We need to read the Signature header, split it into its parts (keyId, headers and signature), fetch the public key linked from keyId, create a comparison string from the plaintext headers we got in the same order as was given in the signature header, and then verify that string using the public key and the original signature.

bundle update rails-controller-testing --conservative. The –conservative flag says when updating this gem do no update any of its dependencies. Using the –conservative flag with bundle is really useful for minimizing changesets as well as avoiding upgrading things that you don’t need to upgrade.

class String alias strip_ws strip def strip chr=nil return self.strip_ws if chr.nil? self.gsub /^[#{Regexp.escape(chr)}]*|[#{Regexp.escape(chr)}]*$/, '' end end

There is no such method in ruby, but you can easily define it like: def my_strip(string, chars) chars = Regexp.escape(chars) string.gsub(/\A[#{chars}]+|[#{chars}]+\z/, "") end

Procs can't accept blocks as implicit arguments (the format you're trying). A proc can receive other proc objects as arguments, either explicitly, or using & arguments. Example: a = Proc.new do |&block| block.call end a.call() {puts "hi"}

ruby语言有什么样的美学特点？

has_scope :category do |controller, scope, value|  value != 'all' ? scope.by_category(value) : scope end

Mash duplicates any sub-Hashes that you add to it and wraps them in a Mash. This allows for infinite chaining of nested Hashes within a Mash without modifying the object(s) that are passed into the Mash. When you subclass Mash, the subclass wraps any sub-Hashes in its own class. This preserves any extensions that you mixed into the Mash subclass and allows them to work within the sub-Hashes, in addition to the main containing Mash.

foo = Foo.new(bar: 'baz') #=> {:bar=>"baz"} qux = { **foo, quux: 'corge' } #=> {:bar=> "baz", :quux=>"corge"} qux.is_a?(Foo) #=> true

by using symbols as keys, you will be able to use the implicit conversion of a Mash via the #to_hash method to destructure (or splat) the contents of a Mash out to a block

Hashie does not have built-in support for coercing boolean values, since Ruby does not have a built-in boolean type or standard method for coercing to a boolean. You can coerce to booleans using a custom proc.

Mash is an extended Hash that gives simple pseudo-object functionality that can be built from hashes and easily extended. It is intended to give the user easier access to the objects within the Mash through a property-like syntax, while still retaining all Hash functionality.

A SimpleDelegator instance can take advantage of the fact that SimpleDelegator is a subclass of Delegator to call super to have methods called on the object being delegated to. class SuperArray < SimpleDelegator def [](*args) super + 1 end end SuperArray.new([1])[0] #=> 2

As simple as Puppeteer, though even simpler.

I have been doing different things w/ Ruby for a couple of years now and the only bad thing I can say about it is that it makes programming in other languages feel awfully burdensome. = )

Benoit Daloze of TruffleRuby points out that this is all much easier to read if you define your Ruby internals in Ruby, like they do. He's not wrong.

Until now, we had a lot of code. Although we were using a plugin to help with boilerplate code, ready endpoints, and webpages for sign in/sign up management, a lot of adaptations were necessary. This is when Doorkeeper comes to the rescue. It is not only an OAuth 2 provider for Rails but also a full OAuth 2 suite for Ruby and related frameworks (Sinatra, Devise, MongoDB, support for JWT, and more).

The process used to create an OAuth wrapper client is very simple.

def with_something prepare yield on_success end any return, break or throw would skip the on_success code. Skipping over the on_success code also seems quite reasonable when the block calls break and throw. It may not seem like the obvious behaviour for return, but perhaps it is a safe assumption to make in general to think of return as aborting the method yielding to the block. It might be desirable to discourage the use of return in this way for transactions to keep the code clearer, but that would also affect the use of break which seems like a reasonable way to abort a transaction from within the transaction block.

If you're nested inside several blocks and can't use next, rather extract the contents of the transaction into its own method and use return there.

Test.new.test { puts "Hi!" }

You cannot use yield inside a define_method block. This is because blocks are captured by closures, observe: def hello define_singleton_method(:bye) { yield } end hello { puts "hello!" } bye { puts "bye!" } #=> "hello!"

This breaks the TIMTOWTDI rule

The language was designed with this idea in mind, in that it “doesn't try to tell the programmer how to program.”

Note that one extra type that is accepted by convention is the Boolean type, which represents both the TrueClass and FalseClass types.

opts = method(__method__).parameters.map(&:last).map { |p| [p, eval(p.to_s)] }.to_h SomeOtherObject.some_other_method(opts)

that's right, we don't want to do params = { ... } because then we're hardcoding the implementation and it becomes very coupled. The benefit of doing it like in my examples is that you can change the method signature and still automatically capture all keyword parameters.

Ruby 2.2 introduced Binding#local_variables which can be used instead of Method#parameters

def initialize_copy(original_animal) self.age = 0 super end def initialize_dup(original_animal) self.dna = generate_dna self.name = "A new name" super end def initialize_clone(original_animal) self.name = "#{original_animal.name} 2" super end

But this sounds like spreading fear and doubt when the Ruby parser has no such concepts :) {} always binds tightly to the call right next to it. This block {} will never go to using, unless it's rewritten as do ... end.

@path.yield_self(&File.method(:read)).yield_self(&Parser.method(:new)) ...

Aligning everything with however long the method name is makes every indention different. belongs_to :thing, class_name: 'ThisThing', foreign_key: :this_thing_id has_many :other_things, class_name: 'ThisOtherThing', foreign_key: :this_other_thing_id validates :field, presence: true Compared to the following, which all align nicely on the left. belongs_to :thing, class_name: 'ThisThing', foreign_key: :this_thing_id has_many :other_things, class_name: 'ThisOtherThing', foreign_key: :this_other_thing_id validates :field, presence: true

I said I wanted begin..end to follow the same indentation principles as if..end because they are semantically related (both are expressions), and I stand by that opinion.

really begin/end is just a way to pass several expressions where you normally need to pass only one. In this way I think it's much closer to something like conditionals (e.g. if, than to do).

Also be aware of how Ruby handles aliases and inheritance: an alias references the method that was resolved at the time the alias was defined; it is not dispatched dynamically.

Prefer alias when aliasing methods in lexical class scope as the resolution of self in this context is also lexical, and it communicates clearly to the user that the indirection of your alias will not be altered at runtime or by any subclass unless made explicit.

Ruby's keyword args work a little differently than similar implementations (selectors in Objective C, for instance). The value on the right-hand side of the colon is the default, not the local name.

an equivalent of R's signif function in Ruby.

I just learned today that extend apparently doesn't override class methods that are already defined, even though the extend happens later:

URI::HTTPS.build(host: AUTH0_CONFIG['auth0_domain'], path: '/v2/logout', query: to_query(request_params)).to_s

def to_query(hash) hash.map { |k, v| "#{k}=#{CGI.escape(v)}" unless v.nil? }.reject(&:nil?).join('&') end

Extensions from Ruby are noted in the following list.

You can pass any options to puma via the server setting Capybara.server = :puma, { queue_requests: true }

This very much appears to be a bug or design flaw in puma - The fact that a persistent connection ties up a thread on the chance a request might come over that connection seems like not great behavior. This would really only be an issue when puma is run with no workers (which wouldn't be done in production) but it still seems a little nuts.

Create a new controller to override the original: app/controllers/active_storage/blobs_controller.rb

Symbols are an interesting twist on the idea of a string. The full explanation can be a bit long, but here’s the short version:Strings can be changed, so every time a string is used, Ruby has to store it in memory even if an existing string with the same value already exists. Symbols, on the other hand, are stored in memory only once, making them faster in certain situations.One common application where symbols are preferred over strings are the keys in hashes. We’ll cover this in detail in the hashes lesson later in the course.You won’t need to use symbols much in the beginning, but it’s good to get familiar with what they are and what they look like so that you can recognize them.

As a documentation convention, methods are listed out with either a :: or a # to indicate two different kinds of publicly accessible methods. Methods denoted by :: are considered class methods, while methods denoted by # are considered instance methods.

before(:all) do @fiber = Fiber.new do Benchmark.ips do |benchmark| @benchmark = benchmark Fiber.yield benchmark.compare! end end @fiber.resume end

does the microgem I published work for your use case?

We actually already use this patch: http://myronmars.to/n/dev-blog/2012/03/building-an-around-hook-using-fibers

I’ve been looking everywhere for examples of how to use Fibers that are complicated enough to do something useful but simple enough to understand. For an older feature it’s one of the least documented.

I haven't done a lot with Fibers,so having you point out a potential use for them and then walk through it was great.

I was wondering particularly whether there is a way to have a comment on the same line as the backslash

Caution: + continues the statement but not the string. puts "foo"+"bar".upcase gives you fooBAR, whereas puts ("foo"+"bar").upcase gives you FOOBAR. (Whether or not there's a newline after the +.) But: if you use a backslash instead of the plus sign, it will always give you FOOBAR, because combining lines into one statement, and then combining successive strings into one string, happen before the string method gets called.

It is very important that your gem reopens the modules ActiveJob and ActiveJob::QueueAdapters instead of defining them. Because their proper definition lives in Active Job. Furthermore, if the project reloads, you do not want any of ActiveJob or ActiveJob::QueueAdapters to be reloaded. Bottom line, Zeitwerk should not be managing those namespaces. Active Job owns them and defines them. Your gem needs to reopen them.

All known use cases of require_dependency have been eliminated with Zeitwerk. You should grep the project and delete them.

export RUBY_THREAD_VM_STACK_SIZE=2000000

Top Web Design & Development Agencies Winter 2022

I'm a big fan of refinements (yes, I am), and that's what I did to make this code look simpler and more beautiful:

# Allows you to just run "pry" inside a Rails app directory and get # everything loaded as rails c does. Inside a Bundler directory does # what bundle console does.