DISQUS

The Prags say pick one editor and learn it well, and I think it’s good advice. Somewhere between five and eight years ago I surveyed the mishmash of editors I had used, surveyed the field of editors available, and decided Emacs was the only one that offered the features I was looking for. I dedicated myself to learning Emacs. It probably took a good six months to become really comfortable with it, and I’m still learning things about it to this day. But at this stage I’ve become sufficiently one with the tool that I can’t imagine being as productive in anything else.

I really don’t get all editor fad-ism going on in Ruby/Rails land. The only thing I can figure is that a lot of these people were still stuck in the “use whatever <span class="caps">IDE</span> comes with the language stack” mindset, and Ruby/Rails work was the first time they realized they could and must choose their own. So I guess it’s a good thing.

To my mind the only reason to switch tools is if you see someone doing things in another tool that a) you can’t imagine doing in your usual tool; and b) once you’ve seen them, you can’t stand living without. Once you switch, pursue mastery. A lot of people know only the fraction of their tools’ capabilities, which I suspect is one of the reasons they are susceptible to these tool fads.

I can think of only once exception to the rule of sticking with one editor. Occasionally there are tools so well-integrated into a language that it behooves you to make the adjustment when using that language. The two examples that come to mind are the various Smalltalk browsers, and Eclipse for Java. The first because only a tool integrated with the running Smalltalk image can expose the full power of Smalltalk; and the latter because you need something which will take care of manual drudge-work for you if you’re going to work with a language as tedious as Java.

For languages which don’t have a language/editor symbiosis that strong, I say pick one editor, learn it well, and stick with it.

JMAGS: Thanks! I don't know what I was thinking.

Shalev:

1. To quote Knuth, premature optimization is the root of all evil ;-) Considering that our mythical Flying Monkey Transport Protocol probably has a packet latency measured in hours, I suspect that this is the least of their performance problems.

2. See the introduction to this series. If two separate pieces of code independently try to add the same method, it's no longer a method addition and becomes an inadvertent method redefinition.

3a. I apply YAGNI pretty religiously. I used to code based on the "we'll need it someday" principle a long time ago, and it never got me anywhere good.

3b. Reuse is not the only reason to extract code into a method. Other reasons include readability and enforcing the Single Responsibility Principle. The code that calls #end? is not concerned with how we know that the message is at the end, but with what to do if it is. Having the implementation details of how we know at that point is a distraction from the core purpose of the code.

But this kind of misses the point anyway, because this is demo code which I have deliberately kept simple in order to focus on the techniques being presented. In the real world #end? might very well be a more complicated (and distracting) algorithm.

Ryan, thanks for that link. I am open to the idea that there are security problems with OpenID, and I have to say some of the cases put forward in that article are compelling (although the intro is a little off-putting - "our innovative technology for user-centric identity management" - conflict of interest much?). What I was responding to was the assertion that there was no apparent utility in OpenID, something I find provably false.

I'm not concerned so much about the issue of centralization - I am my own OpenID provider. (And yes, I realize that I am in the minority in that). The fact that I *can* be my own provider, though, makes OpenID less centralized than previous attempts at single sign-on.

I could probably be convinced that OpenID is not the best solution, although it would take concrete examples of better solutions. What I am not interested in is people telling me that it serves no purpose. It serves me well, and if it is flawed I want to hear about improvements, not hand-waving about how nobody needs it anyway.

Giles, I'm a user. I'm speaking as a user, and nothing else. OpenID is of genuine value to me as a user. It is convenient and makes my life easier. Perhaps every other user in the world maps to your model and finds no use at all in it. But for me it has real utility. Chris was looking for how it was useful, and so (I thought) were you, and now I've explained it.

Paul: sorry about the lost comment. I'm increasingly not a fan of WordPress, period.

Pat: I understand your point, but this was the inheritance post :-) Composition will come later.

@andrew:

> You do monkey-patch in your NullDB. You reopen AR::Base to add a nulldb_connection method.

True. This, unfortunately, is part of the contract of the
ActiveRecord connection adapter API - you are expected to do this if
you want connection_establish :adapter => :foo to work. Whether this
is a true "monkey patch" is debatable; a lot of people only consider
such a thing a monkey patch if it actually *redefines* existing
methods. Of course, the Rails guys could easily have avoided the
whole question by giving us a less-silly API that allowed us to simply
register a new database connection class.

> Subclassing isn't always possible. With AR::Base subclasses have special
> semantic meaning, ie. Single Table Inheritance. That is why everything with
> ActiveRecord is done through mix-ins +/or eval. (You can subclass AR::Base
> not for STI but it's a pain)

It's not a pain, you just set abstract_class = true.

> Whether it is the Rails framework or a plugin, understand it enough to debug
> it. Then you can eval as much as you like.

This is easy to say, but in real world large projects it simply isn't
feasible to understand all of the code in the project, let alone all
of the third-party code it depends on. That is why community
conventions are essential for maintainability.

Thanks for the comment!

Not bad, just needlessly overused. I hope you read the whole article, not just the title. The followups ([first](http://avdi.org/devblog/2008/02/25/followup-to-monkeypatching-is-destroying-ruby/), [second](http://avdi.org/devblog/2008/02/25/full-disclosure/)) hopefully clarify some more.

I actually think *alias_method_chain* is slightly less dangerous than some other techniques, because at least it's a convention and a way to avoid silently stomping existing methods. But that's a good technique for the environments where *alias_method_chain* is available, and I may utilize it next time I'm debugging unexpected behavior in Rails. Thanks!

test