2) если мне память не изменяет (год назад пробовал изучать эту тему) есть отдельные библиотеки для валидации, соответственно, инструкции (что и как валидировать для конкретных полей) пишутся в прото файле - для каждого поля м.б. своя проверка, в том числе и кастомная (дописанная прямо в прото) на базе функционала библиотеки для валидации.. однако, прото - это условно только API часть, чтобы инструкции для валидации выполнялись, в клиентской части также должна быть зависимость от библиотеки валидации, и плюс, нужны интерсепторы (например для исходящего и входящего сообщения), которые эту валидацию выполняют и кидают ошибки - вот тут есть мина, потому что просто добавленный интерсептор валидации, что кидает ошибку этого мало, потому это если сервер кинет ошибку на валидации, то клиент ее не получит, а получит какую-то общуб ошибку на стороне сервера, чтобы это правильно работало нужно также добавлять обработку, чтобы ошибка интерсептора правильно оборачивалась и траслировалась в общем процессе (запрос-ответ).. возможно, спринг эти вопросы и порешал (я про добавление интесептора и правильную обработку ошибок)..
Поэтому напомним, что есть хорошая новость! Вместе с партнерами мы уже работаем над созданием OpenIDE — открытой отечественной средой разработки, которая останется доступной, совместимой с экосистемой JetBrains и свободной от ограничений. Публичный релиз ожидается совсем скоро.
это раздражает.. зачем об этом постоянно писать, когда скачать и попробовать нельзя, да еще со ссылками.. к тому времени пока этот и гига-проект выйдут на рынок, они будут, вероятно, не актуальны
Он привносит ненужные ограничения в ситуациях, где единственный экземпляр класса на самом деле не требуется, а также вводит в приложение глобальное состояние.
после этой фразы можно дальше не читать
наверное, вы просто не знаете чего хотите или рандомно решаете, что будет синглтоном, а что нет..
Давайте сразу договоримся, что как бы нам не было противно текущее состояние нейминга грейдов специалистов и дико размытая грань мидлов и сеньоров от компании к компании, выбора у нас с вами не особо много, так как это неотъемлемая часть рынка.
ничего противного в нейминге грейдов нет, он просто создает неопределенность для неофитов, из чего следует простая идея: то, что не несет пользы, не стоит внимания (мысль Поломодова близка этому).. сам факт наличия грейдов это обычная стереотипизация принятая в современном социуме, и тот, кто создает эти ярлыки, преследует свои собственные цели..
выбор всегда есть, и то, что предлагает рынок, это может быть далеко не то, что вам нужно.. хотите ли вы быть мифическим сеньором или хотите чего-то более осязаемого:
зарабатывать Х денег
работать в интересной для вас индустрии
решать определенные задачи
быть сопричастным к определенному сообществу (идейному, профессиональному, культурному, технологическому)
или все это вместе взятому или в любых сочетаниях
или что вы там сами себе желаете обрести на этом пути.
как следствие нужно опираться от собственных потребностей и искать им соответствие не в названиях работ, а в его содержании
просто вышенаписанное читается как рядовая деятельность, и отсюда хочется спросить, а какие временные рамки опыт для вышеозначенного, так скажем уровня работника ?
джунов в команде к этому нужно приучать сразу, передавать им опыт и привлекать их к процессу
Участие в обсуждениях архитектуры и/или процессов.
ну, да, джун уже познал дзен и это для него пройденный этап, поэтому порассуждать про архитектуру для него это как чаю попить..
лично у меня некоторый диссонанс будто, если сдвинуть описания-лычки на одну позицию вправо, то будет больше похоже на правду (trainee это junior, junior это middle, etc)
выглядит противоестественно, потому что если строго следовать этому D, то необходимо заставить всех разработчиков библиотек, что используются в проекте отнаследоваться от вашего интерфейса, чтобы можно было использовать эти самые библиотеки
Тут я хочу тогда спросить, а какую проблему решаем?
вот в чем вопрос..
автор предложил свое, как он видит более глубокое понимание D проблемы и да, как следствие его размышлений - лечим одно, калечим другое, если допустить, что он правильно понимает проблему, тогда способ ее решения не годен, потому что.. понятно почему
Интерфейс это или класс или что-то еще — неважно, главное чтобы соблюдалось основное условие — МВУ должен зависеть сам от себя.
у меня топографический критинизм и хотелось бы пояснений..
на правильной (как я понял, может это и не так) картинке изображено, что А и интерфейс, который они инжектит в себя являются одним модулем - они изображены оба в одном пунктирном прямоугольнике.. соответственно, В находится в другом модуле, все правильно ?
если все так, то выглядит вроде красиво по отношению к тому, что названо МВУ..
однако, меня сильно смущает, что теперь модуль, в котором находится В не может существовать без модуля, где поселился А и интерфейс, по той простой причине, что В должен реализовывать этот самый интерфейс ?!
а в чем компактность - сеттер против конструктора ?!
2) если мне память не изменяет (год назад пробовал изучать эту тему) есть отдельные библиотеки для валидации, соответственно, инструкции (что и как валидировать для конкретных полей) пишутся в прото файле - для каждого поля м.б. своя проверка, в том числе и кастомная (дописанная прямо в прото) на базе функционала библиотеки для валидации.. однако, прото - это условно только API часть, чтобы инструкции для валидации выполнялись, в клиентской части также должна быть зависимость от библиотеки валидации, и плюс, нужны интерсепторы (например для исходящего и входящего сообщения), которые эту валидацию выполняют и кидают ошибки - вот тут есть мина, потому что просто добавленный интерсептор валидации, что кидает ошибку этого мало, потому это если сервер кинет ошибку на валидации, то клиент ее не получит, а получит какую-то общуб ошибку на стороне сервера, чтобы это правильно работало нужно также добавлять обработку, чтобы ошибка интерсептора правильно оборачивалась и траслировалась в общем процессе (запрос-ответ).. возможно, спринг эти вопросы и порешал (я про добавление интесептора и правильную обработку ошибок)..
хорошая статья, но возникает вопрос:
- а, кто ? кто директор-то?
это раздражает.. зачем об этом постоянно писать, когда скачать и попробовать нельзя, да еще со ссылками.. к тому времени пока этот и гига-проект выйдут на рынок, они будут, вероятно, не актуальны
ровно как и в примере выше, метод может вернуть (Optional)null
класс с @SpringBootApplication это как-то через чур..
можно в тесте создать класс с @TestConfiguration и @SpringBootConfiguration (она и будет стоппером) и накофигурировать что тесту потребно
после этой фразы можно дальше не читатьнаверное, вы просто не знаете чего хотите или рандомно решаете, что будет синглтоном, а что нет..
"запарить рака", чтобы что не значило
ничего противного в нейминге грейдов нет, он просто создает неопределенность для неофитов, из чего следует простая идея: то, что не несет пользы, не стоит внимания (мысль Поломодова близка этому).. сам факт наличия грейдов это обычная стереотипизация принятая в современном социуме, и тот, кто создает эти ярлыки, преследует свои собственные цели..
выбор всегда есть, и то, что предлагает рынок, это может быть далеко не то, что вам нужно.. хотите ли вы быть мифическим сеньором или хотите чего-то более осязаемого:
зарабатывать Х денег
работать в интересной для вас индустрии
решать определенные задачи
быть сопричастным к определенному сообществу (идейному, профессиональному, культурному, технологическому)
или все это вместе взятому или в любых сочетаниях
или что вы там сами себе желаете обрести на этом пути.
как следствие нужно опираться от собственных потребностей и искать им соответствие не в названиях работ, а в его содержании
просто вышенаписанное читается как рядовая деятельность, и отсюда хочется спросить, а какие временные рамки опыт для вышеозначенного, так скажем уровня работника ?
с этим невозможно не согласиться
ну, да, джун уже познал дзен и это для него пройденный этап, поэтому порассуждать про архитектуру для него это как чаю попить..
лично у меня некоторый диссонанс будто, если сдвинуть описания-лычки на одну позицию вправо, то будет больше похоже на правду (trainee это junior, junior это middle, etc)
вы о чем вообще ?
какой еще джоб-хоппинг у джунов, они и на работу-то устроиться не могут, потому что практически нигде не нужны
выглядит противоестественно, потому что если строго следовать этому D, то необходимо заставить всех разработчиков библиотек, что используются в проекте отнаследоваться от вашего интерфейса, чтобы можно было использовать эти самые библиотеки
это не правда, всего пару дней назад второй аккаунт делал
вот в чем вопрос..
автор предложил свое, как он видит более глубокое понимание D проблемы и да, как следствие его размышлений - лечим одно, калечим другое, если допустить, что он правильно понимает проблему, тогда способ ее решения не годен, потому что.. понятно почему
у меня топографический критинизм и хотелось бы пояснений..
на правильной (как я понял, может это и не так) картинке изображено, что А и интерфейс, который они инжектит в себя являются одним модулем - они изображены оба в одном пунктирном прямоугольнике.. соответственно, В находится в другом модуле, все правильно ?
если все так, то выглядит вроде красиво по отношению к тому, что названо МВУ..
однако, меня сильно смущает, что теперь модуль, в котором находится В не может существовать без модуля, где поселился А и интерфейс, по той простой причине, что В должен реализовывать этот самый интерфейс ?!
есть такое
да, отлично работает, хабр открывается, а залогиниться не даёт, про остальные сайты вообще молчу..
кстати вчера вечером картинки на хабре грузились.. гм, было чувство, что вернулся в прошлое.. диалап 2.4Кб скорость, точно также было
спасибо, Филипп, тут уже есть над чем подумать
абсолютно бесполезный комментарий, который выглядит как, - вот вам мое, фи, тут все неправильно !
собственно, где в нем вопросы и подсвеченные проблемы для того, чтобы улучшить ?