kobaltzPRO

Joined 7/18/2015
kobaltz PRO said 3 months ago:

I don't yet, I plan to add one and work on this one more. I used Summernote for a while, but I didn't like having to deal with parsing HTML in some scenarios. This seemed like a much better option since most developers are familiar with Markdown. This library is called SimpleMDE (https://simplemde.com/). I'll probably cover an episode on it soon with integrating with ActiveStorage or something similar.

kobaltz PRO said 2 months ago:

Yea. It is definitely much cooler on projects that have a bunch of contributors. Running it on the Ruby or Rails repo is pretty amazing.

kobaltz PRO said 2 months ago:

Would an episode on combining and building on Elasticsearch and Searchkick do what you're looking for? Personally, I like having more control over my services if possible. Especially if you're hosting with someone like AWS where there are hosted instances of Elasticsearch. I did an [episode]https://www.driftingruby.com/episodes/searchkick-and-elasticsearch) a while back, but can see the added benefit of building in the overall search functionality with multiple models.

kobaltz PRO said 2 months ago:

I believe that this is caused by the url_for which creates the presigned_key URL and has a 5 minute default expiration. You could instead of the JSON response of the direct URL, you send the response back which goes to the SHOW action of the ArticleImage. The show action will get the record and redirect to the S3 link from the url_for. This could have the added benefit of checking authorization/authentication of the image about to be displayed to a user. This would also solve the expiration time as it would generate a new link. You could also wrap the url_for with a Rails.cache.fetch and set the expiration to 5 minutes to prevent the overhead of having to get another signed url for every request of the same image within the given interval.

Simon Kiteley PRO said 2 months ago:

Brilliant, thanks for that. Not sure about a couple of the steps you mention but sure a google search will provide lol.

kobaltz PRO said 2 months ago:

I'm interested in this as well. I'll do some research and will probably write up a blog article about it. If I had to guess, it will be removing the default image button and making a custom button which mimics the Drag/Drop functionality.

kobaltz PRO said about 1 month ago:

I haven't tried adding it to an "older" version of rails. It does seem to be fairly decoupled from Rails as its own gem.
Though, one weird thing that they do which is a little strange that could prevent this from easily working is in the ActiveStorage gemspec.

  s.add_dependency "actionpack", version
  s.add_dependency "activerecord", version

It has this reference to version which is in the main branch's RAILS_VERSION file. If you reference a 5.1.6 tag, the ActiveStorage gem wouldn't exist. You may need to clone the repo and manually adjust it. This would inherently add a level of technical debt as you would have to migrate any bugfixes/security patches/enhancements to your branch.

marklar PRO said about 1 month ago:

Yikes, it sounds like it's not the best idea for a simple plug and play solution with 5.1.6 then.

Thanks for taking the time to reply and thanks for the great video.

kobaltz PRO said about 1 month ago:

You're best bet would be to upgrade to Rails 5.1.X if possible and use the encrypted secrets. It will at least get the code base up to a point where swapping out the encrypted secrets for credentials an easier task.

sekmo said about 1 month ago:

Thanks! But what can I do if at the moment I have to keep the 5.0.x version?

kobaltz PRO said about 1 month ago:

I'd say it would depend on how you're deploying to the production environment.

Basically, you can use your secrets.yml file to store all of the keys and values. Within each of the values, reference an environment variable. So, within the file, you may have something like this:

production:
  database_password: <%= ENV['DATABASE_PASSWORD'] %> 

At least, in this way, you're not storing sensitive information in the codebase. From here, you can set your Environment Variables how you see fit. On a production deployment, it could be through ansible/chef/capistrano that is setting the ENV Vars or something similar.

kobaltz PRO said about 1 month ago:

I'd say it would depend on how you're deploying to the production environment.

Basically, you can use your secrets.yml file to store all of the keys and values. Within each of the values, reference an environment variable. So, within the file, you may have something like this:

production:
  database_password: <%= ENV['DATABASE_PASSWORD'] %> 

At least, in this way, you're not storing sensitive information in the codebase. From here, you can set your Environment Variables how you see fit. On a production deployment, it could be through ansible/chef/capistrano that is setting the ENV Vars or something similar.

kobaltz PRO said about 1 month ago:

Have a look at this forum https://forums.mysql.com/read.php?73,170617,185695

kobaltz PRO said about 1 month ago:

It is just a different way to parse the JSON. If you wanted to reference the object, you could do it with something like version.object['first_name'] but I think that something like version.changed_object.first_name appears nicer. It is really just a preference.