Серёга, вот в этом и заключается задача policy routing.
Можно начать с чтения ссылки в моём ответе. Я там помогал решить подобную проблему.
По сути надо сделать так, чтобы на конечном сервере было две таблицы маршрутизации. В одной (main, таблица по умолчанию) был дефолт такой, какой всегда. В другой (условно назовём её wg) был маршрут default via 10.9.9.1.
И добавить правило: ip rule from 10.9.9.5 lookup wg.
По ссылке я предлагаю для каждого провайдера задавать свою таблицу, чтобы переключениями default в таблице main можно было менять основного провайдера и при этом ничего не делать для сохранения policy routing на обоих провайдров. В случае с VPN имеет смысл задавать только одну таблицу, для VPN, потому что тут не будет переключений дефолта в main.
Пакет будет прилетать из wg с адресом получателя 10.9.9.5. Получатель будет обрабатывать пакет и посылать ответ с тем же адресом. Раньше он шёл по дефолту в таблице main, что было, мягко говоря, немного нехорошо. Теперь же он по списку правил (ip rule) будет находить правило from 10.9.9.5 и проваливаться в таблицу wg. А там default через другой шлюз.
ImagineTables, нет, дизайн самого плеера меня вообще не впечатлил, так как у плееров часто он кастомно-выпендрёжный. На этом скрине есть и другие окна.
loparenok, rustdesk не только имеет бесплатную версию, но и открытый исходный код её, а также позволяет поднять свой сервер, за что его и любят, в том числе в корпоративной среде.
Samsung делает это через механизм брендирования для поставщиков (операторов итд). Через некоторое время после покупки телефон понимает, что он в России, и настраивается на поставщика "закон", затем устанавливает дополнительный софт. При этом его можно спокойно удалить или заморозить (выключить). Поэтому оно не очень приятно, но легко купируется.
Вот! Выросло поколение, у когорых 2G означает полное отсутствие интернета. А ведь 20 лет назад я пользовался на даче интернетом 2G со скоростью не выше 10 кб/с и ничего, даже картинки не всегда отключал...
HoobaBooba, лучше код положить в гитхаб и в конце презентации показать на него ссылку, в том числе в виде QR-кода, чтобы зрители могли его быстро себе сохранить.
В самой презентации важно не портянки кода показывать, а изложить алгоритмы, принципы, подходы, рассказать о том, какие рассматривались варианты решения, от чего пришлось отказаться...
Код при необходимости показывать фрагментами, которые излагают какие-то конкретные вещи, в нём незначительные части можно опускать или заменять на словесные описания.
Например, для приложения сделан абстрактный класс с наследниками, которые позволяют загружать датасеты в разном формате и представлять их в виде единого интерфейса с полями, методами и итераторами? Вот пример загрузки датасета в csv со странами, по которому мы в три строки кода наглядного кода посчитаем среднее значение показателя. А вот другой пример рассчёта прогноза по данным прошлых лет, кроме последнего, и визуализация разницы прогноза с реальными данными последнего года. И чтобы зрителям стало понятно, как такой подход повышает читаемость кода, упрощает имплементацию алгоритмов и проверку различных гипотез.
Зачастую нет смысла показывать, что реальном куске кода, на котором основан фрагмент в презентации. есть также обработка исключений и ошибок http, фильтрация мусорных данных в датасете или что-то ещё такого же плана...
Даже полезные алгоритмы если и показывать в виде фрагментов кода - не всегда стоит приводить их полностью, имеет смысл упрощать. Всё равно код из презентации никто никогда запускать не будет. Его не для этого туда включают.
Просто выкинуть портянку на много строк и перед зрителями рассказывать, что каждая строчка делает, это антипаттерн, такой же, как классическое чтение пространного текста со слайдов, которым грешат иногда докладчики. Портянку лучше предоставить на гитхабе вместе с готовыми инструкциями по запуску и образцом хотя бы минимального набора данных для демонстрации работы приложения. Это всяко будет полезнее для потенциально заинтересовавшихся.
Конференции это особый жанр. На них надо рассказывать интересно, доступно для целевой аудитории, при этом важно успеть изложить наиболее значимое содержание. В конце концов, время выступления обычно не слишком большое.
Artem Mikhniuk, можно написать много парсеров. Тем более что в них много будет похожего кода. Например, будет отличаться в части имён тегов, где брать название или part number, или в части того, какой шаблон url постраничного вывода списка. Можно даже оптимизировать это и сделать какие-то общие функции и классы.
Тестировщик вошёл в бар, заказал кружку пива, заказал 10 кружек пива, заказал -1 кружку пива, заказа пиво на имя Bill Gates, заказал foobar кружек, заказал сахарную пудру, заказал [запрещено РКН]...
Если API доступен в публичном Internet, то запросить у него могут что угодно. В том числе белые и чёрные хакеры. Сервис должен всё это адекватно обработать, не упасть, не сделать что-то неправильное.
Например, если сервис требует авторизации, то надо проверять, что сервис работает с правильными кредами и корректно ругается с неправильными. Причём речь не только о валидности токена авторизации, но и о возможности и правомерность пользователя совершить действия. Например, чтобы пользователь не мог изменить пароль другого пользователя, только свой.
Регулярно вижу, как разработчики сайтов, например, не показывают данные пользователю без регистрации, но вся "защита" этого - ограничения на фронте. Прямые вызовы API возвращают всё вообще и никак не контролируют авторизацию пользователя.
