Dan Manges's Blog - Latest Comments

Re: Dan Manges - Modifying CGI::Cookie

Honeypot Detector — Sat, 13 May 2023 20:37:55 -0000

This is my new contract890!

Re: Dan Manges - Modifying CGI::Cookie

Honeypot Detector — Sat, 13 May 2023 20:27:26 -0000

This is my new contract!

Re: Dan Manges - Finding Unused Code in Rails

sam — Mon, 24 Aug 2020 05:24:46 -0000

Re: Ruby DSLs: instance_eval with delegation - Dan Manges's Blog

Brian — Sat, 27 May 2017 00:15:20 -0000

why this technique is useful for dsl?

Re: Pairing for Developer Interviews

do my assignment — Thu, 27 Oct 2016 20:48:05 -0000

Mixing with someone might be the best thought with the objective for some individual to ensure that the architect that he or she is talking is having the mastery that they required for their work. This can be expert in light of the fact that they can have the ability to screen every movement of the test that they need to do.

Re: Action Dependent Validations and Why :on => :update is Bad - Dan Manges's Blog

Jason Data — Tue, 14 Jun 2016 14:43:12 -0000

I was getting stuck bc `invalid?` was returning false, and you helped me see that that was smelly. Thanks

Re: Ruby DSLs: instance_eval with delegation - Dan Manges's Blog

Ben Randles-Dunkley — Tue, 23 Feb 2016 05:35:15 -0000

From someone who is tired of creating cached values of method responses for passing into DSLs, THANK YOU! :)

Re: Dan Manges - Ruby: View Gem Documentation

ik — Tue, 12 May 2015 08:49:32 -0000

see
Paritosh Piplewar

•

Re: Dan Manges - Ruby Pattern: Extend through Include

Bryan — Thu, 23 Apr 2015 13:58:49 -0000

Not sure how long this link will live but RubyMonk has a nice free tutorial on this.
"4.1 The `included` Callback and the `extend` Method"
https://rubymonk.com/learni...

Re: Misunderstanding the Law of Demeter - Dan Manges's Blog

Carlos Ble — Thu, 08 Jan 2015 18:44:17 -0000

Very good example. What I don't like about the first example is that eventually it violates the CQS (Command Query Separation principle). I would prefer the pay method to be void because it changes the state of the system. Then I would make a second call to retrieve the amount.

Re: Dan Manges - Ruby Inheritance Chain

Adam — Mon, 15 Dec 2014 08:55:25 -0000

Very cool, thanks. I'm about 7 years too late for this post, but anyone interested in this might also want to check out Dave Thomas's presentation on the Ruby Object Model: https://www.youtube.com/wat...

Re: Dan Manges - Ruby Pattern: Extend through Include

Guest — Tue, 09 Dec 2014 12:51:32 -0000

Thanks for this response, Agent Smith, it helped me think more critically about this solution. I thought a bit more about it, and if you don't subclass the class methods, but create that module at a peer level, your third concern disappears (some quick testing will show this works).

I think your first concern is legitimate, but could be overwritten, or supported, by cultural norms in the development community you're working in.

There is also some trickery out there to get around your second concern, but the pattern becomes more bulky.

It seems like a better way to present this pattern would be to demonstrate creating two peer-level modules, rather than one subclassed within the other, and offer the caveat that this behavior can be surprising and potentially confusing to others who work with your code for the first two reasons you've listed above.

Re: Dan Manges - Ruby Pattern: Extend through Include

Brian Katzung — Mon, 19 May 2014 23:19:59 -0000

Include adds a module to the current module's list of included modules. Instances of a class will search all of the class's included ancestors for instance methods after searching in their singleton classes.

Extending an object creates a new singleton class for the object containing the instance methods from the module. A class is an object, so an extend in the class definition creates new singleton classes for it, resulting in new class methods.

Adding a method to an object (using def object.method) adds the method to the singleton class returned by object.singleton_class.

See http://www.kappacs.com/2014... for details and a graphic.

Re: Dan Manges - Ruby Pattern: Extend through Include

Brian — Mon, 19 May 2014 22:43:07 -0000

Just a little more neatly packaged...

require 'extended_include'

module A
module ClassMethods
def xxx; "xxx"; end
end
include_class_methods
end

module B
module ClassMethods
def yyy; "yyy"; end
end
include_class_methods
extended_include A
end

class C; include B; end

puts C.yyy
puts C.xxx

Re: Dan Manges - Ruby Pattern: Extend through Include

Akuuuuu — Wed, 16 Apr 2014 17:03:43 -0000

Ruby newbie here, but I am pretty sure the common idiom of putting your class methods together in a submodule and then extending them as a group whenever your module is included is a bad idea/design mistake.

First of all, with this idiom, when you include the module, it automatically extends your class with class methods, which is not what you asked for. It seems rude.

Secondly Also you need to extend your own module with the module of class methods, or define them one at a time manually or they can't be used via ModuleName::class_method_name. ( a pretty common use case for a module of methods I'd wager )

Thirdly, putting all your class methods into a submodule called ClassMethods has it's own issues when you try to specialize the module by overriding the class methods you include ( and which were extended into your class for you by the idiom ). You find you can't access inherited constants without prefixing them with the module name ( which makes overriding constants impossible to do effectively ) and you'll find your base module's class methods are called and the overridden ones are ignored.( haven't teased this out fully but it's messed up )

