Avoiding Rails Plugins, as much as possible (AMAP?)

Rails is a marvel piece of software, ever-evolving, ever-maturing.

Out of the box, if comes with ever-increasing features, which is making the web development cycle, and workflow, more comfortable from the point of view of the developer. Some of the less-known features, which can be used, to construct useful use-cases. Each of these are potential plugins but open to your choice of implementation

Usables #

Say you have a weird / unorthodox model name, like Person. You would expect Rails to say 10 people, and 1 Person. (This is a default implementation supported by Rails, but proves the point).
A normal implementation would tell Rails to make the plural, 10 persons.
The override is provided in config/inflections.rb

inflect.irregular 'person', 'people'

(You might note, the line is commented, as it is handled in Rails, but given only to provide an example)
You can choose any over-rides that make sense to your application and define them here.

Say you want to measure how long some specific ( or all methods ) take to execute. Most useful measures are against controller methods, say

how long does this post call take

You can write your own tests, and keep running them periodically, log the results, plot charts, and do all sorts of house-keeping once you have the data.

Details available at Official Rails guide.

Rails provides a number of hooks for an exhaustive set of actions. Official guide.

Slightly real-life examples.

Add custom hooks when say,

This is well encapsulated in a Rails plugin, which I highly recommend, if you need this kind of job frequently.

Avoidables #

Although there are some very popular plugins, which are frequently used, and can be avoided. Here are a couple I have come across while working on my startup GetEchoed

Like /users/100 might become /users/100/example-user (if the name of the user is, admittedly funny, Example User).

This plugin provides this functionality through some simple configurations, and is a highly useful-cum-used plugin.

The only requirement for this to work, is that the url generated (which is technically called slug) should be uniquely identifiable.
It means 100/example-name should be a unique combination.

Thats what most of us need, in most cases.
My suggestion, instead of using the heavy plugin, and force your project to behave as per the plugin’s (although powerful) restrictions, DIY.

Over-ride the show method (in this case) like
/users/:id/:name in routes and in your controller method, handle the logic.

user = User.find_by_id(params[:id]).to_i
render_404 and return unless user && user.name.parameterize == params[:name]

The key step here is the .parameterize method, which converts
Example User to example-user

as highlighted in the method definition

Cons:

Alternative: Use http_basic_authenticate_with or authenticate_or_request_with_http_basic.
Both are easily Google-able and have lots of supported documentation all over the web.

The idea is to have the credentials, in your .yml files and use them to authenticate.
Early on, that is all the stuff one actually needs. As time passes, one usually needs different admin actions, and having a framework for the UI/Templates does help.
But Bootstrap / Formtastic etc give enough of all that.

Conclusion: Not saying it’s a bad choice to use plugins/extensions. But using them means one is acknowledging, that all future behavior of a personal project has to adhere to the way the plugins accept. So one should be a little cautious in choosing which plugins can be used for a long time and which put the project in a deep and convoluted third-party-logic.

Discussions at HN

 
15
Kudos
 
15
Kudos