А что, для всех убийц "not awailable"? Или некоторые убийцы кого надо убийцы?
Если вы покажете (и докажете), что для ВСЕХ убийц not awailable, а не так, что для некоторых - not awailable (мы все понимаем, для каких), а для некоторых - ок (мы все понимаем, для каких) - то тогда можно продолжать, если же нет (а мы все понимаем, что нет), то тогда вопрос в национальности, и этот тред можно преращать.
С определенной даты (мы все знаем, с какой) у вас нет морального права говорить про "убийц" в контектсе кидалова netflix (и прочих западных компаний) читателей Хабра.
Чем этот StableValue отличается от ломбокоской lazy? Если реализация - только еще один библиотечный класс, работающий на обычной java, то зачем все это?
Чем Jep-овская приблуда лучше этого кода?
public static class PetClientController {
@Getter(lazy = true)
private final JavaMailSender javaMailSender = new JavaMailSenderImpl();
public void adoptPet(SecurityProperties.User user, Object pet) {
//...
getJavaMailSender().send(new MimeMessage(...));
}
}
Теория игр говорит, что при выборе решения нужно выбирать решение, при котором возможный проигрыш минимальный, а не то решение, при котором выигрыш максимальный.
Если мы выберем запретить ИИ - какие возможные выигрыш и проигрыш - выигрыш - медленное развитие человечества, излечение от всех болезней, расселение по всем планетам через тысячи лет, проигрыш - медленное угасание человечества. Если выберем использовать ИИ, выигрыш - излечивание всех болезней, автоматизация, генетическое преобразование человека, возможно, расселение по планетам, причем за срок порядка столения. Проигрыш при этом - уничтожение человечества, причем за годы.
Я вчера Луну-то снять не мог во время лунного затмения. Глазами прекрасно видно, в бинокль отлично видно (кратеры разглядывал). В телефоне вообще ничего не видно.
Ночью темный объект, пусть с огнями или контуром, как у комментатора выше, просто не отобразится в телефоне.
То-ли пример неверный, то ли еще что. Интеграционные тесты предназначены только для одного - тестирования интеграции - сиречь для того, чтобы проверить, что вилка с розеткой правильно спроектированы и изготовлены.
Я вижу, что тестконтейнеры хороши, когда начинаешь писать тесты в унаследованный проект, где обращение к сторонним сервисам, вроде бд, производится прямо в нижних методах. Выбрали из базы - посчитали что-то - сохранили в базу - выбрали из базы - посчитали - сохранили в базу - закончили упражнение. Такие классы не проюнитишь без серьезного перелопачивания.
Правильное решение для такого кейса - сохранеие адреса выделяется в отдельный класс. В него инжектится датасурс к базе. userService.registerUser - такого быть не должно. Репозиторий должен делать только getUser и saveUser. getUser должен просто возвращать или null, или пользователя по верхнему регистру с идентификатором. saveUser - просто создавать или апдейтить пользователя. В базе должно быть два поля - как есть, и верхнем регистре (можно сделать индекс с верхним регистром и запрос делать UPPER(user) = :user). Никаких проверок и ошибок он не должен возвращать. Это simple объект. Проверка должна осуществляться в бизнес-классе (UserService). В нем из входа приводится к верхнему регистру, обращается к датасурсу, если есть - выбрасывается исключение, если нет - делается вызов saveUser. Этот класс и метод отлично юнит-тестится.
Тестконтейнеры приходится (ПРИХОДИТСЯ!) применять в случае унаследованной системы, также когда часть логики в процедурах или сторонних системах, и на нее завязана тестируемая функциональность.
Более того, я считаю, тестконтейнеры ВРЕДЯТ организации, поскольку вместо правильного разделения слоев, поощряют писать код-лапшу, в котором не применяется DI, не используется в полную мощь Spring, и обращения к сторонним сервисам производится на самых нижних уровнях. Такой бардак обязательно выйдет боком. Не говоря о том, что производительность тесконтейнеров, в отличии от юнит, ужасная - процесс разработки просто или встанет, потому что билд с тестами будет делаться по полчаса-час, либо их просто отключат.
4 Плеер юзабильнее. Чтобы перейти к следующей песне, надо телефон разблокировать - нажать на кнопку разблокировки или потапать по экрану, подержать палец на кружке, три раза сделать попытку при этом, потом перейти в приложение проигрывания, помудохаться там с интерфесом, добраться до маленькой кнопки перехода к следующей песне. На плеере ты нажимаешь на кнопку перехода к следующей песне. Можно не доставая его из кармана. И вот так всё в телефоне. Все через жопу, с чудовищными дрыгающимися, выползающимися, наславивающимися интерфейсами. С кучей рекламы, картинок, анонсов, предложений, пропагации новинок и новых исполнителей, всякого говна... Задача найти свою любимую песню или плейлист превращается в квест. Телефон начинает греться, сжирает заряд за несколько часов, ты не успеваешь дойти до дома, он садится и ты не можешь вызвать такси или купить билет на электричку (а сейчас еще и получишь траблы от теток в мышином, если не включишь телефон).
Звучит красиво, но интуитивно понимаю, что когда все начнут экономить (тратя на это деньги), то облачные провайдеры просто поднимут тарифы, нивелируя эти усилия.
А что, для всех убийц "not awailable"? Или некоторые убийцы кого надо убийцы?
Если вы покажете (и докажете), что для ВСЕХ убийц not awailable, а не так, что для некоторых - not awailable (мы все понимаем, для каких), а для некоторых - ок (мы все понимаем, для каких) - то тогда можно продолжать, если же нет (а мы все понимаем, что нет), то тогда вопрос в национальности, и этот тред можно преращать.
С определенной даты (мы все знаем, с какой) у вас нет морального права говорить про "убийц" в контектсе кидалова netflix (и прочих западных компаний) читателей Хабра.
Надо соблюдать Трудовое законодательство.
Они и в цехе любого производство мастера тем-же самым занимаются. Собачья работа.
Честно говоря, автор идеалист, и занимался чепухой.
Этот "Эффект манделы" разве что в головах зумеров.
Чем этот StableValue отличается от ломбокоской lazy? Если реализация - только еще один библиотечный класс, работающий на обычной java, то зачем все это?
Чем Jep-овская приблуда лучше этого кода?
Теория игр говорит, что при выборе решения нужно выбирать решение, при котором возможный проигрыш минимальный, а не то решение, при котором выигрыш максимальный.
Если мы выберем запретить ИИ - какие возможные выигрыш и проигрыш - выигрыш - медленное развитие человечества, излечение от всех болезней, расселение по всем планетам через тысячи лет, проигрыш - медленное угасание человечества. Если выберем использовать ИИ, выигрыш - излечивание всех болезней, автоматизация, генетическое преобразование человека, возможно, расселение по планетам, причем за срок порядка столения. Проигрыш при этом - уничтожение человечества, причем за годы.
Делайте выводы.
Больше всего удар по бойлерплейт нанес record. С ним почти все фичи ломбока можно запретить.
Годный материал.
"Эксперимент" - как пример того, когда неспециалист, психолог, биолог-недоучка, проектирует эксперимент над животными.
Пример: "Руководители часто винят регулирование или недостаточную производительность моделей ".
Если какая-то деятельность противоречит пусть даже всем мировым (кстати, какие еще есть?) религиям, это не делает ее пустой тратой времени и денег.
Россияне проголосовали за РФ, американцы бы проголосовали за США. Не вижу проблемы.
Я вчера Луну-то снять не мог во время лунного затмения. Глазами прекрасно видно, в бинокль отлично видно (кратеры разглядывал). В телефоне вообще ничего не видно.
Ночью темный объект, пусть с огнями или контуром, как у комментатора выше, просто не отобразится в телефоне.
Вы переоцениваете возможности телефонов.
То-ли пример неверный, то ли еще что. Интеграционные тесты предназначены только для одного - тестирования интеграции - сиречь для того, чтобы проверить, что вилка с розеткой правильно спроектированы и изготовлены.
Я вижу, что тестконтейнеры хороши, когда начинаешь писать тесты в унаследованный проект, где обращение к сторонним сервисам, вроде бд, производится прямо в нижних методах. Выбрали из базы - посчитали что-то - сохранили в базу - выбрали из базы - посчитали - сохранили в базу - закончили упражнение. Такие классы не проюнитишь без серьезного перелопачивания.
Правильное решение для такого кейса - сохранеие адреса выделяется в отдельный класс. В него инжектится датасурс к базе.
userService.registerUser - такого быть не должно. Репозиторий должен делать только getUser и saveUser. getUser должен просто возвращать или null, или пользователя по верхнему регистру с идентификатором. saveUser - просто создавать или апдейтить пользователя. В базе должно быть два поля - как есть, и верхнем регистре (можно сделать индекс с верхним регистром и запрос делать UPPER(user) = :user). Никаких проверок и ошибок он не должен возвращать. Это simple объект. Проверка должна осуществляться в бизнес-классе (UserService). В нем из входа приводится к верхнему регистру, обращается к датасурсу, если есть - выбрасывается исключение, если нет - делается вызов saveUser. Этот класс и метод отлично юнит-тестится.Тестконтейнеры приходится (ПРИХОДИТСЯ!) применять в случае унаследованной системы, также когда часть логики в процедурах или сторонних системах, и на нее завязана тестируемая функциональность.Более того, я считаю, тестконтейнеры ВРЕДЯТ организации, поскольку вместо правильного разделения слоев, поощряют писать код-лапшу, в котором не применяется DI, не используется в полную мощь Spring, и обращения к сторонним сервисам производится на самых нижних уровнях. Такой бардак обязательно выйдет боком. Не говоря о том, что производительность тесконтейнеров, в отличии от юнит, ужасная - процесс разработки просто или встанет, потому что билд с тестами будет делаться по полчаса-час, либо их просто отключат.Надо просто создать условия на Земле ХУЖЕ, чем... погодите-ка...
И у светодиодных ламп?
Какие открытия в фундаментальной науке сделал Китай за последние 50 лет?
То есть, надо чтобы пластиковая упаковка для производителей пива и товаров была дороже, чем стеклянная и деревянная? И в чем проблема?
Эта проблема похожа на следующий вопрос: может ли ML-модель понять, что она такое и как она устроена?
4 Плеер юзабильнее. Чтобы перейти к следующей песне, надо телефон разблокировать - нажать на кнопку разблокировки или потапать по экрану, подержать палец на кружке, три раза сделать попытку при этом, потом перейти в приложение проигрывания, помудохаться там с интерфесом, добраться до маленькой кнопки перехода к следующей песне. На плеере ты нажимаешь на кнопку перехода к следующей песне. Можно не доставая его из кармана. И вот так всё в телефоне. Все через жопу, с чудовищными дрыгающимися, выползающимися, наславивающимися интерфейсами. С кучей рекламы, картинок, анонсов, предложений, пропагации новинок и новых исполнителей, всякого говна... Задача найти свою любимую песню или плейлист превращается в квест. Телефон начинает греться, сжирает заряд за несколько часов, ты не успеваешь дойти до дома, он садится и ты не можешь вызвать такси или купить билет на электричку (а сейчас еще и получишь траблы от теток в мышином, если не включишь телефон).
Звучит красиво, но интуитивно понимаю, что когда все начнут экономить (тратя на это деньги), то облачные провайдеры просто поднимут тарифы, нивелируя эти усилия.