The idiom looks slick at first glance but fails with hard use. I think the apparent slickness is why it has spread everywhere, and it's gained the aura of being blessed by the consensus of the net by being repasted so many times.

I am going to be sticking with defining class methods for modules the normal way ( not in some submodule ) and doing either include or extend or both as the situation warrants. I suspect there was a reason ruby included both the include and extend keywords rather than extend and one that does includeandextend .

The whole idiom seems to me to be kind of a uban legend of software design practice / bug factory.

Re: m2node - a mongrel2 handler for node.js - Dan Manges's Blog

Roger Qiu — Tue, 15 Apr 2014 06:47:07 -0000

What's the fake socket really doing? Is it adapting over a TCP socket? And is there a lot functions being stubbed in the fake socket? I see that the original socket was meant to be the net.Socket object. Why not make your FakeSocket extend from the net.Socket, so it can carry all the functions of a normal socket. Furthermore, this seems kind of hacky, of creating a fake socket to simulate a "socket" and then copying all of the data to the real ZMQ socket for pushing back to Mongrel2. There should be a better way with less indirection, so we can push HTTP responses directly back to Mongrel2.

One way I can imagine is if we could create the parse the HTTP request and create HTTP response independent of socket operations. Kind of like how PHP does it when you use Symfony's HTTP Foundation object. The HTTP message is ultimately just a string. So if we could do this in Node.js, we could connect directly to the sockets, and just parse out the HTTP messages and then push back with fully formed HTTP messages. And in order to integrate with Express or normal HTTP middleware, we just have to adapt the whole midleware "function (req, res)" concept.

Re: Dan Manges - Modifying Rake Tasks

lucykbain — Thu, 06 Mar 2014 01:48:08 -0000

After all these years, I found this very helpful - thanks!

Re: Ruby DSLs: instance_eval with delegation - Dan Manges's Blog

Juntao Qiu — Thu, 28 Nov 2013 20:23:29 -0000

Great post.

But can you explain more about the 'magic' here:

```
@self_before_instance_eval = eval "self", block.binding
```

in the method evaluate please?

Re: Misunderstanding the Law of Demeter - Dan Manges's Blog

bjeanes — Sat, 05 Oct 2013 02:15:58 -0000

Great article. I'm tempted to say that the final example you can (and possibly should) avoid your view reaching into your domain model without changing your domain model by presenters. Views reaching into your domain model can still lead to some pretty brittle coupling and an element of indirection can help greatly there. Something, somewhere, will have to traverse your domain model and that *IS* OK, which is I think the point you are trying to make anyway, but it's much nicer if that's the only thing it does. Views are already dealing with a lot of responsibilities, so splitting some of those out from the rendering component is a good thing, IMO.

Re: Misunderstanding the Law of Demeter - Dan Manges's Blog

C.F. — Thu, 12 Sep 2013 13:22:55 -0000

I appreciate examples on LoD and the delegate idea in Ruby is cool. I'm not a Ruby guy at all, but in the last example, is there a way to hide Wallet completely? Only the Customer should know how he stores his cash.

I contend that LoD would be almost a non-issue if information were properly hidden. It would not be possible to talk to strangers if you couldn't see them in the first place!

Re: Misunderstanding the Law of Demeter - Dan Manges's Blog

Jeff Dickey — Mon, 05 Aug 2013 00:13:28 -0000

"Can you explain this in a real language, or in crap like Java please?"

FTFY, both semantically and structurally. Our startup's single most existential problem is finding developers in or near our time zone (GMT+8 Asia/Singapore) who are also fluent and literate in English to the point of nuance and metaphor. Rubyists tend to be; Java coders tend to think they are. (And I cleaned up after Java coders for five years, in Java.)

No matter what your programming language, it does your team and your customer at most zero good if you can't communicate effectively and efficiently with them, or if you can't effectively and efficiently learn from technical material that, more often than not, is written in English. In my over thirty years of software-development experience, every single failed project I have ever seen or been part of has failed due to failures in communication of human languages. Every. Single. One.

At least the original commenter's nick is appropriate.

Re: Ruby DSLs: instance_eval with delegation - Dan Manges's Blog

mikeyshiran — Tue, 18 Jun 2013 04:00:34 -0000

Great article.
While experimenting with this, I tried defining an arbitrary method in the global scope of my ruby console (PRY for that matter) and then tried calling `MyClass.new.instance_eval { my_arbitrary_method }` and expected an exception to get thrown (since `self` will be set to the new class's instance, and `my_arbitrary_method` is not part of the class methods), but surprisingly, got the method's return value instead.
That's because methods which are defined in the top level of a program are available as private methods on all objects, which means that my test was actually wrong, since `my_arbitrary_method` was indeed part of the class methods.
More about this, in this article: http://marakana.com/bookshe...

Re: Dan Manges - Ruby: View Gem Documentation

Don Reba — Mon, 17 Jun 2013 17:55:47 -0000

'gem_server' is not recognized as an internal or external command,
operable program or batch file.

Re: Ruby DSLs: instance_eval with delegation - Dan Manges's Blog

stephen — Wed, 08 May 2013 21:16:40 -0000

Nice write up, but I'm confused by something. You explain the no method error by saying the following:

"Ouch. Because self is set to the TableDefinition class while instance_evaling the block".

I would expect self to be set to the TableDefinition instance, and not the class, while we evaluate the block? Is this an error in my thinking?

Re: Dan Manges - Pluggable, Please

Guest — Sun, 28 Apr 2013 16:34:46 -0000

Greetings