daijinara I think that the ERR_CACHE_READ_FAILURE is something about plugins or other tools on your system that is deleting the temp files. If you were to do a SHIFT + F5 (on windows) or CMD + SHIFT + R (on macos) then it should tell the browser to force download the files again and ignore your local cache.

There are some applications that will clear out temp files and your browser database did not get not of these changes.

I wonder if whatever thing that is causing your temp files to be cleared out is related to a long expiration life. Honestly, I don't know if there is anything to be done on the server side as this is getting served from CloudFlare's cache.

While I agree that daisyUI may violate some of Tailwind CSS's philosophy, I think it's also important to ask if those principals really matter to me or the project. I recently deployed an application to production using Tailwind CSS and daisyUI and the amount sent over the wire is about 17kB. Uncompressed, it is about 90kB. I'm okay with this even if there is additional stuff that is being generated and never used. Honestly, I really don't care too much about the CSS minimalism stuff. I care more about application maintainability and consistency.

I've dabbled with Shuffle a bit, but I don't use it too often. It's great for getting quick things in a view, but also rather limited in the stuff that it provides. Perhaps it will get better in years to come.

This example is where the db and rails app are separate (since we are passing in the host). But, since the rails app has access to the db server, we can access it via the rails app server.

As far as obfuscating sensitive data, things would be more simple in smaller datasets, but when you're dealing with millions of records, it can quickly get complicated and take a long time. Some of the issues with large data would be 

I know that we're sometimes in situations where we get to the point of saying, "but I need the production data". At that point, I would probably do a "hotfix" to add more logging in the area of the application and see what makes this particular org/company/user so unique. From there, you should, hopefully, be able to replicate it in your staging environment. If, you're seeing the same issues, then try to replicate it locally. If you're still unable to replicate the issue locally, then you could pull the staging database where the issue is being experienced. If pulling and loading the data to my local environment doesn't replicate the issue then there could be a difference in the environments (at an infrastructure level or some kind of environment flag within the code).

So, while it is kind of avoiding the question, I think that we shouldn't ever pull the production database (regardless of obfuscation or not).

  Luke Scott I would make a Ruby class which took in the results of a questionnaire and format it in a way that you're wanting the CSV to look. So, you'd basically make an array with the first item in the array being an array of all of the headers. Then you'd loop through each response and put their response in the appropriate position in the array. From there, you can generate the CSV response and send a file to the client.