Chris Oliver

Okay cool, that's a bit easier! I would say then what I would recommend is a background job for uploading the individual files. You can do the original upload quickly, Carrierwave can complete, and then you can fire off a job to extra the zip and upload those files.

There's a gem called https://github.com/chrishein/s3_uploader that takes a source directory and it recursively uploads all the files and folders to Amazon S3 for you. It basically does exactly what you want it sounds like. You could toss this in a background job and keep a status on the record to know when it completes. Basically start this job as soon as the Carrierwave upload completes and you should be good. You could probably fire it off as part of a processing method like you've got above, just passing in the zip to the background job. The only thing might be that if Carrierwave deletes the temp file when it completes, you may need to extract before starting the job and then pass in the directory of the extracted zip instead of the file directly.

It would be nice if you could upload the zip and have S3 do the extract, but that only seems possible by doing a AWS Lambda function, so I'd probably recommend the s3_uploader for simplicity.

I couldn't agree more. :)

I believe you're going to run into a few issues:

1. Carrierwave usually expects you to only have one file stored per mount. You can create cropped versions and such, but you have to mostly define those ahead of time.
2. How are you planning on referencing the expanded files in S3?

It sounds like you might not really care about saving the original zip file, but instead references to all the individual files that get created. The trouble is you won't know those files or folders until after the unzip. You may need to build your own sync to S3 for those extracted files and create another table to reference those as I'm not sure Carrierwave can handle that.

Now, something I've been using recently is Refile. It does allow you to create your own arbitrary files and then store them. I'm not sure that it will preserve the folder structure of the zip file though, so it might not matter. They have an example of uploading a video and storing both the video and a screenshot of it in the same attribute. It's closer to what you want, but not quite.

Are you wanting to preserve the file and folder structure?

Right. There's no official requirement to make URIs case insenstive.

Domains themselves are always downcased as it's part of the RFC but it is up to your web server to handle case sensitivity for the rest of the URL. It sounds like the rest of the URL should be case sensitive according to a more recent RFC.

http://stackoverflow.com/questions/15641694/are-uris-case-insensitive

That said, I've never had a situation where case in URLs mattered. Since users basically never type URLs, this is a super rare case that almost never comes up unless you're fiddling around in development.

If you do need that, looks like that middleware would work. You could also possibly do a rewrite in Nginx or Apache in order to downcase, which would be faster, but I'm not sure if it supports that type of thing. Usually rewrites are for changing the domain or URL entirely.

As long as your new app uses the same stuff as before, yes.

The passwords are hashed and salted and stored on the User record. Then moving the database to a new app doesn't matter because to check a user's password you go through the same hash and salt process to verify it. Nothing in your app is unique to that process, just the user's password. As long as your old app used Devise and your new one uses Devise too, then migrating the database to a new instance should work just fine.

For example, you could transfer the production database to your laptop and running the code on your laptop, you should be able to login to your production account just fine as long as you use the same authentication method in both places.

If you move between Devise and something else, then you'll have to make sure the authentication methods operate the same way. That's doable, but it's harder as you'd have to write code to make Devise use the same algorithm for hashing passwords as the old system.

Of course, I would caution you not to delete the old app until you can guarantee your new site is up and running with the database.

Oh very cool. Nice feature to have. If you're having trouble with it, definitely ask on the SearchKick github issues page. They're the ones that know it best and can probably point out the problem right away.

That's what local_time does. :)

Ha, no worries at all. :)

You'll need to tweak or at least work on both a bit. Basically you want to create a private Chatroom where the only two ChatroomUser records are you and the person you want to talk to.

The main thing is probably that you could create a "direct_message" attribute for Channel where you can mark it as a direct message and auto-attach the users (yourself and the person you want to DM). On create, you can attach the users to it, and then pretty much everything else probably works about the same. The navbar probably renders direct message ones separate from the main channels and should only display for users who are in it.

Absolutely. If you've looked into ES-rails or ES-ruby gems there docs are pretty poor at best last I saw. I'm sure it's getting better and eventually will be on par with Searchkick, but for now they feel behind. Searchkick is basically a nice ruby-ish wrapper so everything feels intuitive whereas ES-rails and stuff came from non-ruby devs you can tell so it's less ruby-ish in style. I still use Searchkick on a daily basis and recommend it.

My guess is over the next year or so the official ES-rails/ruby gems will get all the nice helpers and things to make it smooth to use like Searchkick but until then you can't go wrong with Searchkick.

Hey Dale, you'll probably need to create that file if your Rails app doesn't have one. Some details on that file: http://edgeguides.rubyonrai...

What URL issues are you having?

You can use fields_for in the form to have form set both the User and Company objects together. Your User model will need accepts_nested_attributes_for :company on it to properly assign the attributes.

I did an example on that with this episode using the forum as an example: https://gorails.com/episodes/forum-nested-attributes-and-fields-for

It definitely can take a while sometimes. Depends on how powerful your computer is and stuff.The good news is you rarely need to do it so once it's done, you will be set for quite a while!

Jacob,

You should be fine putting it in RegistrationsController, my mistake. The main reason why they suggest ApplicationController being that not everybody overrides the RegistrationsController, so it's easier. It can definitely go in RegistrationsController too because that's really where it's being used.

I don't know about combining it, other than setting the arguments to a variable and passing in just the variable into both.

Yeah, I think normally the devise_paramter_sanitizer stuff has to go in ApplicationController. Not entirely sure why but I guess because it's common and that doesn't require people to override the RegistrationsController.

I don't have a video on it, but that's a good topic. My Guides link in the navbar is actually like this.

What you want to do is setup a before_action to set your instance variables so you can use them in your partials that you include on every page. That will set it up so that you always have them available and can display them on every page.

I'll have to make a screencast on this as well!

Awesome to hear! :)

Great point Rick! That's probably a common problem for anyone trying this. Thanks for sharing that. 👍

I'm going to be doing a series on deployments coming up soon.

In the meantime, check out this episode: https://gorails.com/deploy/...

I ssh into the production machine and create the secrets.yml which we symlink on every deploy so your production secrets are kept separately and only the server.