Chris Oliver

I'm not sure how most of them work, but generally you can just keep the data in Javascript and then submit it over to the server as JSON data when you want to save it. That way you're not dealing with hidden form fields all over the place which would get complicated fast.

The drag and drop portion could be done with any Javascript library for it. You'd probably be best off using something like Vue.js or React for this these days because it clean up a lot of the complexity there. jQuery also works really well, but it tends to lead to some spaghetti code if you don't organize it well.

While this isn't exactly the same, I'm going to be doing a series building a clone of Trello starting in a week or two which will be kind of similar.

Hey Stephen,

Since you'll be storing the expiration date on a Document model (along with the reference to the file), you can always verify the document hasn't expired before linking to the file and you can use that same attribute to send the emails.

I would use a Date column to store the expiration.

In this situation, what's easiest is to write two scopes, one for the month, one for the week reminder.

scope :expires_in_one_month, ->{ where(expires_at: 1.month.from_now.to_date) }
scope :expires_in_one_week, ->{ where(expires_at: 1.week.from_now.to_date) }

Now you have two queries that let you find documents that expire in a month and a week.

You can build a cron job that runs once per day and grabs all the documents for each of those expirations and emails the users.

def email_reminders
  Document.expires_in_one_month.each do |document|
      UserMailer.upload_new_reminder(document)
    end

    Document.expires_in_one_week.each do |document|
      UserMailer.upload_new_reminder(document)
    end
end

At a high level, that's all there is to it. I'm sure there will be plenty of smaller details you'll need to implement, but this should get you started.

Hey Ryan,

What you want is to simply define a div with the id of map on the show page and have the markers array be just the item on the page (instead of all the ones on the index). The Javascript is available on every page so you're free to add a map to other pages and it will automatically work!

This is the benefit of writing javascript that's generic to pages. A lot of people want "page-specific" javascript but that's almost always a bad idea. You can always use a unique identifier for your JS to pickup and make your life a lot easier in the long run.

So Redis is an in-memory database. Sidekiq simply uses it as a store of the jobs that need to be run or are running. That information is actually quite minimal because it's really just the name of the class (the Job) to run and the arguments for it (which are just IDs of database records generally). You probably won't have hardly any space used with it, unless you're processing hundreds of thousands of jobs.

ElastiCache is basically a dedicated server just for this service. You can do the same thing by running Redis on a separate machine, but you'll want to setup firewall rules and things for that. EC does that for you basically.

You might want to run this on a separate server if you have a bunch of servers starting jobs. They can all talk to the same Redis instance just like you would have a central database for a bunch of webservers.

Hatch starts you out on the simplest path: Redis on the same machine. Once you grow out of it you can pretty easily migrate to a store on another server.

Hey Ryan,

These are great questions, and everyone's probably going to give a slightly different answer.

Rails really has tried to avoid answering that question. Basecamp (who created Rails) doesn't use a framework, and doesn't generally build anything super Javascript heavy, so they just write plain Javascript.

I've really enjoyed using Vue.js myself and know that the Laravel community has too. I've done several videos on this which you can see here: https://gorails.com/series/using-vuejs-with-rails (there might be some others not in this series).

I generally try to work without a framework if my application is simple. GoRails, for example, doesn't have much Javascript at all and therefore I'd rather just write plain JS. For something more complex that might use websockets or be much more interactive (like Trello for example) then a JS framework really starts to make sense.

A new series I'm starting shortly is going to be building a Trello clone with Vue.js which might answer some of these questions for you too. That should begin in the next week or two.

Not at the moment, but that's as simple as adding a couple lines of code to your JS. Check out the route examples: https://hpneo.github.io/gma...

I mentioned the geocoder gem comes with some calculations methods. One of those is for distance between two points. You can use that, just check the readme.

According to this (https://github.com/rails/ruby-coffee-script) it looks like the coffee-script-source gem would need to get updated to the latest version to use the standard coffee-rails gem that we're used to.

https://github.com/rails/coffee-rails

Making updates to those gems would probably be the best way to do things since it would work exactly as we've used Coffeescript in the past with Rails.

Hey Sai,

Your browser has a maximum size of storage for cookies, so Rails protects you from sending too much data to the browser.

You should probably look at what you're storing in the cookies and change it to save to the database and store the database record ID in the cookie instead.

Before the screencast, I setup a Rails app with my template and added a Transaction model ahead of time so I could focus on the geocoding parts I believe.

You can check out the commits in the repo to see how I set that up: https://github.com/gorails-...

And sometime soon, I will probably be releasing that Rails template that I've been using to start new apps!

Yeah! Popper is nice to have instead. Screencast was using an old version of my Rails template which has been updated already, just hadn't done a git pull recently on that machine. Should update that in the repo.

Yeah, it's encouraged for production, because production will boot faster. The extra RAM usage is going to come from the cache it because that's how it boots faster. It's trading RAM for speed.

Certain memory constrained environments, like Heroku typically is, may not be a great place to do this if you're struggling to keep your app's memory usage down. Otherwise, you should basically use this all the time.

All the routes are handled by Rails in these videos. Vue is just pointing to the Rails routes to submit things to the server.

Not as difficult as you might think. The HTML5 geocoding API will get you an IP address quickly, so you can send that over as a different param and pass that into the .near() method. This will be a great screencast. :D

Just an FYI, you don't have the use the Heroku addon. You can go straight to bugsnag and set it up yourself if you want. The addons are just there to make it slightly easier to setup.

Sure can, do you have any topics you're curious about?

I don't think that gzip has anything to do with it since it's all controlled by Amazon.

Are you able to paste that Javascript into another site somewhere and see if it runs? I tried to inject the snippet on to a page and didn't see anything at all show up. I'm wondering if it's something to do with your Amazon snippet.

I covered how you can do this with the Apartment gem as well as from scratch in these episodes: https://gorails.com/series/multitenancy-crash-course

Another tip: You can also run an errbit server which is an open source version of Airbrake and use the airbrake gem to talk to it which is kind of nifty.

I wonder if that got triggered along with the JS for Stripe. May need to update my screencasts to mention that if I didn't cover that properly.

Can't we just have nice things that work out of the box?? 😜