Выглядит больше как рекламная партнерка с сервисом. Куча огромных банеров в каждой статье. Кто ж даст ее отключать?
Чисто технически опоздали с фишкой на год (может целый год пилили?). Сейчас ассистент, встроенный в браузер, справляется с этой задачей гораздо лучше - он и объяснит если нужно, и саммари напишет, и найдет похожее, и все это делает без лишнего шума на странице. Зачем нужно это вообще не понятно.
FIDO2 сам по себе не мешает привязать к одной учетке несколько девайсов - этот вопрос уровнем выше. Плюс там есть вариации, где ключи извлекаемые, а так же поддерживается синхронизация ключей между несколькими девайсами (удобно же). UX до сих пор отпугивает неподготовленных пользователей. Но мошенник убалтывает жертву добавить в учетку свой девайс и все мучения идут на смарку.
Я не спорю, это огромный шаг вперёд, по сравнению со всем остальным. Но одно дело внедрение в корпоративной среде, где вы можете многое контролировать. И совершенно иное - сервис уровня Госуслуг, который должен быть доступен самому широкому кругу граждан. Это сложная задача.
должен быть реальный "железный" ключ (в идеале карта-доступа). который владелец физически держит в руках при авторизации, и который удаленно по телефону никак не передашь мошеннику.
Есть Passkeys, в варианте с неизвлекаемыми ключами, в том числе для Android и iOS. Но таких пользователей тоже разводят, вынуждая привязать к своей учетке чужой девайс.
Закрывали глаза, пока деньги уходили непонятно куда: самивиноваты теперь должны до конца жизни и ещё больше вкалывают, банки в плюсе, государству - налоги. Win-win. Триггернуло видимо когда в слив в отдельных направлениях стал сильно нежелательным.
сначала осваиваются нематериальные стимулы. И только потом, точечно, добавляются материальные
Стимулы это такие краники, которые открываясь вызывают ощущение неудовлетворенности.
Материальное стимулирование это не про выплату премий или бонусов (выплаты это ответ). Это про создание ощущения неудовлетворенности в материальном плане. Сама по себе премия это не стимул. Стимул это отсутствие премии весь следующий период.
Я не думаю, что нужно отказаться от материального стимулирования со старта. В конце-концов все работники приходят из-за денег. Кран открыт до конца, вызывая перманентный зуд, который на дает сосредоточиться на главном. Поэтому короткая success story поначалу необходима. Иначе у них не будет надежды, вам ни кто не поверит, все разбегутся ещё до окончания испытательного срока. Но потом, с каждой новой итерацией, ответ сдвигается все дальше по времени. А промежутки заполняются собственно работой, которая подкидывает работникам в качестве стимулов уже ваши собственные бизнесовые проблемы, отвечая в виртуальными призами. Что только усиливает материальный стимул.
Я пробовал уйти с JScript на VBScript - там доступ к COM объектам выглядел удобнее. Но в нем небыло функций высшего порядка, замыканий и вроде какие-то заморочки с регулярками. В итоге не срослось.
Если не изменяет память, паттерн у 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 среди игроков и высокие репутационные риски в случае пропущенных багов, такая затея будет убыточной во всех смыслах.
От фанатских сборок ни кто особой стабильности изначально не ожидает. Запустилось и упало не сразу - все равно все будут довольны.
Выглядит больше как рекламная партнерка с сервисом. Куча огромных банеров в каждой статье. Кто ж даст ее отключать?
Чисто технически опоздали с фишкой на год (может целый год пилили?). Сейчас ассистент, встроенный в браузер, справляется с этой задачей гораздо лучше - он и объяснит если нужно, и саммари напишет, и найдет похожее, и все это делает без лишнего шума на странице. Зачем нужно это вообще не понятно.
FIDO2 сам по себе не мешает привязать к одной учетке несколько девайсов - этот вопрос уровнем выше. Плюс там есть вариации, где ключи извлекаемые, а так же поддерживается синхронизация ключей между несколькими девайсами (удобно же). UX до сих пор отпугивает неподготовленных пользователей. Но мошенник убалтывает жертву добавить в учетку свой девайс и все мучения идут на смарку.
Я не спорю, это огромный шаг вперёд, по сравнению со всем остальным. Но одно дело внедрение в корпоративной среде, где вы можете многое контролировать. И совершенно иное - сервис уровня Госуслуг, который должен быть доступен самому широкому кругу граждан. Это сложная задача.
Есть Passkeys, в варианте с неизвлекаемыми ключами, в том числе для Android и iOS. Но таких пользователей тоже разводят, вынуждая привязать к своей учетке чужой девайс.
Закрывали глаза, пока деньги уходили непонятно куда: самивиноваты теперь должны до конца жизни и ещё больше вкалывают, банки в плюсе, государству - налоги. Win-win. Триггернуло видимо когда в слив в отдельных направлениях стал сильно нежелательным.
А убрать доменные пароли, оставив только password-less аутентификацию? Технически сейчас это доступно.
Стимулы это такие краники, которые открываясь вызывают ощущение неудовлетворенности.
Материальное стимулирование это не про выплату премий или бонусов (выплаты это ответ). Это про создание ощущения неудовлетворенности в материальном плане. Сама по себе премия это не стимул. Стимул это отсутствие премии весь следующий период.
Я не думаю, что нужно отказаться от материального стимулирования со старта. В конце-концов все работники приходят из-за денег. Кран открыт до конца, вызывая перманентный зуд, который на дает сосредоточиться на главном. Поэтому короткая success story поначалу необходима. Иначе у них не будет надежды, вам ни кто не поверит, все разбегутся ещё до окончания испытательного срока. Но потом, с каждой новой итерацией, ответ сдвигается все дальше по времени. А промежутки заполняются собственно работой, которая подкидывает работникам в качестве стимулов уже ваши собственные бизнесовые проблемы, отвечая в виртуальными призами. Что только усиливает материальный стимул.
Я пробовал уйти с JScript на VBScript - там доступ к COM объектам выглядел удобнее. Но в нем небыло функций высшего порядка, замыканий и вроде какие-то заморочки с регулярками. В итоге не срослось.
-- Я умная колонка Алиса. Кажется у вас там что-то горит. Хотите купить ведро воды на Яндекс.Маркет, доставим послезавтра?
Если не изменяет память, паттерн у 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 среди игроков и высокие репутационные риски в случае пропущенных багов, такая затея будет убыточной во всех смыслах.
От фанатских сборок ни кто особой стабильности изначально не ожидает. Запустилось и упало не сразу - все равно все будут довольны.