Vitaliy Ivanov, схему не особо понял:), но могу сказать что в принципе возможны любые конфигурации в рамках задачи, как бы не крутили, просто одни проще, другие сложнее.
Евгений, "домашний сервер" - это сервер, который стоит дома. Белый ip тут вообще за рамками задачи - его провайдер выдаёт, который за пределами того, что там намутит в любом случае.
Могу только сказать что в рамках домашней сети никакого VPN и туннелирования не надо, нужна той или иной сложности маршрутизация нормального сетевого трафика, в зависимости от желаемой конфигурации.
В идеале вы делаете из сервера полноценный роутер(помимо всего прочего), а роутер используете как простой свич(точку достпа):
клиенты - роутер(как свич) - сервер(как роутер) - интернет.
Это самый простой и логичный вариант, но можно и навертеть.
Евгений, предполагаю, что скорее всего автор хочет так:
клиенты - роутер - сервер - (обратно)роутер - интернет
Почему не логичная система где:
клиенты - роутер(в режиме свича) - сервер(как навороченный роутер) - интернет
Хз, но мб в сервере нет двух сетевух, или нет оптовой, или роутер специальный провадерский... Ну или, конечно, возможно просто непронимание базы.:)
Т.е. интернет на объекте есть(хотяб внутренний, чтоб софтина работала)?
Коли да - просто ставь любой софт удалённого доступа(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 тебе постоянно будет не хватать таких мелочей.:)
Но ты можешь написать свой кастомный и использовать его везде. Или воспользоваться готовой библиотекой для подобного.
Кирилл Щевелев, по поводу PascalCase - на той же странице также написано "kebab-case is also perfectly acceptable", но никто этого не читает (в том числе и сами разрабы vue после переписывания доков под vue3) и везде эта мерзость в стиле проклятого React. :)
Я считаю, что kebab-case гораздо приятнее и нативнее ощущается и в файлах и в щаблонах, да и читается проще. Но ктож меня слушать будет.:(
По распределению написали выше - делить по связанным кускам функционала.
Причём я считаю, что прям жестко: именование папок всегда одно, на одном уровне с модулем, всё что используется только на текущем уровне - лежит в таких-же папочках ниже уровнем - и так до самого низа. Если что-то используется совместно - лежит в папочке ровно на уровень вышке обоих пользователей (и соответственно перемещается выше-ниже - автоматизируемо). Это позволяет чётко рубить на куски любого размера, но радикально, да.
А по методологиям осторожнее. Ту же фсд я на практике видел - всегда говно выходит, где вместо разделения по фичам эти фичи размазаны по всей структуре - единичные страницы в страницах кушают единичные виджеты в виджетах, маршруты в маршрутах, апи в отдельной куче апи и т.д. Отвратительно. Это конечно не (совсем) вина фсд, а скорее разрабов, но реальный мир - реальный.
