On 12 set, 14:51, Czarek <[email protected]> wrote: >... > There are articles about the internals around the net. Unfortunately > they quickly get outdated. And in a way, this is a good thing, because > it means Rails is continuously evolving.
Thanks God it continues to evolve every day. This is what can make it last several years, if not forever... We should not try to stop this, as you pointed out... > With all the changes going in to 3.0, maintaining such documentation > may be a nightmare, unless it becomes version specific. Especially > with all the refactoring going on. If you mean that maintaining such documentation as a separate projects, such as docrails, yes I agree. That is not what I proposed. I propose that the Rails core team embrace the idea of maintaining such documentation in Rails git repository, as well as Linux kernel does. It surely requires extra work, but I think it worths if other people will be able to contribute more... Docrails will eventually be outdated, since it is a separated project and it is always behind main development. I propose that this kind of documentation should be part of a patch changing significantly the Rails internals. Since it is part of the main repository, there should be no need in maintaining different versions, since git would already take care of this... I wrote about nested templates some time ago in docrails, but I will need to take off the documentation as of Rails 3 release. That is because 'yield' return value has changed in a way that the proposed solution won't work in Rails 3 (I didn't test on Rails 2.3.4 yet). Since I don't know how to implement subtemplates in a similar way for Rails 3, I'll have to drop that documentation. That was said to state the differences about maintaining the documentation inside the main project or as a related independent project. Both have their pros and contras, and, although I liked the railsdoc and Rails guides projects as they are implemented, I think that internal documentation should be maintained altogether with Rails main source code in the same git repository, following the Linux kernel example. > Here are a few tips I found useful: > ... These tips are really useful, but they don't apply to every situations. They are good when dealing with most bugs, but solving some bugs or creating new features that need more knowledge about Rails internals would not be much benefited by these tips. Even with all these techniques, we would waste too much time trying to figure out how Rails works by ourselves, instead of concentrating our efforts to actually correct the bug or add a new feature... > Especially the last part - hack on ruby when you are not under > pressure. Do it for fun. That is exactly what I am doing, but I really don't think it helps... Besides that, we usually really understand things only when we actually need to do something real. When reading some arbitrary code, we may have the feeling that we are understanding, but when having to put it in practice, we realize that we were not... > Learn things before you need them. Read > articles about ROR when you have spare time. It pays off eventually. > Even if this would mean investing more time in total, it will be more > pleasurable. I do it all the time. Actually I can't avoid! ;) There are many great articles out there and sometimes we use more time reading them than we would be allowed to... :) >... Thanks for your reply, Cezary. Regards, Rodrigo. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
