Essential Gems

[Craig Read]

Hi Everyone,

Being a rails newbie, I'm still discovering a lot of awesome gems that I'm sure you lot already know and love.

eg.

During lunch, I implemented formtastic and rbates' nested_form in one of my views.
That view was starting to get reasonably complex, but is now looking significantly cleaner (about 75% less code), and I have eliminated a bunch of javascript in the process.

So, instead of me continuing to write a lot more code than I really need to:

What are the gems you feel you can't do without?
Which ones are great at drying up your code, and/or just making life easier?

Cheers,

Craig.
--
Craig Read

@Catharz

https://github.com/Catharz

http://stackoverflow.com/users/158893/catharz

[Nicholas Faiz]

Inherited Resources. It's great. 

https://github.com/josevalim/inherited_resources

[Simon Russell]

It is quite good, except for the deprecation notice...

> --
> You received this message because you are subscribed to the Google Groups
> "Ruby or Rails Oceania" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/rails-oceania/-/Pi0AXwqe3GwJ.
>
> To post to this group, send email to rails-...@googlegroups.com.
> To unsubscribe from this group, send email to
> rails-oceani...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rails-oceania?hl=en.

[Yasith Fernando]

Devise https://github.com/plataformatec/devise

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

To post to this group, send email to rails-...@googlegroups.com.
To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.

--
http://blog.thekindof.me/

[Lachie]

essential?

http://rubygems.org/gems/rails

nyuk nyuk nyuk

:lachie
http://smartbomb.com.au
http://www.flickr.com/photos/lachie/

[Justin French]

+1

Justin

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rails-oceania/-/Pi0AXwqe3GwJ.

[Louis Simoneau]

When it's relevant, state_machine is a must have for me.

[Rob Howard]

Cocoon ( https://github.com/nathanvda/cocoon ), fills the gaps Mr Bates' nested_forms leaves.

[James Healy]

On 15 May 2012 17:23, Nicholas Faiz <nichol...@gmail.com> wrote:
> Inherited Resources. It's great.

Personally I avoid inherited resources and devise like the plague.
They're helpful for the simple case, but as soon as you start
overriding the defaults you end up with control flow that's impossible
to understand.

I also strongly believe rails controllers should clearly display the
valid actions very explicitly. Any plugin that secretly adds a destroy
action is bad news.

Here's a few key gems that I use on nearly every rails project:

country-select
- add country select boxes to forms

fog
- API wrapper for cloud providers (AWS, Rackspace,etc)

strip_attributes
- remove whitespace and convert empty strings to nil before saving a model

whenever
- mini DSL for configuring crontab

tiemcop
- useful test helper for controlling time

machinist
- an clean and straightforward alternative to factory girl for building
data in test suites.

delayed_job
- simple queuing library for pushing tasks out of the HTTP request
cycle (sending emails, external API calls, etc). It's got some rough
edges, but works well enough.

rein
- migration helpers that setup proper FK constraints in the database

James

[Mike Bailey]

Capistano for running commands on remote servers

Rake for running them on local machines

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
To post to this group, send email to rails-...@googlegroups.com.
To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.

--

- Mike

e. mi...@bailey.net.au

w. mike.bailey.net.au

[Ben Hoskings]

On 15/05/2012, at 10:27 PM, James Healy wrote:

> On 15 May 2012 17:23, Nicholas Faiz <nichol...@gmail.com> wrote:
>> Inherited Resources. It's great.
>
> Personally I avoid inherited resources and devise like the plague.
> They're helpful for the simple case, but as soon as you start
> overriding the defaults you end up with control flow that's impossible
> to understand.

Totally agree. I think the idea behind inherited_resources is laudable -- the less repetition, the better -- and I've used it a fair bit in the past. But I've come to realise that while the idea is sound, the implementation isn't, for the reasons James gave. A real-world controller (i.e. with a couple of customisations) backed onto inherited_resources is too surprising to work with reliably.

It's less bad than using before_filter because the overrides are exposed methods within inherited_resources' implementation of the action, and so will appear in the callstack. But it still violates the principle of least surprise.

Anyhow, I really like:

* rein -- A great set of helpers to add DB-level constraints within migrations. Written by Josh Bassett.

* sequel -- A very capable ORM, that in particular supports a lot of postgres' advanced features, but is also fantastic for quick, lightweight DB stuff from ruby-land (particularly from a sinatra app).

* ir_b -- What I use instead of ruby-debug: it drops you in a repl at the current binding, and it's about 70 lines of code, with no dependencies. In fact, it's worth checking out the code: it's a good lesson about how bindings in ruby work. https://github.com/jugyo/ir_b/blob/master/lib/ir_b.rb

- Ben

[Nicholas Faiz]

Hi,

This is becoming amusing. :) I almost replied to James' post to disagree. In the interest of defending IR I'll just make a quick response.

Everything in IR is configurable. The argument, for e.g., that it's bad because it configures destroy methods on your controllers is only a statement that IR is bad for programmers who don't know how to use the tool properly, specifically a statement like:

actions :all, :except => [ :destroy ]

To say that this configuration is risky is somewhat similar saying that it's foolish to use the resources helper in routes, e.g.( resources @foo ) because you might forget to exclude certain routes.

So yeh, I really can't see the problem with IR generally. It's quite a good lib.. The further issues touched upon like extending its workflow have never been an issue for me. It's object creation lifecycles are easy to wrap around (create!, update!, etc.) and it's easy to place appropriate filters to control how it builds its data.

I generally start out by letting all of my controllers use it, then refine actions as I need to. There are some situations where it's easier to just not use IR, but for most things it's a great quick start.

