Судя по фразе - Вы про аутентификацию ради авторизации. Т.е. тот вариант, где Вы используете лицо для оплаты в кафе, прохода через турникет и т.п. Там, где вы хотите быть уверены, что деньги спишутся с Вашей карты только при личной аутентификации, или в дом не проберется чужой.
Тут нужно понимать, что ключ - это Ваше лицо. Система же создает и хранит у себя "замок-отпечаток". Причем каждая создает его по своему - процесс глубокого обучения не стандартизирован (и не может) - а значит и применяет, при визите, Ваш ключ к собственному нестандартному "замку", также, по особенному.
Но допустим, что кто-то украл такой замок и вместе с ним и всю систему (иначе он бессмысленен).
Что произойдет дальше? Злоумышленник повесит его на дверь, которая была для вас закрыта и теперь Вы сможете ее открыть? Может проще было и не закрывать?
Есть другое применение - использовать "отпечатки" лиц для распознавания там, где нет дверей, чтобы найти человека в толпе, например.
Но с изобретением фотографии, т.е уже давно, получить "лицо" не сложно, и предотвратить злоупотребление таким сценарием можно только договорившись (запретив законом). Сопоставлять каждое лицо в толпе миллионам отпечатков - также (пока) достаточно затратная задача без внятного применения (но надо признать, что теперь стенд "Их разыскивают" может иметь гигантские размеры, да).
В любом случае, для такой системы не нужны непонятные ей замки сторонних производителей, проще, быстрее (миллисекунды) и надежнее создать свой вариант, имея обыкновенное фото в дополнение к интересующей создателей, по контексту, информации.
Но безопасность хранения любых данных - вопрос архиважный, это бесспорно.
Спасибо за саму попытку провести мысленный эксперимент, редкость ныне.
Меж тем, идеи для заголовков и таблиц — окупили все затраты.
Два замечания:
Где-то символ-идентификатор должен быть отбит пробелом, где-то (в инлайновых) — нет. Может просто принять, что маркер — это два "редких" символа подряд?
Преформатированный текст в инлайне, если будет определяться двумя пробелами, также будет очень ·сложно заметить· среди тысячи разрывов. В том числе и два ошибочных пробела. Может поискать дополнительные сочетания, например: ::?
Возможно. Но про "ситуацию резко ухудшает" — мне кажется мы читаем разные статьи.
Я вижу, что человек не дал прерваться круглосуточной жизни завода.
Даже поняв, что проиграл "вглухую" все партии "высшим" силам.
Естественно, программист ходил с этой информацией к руководителю, и не раз. Естественно, слушать его никто не стал. Поэтому программист вошёл в жесточайший цейтнот. С одной стороны, необходимо было обеспечить текущую работу системы. С другой стороны, потихоньку, насколько хватало времени, пытался всё это починить. Завод работал круглосуточно.
P.S. Программист был рад, что его уволили. Сам не уходил, потому что чувствовал ответственность, или даже гиперответственность за происходящее на заводе.
Я верю, что люди могут чувствовать гиперответственность
Я могу объяснить такой подход.
Программист работал не на дядю, а на Завод. Завод тоже живой (как и любое другое предприятие) и бывает так, что некоторые люди чувствуют ответственность за "чужую" жизнь.
Мое решение — писать данные (события) в ациклический направленный граф, а состояния получать по срезам графа.
Интересно, в каком виде Вы храните такой граф?
Например, у нас получилось все хранить в графовой базе и такой граф у нас содержит как "действия" (один "документ" порождает другой и документы меняют через действия "регистры", моделирующие "срезы" состояний), так и "семантико/онтологическую" связь сущностей, например "Страна состоит из регионов" или "Год содержит квартал". Больше того, так как каждый вид связи-действия и связи-"онтологии" могут характеризовать доступность для конкретного пользователя (кабинета), через такой ациклический граф мы можем, также, моделировать систему доступа. Есть правила для перехода по видам связей: семантические связи (отношения справочников) доступны всем; связь-действие доступна тому, кто ее произвел; связь "имеет доступ"; обратное направление связи "передал в" и т.п.) и если от конкретного кабинета к ресурсу имеется непрерывный путь "разрешающих" связей, то данный ресурс доступен данному кабинету.
Идеи хорошие, не новые (фактически, описывается стандартное делопроизводство/документооборот). Скажите, а Вы применяете такой подход при создании систем? Ведь главная проблема — как правильно выводить состояние на основе "действий".
Мы, например, в качестве "source of truth" использовали графовые базы где-то с 2012. Event-sourcing и materialized view (Apache Samza, как пример) — еще один и, видимо, более модный вариант.
По поводу первого — соглашусь полностью. Ключевое, кстати — отсутствие слова "должен" и наличие слова "удобен".
По второму пункту — я, видимо, не верю в методики как в единственно правильные алгоритмы поведения, дающие гарантированный результат. Я, даже в инструктаже компьютера не верю в единственный универсальный алгоритм, что уж говорить о сообществах.
Для меня BDD — одна из удобных эвристик, ценность которой не самодостаточна, но может быть очень высокой в каком-то конкретном случае.
Т.е. если прописанный программистом по такой схеме сценарий (или несколько) поможет бизнесу увидеть свои же требования в более чистом и понятном виде — уже хорошо. Есть шанс найти общий язык.
Если получится договориться и пере(на)писать большую часть важных моментов в таком виде — отлично! Тем более, что, как бонус, программист, отредактировав и вернув требования на согласование взаимного понимания с заказчиком, фактически уже написал и код для проверки этих требований.
Так что и со вторым пунктом соглашусь, но замечу, что "договоренности" для людей, а не люди для договоренностей.
BDD дорог и неудобен исключительно тем, что его нужно поддерживать — переводить тесты с естественного языка в код.
Мне всегда казалось, что BDD удобен как-раз тем, что заставляет сначала более-менее человеческим языком описать сценарий, а код теста получается уже как следствие редактирования сценария программистом. И что важно — до программирования кода реализации.
Никак не хочу комментировать текст самой статьи. Но вот такие безапелляционные сообщения мне всегда "нравилилсь". Благо недостатка в них нет и даже наоборот.
Посмотрел по первой ссылке. Не вижу, где предположения автора противоречат результатам даже таких, косвенно относящихся к "прогнозированию будущего", исследований.
"Услуги переводчика на китайский язык" — работает по настоящему.
Настолько мощная штука, что я не замечал содержания всей остальной полосы (и всего контекста, несмотря на отсылку к 1 апреля) еще секунд 20.
Да, прошу прощения, личная аутентификация = личное присутствие.
По поводу остального - прошу Вас не беспокоиться. Аллегории. Адресованные не Вашему вниманию.
Судя по фразе - Вы про аутентификацию ради авторизации. Т.е. тот вариант, где Вы используете лицо для оплаты в кафе, прохода через турникет и т.п. Там, где вы хотите быть уверены, что деньги спишутся с Вашей карты только при личной аутентификации, или в дом не проберется чужой.
Тут нужно понимать, что ключ - это Ваше лицо. Система же создает и хранит у себя "замок-отпечаток". Причем каждая создает его по своему - процесс глубокого обучения не стандартизирован (и не может) - а значит и применяет, при визите, Ваш ключ к собственному нестандартному "замку", также, по особенному.
Но допустим, что кто-то украл такой замок и вместе с ним и всю систему (иначе он бессмысленен).
Что произойдет дальше? Злоумышленник повесит его на дверь, которая была для вас закрыта и теперь Вы сможете ее открыть? Может проще было и не закрывать?
Есть другое применение - использовать "отпечатки" лиц для распознавания там, где нет дверей, чтобы найти человека в толпе, например.
Но с изобретением фотографии, т.е уже давно, получить "лицо" не сложно, и предотвратить злоупотребление таким сценарием можно только договорившись (запретив законом). Сопоставлять каждое лицо в толпе миллионам отпечатков - также (пока) достаточно затратная задача без внятного применения (но надо признать, что теперь стенд "Их разыскивают" может иметь гигантские размеры, да).
В любом случае, для такой системы не нужны непонятные ей замки сторонних производителей, проще, быстрее (миллисекунды) и надежнее создать свой вариант, имея обыкновенное фото в дополнение к интересующей создателей, по контексту, информации.
Но безопасность хранения любых данных - вопрос архиважный, это бесспорно.
Круто!
А какова будет себестоимость (без затрат на R&D) при более-менее крупной партии?
Надеюсь найдутся инвесторы, которые помогут довести до ума и вывести рынок.
Автор приводит Golang как пример, речь вот об этом:
https://dave.cheney.net/practical-go/presentations/qcon-china.html#_identifiers
Внятный доклад, соответствующий, кстати, критериям в нем описанным.
И первые же комментарии: "много букв...".
"Кошелек Миллера" худеет. ;)
Спасибо за саму попытку провести мысленный эксперимент, редкость ныне.
Меж тем, идеи для заголовков и таблиц — окупили все затраты.
Два замечания:
::?конечно не словарь, но переводчик deepl.com
Я не буду фантазировать, встал ли завод после его ухода, продолжил бы завод работать, если бы человек не пытался решить проблему на месте.
Понял одно — Вы бы его уволили. Надеюсь, что когда-нибудь у Вас будет такая возможность.
Возможно. Но про "ситуацию резко ухудшает" — мне кажется мы читаем разные статьи.
Я вижу, что человек не дал прерваться круглосуточной жизни завода.
Даже поняв, что проиграл "вглухую" все партии "высшим" силам.
Я верю, что люди могут чувствовать гиперответственность
Я могу объяснить такой подход.
Программист работал не на дядю, а на Завод. Завод тоже живой (как и любое другое предприятие) и бывает так, что некоторые люди чувствуют ответственность за "чужую" жизнь.
Цитировался герой Тургенева, но к спору об образовании это отношения не имеет, конечно-же ;)
Интересно, в каком виде Вы храните такой граф?
Например, у нас получилось все хранить в графовой базе и такой граф у нас содержит как "действия" (один "документ" порождает другой и документы меняют через действия "регистры", моделирующие "срезы" состояний), так и "семантико/онтологическую" связь сущностей, например "Страна состоит из регионов" или "Год содержит квартал". Больше того, так как каждый вид связи-действия и связи-"онтологии" могут характеризовать доступность для конкретного пользователя (кабинета), через такой ациклический граф мы можем, также, моделировать систему доступа. Есть правила для перехода по видам связей: семантические связи (отношения справочников) доступны всем; связь-действие доступна тому, кто ее произвел; связь "имеет доступ"; обратное направление связи "передал в" и т.п.) и если от конкретного кабинета к ресурсу имеется непрерывный путь "разрешающих" связей, то данный ресурс доступен данному кабинету.
Идеи хорошие, не новые (фактически, описывается стандартное делопроизводство/документооборот). Скажите, а Вы применяете такой подход при создании систем? Ведь главная проблема — как правильно выводить состояние на основе "действий".
Мы, например, в качестве "source of truth" использовали графовые базы где-то с 2012. Event-sourcing и materialized view (Apache Samza, как пример) — еще один и, видимо, более модный вариант.
Да, ну из моего опыта — если нет чувства "балансирования" — скорее всего — ты и не двигаешься, а стоишь, приперевшись к стенке ;)
По поводу первого — соглашусь полностью. Ключевое, кстати — отсутствие слова "должен" и наличие слова "удобен".
По второму пункту — я, видимо, не верю в методики как в единственно правильные алгоритмы поведения, дающие гарантированный результат. Я, даже в инструктаже компьютера не верю в единственный универсальный алгоритм, что уж говорить о сообществах.
Для меня BDD — одна из удобных эвристик, ценность которой не самодостаточна, но может быть очень высокой в каком-то конкретном случае.
Т.е. если прописанный программистом по такой схеме сценарий (или несколько) поможет бизнесу увидеть свои же требования в более чистом и понятном виде — уже хорошо. Есть шанс найти общий язык.
Если получится договориться и пере(на)писать большую часть важных моментов в таком виде — отлично! Тем более, что, как бонус, программист, отредактировав и вернув требования на согласование взаимного понимания с заказчиком, фактически уже написал и код для проверки этих требований.
Так что и со вторым пунктом соглашусь, но замечу, что "договоренности" для людей, а не люди для договоренностей.
Мне всегда казалось, что BDD удобен как-раз тем, что заставляет сначала более-менее человеческим языком описать сценарий, а код теста получается уже как следствие редактирования сценария программистом. И что важно — до программирования кода реализации.
Практически на этом же стеке, практически с таким же подходом, мы практически ;) создали продукт для цифровизации другого государства в 2015 году.
Голосую за продолжение серии статей!
Никак не хочу комментировать текст самой статьи. Но вот такие безапелляционные сообщения мне всегда "нравилилсь". Благо недостатка в них нет и даже наоборот.
Посмотрел по первой ссылке. Не вижу, где предположения автора противоречат результатам даже таких, косвенно относящихся к "прогнозированию будущего", исследований.
"Услуги переводчика на китайский язык" — работает по настоящему.
Настолько мощная штука, что я не замечал содержания всей остальной полосы (и всего контекста, несмотря на отсылку к 1 апреля) еще секунд 20.
Посмотрел, Gayle Laakmann McDowell продолжала дискутировать. Пара развернутых комментариев, действительно, стоят того, чтобы их добавить.