kobaltzPRO

Joined 7/18/2015
kobaltz PRO said about 1 month ago:

When you ssh into the EC2 instance, try doing this to get the database created.

sudo su
bundle exec rails db:create
exit

I believe they've changed the permissions of the ec2 user and you cannot login as the www user.

0xk175un3 said about 1 month ago:

Yeap, this work, thx a lot!

kobaltz PRO said about 1 month ago:

I think that it depends on the goals of the service object. If it were only internal interactions then this would make sense. However, if the issue was an error with an external api that you've wrapped your service object around, I would probably prefer this method.

kobaltz PRO said 30 days ago:

That is indeed very strange! I just reprovisioned my development environment this morning and tested this with the latest Rails and devise. It is happening to me too! I'm guessing that when the generator is being ran, it is injecting the RAILS_ENV as an attribute and devise is picking it up somehow... Really weird!

kobaltz PRO said 30 days ago:

Using this works without adding in the weird ENV

gem 'devise'
run 'bundle install'

generate(:scaffold, 'user', 'name')
generate('devise:install')
generate('devise','User')

kobaltz PRO said 30 days ago:

I've entered an issue on Github regarding this issue. It is definitely unexpected behavior. However, I don't know how critical it is since there is a workaround.

https://github.com/plataformatec/devise/issues/4992

Simon Kiteley PRO said 27 days ago:

Thank you for that. The workaround should be fine for my purposes.

kobaltz PRO said 23 days ago:

Try rebooting. also you can tail -f ~/Library/Log/puma-dev.log to see what the bootup errors are

Navid Shafie said 23 days ago:

Thanks for your reply @kolbaltz, first in the app directory I ran rm ~/.puma-dev/"$(basename pwd)" to remove it from puma-dev, so when I go to ~/.puma-dev I can't see any folders and then I ran pkill -USR1 puma-dev to kill everything and than I ran pumad to start it again, but same issue.

Not sure what I did wrong at this point :/

Btw when I run which puma-dev I get this: /usr/local/bin/puma-dev

Im in rails 5.1

full message when I ran pumad:
* Use '/usr/local/Cellar/puma-dev/0.12/bin/puma-dev' as the location of puma-dev
* Installed puma-dev on ports: http 80, https 443
Your app should be available at http://appname.test and https://appname.test now!

Navid Shafie said 23 days ago:

I ran tail -f ~/library/Logs/puma-dev.log and this is the output:
* HTTPS Server port: inherited from launchd
! Puma dev listening on http and https
and bunch of
2018/12/28 20:25:21 Error listening: accept tcp 0.0.0.0:0: accept: invalid argument
* Directory for apps: /Users/UserName/.puma-dev
* Domains: test
* DNS Server port: 9253
* HTTP Server port: inherited from launchd
* HTTPS Server port: inherited from launchd
! Puma dev listening on http and https
2018/12/28 20:25:31 Error listening: accept tcp 0.0.0.0:0: accept: invalid argument

kobaltz PRO said 14 days ago:

Inspect your browser dev tools to see if there are any errors in loading the assets. It could be CORS policy blocking the assets.

Jayzen PRO said 14 days ago:

i find the problem, the chrome plugin adblock blocked it

kobaltz PRO said 14 days ago:

This is usually something with the browser that is blocking the asset. It could be a browser extension or something.

Jayzen PRO said 14 days ago:

thansk~

kobaltz PRO said 13 days ago:

The upgrade from 5.2.0 to 5.2.2 is fairly safe. There wasn't much changes. Have you looked at this episode yet https://www.driftingruby.com/episodes/upgrading-ruby-on-rails-versions?

Antonio F. PRO said 9 days ago:

Hello,

yes thanks I had solved .. However, for production environments (already online) I can follow the same strategy?

kobaltz PRO said 9 days ago:

Yes. You would upgrade the application locally and test everything to ensure that it is working properly. If you have a staging environment, it would then be best to test within there to make sure that you're not breaking functionality. This step is really important because we sometimes have services that are not "available" during development. For example, if you do file uploads to S3 in production, but in development, you use local disk, then all of your local development tests will not be touching the S3 APIs or code. This would be considered a risk when going to production, but a staging environment may catch any potential issues.
This is partly why I always try to mimic my production environment as closely as possible when developing. So in the previous example with S3 file uploads, I would use minio locally to mimic the S3 APIs for file uploads. It makes the development environment a bit more complicated, but would expose any potential breaking changes earlier on in the upgrade process.

Antonio F. PRO said 9 days ago:

Thanks :-)

kobaltz PRO said 9 days ago:

Yes. You would upgrade the application locally and test everything to ensure that it is working properly. If you have a staging environment, it would then be best to test within there to make sure that you're not breaking functionality. This step is really important because we sometimes have services that are not "available" during development. For example, if you do file uploads to S3 in production, but in development, you use local disk, then all of your local development tests will not be touching the S3 APIs or code. This would be considered a risk when going to production, but a staging environment may catch any potential issues.
This is partly why I always try to mimic my production environment as closely as possible when developing. So in the previous example with S3 file uploads, I would use minio locally to mimic the S3 APIs for file uploads. It makes the development environment a bit more complicated, but would expose any potential breaking changes earlier on in the upgrade process.

Antonio F. PRO said 9 days ago:

Thanks :-)