As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I m new to ROR3.0 I was read a lot place saying that is "this code is DRY" or something related to DRY
I want to know how to make a code DRY ?
Is it necessary my code should be DRY?
DRY stands for Don't Repeat Yourself. If it's possible, it's good practice to use DRY in most coding environments to make it easy to maintain going forward (and stop your copy-paste keys getting worn out!)
I'd suggest wherever code is repeated to extract the common code and extract into a method.
The wiki below is a good place to see where a lot of these shorthand expressions came from:
http://c2.com/cgi/wiki?DontRepeatYourself
In this case, 'DRY' simply means 'Don't Repeat Yourself'. This simple guideline leads to writing smaller, better decomposed methods which can be reused in several contents. This in turn leads to easier maintenance, better testability etc.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
The Google tells me there are several parsec-like libraries for OCaml: Batteries' ParserCo, Planck, Mparser, PCL, and ocaml-parsec. My problem is knowing which one to choose. Can someone give me some feedback concerning stability, active maintenance, quality of documentation, etc?
I have a vague idea of how ParserCo, Planck and PCL look like, and I would start from Planck, expecting to find some rough edges and evolve the library a bit myself over use. None of them are really actively documented, but Planck got some "serious" test cases (parsing the OCaml grammar itself) and the developer, Jun Furuse, is reactive may be interested in getting it upto shape.
That said, parsing combinator libraries are not that popular in the OCaml world. We still quite actively use parser generators. If you don't have strong opinions either way, I recommend that you have a try at Menhir, that is quite polished and nice to use (and also actively maintained).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I make heavy use of MagicalRecord for fetching, deleting, updating and saving data. I have noticed in testing that I don't get expected results because something went wrong with the operation I was attempting, such as a bad predicate resulting in no record being updated or deleted, etc.
I have looked at the available docs (such as they are) and can find nothing that give a method for examining any return code, etc.
Anyone know of a place that lists all of the available MR methods with explanations (other than the MR Categories and Core)?
I'm not exactly sure what it is you're looking for in the way of documentation. The primary reason for sparse documentation for the project is that the core data docs cover the vast majority of the features. Magical record is merely a set of convenience methods that make standard operations in core data much more manageable.
The parts that are 'non standard' core data functionality may need some extra explanation in how things work, but they source is also available to read and understand. If you have a specific question, please ask it.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have spent some time familiarizing myself with
rails (ruby),
django...and other things like zope and pylons/pyramid (python),
catalyst (perl)
but often find myself wanting to use
sinatra (ruby)
bottle...or flask...(python)
dancer...(perl)
I'm not entirely sure...when I'm about to start a new project, which I should use.
What should be the deciding factor that makes me switch from a micro framework to something more substantial. Is it just when I would otherwise have too much SQL to write? I think not, because if that were the case I could just use an ORM library/module.
My main issue is a fear of choosing something that other developers would not understand if someone else needed to fix the site at a later point in time. Still I am still not sure what should inform my opinion.
With miсro frameworks you have more freedom in the use of libraries, you can add what you think is right. In large frameworks such as Django and etc already much that is "screwed" and there are certain rules and best practices how best to write certain things.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When writing ruby (& ror) applications with BDD, should the step definitions be written before you even create the models, views and controllers in order to save the maximum headache?
Yes, you should - that's the main idea of BDD and TDD, respectively. Red - Green - Refactor. First start off with your feature (e.g. use Cucumber here), then write the step definitions and finally your code.
The RSepc Book is a good read to capture the whole thing. Take at look at figure 1.1 The BDD-cycle on page 29. This gives you a good overview on how to approach BDD and TDD and also has some nice examples.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
In Rails, we offen write a lot of code in our models such as class methods, plugin methods, named_scopes, callbacks... I am wondering if there is a good pattern to organize the sequence. I saw the best example in a presentation before, but now I forgot.
Anyone have suggestion? Thanks
There is no set way... If you are using a scope (since Rails 3, named_scope is deprecated) that relies on a method, it has to be defined after the method in the model. It's possible to mix and match and sometimes it's necessary to do so.
It doesn't affect load time or efficiency to the best of my knowledge
I'm pretty OCD when writing ruby, so I have a very opinionated answer to your question. I created this gist as an example of the structure we use.
I wrote about that a while back as part of my style-guide:
acts_as_good_style.
YMMV as to what the "best" grouping/ordering is, but if you'd like my take it's there under the "Model idiom" section