Новые технологии часто стоят дорого и требуют серьезных вложений. Со временем всё обкатывается, оптимизируется и становится доступным рядовым гражданам.
Тот же StableDiffusion уже вполне годится для домашнего использования.
Правильно, поэтому на каждое изменение логики апишки будем снова вспоминать эти особенности реализации и дублировать еще и там логику, хотя никто ей не пользуется.
Еще и перед начальством за строки кода в день отчитаться можно будет. Плохо что ли? Хорошо!
Потом началось: «Ты меня привёл сюда, ты там лазишь, воруешь мою торговую стратегию, ты вор, ублюдок… Ты мне врёшь. Вы залезаете ко мне, ты знаешь, что у меня там классный торговый робот, ты хочешь его своровать. Ты залезаешь ко мне на сервер, ты мне гадишь статистику. Это ты подкручиваешь настройки, чтобы у меня ничего не работало».
На андроиде до сих пор Java 1.7 (или 1.8 c оговорками), поэтому новые фичи джавы мы увидим ну очень нескоро, в отличии от котлина, который есть здесь и сейчас.
Потому что они… убогие? Без возможности развертывания сотни инстансов в секунду в автоматическом режиме и прочими возможностями облака.
И сейчас есть много хостингов с балансом в реальном времени. Вот только инстанс нужно руками из админки создавать + подниматься он будет в течении часа-двух.
Тут еще проблема в чём — если сделать неаккуратно, открывается широкое поле для багоюза.
Например точим дешевые палки-копалки пока 3 раза подряд не сломается, а потом затачиваем мифрильные трусы +8. Ура, мы порушили экономику.
Значит придется более сложные данные хранить и мы только что на ровном месте усложнили всю систему. А глобальный беспристрастный рандом такой проблемы иметь не будет :)
Тут ничем помочь не смогу. Скорее всего опять же на геймдизайнерских ресурсах.
Потому что вот это «честное распределение» — оно опирается на субъективность восприятия и геймдизайнерам приходится с коэффициентами играться, чтобы с точки зрения игрока всё было как надо (ну и чтобы киты в итоге побольше донатили, куда без этого)
Но в целом, это проблема постановки ТЗ со стороны геймдизайнера. Т.к. плотно сцеплено с UX, монетизацией и прочими вещами вне основной проблемной области программиста.
Здесь фактически значение null могло бы появиться только в том случае, когда animatedView равен null. Добавление простой проверки if (animatedView != null) избавит нас от цепочки безопасных вызовов. Но в данном примере вообще нет необходимости в том, чтобы animatedView принимало значение null. Поэтому лучше его сделать lateinit переменной, и тогда код вообще не будет содержать проверок на null
Конечно необходимости нет. Пока однажды не отстрелите себе ногу из-за того, что инициализация почему-то не прошла либо метод вызвался до инициализации.
Может быть фрагмент сразу после создания в мусорку отправился, может быть переход слишком быстрым был, может быть ещё куча всяких условий.
lateinit не стоит бездумно лупить куда попало, обязательно нужно держать в голове порядок инициализации и использования переменной, иначе потом будет больное ой в виде UninitializedPropertyAccessException.
Опять же, в ряде отраслей у нвидии есть вкусные эксклюзивные фичи, в которые вкладывались средства. Например для любителей машинного обучения есть CUDA, для геймеров DLSS.
А с перекупами и майнерами имеем что?
* Затраты на эти фичи не отбиваются, это раз.
* Пока ты спишь, враг качается Пока карт нет в продаже, индустрия уходит на решения конкурента, это два.
Насчет дороговизны отсутствия тестов – нет, не измерял, вот честно. Но мне лично это кажется очевидным.
Кейс:
1. Разработчик пишет код без тестов. Запускает локально проект, вроде норм. Отдает тестировщикам
2. Тестировщики находят баги, возвращают
3. Разработчик продолжает ковыряться и получать зарплату
Вместо этого можно написать тесты, и тогда тестировщики не вернут задачу на доработку.
Осталось только подсчитать, программист больше времени потратит на починку багов или на написание тестов?
Что будет больше, зп программиста+зп тестировщика при починке багов или только зп программиста который обмазывается тестами по самое нехочу?
Ну и не всегда тестировщик возвращает только баги. Зачастую это и результат двусмысленности в поставленном ТЗ которое потом доуточняется продукт-овнером и спускается обратно программисту.
От такого вас тесты точно не спасут, т.к. проблема в восприятии задачи программистом, а не в коде.
И что делать с ошибками. Бессознательными (те же опечатки) и сознательными.
Например по всей статье дробная часть запятой отделяется, а здесь наборщик спешил и поставил точку по недосмотру.
Или идет длинное доказательство теоремы Ферма, но где-то в середине автор внедрил "2+2=5" и дальше пошло-поехало.
Получается придется делать исключения к своей к картинке мира, чтобы воспроизвести результат 1 к 1.
Странно что вообще только сейчас додумались "а почему бы не дать пользователям возможность запрета звонков с незнакомых номеров"
Новые технологии часто стоят дорого и требуют серьезных вложений. Со временем всё обкатывается, оптимизируется и становится доступным рядовым гражданам.
Тот же StableDiffusion уже вполне годится для домашнего использования.
Правильно, поэтому на каждое изменение логики апишки будем снова вспоминать эти особенности реализации и дублировать еще и там логику, хотя никто ей не пользуется.
Еще и перед начальством за строки кода в день отчитаться можно будет. Плохо что ли? Хорошо!
Совпадение? :)
И сейчас есть много хостингов с балансом в реальном времени. Вот только инстанс нужно руками из админки создавать + подниматься он будет в течении часа-двух.
Значит для каждого игрока придется заводить записи в БД: «неудачных заточек медных мечей», "«неудачных заточек железных мечей» и т.п.
Ну чтобы когда у него 7й медный меч сломается на 8й раз точно получилось, но при этом он не мог мифрильный меч проточить с 100% гарантией.
Например точим дешевые палки-копалки пока 3 раза подряд не сломается, а потом затачиваем мифрильные трусы +8. Ура, мы порушили экономику.
Значит придется более сложные данные хранить и мы только что на ровном месте усложнили всю систему. А глобальный беспристрастный рандом такой проблемы иметь не будет :)
А сколько раз максимум можно? 4? А почему не 3 и не 5? :)
Потому что вот это «честное распределение» — оно опирается на субъективность восприятия и геймдизайнерам приходится с коэффициентами играться, чтобы с точки зрения игрока всё было как надо (ну и чтобы киты в итоге побольше донатили, куда без этого)
Но в целом, это проблема постановки ТЗ со стороны геймдизайнера. Т.к. плотно сцеплено с UX, монетизацией и прочими вещами вне основной проблемной области программиста.
Конечно необходимости нет. Пока однажды не отстрелите себе ногу из-за того, что инициализация почему-то не прошла либо метод вызвался до инициализации.
Может быть фрагмент сразу после создания в мусорку отправился, может быть переход слишком быстрым был, может быть ещё куча всяких условий.
lateinit не стоит бездумно лупить куда попало, обязательно нужно держать в голове порядок инициализации и использования переменной, иначе потом будет больное ой в виде UninitializedPropertyAccessException.
Ставим фильтр «Всё что не в вайтлисте — в /dev/null». Вы великолепны (нет)
А с перекупами и майнерами имеем что?
* Затраты на эти фичи не отбиваются, это раз.
*
Пока ты спишь, враг качаетсяПока карт нет в продаже, индустрия уходит на решения конкурента, это два.Осталось только подсчитать, программист больше времени потратит на починку багов или на написание тестов?
Что будет больше, зп программиста+зп тестировщика при починке багов или только зп программиста который обмазывается тестами по самое нехочу?
Ну и не всегда тестировщик возвращает только баги. Зачастую это и результат двусмысленности в поставленном ТЗ которое потом доуточняется продукт-овнером и спускается обратно программисту.
От такого вас тесты точно не спасут, т.к. проблема в восприятии задачи программистом, а не в коде.