protoc генерирует файлы с абсолютным импортом, то есть если он генерирует файл greeter_pb2.py, то в соседнем greeter_pb2_grpc.py будет импорт `import greeter_pb2`. Есть несколько решений, но все они требуют каких-то действий:
Руками изменить импорт на относительный
В модулях нашего приложения добавить путь к директории сgreeter_pb2.py в sys.path для простого импорта.
Помещать сгенерированные файлы в корень проекта
Изначально сгенерированный код не проходит линтеры, варианты:
Править руками
Править автоматически
Не править и добавить в исключения
Лично мне не нравится добавлять в игнорирование Python модуль, который явно добавляется в репозиторий, но это ИМХО.
Если честно, у меня пока нет мыслей других опций, как можно эти две проблемы решать по другому
Со всем согласен, с перечисленными проблемами в gRPC столкнулся ещё на работе, но хочу поспорить с тем, что если gRPC - это про экстремальные нагрузки, то и Python будет узким местом. Мне кажется, что это не всегда справедливо, ведь большая нагрузка на сеть (соответственно требуется экономия трафика и увеличение скорости передачи) не всегда связаны с невозможностью этот трафик обработать. Например, сеть у нас ограниченная, а вот вычислительных ресурсов достаточно.
Очень хотел описать это и в статье, но не смог сформулировать. Если Python - интерпретируемый и относительно медленный, это не значит, что он не может решать задачи эффективно и работать с низкоуровневыми протоколами. Вопрос будет стоять скорее в том, насколько эффективно в определённой задаче Python сможет заниматься обработкой данных, полученных по этому самому протоколу
И насколько уместен gRPC в той или иной задаче - решать каждому отдельному программисту, но мне кажется что связка Python + gRPC имеет право на существование
Да нет, тут скорее в рамках пробы, как я и описывал, не было потребности в Sapphire уменьшать размер трафика (его в принципе пока почти нет), просто хотелось попробовать
Сейчас - никак, вы правы, но сама библиотека генерирует proto файл и на его основе делает gRPC сервер, совсем нет проблем так же в рантайме генерировать proto файл и получать его (или генерировать перед этим), а клиент уже генерировать на основе этого proto файла (или вообще чтобы сервер генерировал полноценный Python клиент).
Здесь я скорее хотел показать другой способ использования gRPC и упросить некоторые шаги. Опять же, если версионирование и обратная совместимость нужны, то конечно вариант с proto-файлом как основным источником - максимально полезный. Но в тех случаях когда это не очень важно, думаю, что такая библиотека была бы удобным инструментом, это позволяет быстро поднять gRPC интерфейс, посмотреть что да как
Да, в статье я как раз описал, что по моему мнению сам протокол абсолютно не сложный, в данном случае мною была попытка как раз убрать рутинные действия, чтобы разработчику в принципе было просто начать. Да и в принципе как разработчик всегда стараюсь убрать рутинные действия
За свою команду могу сказать, что нам проще и быстрее разделить сложную логику на маленькие части. Предполагаю, что так нам будет намного проще писать и даже если где-то будет заведомо плохая архитектура - она не будет распространятся дальше, как это могло бы быть в монолите
По поводу длинного сообщения в пуше - это делается специально, так как мошенники на андроид смартфонах могут вести съёмку экрана (конечно же, без некоторых действий со стороны пользователя это невозжможно). Поэтому это не просто баг. В компаниях всё-таки не дураки работают
Вот по поводу географического распределения - очень интересно. Если честно, не очень понятно, как это организовать без дополнительных трат, когда у тебя одно место жительства. По поводу Syncthing - уже настроил, хочу в следующей части описать
Ну если не передёргивать, то в отличие от хостера, все риски при самостоятельном бэкапе лежат целиком и полностью на вас. Вы платите хостеру, чтобы в один момент узнать, что все ваши данные утеряны и на их сохранность вы никак не можете повлиять. Когда вы сами этим занимаетесь, у вас больше контроля и как минимум вам будет кому предъявлять претензии - себе, ИМХО
Вопрос: подобная ситуация невозможна, если сервер не у меня дома?
И всё же если у меня стоит маршрутизатор перед сервером, то разве это возможно? Или этот пример - ответ на вопрос, почему не стоит делать роутер+сервер?
Не очень понимаю, почему возможность потрогать самому руками не связана с точным знанием, кто имеет доступ. Я бы сказал, что оно напрямую связано с точным знанием, но не гарантирует его. Мне кажется, если я сам втыкаю Ethernet кабель, сам устанавливаю жёсткие диски + к тому же сам настраиваю фаерволл и пробрасываю порты, сам выпускаю ключи и настраиваю sshd, то кажется это напрямую приближает меня к точному знанию о том, кто имеет доступ к моим данным.
По поводу роутер+обработка данных, как я и писал, я часто слышал, что это не хорошо, но к сожалению нигде не видел объяснения, почему это нехорошо и как на самом деле это влияет на производительность в целом. А хочу реализовать такую штуку по двум причинам
Хочется чтобы одна коробка содержала в себе все
Хочется самостоятельно посмотреть, ощутить на своём опыте, чем же это плохо
Интуитивно я и сам понимаю, что это плохое решение, но всё же для меня это не ответ. Сомнений добавляет и то, что одно из описанных мною решений (Amber Pro) реализовало именно это на не особо мощном железе. Так что кажется, что это вполне жизнеспособный вариант, надо только проверить
Да, наверное в моём случае это хождение по тонкой грани - компактность или объём и отказоустойчивость. Для меня важно, что мой сервер может поместиться в рюкзак, что его довольно комфортно перевозить Спасибо большое, про диски это очень важная информация, так как за я об этих особенностях не знал и даже не парился по этому поводу, теперь, конечно, есть смысл пересмотреть то, что получилось, возможно как-нибудь перестраховаться, условно - зашифрованный бэкап на Гугл диск или ещё как-то. Но это просто первая мысль
Немного не понял вопроса. В принципе хотелось, чтобы данные хранились где-то, куда я могу достать руками, чтобы я точно знал, где они есть, кто имеет к ним доступ и т.д.
Всего оказалось две проблемы:
protoc генерирует файлы с абсолютным импортом, то есть если он генерирует файл greeter_pb2.py, то в соседнем greeter_pb2_grpc.py будет импорт `import greeter_pb2`. Есть несколько решений, но все они требуют каких-то действий:
Руками изменить импорт на относительный
В модулях нашего приложения добавить путь к директории с
greeter_pb2.pyвsys.pathдля простого импорта.Помещать сгенерированные файлы в корень проекта
Изначально сгенерированный код не проходит линтеры, варианты:
Править руками
Править автоматически
Не править и добавить в исключения
Лично мне не нравится добавлять в игнорирование Python модуль, который явно добавляется в репозиторий, но это ИМХО.
Если честно, у меня пока нет мыслей других опций, как можно эти две проблемы решать по другому
Со всем согласен, с перечисленными проблемами в gRPC столкнулся ещё на работе, но хочу поспорить с тем, что если gRPC - это про экстремальные нагрузки, то и Python будет узким местом. Мне кажется, что это не всегда справедливо, ведь большая нагрузка на сеть (соответственно требуется экономия трафика и увеличение скорости передачи) не всегда связаны с невозможностью этот трафик обработать. Например, сеть у нас ограниченная, а вот вычислительных ресурсов достаточно.
Очень хотел описать это и в статье, но не смог сформулировать. Если Python - интерпретируемый и относительно медленный, это не значит, что он не может решать задачи эффективно и работать с низкоуровневыми протоколами. Вопрос будет стоять скорее в том, насколько эффективно в определённой задаче Python сможет заниматься обработкой данных, полученных по этому самому протоколу
И насколько уместен gRPC в той или иной задаче - решать каждому отдельному программисту, но мне кажется что связка Python + gRPC имеет право на существование
Уже сейчас есть возможность включить рефлексию, но возможно было бы лучше, если бы рефлексия была включена по умолчанию, возможно, вы правы
Да нет, тут скорее в рамках пробы, как я и описывал, не было потребности в Sapphire уменьшать размер трафика (его в принципе пока почти нет), просто хотелось попробовать
Сейчас - никак, вы правы, но сама библиотека генерирует proto файл и на его основе делает gRPC сервер, совсем нет проблем так же в рантайме генерировать proto файл и получать его (или генерировать перед этим), а клиент уже генерировать на основе этого proto файла (или вообще чтобы сервер генерировал полноценный Python клиент).
Здесь я скорее хотел показать другой способ использования gRPC и упросить некоторые шаги. Опять же, если версионирование и обратная совместимость нужны, то конечно вариант с proto-файлом как основным источником - максимально полезный. Но в тех случаях когда это не очень важно, думаю, что такая библиотека была бы удобным инструментом, это позволяет быстро поднять gRPC интерфейс, посмотреть что да как
Да, в статье я как раз описал, что по моему мнению сам протокол абсолютно не сложный, в данном случае мною была попытка как раз убрать рутинные действия, чтобы разработчику в принципе было просто начать. Да и в принципе как разработчик всегда стараюсь убрать рутинные действия
Я когда читал курсы давал такую задачку на самостоятельную работу в классе, правда в ней предполагалось использовать регулярные выражения: https://informatics.msk.ru/mod/statements/view.php?id=3163#1
За свою команду могу сказать, что нам проще и быстрее разделить сложную логику на маленькие части. Предполагаю, что так нам будет намного проще писать и даже если где-то будет заведомо плохая архитектура - она не будет распространятся дальше, как это могло бы быть в монолите
Когда ты пробуешь игридиенты по отдельности перед приготовлением
По поводу длинного сообщения в пуше - это делается специально, так как мошенники на андроид смартфонах могут вести съёмку экрана (конечно же, без некоторых действий со стороны пользователя это невозжможно). Поэтому это не просто баг. В компаниях всё-таки не дураки работают
Ну или я не понял иронии статьи
Вот по поводу географического распределения - очень интересно. Если честно, не очень понятно, как это организовать без дополнительных трат, когда у тебя одно место жительства. По поводу Syncthing - уже настроил, хочу в следующей части описать
Ну если не передёргивать, то в отличие от хостера, все риски при самостоятельном бэкапе лежат целиком и полностью на вас. Вы платите хостеру, чтобы в один момент узнать, что все ваши данные утеряны и на их сохранность вы никак не можете повлиять. Когда вы сами этим занимаетесь, у вас больше контроля и как минимум вам будет кому предъявлять претензии - себе, ИМХО
CRM или SRM, 2.5 или 3.5?
А какие у вас диски?
Вопрос: подобная ситуация невозможна, если сервер не у меня дома?
И всё же если у меня стоит маршрутизатор перед сервером, то разве это возможно? Или этот пример - ответ на вопрос, почему не стоит делать роутер+сервер?
От пожара не спасёт сколько угодно RAID на любых носителях, если они в одном месте. Тут уже проблема доверия к тому, чтобы размещать данные где-то ещё
Не очень понимаю, почему возможность потрогать самому руками не связана с точным знанием, кто имеет доступ. Я бы сказал, что оно напрямую связано с точным знанием, но не гарантирует его. Мне кажется, если я сам втыкаю Ethernet кабель, сам устанавливаю жёсткие диски + к тому же сам настраиваю фаерволл и пробрасываю порты, сам выпускаю ключи и настраиваю sshd, то кажется это напрямую приближает меня к точному знанию о том, кто имеет доступ к моим данным.
По поводу роутер+обработка данных, как я и писал, я часто слышал, что это не хорошо, но к сожалению нигде не видел объяснения, почему это нехорошо и как на самом деле это влияет на производительность в целом. А хочу реализовать такую штуку по двум причинам
Хочется чтобы одна коробка содержала в себе все
Хочется самостоятельно посмотреть, ощутить на своём опыте, чем же это плохо
Интуитивно я и сам понимаю, что это плохое решение, но всё же для меня это не ответ. Сомнений добавляет и то, что одно из описанных мною решений (Amber Pro) реализовало именно это на не особо мощном железе. Так что кажется, что это вполне жизнеспособный вариант, надо только проверить
Да, наверное в моём случае это хождение по тонкой грани - компактность или объём и отказоустойчивость. Для меня важно, что мой сервер может поместиться в рюкзак, что его довольно комфортно перевозить Спасибо большое, про диски это очень важная информация, так как за я об этих особенностях не знал и даже не парился по этому поводу, теперь, конечно, есть смысл пересмотреть то, что получилось, возможно как-нибудь перестраховаться, условно - зашифрованный бэкап на Гугл диск или ещё как-то. Но это просто первая мысль
Немного не понял вопроса. В принципе хотелось, чтобы данные хранились где-то, куда я могу достать руками, чтобы я точно знал, где они есть, кто имеет к ним доступ и т.д.
https://www.toshiba-storage.com/ru/products/toshiba-internal-hard-drives-l200/
Вот здесь описание как раз того диска, который есть у меня. Он, конечно же, на SMR, но есть модели на CMR и тоже 2.5 дюйма