Для владельцев сайтов капча — просто подключаемый сервис.
Мы же обсуждаем разработку капчи, а не людей, которые подключают сторонний сервис.
То-то в почтовых сервисах Гугла и Яндекса над этим работают целые отделы
Всё-таки для почты эта задача мне кажется сложнее, чем для сайтов. Да и справляются фильтры сегодня весьма хорошо. И с капчой есть «заметный процент промахов и ложных срабатываний». Если точнее — капча справляется гораздо хуже.
Я о том и говорю, что когда-то это было нормальным решением. Но если сейчас капча требует того же ИИ для её создания и доставляет настоящую боль пользователям, то нужно вернуться к изначальной задаче и подумать ещё раз. Для распознавания спама сильный ИИ не нужен. Задача явно не сложнее создания спама. Начнём с того, что у нас изначально есть очень хороший признак для классификации текстов — наличие URL'а. 80% результата уже достигнуто. Дальше уже тренируйте нейронные сети и прочее.
Почему бы не направить усилия на распознавание зловреда вместо того, чтобы мучить людей решением ваших проблем? В статье много написано про выкрутасы с ИИ. Но распознавание спама выглядит куда более простой задачей для ИИ. И обойти защиту значительно сложнее, чем распознавать любую капчу, потому что текст должен быть рекламным. По-моему, это очередной пример, когда настоящую задачу подменяют какой-то технической мурой.
Большое спасибо за подробное разъяснение. Я предполагал, что хуки могут запоминать порядок вызова, но решил, что это и правда слишком нелепо.) Выходит, что решения для передачи колбека в цикле по-прежнему нет. На проблему просто забивают. Ждите пока начнутся тормоза, а потом делайте уродливый компонент-прослойку, передающий в колбек дополнительный параметр. Т.е. самый простой код уже по умолчанию имеет потенциальные проблемы с производительностью. Мир сошёл с ума.
Что если в одной рендер-функции определяются несколько разных колбеков. Переданные массивы могут совпасть и последствия будут ужасны.) Или я чего-то не понимаю?
Не хочется нахватать минусов, но просто не могу сдержаться.
Зачем? Зачем вы едите этот кактус? Как этот ворох костылей мог стать мейнстримом?
Мне повезло, я столкнулся с проблемой переопределения колбеков в самом начале знакомства с React. Больше всего меня поразило, что эта проблема никого особо не волнует. Ок, разработчики Реакта наконец выдали какое-то решение. Но ведь это же редкое уродство. Во второй аргумент useCallback ещё нужно добавить какой-нибудь идентификатор, чтобы мемоизировать несколько разных колбеков. Мемоизатор скорее всего будет жрать память. Всё это громоздко и неудобно.
Конечно, кроме мемоизации другого решения и не найти, если колбек передаётся в цикле. Почему не признать, что подходы Реакта тупиковые? Нет, продолжают костылять: «In the future, a sufficiently advanced compiler could create this array automatically.» А может пора отбросить попытки эмулировать декларативность императивщиной и использовать нормальный DSL?
Удивительнее то, насколько Дерби опередил своё время. 4 года стагнации, а фреймворк остаётся одной из лучших технологий. Весь веб-дев зигзагами плетётся примерно в том же направлении, не видя конечную цель и не понимая, что она уже давно была достигнута.
Последние 5 лет я работал с Дерби. Было много набитых шишек и боли. Постоянно сомневался, не стоит ли вернутся к более трендовым технологиям. Два месяца назад пришлось начать работать с Реактом. До сих пор шокирован, насколько в трендах всё не лучше. Столько хайпа вокруг React+Redux — а никаких Best Practice точно также нет. В тоннах статей описывают решения только примитивнейших задач. И даже при этом решения имеют явные проблемы. В итоге на многих современных сайтах всё скачет при загрузке, не работает нормально Browser History и другие UX-недоработки.
Не думаю, что кто-то заморачивался над скроллами каждого блока на странице. Опять же, мы просто не подошли к этой проблеме. Куча более банальных вещей требуют нашего внимания.
Что касается инпутов и прочего, я решал так: делал в глобальном стейте ветки, синхронизированными с History state и c URL query. Дальше остаётся только поместить нужные данные внутрь этих веток и их состояние будет сохраняться при переходах по истории или даже при перезагрузке страницы. Всё ещё нужно задуматься, какие данные где хранить, но дальше дополнительных действий не требуется.
Я имел ввиду, что нас отбросили назад Реакт и Редакс.
Реакт слишком низкоуровневый. Отказ от двустороннего датабиндинга — ошибка. Это не решение проблемы, а бегство. Аналогично можно отказываться от высокоуровневых ЯП и писать всё на Ассемблере, чтобы делать всё явно. На простых задачах десятки строк Реакта и Редакса — просто двусторонний датабиндинг написанный явным образом. На сложных — все эти ограничения по потокам данных никак не помогают. С двусторонним датабиндингом легко запутаться. А в решении проблем, которые созданы ограничениями Редакса, невозможно не запутаться.
На практике это будет не так. Кто-то будет в обоих случаях целится в надпись, а кто-то — в область вокруг. Здесь личный опыт сработает сильнее всяких рамок. Если хотите, чтобы 100% пользователей поняли, что вся область кликабельна, сделайте каждый пункт меню в виде большой нестилизованной <button>. И радуйтесь, что вы решили эту задачу, убив всё остальное.
Если человек не видит размеры области нажатия из‐за отсутствия границ, то он склонен считать областью саму надпись и будет целиться именно в неё.
Человек не думает ни о каких областях нажатия. Он кликнет так, чтобы ему было понятно, чего он хочет. А когда из-за плохого дизайна машина его не поймёт, он переучиться кликать на саму надпись, а не на область. И бордеры не исправят это. Только cursor: pointer и время, проведённое с нормальным интерфейсом.
1. UX затрагивается в статье во многих местах. Конкретно эта проблема, на мой взгляд, описывается в пункте Navigation:
Мы ожидаем, что интерфейс будет «стабильным» при взаимодействии с ним. Элементы не должны внезапно исчезать
… и прыгать.
2. Пусть так. Но прыгать в интерфейсе ничего не должно. Тогда изменение ширины нужно анимировать. Но мне кажется, что в большинстве случаев фиксированная ширина сработает лучше.
3. Я, кстати, не уверен. Меняя DOM при скроле вы решили одну проблему, создав другую.
4. Очень много вопросов хорошо разобраны в советах Бюро: bureau.ru/bb/soviet. Не какие-то догмы, а аргументированные разборы задач.
Я ненавижу Реакт не меньше вашего. И как раз хотел написать комментарий, что Дэн отбросил сообщество в создании качественного UX назад. Если добавление самой микроскопической функции требует изменение нескольких слоёв, разбросанных по нескольким файлам — на хороший UX внимания уже не остаётся. Если базовые задачи раздроблены на десятки плохо связанных библиотек — на хороший UX внимания уже не остаётся.
Вы как всегда пытаетесь сделать вид, что у $mol всё хорошо из коробки. Но вот вам камень в оба огорода: что в документации Redux, что в демках $mol не сохраняется положение скролла при движении по истории (History Back). Наши инструменты должны сами решать такие проблемы по умолчанию, без прикладывания усилий.
Конечно, элемент, который обрамлён рамкой, лучше заметен. В этом и проблема. Если всё обвести рамками, всё начнёт кричать. Под «шумом» подразумевается то, что каждый элемент (в том числе и пустоту) мозгу необходимо прочитать и обработать. Но пустоты считываются легче. Всё это особенно критично, когда мы учимся работать с интерфейсом. Конечно, потом мозг привыкает и быстрее отбрасывает мусор. Но вероятность совершить ошибку всё равно выше, потому что мусор продолжает создавать лишнюю нагрузку.
То что в Материале есть карточки, не значит, что их нужно использовать везде.
Не думаю, что матчасть противоречивая. Скорее её мало кто знает. Я программист, немного интересующийся дизайном. И даже при этом вижу грубые ошибки повсюду. То что дизайнеры убирая рамки и увеличивая отступы, например, забывают о контрасте и правиле внутреннего и внешнего, не значит, что рамки нужно пихать везде. Приёмов ещё много.
Особенно достало читать в комментах выпады в сторону анимации. Если вас анимация бесит, это значит, что анимация хреновая, а не то что она не нужна. И тоже самое с другими современными тенденциями в дизайне. Не тенденции плохие, а дизайнеры (или программисты), которые не понимают их сути. Достаточно посмотреть на тот же Материал и на CSS-фреймворки, его реализующие.
Чем лучше видишь боковым зрением элемент, тем быстрее попадёшь в него мышкой. Логично?
Не логично. Если только вы не покажите, как вы попадаете мышкой в цель, которая находится в области бокового зрения.
Вот об этом я и писал выше. Почему??? Кто придумал это правило, и почему его надо применять везде? А критически поразмыслить не судьба?
Как уже написали выше: потому что отступы создают меньше шума. Именно поэтому правило так и звучит: «предпочтение лучше отдавать». И это не значит, что везде нужно использовать отступы, а не бордеры. Это значит, что как раз нужно использовать критическое мышление. Для которого хорошо бы сначала изучить матчасть.
Приятно, что хоть кто-то ещё в мире называет костыль «костылем». Не подскажете, есть ли хоть какие-то более-менее популярные фреймворки, которые не пытаются эмулировать декларативность через императивщину? Из непопулярных-то я знаю. DerbyJS имеет замечательную архитектуру с честными декларативными шаблонами. Но интересно, существует ли какой-нибудь более популярный проект?
Мы же обсуждаем разработку капчи, а не людей, которые подключают сторонний сервис.
Всё-таки для почты эта задача мне кажется сложнее, чем для сайтов. Да и справляются фильтры сегодня весьма хорошо. И с капчой есть «заметный процент промахов и ложных срабатываний». Если точнее — капча справляется гораздо хуже.
Почему бы не направить усилия на распознавание зловреда вместо того, чтобы мучить людей решением ваших проблем? В статье много написано про выкрутасы с ИИ. Но распознавание спама выглядит куда более простой задачей для ИИ. И обойти защиту значительно сложнее, чем распознавать любую капчу, потому что текст должен быть рекламным. По-моему, это очередной пример, когда настоящую задачу подменяют какой-то технической мурой.
Зачем? Зачем вы едите этот кактус? Как этот ворох костылей мог стать мейнстримом?
Мне повезло, я столкнулся с проблемой переопределения колбеков в самом начале знакомства с React. Больше всего меня поразило, что эта проблема никого особо не волнует. Ок, разработчики Реакта наконец выдали какое-то решение. Но ведь это же редкое уродство. Во второй аргумент useCallback ещё нужно добавить какой-нибудь идентификатор, чтобы мемоизировать несколько разных колбеков. Мемоизатор скорее всего будет жрать память. Всё это громоздко и неудобно.
Конечно, кроме мемоизации другого решения и не найти, если колбек передаётся в цикле. Почему не признать, что подходы Реакта тупиковые? Нет, продолжают костылять: «In the future, a sufficiently advanced compiler could create this array automatically.» А может пора отбросить попытки эмулировать декларативность императивщиной и использовать нормальный DSL?
Последние 5 лет я работал с Дерби. Было много набитых шишек и боли. Постоянно сомневался, не стоит ли вернутся к более трендовым технологиям. Два месяца назад пришлось начать работать с Реактом. До сих пор шокирован, насколько в трендах всё не лучше. Столько хайпа вокруг React+Redux — а никаких Best Practice точно также нет. В тоннах статей описывают решения только примитивнейших задач. И даже при этом решения имеют явные проблемы. В итоге на многих современных сайтах всё скачет при загрузке, не работает нормально Browser History и другие UX-недоработки.
Что касается инпутов и прочего, я решал так: делал в глобальном стейте ветки, синхронизированными с History state и c URL query. Дальше остаётся только поместить нужные данные внутрь этих веток и их состояние будет сохраняться при переходах по истории или даже при перезагрузке страницы. Всё ещё нужно задуматься, какие данные где хранить, но дальше дополнительных действий не требуется.
Реакт слишком низкоуровневый. Отказ от двустороннего датабиндинга — ошибка. Это не решение проблемы, а бегство. Аналогично можно отказываться от высокоуровневых ЯП и писать всё на Ассемблере, чтобы делать всё явно. На простых задачах десятки строк Реакта и Редакса — просто двусторонний датабиндинг написанный явным образом. На сложных — все эти ограничения по потокам данных никак не помогают. С двусторонним датабиндингом легко запутаться. А в решении проблем, которые созданы ограничениями Редакса, невозможно не запутаться.
Человек не думает ни о каких областях нажатия. Он кликнет так, чтобы ему было понятно, чего он хочет. А когда из-за плохого дизайна машина его не поймёт, он переучиться кликать на саму надпись, а не на область. И бордеры не исправят это. Только cursor: pointer и время, проведённое с нормальным интерфейсом.
… и прыгать.
2. Пусть так. Но прыгать в интерфейсе ничего не должно. Тогда изменение ширины нужно анимировать. Но мне кажется, что в большинстве случаев фиксированная ширина сработает лучше.
3. Я, кстати, не уверен. Меняя DOM при скроле вы решили одну проблему, создав другую.
4. Очень много вопросов хорошо разобраны в советах Бюро: bureau.ru/bb/soviet. Не какие-то догмы, а аргументированные разборы задач.
Я ненавижу Реакт не меньше вашего. И как раз хотел написать комментарий, что Дэн отбросил сообщество в создании качественного UX назад. Если добавление самой микроскопической функции требует изменение нескольких слоёв, разбросанных по нескольким файлам — на хороший UX внимания уже не остаётся. Если базовые задачи раздроблены на десятки плохо связанных библиотек — на хороший UX внимания уже не остаётся.
Вы как всегда пытаетесь сделать вид, что у $mol всё хорошо из коробки. Но вот вам камень в оба огорода: что в документации Redux, что в демках $mol не сохраняется положение скролла при движении по истории (History Back). Наши инструменты должны сами решать такие проблемы по умолчанию, без прикладывания усилий.
Я видел пару ваших демок. Таблица, у которой прыгают границы столбцов во время прокрутки — это точно не вписывается в принципы хорошего дизайна.
То что в Материале есть карточки, не значит, что их нужно использовать везде.
Не думаю, что матчасть противоречивая. Скорее её мало кто знает. Я программист, немного интересующийся дизайном. И даже при этом вижу грубые ошибки повсюду. То что дизайнеры убирая рамки и увеличивая отступы, например, забывают о контрасте и правиле внутреннего и внешнего, не значит, что рамки нужно пихать везде. Приёмов ещё много.
Особенно достало читать в комментах выпады в сторону анимации. Если вас анимация бесит, это значит, что анимация хреновая, а не то что она не нужна. И тоже самое с другими современными тенденциями в дизайне. Не тенденции плохие, а дизайнеры (или программисты), которые не понимают их сути. Достаточно посмотреть на тот же Материал и на CSS-фреймворки, его реализующие.
Не логично. Если только вы не покажите, как вы попадаете мышкой в цель, которая находится в области бокового зрения.
Как уже написали выше: потому что отступы создают меньше шума. Именно поэтому правило так и звучит: «предпочтение лучше отдавать». И это не значит, что везде нужно использовать отступы, а не бордеры. Это значит, что как раз нужно использовать критическое мышление. Для которого хорошо бы сначала изучить матчасть.