Chris Oliver

Looks like you're on the right track. Step through that and make sure each piece is running like you expect. I would imagine it's something simple in there that's not working right.

Yup, that's basically how I did it too. :)

I just created two form_fors and separated them out. Since both of mine run through Devise, you don't have to do any of the updates to the action because it will just save whatever fields you pass in and it doesn't matter which button was submitted because the logic doesn't change.

You might be able to refactor your action so that it handles things the same way. Basically always try to update the name and profile information. If you didn't receive and field data for it, then no updates are applied. Same for the password. If you didn't pass in the field, it won't attempt to update the password. That would help you remove those two if statements. :)

Usually you will want your mobile app to submit the email/username and password to the sign in endpoint with a JSON format. You can then have the sign in return you JSON for the user, namely the auth_token. That way your mobile app can create its own form, submit the login request, and if it's successful, you can receive JSON for the API key.

Double check that your ~/.bashrc has the rbenv lines in it. This happens when bash doesn't properly load rbenv, and that happens because it doesn't add it to the path in your ~/.bashrc.

That will depend on how big your server is and it's configuration. I haven't tested any websocket stuff at scale, but I've seen some performance tests for 10,000 users before. It starts to slow down at a point, and they were using simulated things, so never real world data. Your mileage will probably vary quite heavily if you start going past a couple thousand users.

Let's pretend I planned that. 😉

Absolutely. Check this out: https://gorails.com/episode...

I have my redis server always running on my laptop on the default port so it is always ready to go. Homebrew comes with instructions on how to start it when you login. If you follow those it will set it up the same way I have.

Perfect. Thanks for sharing that Bob! :)

Yep. You can implement the subscription webhook that gets triggered on delete (or cancel, don't remember the exact name) and just have it remove it from the user on your end. You'd build it same as the other one, but just remove the subscription ID from the user.

I'm hoping to get into React soon!

One of the main things with caching for it will be that you only really need to focus on caching your JSON that the React code will load since it generates the HTML. You won't get performance benefits from caching HTML like you would with Rails, so you can do it on the JSON instead.

That would be https://aws.amazon.com/elastictranscoder/ There's also https://zencoder.com/en/

Hey Giorgos,

This is absolutely a complicated thing to do unfortunately. There are a lot of things that just aren't well defined yet for recording audio and video.

1. The best place is probably going to be storing your videos on Amazon S3. You can use their transcoding service to make the videos web compatible and take screenshots and send the results back to S3. You can also put up a Cloudfront CDN in front of that so downloading the videos will be faster. You'll also only pay for what you use, so the more downloads you get, the more you'll pay. Helps to have your costs scale accordingly.

2. You can check out some things like this which will allow you to record the webcam and audio in HTML5. https://addpipe.com/blog/mediarecorder-api/

And there's webcamjs which will be useful I'm sure: https://github.com/jhuckaby/webcamjs

I don't know too much about all this but I'm likely going to be diving into a video project deeply sometime soon so maybe I'll know more in a month or two.

I like the added_attrs array. It's nice to reuse since I had always just defined the items in each place.

Hey Diane,

Two different approaches you could use:

1. Keep it simple and go with a Turbolinks-Android hybrid app where your chat is via the webview on the app. This is simpler and easier to setup.
2. You could do a native Android connection directly to the websocket. For this you'd basically use a standard websocket library for Android and then make the small tweaks necessary to setup the consumer just like the Javascript does. You'd basically be porting that JS into Android code. Not entirely sure on all the details or if someone else has done this already, but that's the rough outline for a native approach.

Glad you got that working! Certainly seems weird that it wasn't picking up any environment variables! I don't think I've ever run into that, but it makes sense why you were having that problem then.

Glad you like it! 🎉

I gotcha now. So I would keep everything organized on the Message's ID. You can client side send over a message and you could set it up to send back a message ID. That way you now it arrived server side but it's "processing". Then server side you can store that message and tag all your ActionCable broadcast stuff with the Message record's ID. You'll get a database log of messages which is important for loading up the first time, you can load recent history, and you can use that for troubleshooting. The Message record can have a statemachine on it so you know if it was broadcast or not. Slack basically does this when you're having internet issues. It can tell when something got published or not and keeps track of that nicely. You can flag those messages as "ready for broadcasting" or something and then after you broadcast it in the Relay Job, you could then mark it as complete so that if your job did crash or something, you wouldn't resend it.

As long as they're both recent versions, AWS is probably going to be better scaling, but you probably can't go wrong either way.

Not sure I'm following the question, can you clarify for me? 🤓