Posted by matijs
26/09/2024 at 16h54
I think a good process is something like this:
- Add the standard library gems to the dependencies so the warnings go away. For gem projects I think it’s fine to put them in the development dependencies because the published gems don’t need these dependencies right now
- Figure out which gems load the standard library gems
- File bug reports for those gems to make them add the standard library gems as dependencies
- Wait for those gems to be updated and then update the dependencies on those gems in my project
- Remove the standard library gems from the dependencies again
To be honest, I think I have only ever gotten as far as point 2.
Tags
maintenance, programming, ruby
no comments
no trackbacks
Posted by matijs
31/12/2018 at 15h46
- Your next release should nearly always come from the
master branch.
- When updating your feature branch, prefer
git rebase master over git merge master.
- When merging your feature into
master, prefer merge bubbles over squash merges and fast-forwards.
-
bundle exec rake should run your tests.
- You still should not check in
Gemfile.lock.
- Use RuboCop. Running just
rubocop should do the right thing. If you need a specific version, add it to the Gemfile. In that case, bundle exec rubocop should do the right thing.
Tags
development, opinions, ruby
no comments
no trackbacks
Posted by matijs
10/04/2016 at 09h21
This is an anti-pattern that has bitten me several times.
Suppose you have an object hierarchy, with a superclass Animal, and several
subclasses, Worm, Snake, Dog, Centipede. The superclass defines the abstract
concept move, which is realized in the subclasses in different ways, i.e., by
slithering or walking. Suppose that due to other considerations, it makes no
sense to derive Worm and Snake from a SlitheringAnimal, nor Dog and Centipede
from a WalkingAnimal. Yet, the implementation of Worm#move and Snake#move
have a lot in common, as do Dog#move and Centipede#move.
One way to solve this is to provide methods walk and slither in the
superclass that can be used by the subclasses that need them. Because it makes
no sense for all animals be able to walk and slither, these methods would need
to be accessible only to subclasses (e.g., private in Ruby).
Thus, the superclass provides a toolbox of methods that can only be used by its
subclasses to mix and match as they see fit: a Private Toolbox.
This may seem an attractive course of action, but in my experience, this
becomes a terrible mess in practice.
Let’s examine what is wrong with this in more detail. I see four concrete
problems:
- It is not always clear at the point of method definition what a method’s
purpose is.
- Each subclass carries with it the baggage of extra private methods that
neither it nor its subclasses actually use.
- The superclass’ interface is effectively extended to its non-public methods,
- New subclasses may need to share methods that are not available in the
superclass.
The Animal superclass shouldn’t be responsible for the ability to slither and
to move. If we need more modes, we may not always be able to add them to the
superclass.
We could extract the modes of movement into separate helper classes, but in
Ruby, it is more natural to create a module. Thus, there would be modules
Walker and Slitherer, each included by the relevant subclasses of Animal. These
modules could either define move directly, or define walk and slither.
Because the methods added in the latter case would actually makes sense for the
including classes, there is less need to make them private: Once could make a
instance of Dog walk, either by calling move, or by calling walk directly.
This solves all four of Private Toolbox’ problems:
- The module names reveal the purpose of the defined methods.
- Subclasses that do not need a particular module’s methods do not include it.
- The implementor of Animal is free to change its private methods.
- If a new mode of transportation is needed, no changes to Animal are needed.
Instead, a new module can be created that provides the relevant functionality.
Tags
patterns, programming, ruby
no comments
no trackbacks
Posted by matijs
28/07/2015 at 10h52
Because of a pull request I was working on, I had cause to benchmark activesupport’s #try. Here’s the code:
require 'benchmark'
require 'active_support/core_ext/object/try'
class Bar
def foo
end
end
class Foo
end
bar = Bar.new
foo = Foo.new
n = 1000000
Benchmark.bmbm(15) do |x|
x.report(’straight’) { n.times { bar.foo } }
x.report(’try - success’) { n.times { bar.try(:foo) } }
x.report(’try - failure’) { n.times { foo.try(:foo) } }
x.report(’try on nil’) { n.times { nil.try(:foo) } }
end
Here is a sample run:
Rehearsal ---------------------------------------------------
straight 0.150000 0.000000 0.150000 ( 0.147271)
try - success 0.760000 0.000000 0.760000 ( 0.762529)
try - failure 0.410000 0.000000 0.410000 ( 0.413914)
try on nil 0.210000 0.000000 0.210000 ( 0.207706)
------------------------------------------ total: 1.530000sec
user system total real
straight 0.140000 0.000000 0.140000 ( 0.143235)
try - success 0.740000 0.000000 0.740000 ( 0.742058)
try - failure 0.380000 0.000000 0.380000 ( 0.379819)
try on nil 0.210000 0.000000 0.210000 ( 0.207489)
Obviously, calling the method directly is much faster. I often see #try used defensively, without any reason warrented by the logic of the application. This makes the code harder to follow, and now this benchmark shows that this kind of cargo-culting can actually harm performance of the application in the long run.
Some more odd things stand out:
- Succesful
#try is slower than failed try plus a straight call. This is because #try actually does some checks and then calls #try! which does one of the checks all over again.
- Calling
#try on nil is slower than calling a nearly identical empty method on foo. I don’t really have an explanation for this, but it may have something to do with the fact that nil is a special built-in class that may have different logic for method lookup.
Bottom line: #try is pretty slow because it needs to do a lot of checking before actually calling the tried method. Try to avoid it if possible.
Tags
benchmark, programming, ruby
no comments
no trackbacks
Posted by matijs
30/01/2014 at 06h16
These past few days, I’ve been busy updating RipperRubyParser to make it compatible with RubyParser 3. This morning, I discovered that one thing that was changed from RubyParser 2 is the parsing of negations.
Before, !foo was parsed like this:
s(:not, s(:call, nil, :foo))
Now, !foo is parsed like this:
s(:call, s(:call, nil, :foo), :!)
That looks a lot like a method call. Could it be that in fact, it is a method call? Let’s see.
Tags
ruby, software
no comments
no trackbacks
Posted by matijs
02/03/2013 at 16h42
Yesterday, I read Alex Gaynor’s slides on dynamic language
speed.
It’s an interesting argument, but I’m not totally convinced.
At a high level, the argument is as follows, it seems:
- For a comparable algorithm, Ruby et al. do much more work behind the
scenes than ‘fast’ languages such as C.
- In particular, they do a lot of memory allocation.
- Therefore, we should add tools to those languages that allow us to do
memory allocation more efficiently.
Tags
benchmarks, ruby, software, speed
no comments
no trackbacks
Posted by matijs
04/11/2012 at 13h34
Once upon a time, there was only UnifiedRuby, a cleaned up
representation of the Ruby AST.
Now, what do we have?
-
RubyParser before version 3; this is the UnifiedRuby format:
RubyParser.new.parse "foobar(1, 2, 3)"
# => s(:call, nil, :foobar, s(:arglist, s(:lit, 1), s(:lit, 2), s(:lit, 3)))
-
RubyParser version 3:
Ruby18Parser.new.parse "foobar(1, 2, 3)"
# => s(:call, nil, :foobar, s(:lit, 1), s(:lit, 2), s(:lit, 3))
Ruby19Parser.new.parse "foobar(1, 2, 3)"
# => s(:call, nil, :foobar, s(:lit, 1), s(:lit, 2), s(:lit, 3))
-
Rubinius; this is basically the UnifiedRuby format, but using Arrays.
"foobar(1,2,3)".to_sexp
# => [:call, nil, :foobar, [:arglist, [:lit, 1], [:lit, 2], [:lit, 3]]]
-
RipperRubyParser; a wrapper around Ripper producing UnifiedRuby:
RipperRubyParser::Parser.new.parse "foobar(1,2,3)"
# => s(:call, nil, :foobar, s(:arglist, s(:lit, 1), s(:lit, 2), s(:lit, 3)))
How do these fare with new Ruby 1.9 syntax? Let’s try hashes. RubyParser
before version 3 and Rubinius (even in 1.9 mode) can’t handle this.
-
RubyParser 3:
Ruby19Parser.new.parse "{a: 1}"
# => s(:hash, s(:lit, :a), s(:lit, 1))
-
RipperRubyParser:
RipperRubyParser::Parser.new.parse "{a: 1}"
# => s(:hash, s(:lit, :a), s(:lit, 1))
And what about stabby lambda’s?
-
RubyParser 3:
Ruby19Parser.new.parse "->{}"
# => s(:iter, s(:call, nil, :lambda), 0, nil)
-
RipperRubyParser:
RipperRubyParser::Parser.new.parse "->{}"
# => s(:iter, s(:call, nil, :lambda, s(:arglist)),
# s(:masgn, s(:array)), s(:void_stmt))
That looks like a big difference, but this is just the degenerate case.
When the lambda has some arguments and a body, the difference is minor:
-
RubyParser 3:
Ruby19Parser.new.parse "->(a){foo}"
# => s(:iter, s(:call, nil, :lambda),
# s(:lasgn, :a), s(:call, nil, :foo))
-
RipperRubyParser:
RipperRubyParser::Parser.new.parse "->(a){foo}"
# => s(:iter, s(:call, nil, :lambda, s(:arglist)),
# s(:lasgn, :a), s(:call, nil, :foo, s(:arglist)))
So, what’s the conclusion? For parsing Ruby 1.9 syntax, there are really
only two options: RubyParser and RipperRubyParser. The latter stays
closer to the UnifiedRuby format, but the difference is small.
RubyParser’s results are a little neater, so RipperRubyParser should
probably conform to the same format. Reek can then be updated to use the
cleaner format, and use either library for parsing.
Tags
ripper, ruby, sexp, software
no comments
no trackbacks