Подозреваю, что nginx в связке с next имеет смысл, только если есть что-то ещё кроме next, куда нужно проксировать запросы. Api бэкенд какой-то, к примеру.
Но тем не менее. было любопытно повторить опыт автора.
Я запустил дефолтный проект next.js со стандартной заглушкой next.js в /var/www/nextjs.
И ни один из методов, которые предлагают jetbrains не работает по устранению проблемы. Ни какие танцы с pycharm_helpers не помогают. Вообще-то возникает вопрос, а для чего мне еще + 2 контейнера от pycharm нужны при этой процедуре, если они даже не запускаются при всей этой истории?
Pycharm амбициозная, но очень кривая ide практически во всем, что выходит за рамки «написать код, залить его по ssh».
Больше всего поразило, что файл с переменными .env вообще не существует для Pycharm в рамках совокупления с Docker интерпретатором. Мне пришлось их писать руками в Pycharm в настройках. Это не похоже даже близко на что-то удобное в принципе. Так и в чем разница, если с тем же подходом обычный source venv, как минимум, работает, а как максимум по количеству действий требует сильно меньше, чем совокупление pycharm с Docker (которое не работает)?
В Pycharm на столько кривая реализация удалённого интерпретатора, что количество жалоб на сайте jetbrains сравнимо с микроддос атакой. Да чего уж далеко ходить - сам буквально вчера в этом убедился. Вы тоже попробуйте, потому что складывается ощущение, что вы просто знаете что так можно делать, но не делали. В итоге все сводится к тому, что на локальной тачке после пары часов мучений с «возможностями» pycharm ты все равно создаешь venv и работаешь там.
Первое, что пришло в голову, читая статью - почему Хабр не впилит автозамену %username% на никнейм из профиля читающего. Вроде в Editor.js не очень сложно вкостылить, а эффект прикольный будет.
Второе, что пришло в голову - Хабр потихоньку становится амбассадором Delphi?
Подозреваю, что nginx в связке с next имеет смысл, только если есть что-то ещё кроме next, куда нужно проксировать запросы. Api бэкенд какой-то, к примеру.
Но тем не менее. было любопытно повторить опыт автора.
Я запустил дефолтный проект next.js со стандартной заглушкой next.js в /var/www/nextjs.
Сделал Ctrl+C Ctrl+V для конфига nginx.
В результате 403.
Разбираться смысла не вижу, статья сомнительная.
Какие версии у вас используются и каким чудом удалось в принципе поднять удаленный интерпретатор в pycharm?
Проблема на которой лично я решил прекратить поднимается здесь: https://youtrack.jetbrains.com/issue/PY-61111
И ни один из методов, которые предлагают jetbrains не работает по устранению проблемы. Ни какие танцы с pycharm_helpers не помогают. Вообще-то возникает вопрос, а для чего мне еще + 2 контейнера от pycharm нужны при этой процедуре, если они даже не запускаются при всей этой истории?
Pycharm амбициозная, но очень кривая ide практически во всем, что выходит за рамки «написать код, залить его по ssh».
Больше всего поразило, что файл с переменными .env вообще не существует для Pycharm в рамках совокупления с Docker интерпретатором. Мне пришлось их писать руками в Pycharm в настройках. Это не похоже даже близко на что-то удобное в принципе. Так и в чем разница, если с тем же подходом обычный source venv, как минимум, работает, а как максимум по количеству действий требует сильно меньше, чем совокупление pycharm с Docker (которое не работает)?
Не на практике.
В Pycharm на столько кривая реализация удалённого интерпретатора, что количество жалоб на сайте jetbrains сравнимо с микроддос атакой. Да чего уж далеко ходить - сам буквально вчера в этом убедился. Вы тоже попробуйте, потому что складывается ощущение, что вы просто знаете что так можно делать, но не делали. В итоге все сводится к тому, что на локальной тачке после пары часов мучений с «возможностями» pycharm ты все равно создаешь venv и работаешь там.
Первое, что пришло в голову, читая статью - почему Хабр не впилит автозамену %username% на никнейм из профиля читающего. Вроде в Editor.js не очень сложно вкостылить, а эффект прикольный будет.
Второе, что пришло в голову - Хабр потихоньку становится амбассадором Delphi?