Chris Oliver

Watch the next episode in the series: https://gorails.com/episode...

Probably doing something like these solutions would work: https://stackoverflow.com/q...

Hey Travis,

In this situation, I'd connect to the server and pull down a copy of the code that's currently running as soon as possible. Create a new git repo and add all the code there so you've got it safely stored away on Github, etc.

You'll probably also want to make a copy of the production database and save it locally. If you import it to your local database, you'll have a copy of production data that you can use to get up and running probably a bit quicker. Just keep in mind that you'll want to make sure you don't email or charge customers from your local copy, so it would probably be good to sanitize emails and other information.

I would probably then try to setup an actual deployment process, either using something like Hatch, Heroku, or a tool like Capistrano to make sure you can deploy it safely to a separate server or something. That way you can verify that deployments work without affecting the production app.

At that point, you can try doing a deployment over the existing codebase or you may want to deploy to a new directory and point the webserver to the new directory on the same server.

So in general:

1. Create a git repo with all the code
2. Backup the database
3. Setup deployments the way you'd want it going forward
4. Do a test deployment (include a small change so you can see if it worked)
5. Verify that code is running correctly on the server (run it on a different port)
6. Swap the production webserver to the new deployment

I might be forgetting some things, so anyone else with ideas, please jump in. 👍

I don't think so, just use the administrate generator to create the administrate files. You don't need to create any folders yourself.

Yeah you should never edit a gem's source code. Install the administrate assets into your app using the generator and edit those to include trix.

1. The admin compiles separate css and JS files. Your regular users will never have access to the admin, so it doesn't make sense to give them all your admin css and js.

2. They will be compiled automatically. Administrate already configures your app to have separate admin js and css files that are compiled via the normal asset pipeline. The asset pipeline can compile more than one file as output, but we don't generally do that so the user only has to download a minimal set of files. We only do here because sending those regular users the admin style and functionality doesn't make sense.

Use the Heroku Scheduler.

Should work for that too, since the JS is agnostic to any backend storage you might want to use. Direct uploads to S3 etc will work as well.

Really really easy. You need to add the JS and CSS to administrate's versions. Then you can create a custom field. I made one called FormattedText and just added the editor to the form.html.erb view for the field.

<div class="field-unitlabel">
  <%= f.label field.attribute %>
</div>
<div class="field-unit_field">
  <%= f.hidden_field field.attribute, id: field.attribute %>
  <trix-editor input="&lt;%= field.attribute %&gt;"></trix-editor>
</div>

Yep, just swap out the Shrine code on the Photos model and you're set.

Cron jobs are good for multi-server setups too. Just have one server run cron jobs and your background jobs. They'll all share the same database anyways so there's nothing server-specific.

The downside of scheduling jobs is that they're very hard to cancel and manage if you need to ever do that. I find that generally outweighs a nightly cron by a lot and almost never go with the jobs route for a situation like this.

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.