Chris Oliver

Awesome, I just ran into a thing that I need to have SSL for a side project last night so I'm going to try using Let's Encrypt to get that setup. Can't wait to try it out!

Hey Mark,

Yeah, so I think the one thing with multitenancy is that the goal is to truly separate out all your data between users so they never intermingle. Most people don't actually want or need that, but some do for security reasons. Sounds like in your case you don't really need it.

I'm not sure of a better way of structuring this for you because regardless you're going to be stuck within the tenant. What if you don't use tenants and instead make sure that you scope all your queries to the current user or organization?

The authenticity_token: true thing makes me think the same. I haven't ever had to do that, but maybe something has changed more recently that I don't know about. Always possible!

Hey Kosta,

I'm not sure entirely what's wrong, but here's what I would do:

1. Take this and run it in your rails console: Post.search(params[:term], fields: [{title: :text_start}], limit: 10).map(&:title)
2. If this doesn't return an array of string like the test example, then you know this is the problem and you can start fiddling with that to get it to return the right format. Maybe you just needed to reindex or something simple.
3. If it does return an array of strings, then go into your browser and check that the JSON it receives is correct. You can print it out in the browser with a console.log to verify that.
4. If you are receiving the correct JSON in the browser, then you can check to make sure this gets passed over to the autocomplete correctly. You know this probably isn't the case because the test JSON did work, so it's the least likely to be the problem.

That should help you break apart the problem to figure out what's the piece causing the problem and it'll probably be obvious once you get there. :)

You save the customer to an instance variable in the initializer so that you can save it around and use it in any of your subclasses automatically. They don't have to worry about how they get the customer, they just know they have it so they can implement only the calculation.

You might continue on a bit, I ended up refactoring this to use ActionCable to send messages over instead of an AJAX form because you might as well be using it two ways.

I'm not sure what's up with your authentication token, but it does sound like your server side is looking for an HTML response, not a JS response, even though if it was an AJAX request, it should. Sounds like something's not quite right with that somehow. I'm not entirely sure off the top of my head though.

Hey Nikola, looks like you don't have a @chatroom_user record set. That was one of the things we discovered was missing, so you'll want to make sure that your user's got that record when they join. We made a couple tweaks to this to fix a couple bugs on Github, so you might want to check those out: https://github.com/gorails-...

Let me know how it goes! I was considering upgrading to the GM too, but I'm a little afraid to just because I don't have a backup computer to use in case something goes wrong. :)

I haven't yet, but I know that people were using my guide on Sierra really early on. Xcode and homebrew got updated rather fast this time and while I'm sure there are still some issues with it, it sounds like it's working pretty smoothly for everyone.

Here's some packages that aren't currently compatible with Sierra: https://github.com/Homebrew/homebrew-core/issues/1957

Probably some other Github issues you could find on compatibility stuff, but as far as I've heard I think you'd be safe to upgrade.

I realize I'm about a month late on replying to this thread, but I'm definitely going to add this to the guides.

It looks like the renew goes into the public folder in your app. Does this mean that if you do a new deploy with Capistrano it loses access to that file if you ever rebooted nginx or are you symlinking the directory that Let's Encrypt creates on your deploys?

Glad you love it and we're happy to have you as part of the community! :D

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.