Chris Oliver

Basically at this point now, you'll need to use systemd to manage Sidekiq. It will make sure it starts or if it dies, it will restart it. This is nice, but kind of confusing sometimes how to get it setup.

I have this in /etc/systemd/system/sidekiq.service and you can enable it and manage it using the commands at the top there.

#
# systemd unit file for CentOS 7, Ubuntu 15.04
#
# Customize this file based on your bundler location, app directory, etc.
# Put this in /usr/lib/systemd/system (CentOS) or /lib/systemd/system (Ubuntu).
# Run:
#   - systemctl enable sidekiq
#   - systemctl {start,stop,restart} sidekiq
#
# This file corresponds to a single Sidekiq process.  Add multiple copies
# to run multiple processes (sidekiq-1, sidekiq-2, etc).
#
# See Inspeqtor's Systemd wiki page for more detail about Systemd:
# https://github.com/mperham/inspeqtor/wiki/Systemd
#
[Unit]
Description=sidekiq
# start us only once the network and logging subsystems are available,
# consider adding redis-server.service if Redis is local and systemd-managed.
After=syslog.target network.target

# See these pages for lots of options:
# http://0pointer.de/public/systemd-man/systemd.service.html
# http://0pointer.de/public/systemd-man/systemd.exec.html
[Service]
Type=simple
WorkingDirectory=/home/deploy/myapp/current
# If you use rbenv:
ExecStart=/home/deploy/.rbenv/shims/bundle exec "sidekiq -e production"
User=deploy
Group=deploy
UMask=0002

# if we crash, restart
RestartSec=1
Restart=on-failure

# output goes to /var/log/syslog
StandardOutput=syslog
StandardError=syslog

# This will default to "bundler" if we don't specify it
SyslogIdentifier=sidekiq

[Install]
WantedBy=multi-user.target

Not that you'll need to change the WorkingDirectory option for the location of your app and this assumes you're using rbenv on your server for running Ruby.

This setup is for only accepting tokens to authenticate on the API. You can just pass over the Authorization header in Postman to test it out. You'll need a valid token, but just pass in "Authorization: bearer YOURTOKEN" as the header and that should do it.

Btw, the other episode I posted today shows how you can take this code and add it as a Devise strategy so you can use tokens to authenticate with Devise alongside cookies. Check that one out so you can see how to use Devise with it. :)

In Slack, just add yourself to the #gorails-forum channel. 💪

Just like you would do with sending any other email. You can read more on the guides page: http://guides.rubyonrails.org/action_mailer_basics.html

Hey Neil!

Attachments are pretty easy. You use the attachments method on the email and give it a file object.

class ReferralMailer < ActionMailer::Base
  def referral(recipient)
    attachments['referral_form.pdf'] = BefriendingReferralForm.new(@current_referrer).render
    mail(:to => recipient, :subject => "New account information")
  end
end

Since you're rendering your own file, you just pass that in and Rails should take care of the rest.

Yep, this is because Turbolinks 5 works differently than the previous one where you could use jquery.turbolinks to enable all your standard jQuery -> code to work as expected. Thanks for sharing the reminder with everyone!

Hey Stan!

You can do a pretty simple select and map to get the array of text strings here:

irb(main):002:0> @output.select{ |i| i["type"] == "Person" }.map{ |i| i["text"] }
=> ["Gloria Etting", "Betsey Cushing Roosevelt Whitney", "Emlen Etting"]

Basically the select filters the list, and map transforms the results from an array of hashes into an array of just the text attribute values. Then you can loop through that list and print them out in your erb.

🤘

It does! If anyone wants to join us in slack, the #gorails-forum channel has all the notifications now. 🤠

Just testing out slack forum notifications.

Like Jacob said, that would be up to your implemenation.

find_verified_user just needs you to return the User object. That's what you get from warden, so your implemenation will be similar, just however you retrieve the User object in your setup and that should do the trick.

I don't think you need Flash for anything these days. Also keep in mind that HTTP streaming can be used to describe streaming HTTP responses, not necessarily video. For example, you could use HTTP streaming to send realtime updates for a chatroom (before websockets were the better solution). HLS is similar to MPEG-DASH in that it's a video streaming protocol that uses HTTP. Kind of confusing stuff.

