Documentation is only useful if it's 1) actually read, 2) clear and well-written, and 3) up to date. In practice, I find that a lot of documentation is none of those things. Actually writing...
Documentation is only useful if it's 1) actually read, 2) clear and well-written, and 3) up to date. In practice, I find that a lot of documentation is none of those things.
Actually writing documentation up front or together with the program can have some benefits on its own as they can serve as design notes ("writing is thinking"), but documentation for the sake of it is often not very useful.
As for the question, don't fight Rails. It has a specific way of doing things and while you can work around them if you don't like it, you're probably not going to have a good time if you do.
I'm fond of pseudocoding a project in such a way that the pseudocode becomes the documentation as the actual code is written. Agree on Rails. It is a great system, as long as you accept that it's...
I'm fond of pseudocoding a project in such a way that the pseudocode becomes the documentation as the actual code is written.
Agree on Rails. It is a great system, as long as you accept that it's way of doing things is the "right" way.
My recommendation is being wary. If you run into a issue where the web frameworks are preventing you from doing something, I’d be very skeptical of the advice you find online to get around it. For...
My recommendation is being wary. If you run into a issue where the web frameworks are preventing you from doing something, I’d be very skeptical of the advice you find online to get around it. For example, issues with things like csrf where many of the top answers are to simply turn it off. Many of the defaults in thing like RoR are set the way they are for a reason, and it’s better figure out why, rather than blindly turning them off.
Best practices can be a little subjective but if you're looking for some expert-crafted, opinionated recommendations, a good style guide can be helpful. I've found the ones by Airbnb to be...
Best practices can be a little subjective but if you're looking for some expert-crafted, opinionated recommendations, a good style guide can be helpful. I've found the ones by Airbnb to be sensible and well-written. Here is a link to the one for Ruby / Rails. Pair that with what others have noted, that Rails has a "right" way of doing things, for best results.
Documentation is only useful if it's 1) actually read, 2) clear and well-written, and 3) up to date. In practice, I find that a lot of documentation is none of those things.
Actually writing documentation up front or together with the program can have some benefits on its own as they can serve as design notes ("writing is thinking"), but documentation for the sake of it is often not very useful.
As for the question, don't fight Rails. It has a specific way of doing things and while you can work around them if you don't like it, you're probably not going to have a good time if you do.
I'm fond of pseudocoding a project in such a way that the pseudocode becomes the documentation as the actual code is written.
Agree on Rails. It is a great system, as long as you accept that it's way of doing things is the "right" way.
My recommendation is being wary. If you run into a issue where the web frameworks are preventing you from doing something, I’d be very skeptical of the advice you find online to get around it. For example, issues with things like csrf where many of the top answers are to simply turn it off. Many of the defaults in thing like RoR are set the way they are for a reason, and it’s better figure out why, rather than blindly turning them off.
Best practices can be a little subjective but if you're looking for some expert-crafted, opinionated recommendations, a good style guide can be helpful. I've found the ones by Airbnb to be sensible and well-written. Here is a link to the one for Ruby / Rails. Pair that with what others have noted, that Rails has a "right" way of doing things, for best results.