Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
When I first started with ruby/rails and noticed that you don't need to put parenthesis, I recall thinking "no way I'll do that!".
But now I kind of like it.
So the question is, is that good style? Or should I stick to using parenthesis?
Thanks.
The downvotes are probably because SO is technically not a good forum for this kind of question - apparently SO community likes clear, answerable, discrete, objective questions, not more general style or technique questions like this. But I love questions like these, so here goes.
Since working with Ruby various little style questions like this drive me absolutely crazy, which is stupid because they're not that big of a deal. But the Ruby community seems obsessed with style questions, maybe it just comes with the territory of having an extremely expressive language.
My answer:
I try to orient everything around making my code as intelligible as possible, without making it unreasonably long. If I'm struggling between two styles, I'll almost always come down on the style that I think will be easier for a more novice developer to understand in the future.
I omit parentheses when either there's no arguments, or when the argument "flows naturally" after the method name. So if the method is describing an action and the first parameter is the object of that method, it's beautiful to omit the parentheses. Like this:
create :user, name: "Topher"
raise "Problem!" unless #thingy.is_a? String
render partial: "filters"
But often the first parameter of the method is a hash of options or is an incidental value or something other than "the object of the action being taken". In these cases, I usually find it looks wrong / jarring to leave out the parentheses. Like in these cases:
#user.disable!(force: true)
#entries.paginate(page: params[:page])
And of course, if you're chaining methods together (like building up an ActiveRecord call), you need to include the parentheses if any params are present, so the question becomes moot.
A more general answer:
If you haven't already, read the Ruby style guide, from start to finish, a couple times. Some rules will appeal to you, some will repulse you, but exposing yourself to it will get you familiar with the styles and patterns used by many many other Rubyists (who debate about those styles ad nauseum) and when you're confronted with similar situations, you'll be more conscious of the different ways to approach it and what tradeoffs of those different styles might be.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
So, what most comfortable and useful for developer? A similar question was already 4 years ago, and many things could change.
http://activeadmin.info/
https://github.com/sferik/rails_admin
or maybe Typus https://github.com/typus/typus???
Disclaimer: this is only opinion. This kind of question can have no 'correct' answer.
I use Rails Admin a lot on my current main project. It has advantages and disadvantages.
Advantages:
It handles things like nested forms for ActiveRecord relationships out of the box.
Disadvantages:
Adding features or custom behaviour is quite difficult and documentation is over-complex and fragmented.
Putting the DSL for CMS behaviour in the models is not great for code separation.
The default style is a little outdated.
The DSL itself is over-complex, badly documented and prone to code bloat and duplication.
The use of PJAX for page updates can complicate any JS you wish to add to the page. (If you're not careful your code will be run multiple times, or not at all, for a single page.)
The default mechanism for saving content items is incompatible with a database that uses referential integrity. This is a very bad thing. (I ended up patching this code.)
I haven't used ActiveAdmin as much, but when I have I noticed the following things:
Out-of-the-box, you have to roll more of your own features when it comes to things like nested forms for relationships. (This may have changed over time.)
It looks lovely.
The DSL is neatly separated from the model code and feels more logical.
Adding your own features is a lot easier with less code.
Adding JS is pretty trivial.
I don't know if Active Admin is better for referential integrity, but if this interests you let me know in comments and I'll set up a couple of trial projects to show you what I mean.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have been hearing that the controller should be as concise as possible. So, I try to keep most of the processing work in the helper for the corresponding controller. But, I am little confused regarding whether I should instead use private controller methods or helper methods.
I am using helper methods only for processing and returning values. They have no other usage for now. They are not called from views.
That's a bad idea in general. Helper methods shouldn't be used except for specific convert-something-into-string stuff (basically, should be used only in views).
For anything else, you should use service objects or something similar, basically, PORO (plain old ruby objects)
In controllers you want to handle authentication and render the right thing, you don't want to deal with anything else otherwise they become too complex.
You might want to check these books to improve knowledge about this topic:
Growing Rails applications which is a really good book on how to avoid putting code in wrong places and how to keep codebase maintenable on the long term
POODR which is a Ruby guide on how to write good Object-Oriented code, it's a must for any developer and will help you understand why using an helper it's a bad idea
Usually, a Helper is called in a template or a view.
If you want to keep your controller DRY, use functions in your models or in services (read this good article about services by Ben Lewis)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Many times I need to have a variable to express the type of something, but as you probably know it is also the name of a function in Lua.
What could be a proper workaround? I thought of:
Use it anyways. Since I use almost only local values, the type function isn't overwritten but it becomes temporarily inaccessible (also a problem when used as an argument name).
Using a synonym of the word "type" (probably the easiest solution), but I can't come up with anything good.
Using upper case, prefix/suffix, like Type, TYPE or _type, but it goes against the code style used so far.
Save the type function as something else and restore it at the end.
Add a global reference to type called for example 'typeof' so that when type is used locally I can still use typeof.
Recompile Lua with a different name for the type function (no thanks!)
The only sensible options are #2 and #3, choosing one of the others usually is asking for troubles.
Keep in mind that naming conventions are just that, conventions. In exceptional cases breaking the convention to make the code more readable is a good thing.
On the other hand, overloading/changing/fiddling with the standard library names is far worse, especially because you do it just to avoid some names that you don't like so much for your identifiers.
Although they are not considered reserved identifiers with the same strong rules as C (the only really reserved names are those that begins with an underscore followed by a capital letter), Lua standard library names should be considered reserved, unless you have an extremely compelling reason to do otherwise, especially in large applications. Preserving naming conventions is not such a compelling reason.
Usually I use the word kind for that purpose.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm just wondering, I'm new to this pattern subject, I started like couple of weeks ago but my main problem is, when I start writing small applications (for self purposes) I can't think where to put any pattern to use, maybe it's my thinking structure that needs to be tweaked ?
If I start a new project, how would I know if I need to use a pattern ? what questions do I ask myself ? what steps do I take before writing the actual code ?
Look at the Delphi VCL...it's basically took the Design Patterns and ran with them...
Forms are Composite Patterns.
Datasets use the Iterator Pattern.
Screen and Application are Singleton Patterns.
Components use lots of
different Patterns, the Chain of Responsibility, Decorator, Facade
to name a few...
Patterns are ways to organize your program and objects in lightly coupled objects that have jobs that you do over and over again...
Design patterns are just ways to approach solutions to common problems. As you internalize the patterns and as you understand the problem better you will sometimes see that the problem (or part of the problem) you are solving is addressed by a particular pattern.
That's when you use it. When you see it solving your problem.
Design patterns are reusable solutions for common problems.
The principles of Software Engineering cites the reusability of codes, when you use a design pattern you are using a concept previously tested that went trough several validations and is less prone to an design error than if you design your own model.
So first, you have to know the existing design patterns and what they're intended to solution. When you face a common problem you may remember the design patterns you previously studied and use them to solve the situation you're facing at the moment.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
For me to understand the rails project is not enough to see the model or controller diagrams and how many attributes and actions they're having. I understand more if I know where actions are initialized and how they ended. To describe my thoughts more specifically I'll show some example. Let's take nice open project Railscasts. I chose the Comment controller because it nested inside others controllers then it's a little harder to understand how this works. Here's my picture that helps me to understand it.
This isn't well composed diagram but fine for me. On this picture you can see where action is started and what's the reaction on action. The action edit initiates in views/episodes/show.html.erb, comes to controller's action edit, after that shows the edit form, then go to update action and finally go back to show.html.erb. From this picture you can see that a lot of actions initiate in show.html.erb that belongs to episode controller and makes harder to understand how works the comments controller. Now you can easy find place where is action comes.
Here is my questions:
Do you think this idea is useful for you, can make your developer's life easier ?
Do you know some tool that can make such kind of pictures automatically ?
This is quite argumentative, but answering to question 1 :), I have to say that your diagram has a huge noise/signal ratio.
Your diagram only talks me about routing which honestly in a mid-sized scenario is not so complicated to need a diagram. And does it pushing a lot of noise (why I need to see the class of a destroy link?)
Rails is a lot about conventions and to be honest I don't feel the routing mechanism to be so complicated to need a diagram. Just my 2 cents.
To Question 2: I often find RubyMine model diagram to be quite useful, but I think you need a more 'dynamic' view of the project.