Т.е. интернет на объекте есть(хотяб внутренний, чтоб софтина работала)?
Коли да - просто ставь любой софт удалённого доступа(anydesk, vnc какой-нить) на комп с программой и клиент на планшет, всего делов.
Это точно будет работать, и возможно даже лучше чем голая софтина, заработанная без учёта тача.
С некоторым шансом будет работать тупо прям в винде коли джава, как заметили выше.
Установка линь на планшет, а потом поверх сотины - имеет сугубо теоретический шанс на работу.:)
Про вычисление рандома по распределению - херня, никто этого не будет делать, больше ресурсов уйдёт чем пользы. Только если прям массовый характер приобретёт благодаря какому-то популярному софту, тогда конкретно этот софт вычислять и будут.
По вычислению о заголовкам - да, всё зависит от того насколько хорошо софт имитирует браузер. Про конкретный ничего сказать не могу.
В идеале это должно быть расширение для браузера, тогда удачи им найти различия которых нет.
Проще взять за основу одну из систем, где больше всего уже предусмотрено и тупо дополнить и\или смапить в оную все остальные ошибки. Так будет меньше телодвижений, главное чтоб авторы системы не решили когда-нить её целиком перелопатить.:)
То что ты запрашиваешь страницу раз в 2 секунды они видят, точнее могут увидеть если захотят. Что-за веб-монитор - хз, если он нормально сделан то разницы меж тем что ты нервный шизик постоянно тыкающий f5 и программой увидеть нельзя. Только по косвенным: даже шизик не сможет это делать круглосуточно и с интервалом ровно 2с. Следовательно интервал надо романтизировать и на ночь софт отключать. :)
Сам по себе typescript вообще ничего не знает о Vue или о стилях, он только ts код проверяет.
Чтоб он "на лету" подхватывал виртуальные автосгенерирированные типы для стилей используются разные language service плагины для движка ts или вообще отдельные плагины для твоей IDE.
Это по сути очень замороченный и низкоуровневый костыль.
Тебе надо настроить, чтоб под капотом такого плагина сначала компиллился твой scss в css, а уж потом генрировал тайпинг, чего сейчас не происходит, полагаю, из-за вопросов производительности.
Возможно ли это без сложных телодвижений? Хз, надо изучать материалы по ссылке приведённой выше.:)
P.S. "Классическое" решение - просто отдельно запускать хрень(их несколько разных) которая будет следить за изменением файлов и генерить .d.ts, которые будет подхватываться на лету. Но так у тебя будет куча мусорных .d.ts'ок валяться, которые ещё и врать могут, если хрень забыл запустить или она отвалилась.:)
Насколько я знаю, @custom-media - мертвороженная фича, которая нигде не работает, sass, соответственно, её не поддерживает.
Любая постобработка обычно происходит уже после того как sass превратит результат в css, потому обычное использование postcss-плагина тут тоже не поможет.
Теоретически можно что-то вкорячить, но проще забить и работать по-старинке.
v-model это из-коробочный хэлпер, который делает примерно то же само что ты написал. Если переходишь с vue на react тебе постоянно будет не хватать таких мелочей.:)
Но ты можешь написать свой кастомный и использовать его везде. Или воспользоваться готовой библиотекой для подобного.
Сергей delphinpro, ну наверное есть какие-нить онлайн сборщики, которые под капотом тот-же webpack\vite имеют, но это надо гуглить, нормальным разрабам такое нужно редко.:)
Кирилл Щевелев, по поводу PascalCase - на той же странице также написано "kebab-case is also perfectly acceptable", но никто этого не читает (в том числе и сами разрабы vue после переписывания доков под vue3) и везде эта мерзость в стиле проклятого React. :)
Я считаю, что kebab-case гораздо приятнее и нативнее ощущается и в файлах и в щаблонах, да и читается проще. Но ктож меня слушать будет.:(
По распределению написали выше - делить по связанным кускам функционала.
Причём я считаю, что прям жестко: именование папок всегда одно, на одном уровне с модулем, всё что используется только на текущем уровне - лежит в таких-же папочках ниже уровнем - и так до самого низа. Если что-то используется совместно - лежит в папочке ровно на уровень вышке обоих пользователей (и соответственно перемещается выше-ниже - автоматизируемо). Это позволяет чётко рубить на куски любого размера, но радикально, да.
А по методологиям осторожнее. Ту же фсд я на практике видел - всегда говно выходит, где вместо разделения по фичам эти фичи размазаны по всей структуре - единичные страницы в страницах кушают единичные виджеты в виджетах, маршруты в маршрутах, апи в отдельной куче апи и т.д. Отвратительно. Это конечно не (совсем) вина фсд, а скорее разрабов, но реальный мир - реальный.
Если всё в одной подсети, как и написано в ответе, то в обычном случае нет - комутатор будет слать пакеты напрямую, не затрагивая роутер. Но комутатор можно настроить так, что делать он этого не будет, запретив прямую связность, и тогда весь трафик пойдёт через роутер, и всё упрётся не только в линк но и возможности самого роутера.
И конечно кастомный рендер - это сложно. Это очень низкоуровневая штука с кучаей тонких особенностей.
Если у тебя какая-то простенькая задача - возможео проще будет рендереть в html-строку и уже ту преобразовывать во что надо?