Chris Oliver

That's up to you I'm pretty sure. They do allow you to configure their emails for various things like failed payments though. You can find all those email options in the Settings tab on Stripe.

Yep, and I don't know that you necessarily need the currently working boolean in the database. You can just add some methods in your model to delegate to the end_date column.

class Job
  def currently_working?
      !end_date?
    end
end

Then you can just use that method to set the checked attribute on the checkbox by default when editing.

Hey Gerard,

I would probably use Javascript to do two things when checked:

1. Hide/show the end date field
2. Clear the value for the date fields

Flatpickr write the selected value to a form field, so it can be submitted to the server. That's the field you'll want to clear out in the JS.

Then just make sure your end date field is marked as optional in your database so it can be null.

Hey Olivia! You might be able to add this to the User model so that they're always marked as "remember me" to extend the logins for as long as possible.

class User
  def remember_me
    true
  end
end

You can also configure Devise to have a longer cookie expiration which may help.

I'm actually going to be doing sort and search/filter for some Jumpstart Pro upgrades to the base scaffolds soon, so I'll probably dig into this in a related way, just maybe not with ElasticSearch as the backend specifically. May do pg_search instead.

Thanks for the info on webcam uploads Max!

I also just finished recording a screencast on using Uppy with ActiveStorage, so that episode should go live in the next week or so.

Looks like this: https://github.com/ankane/searchkick/issues/793

I don't think that's right. We're using fixtures in this episode in our system tests. We're signing in as fixture users and visiting project fixtures for example.

Hey Nelson,

The name of the model helps make routing way easier, so that's why it's done that way. Here's an example of why.

You might have a /sign_up route, but if you weren't careful, "sign_up" can easily get treated as a topic, which you don't want.

To do this, you'll just write your own custom routes.

get "/sign_up"

get "/:topic/:forum/:post"
get "/:topic/:forum"
get "/:topic"

This way, sign up should get interpreted first, instead of it being treated as a topic. And the rest of the routes are catch-alls to treat everything else as if it were a topic and so on. Those routes have to be the last in your routes file in order to not override the other routes.

Have any of you guys checked out this repo? https://github.com/Sology/uppy-activestorage-upload

Hey Martin!

I wish I could, but it's a lot of work to maintain and I spent like 9 months building it, so I'm not able to offer any discounts. It's already probably cheaper than what I should be charging for it, so in the future I may raise the price a bit. I just want to make it as accessible to everyone as I can, but without burning myself out working on it.

Thank you for the heads up that it wasn't working! I appreciate you!

Also should mention, I found that information here: https://www.elastic.co/guide/en/elasticsearch/reference/7.3/bootstrap-checks.html#_forcing_the_bootstrap_checks

Alex, you were onto something with the cluster_uuid. I found out that you can find more information by running curl http://localhost:9200/_cluster/health instead.

That pointed out "master_not_discovered_exception" so it's a configuration issue that the ES server is not seeing itself as a master in the cluster.

Looks like production mode expects multiple servers now, but we can get around that by adding discovery.type: single-node and that should fix it. I'll go update the Hatchbox configs for that.

ElasticSearch is really picky about RAM I've noticed. If it doesn't have enough it can fail to start and it needs 4GB RAM to itself minimum. A 4GB of RAM server won't suffice for it, so you've got to go with 8GB if you also want to run Rails on the same server, and even then you have to keep an eye on it.

This is where a managed ElasticSearch is definitely worth the money. You have to worry about none of these details and can just use it. 👍

Hey Alex,

Good catch on the cluster_uuid. That does seem strange and maybe a recent version of ElasticSearch has broken my config changes. I'll do some research and see what I find.

Getting a response from ElasticSearch fooled me into thinking that everything was running just fine but maybe it gives a Service Unavailable error if it is running but doesn't have a cluster active / connected or something. I'm not super familiar with ES and it seems to have changed a bit recently.

Hey Alex,

Not sure it's related to this specific thing, but Jumpstart Pro uses PurgeCSS in production and staging to strip out any unused CSS to make the files as fast as possible. If you didn't have the class referenced in the locations it looks, it can strip out the class on accident when compiling.

You can tweak the whitelist for that in postcss.config.js in the repo and add your own classes to the whitelists so they don't get ignored. It also supports regex so you can use that to whitelist a set of classes too.

That'd be a good question for Janko on the Shrine GitHub. I think that should be doable, but he would know how to do that best.

I believe you would just create the S3 storage instance each time you upload, rather than once in the initializer.

s3 = Shrine::Storage::S3.new(
  bucket: "my-app", # required
  region: "eu-west-1", # required
  access_key_id: "abc",
  secret_access_key: "xyz",
)

The above you would configure with the tenant's credentials and then you can probably call the upload method directly on this. He'll know best though!

If you're using Searchkick, try adding this:

Searchkick.client.transport.logger = Logger.new(STDOUT) # or Rails.logger

Found that after a quick search on the issues.

Sounds like the same thing as before. Have you gotten any logging enabled to see what URL it's requesting yet?