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