Please mind that this note is as opinionated as can be. I believe this is the only way one can speak about Rails as RoR itself leave no room for doubts.
I believe Rails was meant for small to middle web sites development, and never meant to be a foundation for something bigger. Just read 37signals' Getting Real book and you will understand that Rails is backed by a company with a no-grow philosophy. And so is Rails - it will never be as big as Java or .Net are.
You can ignore this until you start develop a little bit more elaborate software. And this is where you have to get serious about OOP. But Rails provides no aid here. Instead, it leads you into trouble, because it puts too much pressure on you with conventions and especially with poor naming. (I am not trying to charge DHH with that, after all naming is the weakest skill in IT community of all times.) Thousands of people fall into problems of not understanding where they should rethink Rails conventions and deviate from them, which leads to heated discussions whether Rails breaks OOP and how to keep producing quality maintainable and testable code with Rails (fat models/skinny controllers attempt, writing true unit-tests with Rails, is ActiveRecord an anti-pattern, etc). Well the answer is - get to know some OOP theory. These are the problems OOP community have been solving for decades now and there is nothing really new about that.
Oh wait, there is something new! Rails deserves special gratitude for whetting community appetite for least known DCI design pattern.
Rails community experience lot's of agitation and controversy, and this couldn't be another way. The reason for this is that RoR emphasizes on developers' productivity at the first place rather then being dogmatic about design. Understanding this may turn us to be a little bit less dogmatic about Rails' usage.
More to read:
https://gettingreal.37signals.com/
http://railsoopbook.com/
http://objectsonrails.com/
http://www.leansoftwarearchitecture.com/
http://clean-ruby.com/
http://www.artima.com/articles/dci_vision.html
http://folk.uio.no/trygver/2008/commonsense.pdf
Good luck!
You can ignore this until you start develop a little bit more elaborate software. And this is where you have to get serious about OOP. But Rails provides no aid here. Instead, it leads you into trouble, because it puts too much pressure on you with conventions and especially with poor naming. (I am not trying to charge DHH with that, after all naming is the weakest skill in IT community of all times.) Thousands of people fall into problems of not understanding where they should rethink Rails conventions and deviate from them, which leads to heated discussions whether Rails breaks OOP and how to keep producing quality maintainable and testable code with Rails (fat models/skinny controllers attempt, writing true unit-tests with Rails, is ActiveRecord an anti-pattern, etc). Well the answer is - get to know some OOP theory. These are the problems OOP community have been solving for decades now and there is nothing really new about that.
Oh wait, there is something new! Rails deserves special gratitude for whetting community appetite for least known DCI design pattern.
Rails community experience lot's of agitation and controversy, and this couldn't be another way. The reason for this is that RoR emphasizes on developers' productivity at the first place rather then being dogmatic about design. Understanding this may turn us to be a little bit less dogmatic about Rails' usage.
More to read:
https://gettingreal.37signals.com/
http://railsoopbook.com/
http://objectsonrails.com/
http://www.leansoftwarearchitecture.com/
http://clean-ruby.com/
http://www.artima.com/articles/dci_vision.html
http://folk.uio.no/trygver/2008/commonsense.pdf
Good luck!
No comments:
Post a Comment