Сейчас - никак, вы правы, но сама библиотека генерирует proto файл и на его основе делает gRPC сервер, совсем нет проблем так же в рантайме генерировать proto файл и получать его (или генерировать перед этим), а клиент уже генерировать на основе этого proto файла (или вообще чтобы сервер генерировал полноценный Python клиент).
Здесь я скорее хотел показать другой способ использования gRPC и упросить некоторые шаги. Опять же, если версионирование и обратная совместимость нужны, то конечно вариант с proto-файлом как основным источником - максимально полезный. Но в тех случаях когда это не очень важно, думаю, что такая библиотека была бы удобным инструментом, это позволяет быстро поднять gRPC интерфейс, посмотреть что да как
Да, в статье я как раз описал, что по моему мнению сам протокол абсолютно не сложный, в данном случае мною была попытка как раз убрать рутинные действия, чтобы разработчику в принципе было просто начать. Да и в принципе как разработчик всегда стараюсь убрать рутинные действия
За свою команду могу сказать, что нам проще и быстрее разделить сложную логику на маленькие части. Предполагаю, что так нам будет намного проще писать и даже если где-то будет заведомо плохая архитектура - она не будет распространятся дальше, как это могло бы быть в монолите
По поводу длинного сообщения в пуше - это делается специально, так как мошенники на андроид смартфонах могут вести съёмку экрана (конечно же, без некоторых действий со стороны пользователя это невозжможно). Поэтому это не просто баг. В компаниях всё-таки не дураки работают
Вот по поводу географического распределения - очень интересно. Если честно, не очень понятно, как это организовать без дополнительных трат, когда у тебя одно место жительства. По поводу Syncthing - уже настроил, хочу в следующей части описать
Ну если не передёргивать, то в отличие от хостера, все риски при самостоятельном бэкапе лежат целиком и полностью на вас. Вы платите хостеру, чтобы в один момент узнать, что все ваши данные утеряны и на их сохранность вы никак не можете повлиять. Когда вы сами этим занимаетесь, у вас больше контроля и как минимум вам будет кому предъявлять претензии - себе, ИМХО
Вопрос: подобная ситуация невозможна, если сервер не у меня дома?
И всё же если у меня стоит маршрутизатор перед сервером, то разве это возможно? Или этот пример - ответ на вопрос, почему не стоит делать роутер+сервер?
Не очень понимаю, почему возможность потрогать самому руками не связана с точным знанием, кто имеет доступ. Я бы сказал, что оно напрямую связано с точным знанием, но не гарантирует его. Мне кажется, если я сам втыкаю Ethernet кабель, сам устанавливаю жёсткие диски + к тому же сам настраиваю фаерволл и пробрасываю порты, сам выпускаю ключи и настраиваю sshd, то кажется это напрямую приближает меня к точному знанию о том, кто имеет доступ к моим данным.
По поводу роутер+обработка данных, как я и писал, я часто слышал, что это не хорошо, но к сожалению нигде не видел объяснения, почему это нехорошо и как на самом деле это влияет на производительность в целом. А хочу реализовать такую штуку по двум причинам
Хочется чтобы одна коробка содержала в себе все
Хочется самостоятельно посмотреть, ощутить на своём опыте, чем же это плохо
Интуитивно я и сам понимаю, что это плохое решение, но всё же для меня это не ответ. Сомнений добавляет и то, что одно из описанных мною решений (Amber Pro) реализовало именно это на не особо мощном железе. Так что кажется, что это вполне жизнеспособный вариант, надо только проверить
Да, наверное в моём случае это хождение по тонкой грани - компактность или объём и отказоустойчивость. Для меня важно, что мой сервер может поместиться в рюкзак, что его довольно комфортно перевозить Спасибо большое, про диски это очень важная информация, так как за я об этих особенностях не знал и даже не парился по этому поводу, теперь, конечно, есть смысл пересмотреть то, что получилось, возможно как-нибудь перестраховаться, условно - зашифрованный бэкап на Гугл диск или ещё как-то. Но это просто первая мысль
Немного не понял вопроса. В принципе хотелось, чтобы данные хранились где-то, куда я могу достать руками, чтобы я точно знал, где они есть, кто имеет к ним доступ и т.д.
Просто я не очень понимаю, какие риски существуют при использовании двух дисков на RAID 1. Как я понимаю, шанс отказа двух дисков одновременно минимален, зачем устанавливать ещё (если только не расширить доступную память)
На самом деле после использования программы я увидел проблему, как минимум я пользуюсь k9s и переключать контексты оказалось намного проще, чем подменять конфиги. Я потратил немного времени на то, чтобы разобраться в устройстве конфига и собрать один конфиг из нескольких. Единственная мысль появилась, что было бы хорошо иметь возможность из нескольких конфигов собрать один автоматизированно. Я ещё не искал, решена ли эта задача, но она требуется очень уж нечасто
Сейчас - никак, вы правы, но сама библиотека генерирует 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 дюйма
Просто я не очень понимаю, какие риски существуют при использовании двух дисков на RAID 1. Как я понимаю, шанс отказа двух дисков одновременно минимален, зачем устанавливать ещё (если только не расширить доступную память)
А под nextcloud есть приложение для zettelkasten?
Но ведь есть легаси... И оно дорогое
На самом деле после использования программы я увидел проблему, как минимум я пользуюсь k9s и переключать контексты оказалось намного проще, чем подменять конфиги. Я потратил немного времени на то, чтобы разобраться в устройстве конфига и собрать один конфиг из нескольких. Единственная мысль появилась, что было бы хорошо иметь возможность из нескольких конфигов собрать один автоматизированно. Я ещё не искал, решена ли эта задача, но она требуется очень уж нечасто