Comments on: 6 Steps To Refactoring Rails (for Mere Mortals)

By: cash loans people bad credit

cash loans people bad credit — Thu, 27 Jan 2011 03:38:23 +0000

My partner and i are generally obtaining a hard time , following on your Rss feed. It comes plan fault 451. Tell me if its a an easy task to resolve error or whether just simply us . Ive experimented with opera and For instance. Im using AVG Firewall program plus i am undecided ways to turn it off . I am not excellent together with Computer systems. Dangerous lesemarke your web site and discover for those who have told the pollsters. take care

By: Michael Mullany

Michael Mullany — Wed, 01 Jul 2009 23:16:52 +0000

yomero — we inavertently broke some safari feeds when we migrated to wordpress a few months ago. if you resubscribe to our feedburner feed you'll be cool as a cucumber

By: yomero

yomero — Wed, 01 Jul 2009 22:05:09 +0000

What happened to your RSS feeds?

By: peanut

peanut — Wed, 01 Jul 2009 07:10:26 +0000

Any of this point not new for me. But anyway, thanks for systematization.

By: feydr

feydr — Tue, 30 Jun 2009 02:31:04 +0000

That last point I can definitely vouch for — 'git reset –hard' has come in spades for a parsing project I am working on.

By: Mislav

Mislav — Mon, 29 Jun 2009 21:25:45 +0000

Step 7: merge yourself with another master developer to form a superpowered human being named Carlhuda and leave a fire trail on your keyboard while hacking

By: wycats

wycats — Mon, 29 Jun 2009 20:49:02 +0000

@alan as a matter of fact, I have tried it both ways. It might be possible for a single, very disciplined, excellent programmer to keep a relatively stable codebase without any tests, but even for such a developer, good tests add value.

The rule you're commenting on actually came directly out of work we did on Merb, as well as an observation about Ruby 1.9. In the case of Merb, our early tests (the 0.3 to 0.5 era) were fairly coupled, and we routinely made refactoring and new-feature changes at the same time. I talked some about the coupling problem at RubyConf last year.

Ruby 1.9 has a similar problem. Because the internals were changed at the same time as language features were added, it's very difficult to determine whether a breaking change is intentional or not. Had they focused on swapping in a new VM (like JRuby and Rubinius did), it's trivial to point at a breaking change and *know* it's accidental.

The work we're doing on Rails is really just the culmination of a lot of experiences trying different refactoring strategies. Especially when working with members of a team and the open-source community, the quality of the recommendation that refactoring is a separate phase from new features has significant communication benefits that make it worthwhile all on its own.

By: Alan

Alan — Mon, 29 Jun 2009 20:14:38 +0000

"We’ve held fast to this requirement for the Rails 3 work Carl and I have been doing, which has resulted in an extremely stable edge, despite making fairly invasive changes."

Did you try both ways? If not, how can you derive this causation?

I've done very invasive changes, while adding features, without even any automated tests, and maintained stable code. It was (as everything else in programming) a matter of being careful, not any particular strategy or methodology.

By: Stephen Stillwater

Stephen Stillwater — Mon, 29 Jun 2009 18:58:59 +0000

Indeed, this article could also be titled "an extremely abridged version of 'Refactoring' by Fowler, Beck, et. al". :P

By: wycats

wycats — Mon, 29 Jun 2009 18:45:36 +0000

@jsd what I've seen time and time again is that innocent use of a public API in a private context eventually made the public interface far more complex than it needed to be. More importantly, it was not quite difficult to determine whether some functionality in a *public* method was meant to be public, or meant to be internal.

Just to be clear, when I say "public" with regard to Rails, I mean functionality intended to be used by users of the library or framework, not the "public" visibility in Ruby.