Умная модель сделает вывод, что игра подразумевает одновременные ответы, и будет генерировать либо случайным образом, либо на основе предыдущих раундов, используя разные стратегии (может даже запуска множество агентов и отбирая среди них тех, что лучше подходят под соперника).
Вообще, из этого эксперимента неясно, что именно происходит: у моделей такая непреодолимая тяга к победе, что они читерят даже понимая, как можно имитировать одновременность ходов, или они просто как Электроник, которому объяснили, что нужно забросить шайбу в ворота, но не объяснили в чьи ворота.
Скачал https://github.com/OpenDUNE/OpenDUNE, который якобы повторяет механику оригинала. Никакого эффекта смерти червя там не обнаружилось, реально просто исчезает :(
1. Либо когда меньше половины жизни (хоть 49%, хоть 0%):
# src/unit.c
if (unit->o.hitpoints >= ui->o.hitpoints / 2) return false;
if (unit->o.type == UNIT_SANDWORM) {
Unit_SetAction(unit, ACTION_DIE);
}
2. Либо когда достигнет лимита съеденных юнитов (amount начинается с 3)
При этом с ACTION_DIE никакого спецэффекта (взрыва) не связано.
Понятное дело, что лично меня это ничего не доказывает :)
Мало ли, что они там реализовали, у меня червяк жрал только подавай, и был эффект смерти, о котором уже говорил. @DimaIam упомянул, что при этом еще спайс оседал - очень может быть!
Поэтому немного подфуфлил текстуры и алгоритм, чтобы показать в грубом виде как это было. Тем более, что в файле со взрывами (src/table/explosion.c) у них есть неиспользуемая заготовка /* EXPLOSION_UNUSED_12 */.
Фановая версия уничтожения червя
Вот так вот
Вообще, судя по коду, с червем они настрадались. Почти везде он нарушает общую логику юнитов, и приходится вставлять if-ы:
Юниты должны повернутся лицом к противнику, прежде чем выстрелить, червяк - нет (да, когда он глотает - это стрельба с нулевого расстояния, а пуля - сам червь).
Проход через "кочку" не триггерит взрыв.
Сам червяк - это одни квадрат, но для визуальной длины добавляется еще два, хотя по ним урон не засчитывается). И рисуется из-за этого отдельным методом (причем сначала рисуется червь, потом все остальные юниты, чтобы он не затирал их).
Чтобы червь не лазил по твердой поверхности, ему там сделали скорость 0.
Урон у червя 300 (скажи триста..), но это ничего не значит, т.к. проглотить он может любого юнита, и тото просто удаляется из игры (Unit_Remove без взрывов и т.д.). Иначе бы червь не мог бы проглотить танк Devastator, у которого хп 400. Кстати, хп самого червя 1000 (но фактически 500, т.к. после этого начнет срабатывать исчезновение). Больше характеристик здесь https://github.com/OpenDUNE/OpenDUNE/blob/master/src/table/unitinfo.c#L1840
Отдельная защита от коллизий, чтобы червь мог находиться на одной клетке с другим юнитом (остальные либо давят, либо не могут попасть на эту клетку). Кстати, раздавливание тоже не проверяет хп противника, лишь бы у него были "ноги" (да, в дюне все объекты обмазаны еще кучей категорий, по которым тоже строится логика).
Отдельные исключения, чтобы он атаковал атрейдесов и не светил им карту (т.к. сам принадлежит к фременам, которые являются дружественным домом для атрейдесов).
И напоследок, любимые блюда червя:
Пехота - 100
Харвестер - 1000
Остальная техника на колесах/гусеницах - 5000
Кроме того, приоритет умножается, если техника рядом, едет или стреляет (а если все сразу, так и ваще!)
При этом червь выбирает только одну цель за раз, и преследует ее, пока может. А потом еще долго тупит, пытаясь понять по какому маршруту идти дальше.
А еще, там для хранения информации о каждом юните используется такой костыль, как общий массив с ключами от 0 до 101, и для червяков отведено только два индекса (16 и 17), поэтому их в игре одновременно не может быть больше 2 :(
А танчик сони используется тот же эффект блюра песка, что и червь (видимо так намучались с ним, что было жалко только ради червя делать).
Если кто-то хочет поразвлечься, подкрутив здоровье/ударку/скорость обычному солдату, чтобы тот на финальной миссии в одиночку разнес все фракции (или сделать стреляющий харвестер), то вот инструкции по сборке на Ubuntu:
sudo apt install build-essential libsdl2-dev
git clone git@github.com:OpenDUNE/OpenDUNE.git
cd OpenDUNE
# change code
./configure --with-sdl2
make
Да нет же, речь именно о том, чтобы завалить. Не о том, что он исчезнет после 50%, или проглотит кого-то и успокоится. И никаких хитрых схем аля "бить, пока поедает примакну", или удара "Рукой Смерти", или подрыва "кочки", когда он проходит через нее.
Просто тупо фигачить по нему, пока он ползет мимо базы.
Возможно, дело случая, когда движок еще не успевал понять, что надо прятать червя, а по нему прилетает достаточный урон, чтобы добить до конца.
Ну тогда респект разрабам, что они все-таки предусмотрели этот кейс с гибелью червя. Хотя я ожидал чего-то большего в плане эффектов, уж больно много эта тварь добра пожрала :) (хотя пишут, что он всего пяток юнитов съедал и успокаивался, но мне казалось, он их может хавать бесконечно).
Да, графика там была даже слишком реалистичной. От сцены смерти, когда слишком далеко улетел, до сих пор дрожь) Какие-то странные чуваки, которые ныкаются по пещерам, а потом отважно добывают тебе спайс, ковыряя лопатами песок в безжалостной пустыне, без еды и воды, где палящий песок и черви. Жесть.. Немного картинок для сведения олдскулл:
В том-то и дело, что исчезал. А харконнены успевали его замочить (может у них сильнее импакт, либо просто у меня за других не получалось так удачно долбить).
Примерно так: выстраиваешь по краю батарею ракетниц, добавляешь за ними пузатых танков, и когда он вдоль проходит, они от души прикладываются.
Хотел найти видео или хотя бы картинку - но нигде нет :(
Более того, в одном месте пишут, что он взрывается, но это не так, ну или я не запомнил взрыва. Но в конечном итоге он вываливался наружу (такой козявкой, не очень хорошо прорисованной), а потом погружался в песок, аналогично пехотинцам.
Ага, теперь кроме цветовой какофонии будет еще и текстовая. Хотя для обфусцированного кода или проекта, где все совсем плохо - это полезно.. было когда-то до ИИ.
Вот если бы OpenIDE сделали возможность после поиска по имени таблицы раскрывать колонки.. а еще лучше при просмотре таблицы добавили навигацию к колонке по имени (и Рома перенес бы это) - другой разговор)
Ну или (хотя понимаю, что много прошу от IDE в 2026-ом) возможность переименовать файл за пределами Project..
А то получается одного раздувшегося, тормозного, полного косяков и нестыковок редактора мало - надо еще один на его основе.
Пишите для себя, тогда точно как минимум одному человеку понравится и пригодится, и этот человек вам не чужой :)
А если пытаться закрывать потребности рынка, то потом: "А почему не взлетело", "Для кого старался", "Столько времени и сил в никуда", "Больше здесь ничего не напишу"...
Приятный слог статьи, спасибо! И предлагаемая ORM выглядит симпатичной!
Но угроза очередной смены работы всё еще висит над Виктором :(
Как говорится: "Надежда - хороший завтрак, но плохой ужин".
Если в проекте уже есть толстая таблица, то идея со специализированными отображениями может помочь на уровне кода. И скорость будет удовлетворительная. До какой-то поры.
Но бд - не волшебный ящик, и с ростом данных будет выставлен счёт. Поэтому со старта закладывать архитектуру, которая будет полагаться на такое хранение данных - дело рискованное.
Чем больше колонок - тем больше бд тратит ресурсов на их сканирование (заодно вытесняя полезный кэш).
Чем больше nullable колонок - тем меньше раз сработает оптимизация, и тем больше раз вообще понадобится фильтрация (например, поиск пользователей со страйпом, вместо работы с таблицей, которая уже содержит только пользователей со страйпом).
А сколько у таких таблиц будет индексов? А это же тоже недешевое удовольствие, особенно когда всё внутри одной таблицы.
А если к таблицам подключать audit-модули, для контроля за изменениями, то как быстро будут раздуваться такие audit___users и насколько удобно в них будет найти нужные изменения среди всех? Или переделывать готовые решения, чтобы раскидывать изменения по разным audit таблицам?
А впереди еще вопросы по разным уровням доступа к разным частям (колонкам) персональной информации. Бекапы. Репликации...
Имхо: лучше сразу разъединить, а потом ломать голову как объединить, чем наоборот. Потому что когда возникнет проблема - будет понятней, что должно быть в этом объединении (возможно вообще понадобится вьюшка из разных таблиц и агрегаций). А вот разъединять живые таблицы на проде - всегда стресс.
Добро пожаловать в клуб свидетелей документации на основе кода, а не комментариев к коду :)
Сам когда-то на Хабр с похожей штукой залетел (https://habr.com/ru/articles/775056/). Только там вместо отдельной библиотеки делал небольшую надстройку над существующей.
Из других отличий, входящие параметры определяются не через атрибут + дто, а чистым дто, который заполняется через ValueResolver.
Да, за это у класса CompletionListQuery должен появиться какой-то признак, позволяющий понять, что его нужно заполнить (интерфейс, атрибут, наследование). Но имхо такой подход приятней глазу, а то эти атрибуты в типизации - как прыщи)
Второй момент, не обязательно нужен Symfony 8 с ее сахаром, чтобы возвращать из контроллера типизированный объект. Можно использовать обычный слушатель kernel.view. Но в целом идея такая же.
Спасибо за книгу Аделя Ф! Наконец БХВ стали проявлять здоровую активность и возвращать позиции в ИТ. Так держать!
Но зачем айтишнику писать книги, и почему сейчас — самый лучший момент?
Разве ИИ не обесценил эту форму подачи информации, а заодно и всю профессию программирования?
Для кого писать ИТ-книги, если через пару лет программисты уйдут в закат вслед за видеопрокатчиками, телефонистами и людьми-будильниками?
Волны ИИ-хайпа накатывают одна за другой - и чтение книг кажется уделом старпёров. А уж писать их - тем более… Поэтому без ответов на эти вопросы новых авторов не завлечь :)
ИИ - классная штука, как ни крути! Но мозги она прокачивает плохо. Даже наоборот - размягчает их (как Оземпик кости). Со всеми вытекающими последствиями как для нас, так и для тех, на кого мы работаем.
Долг понимания кода, потеря воли к преодолению сложностей, стекающие знания - вот они, нынешние чума, проказа и дизентерия, обрушившиеся на брата-программиста.
Приправлю аналогией из книги сэра Терри Пратчетта «Equal Rites». Там ведьмы умеют "вживаться" (переносить сознание) в тела животных. Если находиться в теле разумное время - это очень удобно: захватил (одолжил) сознание птицы, слетал куда-то, узнал что нужно, освободил. Но если оставаться в чужом теле слишком долго, сознание просто растворяется и конец. Это толстый намек на вайбкодинг. Когда слишком долго получаешь результаты не думая, - в какой-то момент думание атрофируется, а вместе с ним и способность получать результаты.
Так далеко не уйти.
В этом плане книги - та самая здоровая пища, которая усваивается не так быстро, но зато по-настоящему питает мозг. А писательская деятельность - как тренировка, не дающая мышцам одрябнуть.
Понятное дело, что в эпоху машин глупо всё время передвигаться пешком. Но пробежки наполняют энергией, чтение - мозгами, письмо - силой!
Немного коряво, но как-то так я бы завлекал на эту стезю :)
PS.
По поводу современного окна возможностей.
Как раз недавно наводил порядок в своей коллекции, и заметил книгу по программированию Александра Шеня аж 1995 года. Она начинается с очень веселого, дерзкого и невероятно современного вступления "Не покупайте эту книгу!".
Для сравнения, рядом привел 7-е издание этой книги. В нём уже нет этого вступления, зато есть красный штамп. Такие времена.
Александр Шень - Программирование: теоремы и задачи - 1-е vs 7-е издания
Обновил статью. Наглядная демонстрация того, что специализированная метка - рулит) И того, что PhpStorm разрабы не такие негодяи, как я иногда их пытаюсь представить) Что ж, мечты сбываются, был не прав, признаю!
Умная модель сделает вывод, что игра подразумевает одновременные ответы, и будет генерировать либо случайным образом, либо на основе предыдущих раундов, используя разные стратегии (может даже запуска множество агентов и отбирая среди них тех, что лучше подходят под соперника).
Вообще, из этого эксперимента неясно, что именно происходит: у моделей такая непреодолимая тяга к победе, что они читерят даже понимая, как можно имитировать одновременность ходов, или они просто как Электроник, которому объяснили, что нужно забросить шайбу в ворота, но не объяснили в чьи ворота.
Скачал https://github.com/OpenDUNE/OpenDUNE, который якобы повторяет механику оригинала. Никакого эффекта смерти червя там не обнаружилось, реально просто исчезает :(
1. Либо когда меньше половины жизни (хоть 49%, хоть 0%):
2. Либо когда достигнет лимита съеденных юнитов (amount начинается с 3)
При этом с ACTION_DIE никакого спецэффекта (взрыва) не связано.
Понятное дело, что лично меня это ничего не доказывает :)
Мало ли, что они там реализовали, у меня червяк жрал только подавай, и был эффект смерти, о котором уже говорил. @DimaIam упомянул, что при этом еще спайс оседал - очень может быть!
Поэтому немного подфуфлил текстуры и алгоритм, чтобы показать в грубом виде как это было. Тем более, что в файле со взрывами (src/table/explosion.c) у них есть неиспользуемая заготовка /* EXPLOSION_UNUSED_12 */.
Фановая версия уничтожения червя
Вообще, судя по коду, с червем они настрадались. Почти везде он нарушает общую логику юнитов, и приходится вставлять if-ы:
Юниты должны повернутся лицом к противнику, прежде чем выстрелить, червяк - нет (да, когда он глотает - это стрельба с нулевого расстояния, а пуля - сам червь).
Проход через "кочку" не триггерит взрыв.
Сам червяк - это одни квадрат, но для визуальной длины добавляется еще два, хотя по ним урон не засчитывается). И рисуется из-за этого отдельным методом (причем сначала рисуется червь, потом все остальные юниты, чтобы он не затирал их).
Чтобы червь не лазил по твердой поверхности, ему там сделали скорость 0.
Урон у червя 300 (скажи триста..), но это ничего не значит, т.к. проглотить он может любого юнита, и тото просто удаляется из игры (Unit_Remove без взрывов и т.д.). Иначе бы червь не мог бы проглотить танк Devastator, у которого хп 400. Кстати, хп самого червя 1000 (но фактически 500, т.к. после этого начнет срабатывать исчезновение). Больше характеристик здесь https://github.com/OpenDUNE/OpenDUNE/blob/master/src/table/unitinfo.c#L1840
Отдельная защита от коллизий, чтобы червь мог находиться на одной клетке с другим юнитом (остальные либо давят, либо не могут попасть на эту клетку). Кстати, раздавливание тоже не проверяет хп противника, лишь бы у него были "ноги" (да, в дюне все объекты обмазаны еще кучей категорий, по которым тоже строится логика).
Отдельные исключения, чтобы он атаковал атрейдесов и не светил им карту (т.к. сам принадлежит к фременам, которые являются дружественным домом для атрейдесов).
И напоследок, любимые блюда червя:
Пехота - 100
Харвестер - 1000
Остальная техника на колесах/гусеницах - 5000
Кроме того, приоритет умножается, если техника рядом, едет или стреляет (а если все сразу, так и ваще!)
При этом червь выбирает только одну цель за раз, и преследует ее, пока может. А потом еще долго тупит, пытаясь понять по какому маршруту идти дальше.
А еще, там для хранения информации о каждом юните используется такой костыль, как общий массив с ключами от 0 до 101, и для червяков отведено только два индекса (16 и 17), поэтому их в игре одновременно не может быть больше 2 :(
А танчик сони используется тот же эффект блюра песка, что и червь (видимо так намучались с ним, что было жалко только ради червя делать).
Если кто-то хочет поразвлечься, подкрутив здоровье/ударку/скорость обычному солдату, чтобы тот на финальной миссии в одиночку разнес все фракции (или сделать стреляющий харвестер), то вот инструкции по сборке на Ubuntu:
Кроме того, нужно отдельно скачать dune2, например от сюда https://www.old-games.ru/game/download/1482.html (anykey - русскоязычная озвучка https://www.old-games.ru/game/download/get.php?fileid=2956&modal=1)
и распаковать в папку OpenDUNE/bin/data.
После этого в папке bin запустить ./opendune
Но по умолчанию экран слишком мелкий, так что подкрутите конфиг масштабированием (scalefactor=4 в ~/.config/opendune/opendune.ini)
Да нет же, речь именно о том, чтобы завалить. Не о том, что он исчезнет после 50%, или проглотит кого-то и успокоится. И никаких хитрых схем аля "бить, пока поедает примакну", или удара "Рукой Смерти", или подрыва "кочки", когда он проходит через нее.
Просто тупо фигачить по нему, пока он ползет мимо базы.
Возможно, дело случая, когда движок еще не успевал понять, что надо прятать червя, а по нему прилетает достаточный урон, чтобы добить до конца.
Ну тогда респект разрабам, что они все-таки предусмотрели этот кейс с гибелью червя. Хотя я ожидал чего-то большего в плане эффектов, уж больно много эта тварь добра пожрала :) (хотя пишут, что он всего пяток юнитов съедал и успокаивался, но мне казалось, он их может хавать бесконечно).
На всякий случай, я играл на PC, вот в эту версию https://dune.fandom.com/wiki/Dune_II
Там же, кстати, тоже говорят, что это возможно (но без акцента на доме):
Понимаю, что всё это звучит как вброс) Сам в шоке, что в интернете нет видео на эту тему.
Да, графика там была даже слишком реалистичной. От сцены смерти, когда слишком далеко улетел, до сих пор дрожь) Какие-то странные чуваки, которые ныкаются по пещерам, а потом отважно добывают тебе спайс, ковыряя лопатами песок в безжалостной пустыне, без еды и воды, где палящий песок и черви. Жесть.. Немного картинок для сведения олдскулл:
В том-то и дело, что исчезал. А харконнены успевали его замочить (может у них сильнее импакт, либо просто у меня за других не получалось так удачно долбить).
Примерно так: выстраиваешь по краю батарею ракетниц, добавляешь за ними пузатых танков, и когда он вдоль проходит, они от души прикладываются.
Хотел найти видео или хотя бы картинку - но нигде нет :(
Более того, в одном месте пишут, что он взрывается, но это не так, ну или я не запомнил взрыва. Но в конечном итоге он вываливался наружу (такой козявкой, не очень хорошо прорисованной), а потом погружался в песок, аналогично пехотинцам.
Еще Харконены могли завалить червя! Но главного так и не показали:
Скрытый текст
Или так) Но за теми, у кого нет желания перечитывать, Даннинг с Крюгером приходят чаще.
Может, и самый перспективный, но перспектива так себе.
Ага, теперь кроме цветовой какофонии будет еще и текстовая. Хотя для обфусцированного кода или проекта, где все совсем плохо - это полезно.. было когда-то до ИИ.
Вот если бы OpenIDE сделали возможность после поиска по имени таблицы раскрывать колонки.. а еще лучше при просмотре таблицы добавили навигацию к колонке по имени (и Рома перенес бы это) - другой разговор)
Ну или (хотя понимаю, что много прошу от IDE в 2026-ом) возможность переименовать файл за пределами Project..
А то получается одного раздувшегося, тормозного, полного косяков и нестыковок редактора мало - надо еще один на его основе.
Пишите для себя, тогда точно как минимум одному человеку понравится и пригодится, и этот человек вам не чужой :)
А если пытаться закрывать потребности рынка, то потом: "А почему не взлетело", "Для кого старался", "Столько времени и сил в никуда", "Больше здесь ничего не напишу"...
Если собственную статью хочется и самому перечитывать - то успешная.
Если не сделано ничего - это уже неплохо! Хуже, если опять наделали бед.
Справедливости ради, в этом релизе должна появиться навигация через #[CoversMethod] (https://youtrack.jetbrains.com/issue/WI-84302/PHPUnit-Make-it-possible-to-navigate-to-the-specific-method-via-CoversMethod#focus=Comments-27-13552145.0-0).
Но не проверял, поскольку золотое правило гласит никогда не ставить новую версию PhpStorm, пока не пройдет хотя бы месяц - уж слишком больно.
PS. Довольно с
транный перевод. Не нашел в оригинале ничего про паразитирующий на чужом продукте OpenIDE. А тут он вплетен, как будто так и было.Приятный слог статьи, спасибо! И предлагаемая ORM выглядит симпатичной!
Но угроза очередной смены работы всё еще висит над Виктором :(
Как говорится: "Надежда - хороший завтрак, но плохой ужин".
Если в проекте уже есть толстая таблица, то идея со специализированными отображениями может помочь на уровне кода. И скорость будет удовлетворительная. До какой-то поры.
Но бд - не волшебный ящик, и с ростом данных будет выставлен счёт. Поэтому со старта закладывать архитектуру, которая будет полагаться на такое хранение данных - дело рискованное.
Чем больше колонок - тем больше бд тратит ресурсов на их сканирование (заодно вытесняя полезный кэш).
Чем больше nullable колонок - тем меньше раз сработает оптимизация, и тем больше раз вообще понадобится фильтрация (например, поиск пользователей со страйпом, вместо работы с таблицей, которая уже содержит только пользователей со страйпом).
А сколько у таких таблиц будет индексов? А это же тоже недешевое удовольствие, особенно когда всё внутри одной таблицы.
А если к таблицам подключать audit-модули, для контроля за изменениями, то как быстро будут раздуваться такие audit___users и насколько удобно в них будет найти нужные изменения среди всех? Или переделывать готовые решения, чтобы раскидывать изменения по разным audit таблицам?
А впереди еще вопросы по разным уровням доступа к разным частям (колонкам) персональной информации. Бекапы. Репликации...
Имхо: лучше сразу разъединить, а потом ломать голову как объединить, чем наоборот. Потому что когда возникнет проблема - будет понятней, что должно быть в этом объединении (возможно вообще понадобится вьюшка из разных таблиц и агрегаций). А вот разъединять живые таблицы на проде - всегда стресс.
Добро пожаловать в клуб свидетелей документации на основе кода, а не комментариев к коду :)
Сам когда-то на Хабр с похожей штукой залетел (https://habr.com/ru/articles/775056/). Только там вместо отдельной библиотеки делал небольшую надстройку над существующей.
Из других отличий, входящие параметры определяются не через атрибут + дто, а чистым дто, который заполняется через ValueResolver.
Да, за это у класса CompletionListQuery должен появиться какой-то признак, позволяющий понять, что его нужно заполнить (интерфейс, атрибут
, наследование). Но имхо такой подход приятней глазу, а то эти атрибуты в типизации - как прыщи)Второй момент, не обязательно нужен Symfony 8 с ее сахаром, чтобы возвращать из контроллера типизированный объект. Можно использовать обычный слушатель kernel.view. Но в целом идея такая же.
Зачем CSS, если специально для этого придумали <dialog> ?)
Это точно работает? Применил к нашему основному проекту, но визуально ничего не поменялось..
Спасибо за книгу Аделя Ф! Наконец БХВ стали проявлять здоровую активность и возвращать позиции в ИТ. Так держать!
Но зачем айтишнику писать книги, и почему сейчас — самый лучший момент?
Разве ИИ не обесценил эту форму подачи информации, а заодно и всю профессию программирования?
Для кого писать ИТ-книги, если через пару лет программисты уйдут в закат вслед за видеопрокатчиками, телефонистами и людьми-будильниками?
Волны ИИ-хайпа накатывают одна за другой - и чтение книг кажется уделом старпёров. А уж писать их - тем более… Поэтому без ответов на эти вопросы новых авторов не завлечь :)
ИИ - классная штука, как ни крути! Но мозги она прокачивает плохо. Даже наоборот - размягчает их (как Оземпик кости). Со всеми вытекающими последствиями как для нас, так и для тех, на кого мы работаем.
Долг понимания кода, потеря воли к преодолению сложностей, стекающие знания - вот они, нынешние чума, проказа и дизентерия, обрушившиеся на брата-программиста.
Приправлю аналогией из книги сэра Терри Пратчетта «Equal Rites». Там ведьмы умеют "вживаться" (переносить сознание) в тела животных. Если находиться в теле разумное время - это очень удобно: захватил (одолжил) сознание птицы, слетал куда-то, узнал что нужно, освободил. Но если оставаться в чужом теле слишком долго, сознание просто растворяется и конец. Это толстый намек на вайбкодинг. Когда слишком долго получаешь результаты не думая, - в какой-то момент думание атрофируется, а вместе с ним и способность получать результаты.
Так далеко не уйти.
В этом плане книги - та самая здоровая пища, которая усваивается не так быстро, но зато по-настоящему питает мозг. А писательская деятельность - как тренировка, не дающая мышцам одрябнуть.
Понятное дело, что в эпоху машин глупо всё время передвигаться пешком. Но пробежки наполняют энергией, чтение - мозгами, письмо - силой!
Немного коряво, но как-то так я бы завлекал на эту стезю :)
PS.
По поводу современного окна возможностей.
Как раз недавно наводил порядок в своей коллекции, и заметил книгу по программированию Александра Шеня аж 1995 года. Она начинается с очень веселого, дерзкого и невероятно современного вступления "Не покупайте эту книгу!".
Для сравнения, рядом привел 7-е издание этой книги. В нём уже нет этого вступления, зато есть красный штамп. Такие времена.
Право слово, серьезные ресурсы превращаются в цирк не из-за появления шуточных материалов, но из-за исчезновения полезных.
Вот после таких кейсов в языках и появляются дженерики.
Подъехал фидбек от JetBrains. Оказывается, уже можно проваливаться в тестируемый класс (Ctrl + Shift + T, либо через контекстное меню Go To -> Test Subject): https://youtrack.jetbrains.com/issue/WI-84302/PHPUnit-Make-it-possible-to-navigate-to-the-specific-method-via-CoversMethod#focus=Comments-27-13552145.0-0
Обновил статью. Наглядная демонстрация того, что специализированная метка - рулит) И того, что PhpStorm разрабы не такие негодяи, как я иногда их пытаюсь представить) Что ж, мечты сбываются, был не прав, признаю!