http://weblog.rubyonrails.org/2011/4/18/why-http-streaming/
https://en.wikipedia.org/wiki/HTTP_Live_Streaming

Then there's all this WebRTC stuff that's very similar, but another rabbit hole to understand. Apple doesn't support any of the WebRTC things yet, so you have workarounds for that as well I believe.

I feel like it's gonna take a lot of reading to get my head wrapped around all this, but it's some really neat stuff. I'm super fresh to all this stuff, so my descriptions of it could be way off as well. :)

That's great to hear! :D And I agree, it's a tough one to wrap your head around the first time.

Good catch, forgot to push. Just did it now!

I don't know too much about it, but most of that won't be going through Rails or ActionCable. You want to be sending raw data over the wire, so you wouldn't be using WebSockets or Rails for that. WebRTC is designed for this, but Javascript in the browser so it lives outside of Rails / ActionCable.

Really if you want to do live streaming, I'd use a service like https://www.twilio.com/video or https://tokbox.com/ for powering it.

I haven't done this before, so I can't relaly make a good screencast on it for you just yet. At some point I'd like to, but it's a complex topic so it'll probably take a while when I do get around to diving in.

Yeah I think a lot of people do the same thing with Devise, however, it's got a great design so you can dive into the guts of it and make changes really easily. It also doesn't enforce much of anything upon your application, but it's easy to misunderstand that when you're new to the gem.

Hey Mark,

I've personally always found it easiest to just build the Stripe integration myself. I've tried a couple of these gems and often found I was boxed into the way they do things which I could break out of, but at that point I'd basically not be using their gem that much.

You can always try the gems in a sample app and see how the integration goes before you put it in your real project.

Looking forward to hearing about your solution and how it goes once you get it implemented. There really isn't much information on this out there and definitely should be more!

This is a good challenge Justin! I've thought about this in the past but never needed to implement it.

A lot of this probably will come down to your specific use case, but here are some thoughts:

1. You could probably use a mix-and-match approach to use one strategy for say, downloads < 100MB and do like Strategy #1 for that and then if it's > 100MB you could do a different process.
2. I don't feel like it would make sense to automatically create zip files whenever a bunch changes.
3. I know that Dropbox will initialize a download as a background job and email you a link to it when it's finished. This could be a good approach, and you could dynamically spin up an EC2 server to run that download and zip, then kill the server afterwards. This is obviously useful if you're doing larger downloads that might need a large amount of disk space or ram for compressing. You might be able to use AWS Lambda for this instead of a full EC2 server, but it depends on the resources you're allowed in Lambda.

Dropbox takes the background process approach, while Slack takes the approach of no zipping files and just doing one at a time.

It's hard (read: impossible) to come up with a single solution to this without knowing more details like the average file sizes, types and percentages of requests, and things. If people are uploading small documents that's one thing. If they're uploading videos, that's another.

If you don't know the average usage before you get into this, then I would strongly encourage you to take the simplest approach first (rubyzip) and implement that. You could run this all on the webserver at first and then move it to a dedicated server for processing if it starts taxing your webserver. You can measure the free disk space before a job and what you'll need for the zip before executing it. That could tell you to either run it locally or on a dedicated EC2 instance for a few minutes. Once you get a user that's breaking the capabilities of one solution, then you can implement a more complex one and scale that out as you gather more usage measurements.

This will also come down to keeping an idea of what percentage of requests are uploads vs downloads. If you have lots of zip downloads, then re-creating the zip every change might make sense for speed of downloads. If it's mostly uploads and rarely downloads, then you can do that as-needed instead and maybe cache the zip file until a change is made to the bucket.

It'll be super interesting to see, but the nice part is that as long as you store metadata for all the files in your database, you can get a quick detail of the average file size, largest file, and so on to help you analyze which will be the best approach.

Do you have an idea of what usage you're expecting?

[Edit: I accidentally wrote a mini-novel 🤓]

I prefer Administrate personally because it's more or less just regular controllers namespaced to the admin area. No special DSLs or anything, so you can customize it just like you would write your normal app.

Also yeah, noticed those security updates recently as well. 👍

Haha no worries man, it's not a noob mistake, definitely one that I'd be like huh that's weird and have to do some digging to make sure it was all configured right myself. Run into those things all the time.