SC
Да, уже разобрался.
С результ тоже, не получиось return сделать сразу.
С результ тоже, не получиось return сделать сразу.
Size: a a a
2020 July 02
E
у меня еще свежа моя сдача в голове)
А я её читал 2 раза, а на сдачу всё так и не попал.
T
Я имел в виду то, что присвоится не результат, а true как показатель успешного присвоения )
Вроде видел такое где-то, но это не точно.
Про присвоение у нас вроде начал понимать, спасибо.
Вроде видел такое где-то, но это не точно.
Про присвоение у нас вроде начал понимать, спасибо.
А присваивание может быть неуспешным? 😊
А
Когда делаю debug приложения в консоли постоянно циклится (скрин) как можно это скрыть, (Vert.x)
А
или такие, а то они засоряют console ненужной информацией
AF
А присваивание может быть неуспешным? 😊
Не должно... ©
D
загугли свойство, его на время можно отключить
D
но я бы не рекомендовал, эта типо продакшен фича, чтобы о блокировках предупреждать, тут блокировка просто ручная из-за дебага
А
но я бы не рекомендовал, эта типо продакшен фича, чтобы о блокировках предупреждать, тут блокировка просто ручная из-за дебага
засоряет консоль просто, не видно ничего, невозможно воспользоваться прямым исполнением кода (код результата теряется)
D
засоряет консоль просто, не видно ничего, невозможно воспользоваться прямым исполнением кода (код результата теряется)
тогда совет выше
D
проперти есть
GV
Привет,
какие есть best practice по хранению данных basic авторизации для использования в микросервисе?
Микросервис, хостится на heroku, в будущем переедет на свои мощности. Предлагается несколько вариантов:
1. Указывать данные в config vars и вытягивать их в коде через
2. Передавать как параметры (скажем -D) в Procfile. В таком случае у нас файл с данными улетит в гит;
3. Указывать во внешнем файле application.properties, такой подход работает на своих серверах, но не работает(?) в heroku.
Как можно не хранить логин-пароль в открытом виде, но при этом получить переносимое приложение?
какие есть best practice по хранению данных basic авторизации для использования в микросервисе?
Микросервис, хостится на heroku, в будущем переедет на свои мощности. Предлагается несколько вариантов:
1. Указывать данные в config vars и вытягивать их в коде через
System.getEnv() - в таком случае у нас логин пароль по сути хранятся в открытом виде, плюс при self хостинге придется писать это в переменные среды;2. Передавать как параметры (скажем -D) в Procfile. В таком случае у нас файл с данными улетит в гит;
3. Указывать во внешнем файле application.properties, такой подход работает на своих серверах, но не работает(?) в heroku.
Как можно не хранить логин-пароль в открытом виде, но при этом получить переносимое приложение?
DC
Привет,
какие есть best practice по хранению данных basic авторизации для использования в микросервисе?
Микросервис, хостится на heroku, в будущем переедет на свои мощности. Предлагается несколько вариантов:
1. Указывать данные в config vars и вытягивать их в коде через
2. Передавать как параметры (скажем -D) в Procfile. В таком случае у нас файл с данными улетит в гит;
3. Указывать во внешнем файле application.properties, такой подход работает на своих серверах, но не работает(?) в heroku.
Как можно не хранить логин-пароль в открытом виде, но при этом получить переносимое приложение?
какие есть best practice по хранению данных basic авторизации для использования в микросервисе?
Микросервис, хостится на heroku, в будущем переедет на свои мощности. Предлагается несколько вариантов:
1. Указывать данные в config vars и вытягивать их в коде через
System.getEnv() - в таком случае у нас логин пароль по сути хранятся в открытом виде, плюс при self хостинге придется писать это в переменные среды;2. Передавать как параметры (скажем -D) в Procfile. В таком случае у нас файл с данными улетит в гит;
3. Указывать во внешнем файле application.properties, такой подход работает на своих серверах, но не работает(?) в heroku.
Как можно не хранить логин-пароль в открытом виде, но при этом получить переносимое приложение?
1) Прописывать креденшиалс в переменные окружения - нормальная практика
1.1) При этом вообще-то адекватные способы управления конфигурацией позволяют делать так, что приложение не знает, где именно будут эти ключи конфигурации, тот же Спринг вполне умеет искать параметры в разных источниках
1.1) При этом вообще-то адекватные способы управления конфигурацией позволяют делать так, что приложение не знает, где именно будут эти ключи конфигурации, тот же Спринг вполне умеет искать параметры в разных источниках
GV
1) Прописывать креденшиалс в переменные окружения - нормальная практика
1.1) При этом вообще-то адекватные способы управления конфигурацией позволяют делать так, что приложение не знает, где именно будут эти ключи конфигурации, тот же Спринг вполне умеет искать параметры в разных источниках
1.1) При этом вообще-то адекватные способы управления конфигурацией позволяют делать так, что приложение не знает, где именно будут эти ключи конфигурации, тот же Спринг вполне умеет искать параметры в разных источниках
То есть сделать в коде простой if вроде
это здравая идея?
если загрузка property из файла дала null, посмотри в переменных окружения
это здравая идея?
DC
То есть сделать в коде простой if вроде
это здравая идея?
если загрузка property из файла дала null, посмотри в переменных окружения
это здравая идея?
У тебя микросервис на каких библиотеках/фреймворках?
GV
У тебя микросервис на каких библиотеках/фреймворках?
Micronaut
GV
Micronaut
У него есть целых 8 возможных источников конфига
GV
Я думал насчет
@Value("${my.property}")
String token;
и в случае если он даст null, искать уже через System.getEnvGV
Я думал насчет
@Value("${my.property}")
String token;
и в случае если он даст null, искать уже через System.getEnvВ таком случае я без изменения кода смогу в heroku подкладывать через config vars, а на своем сервере через application.properties
P
Я думал насчет
@Value("${my.property}")
String token;
и в случае если он даст null, искать уже через System.getEnvВ micronaut же есть
@ConfigurationProperties, он должен уметь искать параметры из разных источников