Chris Oliver

I've been pretty happy using #3 because it doesn't slow down the page load at all, and you can still customize those pretty well. The downside is you can't include the count of shares because that requires JS.

If you do need those extras from the JS, you could use a service to simplify, or a relatively easy way is just to include the JS libraries using the official instructions. I've found that using services like AddThis are really just a pain to use. Same thing goes for gems, it's just adding an unnecessary layer of abstraction to it that you don't really need.

I just updated my open graph tags tonight and did the following in the head in the layout.

<meta name="twitter:card" content="summary" />
<meta name="twitter:site" content="@gorails" />
<meta name="twitter:title" content="<%= yield :title %>" />
<meta name="twitter:description" content="<%= yield :meta_description %>" />
<meta name="twitter:image" content="<%= asset_url "open-graph.jpg" %>" />
<meta name="twitter:creator" content="@excid3" />

That way the views can have the following code to put in the yield sections.

<%= content_for :title, @episode.name %>

You can then wrap the head code with the following to include it or not based upon existence of the content:

<% if content_for?(:title) %>
<% end %>

I believe there's a "converters" option that you can pass in. It basically tries to convert every column to a Date object and if it is successful, it will use that. You'd pass in the ":date" option for it (something like converters: [:date] I believe). You can read a bit more about that here: http://ruby-doc.org/stdlib-...

Plus if you have something custom that doesn't work with that, you can write your own converter. I just did this for a project and figured I should make an episode on it. Pretty nifty and easy to do, but really poorly documented.

Ah that's disappointing. I wonder what the issue was with the JS...As long as you've got an easy admin to work with, that's all that matters.

Great question Jeff. I think Mongoid's docs do a pretty good job outlining the difference between it and ActiveRecord here: https://docs.mongodb.org/ec...

What Andrew said! For some of the controller methods, you can sometimes just instantiate the class like any other normal object. The trouble will be that you don't have request objects to work with to pass in.

That's a really good idea! I'll do that. :)

Computers eh? :)

It's pretty much the most awesome one I've seen. I'm going to have to do an episode on it soon.

If you don't need anything too complicated, Basecamp just released their new text editor that I found to be really good. It's called Trix. https://github.com/basecamp/trix

There's also CKEditor and TinyMCE that have been used by a lot of people in the past. I don't particularly like them, but they do a lot more than Trix.

I'm using ActiveAdmin for most sites since it existed beforehand, but now I'm starting to use Administrate in production. Only real concerns with this over production use is that it hasn't existed for all that long to work out the basic bugs. Since it's pretty much scaffolds, you can pretty easily debug anything that would go wrong. The main downside right now is going to be a potentially quickly changing API that may be more than you would want to deal with maintenance wise.

You can setup Refile to cache some file metadata like the filename to your model. https://github.com/refile/r...

That should take care of showing the filename and then anytime the URL is clicked, then that's when Refile will download the file. Just displaying the link won't cause it to download the file just to render the filename in the link.

Nope, that should still work out of the box. Server side will just continue to set cookies, but will only match users available for the current tenant.

That's because the sinatra app (which Refile is referring to) gets mounted to your Rails app at /attachments. Rails basically routes the URL over to the Sinatra app, effectively so that the files never hit your Rails code. It just gets diverted before Rails would start processing it. And then files are served up from the same url because that's where the Sinatra app is.

That's actually how it's supposed to work actually because it provides you the ability to generate different image sizes on the fly. The downside to this is it requires you to setup a CDN so that it doesn't have to generate the image every single request. You can check out the readme for some more information on that.

Thanks for the heads up! I'll take a look and see what's up!

That's great to hear!

Heroku really only recommends the two lines for url and pool. The rest of that is all handled by Heroku. The DB_POOL may not be set, which will default it to 5 which is fine. You'll be able to easily change that as you scale up your Heroku servers.

I'd probably toss everything in db/seeds.rb. Check out the ffaker gem for creating fake names and things.

If you need to create Devise users, you can just do this (but you'll have to give them passwords)

# You can optionally generate a password if you don't want to hardcode the password
# generated_password = Devise.friendly_token.first(8)

User.create(email: "test@example.com", password: "password", password_confirmation: "password")

And for paperclip images, you can use the ruby File library to open the file and assign it.

img = File.open(File.join(Rails.root, 'image.png'))
User.first.update(avatar: img)

You can use Rails.root there as a helper to get the Rails directory, and then you can join in any folders and filenames you need to get the full path in Ruby. Then you open it as a File object and assign that to your paperclip attribute. That should do the trick!

What is the contents of your app/models/admin.rb file? It sounds like the Admin class isn't defined in there for some reason.

Great question. If you want to use the existing Admin model from devise, all you need to do is add before_action :authenticate_user! to your admin controllers to force the admin user to be logged in. That should be it!