Chris Oliver

Since it's a class method, you can add .to_csv on any call. Service.all.to_csv or Service.where(name: "whatever").to_csv. Both will work and will return CSV's that are only of the appropriate results.

Ah, sorry I misunderstood. :)

So you have a dashboard with say like 4 tables of data and you want the user to be able to download each one independently? In that case, I would probably create a handful of extra routes and actions in that controller that just run those individual queries and export to CSV. That way you can keep them organized together nicely and still allow their separation.

The main recommendation is to try to write every cache with good defaults that's generic to the current user. For example, you'd write the cache and always include the edit link, but make it hidden by default. Then you can add some JS to display that link when the user has permissions. Obviously you'll need to write something to let the JS know what permissions the user has, so it changes things a bit.

The primary reason for having generic caches is that you end up not storing N number of copies of the cache because you have N number of users on your site. It's not good to have 1 million copies of a cache because you have 1 million users (of course). :)

DHH also talked about a similar situation in another blog or video where he mentioned handling the "share" form for Basecamp. Basically it's a list of all the users an object is shared with. They actually cache the form that includes yourself in it and then use JS to hide your name from the list because it would be weird to share something with yourself. Having a single cache really improves this and a small sprinkling of JS on top cleans it up nicely.

I'll have to do the next episode on this!

Hey John,

Any Javascript code you write inside the app/assets/javascripts folder gets included globally and is generally where you want to keep your code. It doesn't matter if you're using a regular form or a nested one, the JS won't care which is good for situations like this.

You might want to double check that you've got the right IDs for your fields because their names can change when you do nested forms. That is likely the reason that you're not getting any data filtered. Inspect the HTML on the page and make sure those form field ID's match up to your JS. With any luck, that hopefully fixes it!

That means a lot! Thanks so much for saying that Gilbert! :D

This one's a little tougher, but the basic idea is this: 1. Export your CSVs to temporary files 2. Zip them up 3. Send the zip file over as the download.

You'll have to do this because there can only be one file downloaded per requests, so hence the need for creating a zip file.

You guys can remove that passenger repository and install the version directly from Ubuntu. Should be good enough for now, and then once Phusion updates their repo, you can switch back to it so you can continue to get updates. http://packages.ubuntu.com/...§ion=all

What were the issues you ran into? The key names should be scoped accordingly, but other than that, you shouldn't have any issues sharing it.

Yeah, you could probably do that too with the cache key. There are a lot of different ways to set it up, your goal is really just to make sure that the key gets updated when your database changes and that it only updates when needed. Sometimes that will depend on your app and certain cache keys will make more sense than others.

I'm hopping into the forum this morning to answer a bunch!

I do usually recommend Redis most often and the reason for that is simple: You're probably already using it to run your background jobs with Sidekiq or the like, so you might as well just take advantage of that. You can run a separate Memcached instance but I don't think you're going to see a major difference unless there is a feature you specifically need from it that Redis doesn't provide. Basecamp uses Redis for caching, so that means it's definitely good to go. :)

You can try using the older trusty repository for now while they work up on updating their apt repository:

sudo sh -c 'echo deb https://oss-binaries.phusionpassenger.com/apt/passenger trusty main > /etc/apt/sources.list.d/passenger.list'

The main reason not to use that is because you can update Ruby versions independently of the packages. Ruby 2.3 will get patches, 2.4 will come out, etc and you may have older apps that use 1.9 for example. All those would be easily managed with a version manager like rbenv and you can install it without waiting for the package maintainers to update it.

Have you read this thread? https://github.com/mperham/...

You may just need to bump down your concurrency number for Sidekiq so it's not using so many connections or upgrade your Redis instance so you have one with more connections. Most of the Heroku things like this have some pretty low limitations on concurrency on the lower end.

It also contains the DB and cache because neither are that large. I still have 400MB of RAM free right now.

Fixed!

Whoops, just updated that. Hard to keep all these dang version numbers up to date.

Hey Christophe,

Didn't see this until just now. You actually need to provide the status in the search_data so that ElasticSearch can index it and allow you to query off it. Right now you don't have it, so the where query isn't going to be able to find anything with that attribute. You'll want to just add that status into the hash and then reindex and your search should work then.

Did you get this working? You'll need to also make sure your background job runner is a second command added to your Procfile. For example, you'd add sidekiq to your Procfile as a background process and that will make sure these deliver_later emails get sent on Heroku.

These are really two different things you can't compare much. ActionCable is websockets, allowing you to talk back and forth to the server in realtime. You'd still have to build your messaging system on top of that.

You can actually use ActionCable to implement a realtime messaging system that uses Mailboxer on the backend. It'd pretty much just require you to take the stuff I covered in the other episodes and rather than doing POST requests to the server, use JS to send it over to ActionCable actions. This should make for a pretty easy implementation of realtime messaging.