Коллеги, позвольте уточнить: речь фактически идёт о сборе биометрических данных пользователя. То есть пользователь должен согласиться с передачей биометрии, а согласно последним веяниям регулятора вы не можете отказать в сервисе пользователю, который не даст вам согласие на обработку биометрии. Как решается эта коллизия?
Известны и опубликованы процедуры бандлинга своего рут СА в ОС/браузеры. Технической сложности в них нет.
Вообще говоря выходит, что условный регру или любой другой отечественный провайдер не захотел/не смог пройти бюрократические процедуры - и вот это интересно было бы почитать почему.
Не разжигания для, но любопытства ради. Почему бы наконец какому-нибудь рег.ру не стать нормальным корневым CA и не развернуть продажу клиентских сертификатов вплоть до EV?
Мне кажется, Вы возводите один конкретный документ — ПМИ в данном случае — в абслют. Да, в рамках ПМИ принимаются не только фичи, но и комплектность системы (в т.ч. документации), а так же могут проверяться такие вещи как квалификация операторов и выполнение развертывания согласно проекту. Но не надо тащить в ПМИ процесс, для этого есть другие хорошие документы и регламенты.
И про "долго" речи тоже не шло. Если выполнение процесса, предусматривающего помимо поставки кода поставку бумаги — долго, это не проблема бумаги. Это другая проблема.
ГОСТ 34, вокруг которого весь сыр-бор чрезвычайно зануден, дотошен и громоздок для любого, кто попытается применить его ради применения стандарта. Причем степень его занудности зачастую ниже, чем, например, степень занудности общеотраслевых стандартов типа ITIL. Все же, применять стандарты к себе и у себя нужно для удовлетворения своим внутренним требованиям в первую очередь, а не ради удовлетворения стандарта. Иначе можно и лоб расшибить. Но это все равно не проблема стандарта. :)
Нет, увы. Устойчивость к регрессам — не фича в общем смысле. Вы можете создать или заказать ИС, устойчивую к регрессам и такую устойчивость можно даже, наверняка, математически доказать.
В общем же смысле, ИС любого прикладного назначения, включающая в себя АРМ и живого человека в роли оператора, за АРМ сидящего, не может быть "сама по себе" устойчива к регрессу, да ей и не надо. Потому что заказывая доработку "валидация формы" Вы вносите изменение в существующее ТЗ на систему. Предполагается, что исполнитель снимет с Вас требования, отразит в ТЗ и обновит сообразным образом ПМИ и прочую документацию по ИС. И по итогу разработки это будет уже новая версия ИС, которую, опять таки, надо принять в соответствии с ПМИ.
Если же вы приняли ИС и пакет сопроводительной документации, ввели ее в эксплуатацию, а затем попросили инженера Васю "быстренько воткнуть вот сюда проверку введенного значения", реализация которой привела к таймаутам на интерфейсах АРМ из-за дурацких и тяжелых запросов к БД — это не проблема "забюрократизированности" подхода или "тяжести" документации. Это другая проблема.
ПМИ все же не гарант отсутствия регрессий, это неверное толкование. ПМИ должна, и вроде у нее получается, гарантировать работоспособность сдаваемой заказчику версии ИС согласно требований заказчика. Или как предлагается это делать иначе?
Красиво, руки почти что потянулись попытаться воспроизвести и сунуть в мониторинг. Но нет — не хорошо, когда в черную магию умеет кто-то один, а поддерживать ее — другим.
Нет ли заходов попроще? Пусть с меньшей точностью, но способных явно указать "эту таблу пора пересобрать"?
putty-nd
Остальное под виндой совершенно не оно, потому что, как правило, какого-нибудь хоткея нет: либо открытия нового таба, либо клонирования сессии активного в новый таб.
Претензия автора состоит в том, что падение CTR аффектит бизнесы, для которых есть Я-аналоги. Ваш пример не самый удачный, все же.
В chrome можно ввести в адресной строке "tra слово" и получить перевод от google translate.
Нельзя ли привести конкретных примеров кейсов "фирма А в нише Б вытеснена колдунщиком В"?
Пока что, на примерах автомобилей, пылесосов и билетов, картина не складывается: в среднем пользователь не хочет иметь дело с ООО "Рога и Копыта" в данных вопросах. Пользователь хочет либо проверенный агрегатор, либо прямого продавца. Конкретный театр и конкретный перевозчик в конкретном регионе, оба найденные через проверенный агрегатор — ок.
С одной стороны, кажется, Вы изобрели стори поинты. С другой стороны, приведенный пример задачи и декомпозиции в решение вот так с наскоку выглядит архитектурным ужасом. Надеюсь, это просто пример плохой. :)
А какова вероятность, что скорость доступа к дискам будет сопоставима с wsl1? Ато неуютно как-то, поезд пошел вперёд, а ты сидишь на старье просто потому что тебе нужен быстрый доступ к файлам хоста. :)
Для ленты.ру и "общих" ресурсов альтернатива аналитике и баннерной рекламе давно известна — членский взнос, он же подписка. Но, кажется, эта альтернатива не устраивает массового пользователя.
Аналогия с разбоем, все же, не уместна. Куки нужны аналитике не для того, чтобы забрать ваши деньги, а лишь для того, чтобы на вас посмотреть. Опять же, никто не спорит с тем, что эту технологию зачастую используют для иных целей. И вопрос должен, в идеальном случае, ставиться несколько иначе: может ли быть технология, которая позволит магазину смотреть на аудиторию, но затруднит неправомерное использование данных?
GDPR, вроде, оффлайн процессы не регламентирует. :)
А онлайн магазин стоит перед выбором: если спрашивать у каждого посетителя разрешения на аналитику — конверсия, вероятнее всего, погибнет. Если не спрашивать — юридические риски. Пока что плашки "продолжая просматривать сайт вы соглашаетесь..." работают. Надолго ли?..
Коллеги, позвольте уточнить: речь фактически идёт о сборе биометрических данных пользователя. То есть пользователь должен согласиться с передачей биометрии, а согласно последним веяниям регулятора вы не можете отказать в сервисе пользователю, который не даст вам согласие на обработку биометрии. Как решается эта коллизия?
Вопрос был не про то. :)
Известны и опубликованы процедуры бандлинга своего рут СА в ОС/браузеры. Технической сложности в них нет.
Вообще говоря выходит, что условный регру или любой другой отечественный провайдер не захотел/не смог пройти бюрократические процедуры - и вот это интересно было бы почитать почему.
А в чем, собственно, проблема?
Программы MS/Apple в открытом доступе с условиями, политическую ситуацию в расчет не берём в силу переменчивости.
Не разжигания для, но любопытства ради. Почему бы наконец какому-нибудь рег.ру не стать нормальным корневым CA и не развернуть продажу клиентских сертификатов вплоть до EV?
Мне кажется, Вы возводите один конкретный документ — ПМИ в данном случае — в абслют. Да, в рамках ПМИ принимаются не только фичи, но и комплектность системы (в т.ч. документации), а так же могут проверяться такие вещи как квалификация операторов и выполнение развертывания согласно проекту. Но не надо тащить в ПМИ процесс, для этого есть другие хорошие документы и регламенты.
И про "долго" речи тоже не шло. Если выполнение процесса, предусматривающего помимо поставки кода поставку бумаги — долго, это не проблема бумаги. Это другая проблема.
ГОСТ 34, вокруг которого весь сыр-бор чрезвычайно зануден, дотошен и громоздок для любого, кто попытается применить его ради применения стандарта. Причем степень его занудности зачастую ниже, чем, например, степень занудности общеотраслевых стандартов типа ITIL. Все же, применять стандарты к себе и у себя нужно для удовлетворения своим внутренним требованиям в первую очередь, а не ради удовлетворения стандарта. Иначе можно и лоб расшибить. Но это все равно не проблема стандарта. :)
Нет, увы. Устойчивость к регрессам — не фича в общем смысле. Вы можете создать или заказать ИС, устойчивую к регрессам и такую устойчивость можно даже, наверняка, математически доказать.
В общем же смысле, ИС любого прикладного назначения, включающая в себя АРМ и живого человека в роли оператора, за АРМ сидящего, не может быть "сама по себе" устойчива к регрессу, да ей и не надо. Потому что заказывая доработку "валидация формы" Вы вносите изменение в существующее ТЗ на систему. Предполагается, что исполнитель снимет с Вас требования, отразит в ТЗ и обновит сообразным образом ПМИ и прочую документацию по ИС. И по итогу разработки это будет уже новая версия ИС, которую, опять таки, надо принять в соответствии с ПМИ.
Если же вы приняли ИС и пакет сопроводительной документации, ввели ее в эксплуатацию, а затем попросили инженера Васю "быстренько воткнуть вот сюда проверку введенного значения", реализация которой привела к таймаутам на интерфейсах АРМ из-за дурацких и тяжелых запросов к БД — это не проблема "забюрократизированности" подхода или "тяжести" документации. Это другая проблема.
О каких правках идёт речь? Изменения функционала — суть изменения ТЗ и должны разрабатываться, сдаваться и приниматься потребителем явно.
А если система валится от пользовательского ввода — это не проблема процесса ведения документации, это другая проблема.
ПМИ все же не гарант отсутствия регрессий, это неверное толкование. ПМИ должна, и вроде у нее получается, гарантировать работоспособность сдаваемой заказчику версии ИС согласно требований заказчика. Или как предлагается это делать иначе?
А можете, пожалуйста, примеров привести?
Вы не понимаете зачем нужна документация ПМИ? Или не можете автоматизировать создание паспорта системы?
На десятках миллионов строк, кажется, когда случится reltuples > relpages — это уже ну прям совсем поздно. :)
Красиво, руки почти что потянулись попытаться воспроизвести и сунуть в мониторинг. Но нет — не хорошо, когда в черную магию умеет кто-то один, а поддерживать ее — другим.
Нет ли заходов попроще? Пусть с меньшей точностью, но способных явно указать "эту таблу пора пересобрать"?
putty-nd
Остальное под виндой совершенно не оно, потому что, как правило, какого-нибудь хоткея нет: либо открытия нового таба, либо клонирования сессии активного в новый таб.
Претензия автора состоит в том, что падение CTR аффектит бизнесы, для которых есть Я-аналоги. Ваш пример не самый удачный, все же.
В chrome можно ввести в адресной строке "tra слово" и получить перевод от google translate.
Нельзя ли привести конкретных примеров кейсов "фирма А в нише Б вытеснена колдунщиком В"?
Пока что, на примерах автомобилей, пылесосов и билетов, картина не складывается: в среднем пользователь не хочет иметь дело с ООО "Рога и Копыта" в данных вопросах. Пользователь хочет либо проверенный агрегатор, либо прямого продавца. Конкретный театр и конкретный перевозчик в конкретном регионе, оба найденные через проверенный агрегатор — ок.
А как же git push +?
А теперь они изобрели awstat.
С одной стороны, кажется, Вы изобрели стори поинты. С другой стороны, приведенный пример задачи и декомпозиции в решение вот так с наскоку выглядит архитектурным ужасом. Надеюсь, это просто пример плохой. :)
А какова вероятность, что скорость доступа к дискам будет сопоставима с wsl1? Ато неуютно как-то, поезд пошел вперёд, а ты сидишь на старье просто потому что тебе нужен быстрый доступ к файлам хоста. :)
Для ленты.ру и "общих" ресурсов альтернатива аналитике и баннерной рекламе давно известна — членский взнос, он же подписка. Но, кажется, эта альтернатива не устраивает массового пользователя.
Аналогия с разбоем, все же, не уместна. Куки нужны аналитике не для того, чтобы забрать ваши деньги, а лишь для того, чтобы на вас посмотреть. Опять же, никто не спорит с тем, что эту технологию зачастую используют для иных целей. И вопрос должен, в идеальном случае, ставиться несколько иначе: может ли быть технология, которая позволит магазину смотреть на аудиторию, но затруднит неправомерное использование данных?
GDPR, вроде, оффлайн процессы не регламентирует. :)
А онлайн магазин стоит перед выбором: если спрашивать у каждого посетителя разрешения на аналитику — конверсия, вероятнее всего, погибнет. Если не спрашивать — юридические риски. Пока что плашки "продолжая просматривать сайт вы соглашаетесь..." работают. Надолго ли?..