Cheers!

Nicholas

[Michael Pearson]

Gems I wish I'd known about before I used them, Rails focused:

foreman: for running many things at once as part of your application (eg web server, delayed job, etc)

draper: model decorator pattern for Rails

haml: HTML is awful, ERB makes it worse

airbrake: any exception that occurs on your site gets reported to a centralised upstream (although with ab's recent issue I'm very close to switching this to exceptional)

sass & bootstrap-sass: TW bootstrap is an excellent general-purpose toolkit, especially if design isn't your focus

mailcatcher: daemon that intercepts & displays outgoing mail in your browser

with caveats:

guard, spork & spork-rails: essential if you're doing TDD in Rails, but a real pain to set up in some cases.

On Tue, May 15, 2012 at 5:13 PM, Craig Read <craig...@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
To post to this group, send email to rails-...@googlegroups.com.
To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.

--
Michael Pearson

[Iain Beeston]

+1 for exactly what james said (that's been my experience too).

Faker is nice to have. Capistrano make my life a lot easier

Iain

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rails-oceania/-/rIdN-3vEei4J.

[Iain Beeston]

I'd definitely recommend spin as an alternative to spork

Iain

[Daniel]

On Tuesday, May 15, 2012 10:27:39 PM UTC+10, James Healy wrote:

On 15 May 2012 17:23, Nicholas Faiz <nichol...@gmail.com> wrote:
> Inherited Resources. It's great.

Personally I avoid inherited resources and devise like the plague.
They're helpful for the simple case, but as soon as you start
overriding the defaults you end up with control flow that's impossible
to understand.

+1 for inherited resources making things hard to follow.

[Nicholas Faiz]

Just to follow up on my defense of IR, it was brought up in #roro again today and I ended up noticing that the author, Jose Valim, has formally deprecated it.

So, yeh, unfortunately, I'll have to rethink my usage of it now. I still disagree with a lot of the criticisms made toward it, and want to specify that Jose has said he's no longer continuing with it because he finds the responders gem along with Rails 3 to be a better solution for the problem.

From what I've gathered, seeing the responses made here and in channel on #roro, IR can easily be abused. So I suppose that's just the power of complexity.

Cheers,

Nicholas

[Ben Hoskings]

On 18/05/2012, at 1:26 PM, Nicholas Faiz wrote:

> From what I've gathered, seeing the responses made here and in channel on #roro, IR can easily be abused. So I suppose that's just the power of complexity.

That's just the thing, though: complexity (in the sense of things being intertwined, which definitely describes IR) is something that should be avoided.

http://www.infoq.com/presentations/Simple-Made-Easy

- Ben

[Nicholas Faiz]

Well, I was just back from the gym when I wrote that. It should have read 'the *danger* of complexity'!

I agree it's complex and can easily be misused. I just loved it because I'd found a good way to use it and it saved me so much time.

Cheers,

N.

[Craig Read]

Thanks for the responses everyone!

Good to see my question raised some controversy with gem selection too. ;)

As an aside, I'm going to implement delayed job for pulling some stats down from a 3rd party API into my app.
I'm hosting it on Heroku, and it seems hirefire is the go for managing the dynos.

Does anybody have any experience with this, thoughts to share, traps to avoid, etc?

Cheers,

Craig...

[Nigel Sheridan-Smith]

Hi Craig,

Delayed Job works quite nicely... been using it for a few things.

I'd recommend capturing the failed jobs (a non-default configuration setting) and then finding out when they fail. The error message and exception trace is captured in a database table column called 'last_error'.

Delayed Job will retry failed jobs about 5 or 6 times by default I think.

Other than that, its pretty easy to use and get set up. In the console, you can use Delayed::Job.count, Delayed::Job.delete_all, etc to refer to the database records like any other ActiveRecord object.

There was one gotcha - I think I had to pre-load the job classes in delayed_job_config.rb:

# Add any custom job classes here!
require Dir.getwd + '/app/models/userload_job.rb'
require Dir.getwd + '/app/models/sq_job.rb'
require Dir.getwd + '/app/models/friendcount_job.rb'

From memory, if you don't do this, then no job is created and no error is logged anywhere when the job fails to be created. The downside of this is that you typically have to restart the Rails server if you change the code in these classes.

Cheers,

Nigel

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

To post to this group, send email to rails-...@googlegroups.com.
To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.

--

http://www.whossingle.net - check out who's available, engaged or taken amongst

your friends and their friends

http://www.partneredup.com - a new way to meet people online and offline

Dr Nigel Sheridan-Smith PhD BE

Mob: 0403 930 963

Email: nigel --AT-- partneredup.com

LI: http://www.linkedin.com/in/nsheridansmith

[Dmytrii Nagirniak]

Hi,

This is the Gemfile from one of my projects.

Couple of things to notice though:

- allowy - authorisation tool that I use extensively, inspired by CanCan but with you controlling everything.

- inherited_resource - as others said, I try to avoid using it and it's still there due to historical reasons :)

- squeel - it is amazing, you won't want to use Arel after it :)

- pry (and friends) - using for all the debugging things. It is amazing. There's a lot of drama with Ruby debuggers.

- its - nice RSpec extension to simplify simple specs :)

- fuubar - RSpec "progress" formatter. Quite nicer the any built in.

The rest I think is pretty explanatory.

Any critiques on my gem set?

Cheers,

Dmytrii

http://ApproachE.com

[Dmytrii Nagirniak]

Silly me, forgot to add the link, sorry :)

https://gist.github.com/f45e00df4acc38740623