Если не изменяет память, паттерн у GoF это многократно проверенный на практике шаблон реализации. Паттерн состоит из названия, проблемы, контекста, ограничений, решения и примеров кода.
Т.е. прежде чем советовать другим, они использовали их в реальных проектах. Но суть в том, что даже если проблема кажется похожей, но в другом контексте или с другими ограничениями, то паттерн смысла уже не имеет (ну или как минимум его использование нужно вдумчиво обосновать, а не копировать из книжки).
GoF писали текстовый редактор для десктопа и в нем черпали вдохновение. Понятно, что ни о каких микросервисах там речи не шло. Что работало в их ситуации, в другой может и не работать. Здесь нет противоречия.
Вместо pre-commit можно использовать prek https://github.com/j178/prek . Он с большего совместим, быстрее, запускает проверки параллельно, проще добавлять кастомные правила.
Во время когда GoF написали свою книжку возможности C++ и Java были куда скромнее. Паттерны фактически показывали способы как обходить типичные ограничения языка в парадигме ООП. С точки зрения современных языков они выглядят довольно низкоуровневыми. Ну и избыточными - зачем городить такой огород, когда всё уже есть из коробки? Наличие функций высшего порядка, генераторов и библиотеки абстрактных типов, как в python, даёт возможность просто писать код, не замечая, что у других тут могут быть какие-то особенные сложности.
По-моему ценность GoF больше в том, что они вдохновили других авторов по аналогии разбирать и искать типичные решения типичных проблем в своих областях. Книги, которые рассматривают не ООП, а различные архитектуры: Enterprise Integration Patterns, Reactive Design Patterns или Microservices Patterns были уже полезными.
Книжка была интересной как рефлексия опыта разработки тестового редактора на технологиях того времени. Авторы показали подход как находить некоторый класс эмпирических закономерностей в своем коде, документировать и возможно использовать в будущем. Но они совершенно не настаивали на том, чтобы их паттерны стали догмами и потом разработчики искали в каждой программе возможности для их тиражирования.
Рефлексия это интеллектуальный труд. Взять примеры из книжки - большого ума не надо. Новички часто хватаются за второе, как более простое, и начинает создавать синглтоны, потокобезопасные синглтоны, асинхронно инициализируемые синглтоны, универсальные синглтоны. Короче заниматься решением проблем, которые вообще не нужно создавать.
Уберите из лексикона все то, что не относится к решаемой задаче и вы получите именно то решение, которое будет легко понимать и сопровождать.
GoF была хорошей книжкой 20 лет тому назад. Но сейчас от неё толку не больше, чем от египетских иероглифов. Все полезные паттерны уже реализованы в самих языках, а вредные мирно покоятся в своих гробницах. Не надо их оттуда откапывать, там нет золота - только прах, кости и древние проклятия с граблями.
Пример пусть и не идеальный, но идеи Мартина вцелом полезные
По-моему, Мартин действует скорее как собиратель фольклора, публикуя чужие идеи под общей обложкой в своих сборниках разной премудрости. Как молодой программист, услышавший случайно на конференции про новый подход, кидается без разбора на слующий же день применить его в коде для продакшен, Мартин - пишет об этом статью и добавляет главу в очередную свою книгу в духе непререкаемой истины.
А вот обобщения и примеры он явно старается выдумывать сам. Но у него похоже мало контекста и практики в том, о чём хочет написать. Поэтому они получаются довольно пустыми, иногда до смешного.
Как я понял из оригинального поста, в тот год они серьёзно обновили движок, который до этого практически не менялся почти 10 лет. Поддержка VR стала одной из фич. Но для HL2 она не была целью, а скорее побочным эффектом. С HL2 они просто развлекались - запустится или нет. Для нормальной поддержки VR им бы пришлось изрядно дорабатывать уровни.
Пока ИИ не будет юридически признан субьектом права, все остальное лишь научная фантастика. Пометки AI generated для контента это тоже ни разу не про авторские права.
Проблема была же не в охраннике. Они хотели быстро-дешево подогреть хайп вокруг VR, выпустив по случаю адаптированную версию культовой игры. Но из этого кейса поняли, что одной лишь пересборкой все не ограничится - игру придётся тщательно тестировать заново и править подобные баги в коде или ресурсах. А это медленно-дорого. Учитывая низкую распространённость VR среди игроков и высокие репутационные риски в случае пропущенных багов, такая затея будет убыточной во всех смыслах.
От фанатских сборок ни кто особой стабильности изначально не ожидает. Запустилось и упало не сразу - все равно все будут довольны.
но при сборке ядра Debian я столкнулся с проблемой отсутствия одного файла при сборке. Как я понял, этого файла не было из-за лицензии
Ядро из исходников Debian пересобирается с родным конфигом без каких-либо изменений. Странно если было бы иначе.
Проблема с которой вы столкнулись, но неправильно интерпретировали, это лишь видимая часть айсберга. Посмотрите какие вообще патчи накатывает Debian на ядро.
Грызуны селятся в частных домах не только из-за еды. Там банально теплее и шансы встретить хищника исчезающе малы, что создает благоприятные условия для размножения. Бесплатная кормушка это скорее приятный бонус, чтобы не бегать лишний раз на улицу.
Anthropic утверждает: такой подход существенно повышает надёжность и помогает моделям работать над крупными задачами почти бесконечно — пока остаются фичи, которые надо реализовать.
В Debian, как и в большинстве других дистрибутивов Linux, ядро идёт с патчами. Поэтому конфиг ядра, стянутый из /boot/, не подойдёт к ванильным исходникам с kernel.org. Проще брать исходники ядра из дистрибутива, где все уже настроено. Хотя, там в инструкциях описаны разные сценарии сборки - включая и то как пропатчить ванильное ядро.
Если изменения касаются лишь отдельного драйвера, а не всего ядра, будет гораздо проще пересобирать только его - через DKMS.
Для отладки в QEMU, ему можно передать пути к кастомному ядру параметрами командной строки -kernel и -initrd. Таким образом можно обойтись без приседаний со сборкой имиджа и плясок вокруг grub2.
Если пользуетесь VSCode, для удобства можно настроить Devcontainer с Debian. Это избавит от возьни с docker и mount вручную.
А ревьюверы почему пропустили это и не развернули вернуть назад работающий код?
Код ревью это больше про социализацию разработчиков в команде и обмен знаниями. На ревью обычно не проверяют валидность самого решения - это ответственность автора. Оценивается общая адекватность и следование каким-то принятым в команде стандартам, которые сложно формализовать. По умолчанию считается, что специально лажу ни кто писать не будет. Ошибки выбиваются из общей канвы. Поэтому они хорошо заметны и ревью не отнимает много времени.
LLM хорошо следуют паттернам (особенно если они задокументированы), код на выходе смотрится стройно и убедительно. Но фактически может делать ерунду. Такие изменения ревьювать гораздо сложнее. Как если бы у вас в команде был злодей, который сознательно пытается всех запутать.
По хорошему, в отношении AI-generated кода нужно включать 0-trust режим, используя практики Security Code Review с чеклистами в сотню пунктов, - но это будет кратно дольше и дороже. А Cursor'ы ведь не для этого внедряют.
Все сильно зависит о того какой вопрос задать. Если спросить: какая самая длинная река в мире? отвечает - Амазонка. Что длиннее Амазонка или Нил? отвечает - Нил. Порядок вопросов не влияет на ответы.
-- Я умная колонка Алиса. Кажется у вас там что-то горит. Хотите купить ведро воды на Яндекс.Маркет, доставим послезавтра?
Если не изменяет память, паттерн у GoF это многократно проверенный на практике шаблон реализации. Паттерн состоит из названия, проблемы, контекста, ограничений, решения и примеров кода.
Т.е. прежде чем советовать другим, они использовали их в реальных проектах. Но суть в том, что даже если проблема кажется похожей, но в другом контексте или с другими ограничениями, то паттерн смысла уже не имеет (ну или как минимум его использование нужно вдумчиво обосновать, а не копировать из книжки).
GoF писали текстовый редактор для десктопа и в нем черпали вдохновение. Понятно, что ни о каких микросервисах там речи не шло. Что работало в их ситуации, в другой может и не работать. Здесь нет противоречия.
Вместо pre-commit можно использовать prek https://github.com/j178/prek . Он с большего совместим, быстрее, запускает проверки параллельно, проще добавлять кастомные правила.
mise, prek, poethepoet, uv, ruff, import-linter, basedpyright.
Во время когда GoF написали свою книжку возможности C++ и Java были куда скромнее. Паттерны фактически показывали способы как обходить типичные ограничения языка в парадигме ООП. С точки зрения современных языков они выглядят довольно низкоуровневыми. Ну и избыточными - зачем городить такой огород, когда всё уже есть из коробки? Наличие функций высшего порядка, генераторов и библиотеки абстрактных типов, как в python, даёт возможность просто писать код, не замечая, что у других тут могут быть какие-то особенные сложности.
По-моему ценность GoF больше в том, что они вдохновили других авторов по аналогии разбирать и искать типичные решения типичных проблем в своих областях. Книги, которые рассматривают не ООП, а различные архитектуры: Enterprise Integration Patterns, Reactive Design Patterns или Microservices Patterns были уже полезными.
Книжка была интересной как рефлексия опыта разработки тестового редактора на технологиях того времени. Авторы показали подход как находить некоторый класс эмпирических закономерностей в своем коде, документировать и возможно использовать в будущем. Но они совершенно не настаивали на том, чтобы их паттерны стали догмами и потом разработчики искали в каждой программе возможности для их тиражирования.
Рефлексия это интеллектуальный труд. Взять примеры из книжки - большого ума не надо. Новички часто хватаются за второе, как более простое, и начинает создавать синглтоны, потокобезопасные синглтоны, асинхронно инициализируемые синглтоны, универсальные синглтоны. Короче заниматься решением проблем, которые вообще не нужно создавать.
Уберите из лексикона все то, что не относится к решаемой задаче и вы получите именно то решение, которое будет легко понимать и сопровождать.
GoF была хорошей книжкой 20 лет тому назад. Но сейчас от неё толку не больше, чем от египетских иероглифов. Все полезные паттерны уже реализованы в самих языках, а вредные мирно покоятся в своих гробницах. Не надо их оттуда откапывать, там нет золота - только прах, кости и древние проклятия с граблями.
Дешевле снизу установить батут, показать обущающее видео персоналу как подпрыгивать и дать расписаться в журнале техники безопасности.
SOLID появился на 10 лет раньше этой книжки http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
По-моему, Мартин действует скорее как собиратель фольклора, публикуя чужие идеи под общей обложкой в своих сборниках разной премудрости. Как молодой программист, услышавший случайно на конференции про новый подход, кидается без разбора на слующий же день применить его в коде для продакшен, Мартин - пишет об этом статью и добавляет главу в очередную свою книгу в духе непререкаемой истины.
А вот обобщения и примеры он явно старается выдумывать сам. Но у него похоже мало контекста и практики в том, о чём хочет написать. Поэтому они получаются довольно пустыми, иногда до смешного.
Венгерский это один из самых сложных языков в мире. Но зачем другим-то голову морочить?
Как я понял из оригинального поста, в тот год они серьёзно обновили движок, который до этого практически не менялся почти 10 лет. Поддержка VR стала одной из фич. Но для HL2 она не была целью, а скорее побочным эффектом. С HL2 они просто развлекались - запустится или нет. Для нормальной поддержки VR им бы пришлось изрядно дорабатывать уровни.
Пока ИИ не будет юридически признан субьектом права, все остальное лишь научная фантастика. Пометки AI generated для контента это тоже ни разу не про авторские права.
Проблема была же не в охраннике. Они хотели быстро-дешево подогреть хайп вокруг VR, выпустив по случаю адаптированную версию культовой игры. Но из этого кейса поняли, что одной лишь пересборкой все не ограничится - игру придётся тщательно тестировать заново и править подобные баги в коде или ресурсах. А это медленно-дорого. Учитывая низкую распространённость VR среди игроков и высокие репутационные риски в случае пропущенных багов, такая затея будет убыточной во всех смыслах.
От фанатских сборок ни кто особой стабильности изначально не ожидает. Запустилось и упало не сразу - все равно все будут довольны.
Ядро из исходников Debian пересобирается с родным конфигом без каких-либо изменений. Странно если было бы иначе.
Проблема с которой вы столкнулись, но неправильно интерпретировали, это лишь видимая часть айсберга. Посмотрите какие вообще патчи накатывает Debian на ядро.
Грызуны селятся в частных домах не только из-за еды. Там банально теплее и шансы встретить хищника исчезающе малы, что создает благоприятные условия для размножения. Бесплатная кормушка это скорее приятный бонус, чтобы не бегать лишний раз на улицу.
или пока на балансе не кончатся деньги.
В эпоху стремления к тотальной автоматизации SDLC, эти формальности тоже будут пытаться автоматизировать, отдав на откуп нейронкам.
Вероятно я не до конца понял проблему, которую вы решали. На первый взгляд решение выгляит что-то слишком сложным.
Ядро Debian пересобирается буквально в несколько команд по штатной инструкции https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html.
В Debian, как и в большинстве других дистрибутивов Linux, ядро идёт с патчами. Поэтому конфиг ядра, стянутый из /boot/, не подойдёт к ванильным исходникам с kernel.org. Проще брать исходники ядра из дистрибутива, где все уже настроено. Хотя, там в инструкциях описаны разные сценарии сборки - включая и то как пропатчить ванильное ядро.
Если изменения касаются лишь отдельного драйвера, а не всего ядра, будет гораздо проще пересобирать только его - через DKMS.
Для отладки в QEMU, ему можно передать пути к кастомному ядру параметрами командной строки -kernel и -initrd. Таким образом можно обойтись без приседаний со сборкой имиджа и плясок вокруг grub2.
Если пользуетесь VSCode, для удобства можно настроить Devcontainer с Debian. Это избавит от возьни с docker и mount вручную.
Код ревью это больше про социализацию разработчиков в команде и обмен знаниями. На ревью обычно не проверяют валидность самого решения - это ответственность автора. Оценивается общая адекватность и следование каким-то принятым в команде стандартам, которые сложно формализовать. По умолчанию считается, что специально лажу ни кто писать не будет. Ошибки выбиваются из общей канвы. Поэтому они хорошо заметны и ревью не отнимает много времени.
LLM хорошо следуют паттернам (особенно если они задокументированы), код на выходе смотрится стройно и убедительно. Но фактически может делать ерунду. Такие изменения ревьювать гораздо сложнее. Как если бы у вас в команде был злодей, который сознательно пытается всех запутать.
По хорошему, в отношении AI-generated кода нужно включать 0-trust режим, используя практики Security Code Review с чеклистами в сотню пунктов, - но это будет кратно дольше и дороже. А Cursor'ы ведь не для этого внедряют.
Все сильно зависит о того какой вопрос задать. Если спросить: какая самая длинная река в мире? отвечает - Амазонка. Что длиннее Амазонка или Нил? отвечает - Нил. Порядок вопросов не влияет на ответы.