Ну, и как волшебным образом "смежная команда" может оценить сотрудников соседей, если они не погружены и не вовлечены в то, кто что делает у этих самых соседей? Отдельные команды - отдельное планирование.
А откуда возьмутся эти "большие числа"? Команда редко больше 12-15 человек, а кто тебя еще знает достаточно хорошо, чтобы определить твою компетентность? В соседних отделах как ни крути, а знать тебя будут довольно однобоко, и что бы такой "360" сделать адекватным и информативным в него придется ввалить столько усилий, что мама не горюй.
Внедрить 360-фидбэк. Мнение команды о человеке часто бывает куда более объективнее, чем мнение сторонних менеджеров, зажатых в тисках квот.
Интересно, в каком мире живет тот, кто это написал? Потому что в реальном мире все эти "360" не имеют с реальностью ничего общего. Что меня, как сотрудника, должно мотивировать объективно оценивать коллегу? Да ничего, нет такой мотивации. А вот мотивов оценить его НЕ объективно полным-полно. Мы с ним друзья-кореша? Везде высший балл! Мы с ним не в ладах? На тебе низкие оценки. все эти "360" это просто попытка переложить ответственность с больной головы на здоровую - это не мы тебе низкие оценки дали, а твои же коллеги, разбирайся с ними. Конечно разберусь - вот будет очередной "360" и я им покажу!
Пожалуй, одно из самых заметных изменений для каждого разработчика
Вы издеваетесь? Каждому разработчику давно плевать где там в коде public static void main(String[] args) - это одна единственная строка, которая генерируется за разработчика, и видит он ее примерно никогда. Изменение, ё-мое...
Краткое содержание: если слышишь "мы семья - значит тебя пытаются нае... обмануть с целью извлечения из тебя максимальной выгоды. Всегда помни, что ты за деньги продаешь 8 часов своей жизни из 5 дней в неделю, и на этом все.
А кто говорил о проблеме? Никакой проблемы нет, есть свершившийся факт - jpa прячет от разработчика sql. Идите и перечитайте первое мое сообщение, там именно об этом. Если для вас не проблема, что между вами и БД появляется прослойка, которая прячет от вас конечный запрос, который будет выполнен, и лишает вменяемых средств воздействия на этот запрос, то счастья вам и здоровья, продолжайте изгаляться с энтити графом когда что-то идет не так.
Если подобную логику делать самому получится просто свой велосипед.
Нет. Велосипед получился, когда написание запросов забрали у разработчика, и возложили на искуственного идиота. Но этот велосипед вполне себе едет, многим нравится.
А что, эти аннотации как-то говорят разработчику какой итоговый sql будет сформирован? Они описывают объекты базы данных, а вовсе не запрос, который к ним будет выполняться.
Ну, как это "не про то", когда именно эта часть в jpa уехала настолько под капот, что что б увидеть запрос нужно параметр конфиги менять? Именно про то!
Использовать entity graph для получения правильных запрсов.
Сначала берем jpa что б не думать о sql, а потом начинаем танцевать нижний брейк с энтити графом, что б получить "правильный запрос". Хех, что здесь может быть не так?! =))))
Какие еще "накладные расходы"? GC в эрланге за счет иммутабельности работает буквально моментально - просто берет и чистит состояние процесса, по сути, без долгой беготни по ссылкам, поскольку их нет.
Ну, и как волшебным образом "смежная команда" может оценить сотрудников соседей, если они не погружены и не вовлечены в то, кто что делает у этих самых соседей? Отдельные команды - отдельное планирование.
А откуда возьмутся эти "большие числа"? Команда редко больше 12-15 человек, а кто тебя еще знает достаточно хорошо, чтобы определить твою компетентность? В соседних отделах как ни крути, а знать тебя будут довольно однобоко, и что бы такой "360" сделать адекватным и информативным в него придется ввалить столько усилий, что мама не горюй.
Всех много, а всего мало - и всего на всех не хватит.
Внедрить 360-фидбэк.Мнение команды о человеке часто бывает куда более объективнее, чем мнение сторонних менеджеров, зажатых в тисках квот.Интересно, в каком мире живет тот, кто это написал? Потому что в реальном мире все эти "360" не имеют с реальностью ничего общего. Что меня, как сотрудника, должно мотивировать объективно оценивать коллегу? Да ничего, нет такой мотивации. А вот мотивов оценить его НЕ объективно полным-полно. Мы с ним друзья-кореша? Везде высший балл! Мы с ним не в ладах? На тебе низкие оценки. все эти "360" это просто попытка переложить ответственность с больной головы на здоровую - это не мы тебе низкие оценки дали, а твои же коллеги, разбирайся с ними. Конечно разберусь - вот будет очередной "360" и я им покажу!
Вот нет других проблем при изучении языка - сигнатура метода main все портит...
Пожалуй, одно из самых заметных изменений для каждого разработчикаВы издеваетесь? Каждому разработчику давно плевать где там в коде
public static void main(String[] args)- это одна единственная строка, которая генерируется за разработчика, и видит он ее примерно никогда. Изменение, ё-мое...Краткое содержание: если слышишь "мы семья - значит тебя пытаются нае... обмануть с целью извлечения из тебя максимальной выгоды. Всегда помни, что ты за деньги продаешь 8 часов своей жизни из 5 дней в неделю, и на этом все.
А кто говорил о проблеме? Никакой проблемы нет, есть свершившийся факт - jpa прячет от разработчика sql. Идите и перечитайте первое мое сообщение, там именно об этом. Если для вас не проблема, что между вами и БД появляется прослойка, которая прячет от вас конечный запрос, который будет выполнен, и лишает вменяемых средств воздействия на этот запрос, то счастья вам и здоровья, продолжайте изгаляться с энтити графом когда что-то идет не так.
Если подобную логику делать самому получится просто свой велосипед.Нет. Велосипед получился, когда написание запросов забрали у разработчика, и возложили на искуственного идиота. Но этот велосипед вполне себе едет, многим нравится.
А что, эти аннотации как-то говорят разработчику какой итоговый sql будет сформирован? Они описывают объекты базы данных, а вовсе не запрос, который к ним будет выполняться.
JPA/ORM это не про то, чтобы не думать об sqlНу, как это "не про то", когда именно эта часть в jpa уехала настолько под капот, что что б увидеть запрос нужно параметр конфиги менять? Именно про то!
Использовать entity graph для получения правильных запрсов.Сначала берем jpa что б не думать о sql, а потом начинаем танцевать нижний брейк с энтити графом, что б получить "правильный запрос". Хех, что здесь может быть не так?! =))))
Какие еще "накладные расходы"? GC в эрланге за счет иммутабельности работает буквально моментально - просто берет и чистит состояние процесса, по сути, без долгой беготни по ссылкам, поскольку их нет.
А давно эрланг стал интерпретируемым?
А почему приговор-то?
Очередная поделка в попытке проехаться на нетленке Остера? Почему-то я не удивлен.
В Sublustrum разве что атмосферная коммуналка в сталинке, а дальше просто шиза.
Работает точно так же - в качестве зависимости внедряется ссылка на один и тот же объект.
Разработчики на Spring:
- Синглтон зло? Ух ты!
Краткая суть - у них распродажа, поэтому случайный текст и ссылка.
Вот потому и антипаттерн, что приходится выбирать между двумя плохими решениями.