Например визуальный взлом машинного зрения, как-то спец раскрас, отражающие поверхности и прочие превосходно определяемые радаром поверхности, не говоря уже о намеренном вводе в заблуждение, как-то "это не утка, это собака" путём добавления пары штрихов невидимых для человека, но критичных для распознования машинным зрением.
Только мобильное приложение невозможно фильтровать в плане слежки. После сёрфинга в приложении потом начинается шквал писем, что я забыл, где там "скидка" и что обязательно прямо сейчас нужно купить.
Видимо суть в том, что условия, на которых сейчас это возможно, такие "неудобные", что никто этого делать не хочет (кроме Яндекса).
Странно как по мне другое — и срок, и невозможность выполнения в срок — проще всего отключить эту фичу временно — это ведь должно решить проблему монополии — равные условия для всех, а потом потихоньку допиливать, если времени не хватает. А они, видимо, решили просто забить и искать обходные пути вместо решения.
Свободные номера тут ни при чём, отели "продают" на букинг определённое кол-во номеров которое ≠ общему кол-ву свободных номеров в отеле.
Но вот по идее и продать их напрямую они не должны мочь, но тут я не уверен.
В общем, я понимаю, что Вы хотите упростить текущие проблемы с парсингом номеров и вынести их в отдельный сервис, но, к сожалению, данные карт — это, пожалуй, последнее что хочется отправлять на внешний сервис, даже если сейчас он вызывает доверие. Любой дополнительный встраиваемый скрипт, npm пакет или АПИ куда мы отправляем номера карт в открытом виде — это потенциальная брешь на будущее, ни один нормальный отдел безопасности этого не разрешит.
Моё мнение — если хотите идти в этом направлении — лучше всего делать это исключительно на стороне клиента, с минимумом кода (опен сорс, конечно же) который взаимодействует непосредственно с данными карты. Продать это будет крайне сложно, но как портфолио сойдёт. Скорее даже как ответ на SO к похожим вопросам, там часто бывает "я посмотрел на вопрос, и решил написать свою библиотеку для его решения". А так — удачи Вам, конечно, но на многое я бы не рассчитывал.
Ну вообще на многих популярных веб-сервисах ввод данных карты идёт прямо на странице сайта.
Это не значит, что так должно быть, и что это лучшая практика.
Возвращаясь к заголовку — королевская форма для приёма банковских карт та, которая не требует ввода карты. Да, я лучше буду доверять большим мастодонтам банковские данные, чем каждому третьему сайту обещающему не хранить данные карты (что, емнип, незаконно, лень искать, первый попавшийся результат тут же, на qna: https://qna.habr.com/q/76658), но сохраняющему у себя не только номер в открытом виде, но и CVV.
Нет, это определённо, не королевская форма.
Дебаггинг здесь не в прямом смысле, скорее редактирование стилей в браузере, перед добавлением их в код.
Я про это
Tailwind затрудняет настройку дизайна в браузере
Я занимаюсь как дизайном, так и frontend-разработкой, поэтому редактирование в браузере с помощью DevTools для меня крайне важно. С Tailwind работа в DevTools может стать сложнее. Скажем, например, я хочу изменить отступы для компонента. Когда я изменяю значение класса py-3, это влияет на каждый использующий его элемент страницы.
В данном случае в браузере он всё-равно получает tailwind, и сталкивается ровно с теми же проблемами — невозможно набору элементов быстро прописать какой-нибудь стиль — нужно вручную определить селектор, который будет применяться к этим элементам или каждому из элементов добавлять класс тейлвинда (это принципиально хуже традиционных подходов).
Причём разный код в браузере и в исходниках — это отдельная проблема, которую все мы давно знаем на примере препроцессоров (хотя с map'ами это значительно удобнее, чем без оных)
В идеальных условиях с новым сухим гидрозатвором, может ничего и не случится. Но добавить совершенно небольшую течь (незаметную для наполненной ванны) и из затвора тонким ручейком будет постоянный мост. А если добавить мокрые длинные волосы в слив (которые там есть почти всегда)… А ещё там всегда избыточная влажность, которой некуда деваться и всё это оседает на стенках труб.
И я, и вы были такими. И вроде ничего страшного не произошло, ничего постыдного сделано не было.
Я думаю, это наталкивает на мысль, что это обязательный опыт (при отсутствии ментора, как правило), и его нужно просто пройти, а не пренебрежительно тыкать пальцем.
Представьте себе, что Tailwind появляется только во время компиляции. То есть вы пишете обычный CSS с именованием и всё такое, а умный компилятор преобразует ваш CSS в утилитарные классы. Это было бы воплощением мечты.
Странное заключение, после статьи, где половина жалоб на усложнение дебаггинга стилей в браузере.
некоторые вон книги миллионами продают по теме ("легко бросить курить" и т.п.)
Ага, а ещё "первый миллион это просто" и прочие очень полезные книги. Популярность продаж не всегда коррелирует с положительным результатом прочитавших.
О, а ещё из их последних "улучшений" — они отказываются от всех модалок в пользу инлайн-подхода, как у vscode. Коммит — заменяется вью в текущем редакторе на коммит. Пулл реквест — то же самое. Дифф изменений — и тот туда же. А то, что у меня сплит (дифф сайд-бай-сайд очень смешно выглядит в сплите) и в каждом вью открыт ровно один файл (который заменяется новым окном) — это не важно.
Правильно, это Apple клавиатура. Delete = fn+backspace.
Например визуальный взлом машинного зрения, как-то спец раскрас, отражающие поверхности и прочие превосходно определяемые радаром поверхности, не говоря уже о намеренном вводе в заблуждение, как-то "это не утка, это собака" путём добавления пары штрихов невидимых для человека, но критичных для распознования машинным зрением.
Я думаю что это больше спортивный интерес, как рыбалка.
Или просто текстовый diff - он как минимум покажет что один пробел не равен другому пробелу, даже если они выглядят одинаково.
Я бы сказал, цель опроса в одном единственном вопросе - про плюшки бизнеса для работника.
Непопулярный ответ "Уютный офис" неплохо показывает тенденцию сместившуюся на другие плюшки с пандемией.
Только мобильное приложение невозможно фильтровать в плане слежки. После сёрфинга в приложении потом начинается шквал писем, что я забыл, где там "скидка" и что обязательно прямо сейчас нужно купить.
Видимо суть в том, что условия, на которых сейчас это возможно, такие "неудобные", что никто этого делать не хочет (кроме Яндекса).
Странно как по мне другое — и срок, и невозможность выполнения в срок — проще всего отключить эту фичу временно — это ведь должно решить проблему монополии — равные условия для всех, а потом потихоньку допиливать, если времени не хватает. А они, видимо, решили просто забить и искать обходные пути вместо решения.
Свободные номера тут ни при чём, отели "продают" на букинг определённое кол-во номеров которое ≠ общему кол-ву свободных номеров в отеле.
Но вот по идее и продать их напрямую они не должны мочь, но тут я не уверен.
В общем, я понимаю, что Вы хотите упростить текущие проблемы с парсингом номеров и вынести их в отдельный сервис, но, к сожалению, данные карт — это, пожалуй, последнее что хочется отправлять на внешний сервис, даже если сейчас он вызывает доверие. Любой дополнительный встраиваемый скрипт, npm пакет или АПИ куда мы отправляем номера карт в открытом виде — это потенциальная брешь на будущее, ни один нормальный отдел безопасности этого не разрешит.
Моё мнение — если хотите идти в этом направлении — лучше всего делать это исключительно на стороне клиента, с минимумом кода (опен сорс, конечно же) который взаимодействует непосредственно с данными карты. Продать это будет крайне сложно, но как портфолио сойдёт. Скорее даже как ответ на SO к похожим вопросам, там часто бывает "я посмотрел на вопрос, и решил написать свою библиотеку для его решения". А так — удачи Вам, конечно, но на многое я бы не рассчитывал.
Это не значит, что так должно быть, и что это лучшая практика.
Возвращаясь к заголовку — королевская форма для приёма банковских карт та, которая не требует ввода карты. Да, я лучше буду доверять большим мастодонтам банковские данные, чем каждому третьему сайту обещающему не хранить данные карты (что, емнип, незаконно, лень искать, первый попавшийся результат тут же, на qna: https://qna.habr.com/q/76658), но сохраняющему у себя не только номер в открытом виде, но и CVV.
Нет, это определённо, не королевская форма.
Видимо, речь об этом.
Дебаггинг здесь не в прямом смысле, скорее редактирование стилей в браузере, перед добавлением их в код.
Я про это
В данном случае в браузере он всё-равно получает tailwind, и сталкивается ровно с теми же проблемами — невозможно набору элементов быстро прописать какой-нибудь стиль — нужно вручную определить селектор, который будет применяться к этим элементам или каждому из элементов добавлять класс тейлвинда (это принципиально хуже традиционных подходов).
Причём разный код в браузере и в исходниках — это отдельная проблема, которую все мы давно знаем на примере препроцессоров (хотя с map'ами это значительно удобнее, чем без оных)
В идеальных условиях с новым сухим гидрозатвором, может ничего и не случится. Но добавить совершенно небольшую течь (незаметную для наполненной ванны) и из затвора тонким ручейком будет постоянный мост. А если добавить мокрые длинные волосы в слив (которые там есть почти всегда)… А ещё там всегда избыточная влажность, которой некуда деваться и всё это оседает на стенках труб.
Я думаю, это наталкивает на мысль, что это обязательный опыт (при отсутствии ментора, как правило), и его нужно просто пройти, а не пренебрежительно тыкать пальцем.
Странное заключение, после статьи, где половина жалоб на усложнение дебаггинга стилей в браузере.
Ага, а ещё "первый миллион это просто" и прочие очень полезные книги. Популярность продаж не всегда коррелирует с положительным результатом прочитавших.
Не стоит путать привычку с зависимостью.
Ну во-первых, сеньоры тоже делают ошибки.
Во-вторых, сеньоры разбирают тонны чужого кода и сторонние библиотеки, где кроме дебаггера альтернатив нет.
О, а ещё из их последних "улучшений" — они отказываются от всех модалок в пользу инлайн-подхода, как у vscode. Коммит — заменяется вью в текущем редакторе на коммит. Пулл реквест — то же самое. Дифф изменений — и тот туда же. А то, что у меня сплит (дифф сайд-бай-сайд очень смешно выглядит в сплите) и в каждом вью открыт ровно один файл (который заменяется новым окном) — это не важно.
Да хоть бы вынесли все цвета в глобальные css переменные — комьюнити было бы легче писать свои темы.