Судя по всему, navigation favorites — это приватная функция в Android Auto, то есть только Google Maps и Waze могут ей пользоваться. Примерно как раньше только в этих приложениях можно было свапить карту пальцами.
Действие знака 3.1 («кирпич») не распространяется на маршрутные транспортные средства:
Действие знаков не распространяется:
3.1-3.3, 3.18.1, 3.18.2, 3.19 и 3.34 - на маршрутные транспортные средства;
"Маршрутное транспортное средство" - транспортное средство общего пользования (автобус, троллейбус, трамвай), используемое при осуществлении регулярных перевозок пассажиров и багажа в соответствии с законодательством Российской Федерации об организации регулярных перевозок и движущееся по установленному маршруту с обозначенными местами остановок.
Поскольку такси маршрутным транспортным средством не является, то и проезжать «под кирпич» на нём нельзя.
Это ресурсозатратно на больших объёмах, к тому же неочевидно — ведь более-менее читаемый с точки зрения алгоритмов контент уже доступен в HTML. Это же не таргетированный парсинг конкретного сайта, а сканирование миллионов веб-страниц с тысяч сайтов.
Для одного низкокардинального фасета, конечно, ничего делать и не нужно, но что, если кардинальность будет сильно больше? И если фасетов будет не один, а множество? У вас же сложность O(M * K), где M — количество сматченных документов, K — число фасетов. То есть 4 фасета должны дать увеличение времени где-то в 4 раза. Хотя, конечно, это всё ещё будут миллисекунды.
Ну в общем случае будет неизвестно, ShieldFont там, или какой-то другой — его же специально или нет, но назвать по-другому. А вот времени и ресурсов у бота для выполнения скриптов может не быть.
Насколько я могу видеть, никакой специальной предварительной индексации для фасетов не делается. Тогда, если базовый запрос сматчит миллионы записей, например, пользователь не ограничит выборку по бренду или другим существенным параметрам, весь этот миллион и будет пропускаться через каждый фасет. У вас есть планы по дальнейшей оптимизации подобных сценариев?
We never show scrambled text to screen readers. ShieldFont hides shielded passages from accessibility tools by default with aria-hidden="true", because a decoy read aloud is fluent, grammatical, wrong English, and that is worse than silence.
The real words remain sealed in the page, and the reader’s browser uncovers them by solving a compute-heavy puzzle. It requires JavaScript and a few seconds of processing, more than most mass scrapers are willing to spend. This makes the content available to most screen readers, translators, and copy/paste, but there is still room to improve and make it instantly available.
Браузер это не сам конвертирует. Он просто рендерит текст этим шрифтом. Сам шрифт содержит в себе скрипт, который для конкретной последовательности символов, например "february", делает замену и отображает текст как "august". Следовательно, в общем случае боту нужно будет загрузить сам шрифт и симулировать все преобразования глифов, которые он делает. Либо отрендерить весь текст этим шрифтом и затем распознать.
нужно вводить локальный адаптив "всем красный" чтобы при подъезде включался зеленый нужному направлению
По дефолту светофор должен работать в «тупом» режиме: переключаться, условно, каждые 30 секунд — 1 минуту, а все интеллектуальные системы могут только вмешиваться в этот процесс. Иначе при сбое камер всем вечно будет гореть красный.
Ну хорошо. Так что будет, если они изначально неправильные как в моём примере?
Там замены слов целиком, например, перемешивает месяцы.
Ок, но тогда ты прочитаешь мусорный текст вместо настоящего.
Я думал, что речь про глобальные закладки в самом Android Auto.
Судя по всему, navigation favorites — это приватная функция в Android Auto, то есть только Google Maps и Waze могут ей пользоваться. Примерно как раньше только в этих приложениях можно было свапить карту пальцами.
Действие знака 3.1 («кирпич») не распространяется на маршрутные транспортные средства:
Поскольку такси маршрутным транспортным средством не является, то и проезжать «под кирпич» на нём нельзя.
Ещё скажите, что нужно прогноз погоды прикрутить: вдруг к 8 утра в Питере будет ожидаться снегопад, и ожидаемые пробки станут ещё больше.
Наверное потому что Яндекс стал уже тяжёлым и неповоротливым, и «проснётся» только когда подобную систему реализуют где-нибудь в Европе или США.
Это ресурсозатратно на больших объёмах, к тому же неочевидно — ведь более-менее читаемый с точки зрения алгоритмов контент уже доступен в HTML. Это же не таргетированный парсинг конкретного сайта, а сканирование миллионов веб-страниц с тысяч сайтов.
Какой ещё флаг скринридера? Кто и как должен его определять?
Там для скринридера отдельно вычисляется «нормальный» контент специально замедленным скриптом.
Для одного низкокардинального фасета, конечно, ничего делать и не нужно, но что, если кардинальность будет сильно больше? И если фасетов будет не один, а множество? У вас же сложность O(M * K), где M — количество сматченных документов, K — число фасетов. То есть 4 фасета должны дать увеличение времени где-то в 4 раза. Хотя, конечно, это всё ещё будут миллисекунды.
А шрифт называется как-нибудь `a596ed9.woff` — и не поймёшь какой он
В таблице стилей там только подключение шрифта, который может быть назван как угодно
Ну в общем случае будет неизвестно, ShieldFont там, или какой-то другой — его же специально или нет, но назвать по-другому. А вот времени и ресурсов у бота для выполнения скриптов может не быть.
Насколько я могу видеть, никакой специальной предварительной индексации для фасетов не делается. Тогда, если базовый запрос сматчит миллионы записей, например, пользователь не ограничит выборку по бренду или другим существенным параметрам, весь этот миллион и будет пропускаться через каждый фасет. У вас есть планы по дальнейшей оптимизации подобных сценариев?
Для скринридеров у них отдельный костыль:
Браузер это не сам конвертирует. Он просто рендерит текст этим шрифтом. Сам шрифт содержит в себе скрипт, который для конкретной последовательности символов, например "february", делает замену и отображает текст как "august". Следовательно, в общем случае боту нужно будет загрузить сам шрифт и симулировать все преобразования глифов, которые он делает. Либо отрендерить весь текст этим шрифтом и затем распознать.
По дефолту светофор должен работать в «тупом» режиме: переключаться, условно, каждые 30 секунд — 1 минуту, а все интеллектуальные системы могут только вмешиваться в этот процесс. Иначе при сбое камер всем вечно будет гореть красный.
Можно подробнее? Есть пруф?
У нас на работе экспериментировали в GPT. Благо OpenAI дал всем месячный анлим. Результат далёк от ожидаемого.