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.
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
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.
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
I am new to grails. One thing I have noticed in the codebase of my current project is that the domain classes and the controller classes share the same package. So, you have something like this:
grails-app/controllers/foo/BarController.groovy
grails-app/domain/foo/Bar.groovy
So, is this a common practice? What are pros and cons of this? Thank you very much.
I think it's ok to use the same package for domain objects and controllers.
There is a practice called Package by Feature, which argues that grouping classes by what kind of component they are or what layer they are in is not as effective as grouping things together that contribute toward implementing the same functionality. When I work on projects packaged by layer I do a lot of hunting around going back and forth, grouping by feature would reduce that.
Usually domain objects have very little private about them. Also privacy in Groovy classes is nonexistent anyway.
This is how "convention" works over "configuration" in Grails. This is a common practice. I haven't found a demerit using it this way.
Normally, when you create-domain-class or create-controller even the tests are added in the same package as the domain class/controller respectively.
Best example of convention I can cite is when you use
grails generate-all yourPackage.Domain
Stumbled upon a similar post related to Grails where exactly the package by feature aspect as mentioned by Nathan is explained. Hope that helps.
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 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 8 years ago.
Improve this question
I've been building Rails Application Prototypes and Loving it. I'm aware that there are many pre-build libraries to utilize in projects.
While, I'm not a fan of using plugins for managing login and user authentication, which is core part of the app, aside from that what other chores can be dealt with plugins/gems, like pagination etc.
What do you use in your day to day rails development.
There are times when using freely available plugins/gems (libraries) may not be suitable but since it is quite trivial to review the code of these, in the long run you will find that many of these gems can be quite handy. A lot of these are also actively kept up to date by the community and this is also an important point as Rails in particular has been evolving at a fairly rapid pace.
For example, Devise has been around for quite sometime and if you look at the amount of support this tends to translate into a commensurate number of blog articles and how-to's on the web; even here on SO Devise in particular gets many questions. It also has many modules that you can incorporate within your app, or just disable if you do not require their functionality.
Rather than going into the benefits of plugins, I suggest you visit http://rubygems.org/ as it let's you go through the various gems based on their particular functionality.
Personally, I use Devise as well as authentication from scratch, Omniauth, Kaminari (pagination), CanCan for ACL and quite a bit more. This is the Gemfile from one of my recent apps and it should give you a decent idea of what I use.
Being familiar with popular gems is quite handy as it means rather than having to 're-invent the wheel', when it simply comes to getting the job done... you do have options - especially when it's not the sole purpose of your app. Certainly though, if you're up to creating custom plugins or decide to pull out reusable code into plugins, do share them with the community.
Hope this helps!
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 8 years ago.
Improve this question
I am using indextank with heroku. Which is a better gem to use, indextank or thinkingtank? I looked at the documentation, and tutorials for both,and it seems like thinkingtank is easier to use. A related/follow up question: what are the advantages/disadvantages of each?
It depends on what you're doing. If you are writing a simple app that's not based on ActiveRecord, the indextank client lets you add and search content without storing anything within your app. An example: if you are fetching tweets, you could index them directly without having a data model on your side. It's more "low level", so to speak.
If you are using ActiveRecord or another ORM, you should take a look at Tanker, it's more actively developed than ThinkingTank:
https://github.com/kidpollo/tanker
Hope this answers your question, if not please come chat with us at http://indextank.com (chat widget on the main page) and we'll be happy to help!
As Diego said, Tanker does seem like it has much going for it. Alternatively you could use IndexTanked:
https://github.com/zencoder/index-tanked
We wrote this library to power search on zencoder.com. Documentation is non-existant so far, but is coming.
One important feature included in IndexTanked, that was a necessity for us, was fault-tolerance. IndexTanked includes configurable fallback methods for use in case of failure to index, delete from the index, or search. Additionally, it limits calls to indextank by checking if the indexed fields have changed on updates. You can even obtain which fields we're checking against so you can select the minimum viable fields to be indexed when needed.
You can drop the author, Adam, a line at adam#zencoder.com if you have an questions (perfectly reasonable with the lack of docs).